Software Architecture in Practice

1. Software Architecture in Practice Part Two: Creating an Architecture 2nd Ed. Len Bass, Paul Clements, Rick Kazman

2. Chapter 7:Designing the Architecture • Architecture in the life cycle • Designing the architecture • Forming the team structure & its relationship to the architecture • Creating a skeletal system

3. Evolutionary Delivery Life Cycle Figure 7.1

4. Architectural Drivers • Shaping requirements: functional, quality, & business requirements • Find them by: • Identify the highest priority business goals (relatively few). • Turn these into quality scenarios or use cases. • Choose the ones that will have the most impact on the architecture. • These are the architectural drivers & should be < 10.

5. Attribute Driven Design • An extension of other methods. • Bases the decomposition process on the quality attributes. • Recursive decomposition: • tactics & architectural patterns are chosen to satisfy a set of quality scenarios • functionality is allocated to instantiate the module types • results in course-grained architecture

6. ADD Steps • Identify an initial set of architectural drivers • Choose the module to decompose (initially the entire system) • Refine the module: • Choose the specific architectural drivers • Choose an architectural pattern that satisfies the drivers, based on the appropriate tactics. Identify child modules to implement the tactics. • Instantiate modules & allocate functionality: draw multiple views.

7. ADD Steps, con’t • Define interfaces of the child modules. The decomposition provides modules & constraints on the types of module interactions. Document. • Verify & refine use cases & quality scenarios and make them constraints for the child modules. Verification & preparation for more decomposition or implementation. • Repeat C for every module that needs further decomposition.

8. Creating a Skeletal System • Provide an underlying capability to implement a system’s functionality in an effective order: • Implement execution & interaction. • Install the simplest of functions that instigates some rote behavior. • Result: a running system that sits & hums to itself. • Choose functionality: most problematic; available staff; initial deliverable. • Employ the uses structure to identify additional software to support chosen functionality.

9. Skeleton, con’t • Benefits: • At no point is the integration & test overwhelming; easy to find incremental source of errors. • Budgets & schedules are more predictable with smaller increments, providing management & marketing with more delivery options. • Stubs adhere to the final version of interfaces: • help with understanding & testing interactions • producing hardcoded canned output or reading in output • can generate synthetic load that aids early understanding of performance, including interactions & bottlenecks.

10. Skeleton, con’t • Potential problem: • The first development team to complete a portion of the system gets to define the interfaces for everyone. • This might be too simple, and penalize the complex parts of the system. • The effect would be to make they complex subsystems more complex. • So, first negotiate the interfaces.

11. In Summary • Architectural design must follow requirements analysis, but should begin as soon as the architectural drivers are determined. • When a sufficient portion of the architecture has been designed (but not completed), start building a skeletal framework that is the basis of iterative development.

12. Chapter 8:Flight Simulation • Among the most sophisticated software systems: • Highly distributed • Hard real-time performance requirements • Modifiability: changes in requirements, simulated vehicles & environment • Scalability: continuous improvement of the simulation of the real world

13. Integrability • A driving concern in large systems • Those developed by distributed teams or separate organizations • Definition: the ease with which separately developed elements, including COTS, can be made to work together to fulfill the system’s requirements.

14. Applicable Tactics • Keep interfaces small, simple, and stable. • Adhere to defined protocols. • Loose coupling or minimal dependencies between elements. • Use a component framework. • Use “versioned” interfaces that allow extensions while permitting existing elements to work under the original constraints.

15. Pattern: a Structural Model • With the emphasis on: • Simplicity and similarity of system’s substructures • Decoupling of data- and control-passing strategies from computation • Minimizing module types • A small number of system-wide coordination strategies • Transparency of design

16. Details, p. 181 • The pattern includes an object-oriented design to model the subsystems and controller children of the air vehicle. It marries real-time scheduling to this OOD as a mean of controlling the execution order of the simulation’s subsystems so that fidelity can be guaranteed.

17. Highlights • Architectural solution: • reference model Fig 8.3 • Treatment of time: • Periodic Time Management (for real-time) • Event-based Time Management (non-RT) • Skeletal System: Architecture Prototype • Flight Simulator has 6 module types! • What are the benefits?

18. Integrability • Both the data connections and the control connections have been minimized. • Integrating another controller has been reduced to a problem that is linear, not exponential. • Integrating two subsystems is again reduced to ensuring that the two pass data consistently.

19. Cost/Benefit Ratio • The cost is that the subsystem controllers often act purely as data conduits, increasing complexity and performanceoverhead. • In practice (for applicable) systems, the benefits far outweigh the cost: • Architectural skeleton allows incremental development and easier integration. • Every project that has used structural modeling has reported easy, smooth integration.

20. Chapter 10:Reconstructing Software Architectures • What if you have software that has no architecture documentation? • Never recorded • Recorded but lost • Evolution didn’t include updating the documentation • Finding the architecture hidden in an existing system • Detailed analysis with tool support • Hard, messy, and not always possible

21. Reconstruction Process • Interpretive, interactive, and iterative, involving many activities; it is not automatic! • Needs skills of a reverse engineering expert and the system’s expert • Reconstruct from implementation elements • Complier construction techniques & tools: grep, sed, awk, perl, python, and lex/yacc, etc.

22. Actual Projects • MRI scanners • Public telephone switches • Helicopter guidance systems • Classified NASA systems • Physics simulation systems • Embedded control software for mining machinery • Satellite ground systems • A variety of automotive software

23. Workbench Approach • No single tool or tool set is adequate • Tools tend to be language specific • EX: MRI scanner can have software in 15 languages • Data extraction tools are imperfect • Incomplete results or false positives • Use tools to augment and check on each other

24. Reconstruction Activities • Iteratively, do: • Information extraction - from various sources. • Database construction - into standard form. • View fusion – combine into coherent view. • Reconstruction – main work of building abstractions and representations.

25. Information Flow among Activities Figure 10.1

26. Information Extraction • Analyzing existing design and implementation artifacts to construct a model • Blend of the ideal with the practical • Ideal – what you want to discover • Practical – what available tools can give you • Static - looking at system artifacts • Dynamic – looking at runtime behavior • Multi-process and multi-processor systems with middleware such as J2EE, Jini, or .NET, frequently build topology dynamically, depending on availability of system resources

27. Remaining Steps • Database construction & Guidelines • View Fusion • Improving the view • Disambiguating function calls • Guidelines • Reconstruction • Visualization and interaction • Pattern definition and recognition • Guidelines

28. Groupwork • Have you done any similar work? • What type of application? • Why was the effort important? • What were your results?