1. 1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University

2. Outline 1. Architecture in the Life Cycle 2. Designing the Architecture 3. Forming the Team Structure 4. Creating a Skeletal System 5. Summary 2

3. Designing the Architecture Lecture: 6-7 3

4. 1. Architecture in Life Cycle We need to understand architecture’s place in the software development life cycle The Evolutionary Delivery Life Cycle model puts architecture squarely in the middle of things The intent of this model is to get user and customer feedback and iterate through several releases before the final release The model also allows the adding of functionality with each iteration  delivery of a limited version of software once a sufficient set of features has been developed 4

5. Architecture in Life Cycle (Continue…) What is SDLC? What is this diagram about? In which part we are interested? When should the design of an architecture begin? What are architectural drivers and how we can determine them? 5

6. Architecture in Life Cycle (Continue…) When should the design of an architecture begin?  The design of the architecture iterates with preliminary requirements analysis We cannot begin the design until you have some idea of the system requirements & It does not take many requirements in order for design to begin  An architecture is "shaped" by some collection of functional, quality, and business requirements  We call these shaping requirements architectural drivers The architecture of the A-7E discussed in Chapter 3 is shaped by its modifiability and performance requirements 6

7. Architecture in Life Cycle (Continue…) How to determine Architectural Drivers?  First of all identify the highest priority business goals  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 These are the architectural drivers, there should be fewer than ten  Once the architectural drivers are known, the architectural design can begin The requirements analysis process will then be influenced by the questions generated during architectural design 7

8. 2. Designing the Architecture There exists many design methods for Software Architecture  Attribute-Driven Design (ADD)  Architecture-Centric Design Method (ACDM) etc. ADD takes set of quality attribute scenarios as input  Employs knowledge about the relation between quality attribute achievement and architecture The ADD method can be viewed as an extension to most other development methods, like RUP  Incorporating ADD into RUP involves modifying the steps dealing with the high-level design of the architecture 8

9. Attribute Driven Design In ADD the decomposition process is based on the quality attributes the software has to fulfill ADD performs a recursive decomposition process  At each stage, tactics and architectural patterns are chosen to satisfy a set of quality scenarios &  Functionality is allocated to instantiate the module types provided by the pattern The output of ADD includes  The first several levels of a module decomposition view of an architecture and some other views as appropriate  The system is described as a set of containers for functionality and the interactions among them 9

10. Attribute Driven Design (Continue…) Sample Input  The input to ADD is a set of requirements  ADD assumes functional requirements (typically expressed as use cases) and constraints as input  ADD differs from other methods due to its treatment with quality requirements  ADD mandates that quality requirements be expressed as a set of system-specific quality scenarios  System-specific scenarios should be defined to the detail necessary for the application 10

11. Attribute Driven Design (Continue…) ADD Steps 1. Choose the module to decompose. The module to start with is usually the whole system. All required inputs for this module should be available (constraints, functional requirements, quality requirements) 2. Refine the module according to these steps: a. Choose the architectural drivers from the set of concrete quality scenarios and functional requirements. This step determines what is important for this decomposition b. 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 11

12. Attribute Driven Design (Continue…) ADD Steps (Continue…) c. Instantiate modules and allocate functionality from the use cases and represent using multiple views d. 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 e. 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 3. Repeat the steps above for every module that needs further decomposition 12

13. Attribute Driven Design (Continue…) Case Study  We need to design a product line architecture for a garage door opener within a home information system using ADD. Functional Requirements  The opener is responsible for raising and lowering the door via a switch, remote control, or the home information system.  It is also possible to diagnose problems with the opener from within the home information system. 13

14. Attribute Driven Design (Continue…) Quality Requirements / Drivers  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 architecture for each specific processor should be directly derivable from the product line architecture. 14

15. Attribute Driven Design (Continue…) Quality Requirements / Drivers (Continue…)  If an obstacle (person or object) is detected by the garage door during 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. 15

16. Attribute Driven Design (Continue…) ADD Steps in Detail 1.Choose the Module to Decompose The following are all modules:  system, subsystem, and sub-module The decomposition typically starts with the system, which is then decomposed into subsystems, which are further decomposed into sub-modules  In our example, the garage door opener is the system. One constraint at this level is that the opener must interoperate with the home information system. 16

17. Attribute Driven Design (Continue…) ADD Steps in Detail (Continue…) 2.a.Choose the Architectural Drivers Architectural drivers are the combination of functional and quality requirements  The drivers will be found among the top-priority requirements for the module The determination of architectural drivers is not always a top-down process  Sometimes detailed investigation is required to understand the ramifications of particular requirements  In our example, determining that the performance requirement is an architectural driver requires examining the mechanics of a garage door and the speed of the potential processors The decomposition of a module is based on the architectural drivers 17

18. Attribute Driven Design (Continue…) ADD Steps in Detail (Continue…) 2.a.Choose the Architectural Drivers (Continue…) Other requirements apply to that module, but, by choosing the drivers, we are reducing the problem to satisfying the most important ones All of the requirements are not treated as equal; the less important requirements are satisfied within the constraints of the most important This is a significant difference between ADD and other architecture design methods 18

19. Attribute Driven Design (Continue…) ADD Steps in Detail (Continue…) 2.b.Choose an Architectural Pattern Each tactic is designed to realize one or more quality attributes  Patterns in which tactics are embedded have an impact on other quality attributes Achievement of the quality and functional requirements is analyzed during the refinement step Our goal is to establish an overall architectural pattern consisting of module types The pattern satisfies the architectural drivers and is constructed by composing selected tactics Two main factors guide tactic selection;  The first is the drivers themselves  The second is the side effects that a pattern implementing a tactic has on other qualities 19

20. Attribute Driven Design (Continue…) ADD Steps in Detail (Continue…) 2.b.Choose an Architectural Pattern (Continue…) By examining architectural drivers, we see performance and modifiability as the critical quality attributes.  Semantic Coherence and Information Hiding  increase Computational efficiency and Scheduling Policy Semantic coherence and information hiding  Separate modules with responsibilities user interface, communication, sensors, diagnosis Increase computational efficiency  The performance-critical computations should be made as efficient as possible. Schedule wisely  The performance-critical computations should be scheduled to ensure the achievement of the timing deadline 20

21. Attribute Driven Design (Continue…) ADD Steps in Detail (Continue…) 2.b.Choose an Architectural Pattern (Continue…) 21

22. Attribute Driven Design (Continue…) ADD Steps in Detail (Continue…) 2.c.Instantiate Modules and Allocate Functionality Using Multiple Views In earlier step we defined module types of the decomposition and now we will instantiate those module In a concrete system we normally have more than one module There will be one for each "group" of functionality  These will be instances of the types shown in the pattern. The responsibility for managing obstacle detection and halting the garage door is allocated to the performance-critical section The non-performance-critical module becomes instantiated as diagnosis and raising/lowering door modules Responsibilities of the virtual machine include communication and sensor reading and actuator control 22

23. Attribute Driven Design (Continue…) ADD Steps in Detail (Continue…) 2.c.Instantiate Modules and Allocate Functionality Using Multiple Views (Continue…) 23

24. Attribute Driven Design (Continue…) ADD Steps in Detail (Continue…) 2.c.Instantiate Modules and Allocate Functionality Using Multiple Views (Continue…) Use cases related to the parent module helps the architect gain a more detailed understanding of the distribution of functionality This also may lead to adding or removing child modules to fulfill all the functionality required Every use case of the parent module must be represent-able 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 These steps help gaining confidence that the system can deliver the desired functionality but to check if the required qualities can be met, we need more than just the responsibilities so far allocated 24

25. Attribute Driven Design (Continue…) ADD Steps in Detail (Continue…) 2.c.Instantiate Modules and Allocate Functionality Using Multiple Views (Continue…) In ADD, one view from each of the three major groups of views should be sufficient to begin with The method itself does not depend on the particular views chosen Module Decomposition View:  The module decomposition view provides containers for holding responsibilities and major data flow relationships among the modules are also identified through this view Concurrency View:  Modeling concurrency can lead to the discovery of new responsibilities as well as of the discovery of new modules, such as a resource manager, in order to solve issues of concurrent access to a scarce resource and the like 25

26. Attribute Driven Design (Continue…) ADD Steps in Detail (Continue…) 2.c.Instantiate Modules and Allocate Functionality Using Multiple Views (Continue…) Deployment View:  If multiple processors or specialized hardware is used in a system, additional responsibilities may arise from deployment to the hardware  The deployment view also helps in deciding if multiple instances of some modules are needed  A reliability requirement may force us to duplicate critical functionality on different processors 26

27. Attribute Driven Design (Continue…) ADD Steps in Detail (Continue…) 2.d.Define Interfaces of the Child Modules An interface of a module shows the services and properties provided and required.  This is different from a signature. It documents what others (modules, components, resources) can use and on what they can depend. Analyzing and documenting the decomposition in terms of structure, dynamism, and runtime uncovers the interaction assumptions for the child modules, which should be documented in their interfaces  producers/consumers of information  the information that a component synchronizes, sequentializes, and perhaps blocks calls  communication requirements, such as that information should not be updated more than once every second 27

28. Attribute Driven Design (Continue…) ADD Steps in Detail (Continue…) 2.e.Verify and Refine Use Cases and Quality Scenarios as Constraints for the Child Modules The decomposition performed so far must be verified and the child modules must be prepared for their own decomposition Functional Requirements  Each child module has responsibilities that are derived from decomposition of the functional requirements  In our example, the initial responsibilities can be verified against the modules;  User interface: Recognize user requests  Raising/lowering door module: Control actuators to raise or lower the door  Obstacle detection: Recognize when an obstacle is detected  Communication Virtual Machine: Manage all communication with the home information system 28

29. Attribute Driven Design (Continue…) ADD Steps in Detail (Continue…) 2.e.Verify and Refine Use Cases and Quality Scenarios as Constraints for the Child Modules (Continue…) Constraints  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 multiple child modules  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 the constraint is satisfied by a single child 29

30. Attribute Driven Design (Continue…) ADD Steps in Detail (Continue…) 2.e.Verify and Refine Use Cases and Quality Scenarios as Constraints for the Child Modules (Continue…) Quality Scenarios  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  A quality scenario may be satisfied by the current 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  If an obstacle (person or object) is detected by the garage door during descent, the door must halt (alternately re-open) within 0.1 second  This scenario is delegated to the scheduler and the obstacle detection module. 30

31. 3. Forming the Team Structure Once the first few levels of the architecture's module decomposition structure are fairly stable, those modules can be allocated to development teams The result is the Work Assignment View (Recall Lecture# 2). This view will either allocate modules to existing development units or define new ones Within a team sub-modules of a large module may be allocated to subcontractors 31

32. 4. Creating a Skeletal System Once architecture is sufficiently designed & teams are allocated, a skeletal system can be constructed The idea at this stage is to to implement a system's functionality in an order advantageous to the project Classical software engineering practice recommends "stubbing out" sections of code  portions of the system can be added separately and tested independently By using the architecture as a guide, a sequence of implementation becomes clear 32

33. 33 Summary Any Questions?