This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Ever since the first program was divided into modules, software systems have had architectures, and programmers have been responsible for the interactions among the modules and the global properties of the assemblage. Historically, architectures have been implicit accidents of implementation, or legacy systems of the past. Good software developers have often adopted one or several architectural patterns as strategies for system organization, but they use these patterns informally and have no means to make them explicit in the resulting system. Today, effective software architecture and its explicit representation and design have become dominant themes in software engineering.
When we discuss the architecture of a building, many different attributes come to mind. At the most simplistic level, we consider the overall shape of the physical structure. But in reality, architecture is much more. It is the manner in which the various components of the building are integrated to form a cohesive whole. It is the way in which the building fits into its environment and meshes with other buildings in its vicinity. It is the degree to which the building meets its stated purpose and satisfies the needs of its owner. It is the aesthetic feel of the structure-the visual impact of the building-and the way textures, colors, and materials are combined to create the external facade and the internal "living environment." It is small details-the design of lighting fixtures, the type of flooring, the placement of wall hangings, the list is almost endless. And finally, it is art.
The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.
The architecture is not the operational software. Rather, it is a representation that enables a software engineer to (1) analyze the effectiveness of the design in meeting its stated requirements, (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and (3) reducing the risks associated with the construction of the software.
This definition emphasizes the role of "software components" in any architectural representation. In the context of architectural design, a software component can be something as simple as a program module, but it can also be extended to include databases and "middleware" that enable the configuration of a network of clients and servers. The properties of components are those characteristics that are necessary to an understanding of how the components interact with other components. At the architectural level, internal properties (e.g., details of an algorithm) are not specified. The relationships between components can be as simple as a procedure call from one module to another or as complex as a database access protocol.
Why Is Architecture Important?
â€¢ Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system.
â€¢ The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.
â€¢ Architecture "constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together"
The architectural design model and the architectural patterns contained within it are transferable. That is, architecture styles and patterns can be applied to the design of other systems and represent a set of abstractions that enable software engineers to describe architecture in predictable ways.
Software design is both a process and a model. The design process is a sequence of steps that enable the designer to describe all aspects of the software to be built. It is important to note, however, that the design process is not simply a cookbook. Creative skill, past experience, a sense of what makes "good" software, and an overall commitment to quality are critical success factors for a competent design.
The design model is the equivalent of an architect's plans for a house. It begins by representing the totality of the thing to be built (e.g., a three-dimensional rendering of the house) and slowly refines the thing to provide guidance for constructing each detail (e.g., the plumbing layout). Similarly, the design model that is created for software provides a variety of different views of the computer software. Basic design principles enable the software engineer to navigate the design process.
â€¢ The design process should not suffer from "tunnel vision." A good
designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job, and the design concepts
â€¢ The design should be traceable to the analysis model. Because a single element of the design model often traces to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model.
â€¢ The design should not reinvent the wheel. Systems are constructed using a set of design patterns, many of which have likely been encountered before. These patterns should always be chosen as an alternative to reinvention. Time is short and resources are limited! Design time should be invested in representing truly new ideas and integrating those patterns that already exist.
â€¢ The design should "minimize the intellectual distance" [DAV95]
between the software and the problem as it exists in the real world.
That is, the structure of the software design should (whenever possible)
mimic the structure of the problem domain.
â€¢ The design should exhibit uniformity and integration. A design is uniform if it appears that one person developed the entire thing. Rules of style and format should be defined for a design team before design work begins. A design is integrated if care is taken in defining interfaces between design component
The design should be structured to accommodate change. The design
concepts discussed in the next section enable a design to achieve this principle.
â€¢ The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Well designed software should never "bomb." It should be designed to
Accommodate unusual circumstances, and if it must terminate processing, do so in a graceful manner.
â€¢ Design is not coding, coding is not design. Even when detailed procedural designs are created for program components, the level of abstraction of the design model is higher than source code. The only design decisions made at the coding level address the small implementation details that enable the
Procedural design to be coded.
â€¢ The design should be assessed for quality as it is being created, not
After the fact. A variety of design concepts and design measures
are available to assist the designer in assessing quality.
â€¢ The design should be reviewed to minimize conceptual (semantic)
errors. There is sometimes a tendency to focus on minutiae when the design is reviewed, missing the forest for the trees. A design team should ensure that major conceptual elements of the design (omissions, ambiguity, and inconsistency) have been addressed before worrying about the syntax of the design model. When these design principles are properly applied, the software engineer creates a design that exhibits both external and internal quality factors. External quality factors are those properties of the software that can be readily observed by users (e.g., speed, reliability, correctness, usability) Internal quality factors are of importance to software engineers. They lead to a high-quality design from the technical perspective. To achieve internal quality factors, the designer must understand basic design concept.
Design and Software Quality
Throughout the design process, the quality of the evolving design is assessed with a series of formal technical reviews or design walk through.
â€¢ The design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer.
â€¢ The design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.
â€¢ The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.
Each of these characteristics is actually a goal of the design process. But how is each of these goals achieved?
In order to evaluate the quality of a design representation, we must establish technical criteria for good design.
1. A design should exhibit an architectural structure that (1) has been created using recognizable design patterns, (2) is composed of components that exhibit good design characteristics (these are discussed later in this chapter), and (3) can be implemented in an evolutionary fashion, thereby facilitating implementation and testing.
2."To achieve a good A design should be modular; that is, the software should be logically partitioned into elements that perform specific functions and subfunctions.
3. A design should contain distinct representations of data, architecture, interfaces, and components (modules).
4. A design should lead to data structures that are appropriate for the objects to be implemented and are drawn from recognizable data patterns.
5. A design should lead to components that exhibit independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections between modules and with the external environment.
7. A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.
These criteria are not achieved by chance. The software design process encourages good design through the application of fundamental design principles, systematic methodology, and thorough review.
SOFTWARE DESIGN AND SOFTWARE ENGINEERING
Software design sits at the technical kernel of software engineering and is applied regardless of the software process model that is used. Beginning once software requirements have been analyzed and specified, software design is the first of three technical activities-design, code generation, and test-that are required to build and verify the software. Each activity transforms information in a manner that ultimately results in validated computer software. Each of the elements of the analysis model provides information that is necessary to create the four design models required for a complete specification of design.
Software requirements, manifested by the data, functional, and behavioral models, feed the design task. Using one of a number of design methods , the design task produces a data design, an architectural design, an interface design, and a component design.
The data design transforms the information domain model created during analysis into the data structures that will be required to implement the software. The data objects and relationships defined in the entity relationship diagram and the detailed data content depicted in the data dictionary provide the basis for the data design activity.
Part of data design may occur in conjunction with the design of software architecture. More detailed data design occurs as each software component is designed.
The architectural design defines the relationship between major structural elements of the software, the "design patterns" that can be used to achieve the requirements. The system architecture, the inter that have been defined for the system, and the constraints that affect the way in which architectural design patterns can be applied. The architectural design representation the framework of a computer-based system-can be derived from the system specification, the analysis model, and the interaction of subsystems defined within the analysis model.
The interface design describes how the software communicates within itself, with systems that interoperate with it, and with humans who use it. An interface implies a flow of information (e.g., data and/or control) and a specific type of behavior. Therefore, data and control flow diagrams provide much of the information required for interface design.
The component-level design transforms structural elements of the software architecture into a procedural description of software components. Information obtained from the PSPEC, CSPEC, and STD serve as the basis for component design. During design we make decisions that will ultimately affect the success of software construction and, as important, the ease with which software can be maintained.