Software Architecture

Software Architecture School of Computer Science & Engineering • School of Software, UESTC Jianchuan Xing E-mail：xingjianchuan@sina.com Software Architecture

Chapter 5 Module Architecture View Software Architecture

Outline • 5.1 Design Activities for the Module Architecture View • 5.2 Design of Module Architecture View for IS2000 • 5.3 Summary of Module Architecture View Software Architecture

5.1 Design Activities for the Module Architecture View • Figure 5.1 shows the design tasks for the module architecture view, and how they interact with other design tasks. Like the conceptual view, the module view has three basic phases: global analysis, central design tasks, and interface design. • The middle phase consists of three tightly coupled design tasks: modules, layers, and global evaluation. Software Architecture

5.1 Design Activities for the Module Architecture View (Cont.) • This central phase uses the issue cards from global analysis, and components, connectors, and configuration from the conceptual view as input. The results of this phase – the modules, subsystems, and layers – are used during interface design, and by the central design tasks of the execution and code architecture view. • During the central design phase you may identify new factors, issues, or strategies, causing you to revisit the global analysis task. You may also discover constraints about the modules or layers that cause you make changes to the conceptual view. Software Architecture

5.1 Design Activities for the Module Architecture View (Cont.) • After the central design phase, you may also get feedback from the interface design task, or from the execution or code architecture views, causing you to adjust the modules or layers. Software Architecture

5.1 Design Activities for the Module Architecture View (Cont.) Figure 5.1. Design tasks of the module architecture view Software Architecture

5.1.1 Global Analysis • The first design task for the module view is global analysis. You have done much of the global analysis already, during the design of the conceptual view. When designing the module view, you may identify new factors or may create new issues and strategies, and the analysis of these follows the same approach described in Chapter 3, Global Analysis. • Before starting the central design tasks you should identify the strategies you expect to be relevant for the module view. Although you should check all the factors, certain categories are more likely to be relevant to this view. Software Architecture

5.1.1 Global Analysis (Cont.) • Once you’ve identified the relevant factors, you then determine which strategies are influenced by them. Look for strategies related to modifiability, portability, and reuse. Use these strategies to guide the decisions for the module view. Also look for strategies related to properties like performance, dependability, and failure detection, reporting, recovery to make sure your module view design supports them. Software Architecture

5.1.2 Central Design Tasks • For the central design tasks you map conceptual elements to subsystems and modules, create layers, and assign modules to layers. You also determine the interfaces of the modules and layers. Guiding these decisions are the strategies form global analysis, experience with prior products, and general software engineering knowledge. • Modules • Layers • Global Evaluation Software Architecture

5.1.2 Central Design Tasks (Cont.) • Modules • To design the modules you map the elements from the conceptual view to subsystems and modules. A subsystem usually corresponds to a higher level conceptual component (one that is decomposed into other components and connectors). It can contain other subsystems or modules. Software Architecture

5.1.2 Central Design Tasks (Cont.) • Layers • Layers organize the modules into a partially ordered hierarchy. When a module is assigned to a layer, it can use any of the other modules in that layer. But whenever a module usage crosses a later boundary, the interface required and provided by the modules must also be required and provided by the layers. Thus layers are used to constrain the module “use” relations. Software Architecture

5.1.2 Central Design Tasks (Cont.) • Figure 5.2. Meta-model for subsystems and modules Software Architecture

5.1.2 Central Design Tasks (Cont.) • Figure 5.3. Meta-model for layers Software Architecture

5.1.2 Central Design Tasks (Cont.) • Global Evaluation • To define the modules and layers, you get guidance from multiple sources: your conceptual view design, the strategies from global analysis, your experience with software architectures, and your general knowledge of architecture and software engineering. An important part of global evaluation is deciding which source of information to use at which time. • Global evaluation also means being on the lookout for feedback to the tasks and decisions you made earlier in the design. You should look for additional factors, issues, and strategies that feed back to global analysis task. You need to evaluate whether any of your decisions about modules and layers warrant a change to the design of the conceptual view. Software Architecture

5.1.2 Central Design Tasks (Cont.) • The third aspect of global evaluation is evaluating your module view decisions with respect to each other. You should expect to adjust the modules and subsystems based on your decisions about the layers, and vice versa. You will have to define new interfaces or revise them to satisfy the “require” and “provide” relations of both modules and layers. Software Architecture

5.1.3 Final Design Task: Interface Design • The final phase of module view design is to describe the interfaces for each of the modules and layers identified during the central design phase. This is done after the other tasks are complete. Here you do the detailed design of interfaces required or provided by modules or layers based on their use-dependencies. For this task you may decide to create new interfaces or to split or combine some. These decisions feed back to the central design tasks, and you may need to revise your modules or layers as a result. Software Architecture

5.2 Design of Module Architecture View for IS2000 • Now that we have introduced the tasks for the module view design, let’s look at how these are applied to the example system. Software Architecture

5.2.1 Global Analysis • We expect the following strategies to be applicable to the module view: • Issue: Aggressive Schedule • Strategy: Reuse existing components. • Issue: Skill Deficiencies • Strategy: Encapsulate multiprocess support facilities. • Issue: Changes in General-Purpose and Domain-Specific Hardware • Strategy1: Encapsulate domain-specific hardware. • Strategy 2: Encapsulate general-purpose hardware. Software Architecture

5.2.1 Global Analysis (Cont.) • Issue: Changes in Software Technology • Strategy 1: Use standards. • Strategy 2: Develop product-specific interfaces to external components. • Issue: Real-Time Acquisition Performance • Strategy: Separate time-critical from nontime-critical components. • Issue: Implementation of Diagnostics • Strategy 1: Reduce the effort for error handling • Strategy 2: Encapsulate diagnostics components. Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering • Initial Definition of Layers • The GUI layer implements the graphical user interface for applications. Architecturally, a separate GUI layer is desirable for four reasons: • Design of GUI components is distinctly different from design of components with a programmatic application programming interface (API). • A separate GUI layer helps to promote a single, unified user interface design and reusable widgets for implementation. • Procedural and GUI components are enabled to be reused in other contexts. • Separation and decoupling of procedural and data components from GUI components reduces reworking resulting from changes to GUIs. Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering (Cont.) • Figure 5.4. Initial creation of layers based on conceptual components. GUI=graphical user interface. Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering (Cont.) • Defining Modules for Image Processing • As defined in the conceptual view, image processing consists of a packetizer for collecting the raw data and one or more image pipelines that process the packets into images. • An image pipeline is composed of a sequence of stages: The “packetized” data is input to the first stage, and each stage’s output is input to the next stage. The output of the final stage is framed images. • For defining modules, let’s start by assigning each component to a single module. In general we want to separate as much of the communication infrastructure as feasible into connector- and port-specific modules. Then the modules implementing a conceptual component are insulated from changes to the software platform. Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering (Cont.) • Figure 5.5. Conceptual configuration for ImageProcessing (from the conceptual view) Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering (Cont.) • Table 5.1. Mapping Conceptual Elements to Module Elements: ImageProcessing Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering (Cont.) • Table 5.2. Mapping Conceptual Elements to Module Elements: ImagePipeline Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering (Cont.) • Identifying decomposition dependencies. If a conceptual component is decomposed into lower components, there is a dependency from the corresponding parent module or subsystem to the child module or subsystem. • Identifying use-dependencies. If a conceptual component provides a service to another component, there is a dependency from the user to the provider of the service. Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering (Cont.) Figure 5.6. Initial containment relationships in imaging subsystem Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering (Cont.) Figure 5.7. Alternative notations for requiring and providing an interface Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering (Cont.) Figure 5.8. Imaging subsystem use-dependencies Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering (Cont.) • Reviewing the ImageProcessing Layer • We need to assign the image-processing module to the ImageProcessing layer. • Next let’s take the modules corresponding to acquisition management and put them in the Application layer. • The acquisition manager client (MClient) accesses the MPipeline module through the IAcqControl interface. Therefore we can use it as interface to the ImageProcessing layer as well. • For the probe services, let’s apply the strategy Reuse existing components, and incorporate the existing modules MProbeControl and MDataCollect into our design. Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering (Cont.) Figure 5.9. Assigning modules to layers Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering (Cont.) Figure 5.10. Use-dependencies between layers Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering (Cont.) • Adding Supporting Layers • In addition to mapping conceptual components, connectors, and ports to modules and organizing them into layers, an architect often needs to provide supporting layers. • What is needed depends on the services the software platform provides. Software Architecture

5.2.2 Central Design Tasks: Modularization and Layering (Cont.) • Table 5.3. Factors Added During Module View Design Software Architecture

5.2.3 Final Design Task: Interface Design Figure 5.11. Final version of layers and their use-dependencies Software Architecture

5.2.3 Final Design Task: Interface Design (Cont.) Figure 5.12. Interface definition for IAcqControl Software Architecture

5.2.3 Final Design Task: Interface Design (Cont.) Table 5.4. Sample Module Summary Table Software Architecture

5.2.4 Design Summary for IS2000 Module View Table 5.5. Sequence of Design Decisions for IS2000 Module View Software Architecture

5.2.4 Design Summary for IS2000 Module View (Cont.) Table 5.5. Sequence of Design Decisions for IS2000 Module View (cont.) Software Architecture

5.3 Summary of Module Architecture View • Table 5.6. Summary of Module Architecture View Software Architecture

5.3 Summary of Module Architecture View (Cont.) • Table 5.6. Summary of Module Architecture View (Cont.) Software Architecture

5.3 Summary of Module Architecture View (Cont.) Figure 5.13. Meta-model of the module architecture view Software Architecture

5.3.1 Traceability • The following three items should be traceable in the module view: • Critical requirements. • Organizational and technological factors. • Elements in the conceptual view. Software Architecture

Software Architecture