Chapter 6: Architectural design (3705)

Chapter 6: Architectural design (3705)

1. 6.1 Architectural design decisions

   • satisfy the functional and non-functional requirements of a system
   • series of decisions to be made rather than a sequence of activities.
   • most large systems are distributed systems in which the system software is distributed across many different computers. The choice of distribution architecture is a key decision that affects the performance and reliability of the system
   • Architectural pattern is a description of a system organization (Garlan and Shaw 1993), such as a client–server organization or a layered architecture
   • Because of the close relationship between non-functional system characteristics and software architecture, the choice of architectural style and structure should depend on the non-functional requirements of the system:
     • Performance If performance is a critical requirement, the architecture should be designed to localize critical operations within a small number of components, with these components deployed on the same computer rather than distributed across the network.
       • using a few relatively large components rather than small, finer-grain components.
       • large components reduces the number of component communications
       • also consider runtime system organizations that allow the system to be replicated and executed on different processors.
     • Security
       • a layered structure for the architecture should be used, with the most critical assets protected in the innermost layers and a high level of security validation applied to these layers.
     • Safety
       • architecture should be designed so that safety-related operations are co-located in a single component or in a small number of components. This reduces the costs and problems of safety validation and may make it possible to provide related protection systems that can safely shut down the system in the event of failure.
     • Availability
       • the architecture should be designed to include redundant components so that it is possible to replace and update components without stopping the system
     • Maintainability
       • the system architecture should be designed using fine-grain, self-contained components that may readily be changed. Producers of data should be separated from consumers, and shared data structures should be avoided.
   • potential conflict between some of these architectures
     • If both performance and maintainability are important system requirements, however, then some compromise must be found.
     • Evaluating an architectural design is difficult because the true test of an architecture is how well the system meets its functional and non-functional requirements when it is in use.

2. 6.2 Architectural views

   • architectural models of a software system can be used to focus discussion about the software requirements or design.
   • they may be used to document a design so that it can be used as a basis for more detailed design and implementation of the system.
     • two issues that are relevant to both of these:
       • What views or perspectives are useful when designing and documenting a system’s architecture?
       • What notations should be used for describing architectural models?
   • impossible to represent all relevant information about a system’s architecture in a single diagram, as a graphical model can only show one view or perspective of the system
     • different opinions as to what views are required. Krutchen (Krutchen 1995) in his well-known 4+1 view model of software architecture, suggests that there are four fundamental architectural views, which can be linked through common use cases or scenarios
       • logical view
         • shows the key abstractions in the system as objects or object classes. It should be possible to relate the system requirements to entities in this logical view
       • process view
         • shows how, at runtime, the system is composed of interacting processes. This view is useful for making judgments about non-functional system characteristics such as performance and availability.
       • development view
         • shows how the software is decomposed for development; that is, it shows the breakdown of the software into components that are implemented by a single developer or development team. This view is useful for software managers and programmers.
       • physical view
         • shows the system hardware and how software components are distributed across the processors in the system. This view is useful for systems engineers planning a system deployment.
   • UML for describing and documenting software architecture
     • Object orientated and provides more detail, useful when using model driven development (Chapter 5)
   • use of more specialized architectural description languages (ADLs) to describe system architectures.
     • basic elements of ADLs are components and connectors, and they include rules and guidelines for well-formed architectures.
   • Users of agile methods claim that detailed design documentation is mostly unused. It is, therefore, a waste of time and money to develop these documents

3. 6.3 Architectural patterns

   • Architectural patterns were proposed in the 1990s under the name “architectural styles”
   • Figure 6.4 describes the well-known Model-View-Controller pattern. This pattern is the basis of interaction management in many web-based systems and is supported by most language frameworks.
   • Layered architecture
     • The notions of separation and independence are fundamental to architectural design because they allow changes to be localized
     • This pattern is shown in Figure 6.7. Here, the system functionality is organized into separate layers, and each layer only relies on the facilities and services offered by the layer immediately beneath it.
     • This layered approach supports the incremental development of systems.
     • If its interface is unchanged, a new layer with extended functionality can replace an existing layer
     • when layer interfaces change or new facilities are added to a layer, only the adjacent layer is affected. As layered systems localize machine dependencies, this makes it easier to provide multi-platform implementations of an application system.
     • The lowest layer includes system support software—typically, database and operating system support. The next layer is the application layer, which includes the components concerned with the application functionality and utility components used by other application components. The third layer is concerned with user interface management and providing user authentication and authorization, with the top layer providing user interface facilities.
   • Repository architecture
     • The layered architecture and MVC patterns are examples of patterns where the view presented is the conceptual organization of a system.
     • the Repository pattern (Figure 6.10), describes how a set of interacting components can share data.
     • The majority of systems that use large amounts of data are organized around a shared database or repository
     • The Repository pattern is concerned with the static structure of a system and does not show its runtime organization.
   • Client–server architecture
     • Client–Server pattern (Figure 6.12), illustrates a commonly used runtime organization for distributed systems
     • Client–Server pattern is organized as a set of services and associated servers, and clients that access and use the services
     • The major components of this model are:
       • A set of servers that offer services to other components.
         • Servers are software components, and several servers may run on the same computer.
       • A set of clients that call on the services offered by servers.
       • A network that allows the clients to access these services. Client–server systems are usually implemented as distributed systems, connected using Internet protocols.
     • the logical model of independent services running on separate servers can be implemented on a single computer.
       • Services and servers can be changed without affecting other parts of the system.
     • The most important advantage of the client–server model is that it is a distributed architecture. Effective use can be made of networked systems with many distributed processors
   • Pipe and filter architecture
     • This is a model of the runtime organization of a system where functional transformations process their inputs and produce outputs
     • Data flows from one to another and is transformed as it moves through the sequence.
     • The transformations may execute sequentially or in parallel. The data can be processed by each transform item by item or in a single batch.
     • The name “pipe and filter” comes from the original Unix system where it was possible to link processes using “pipes.” These passed a text stream from one process to another.
       • The term filter is used because a transformation “filters out” the data it can process from its input data stream.
       • When transformations are sequential with data processed in batches, this pipe and filter architectural model becomes a batch sequential model, a common architecture for data-processing systems such as billing systems
     • Pipe and filter systems are best suited to batch processing systems and embedded systems where there is limited user interaction.
       • It is difficult to implement this as a sequential stream that conforms to the pipe and filter model.

4. 6.4 Application architectures

   • Application architectures encapsulate the principal characteristics of a class of system
   • As a software designer, you can use models of application architectures in a number of ways:
     • As a starting point for the architectural design process
     • As a design checklist
     • As a way of organizing the work of the development team
     • As a means of assessing components for reuse
     • As a vocabulary for talking about applications
   • superficially dissimilar applications may have much in common and thus share an abstract application architecture
     • Transaction processing application
       • database-centered applications that process user requests for information and update the information in a database.
       • This class of system includes interactive banking systems, e-commerce systems, information systems, and booking systems.
     • Language processing systems
       • Language processing systems are systems in which the user’s intentions are expressed in a formal language, such as a programming language
       • language processing system processes this language into an internal format and then interprets this internal representation.
       • The bestknown language processing systems are compilers
       • language processing systems are also used to interpret command languages for databases and information systems
     • a large number of webbased business systems are transaction processing systems, and all software development relies on language processing systems.
   • Transaction processing systems
     • Transaction processing systems are designed to process user requests for information from a database, or requests to update a database
     • Figure 6.16 illustrates the conceptual architectural structure of transaction processing applications
     • The input and output components are implemented as software in the ATM, and the processing component is part of the bank’s database server
     • Information systems
       • All systems that involve interaction with a shared database can be considered to be transaction-based information systems
       • The layers in this model can map directly onto servers in a distributed Internet-based system.
     • Language processing systems
       • Language processing systems translate one language into an alternative representation of that language
       • Natural language processing systems may translate one natural language to another, for example, French to Norwegian.
       • A lexical analyzer, which takes input language tokens and converts them into an internal form. 2. A symbol table, which holds information about the names of entities (variables, class names, object names, etc.) used in the text that is being translated. 3. A syntax analyzer, which checks the syntax of the language being translated. It uses a defined grammar of the language and builds a syntax tree. 4. A syntax tree, which is an internal structure representing the program being compiled. 5. A semantic analyzer, which uses information from the syntax tree and the symbol table to check the semantic correctness of the input language text. 6. A code generator, which “walks” the syntax tree and generates abstract machine code.
       • Compilers can be implemented using a composite of a repository and a pipe and filter model. In a compiler architecture, the symbol table is a repository for shared data. The phases of lexical, syntactic, and semantic analysis are organized sequentially, as shown in Figure 6.22, and communicate through the shared symbol table.

5. Introduction

   • Architectural design is concerned with understanding how a software system should be organized and designing the overall structure of that system
   • architectural design is the first stage in the software design process
   • critical link between design and requirements engineering, as it identifies the main structural components in a system and the relationships between them
   • The output of the architectural design process is an architectural model that describes how the system is organized as a set of communicating components.
   • In agile processes, it is generally accepted that an early stage of an agile development process should focus on designing an overall system architecture. Incremental development of architectures is not usually successful
     • Changing components is easy, but changing architecture is cost;y and difficult down the line
   • There is a significant overlap between the processes of requirements engineering and architectural design
   • You need to identify the main architectural components as these reflect the high-level features of the system.
   • You can design software architectures at two levels of abstraction, which I call architecture in the small and architecture in the large:
     • Architecture in the small is concerned with the architecture of individual programs. At this level, we are concerned with the way that an individual program is decomposed into components.
     • Architecture in the large is concerned with the architecture of complex enterprise systems that include other systems, programs, and program components.
   • Software architecture affects the performance, robustness, distributability, and maintainability of a system
   • explicitly designing and documenting software architecture has three advantages:
     • Stakeholder communication
     • System analysis
     • Large-scale reuse
   • System architectures are often modeled informally using simple block diagrams, as in Figure 6.1.
   • contradictions between architectural theory and industrial practice arise because there are two ways in which an architectural model of a program is used:
     • As a way of encouraging discussions about the system design
     • As a way of documenting an architecture that has been designed The aim here is to produce a complete system model that shows the different components in a system, their interfaces and their connections
   • developing a detailed architectural description is an expensive and time-consuming process and is not widely used

Images and files in the map