Architecture design represents the structure of data and program components that are required to build a computer-based system. It considers the architectural style that the system will take, the structure and properties of the interrelationships that occur among all architectural components of a system. Architectural design begins with data design and then proceeds to the derivation of one or more representations of the architectural structure of the system. Alternative architectural styles or patterns are analyzed to derive the structure that is best suited to customer requirements and quality attributes. Once an alternative has been selected, the architecture is elaborated using an architectural design method.
Definition: Software architecture provides a holistic view of the system to be built. It depicts the structure and organization of software components, their properties, and the connections between them. Software components include program modules and the various data representations that are manipulated by the program. Therefore, data design is an integral part of the derivation of the software architecture. Architecture highlights early design decisions and provides a mechanism for considering the benefits of alternative system structures.
1. Software Architecture
1.1 What is architecture?
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.
The 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 can be as simple as a procedure call from one module to another or as complex as a database access protocol.
1.2. Why Is Architecture Important?
ü Representations of software architecture are an enabler for communication between all parties 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 style 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.
2. Data Design
Data design creates a model of data and/or information that is represented at a high level of abstraction. This data model is then refined into progressively more implementation-specific representations that can be processed by the computer-based system. The structure of data has always been an important part of software design. The design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications.
2.1 Data Modeling, Data Structures, Databases, and the Data Warehouse
The data objects defined during software requirements analysis are modeled using entity/relationship diagrams and the data dictionary. The data design activity translates these elements of the requirements model into data structures at the software component level and, when necessary, a database architecture at the application level.
Data mining technique also called as Knowledge discover in databases that navigates through existing databases in an attempt to extract appropriate business-level information.
A data warehouse is a separate data environment that is not directly integrated with day-to-day applications but encompasses all data used by a business. A data warehouse is a large, independent database that encompasses some, but not all, of the data that are stored in databases that serve the set of applications required by a business.
2.2 Data Design at the Component Level
Data design at the component level focuses on the representation of data structures that are directly accessed by one or more software components. The design of data begins during the creation of the analysis model. Recalling that requirements analysis and design often overlap, we consider following set of principles for data specification:
ü The systematic analysis principles applied to function and behavior should also be applied to data.
ü All data structures and the operations to be performed on each should be identified.
ü A data dictionary should be established and used to define both data and program design.
ü Low-level data design decisions should be deferred until late in the design process.
ü The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure.
ü A library of useful data structures and the operations that may be applied to them should be developed.
ü A software design and programming languages should support the specification and realization of abstract data types.
3. Architectural Styles
The software that is built for computer-based systems also exhibits one of many architectural styles. Each style describes a system category that encompasses
(1) a set of components that perform a function required by a system;
(2) a set of connections that enable “communication, coordination and cooperation” among components;
(3) constraints that define how components can be integrated to form the system; and
(4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.
3.1 A Brief Taxonomy of Styles and Patterns
Data-centered architectures: A data store resides at the center of this architecture and is accessed frequently by other components that update, add, delete, or otherwise modify data within the store. Data-centered architectures promote integrability i.e. existing components can be changed and new client components can be added to the architecture without concern about other clients.
Data-flow architectures: This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data. A pipe and filter pattern has a set of components, called filters, connected by pipes that transmit data from one component to the next. Each filter works independently of those components upstream and downstream, is designed to expect data input of a certain form, and produces data output of a specified form.
Call and return architectures: This architectural style enabled a software designer to achieve a program structure that is relatively easy to modify and scale.
Object-oriented architectures: The components of a system encapsulate data and the operations that must be applied to manipulate the data. Communication and coordination between components is accomplished via message passing.
Layered architectures: The basic structure of layered architectures is “A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set.
These architectural styles are only a small subset of those available to the software designer. Once requirements engineering uncovers the characteristics and constraints of the system to be built, the architectural pattern or combination of patterns that best fits those characteristics and constraints can be chosen.
4. Analyzing Alternative Architectural Design
4.1 An Architecture Trade-off Analysis Method
An architecture trade-off analysis method establishes an iterative evaluation process for software architectures. The design analysis activities that follow are preformed iteratively:
ü Collect Scenario. A set of use-case is developed to represent the system from the user’s point of view.
ü Elicit requirements, constraint, and environment description. The information is required as part of requirements engineering and is used to be certain that all customer, user, and stakeholder concerns have been addressed.
ü Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements.
o Module view for analysis of work assignments with components and the degree to which information hiding has been achieved.
o Process view for analysis of system performance.
o Data flow view for analysis of the degree to which the architecture meets functional requirements.
ü Evaluate quality attributes by considering each attribute in isolation.
ü Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style.
ü Critique candidate architectures using the sensitivity analysis.
4.2 Quantitative Guidance for Architectural Design
Once an architecture has been derived, it is elaborated and the analyzed against quality criteria.
One of the many problems faced by software engineer during the design process is a general lack of quantitative methods for assessing quality of proposed designs. Work in the area of quantitative analysis of architectural design is still in its formative stages. Asada and his colleagues suggest a number of pseudo quantitative techniques that can be used to complement the ATAM approach as a method for the analysis of architectural design quality.
Asada proposes a number of simple models that assists a designer in determining the degree to which a particular architecture meets predefined “goodness” criteria.
The first model, called spectrum analysis, assesses an architectural design on a “goodness” spectrum from the best to worst possible designs. Once the software architecture has been proposed, it is assessed by assessing by a “score” to each of its design dimensions.
Design selection analysis is another model that requires a set of design dimensions to be defined. The proposed architecture is then assessed to determine the number of design dimensions that it achieve when compared to an ideal system.
Contribution analysis “identified the reasons that one set of design choices gets a lower score than another”. Recalling our discussion of quality function deployment value analysis is conducted to determine the relative priority of requirements determine during function deployment.
5. Mapping Requirements into a Software Architecture
Structured design is often characterized as a data flow-oriented design method because it provides a convenient transition from a data flow diagram to software architecture. The transition as part of six-step process:
(1) the type of information flow is established;
(2) flow boundaries are indicated;
(3) the DFD is mapped into program structure;
(4) control hierarchy is defined;
(5) resultant structure is refined using design measuring and heuristics; and
(6) the architectural description is refined and elaborated.
5.1 Transform Flow
Recall the fundamental system model information must enter and exit software in an “external world” form. Information enters the system along paths that transform external data into an internal form. These paths are identified as incoming flow. At the kernel of the software, a transition occurs. Incoming data are passed through a transform center and begin to move along paths that now lead “out” of the software. Data moving along these paths are called outgoing flow.
5.2 Transaction Flow
The fundamental system model implies transform flow. It is possible to characterize all data flow in this category. Information is often characterized by a single data item called a transaction that triggers other data flow along one of many paths. Transaction flow is characterized by data moving along an incoming path that converts external world information into a transaction. The transaction is evaluated is evaluated and, based on its value, flow along one of many action paths in initiated.
Architectural design encompasses the initial set of design activities that lead to a complete design model of the software.