Object Oriented Analysis and Design Using the UML

1. Object Oriented Analysis and Design Using the UML Analysis and Design Overview

2. Objectives: Analysis and Design Overview • Review the key analysis and design terms and concepts • Introduce the analysis and design process, including roles, artifacts and workflow • Understand the difference between analysis and design • Note that the details of each of the Analysis and Design activities will be covered later. • Present a context for the detailed analysis and design activities.

3. Analysis and Design in Context Inception Elaboration Construction Transition Requirements Analysis & Design Test Configuration & Change Mgmt Management Environment Preliminary Iteration(s) Iter.#1 Iter.#2 Iter.#n Iter.#n+1 Iter.#n+2 Iter.#m Iter.#m+1 • The purposes of Analysis and Design are: • To transform the requirements into a design of the system to-be. • To evolve a robust architecture for the system. Note: Analysis and Design taken ‘together.’ WHY????? Olden days versus Modern Times…..

4. Use-Case Model Analysis and Design Design Model Supplementary Specification Architecture Document Glossary Data Model Analysis and Design Overview Input Artifacts – from Requirements Workflow Ultimately, we wish to produce a Design Model

5. Analysis and Design Overview (continued) • Design model is an abstraction of source code and serves as the blue print for Construction. • Design Model consists of Design Classes structured into Design packages • Design Model also contains descriptions as to how objects of these design classes interact to perform Use Cases (Use Case Realizations) • Class diagrams and • Interaction Diagrams do this for us…

6. Analysis and Design Overview (continued) • Design activities are centered around the notion of an architecture. • Production and validation of this architecture is the main focus of early design iterations. • Architecture is represented by a number of architectural views that capture the major structural design decisions. • Architectural views are the abstractions or simplifications of the entire design, in which important characteristics are made more visible by leaving details aside.

7. Analysis and Design Overview (continued) • We will create an Analysis Model as the first part of Analysis and Design. • We create Analysis Classes from Use Cases • Our Design Model will take the artifacts from Analysis Modeling (analysis classes) and create • Design classes and (static) • Use Cases realizations – showing how objects collaborate in ‘realizing’ each use case. (dynamic)

8. Analysis & Design Overview Topics • Key Concepts – Get a common vocabulary • Analysis & Design Workflow Overview

9. Analysis Focus on understanding the problem Idealized design Behavior System structure Functional requirements A small model Design Focus on understanding the solution Operations and Attributes Performance Close to real code Object lifecycles Non-functional requirements A large model Analysis Versus Design Difference is on emphases Analysis: understanding the problem; develop a visual model of What you are trying to build

10. Goal of Analysis • Understand the problem; try to build a visual model of what you are trying to do independent of implementation or technology concerns. • Focus on translating the functional requirements into software concepts • Nothing in Use Cases says ‘Objects.’ • We are capturing Requirements! • Get rough cut at objects that from our system but focusing on behavior and therefore encapsulation.

11. Goal of Design • Refine Analysis Model with a goal of creating a Design Model that will facilitate our moving “quickly and seamlessly” into coding. (Morph Analysis Classes into Design classes and more!) • Design Model will help us adapt to implementation (and deployment) environments.

12. Analysis  Design  Solution • In modeling, we will start with an object model that resembles the real world (analysis) then, • Find more abstract (but more fundamental) solutions to a more general problem (design)

13. Analysis and Design is not Top-Down or Bottom-Up Use cases come in from the left and define a middle level Analysis Classes are not defined in a top-down or bottom-up pattern; they are in the middle . Top Down Subsystems Bottom Up Use Cases Defining Subsystems is moving ‘up;’ defining design classes is moving down. Must travel all paths to get system right. Analysis Classes Design Classes

14. Design Model • A Use Case Realization describes how a particular use case is implemented in the design model in terms of collaborating objects. • In the RUP, each use case has a use case realization!! • A Use-Case Realization ties use cases from the use-case model and ‘analysis classes’ to design classes and related design entities and relationships of a design model. • A Use-Case Realization specifies what classes must be built to implementeach use case. • In the UML, use-case realizations are stereotyped collaborations. The symbol for a collaboration is an ellipsis containing the name of the collaboration. (next)

15. Use-Case Model Design Model Class Diagrams Collaboration Diagrams Sequence Diagrams Use Case Use-Case Realization What is a Use-Case Realization? A use-case realization in the design model can be traced to a use case in the use-case model. A “realization relationship” is drawn from the use-case realization to the use case it “realizes.” Use Case A use case realization can be represented using a set of diagrams which model the context of the collaboration – class diagrams,and the interactions of these collaborations – collaboration and sequence diagrams.

16. End-user Functionality System integrators Performance Scalability Throughput Software Architecture: The “4+1 View” Model LogicalView Implementation View Analysts/Designers Structure Programmers Software management Use-Case View Process View Deployment View System engineering System topology Delivery, installation communication This diagram describes how Rational Software Corporation models software architecture Projects have multiple stakeholders – each with unique concerns and views. Rational has defined the 4+1 architectural model – a series of simplified descriptions (abstractions) from particular perspectives – omitting entities not relevant to this view. A project may document all views, a subset, or additional views. But EACH VIEW is complete from the perspective of specific stakeholder(s).

17. Analysis & Design Overview Topics • Key Concepts • Analysis & Design Workflow Overview

18. Architectural Analysis Review the Architecture Describe Architectural Describe Architecture Reviewer Architect Concurrency Design Distribution Subsystem Design Use-Case Analysis Review the Use-Case Design Design Design Designer Reviewer Class Design Analysis and Design Workflow Remember, we start off with the Use Case Model and supplementary info (Glossary; Domain model; business model…) from Requirements Workflow and ultimately end up with a Design Model – an abstraction of the source code. Design activities center around architecture – the main focus of early design iterations. We here, however, will concentrate on the activities of the Designer.

19. The Architect (very briefly) Establishes the overall structure for each architectural view: • the decomposition of the view, • the grouping of elements, and the interfaces between these major groupings. • In contrast with the other workers, the Architect's view is one of breadth, as opposed to depth

20. The Designer (briefly) • Defines the responsibilities, operations, attributes, and relationships of one or several classes and determines how they should be adjusted (modified, refined, morphed into other design / implementation artifacts (like packages, subsystems, etc.)) to support the implementation environment. • Is usually responsible for Use-Case Realizations, in order to ensure the overall consistency of how a particular use case is realized using design elements.

21. The Database Designer (briefly) • Defines the tables, indexes, views, constraints, triggers, stored procedures, table spaces or storage parameters, and other database-specific constructs needed to store, retrieve, and delete persistent objects. • This information is maintained in the Data Model.

22. Reviewers • Architecture Reviewer plans and conducts the formal reviews of the software architecture in general. • The Design reviewer plans and conducts the formal reviews of the design model.

23. Design Model Database Designer Architecture Reviewer Design Reviewer Architect Designer Software Architecture Document Use-Case Realization Data Model Workers and Their Responsibilities Architect: Establishes overall structure of each of the views. Decomposition; Breadth Package/Subsystem Class DB Designer: Designs tables, stored procs Indexes, etc. needed to store, maintain persistent data Designer: Responsible for the operations, attributes, and relationships of one or several classes and how they are implemented; Design packages; UC Realizations

24. Review: Analysis and Design Overview • What is the purpose of Analysis and Design? • 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 the purpose of Architectural Analysis? • What is the purpose of Use-Case Analysis? • What are the major responsibilities of the Architect, Developer, Database workers?