Diseño y Evaluación de Arquitecturas de Software. Architecture Based Design Method

Transcription

1 Diseño y Evaluación de Arquitecturas de Software Architecture Based Design Method César Julio Bustacara Medina Facultad de Ingeniería Pontificia Universidad Javeriana 08/10/2015 1

2 Architecture Based Design Method This presentation is based on following technical reports: The Architecture Based Design Method, Technical Report, CMU/SEI-2000-TR001, Felix Bachmann, Len Bass, Gary Chastek, Patrick Donohoe and Fabio Peruzzi, An Application of the Architecture-Based Design Method to the Electronic House, Felix Bachmann, Len Bass and Mark Klein,

3 Architecture Based Design Method The ABD method provides a series of steps used in producing the conceptual architecture of a system. ABD depends on determining the architectural drivers for a system Architectural drivers are the combination of business, quality and functional requirements that shape the architecture With ABD, design can begin before all requirements are identified ABD methodology includes three fundamental approaches or foundations: Decomposition of function Realization of quality and business requirements Use of software templates 3

4 ABD Method Overview (1) ABD is a recursive method in which the steps of each iteration are clearly defined It provides a method of design that can meet all requirements and validate that all requirements have been met The input to the method is a list of requirements Functional, quality and business, and constraints Systems to be designed are recursively decomposed System decomposition is examined from the perspective of three views: Logical, Concurrency, Deployment Software templates are also examined as a fourth view 4

5 ABD Method Overview (2) The concrete requirements (functional, quality, and business) are used to verify the decisions made during decomposition Constraints are examined to verify that they have not been violated by a decision made during decomposition Design methods (ABD included) are not intended to replace expert designers They support design decisions by providing a structure in which the design can progress ABD has been used in design projects in which the SEI has assisted 5

6 Method Terminology - (1) Systems are decomposed into conceptual subsystems and one or more software templates ABD organizes design decisions, but does not make commitments to Software components and classes, nor to Organization of components into processes and processing threads A design element refers generically to the system, a conceptual subsystem, or a conceptual component At the top level, systems are decomposed into conceptual subsystems and one or more software templates 6

7 Method Terminology (2) At the next level the subsystems are decomposed into conceptual components Design elements have conceptual interfaces that encapsulate knowledge of data input and output Functions of one design element at one stage may be distributed at a later stage in the method to other design elements The method concludes once decisions begin to be made about classes, methods, processes, and operating system threads 7

8 Templates Level of Decomposition System Conceptual subsystem Conceptual components Concrete components aggregation Inheritance Evolves into 8

9 Perspectives and Views It is important to examine an architecture from a variety of different perspectives Static: displays organization of functionality Dynamic: displays activities that may take place concurrently Performance implications Three views are considered in the ABD method Logical view - record responsibilities and conceptual interfaces for design elements Concurrency view - multiple users, resource contention, start-up and other parallel activities Deployment view - represents nodes in the physical structure of a system 9

10 Use Cases A use case is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor [Booch, Rumbaugh, Jacobson 1999] Describes a set of sequences, in which each sequence represents the interaction of things outside the system with the system itself Behaviors identify system-level functions -- I.e. represents a functional requirement of the system as a whole A use case carries out some tangible amount of work Use cases can be the source of various types of test situations A use case is a piece of functionality in the system that gives a user a result of value. [Jacobson 99] 10

11 Quality Scenarios It is necessary to make quality requirements concrete The system should be easy to modify It should be easy to add new features of the following type New fields must be able to be added to report printouts without recompilation of program source modules Quality scenarios capture change, performance, reliability and interoperability Quality scenarios capture expected and unexpected scenarios Unexpected scenarios - may not realistic except for thought in determining boundary conditions within design 11

12 Variabilities and Commonalities (1) It is important to capture product line variations early in the design stage Coarse or fine grained variations in product line versions need to be identified as early as possible to avoid later development problems Coarse - different customer, different features Fine grained - different purpose, different implementation of the same feature Variability can occur in function or in platform or in environment ABD does not capture variabilities but expects them to be captured 12

13 Variabilities and Commonalities (2) Variabilities in platform should be categorized as quality requirements during the requirements phase Variabilities in function will be described later Commonalities refers to the fixed points within the variation inherent to a product line Features common to all instances of the product line 13

14 Software Templates A software template of a particular type enumerates responsibilities for design elements of that type. There are three kinds of responsibilities Patterns that describe how this type of design element interacts with services provided to multiple design elements (crosscutting services). Patterns that describe how this type of design element interacts with the infrastructure. Responsibilities that every design element of a particular type must provide (requirement to handle errors in a consistent way). 14

15 Template Purposes Repository for certain components that can be reused within the system Helps solve some integration problems by documenting and solving patterns of interaction a single time Categorize design elements into types Templates capture the interactions of design element types with the infrastructure and shared services Results in the skeleton system - i.e. contains the infrastructure with little or no functionality Supports the determination of patterns of interaction of various architectural element types for quality attribute modeling 15

16 Architectural Drivers Architectural drivers are the combination of functional, quality and business requirements that shape an architecture At the top level, the drivers can be determined by looking at the purpose of the system and the critical business needs Drivers do not depend on the details of the functional requirements but on their abstraction Determination of the architectural drivers may not always be a top-down process May involve research into the details of two or more approaches to learn the data processing characteristics of each that will affect the overall architecture 16

17 Architectural Driver Examples System level drivers: The purpose of an air traffic control system is to perform realtime control of enroute aircraft and this dictates high availability and reasonably stringent performance The purpose of some financial systems is to transfer money or orders from one place to another and this dictates high security and high availability Business goal or background drivers: The organization wishes to develop a product line, and this dictates a concern for generality that might not occur in a single product architecture The organization wishes to develop a particular competence, such a Web-based database access. Consequently, the architecture for the next system will be influenced by that desire 17

18 Architectural Styles An architectural style consists of a collection of component types together with a description of the pattern of interaction among them Examples are client, server, layer and process Component is primitive that describes any connection of coherent computation System Level architectural driver: The purpose of a flight simulator is to train aircrews and this dictates both high fidelity of the simulation and real-time performance The architectural driver is to process large amounts of data with hard real-time performance constraints An architecture with a real-time scheduling strategy is needed If only large amounts of data were processed, a different strategy could be selected 18

19 ABD Method within the Lifecycle Requirements Analysis ABD Method Concrete component design Functional requirements Quality requirements Constraints Abstract components Software templates Constraints Requirements Requirements phase should be at least partially complete Functional requirements Quality and business reqirements Constraints Record all decisions and rationale for those decisions 19

20 ABD method contents (1) Input to the ABD method consist of: Abstract functional requirements, including the identification of variabilities and commonalities Use cases (concrete functional requirements) Abstract quality and business requirements Quality scenarios (concrete quality and business requirements) Architecture options Constraints 20

21 ABD method contents (2) Important to consider all the end users when capturing the requirements Understand the dependencies among requirements Functional requirements are captured at an abstract level where detailed information is not known Use Case is a concrete expression of an interaction between one or more end users in the system Quantify quality and business requirements Do not make architecture decisions at this point: enumerate all possible options Constraints are design decisions that are pre-specified 21

22 The ABD method (1) ABD is based on decomposing the overall system. Every system has an application portion and an infrastructure portion The top-level decomposition is into conceptual subsystems Subsystem templates are associated with each subsystem Conceptual subsystems has its own responsibilities and is considered according to the three views: logical, concurrency, and deployment 22

23 The ABD method (2) Conceptual subsystems are, in turn decomposed into conceptual components Following the conceptual subsystems, concrete components reflect a commitment to a software element such as a set of classes 23

24 Design Element Generation The order of traversing the decomposition tree is not important a more detailed understanding of a particular aspect of the design may cause reconsideration of prior decisions May be true for architecture decisions as well as requirements Detailed investigations of a design aspect may take place at any time in order to choose the appropriate architecture All design decisions should be documented Considerations in determining how to decompose the problem Domain knowledge Incorporation of new technology Personnel performing the architectural design 24

25 Decomposition Decomposition of each design element begins with a set of requirements, a template, and a set of constraints Defining Logical View Decompose function Choose basic architectural style Define Logical view Allocate function to style Verify with quality scenarios and constraints Iterative steps Define Concurrency view Refine templates Define Deployment view Verify with use cases and change scenarios 25

26 Divide Functionality (1) Each design element has a set of responsibilities Responsibilities should be divided into groups Responsibilities come from the requirements Criteria or this division depends on the qualities important to a particular design element For modifiability, criteria might be Functional coherence Similar patterns of data or computational behavior Similar levels of abstraction Locality responsibility... For performance, criteria might be Minimize data movement Minimize unnecessary data calculations... 26

27 Divide Functionality (2) The goal of decomposition is to produce groups of functionality that will Represent decomposition of the design element responsibilities Keep the groups small (3-15) Associated with each group is A characterization of the variabilities and dependencies Enumeration the information requirements A diagram of this element can be drawn to show the external interfaces 27

28 Architectural Style Each design element has a dominant architectural style or pattern Based on the drivers for this design element The process is to determine architectural drivers for this design element and from the architectural drivers determine the dominant architectural style If a dominant style cannot be discerned, a style of independent filters with connections from outside the design element may be used Examine each quality requirement, and determine whether it is relevant to the design element being decomposed The result of this step is a collection of component types Without reference to the functionality or how often this type appears 28

29 Allocate Architectural Style (1) Groups functionality resulting from the decomposition of function should be allocated to the types of components resulting from the determination of style Components resulting from this allocation will be candidate child design elements for the design element being decomposed 29

30 Allocate Architectural Style (2) Identify the conceptual interface Information the design element needs and produces (identified during functional decomposition) Data control flow information needed Use cases are exercised to verify that they can be achieved through the proposed structure 30

31 Refine Templates Upon initiation, the method has no template Responsibilities are added as they are defined Design decisions are documented as they are made during the process Other design information is added to the template during the process: Requirements to perform functionality in the design Descriptions of shared responsibility Interface information 31

32 Other Views (1) Concurrency View To determine what activities might be carried on in parallel Examination virtual threads A single path of execution through a program, a dynamic model, or other representation of control flow (not an operating system thread) Think about use cases showing two users, effects of startup or shutdown 32

33 Other Views (2) Deployment View Issues with the used of multiple processors are examined Examination of the effect of the network on virtual threads Physical threads describe threads on a particular processor Question the impact of the network on data transmission, latencies, and on the synchronization of activities Unit of deployment: the smallest design element that can be allocated to a processor If a design element is split across two processors, it may imply a division of functionality or multiple instances of the design element 33

34 Other Views (3) Verify Quality Scenarios Each quality scenario includes an attribute stimulus and a desired response that must be verified Verify Constraints 34

35 Example (1) Architecture-Based Design of Multi- Agent Systems, Danny Weyns, Springer,

36 Example (2) 36

37 Summary ABD method The steps of the ABD Method, once requirements have been specified, are as follows: Identify architectural drivers Verify quality scenarios Divide (encapsulate) functionality Choose architectural style Generate deployment view Generate concurrency view Allocate functionality to style Verify functionality Refine templates 37

38 Conclusions The ABD method is used to generate high-level architecture Outputs of the method that are useful in further design: Design elements Templates Quality requirements Quality scenarios Representation of commonalties and variabilities An understanding of architecture and the influences that drive architecture design can be exploited to help the development process 38

39 Exercise Problem: Provide a web-accessed database containing descriptions and a catalogue of prices for a candy store Responsibilities User interface Data base Print capable... Use and adapt critical functionally, critical quality attributes and constraints proposed by Felix Bachmann, Len Bass and Mark Klein, in their study case. Generate a similar documentation to study case. 39