Software archiecture lecture08

Designing Architecture

IntroductionIntroduction

• We now turn our attention to the design of an • We now turn our attention to the design of an architecture and what you can do as it starts to come into being. This chapter will cover four topics:topics:

▫ Architecture in the life cycle

▫ Designing the architecture▫ Designing the architecture

▫ Forming the team structure and its relationship to the architecturethe architecture

▫ Creating a skeletal system

Architecture in the Life CycleArchitecture in the Life Cycle

• Several Software development life-cycle models • Several Software development life-cycle models exist, but one that puts architecture squarely in the middle of things is the Evolutionary Delivery Life Cycle model Life Cycle model

• The intent of this model is to get user and customer feedback and iterate through several customer feedback and iterate through several releases before the final release.

• The model also allows the adding of • The model also allows the adding of functionality with each iteration and the delivery of a limited version once a sufficient set of of a limited version once a sufficient set of features has been developed.

Evolutionary Delivery Life Cycle modelEvolutionary Delivery Life Cycle model

Architecture in the Life CycleArchitecture in the Life Cycle

• Where can I begin designing?• Clearly, you cannot begin the design until you have • Clearly, you cannot begin the design until you have some idea of the system requirements.▫ On the other hand, it does not take many requirements in order for design to beginorder for design to begin

• An architecture is "shaped" by some collection of functional, quality, and business requirements. We call “architectural drivers”“architectural drivers”• To determine the architectural drivers,▫ identify the highest priority business goals. (not too many)▫ Turn these business goals into quality scenarios or use ▫ Turn these business goals into quality scenarios or use cases.▫ From this list, choose the ones that will have the most impact on the architecture.

• Once the architectural drivers are known, the • Once the architectural drivers are known, the architectural design can begin.

Designing the ArchitectureDesigning the Architecture

• Attribute-Driven Design (ADD)• Attribute-Driven Design (ADD)

▫ a method for designing an architecture to satisfy both quality requirements and functional requirements

• A set of quality attribute scenarios is input for ADD• A set of quality attribute scenarios is input for ADD

• The ADD method can be viewed as an extension to most other development methods, such as the most other development methods, such as the Rational Unified Process

• The Rational Unified Process has several steps that • The Rational Unified Process has several steps that result in the high-level design of an architecture but then proceeds to detailed design and implementationimplementation

Attribute-Driven DesignAttribute-Driven Design

• ADD is an approach to defining a software architecture that bases the decomposition process on the quality attributes. bases the decomposition process on the quality attributes. • It is a recursive decomposition process where tactics and architectural patterns are chosen to satisfy a set of quality scenarios and then functionality is allocated to instantiate the scenarios and then functionality is allocated to instantiate the module types provided by the pattern. • ADD is positioned in the life cycle after requirements analysis.• The output of ADD is the first several levels of a module decomposition view of an architecture and other views as decomposition view of an architecture and other views as appropriate. • The system is described as a set of containers for functionality and the interactions among them. functionality and the interactions among them. • Nevertheless, it is critical for achieving the desired qualities, it provides a framework for achieving the functionality.

ADD StepsADD Steps

• The steps performed when designing an architecture using the ADD method. method. ▫ Choose the module to decompose (usually start with the whole system). All

required inputs for this module should be available▫ Refine the module according to these steps:

� Choose the architectural drivers from the set of concrete quality scenarios and functional requirements. This step determines what is important for this

� Choose the architectural drivers from the set of concrete quality scenarios and functional requirements. This step determines what is important for this decomposition.

� Choose an architectural pattern that satisfies the architectural drivers. Create (or select) the pattern based on the tactics that can be used to achieve the drivers. Identify child modules required to implement the tactics.Instantiate modules and allocate functionality from the use cases and represent Identify child modules required to implement the tactics.

� Instantiate modules and allocate functionality from the use cases and represent using multiple views.

� Define interfaces of the child modules. The decomposition provides modules and constraints on the types of module interactions. Document this information in the interface document for each module.interface document for each module.

� Verify and refine use cases and quality scenarios and make them constraints for the child modules. This step verifies that nothing important was forgotten and prepares the child modules for further decomposition or implementation.

▫ Repeat the steps above for every module that needs further decomposition.

The garage door openerThe garage door opener

• We demonstrate the ADD method by using it to • We demonstrate the ADD method by using it to design a product line architecture for a garage door opener within a home information system.

• The opener is responsible for raising and lowering the door via

▫ a switch ▫ a switch

▫ remote control

▫ the home information system. ▫ the home information system.

• It is also possible to diagnose problems with the opener from within the home information opener from within the home information system.

Sample InputSample Input

• The input to ADD is a set of requirements• System-specific quality scenarios should be defined to the detail • System-specific quality scenarios should be defined to the detail necessary for the application.

• For our garage door example,▫ The device and controls for opening and closing the door are different for the various products in the product line, as already mentioned. They

▫ The device and controls for opening and closing the door are different for the various products in the product line, as already mentioned. They may include controls from within a home information system. The product architecture for a specific set of controls should be directly derivable from the product line architecture.

▫ The processor used in different products will differ. The product ▫ The processor used in different products will differ. The product architecture for each specific processor should be directly derivable from the product line architecture.

▫ If an obstacle (person or object) is detected by the garage door during descent, it must halt (alternately re-open) within 0.1 second.descent, it must halt (alternately re-open) within 0.1 second.

▫ The garage door opener should be accessible for diagnosis and administration from within the home information system using a product-specific diagnosis protocol. It should be possible to directly produce an architecture that reflects this protocol.produce an architecture that reflects this protocol.

1.Choose the module to decompose1.Choose the module to decompose

• The following are all modules: • The following are all modules:

▫ System

▫ Subsystem▫ Subsystem

▫ Submodule

• The decomposition typically starts with the system, which is then decomposed into system, which is then decomposed into subsystems, which are further decomposed into submodulessubmodules

• the garage door opener is the system, we choose to decomposechoose to decompose

2a. Choose the architectural drivers 2a. Choose the architectural drivers

• Architectural drivers are the combination of functional and quality requirements.• Architectural drivers are the combination of functional and quality requirements.• The drivers will be found among the top-priority requirements for the module.The four scenarios we have shown are architectural requirements for the module.• The four scenarios we have shown are architectural drivers▫ real-time performance▫ real-time performance▫ modifiability to support product lines. ▫ online diagnosis be supported. • All of these requirements must be addressed in the initial decomposition of the system.• All of these requirements must be addressed in the initial decomposition of the system.• We do not treat all of the requirements as equal; the less important requirements are satisfied within the less important requirements are satisfied within the constraints of the most important.

2b. Choose an architectural pattern 2b. Choose an architectural pattern

• Each tactic is designed to realize one or more • Each tactic is designed to realize one or more quality attributes

• But the patterns in which they are arranged • But the patterns in which they are arranged have an impact on other quality attributes.

• In an architecture design, a composition of many such tactics is used to achieve a balance many such tactics is used to achieve a balance between the required multiple qualities.

• Achievement of the quality and functional • Achievement of the quality and functional requirements is analyzed during the refinement step.step.


• The goal of this step is to establish an overall architectural pattern consisting of module types• The goal of this step is to establish an overall architectural pattern consisting of module types• Two main factors guide tactic selection. ▫ The drivers The side effects that a pattern implementing a tactic ▫ The drivers ▫ The side effects that a pattern implementing a tactic has on other qualities.

• We see performance and modifiability as the critical quality attributes. • We see performance and modifiability as the critical quality attributes. • We choose these as our tactics:▫ semantic coherence and information hiding ▫ semantic coherence and information hiding

� combine them to define virtual machines for the affected areas

▫ increase computational efficiency▫ choose scheduling policy▫ choose scheduling policy


• Architectural pattern• Architectural pattern

2c. Instantiate modules 2c. Instantiate modules

• Our criterion for allocating functionality is similar to that used in functionality-based design methods, • Our criterion for allocating functionality is similar to that used in functionality-based design methods, such as most object-oriented design methods.• We allocate the responsibility for managing obstacle detection and halting the garage door to the • We allocate the responsibility for managing obstacle detection and halting the garage door to the performance-critical section since this functionality has a deadline• The management of the normal raising and lowering • The management of the normal raising and lowering of the door has no timing deadline, and so we treat it as non-performance-critical section• We also identify several responsibilities of the virtual • We also identify several responsibilities of the virtual machine: communication and sensor reading and actuator control. This yields two instances of the virtual machine that are also shown in Figureactuator control. This yields two instances of the virtual machine that are also shown in Figure

2c. Instantiate modules 2c. Instantiate modules

• The result of this step is a decomposition of a • The result of this step is a decomposition of a module.

• The next steps verify how well the • The next steps verify how well the decomposition achieves the required functionality

2c. Allocate functionality2c. Allocate functionality

• Every use case of the parent module must be • Every use case of the parent module must be representable by a sequence of responsibilities within the child modules.

• Assigning responsibilities to the children in a decomposition also leads to the discovery of necessary information exchange.necessary information exchange.

• At this point only the information itself and the producer and consumer roles are of interest.producer and consumer roles are of interest.

• These steps should be sufficient to gain confidence that the system can deliver the confidence that the system can deliver the desired functionality.

2c. Represent the architecture with 2c. Represent the architecture with

views

• Dynamic and runtime deployment information is • Dynamic and runtime deployment information is also required to analyze the achievement of qualities such as performance, security, and reliability.reliability.

• In our experience with ADD, one view from each of the three major groups of views have been of the three major groups of views have been sufficient to begin with.

▫ Module decomposition view▫ Module decomposition view

▫ Concurrency view

▫ Deployment view.▫ Deployment view.

2c. Module decomposition view2c. Module decomposition view

• Module decomposition view show • Module decomposition view show

▫ Module as containers for holding responsibilities as they are discovered.

▫ Major data flow relationships among the modules are also identified through this view.

2c. Concurrency view2c. Concurrency view

• In the concurrency view dynamic aspects of a • In the concurrency view dynamic aspects of a system such as parallel activities and synchronization can be modeled.

• This modeling helps to identify resource contention problems, possible deadlock situations, data consistency issues, and so forth.situations, data consistency issues, and so forth.

• It can lead to discovery of new modules, such as a resource manager, in order to solve issues of a resource manager, in order to solve issues of concurrent access to a scarce resource and the like.like.


• The concurrency view is one of the component-• The concurrency view is one of the component-and-connector views.

▫ The components are instances of the modules▫

▫ The connectors are the carriers of virtual threads

▫ A "virtual thread" describes an execution path through the system or parts of it.through the system or parts of it.

• The connectors in a concurrency view are those that deal with threads such as "synchronizes that deal with threads such as "synchronizes with," "starts," "cancels," and "communicates with." with."


• To understand the concurrency in a system, the • To understand the concurrency in a system, the following use cases are illuminating:

▫ Two users doing similar things at the same time.▫

▫ One user performing multiple activities simultaneously.

▫ Starting up the system.▫ Starting up the system.

▫ Shutting down the system.

• In our example, we can see a point of • In our example, we can see a point of synchronization in the sensor/actuator virtual machinemachine

2c. Deployment view2c. Deployment view

• Using a deployment view helps to determine • Using a deployment view helps to determine and design a deployment that supports achieving the desired qualities.

• The deployment view also helps in deciding if multiple instances of some modules are needed.

• In our example, deployment issues are found in • In our example, deployment issues are found in the division of responsibilities between the door opener system and the home information opener system and the home information system.

2d. Define interfaces of the child 2d. Define interfaces of the child

modules

• An interface of a module shows the services and • An interface of a module shows the services and properties provided and required.

• It documents what others can use and on what • It documents what others can use and on what they can depend.

• During analyzing views, It uncovers the interaction assumptions for the child modules.interaction assumptions for the child modules.

• The module view documents

▫ producers/consumers of information.▫ producers/consumers of information.

▫ patterns of interaction that require modules to provide services and to use them.provide services and to use them.

2d. Define interfaces of the child 2d. Define interfaces of the child

modules• The concurrency view documents▫ interactions among threads that lead to the interface • The concurrency view documents▫ interactions among threads that lead to the interface of a module providing or using a service.▫ the information that a component is active—for example, has its own thread running.example, has its own thread running.▫ the information that a component synchronizes, sequentializes, and perhaps blocks calls.

• The deployment view documents• The deployment view documents▫ the hardware requirements, such as special-purpose hardware.▫ some timing requirements, such as that the ▫ some timing requirements, such as that the computation speed of a processor has to be at least 10 MIPS.▫ communication requirements, such as that information ▫ communication requirements, such as that information should not be updated more than once every second.

2e.Verify and refine 2e.Verify and refine

• Verify and Refine Use Cases and Quality • Verify and Refine Use Cases and Quality Scenarios as Constraints for the Child Modules

• This decomposition must be verified and the • This decomposition must be verified and the child modules must be prepared for their own decomposition

• Verify and Refine• Verify and Refine

▫ Functional requirements

▫ Constraints▫ Constraints

▫ Quality scenarios

2e Functional Requirment2e Functional Requirment

• Each child module has responsibilities that • Each child module has responsibilities that derive partially from considering decomposition of the functional requirements

• Those responsibilities can be translated into use cases for the module.

• Another way of defining use cases is to split and • Another way of defining use cases is to split and refine the parent use cases

• This approach has traceability because an • This approach has traceability because an analyst can follow the refinement.

2e Functional Requirement2e Functional Requirement

• In our examples, the responsibilities are decomposed into the following functional groups corresponding to the modules.following functional groups corresponding to the modules.▫ User interface. Recognize user requests and translate them into the form expected by the raising/lowering door module.▫ Raising/lowering door module. Control actuators to raise or lower the door. Stop the door when it reaches either fully open or fully ▫ Raising/lowering door module. Control actuators to raise or lower the door. Stop the door when it reaches either fully open or fully closed.▫ Obstacle detection. Recognize when an obstacle is detected and either stop the descent of the door or reverse it.either stop the descent of the door or reverse it.▫ Communication virtual machine. Manage all communication with the home information system.▫ Sensor/actuator virtual machine. Manage all interactions with the sensors and actuators.sensors and actuators.▫ Scheduler. Guarantee that the obstacle detector will meet its deadlines.▫ Diagnosis. Manage the interactions with the home information system devoted to diagnosis.system devoted to diagnosis.

2e Constraints2e Constraints

• Constraints of the parent module can be satisfied in • Constraints of the parent module can be satisfied in one of the following ways:

▫ The decomposition satisfies the constraint.

▫ The constraint is satisfied by a single child module.▫ The constraint is satisfied by a single child module.

▫ The constraint is satisfied by multiple child modules.

• In our example, one constraint is that the • In our example, one constraint is that the communication with the home information system is maintained. The communication virtual machine will recognize if this communication is unavailable, so recognize if this communication is unavailable, so the constraint is satisfied by a single child.

2e Quality Scenarios2e Quality Scenarios

• Quality scenarios also have to be refined and assigned to the child modules• Quality scenarios also have to be refined and assigned to the child modules• A quality scenario may be completely satisfied by the decomposition without any additional impact. It can then be marked as satisfied.the decomposition without any additional impact. It can then be marked as satisfied.• A quality scenario may be satisfied by the current decomposition with constraints on child modules. The decomposition may be neutral with respect to a decomposition with constraints on child modules. • The decomposition may be neutral with respect to a quality scenario• A quality scenario may not be satisfiable with the current decomposition, the rationale for the • A quality scenario may not be satisfiable with the current decomposition, the rationale for the decomposition not supporting this scenario must be recorded. This is usually the result of a tradeoff with other, perhaps higher-priority scenariosrecorded. This is usually the result of a tradeoff with other, perhaps higher-priority scenarios

2e Quality Scenarios2e Quality Scenarios

• In our example• The devices and controls equipments are different for • The devices and controls equipments are different for different products in the product line. This scenario is delegated to the user interface module.• The processor used in different products will differ. This • The processor used in different products will differ. This scenario is delegated to all of the modules. Each module becomes responsible for not using processor-specific.• If an obstacle is detected by the garage door during • If an obstacle is detected by the garage door during descent, the door must halt within 0.1 second. This scenario is delegated to the scheduler and the obstacle detection module.detection module.• The garage door opener should be accessible for diagnosis and administration from within the home information system using a product-specific diagnosis protocol. This scenario is split between the diagnosis information system using a product-specific diagnosis protocol. This scenario is split between the diagnosis and communication modules.

Forming the Team StructureForming the Team Structure

• Once the first few levels of the architecture's module decomposition structure are fairly stable, those modules can decomposition structure are fairly stable, those modules can be allocated to development teams.• The impact of an architecture on the development of organizational structure is clear.organizational structure is clear.▫ Once an architecture for the system under construction has been agreed on, teams are allocated to work on the major modules and a work breakdown structure is created that reflects those teams. teams. ▫ Each team then creates its own internal work practices. For large systems, the teams may belong to different subcontractors. ▫ The work practices may include items such as bulletin boards and Web pages for communication, naming conventions for files, and Web pages for communication, naming conventions for files, and the configuration control system. All of these may be different from group to group. ▫ Furthermore, quality assurance and testing procedures are set up for each group, and each group needs to establish liaisons and for each group, and each group needs to establish liaisons and coordinate with the other groups.

Forming the Team StructureForming the Team Structure

• Within the team there needs to be high-• Within the team there needs to be high-bandwidth communications.

• Between teams, low-bandwidth communications • Between teams, low-bandwidth communications are sufficient.

• This assumes that the system has been designed with appropriate separation of designed with appropriate separation of concerns.

• Team structure and controlling team interactions • Team structure and controlling team interactions often turn out to be important factors affecting a large project's successlarge project's success

Creating a Skeletal SystemCreating a Skeletal System

• Once an architecture is sufficiently designed and • Once an architecture is sufficiently designed and teams are in place to begin building to it, a skeletal system can be constructed.

• Classical software engineering practice recommends "stubbing out" sections of code so that portions of the system can be added that portions of the system can be added separately and tested independently.

▫ However, which portions should be stubbed? ▫ However, which portions should be stubbed?

▫ By using the architecture as a guide, a sequence of implementation becomes clear.of implementation becomes clear.

Creating a Skeletal SystemCreating a Skeletal System

• First, implement the software that deals with the execution and interaction of architectural components. interaction of architectural components. ▫ This may require producing a scheduler in a real-time system▫ implementing the rule engine (with a prototype set of rules) to control rule firing in a rule-based system

▫ implementing process synchronization mechanisms in a multi-process ▫ implementing process synchronization mechanisms in a multi-process system

▫ implementing client-server coordination in a client-server system.

• At this point, you will have a running system that essentially sits there and hums to itself—but a running system nevertheless. This is there and hums to itself—but a running system nevertheless. This is the foundation onto which useful functionality can be added.

• You can now choose which of the elements providing functionality should be added to the system.

The choice may be based on lowering risk by addressing the most should be added to the system. ▫ The choice may be based on lowering risk by addressing the most problematic areas first

▫ it may be based on the levels and type of staffing available▫ it may be based on getting something useful to market as quickly as possible.

▫ it may be based on getting something useful to market as quickly as possible.

SummarySummary

• Architecture design must follow requirements analysis, but it does not need to be deferred until requirements analysis is completed. not need to be deferred until requirements analysis is completed.

• In fact, architecture design can begin once the critical architectural drivers have been determined.

• When a sufficient portion of the architecture has been designed (again, not necessarily completely designed), a skeletal system can

• When a sufficient portion of the architecture has been designed (again, not necessarily completely designed), a skeletal system can be developed. This skeletal system is the framework on which iterative development (with its associated ability to deliver at any point) is performed.

• The quality scenarios and tactics are critical to architecture design.point) is performed.

• The quality scenarios and tactics are critical to architecture design.• ADD is a top-down design process based on using quality requirements to define an appropriate architectural pattern and on using functional requirements to instantiate the module types given using functional requirements to instantiate the module types given by that pattern.

• Architecture determines some level of organizational structure through determining the necessary communication paths.

• Existing organizational structure influences architecture as well by • Existing organizational structure influences architecture as well by providing organizational units with specialized expertise and vested interests.

Education

Software archiecture lecture08