1. Software Architecture in Practice RiSE’s Seminars Bass’s book :: Chapters 07 Eduardo Cruz

2. 2 Summary Designing the Architecture (Chapter 7)  Architecture in the life cycle  Designing the Architecture  Forming its team structure and its relationship to the architecture  Creatign a skeletal system  Evolutionary Delivery Life Cycle  When Can I begin Designing?  How to identify the architectural drivers?  Attribute-Driven Design

3. 3 Evolutionary Delivery Life Cycle Software Concept Preliminary Requirements Analysis Design of Architecture and System Core Develop a Version Incorporate Customer Feedback Elicit Customer Feedback Deliver the Version Deliver Final Version

4. 4 Evolutionary Delivery Life Cycle Goal  To get user and customer feedback Microsoft strategy  Skeletal system Early Low-fidelity Updates Designing the Architecture :: Chapter 7

5. 5 When Can I begin Designing? Architecture shaped by: Functionality Quality Business requirements Examples  Avionic system Availability, Performance, Security...  COMPGOV Availability, Performance, Security... Designing the Architecture :: Chapter 7 Architectural drivers

6. 6 How to identify the architectural drivers? Designing the Architecture :: Chapter 7 To priorize business goals {few} To put these business goals into quality scenarios or use cases  Scenary’s template To choose the most importants  Impact on the architecture

7. 7 Quality attribute parts Availability Modifiability Performance Security Testability Usability Designing the Architecture :: Chapter 7 ARTIFACT STIMULUSRESPONSE MEASURE SOURCE OF STIMULUS ENVIRONMENT

8. 8 Attribute-Driven Design Designing the Architecture :: Chapter 7 Approach to define a software architecture that bases the decomposition process on the quality attributes the software has to fulfill Recursive decomposition process Use  Tatics  Architectural Patterns Systematic approach

9. 9 Attribute-Driven Design (cont.) Designing the Architecture :: Chapter 7 To satisfy quality attributes and functional requirements RUP’s extension  High-level design  Detailed design and implementation ADD  Detailed {high-level} + Rational Input  Functional requirements (expressed as use cases)  Constraints  Quality attributes scenarios

10. 10 ADD Steps (p. 157) 1. Choose the module to decompose  Module: the system  Inputs: requirements, quality attributes, constraints  Quality attributes scenarios 2. Refine the module  Choose the architectural drivers from the set of concrete quality scenarios and functional requirements  Choose an architectural pattern that satisfies the architectural drivers  Instantiate modules and allocate functionality from the use cases  Define interfaces of the child modules  Verify and refine use cases and quality scenaries 3. Repeat the steps above for every module that needs further decomposition

11. 11 ADD Steps Choose the module to decompose  System  Subsystem  Submodules Choose the architectural drivers  Combination of functional and quality requirements that “shape” the architecture or the particular module under considerations  It is not always a top-down process Prototype  Decomposition criterias Based on architectural drivers Requirements priorization System Subsystem

12. 12 ADD Steps (cont.) Choose an Architectural Pattern  Goal: To establish an overall architectural pattern consisting of module types  Quality attributes -> Tatics -> Patterns Instantiate Modules and Allocate Functionality using Multiple Views  Instantiate module Use of responsability  Allocate functionality Based on Use cases  Represent the architecture with views (flexibility) Iterative process One view is normally sufficient  Module decomposition  Concurrency  Deployment  Others aspects can be used

13. 13 ADD Steps (cont.) Define Interfaces of the Child Modules  Documentation aspects Verify and Refine Use cases and Quality Scenarios as Constraints for the Child Modules  Functional requirements Requirements + use cases -> module  Constraints The decomposition satisfies the constraint The constraint is satisfied by a single child module The constraint is satisfied by multiple child module

14. 14 ADD Steps (cont.)  Quality scenarios 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 decompostion  Result Child module  Responsability  Use cases  Interfaces  Quality scenario  Constraints

15. 15 References L. Bass, P. C. Clements, R. Kazman. Software Architecture in Practice. Second Edition, Addison- Wesley, 2003.

16. Functionality-based architecture design RiSE’s Seminars Jan Bosch’s book :: Chapter 4 Vinicius Cardoso Garcia {Design & Use of Software Architectures}

17. 17 Summary Introduction Defining the system context Identifying the archetypes Decomposing the architecture into components Describing system instantiations Illustrating functionality-based architecture design  Fire-alarm system context Summary

18. 18 Introduction Architectural design is the process of converting a set of requirements into a software architecture Functionality-based architectural design  Focus on explicit evaluation of and for quality requirements  Does not mean that the functional requirements are irrelevant Design phase consists of four main steps  Determining the context of the system  Identification of archetypes  Decomposing system into components  Description system instances using the archetypes and the system interfaces

19. 19 Starting from the functional requirements does not preclude the optimization of quality requirements An objective and repeatable architectural design method must be organized  Unlikely that architectural design process does not require iterations to optimize the architecture An architecture based primarily on functional requirements is more general It is unlikely that a SA which fulfils a particular set of quality requirements will be applicable in a domain with different FR

20. 20 Defining the system context “No objects is an island” (Beck and Cunningham, 1989) -> software systems in general The role of the software architect is to convert the requirements of the stakeholder concerning the external visible properties of the system into a software architecture  Facilitates the fulfillment of these requirements The externally visible behavior is present at the interfaces to its context Explicitly defining the system in terms of the functionality and quality required on its interfaces is an important starting point

21. 21 Additional reason for explicitly defining the system context and boundaries  Is a natural tendency to include more and more aspects during design When this effort is spent on SA design -> take time When there is no extreme time pressure, software architects try to extend the domain of he design  Improve the applicability and allow for likely future requirements  That extensions increase the design and development cost Defining the system context System Higher-level systems Peer-level systems Lower-level systems Used by uses uses Depends on

22. 22 Define the interfaces of the system to external entities.  These entities may be located at a lower level, a higher level or at the same level; Associate functional and quality requirements with each interface.  Both operational and development quality requirements can be associated with interfaces; In the case of software product line, the variability in the interfaces supported by the various products in the product line should be explicitly identified and specified.  The cost and resource efficiency of low-end products should not be sacrificed for the requirements of high-end products. Defining the system context

23. 23 Identifying the archetypes Identify and define the core abstractions based on which the system is structured -> archetypes  These entities form the most stable part of the system and are generally very stable and only changed in very limited ways.  Large systems often can be described in terms of a small number of archetypes The identification is largely dependent on the creative insight and experience of the architect (or architects) The primary starting point is a good understanding of the domains It is possible to recognize recurring patterns whiting the system at various places -> candidate archetypes!  The candidate archetypes are recorded and form a set  The set is analyzed to select the most appropriate archetypes

24. 24 The identification of architectural entities is related to domain analysis methods (Prieto-Diaz and Arango, 1991)  Archetypes can be modeled as domain objects  After analyzing the various domain entities, abstracts the most relevant properties and models them as architectural entities  The iteration between them are defined in more detail  ADLs -> architectures are described in terms of components and connectors Identifying the archetypes

25. 25 To conclude:  Identification of candidate archetypes;  The selection of a small and stable set of archetypes from the candidates. This may require the exclusion of candidates, but especially the merging of candidates is rather common;  The identification and selection of relations between archetypes. Identifying the archetypes

26. 26 Decomposing the architecture into components Archetypes do not represent the architectural structure of the system  They are generally instantiated in several places in the system in several concrete forms  The next step is to define the structure of the software architecture decomposition into components and relation between these components This decomposition does note need to be single level  Incorporate two or more recursive levels Several approaches can be used to identify and select components

27. 27 Interfaces: Each of the system interfaces should be connected to a component. One possible approach is by associating a component with each interface; Domains: A second source for components is to associate domains covered by the system. Two types of domains:  application domains - problem intends to address  computer science domains - areas associated with the solution used to solve the problem Abstraction layers: horizontal layers that implement relevant functionality and simplify the specification of problem-domain functionality at higher levels. Are identified while interacting over the component selection of the system. Decomposing the architecture into components

28. 28 Domain entities: The decomposition defined by the domain experts provides a highly valuable input to the identification and selection of components of the system, and software architects are often tempted to select these components right away. Archetype instantiations: Even the identified archetypes may provide valuable input to selection components. The archetypes are defined based on the identification of recurring patterns throughout the system. These archetype initiations may represent useful components. Functional x Entity-based decomposition  Functional is concerned with the functions that he system supposed to provide – C, Pascal  The primary concepts that can be identified in the systems – C++, Java, C# Decomposing the architecture into components

29. 29 Problem-domain x Solution-domain  Both domains can be decomposed according to the main functions and entities in the domain Compiler architecture Control theory architecture Graphical User-interface architecture 3-tier architecture Solution domain Entity Functionality Problem domain Decomposing the architecture into components To identifying relation on the origin on which component is defined, a second approach is to “script” scenarios for the architecture. Following a logical sequence of execution in the architecture helps to identify what components need to be able to communicate with each other

30. 30 To summarize... Identification and specification of components  We have examined the possible sources for the identification of components, including the system interfaces, domains, abstraction layers, domain entities and archetype instantiation. Identification and specification of relations  Once the components have been identified, the relations between them need to be identified. We have presented some guidelines and hints, based on the origin of the component. Decomposing the architecture into components

31. 31 Design is typically an iterative process  integrating activities addressing the overall system  focusing activities on addressing parts of the system that require particular attention The components of the software architecture are recursively decomposed into lower-level components; Each component is either populated with instantiated archetypes  fulfill the functionality required from the system or is represented by an individual instantiated archetype; The generic relations between the archetypes are instantiated for the instantiated archetypes  verification of the match between abstractions and the concrete system decomposition is performed; Sufficient variability of product-line architectures is verified by the definition of multiple system instantiations, representing different products. Describing system instantiations

32. 32 Fire-alarm systems Defining the context  Is a relatively autonomous system, but it does not provide a number of interfaces to its context  The first issue: whether the mechanical and hardware parts of the detectors and alarm devices are part of the system or not Those parts to be external -> the interfaces exists between the software and the physical detectors and alarm devices  Second issue: whether the communication of the system is part of the system -> high distributed

33. 33 Fire-alarm systems - Interfaces Building Automation systems operator Detector Output Fire-alarm system interface

34. 34 Identifying the archetypes Point: high-level abstraction concerning fire-alarm domain functionality. It is the abstraction of the two subsequent archetypes; Detector: captures the core functionality of the fire-detection equipment, including smoke and temperature sensors; Output: contains generic output functionality, including traditional alarms; Control unit: connected to a network and can communicate.

35. 35 Relations between the F-A archetypes Point Control Unit DetectorOutput Communicates with

36. 36 Decomposing the architecture into components Physical point is an instantiation of the point archetype, whereas the communication component is typically a component based on a solution domain; Section component is a domain entity in the system, it represents a controller and the physical points is monitored by it;  Also represents a geographic area where the physical points are responsible That architecture employs an entity-based decomposing and the entities are taken from the solution domain Physical pointsCommunication Section

37. 37 Describing the system instantiations Smoke detector Smoke detector Smoke detector Smoke detector Smoke detector Control unit Sound alarm User interface Small fire-alarm system instantiation

38. 38 Describing the system instantiations Two building fire-alarm system instantiation point Control Unit Control Unit Control Unit Control Unit point Control Unit Control Unit Control Unit Control Unit point Operator Interface

39. 39 Summary The method has a focus on the explicit evaluation of an d design for quality requirements, but that does not mean that the functional requirements are irrelevant. Before one can start to optimize an architecture for quality requirements, the first step must be to design an initial version of the architecture based on the functional requirements.

40. 40 Artefacts developed during process

41. 41 References Bosch, J. Design & Use of Software Architectures, 1st edition ed: Addison-Wesley Professional, 2000. Prieto-Díaz, R. and Arango, G. Domain Analysis and Software Systems Modeling. IEEE Computer Society Press, 1991.

42. Software Architecture in Practice RiSE’s Seminars Bass’s et al. Book :: Chapter 12 Fred Durão e Ednaldo Dilorenzo

43. 43 Summary The CBAM (Chapter 12)  Concepts  Decision Making Context  The Basis for the CBAM  Calculating ROI  The importance of Cost Modeling  Implementing CBAM  Case Study: The NASA ECS Project

44. 44 The CBAM – A Quantitative Approach to Architecture Design Decision Making

45. 45 Concepts The biggest tradeoffs in large, complex systems usually have to do with economics. How should an organization invest its resources in a manner that will maximize its gains and minimize its risk? “…perhaps more important than costs, are the benefits than an architecture decision may bring to an organization.” CBAM provides an assessment of the technical and economic issues and architectural decisions The CBAM :: Chapter 12

46. 46 Decision-Making Context When ATAM is applied to a software system, we have as a result a set of artefacts  a set of architectural views;  a set of stakeholders goals; a set of risks;  a set of tradeoffs points and more… The ATAM uncovers the architectural decisions, links the to business goals and quality attribute response measures. The CBAM does not make decisions for the stakeholders. It simply aids in the elicitation and documentation of the costs and benefits (based on ATAM results). The CBAM can aid the stakeholders in choosing architectural strategies based on their return on investment return on investment (ROI) – the ratio of benefit to cost. The CBAM :: Chapter 12

47. 47 The Basis for the CBAM Variations of Scenarios  a way to concretely express and represent specific quality attributes Utility-Response Curves  Every stimulus-response value pair in a scenario provides some utility to the stakeholders, and the utility of different possible values for the response can be compared. Priorities of Scenarios  Different scenarios within a given system have different levels of importance to the stakeholders and hence different utilities.  To characterize the relative importance of each scenario, a weigh is assigned through a two-step voting exercise. The CBAM :: Chapter 12

48. 48 The Basis for the CBAM {2} Architectural Strategies  In order to move from the current utility attribute response level to the desired or even best-case level. Side Effects  Impact of the changes The CBAM :: Chapter 12

49. 49 Calculating ROI R (ROI) = B (Benefit) / C (Cost) This can be used to determine the optimal order for implementation the various strategies. The CBAM :: Chapter 12

50. 50 The importance of Cost Modeling “How do I convince my boss to investing in availability ?” Maintain high availability requires a high level of redundancy with a rollover capability  This takes time an personnel  Personnel cost money as do purchasing highly available software and adapting it for particular needs Cost models are imperfect for a wide variety of reasons, but they are the only tools available to constrain requirements. The CBAM :: Chapter 12

51. 51 Implementing CBAM The CBAM :: Chapter 12

52. 52 Case Study: The NASA ECS Project The Earth Observing System is a constellation of NASA satellites that gathers data for the U.S. Global Change Research Program. The ECS processes an input stream of hundreds of gigabytes of raw environment-related data per day. The ECS project manager had a limited annual budget to maintain and enhance his current system. The CBAM :: Chapter 12

53. 53 STEP 1: COLLATE SCENARIOS ScenarioScenario Description 1Reduce data distribution failures that result in hung distribution requests requiring manual intervention. 2 Reduce data distribution failures that result in lost distribution requests. 3Reduce the number of orders that fail on the order submission process. 4Reduce order failures that result in hung orders that require manual intervention. 5Reduce order failures that result in lost orders. 6There is no good method of tracking ECSGuest failed/canceled orders without much manual intervention (e.g., spreadsheets). 7Users need more information on why their orders for data failed. 8Because of limitations, there is a need to artificially limit the size and number of orders. 9Small orders result in too many notifications to users. 10The system should process a 50-GB user request in one day, and a 1-TB user request in one week. The CBAM :: Chapter 12

54. 54 STEP 2: REFINE SCENARIOS ScenarioWorstCurrentDesiredBest 110% hung5% hung1% hung0% hung 2> 5% lost< 1% lost0% lost 310% fail5% fail1% fail0% fail 410% hung5% hung1% hung0% hung 510% lost< 1% lost0% lost 650% need help25% need help0% need help 710% get information50% get information100% get information 850% limited30% limited0% limited 91/granule 1/100 granules1/1000 granules 10< 50% meet goal60% meet goal80% meet goal> 90% meet goal The CBAM :: Chapter 12

55. 55 STEP 3: PRIORITIZE SCENARIOS ScenarioVotesWorstCurrentDesiredBest 11010% hung5% hung1% hung0% hung 215> 5% lost< 1% lost0% lost 31510% fail5% fail1% fail0% fail 41010% hung5% hung1% hung0% hung 51510% lost< 1% lost0% lost 61050% need help25% need help0% need help 7510% get information 50% get information 100% get information 8550% limited30% limited0% limited 9101/granule 1/100 granules1/1000 granules 105< 50% meet goal60% meet goal80% meet goal> 90% meet goal The CBAM :: Chapter 12

56. 56 STEP 4: ASSIGN UTILITY ScenarioVotesWorstCurrentDesiredBest 110 8095100 215070100 3152570100 410 8095100 515070100 610080100 751070100 85020100 91050 8090 1050 90100 The CBAM :: Chapter 12

57. 57 STEP 5: DEVELOP ARCHITECTURAL STRATEGIES FOR SCENARIOS AND DETERMINE THEIR EXPECTED QUALITY ATTRIBUTE RESPONSE LEVELS StrategyNameDescriptionScenarios Affected Current Response Expected Response 1Order persistence on submission Store an order as soon as it arrives in the system. 3, 5, 65% fail, < 1% lost, 25% need help 2% fail, 0% lost, 0% need help 2Order chunkingAllow operators to partition large orders into multiple small orders. 830% limited15% limited 3Order bundlingCombine multiple small orders into one large order. 9, 101 per granule 60% meet goal 1 per 1000, 55% meet goal, 2% hung 4Order segmentationAllow an operator to skip items that cannot be retrieved due to data quality or availability issues. 45% hung2% hung 5Order reassignmentAllow an operator to reassign the media type for items in an order. 15% hung2% hung 6Order retryAllow an operator to retry an order or items in an order that may have failed due to temporary system or data problems. 45% hung3% hung The CBAM :: Chapter 12

58. 58 STEP 5: DEVELOP ARCHITECTURAL STRATEGIES FOR SCENARIOS AND DETERMINE THEIR EXPECTED QUALITY ATTRIBUTE RESPONSE LEVELS StrategyNameDescriptionScenarios Affected Current Response Expected Response 7Forced order completion Allow an operator to override an item’s unavailability due to data quality constraints. 15% hung3% hung 8Failed order notification Ensure that users are notified only when part of their order has truly failed and provide detailed status of each item; user notification occurs only if operator okays notification; the operator may edit notification. 6, 725% need help, 50% get information 20% need help, 90% get information 9Granule level-order tracking An operator and user can determine the status for each item in their order. 6, 725% need help, 50% get information 10% need help, 95% get information 10Links to user information An operator can quickly locate a user’s contact information. Server will access SDSRV information to determine any data restrictions that might apply and will route orders/order segments to appropriate distribution capabilities, including DDIST, PDS, external subsetters and data processing tools, etc. 750% get information 60% get information The CBAM :: Chapter 12

59. 59 STEP 6: DETERMINE THE UTILITY OF THE “EXPECTED” QUALITY ATTRIBUTE RESPONSE LEVELS BY INTERPOLATION Strategy Scenarios Affected Current UtilityExpected Utility 1Order persistence on submission 3, 5, 670, 70, 8090, 100, 100 2Order chunking82060 3Order bundling9, 1050, 7080, 65 4Order segmentation48090 5Order reassignment18092 6Order retry48085 7Forced order completion18087 8Failed order notification6, 780, 7085, 90 9Granule level order tracking6, 780, 7090, 95 10Links to user information77075 The CBAM :: Chapter 12

60. 60 STEP 7: CALCULATE THE TOTAL BENEFIT OBTAINED FROM AN ARCHITECTURAL STRATEGY StrategyScenario AffectedScenario WeightRaw Architecural Strategy Benefit Normalized Architectural Strategy Benefit 131520300 151530450 161020200 28540200 39930300 310 -5-25 44410100 51112120 644550 711770 866550 87720100 96610100 97725125 1077525 The CBAM :: Chapter 12

61. 61 STEP 8: CHOOSE ARCHITECTURAL STRATEGIES BASED ON ROI VALUE SUBJECT TO COST CONSTRAINTS StrategyCostTotal Strategy Benefit Strategy ROIStrategy Rank 112009500,791 24002000,53 34002750,692 42001000,53 54001200,37 6200500,258 7200700,356 83001500,53 910002250,2210 100250,258 The CBAM :: Chapter 12

62. 62 Results of the CBAM Exercise The most obvious results are the ordering of architectural strategies based on their predicted ROI. The CBAM process provides a great deal of structure to what is always largely unstructured discussions The CBAM :: Chapter 12

63. 63 References Bass L., Clements P. and Kazman R. Software Architecture in Practice. Second Edition, 2003. “a felicidade pode esperar” The CBAM :: Chapter 12

64. DAGAR: A Process for Domain Architecture Definition and Asset Implementation RiSE Workshop Eduardo Santana de Almeida

65. 65 Agenda DAGAR  Context  Problem  Motivation  Proposal  Key definitions  Activities  Brief Analysis Software architecture x Domain architecture

66. 66 DAGAR: A Process for Domain Architecture Definition and Asset Implementation Context  Software Technology for Adaptable, Reliable Systems (STARS) program  1996 Sponsored  U.S. Defense Advanced Research Projects Agency (DARPA)  Military services  Software Engineering Institute (SEI)  MITRE

67. 67 Context Reuse  Oportunistic x Planned  Software Product Lines DAGAR: A Process for Domain Architecture Definition and Asset Implementation Organization Domain Modeling (ODM) Lack of Methods for Develop Doman Architecture Problem Proposal Repeatable Documented Tools {GenVoca – Don Batory}

68. 68 Differences Software architecture Domain architecture DAGAR: A Process for Domain Architecture Definition and Asset Implementation Realms {specification}  Module  Interfaces Components {instance}  Specification  Body Key DAGAR definitions Realm Component specification Component body ADA package

69. 69 Overview

70. 70 Approach for Architecting the Asset Base DAGAR: A Process for Domain Architecture Definition and Asset Implementation

71. 71 Asset Base Architecture: Definition DAGAR: A Process for Domain Architecture Definition and Asset Implementation

72. 72 Develop Top-Level Architecture DAGAR: A Process for Domain Architecture Definition and Asset Implementation

73. 73 Develop Realm Descriptions DAGAR: A Process for Domain Architecture Definition and Asset Implementation

74. 74 Recommendations for Architecting the Asset Base domain modeling efforts Domain engineering projects should focus their domain modeling efforts on domain models that supports the creation and application of a domain architecture new way of thinking about asset base architecturetraining domain architecture development DAGAR requires a new way of thinking about asset base architecture. Domain engineers need training in DAGAR and domain architecture development all possible applications An asset base architect must be concerned with all possible applications of the assets in a domain DAGAR: A Process for Domain Architecture Definition and Asset Implementation

75. 75 Implementing the Asset Base DAGAR: A Process for Domain Architecture Definition and Asset Implementation

76. 76 Recommendations for Implementing the Asset Base An Asset base, devoid of its architecture, is not intended to be generally useful and reusable. Asset base success cannot be measured apart from the architecture within which it was created sufficiently knowledgeable about Ada The domain engineering team must be sufficiently knowledgeable about Ada to be able to complete the DAGAR component payoof DAGAR requires that up front effort be applied in developing both assets and CLIPS rules. The payoof comes from being able to automate generation of subsystem after subsystem from the domain asset base DAGAR: A Process for Domain Architecture Definition and Asset Implementation

77. 77 Applying the Asset Base to Generate a Subsystem DAGAR: A Process for Domain Architecture Definition and Asset Implementation

78. 78 Brief analysis DAGAR: A Process for Domain Architecture Definition and Asset Implementation Very general  Flexible  Based on ADA  Not useful {currently}  Useful Template Learned lessons, project description...

79. 79 References C. Klinger, J. Solderitsch. DAGAR: A Process for Domain Architecture Definition and Asset Implementation, STARS program. 1996, p. 33.