Your SlideShare is downloading. ×
0
Software ArchitectureAttribute Driven Design – ADD 2.0 Vakgroep Informatietechnologie – IBCN
Where are we ?Previously we have examined:     Quality attributes     Software Architecture Views     Some tactics and ...
Evolutionary Delivery Life CycleVakgroep Informatietechnologie – Onderzoeksgroep IBCN   p. 3
When do we start developing the SA?Requirements come first     But not all requirements are necessary to get started    ...
ASRs: Architectural DriversIdentify the Architectural Drivers:      Identify the highest priority business goals         ...
Attribute Driven Design: ADD (1/2)Design an architecture that supports functionalrequirements, quality requirements and de...
Attribute Driven Design: ADD (2/2)Add is a recursive design process:    Plan: Quality attributes and design constraints a...
ADD – Agile - SCRUM                                Scrum Process     ADDVakgroep Informatietechnologie – Onderzoeksgroep I...
ADD 2.0 stepsVakgroep Informatietechnologie – Onderzoeksgroep IBCN   p. 9
Output of ADDDuring ADD:       Document all design decisions as well as their rationale.ADD produces an initial software ...
ADD Step 1: Requirements InformationStep 1: Confirm there is sufficient requirementsinformation.     Sufficient does NOT ...
Controlling the car of the futureVakgroep Informatietechnologie – Onderzoeksgroep IBCN    p. 12
Controlling the car of the futureWhat are the business drivers for car manufacturers ?Vakgroep Informatietechnologie – Ond...
Requirements: Automotive platform   Functional: The platform shall        manage data from all possible sensors in a car...
ADD Step 2: Element SelectionStep 2: Choose an element of the system todecompose    Start with the entire system as a dec...
ADD Step 3: Architectural DriversStep 3: Identify candidate architectural drivers    Rank requirements with respect to th...
Automotive: Architectural Drivers                                      Step 3: ASR - Modifiability                        ...
ADD Step 4: Design ConceptsStep 4: Choose design concepts that satisfy thearchitectural drivers    Design concepts can be...
ADD Step 4: Sub- stepsStep 4 sub-steps:      1.    Identify the design concerns associated with the            architectur...
Automotive: Design Concepts                                      Step 4.1: Modifiability Concerns                         ...
Modifiability UI & sensorsVakgroep Informatietechnologie – Onderzoeksgroep IBCN   p. 21
Modifiability ScenarioSupport for HUDHead up display                                          Artifact                    ...
Automotive : Design Concepts                                      Step 4.2 : Supporting tactics                           ...
Automotive: Design Concepts                                      Step 4.2 : Supporting Patterns                           ...
ADD Step 5: Instantiate elementsStep 5: Instantiate Architectural Elements andallocate responsibilities.     Example: Sel...
ADD Step 5: Sub- steps (1/2)Step 5 sub-steps:      1.    Instantiate the elements.      2.    Consider multiple views:    ...
Automotive : Instantiate elements                                      Step 5.1 : Instantiate MVC                         ...
Automotive : ..allocate responsibilities Model           instances         CCP: the car control platform View         i...
Automotive : Allocate responsibilities ASR:          Tire pressure loss:       When the tire sensor detects a loss of pr...
Automotive : Static View- subsystems      <<Model>>                             <<View>>              <<View>>         :CC...
ADD Step 5: Sub- steps (2/2)Step 5 sub-steps ctd:      4.    Discover new responsibilities using typical system use       ...
ADD Step 6: InterfacesStep 6: Define the interfaces for the instantiatedelements.         Interfaces describe the PROVIDE...
ADD Step 7: VerificationStep 7: Verify and refine requirements and makethem constraints for instantiated elements.       ...
Summary: Designing a Software ArchitecturePlan: From Requirements to Architectural Drivers    Use the most important ones...
Upcoming SlideShare
Loading in...5
×

Sa 009 add

754

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
754
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Sa 009 add"

  1. 1. Software ArchitectureAttribute Driven Design – ADD 2.0 Vakgroep Informatietechnologie – IBCN
  2. 2. Where are we ?Previously we have examined: Quality attributes Software Architecture Views Some tactics and patterns for achieving quality attributesNow we focus on Design of an Architecture Architecture in the software life cycle Designing the architecture Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2
  3. 3. Evolutionary Delivery Life CycleVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3
  4. 4. When do we start developing the SA?Requirements come first But not all requirements are necessary to get started Not all requirements are equal.Architecture shaped by : Functional requirements Quality requirements Design ConstraintsWe call these “Architectural Drivers” The architecture of of an Air Traffic Control system is driven by high availability. A Flight simulator is driven by hard real time response times. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4
  5. 5. ASRs: Architectural DriversIdentify the Architectural Drivers:  Identify the highest priority business goals  Only a few of these  Turn these into scenarios or use cases  Choose architecture significant requirements (ASRs)  These are the architectural drivers  There should be less than 10 of theseVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5
  6. 6. Attribute Driven Design: ADD (1/2)Design an architecture that supports functionalrequirements, quality requirements and designconstraints. ADD: architecture design using a decomposition process that is based on the quality attributes of the the system ADD input: architectural drivers (ASRs) ADD output: levels of decomposition and related architectural views Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6
  7. 7. Attribute Driven Design: ADD (2/2)Add is a recursive design process: Plan: Quality attributes and design constraints are considered to select which tactics or patterns will be used in the architecture. Do: Software architectural elements are instantiated to satisfy the ASRs (architecture significant functional and quality requirements). Check: The architecture design is analyzed to determine if the other (non ASR) functional and quality requirements are met.Relation to Agile ? ADD can be part of the high level design steps in Agile. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7
  8. 8. ADD – Agile - SCRUM Scrum Process ADDVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8
  9. 9. ADD 2.0 stepsVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9
  10. 10. Output of ADDDuring ADD:  Document all design decisions as well as their rationale.ADD produces an initial software architecture design:  How to partition the system into computational & developmental elements  The software elements that will be part of the different structures, the type of elements, the properties and structural relations  The interactions between the software elements, the properties of the interactions and the mechanisms by which they occur. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 10
  11. 11. ADD Step 1: Requirements InformationStep 1: Confirm there is sufficient requirementsinformation.  Sufficient does NOT equal complete.  The list of prioritized requirements according to business goals.  Quality attributes should be described using measurable (testable) responses  This information is needed to select tactics and patterns that can be used to achieve the requirements.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 11
  12. 12. Controlling the car of the futureVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12
  13. 13. Controlling the car of the futureWhat are the business drivers for car manufacturers ?Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13
  14. 14. Requirements: Automotive platform Functional: The platform shall  manage data from all possible sensors in a car.  perform real time diagnostics and plan maintenance  enable ecological driving modes. Quality attributes  Modifiability:  The platform will work on all cars from the vendor(s): from low-end to luxury car.  Automatically take into account the options selected by a customer.  Performance:  Data from security events has to be send immediately to the driver. Design constraints  The platform executes on a microcontroller environment  The hardware cost must be minimal  The power consumption must be minimal Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 14
  15. 15. ADD Step 2: Element SelectionStep 2: Choose an element of the system todecompose  Start with the entire system as a decomposition element.  All requirements are allocated to the system level.  Once the system is partitioned, assign requirements to the decomposition elements.  Different levels of decomposition and elements:  System ,  Sub-system ,  Module ,  Sub-moduleVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 15
  16. 16. ADD Step 3: Architectural DriversStep 3: Identify candidate architectural drivers  Rank requirements with respect to their impact on the architecture:  (H,H); (H,M), …(M,L) from the utility tree  Priority/Complexity score from the use case index  Select the architectural drivers.  Less important requirements are satisfied within constraints obtained by satisfying more important requirements.  Not all requirements apply to all decomposition elements.  This is a difference of ADD from other SA design methods.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16
  17. 17. Automotive: Architectural Drivers Step 3: ASR - Modifiability -Support all models from the vendor -Extensible to new models & electric vehicles - Reuse -Support the option list - Configurable -Run on different types of microcontrollersVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 17
  18. 18. ADD Step 4: Design ConceptsStep 4: Choose design concepts that satisfy thearchitectural drivers  Design concepts can be tactics or patterns. Patterns are collections of tactics.  Step 4 involves a number of sub-steps to determine the type of software elements that will be part of the design.  Important design decisions are taken while others can be deferred: document both !  Major types of elements at this design level  Functionality of the elements  Types of communication between elementsVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 18
  19. 19. ADD Step 4: Sub- stepsStep 4 sub-steps: 1. Identify the design concerns associated with the architectural drivers.  This comes straight from the utility tree 1. For each design concern, list the alternative tactics or patterns that address the concern.  Inspiration comes from the quality attribute tactics  From your experience 1. Find the tactics and patterns that satisfy most ASRs  Create a table with patterns & tactics in the columns and ASRs in the rows. 1. Patterns have an impact of several quality attributes.  How do we balance?  What are the trade-offs ?Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19
  20. 20. Automotive: Design Concepts Step 4.1: Modifiability Concerns  Extensibility:  Hardware platform  New sensors  New applications – Self park  Reuse :  Across models  Integration:  3rd party car entertainment  3rd party GPS  3rd party smartphoneVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 20
  21. 21. Modifiability UI & sensorsVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21
  22. 22. Modifiability ScenarioSupport for HUDHead up display Artifact Display & Control code Source Stimulus Environment Response ResponseDeveloper Adds support Build Addition measure for a HUD Time is made No changes without to existing (production) effects on interfaces other modules Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 22
  23. 23. Automotive : Design Concepts Step 4.2 : Supporting tactics  Semantic coherence  Abstract common services  Encapsulation  Use intermediary  Runtime bindingVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 23
  24. 24. Automotive: Design Concepts Step 4.2 : Supporting Patterns  Layers  MVC  Broker  Publish Subscribe  … Step 4.3 : Find the tactics and patterns that satisfy most ASRs Tradeoffs ?  PerformanceVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24
  25. 25. ADD Step 5: Instantiate elementsStep 5: Instantiate Architectural Elements andallocate responsibilities.  Example: Selecting a layered pattern (step 4) to support modifiability does not tell how many layers you need and what the responsibilities of each layer are.  Responsibilities for instantiated elements are derived from functional requirements and use cases.  Examine multiple views: static , dynamic, deployment.  Apply implicit use casesVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 25
  26. 26. ADD Step 5: Sub- steps (1/2)Step 5 sub-steps: 1. Instantiate the elements. 2. Consider multiple views:  Static views provide containers for functionality and show relations between modules  Dynamic views show parallel activities such as resource contention, deadlock . 1. Apply use cases with the CRC methodology  Every use case of the parent element must be implemented by a sequence of responsibilities of the children.  Assigning these responsibilities to the children will also determine communications: producer/consumer relationship  How the information is exchanged is not critical at this point.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 26
  27. 27. Automotive : Instantiate elements Step 5.1 : Instantiate MVC 1. Separate core functions from (inter)action, input & output. User input  Data , commands Sensor input Controls  Actuators  Car control systems Views  Main dashboard  HUD  Central display screenVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 27
  28. 28. Automotive : ..allocate responsibilities Model instances  CCP: the car control platform View instances  dBoard: the driver dashboard  cDisplay : the central console display Controllers (Intermediaries)  Sensors: Global sensor controller  iDrive : man machine controller on central console  sWheel : steering wheel controls.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 28
  29. 29. Automotive : Allocate responsibilities ASR: Tire pressure loss:  When the tire sensor detects a loss of pressure in the tire, the driver will be alerted immediately.  In case the pressure drops more then 50% below the normal value, the driver is advised to pull over and stop.  In case the car has run flat tires, the driver is advised that the trip can be continued at reduced speed.  The platform will identify the service centers in the area or will forward a call to the local road service center.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 29
  30. 30. Automotive : Static View- subsystems <<Model>> <<View>> <<View>> :CCP :dBoard :cDisplay <<Controller>> <<Controller>> <<Controller>> :Sensors :sWheel :iDrive1. Make CRC cards2. “Role” play the scenario3. Allocate responsibilities & collaboration4. Document using sequence diagramsVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 30
  31. 31. ADD Step 5: Sub- steps (2/2)Step 5 sub-steps ctd: 4. Discover new responsibilities using typical system use cases:  One user doing many tasks simultaneously  Many users doing similar tasks simultaneously  Startup of the system  Shutdown of the system  Disconnected operations  Failure of various elements 5. Analyze and document the design decisions using different views:  Static views for non runtime properties  Dynamic views for reasoning about runtime behavior and properties  Deployment views to reason about the relation between software and hardware.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 31
  32. 32. ADD Step 6: InterfacesStep 6: Define the interfaces for the instantiatedelements.  Interfaces describe the PROVIDE and REQUIRE assumptions that software elements make about each other. This can include  Information exchanged (events, data, …)  Syntax of operations (signature)  Semantics (description, pre- & post conditions, restrictions )  Error handling  Analyzing the decomposition into the three views provides interaction information for the interface  Static or Module view (producer/consumer info)  Dynamic or Concurrency view (communication patterns, synchronization, thread interaction, ..)  Allocation or Deployment view (timing , communication, ..)  Document the interfacesVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 32
  33. 33. ADD Step 7: VerificationStep 7: Verify and refine requirements and makethem constraints for instantiated elements.  Steps 4, 5 and 6 are executed taking into account mainly the ASRs. Next we have to verify if all other requirements are satisfied by this decomposition. If this is not the case we need to backtrack.  Verifying the decomposition by “running” the parent’s use cases - iterative design  Verify if all requirements have been allocated to one or more elements.  Preparing children for their own decomposition by inheriting use cases/constraints from the parent.  Translate the responsibilities of elements into functional requirements for those elements.  Refine quality attributes for individual elements.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 33
  34. 34. Summary: Designing a Software ArchitecturePlan: From Requirements to Architectural Drivers Use the most important ones: ASRs Less than 10Do: From ASRs to the initial Architecture ASRs are satisfied with tactics and patterns. Attribute Driven Design (ADD) top down design process  Quality requirements determine the design concepts that can be tactics, patterns or a combination of both.  Functional requirements instantiate modules for that pattern.Check: Verify the initial design with respect to the other(non ASR) requirements.Start the next level decomposition. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 34
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×