Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

3 analysis and design overview

2,824 views

Published on

Published in: Technology, News & Politics
  • Login to see the comments

3 analysis and design overview

  1. 1. Analysis and Design Overview 10/03/11
  2. 2. Objectives <ul><li>Review the key Analysis and Design terms and concepts </li></ul><ul><li>Introduce the Analysis and Design process, including roles, artifacts and workflow </li></ul><ul><li>Explain the difference between Analysis and Design </li></ul>
  3. 3. Analysis and Design in Context <ul><li>The purposes of Analysis and Design are to: </li></ul><ul><li>Transform the requirements into a design of the system-to-be. </li></ul><ul><li>Evolve a robust architecture for the system. </li></ul><ul><li>Adapt the design to match the implementation environment, designing it for performance. </li></ul>
  4. 4. Analysis and Design Overview Supplementary Specification Use-Case Model Design Model Data Model Architecture Document Analysis and Design Glossary
  5. 5. Analysis Versus Design WHAT? HOW? Analysis Design <ul><ul><li>Focus on understanding the problem </li></ul></ul><ul><ul><li>Idealized design </li></ul></ul><ul><ul><li>Behavior </li></ul></ul><ul><ul><li>System structure </li></ul></ul><ul><ul><li>Functional requirements </li></ul></ul><ul><ul><li>A small model </li></ul></ul><ul><ul><li>Focus on understanding the solution </li></ul></ul><ul><ul><li>Operations and attributes </li></ul></ul><ul><ul><li>Performance </li></ul></ul><ul><ul><li>Close to real code </li></ul></ul><ul><ul><li>Object lifecycles </li></ul></ul><ul><ul><li>Nonfunctional requirements </li></ul></ul><ul><ul><li>A large model </li></ul></ul>
  6. 6. Analysis and Design Are Not Top-Down or Bottom-Up Bottom Up Top Down Design Classes Subsystems Use Cases Analysis Classes (Define a middle level) Analysis and Design
  7. 7. What Is Architecture? <ul><li>Software architecture encompasses a set of significant decisions about the organization of a software system. </li></ul><ul><ul><li>Selection of the structural elements and their interfaces by which a system is composed </li></ul></ul><ul><ul><li>Behavior as specified in collaborations among those elements </li></ul></ul><ul><ul><li>Composition of these structural and behavioral elements into larger subsystems </li></ul></ul><ul><ul><li>Architectural style that guides this organization </li></ul></ul>Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational (derived from Mary Shaw)
  8. 8. Architecture Constrains Design and Implementation <ul><li>Architecture involves a set of strategic design decisions, rules or patterns that constrain design and construction. </li></ul>Architecture decisions are the most fundamental decisions, and changing them will have significant effects. Architecture Design Implementation Code
  9. 9. Software Architecture: The “4+1 View” Model Process View Deployment 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. 10. Analysis and Design Workflow 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. 11. Analysis and Design Activity Overview Architect Designer
  12. 12. Software Architect’s Responsibilities <ul><li>The Software Architect leads and coordinates technical activities and artifacts. </li></ul>Architect Software Architecture Document Reference Architecture Analysis Model Design Model Deployment Model Implementation Model
  13. 13. Designer’s Responsibilities <ul><li>The designer must know use-case modeling techniques, system requirements, and software design techniques. </li></ul>Designer Use-Case Realization Package Class/Subsystems
  14. 14. Analysis and Design Is Use-Case Driven <ul><li>Use cases defined for a system are the basis for the entire development process. </li></ul><ul><li>Benefits of use cases: </li></ul><ul><ul><li>Concise, simple, and understandable by a wide range of stakeholders. </li></ul></ul><ul><ul><li>Help synchronize the content of different models. </li></ul></ul>Withdraw Money Check Balance Customer
  15. 15. What Is a Use-Case Realization? Use-Case Model Design Model Use Case Use-Case Realization Class Diagrams Use Case Communication Diagrams Sequence Diagrams
  16. 16. Analysis and Design in an Iterative Process 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. 17. Review <ul><li>What is the purpose of the Analysis and Design Discipline? </li></ul><ul><li>What are the input and output artifacts? </li></ul><ul><li>Name and briefly describe the 4+1 Views of Architecture. </li></ul><ul><li>What is the difference between Analysis and Design? </li></ul><ul><li>What is architecture? </li></ul>
  18. 18. Architectural Analysis
  19. 19. Objectives: Architectural Analysis <ul><li>Explain the purpose of Architectural Analysis and where it is performed in the lifecycle. </li></ul><ul><li>Describe a representative architectural pattern and set of analysis mechanisms, and how they affect the architecture. </li></ul><ul><li>Describe the rationale and considerations that support the architectural decisions. </li></ul><ul><li>Show how to read and interpret the results of Architectural Analysis: </li></ul><ul><ul><li>Architectural layers and their relationships </li></ul></ul><ul><ul><li>Key abstractions </li></ul></ul><ul><ul><li>Analysis mechanisms </li></ul></ul>
  20. 20. Architectural Analysis in Context [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. 21. Architectural Analysis Overview Supplementary Specification Glossary Use-Case Model Architectural Analysis Design Model Reference Architecture Deployment Model Vision Document Software Architecture Doc Project-Specific Guidelines
  22. 22. Architectural Analysis Steps <ul><li>Key Concepts </li></ul><ul><li>Define the High-Level Organization of the model </li></ul><ul><li>Identify Analysis mechanisms </li></ul><ul><li>Identify Key Abstractions </li></ul><ul><li>Create Use-Case Realizations </li></ul><ul><li>Checkpoints </li></ul>
  23. 23. The “ 4+1 View ” Model Process View Deployment 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. 24. Review: What Is a Package? <ul><li>A package is a general-purpose mechanism for organizing elements into groups. </li></ul><ul><li>It is a model element that can contain other model elements. </li></ul><ul><li>A package can be used </li></ul><ul><ul><li>To organize the model under development. </li></ul></ul><ul><ul><li>As a unit of configuration management. </li></ul></ul>University Artifacts
  25. 25. Package Relationships: Dependency <ul><li>Packages can be related to one another using a dependency relationship. </li></ul><ul><li>Dependency Implications </li></ul><ul><ul><li>Changes to the Supplier package may affect the Client package. </li></ul></ul><ul><ul><li>The Client package cannot be reused independently because it depends on the Supplier package. </li></ul></ul>Dependency relationship Client Package Supplier Package
  26. 26. Avoiding Circular Dependencies Hierarchy should be acyclic Circular dependencies make it impossible to reuse one package without the other. A B C A' C A B A B
  27. 27. Architectural Analysis Steps <ul><li>Key Concepts </li></ul><ul><li>Define the High-Level Organization of the model </li></ul><ul><li>Identify Analysis mechanisms </li></ul><ul><li>Identify Key Abstractions </li></ul><ul><li>Create Use-Case Realizations </li></ul><ul><li>Checkpoints </li></ul>
  28. 28. Patterns and Frameworks <ul><li>Pattern </li></ul><ul><ul><li>Provides a common solution to a common problem in a context </li></ul></ul><ul><li>Analysis/Design pattern </li></ul><ul><ul><li>Provides a solution to a narrowly-scoped technical problem </li></ul></ul><ul><ul><li>Provides a fragment of a solution, or a piece of the puzzle </li></ul></ul><ul><li>Framework </li></ul><ul><ul><li>Defines the general approach to solving the problem </li></ul></ul><ul><ul><li>Provides a skeletal solution, whose </li></ul></ul><ul><ul><li>details may be Analysis/Design patterns </li></ul></ul>
  29. 29. What Is a Design Pattern? <ul><li>A design pattern is a solution to a common design problem. </li></ul><ul><ul><li>Describes a common design problem </li></ul></ul><ul><ul><li>Describes the solution to the problem </li></ul></ul><ul><ul><li>Discusses the results and trade-offs of applying the pattern </li></ul></ul><ul><li>Design patterns provide the capability to reuse successful designs. </li></ul>Structural Aspect Behavioral Aspect Parameterized Collaboration Pattern Name Template Parameters
  30. 30. What Is an Architectural Pattern? <ul><li>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 ” </li></ul><ul><ul><li>Layers </li></ul></ul><ul><ul><li>Model-view-controller (M-V-C) </li></ul></ul><ul><ul><li>Pipes and filters </li></ul></ul><ul><ul><li>Blackboard </li></ul></ul>
  31. 31. Typical Layering Approach 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. 32. Example: Layers 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. Application Presentation Session Transport Network Data Link Physical
  33. 33. Layering Considerations <ul><li>Level of abstraction </li></ul><ul><ul><li>Group elements at the same level of abstraction </li></ul></ul><ul><li>Separation of concerns </li></ul><ul><ul><li>Group like things together </li></ul></ul><ul><ul><li>Separate disparate things </li></ul></ul><ul><ul><li>Application vs. domain model elements </li></ul></ul><ul><li>Resiliency </li></ul><ul><ul><li>Loose coupling </li></ul></ul><ul><ul><li>Concentrate on encapsulating change </li></ul></ul><ul><ul><li>User interface, business rules, and retained data tend to have a high potential for change </li></ul></ul>
  34. 34. Modeling Architectural Layers <ul><li>Architectural layers can be modeled using stereotyped packages. </li></ul><ul><li><<layer>> stereotype </li></ul>Package Name <<layer>>
  35. 35. What Are Stereotypes? <ul><li>Stereotypes define a new model element in terms of another model element. </li></ul><ul><li>Sometimes you need to introduce new things that speak the language of your domain and look like primitive building blocks. </li></ul>Class <<stereotypename>> Stereotype
  36. 36. High-Level Organization of the Model Application <<layer>> Business Services <<layer>>
  37. 37. Architectural Analysis Steps <ul><li>Key Concepts </li></ul><ul><li>Define the High-Level Organization of the model </li></ul><ul><li>Identify Analysis mechanisms </li></ul><ul><li>Identify Key Abstractions </li></ul><ul><li>Create Use-Case Realizations </li></ul><ul><li>Checkpoints </li></ul>
  38. 38. What Are Architectural Mechanisms? 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. 39. Architectural Mechanisms: Three Categories <ul><li>Architectural Mechanism Categories </li></ul><ul><ul><li>Analysis mechanisms (conceptual) </li></ul></ul><ul><ul><li>Design mechanisms (concrete) </li></ul></ul><ul><ul><li>Implementation mechanisms (actual) </li></ul></ul>
  40. 40. Why Use Analysis Mechanisms? 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. 41. Sample Analysis Mechanisms <ul><li>Persistency </li></ul><ul><li>Communication (IPC and RPC) </li></ul><ul><li>Message routing </li></ul><ul><li>Distribution </li></ul><ul><li>Transaction management </li></ul><ul><li>Process control and synchronization (resource contention) </li></ul><ul><li>Information exchange, format conversion </li></ul><ul><li>Security </li></ul><ul><li>Error detection / handling / reporting </li></ul><ul><li>Redundancy </li></ul><ul><li>Legacy Interface </li></ul>
  42. 42. Examples of Analysis Mechanism Characteristics <ul><li>Persistency mechanism </li></ul><ul><ul><li>Granularity </li></ul></ul><ul><ul><li>Volume </li></ul></ul><ul><ul><li>Duration </li></ul></ul><ul><ul><li>Access mechanism </li></ul></ul><ul><ul><li>Access frequency (creation/deletion, update, read) </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><li>Inter-process Communication mechanism </li></ul><ul><ul><li>Latency </li></ul></ul><ul><ul><li>Synchronicity </li></ul></ul><ul><ul><li>Message size </li></ul></ul><ul><ul><li>Protocol </li></ul></ul>
  43. 43. Example: Analysis Mechanism Characteristics <ul><li>Legacy interface mechanism </li></ul><ul><ul><li>Latency </li></ul></ul><ul><ul><li>Duration </li></ul></ul><ul><ul><li>Access mechanism </li></ul></ul><ul><ul><li>Access frequency </li></ul></ul><ul><li>Security mechanism </li></ul><ul><ul><li>Data granularity </li></ul></ul><ul><ul><li>User granularity </li></ul></ul><ul><ul><li>Security rules </li></ul></ul><ul><ul><li>Privilege types </li></ul></ul><ul><li>Others </li></ul>
  44. 44. Describing Analysis Mechanisms <ul><li>Collect all analysis mechanisms in a list </li></ul><ul><li>Draw a map of classes to analysis mechanisms </li></ul><ul><li>Identify characteristics of analysis mechanisms </li></ul><ul><li>Model using collaborations </li></ul>Classes Parsing Authentication Communication Persistency Analysis Mechanisms Flight Aircraft Mission Schedule Route Load
  45. 45. Example: Course Registration Analysis Mechanisms Security Legacy Interface Persistence Distribution
  46. 46. Architectural Analysis Steps <ul><li>Key Concepts </li></ul><ul><li>Define the High-Level Organization of the model </li></ul><ul><li>Identify Analysis mechanisms </li></ul><ul><li>Identify Key Abstractions </li></ul><ul><li>Create Use-Case Realizations </li></ul><ul><li>Checkpoints </li></ul>
  47. 47. What Are Key Abstractions? <ul><li>A key abstraction is a concept, normally uncovered in Requirements, that the system must be able to handle </li></ul><ul><li>Sources for key abstractions </li></ul><ul><ul><li>Domain knowledge </li></ul></ul><ul><ul><li>Requirements </li></ul></ul><ul><ul><li>Glossary </li></ul></ul><ul><ul><li>Domain Model, or the Business Model (if one exists) </li></ul></ul>
  48. 48. Defining Key Abstractions <ul><li>Define analysis classes </li></ul><ul><li>Model analysis classes and relationships on class diagrams </li></ul><ul><ul><li>Include a brief description of an analysis class </li></ul></ul><ul><li>Map analysis classes to necessary analysis mechanisms </li></ul>
  49. 49. Example: Key Abstractions Student Professor Schedule CourseCatalog Course CourseOffering
  50. 50. Architectural Analysis Steps <ul><li>Key Concepts </li></ul><ul><li>Define the High-Level Organization of the model </li></ul><ul><li>Identify Analysis mechanisms </li></ul><ul><li>Identify Key Abstractions </li></ul><ul><li>Create Use-Case Realizations </li></ul><ul><li>Checkpoints </li></ul>
  51. 51. What Is a Use-Case Realization? Use-Case Model Design Model Use Case Use-Case Realization Class Diagrams Use Case Communication Diagrams Sequence Diagrams
  52. 52. The Value of Use-Case Realizations <ul><li>Provides traceability from Analysis and Design back to Requirements </li></ul><ul><li>The Architect creates the Use-Case Realization </li></ul>Analysis & Design (Design Model) Requirements (Use-Case Model) Use-Case realization Use Case
  53. 53. Architectural Analysis Steps <ul><li>Key Concepts </li></ul><ul><li>Define the High-Level Organization of the model </li></ul><ul><li>Identify Analysis mechanisms </li></ul><ul><li>Identify Key Abstractions </li></ul><ul><li>Create Use-Case Realizations </li></ul><ul><li>Checkpoints </li></ul>
  54. 54. Checkpoints <ul><li>General </li></ul><ul><ul><li>Is the package partitioning and layering done in a logically consistent way? </li></ul></ul><ul><ul><li>Have the necessary analysis mechanisms been identified? </li></ul></ul><ul><li>Packages </li></ul><ul><ul><li>Have we provided a comprehensive picture of the services of the packages in upper-level layers? </li></ul></ul>
  55. 55. Checkpoints (continued) <ul><li>Classes </li></ul><ul><ul><li>Have the key entity classes and their relationships been identified and accurately modeled? </li></ul></ul><ul><ul><li>Does the name of each class clearly reflect the role it plays? </li></ul></ul><ul><ul><li>Are the key abstractions/classes and their relationships consistent with the Business Model, Domain Model, Requirements, Glossary, etc.? </li></ul></ul>
  56. 56. Review: Architectural Analysis <ul><li>What is the purpose of Architectural Analysis? </li></ul><ul><li>What is a package? </li></ul><ul><li>What is a layered architecture? Give examples of typical layers. </li></ul><ul><li>What are analysis mechanisms? Give examples. </li></ul><ul><li>What key abstractions are identified during Architectural Analysis? Why are they identified here? </li></ul>
  57. 57. Exercise: Architectural Analysis <ul><li>Given the following: </li></ul><ul><ul><li>Some results from the Requirements discipline: (Exercise Workbook: Payroll Requirements) </li></ul></ul><ul><ul><ul><li>Problem statement </li></ul></ul></ul><ul><ul><ul><li>Use-Case Model main diagram </li></ul></ul></ul><ul><ul><ul><li>Glossary </li></ul></ul></ul><ul><ul><li>Some architectural decisions: (Exercise Workbook: Payroll Architecture Handbook, Logical View, Architectural Analysis) </li></ul></ul><ul><ul><ul><li>(textually) The upper-level architectural layers and their dependencies </li></ul></ul></ul>
  58. 58. Exercise: Architectural Analysis (continued) <ul><li>Identify the following: </li></ul><ul><ul><li>The key abstractions </li></ul></ul>
  59. 59. Exercise: Architectural Analysis (continued) <ul><li>Produce the following: </li></ul><ul><ul><li>Class diagram containing the key abstractions </li></ul></ul><ul><ul><li>Class diagram containing the upper-level architectural layers and their dependencies </li></ul></ul>
  60. 60. Exercise: Review <ul><li>Compare your key abstractions with the rest of the class </li></ul><ul><ul><li>Have the key concepts been identified? </li></ul></ul><ul><ul><li>Does the name of each class reflect the role it plays? </li></ul></ul><ul><li>Compare your class diagram showing the upper-level layers </li></ul><ul><ul><li>Do the package relationships support the Payroll System architecture? </li></ul></ul>

×