1. Analysis and Design Overview 12/14/2015 11

2. Objectives Review the key Analysis and Design terms and concepts Introduce the Analysis and Design process, including roles, artifacts and workflow Explain the difference between Analysis and Design 2

3. Analysis and Design in Context 3 The purposes of Analysis and Design are to:  Transform the requirements into a design of the system- to-be.  Evolve a robust architecture for the system.  Adapt the design to match the implementation environment, designing it for performance. The purposes of Analysis and Design are to:  Transform the requirements into a design of the system- to-be.  Evolve a robust architecture for the system.  Adapt the design to match the implementation environment, designing it for performance.

4. Analysis and Design Overview 4 Supplementary Specification Use-Case Model Design ModelData Model Architecture Document Analysis and Design Glossary

5. Analysis Versus Design 5 AnalysisDesign  Focus on understanding the problem  Idealized design  Behavior  System structure  Functional requirements  A small model  Focus on understanding the solution  Operations and attributes  Performance  Close to real code  Object lifecycles  Nonfunctional requirements  A large model WHAT? HOW?

6. Analysis and Design Are Not Top-Down or Bottom-Up 6 Bottom Up Top Down Design Classes Subsystems Use CasesAnalysis Classes (Define a middle level) Analysis and Design

7. What Is Architecture? Software architecture encompasses a set of significant decisions about the organization of a software system.  Selection of the structural elements and their interfaces by which a system is composed  Behavior as specified in collaborations among those elements  Composition of these structural and behavioral elements into larger subsystems  Architectural style that guides this organization 7 Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational (derived from Mary Shaw)

8. Architecture Constrains Design and Implementation Architecture involves a set of strategic design decisions, rules or patterns that constrain design and construction. 8 Architecture decisions are the most fundamental decisions, and changing them will have significant effects. Architecture Design Implementation Code

9. Software Architecture: The “4+1 View” Model 9 Process ViewDeployment View Logical View Use-Case View Implementation View End-user Functionality Programmers Software management Performance, scalability, throughput System integrators System topology, delivery, installation, communication System engineering Analysts/Designers Structure

10. Analysis and Design Workflow 10 Analysis Design [Early Elaboration Iteration] [Inception Iteration (Optional)] Define a Candidate Architecture Perform Architectural Synthesis Analyze Behavior Refine the Architecture Design Components Design the Database (Optional)

11. Analysis and Design Activity Overview 11 Architect Designer

12. Software Architect’s Responsibilities The Software Architect leads and coordinates technical activities and artifacts. 12 Architect Software Architecture Document Reference Architecture Analysis Model Design Model Deployment ModelImplementation Model

13. Designer’s Responsibilities The designer must know use-case modeling techniques, system requirements, and software design techniques. 13 Designer Use-Case Realization Package Class/Subsystems

14. Analysis and Design Is Use-Case Driven Use cases defined for a system are the basis for the entire development process. Benefits of use cases:  Concise, simple, and understandable by a wide range of stakeholders.  Help synchronize the content of different models. 14 Withdraw Money Check Balance Customer

15. What Is a Use-Case Realization? 15 Use-Case ModelDesign Model Use CaseUse-Case Realization Class Diagrams Use Case Communication Diagrams Sequence Diagrams

16. Analysis and Design in an Iterative Process 16 Iteration n Iteration n + 1 Use Case A Scenarios 1 & 2 Use-Case Realization A Start of iteration End of iteration Use Case B Scenario 1 Use-Case Realization A Use Case A Scenario 3 Use-Case Realization B

17. Review What is the purpose of the Analysis and Design Discipline? What are the input and output artifacts? Name and briefly describe the 4+1 Views of Architecture. What is the difference between Analysis and Design? What is architecture? 17

18. Architectural Analysis 18

19. Objectives: Architectural Analysis Explain the purpose of Architectural Analysis and where it is performed in the lifecycle. Describe a representative architectural pattern and set of analysis mechanisms, and how they affect the architecture. Describe the rationale and considerations that support the architectural decisions. Show how to read and interpret the results of Architectural Analysis:  Architectural layers and their relationships  Key abstractions  Analysis mechanisms 19

20. Architectural Analysis in Context 20 [Early Elaboration Iteration] [Inception Iteration (Optional)] Define a Candidate Architecture Perform Architectural Synthesis Analyze Behavior Refine the Architecture Design Components Design the Database (Optional) Architecture Analysis Architect

21. Architectural Analysis Overview 21 Supplementary Specification Glossary Use-Case Model Architectural Analysis Design Model Reference Architecture Deployment Model Vision Document Software Architecture Doc Project-Specific Guidelines

22. Architectural Analysis Steps Key Concepts Define the High-Level Organization of the model Identify Analysis mechanisms Identify Key Abstractions Create Use-Case Realizations Checkpoints 22

23. The “ 4+1 View ” Model Process ViewDeployment View Logical View Use-Case View Implementation View End-user Functionality Programmers Software management Performance, scalability, throughput System integrators System topology, delivery, installation, communication System engineering Analysts/Designers Structure

24. Review: What Is a Package? A package is a general-purpose mechanism for organizing elements into groups. It is a model element that can contain other model elements. A package can be used  To organize the model under development.  As a unit of configuration management. 24 University Artifacts

25. Package Relationships: Dependency Packages can be related to one another using a dependency relationship. Dependency Implications  Changes to the Supplier package may affect the Client package.  The Client package cannot be reused independently because it depends on the Supplier package. Client PackageSupplier Package Dependency relationship

26. Hierarchy should be acyclic Circular dependencies make it impossible to reuse one package without the other. Avoiding Circular Dependencies A B C A' C A B A B

27. Architectural Analysis Steps Key Concepts Define the High-Level Organization of the model Identify Analysis mechanisms Identify Key Abstractions Create Use-Case Realizations Checkpoints 27

28. Patterns and Frameworks Pattern  Provides a common solution to a common problem in a context Analysis/Design pattern  Provides a solution to a narrowly-scoped technical problem  Provides a fragment of a solution, or a piece of the puzzle Framework  Defines the general approach to solving the problem  Provides a skeletal solution, whose details may be Analysis/Design patterns 28

29. What Is a Design Pattern? A design pattern is a solution to a common design problem.  Describes a common design problem  Describes the solution to the problem  Discusses the results and trade-offs of applying the pattern Design patterns provide the capability to reuse successful designs. 29 Structural AspectBehavioral Aspect Parameterized Collaboration Pattern Name Template Parameters

30. What Is an Architectural Pattern? An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them – Buschman et al, “Pattern-Oriented Software Architecture — A System of Patterns”  Layers  Model-view-controller (M-V-C)  Pipes and filters  Blackboard 30

31. Typical Layering Approach 31 General functionality Specific functionality Distinct application subsystems that make up an application — contains the value adding software developed by the organization. Business specific — contains a number of reusable subsystems specific to the type of business. Middleware — offers subsystems for utility classes and platform-independent services for distributed object computing in heterogeneous environments and so on. System software — contains the software for the actual infrastructure such as operating systems, interfaces to specific hardware, device drivers, and so on. Application Business-Specific Middleware System Software

32. Example: Layers 32 ApplicationPresentationSessionTransportNetworkData LinkPhysical Layer 7 Layer 6 Layer 5 Layer 4 Layer 3 Layer 2 Layer 1 Provides miscellaneous protocols for common activities Structure information and attaches semantics Provides dialog control and synchronization facilities Breaks messages into packets and guarantees delivery Selects a route from send to receiver Detects and corrects errors in bit sequences Transmits bits: velocity, bit-code, connection, etc.

33. Layering Considerations Level of abstraction  Group elements at the same level of abstraction Separation of concerns  Group like things together  Separate disparate things  Application vs. domain model elements Resiliency  Loose coupling  Concentrate on encapsulating change  User interface, business rules, and retained data tend to have a high potential for change 33

34. Modeling Architectural Layers Architectural layers can be modeled using stereotyped packages. > stereotype 34 Package Name >

35. What Are Stereotypes? Stereotypes define a new model element in terms of another model element. Sometimes you need to introduce new things that speak the language of your domain and look like primitive building blocks. 35 Class > Stereotype

36. High-Level Organization of the Model 36 Application > Business Services >

37. Architectural Analysis Steps Key Concepts Define the High-Level Organization of the model Identify Analysis mechanisms Identify Key Abstractions Create Use-Case Realizations Checkpoints 37

38. What Are Architectural Mechanisms? 38 Required Functionality Implementation Environment Architect Supplementary Specification Use-Case Model Mechanisms COTS Products Databases IPC Technology, etc. “realized by client classes using” “responsible for” “constrained by”

39. Architectural Mechanisms: Three Categories Architectural Mechanism Categories  Analysis mechanisms (conceptual)  Design mechanisms (concrete)  Implementation mechanisms (actual) 39

40. Why Use Analysis Mechanisms? 40 Oh no! I found a group of classes that has persistent data. How am I supposed to design these things if I don’t even know what database we are going to be using? That is why we have a persistence analysis mechanism. We don’t know enough yet, so we can bookmark it and come back to it later. Analysis mechanisms are used during analysis to reduce the complexity of analysis and to improve its consistency by providing designers with a shorthand representation for complex behavior.

41. Sample Analysis Mechanisms Persistency Communication (IPC and RPC) Message routing Distribution Transaction management Process control and synchronization (resource contention) Information exchange, format conversion Security Error detection / handling / reporting Redundancy Legacy Interface 41

42. Examples of Analysis Mechanism Characteristics Persistency mechanism  Granularity  Volume  Duration  Access mechanism  Access frequency (creation/deletion, update, read)  Reliability Inter-process Communication mechanism  Latency  Synchronicity  Message size  Protocol 42

43. Example: Analysis Mechanism Characteristics Legacy interface mechanism  Latency  Duration  Access mechanism  Access frequency Security mechanism  Data granularity  User granularity  Security rules  Privilege types Others 43

44. Describing Analysis Mechanisms Collect all analysis mechanisms in a list Draw a map of classes to analysis mechanisms Identify characteristics of analysis mechanisms Model using collaborations 44 Classes Parsing Authentication Communication Persistency Analysis Mechanisms Flight Aircraft Mission Schedule Route Load

45. Example: Course Registration Analysis Mechanisms 45 SecurityLegacy Interface PersistenceDistribution

46. Architectural Analysis Steps Key Concepts Define the High-Level Organization of the model Identify Analysis mechanisms Identify Key Abstractions Create Use-Case Realizations Checkpoints 46

47. What Are Key Abstractions? A key abstraction is a concept, normally uncovered in Requirements, that the system must be able to handle Sources for key abstractions  Domain knowledge  Requirements  Glossary  Domain Model, or the Business Model (if one exists) 47

48. Defining Key Abstractions Define analysis classes Model analysis classes and relationships on class diagrams  Include a brief description of an analysis class Map analysis classes to necessary analysis mechanisms 48

49. Example: Key Abstractions 49 Student Professor ScheduleCourseCatalogCourseCourseOffering

50. Architectural Analysis Steps Key Concepts Define the High-Level Organization of the model Identify Analysis mechanisms Identify Key Abstractions Create Use-Case Realizations Checkpoints 50

51. What Is a Use-Case Realization? 51 Use-Case ModelDesign Model Use CaseUse-Case Realization Class Diagrams Use Case Communication Diagrams Sequence Diagrams

52. The Value of Use-Case Realizations Provides traceability from Analysis and Design back to Requirements The Architect creates the Use-Case Realization 52 Use Case Analysis & Design (Design Model) Requirements (Use-Case Model) Use-Case realization

53. Architectural Analysis Steps Key Concepts Define the High-Level Organization of the model Identify Analysis mechanisms Identify Key Abstractions Create Use-Case Realizations Checkpoints 53

54. Checkpoints General  Is the package partitioning and layering done in a logically consistent way?  Have the necessary analysis mechanisms been identified? Packages  Have we provided a comprehensive picture of the services of the packages in upper-level layers? 54

55. Checkpoints (continued) Classes  Have the key entity classes and their relationships been identified and accurately modeled?  Does the name of each class clearly reflect the role it plays?  Are the key abstractions/classes and their relationships consistent with the Business Model, Domain Model, Requirements, Glossary, etc.? 55

56. Review: Architectural Analysis What is the purpose of Architectural Analysis? What is a package? What is a layered architecture? Give examples of typical layers. What are analysis mechanisms? Give examples. What key abstractions are identified during Architectural Analysis? Why are they identified here? 56

57. Exercise: Architectural Analysis Given the following:  Some results from the Requirements discipline: (Exercise Workbook: Payroll Requirements) Problem statement Use-Case Model main diagram Glossary  Some architectural decisions: (Exercise Workbook: Payroll Architecture Handbook, Logical View, Architectural Analysis) (textually) The upper-level architectural layers and their dependencies 57

58. Exercise: Architectural Analysis (continued) Identify the following:  The key abstractions 58

59. Exercise: Architectural Analysis (continued) Produce the following:  Class diagram containing the key abstractions  Class diagram containing the upper-level architectural layers and their dependencies 59

60. Exercise: Review Compare your key abstractions with the rest of the class  Have the key concepts been identified?  Does the name of each class reflect the role it plays? Compare your class diagram showing the upper-level layers  Do the package relationships support the Payroll System architecture? 60