Object-Oriented Analysis

About This Course

Introductions 
Your organization  Your role  Your background, experience 
Object Technology experience  Software Development experience 

Course expectations

Intended Audience and Prerequisites 
Intended Audience 
Software developers who are making the paradigm shift to object technology  Software managers who need to better understand object technology to be more effective leaders  Data modelers who need to better communicate with object modelers 

Prerequisite 
A desire to learn about object technology

Course Objectives 
After completing this course, you will be able to 
Define the Best Practices of Software Engineering.  Model system behavior with use cases.  Demonstrate the differences between analysis and design.  Identify classes, objects, associations and show how to create simple interaction and class diagrams.  Produce a class diagram with analysis classes and their stereotypes.

Rational University Curriculum
Fundamentals of Visual Modeling

Object-Oriented Analysis

Rose Fundamentals

Object-Oriented Design

Database Design with Rational Rose

Object-Oriented Analysis
Modeling System Behavior with Use Cases

 Recognize a use-case specification.  Identify use cases from a problem statement.  Demonstrate how to create a use-case diagram that accurately models the system. and supplementary specification document.Objectives  Identify actors from a problem statement. glossary. .

Where Are We?  Introduction to Requirements  Key Concepts  Use-Case Model  Other Requirements Artifacts  Checkpoints .

‡ Provide a better understanding of the system requirements. ‡ Provide a basis for estimating cost. . ‡ Define a user-interface for the system. ‡ Provide a basis for planning the technical contents of iterations. ‡ Define the boundaries of the system.The Purpose of the Requirements Discipline  The Requirements discipline intends to: ‡ Find agreement on what the system should do.

Requirements in Context .

..Relevant Requirements Artifacts Use-Case Model Glossary Actors Use Cases . Supplementary Specification Use-Case Specifications .

Case Study: Course Registration Problem Statement  Review the problem statement provided in the Course Registration Requirements Document .

Where Are We?  Introduction to Requirements  Key Concepts  Use-Case Model  Other Requirements Artifacts  Checkpoints .

. its environment.  It is an outwardly visible and testable activity of a system.  Use cases describe the system.  System behavior is captured in use cases. and the relationship between the system and its environment.What Is System Behavior?  System behavior is how a system acts and reacts.

 A use case defines a set of use-case instances. where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor. Actor Use Case .ajor Concepts in Use-Case Modeling  An actor represents anything that interacts with the system.

Where Are We?  Introduction to Requirements  Key Concepts  Use-Case Model  Other Requirements Artifacts  Checkpoints .

Review: What Is a Use-Case Model?  A model that describes a system¶s functional requirements in terms of use cases.  A model of the system¶s intended functionality (use cases) and its environment (actors). View Report Card Student Register for Courses Login .

Review: What Are the Benefits of Use-Case Models?  Used to communicate with the end users and domain experts  Provides buy-in at an early stage of system development  Insures a mutual understanding of the requirements  Used to identify  Who interacts with the system and what the system should do  The interfaces the system should have  Used to verify  All requirements have been captured  The development team understands the requirements .

Useful Questions in Finding Actors  Who will supply. or remove information?  Who will use this functionality?  Who is interested in a certain requirement?  Where in the organization is the system used?  Who will support and maintain the system?  What are the system¶s external resources?  What other systems will need to interact with this one? Actor . use.

or another system can play.Focus on the Roles  An actor represents a role that a human. hardware device. ? .

A User May Have Different Roles Charlie as Professor Professor Charlie Charlie as Student Student .

such as system administration  External hardware that the system uses  Other systems interacting with the system .System Surroundings and Actors  Users who execute the system¶s  Main functions  Secondary functions.

Name and Describe Each Actor  Actor names should clearly denote the actor¶s role  Actor description:  Area of responsibility  Dependency of the actor on the system .

read the Problem Statement for the Course Registration case study.  As a group.Practice: Find the Actors  In the Course Registration System Requirements document. identify the following:  Actors  Description of the actor .

Practice: Solution The external system responsible for student billing Student Billing System A person who is registered to take courses at the University The unabridged catalog of all courses offered by the University A person who is teaching classes at the University Professor Course Catalog Registrar The person who is responsible for the maintenance of the course registration system .

Finding Use Cases: Focus on the Actor  The system exists only for its users  Use cases should be based on the user¶s needs .

 For each actor you have identified. what are the tasks the system would be involved in?  Does the actor need to be informed about certain occurrences in the system?  Will the actor need to inform the system about sudden. external changes?  What information must be modified or created in the system? .Useful Questions in Finding Use Cases  Answer the following questions to find use cases.

 No two use cases should have the same name. Register for Courses Login Maintain Student Information .Naming the Use Case  The name indicates what is achieved by its interactions with the actor(s).  The name may be several words in length.

Practice: Finding Use Cases  In the Course Registration System Requirements document. identify the following:  Use Cases  Use-Case names . read the Problem Statement for the Course Registrations case study. using the actors identified in the earlier practice session.  As a group.

Practice: Solution Register for Courses View Report Card Login Select Courses To Teach Submit Grades Maintain Professor Information Maintain Student Information Close Registration .

Use Cases and Actors 
A use case models a dialog between actors and the system.  A use case is initiated by an actor to invoke a certain functionality in the system.

Concept: Communicate-Association 
Use cases and actors interact by sending signals to one another.  To indicate such interactions, use a communicate-association.

Actor
Communicate-Association

Use Case

Practice: Use Case and Actor Communication 
In the Course Registrations System Requirements document, read the Problem Statement for the Course Registration case study.  As a group, using the actors and use cases identified in the earlier practice session, identify: 
Communicate-associations between the actors and the use cases.

Solution: Use Case and Actor Communication

View Report Card

Student Register for Courses Course Catalog Maintain Professor Information

Login
Maintain Student Information Select Courses to Teach Registrar Professor

Submit Grades

Close Registration

Billing System

Where Are We? 
Introduction to Requirements  Key Concepts  Use-Case Model  Other Requirements Artifacts  Checkpoints

Use-Case Specifications 
      Name Brief description Flows of Events Relationships Activity diagrams Use-Case diagrams Special requirements  Preconditions  Postconditions  Other diagrams
Use-Case Model

Actors Use Cases

...
Use-Case Specifications

Use Case Flow of Events  Has one normal. basic flow  Several alternative flows  Regular variants of the basic flow  Odd cases  Exceptional flows handling error situations .

What Are Scenarios ?  A scenario is an instance of a use case .

Glossary Course Registration System Glossary 1. . Includes the days of the week and times it is offered. Often. explaining terms.2 Course Offering: A specific delivery of the course for a specific semester ± you could run the same course in parallel sessions in the semester. which may be unfamiliar to the reader of the use-case descriptions or other project documents.3 Course Catalog: The unabridged catalog of all courses offered by the university. capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information. 2. Definitions The glossary contains the working definitions for the key concepts in the Course Registration System. 2. 2.1 Course: A class offered by the university. this document can be used as an informal data dictionary. Introduction This document is used to define terminology specific to the problem domain. Glossary 2.

Supplementary Specification  Functionality  Usability  Reliability  Performance  Supportability  Design constraints Supplementary Specification .

Course Registration System .Example: Glossary And Supplementary Specification  Review the Glossary and Supplementary Specification provided in the Course Registration Requirements Document.

Where Are We?  Introduction to Requirements  Key Concepts  Use-Case Model  Other Requirements Artifacts  Checkpoints .

Checkpoints: Use-Case Model  Is the use-case model understandable?  By studying the use-case model. can you form a clear idea of the system's functions and how they are related?  Have all functional requirements been met?  Does the use-case model contain any superfluous behavior?  Is the division of the model into usecase packages appropriate? .

Checkpoints: Actors  Have all the actors been identified?  Is each actor involved with at least one use case?  Is each actor really a role? Should any be merged or split?  Do two actors play the same role in relation to a use case?  Do the actors have intuitive and descriptive names? Can both users and customers understand the names? .

and explanatory names so that they cannot be mixed up at a later stage?  Do customers and users understand the names and descriptions of the use cases? . intuitive.Checkpoints: Use Cases  Is each use case involved with at least one actor?  Is each use case independent of the others?  Do any use cases have very similar behaviors or flows of events?  Do the use cases have unique.

Checkpoints: Use-Case Specifications  Is it clear who wishes to perform a use case?  Is the purpose of the use case also clear?  Does the brief description give a true picture of the use case?  Is it clear how and when the usecase's flow of events starts and ends?  Does the communication sequence between actor and use case conform to the user's expectations?  Are the actor interactions and exchanged information clear?  Are any use cases overly complex? .

Checkpoints: Glossary  Does each term have a clear and concise definition?  Is each glossary term included somewhere in the use-case descriptions?  Are terms used consistently in the brief descriptions of actors and use cases? .

Review  What are the main artifacts of Requirements?  What are the Requirements artifacts used for?  What is a use-case model?  What is an actor?  What is a use case? List examples of usecase properties.  What is the difference between a scenario and a use case? .

Exercise: System Behavior  Given the following  The Payroll System Problem Statement Continued« .

)  Identify for the Payroll System  Actors  Use cases  Name the use cases Continued«. .Exercise: System Behavior (cont.

 Provide:  Actor descriptions  Brief use-case descriptions .Exercise: System Behavior (cont.)  Produce the use-case model for the Payroll System.

Exercise: Review  Compare your results to other groups.  Are there differences? Why? How would you resolve these differences?  Compare the final model to the course solution.  Are there differences? Do you agree with the differences? Why? Payroll System .

Object-Oriented Analysis Module 3: Analysis and Design Overview .

artifacts and workflow for analysis and design  Define the difference between analysis and design  Explain the role of architecture in analysis and design  Describe the concept of use-case realization .Objectives  Define key analysis. design terms and concepts  Describe the roles.

Where Are We?  Analysis and Design Discipline Overview  Key Concepts .

Analysis and Design in Context The purposes of Analysis and Design are to: yTransform the requirements into a design of the system to be. yAdapt the design to match the implementation environment. designing it for performance. yEvolve a robust architecture for the system. .

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

Analysis and Design Discipline .

Architect Design Model Software Architecture Document .Role: Software Architect  The Software Architect leads and coordinates technical activities and artifacts.

Use-Case Realization Designer Package/ Subsystem Class . and software design techniques. system requirements.Role: Designer  The Designer must know use-case modeling techniques.

Analysis and Design Activity Overview .

Where Are We?  Analysis and Design Discipline Overview  Key Concepts .

Design Analysis Focuses on understanding the problem Idealized design Behavior Design Focuses on understanding the solution Close to real code Operations and attributes Object life cycles Nonfunctional requirements A large model Functional requirements A small model .Analysis vs.

Analysis and Design Is Not Top-Down or BottomUp Subsystems Top Down Use Cases Design Classes Bottom Up .

 Helps with component-based development.  Manages complexity and maintains system integrity. . managing. constructing.  Provides a basis for project management.  Provides an effective basis for large-scale reuse.  Benefits:  Intellectual control over projects.Review: Analysis and Design Is ArchitectureCentric  A system¶s architecture is a:  Primary artifact for conceptualizing. and evolving the system under development.

Rational (derived from Mary Shaw) . Rich Reitman. Philippe Kruchten.Concept: 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 the structural and behavioral elements into larger subsystems  Architectural style that guides the organization Grady Booch. Kurt Bittner.

rules or patterns that constrain design and construction architecture design implementation CODE Architecture decisions are the most fundamental decisions and changing them has significant ripple effects.Architecture Constrains  Architecture involves a set of strategic design decisions. .

installation communication .Software Architecture: The ³4+1 View´ Model Logical View End-user Functionality Implementation View Analysts/Designers Structure Programmers Software management Use-Case View Process View System integrators Performance Scalability Throughput Deployment View System engineering System topology Delivery.

and understandable by a wide range of stakeholders.  Help synchronize the content of different models. simple. Check Balance Customer Withdraw Money .Review: 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.

Concept: Use-Case Realization Use-Case Model Design Model Use Case Use-Case Realization Sequence Diagrams Collaboration Diagrams Use Case Class Diagrams .

The Value of Use-Case Realizations  Provides traceability from analysis and design back to requirements .

Review: Analysis and Design Is Iterative  Critical risks are resolved before making large investments.  Testing and integration are continuous.  Progress is measured by assessing implementations.  Initial iterations enable early user feedback. .  Partial implementations can be deployed.  Objective milestones focus on the short term.

Analysis and Design in an Iterative Process Start of iteration Use Case A Use Case B Use Case C End of iteration Use-Case Realization A Iteration n Use-Case Realization B Iteration n + 1 Use-Case Realization C Iteration n + 2 .

 What is the difference between Analysis and Design?  What is architecture? .Review  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.

Object-Oriented Analysis Module 4: Architectural Analysis .

 Describe how a representative architectural pattern and a set of analysis mechanisms affect the architecture.  Analysis mechanisms. .  Demonstrate how to read and interpret:  Architectural layers and their relationships.Objectives  Define the purpose of architectural analysis and show where it is performed in the lifecycle.  Key abstractions.

Architectural Analysis in Context Architectural Analysis Architect .

Architectural Analysis Overview Glossary Supplementary Specification Software Architecture Design Document Guidelines Architectural Analysis Use-Case Realization (identified) Use-Case Model Design Model Business Model .

Review: What Is Architecture: The ³4+1 View´ Model Logical View End-user Functionality Implementation View Analysts/Designers Structure Programmers Software management Use-Case View Process View System integrators Performance Scalability Throughput Deployment View System engineering System topology Delivery. installation communication .

Where Are We?  Define the High-Level Organization of Subsystems  Identify Analysis Mechanisms  Identify Key Abstractions  Create Use-Case Realizations  Checkpoints .

.Define the High-Level Organization of Subsystems  The purpose of this step is to create an initial structure for the design model.

Patterns and Frameworks  Pattern  A common solution to a common problem in a context  Analysis/Design Pattern  A solution to a narrowly-scoped technical problem  A fragment of a solution or a piece of the puzzle  Framework  Defines the general approach to solving the problem  Skeletal solution. whose details may be analysis/design patterns .

Template Parameters Pattern Name Parameterized collaboration Structural Aspect Behavioral Aspect .Concept: Design Patterns  A design pattern  Describes common design problems  Is a solution to a common design problem  Discusses results and trade-offs of applying patterns  Design patterns provide the capability to reuse successful designs.

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

Architectural Pattern: Layers .

Typical Layering Approach Specific functionality General functionality .

and retained data tend to have a high potential for change . Domain model elements  Resiliency  Loose coupling  Concentrate on encapsulating change  User interface. business rules.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.

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

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

Package Relationships: Dependency  Packages can be related to one another using a dependency relationship Dependency relationship Client Package Supplier Package  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 .

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

Example: Upper Level Layers <<layer>> Presentation Logic <<layer>> Business Logic .

Architectural Pattern: M-V-C Database .

Typical Approach for M-V-C Observer Model <<subscribe>> // Encapsulates application data() // Responds to state queries() // Exposes application functionality() // Notifies view of changes() View // Render the models() // Request updates from models() // Send user gestures to controller() // Allows controller to select view() Controller <<subscribe>> // Defines application behavior() // Maps user actions to model updates() // Selects view for response() // One for each use-case() .

Where Are We?  Define the High-Level Organization of Subsystems  Identify Analysis Mechanisms  Identify Key Abstractions  Create Use-Case Realizations  Checkpoints .

Use-Case Model Architect .Concept: Architectural Mechanisms Required Functionality ³realized by client classes using´ Implementation Environment ³constrained by´ Mechanisms Supplementary Specification ³responsible for´ COTS Products Databases IPC Technology etc.

Architectural Mechanisms: Three Categories  Architectural Mechanism Categories  Analysis Mechanisms (conceptual)  Design Mechanisms (concrete)  Implementation Mechanisms (actual) ‡ Example  Analysis mechanism = Persistence  Design mechanism = RDBMS  Implementation mechanism = Oracle .

 To provide design solutions for common architectural problems:  Persistence  Distribution  Security  Legacy interface .What is the Purpose of Defining Analysis Mechanisms?  To define the analysis mechanisms and services used by designers that give ³life´ to their objects.

How am I supposed to design these things if I don¶t even know what database we are going to use? That¶s why we have a persistence analysis mechanism. so bookmark it and come back to it later.Why Use Analysis Mechanisms? Oh no! I found a group of classes that has persistent data. 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. We don¶t know enough yet. .

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

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

.Example of Analysis Mechanism Characteristics (cont.)  Legacy interface mechanism         Latency Duration Access mechanism Access frequency Data granularity User granularity Security rules Privilege types  Security mechanism  etc.

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 .

Example: Course Registration Analysis Mechanisms  Persistence  Distribution  Security  Legacy Interface .

 A common thread emerging from a set of solutions to various problems. These mechanisms are identified by:  Previous knowledge and experience.  The software architect is responsible for identifying analysis mechanisms. .So«How Do I Discover Analysis Mechanisms?  By identifying that a common subproblem exists and assigning a name to name it.

Where Are We?  Define the High-Level Organization of Subsystems  Identify Analysis Mechanisms  Identify Key Abstractions  Create Use-Case Realizations  Checkpoints .

or the Business Model (if one exists) .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.

Purpose of Identifying Key Abstractions  To µprime the pump¶ for analysis by identifying the key abstractions (representation of concepts identified during business modeling and requirement activities) that the system must handle. .

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

Example: Key Abstractions Professor Student Schedule CourseCatalog CourseOffering Course .

Where Are We?  Define the High-Level Organization of Subsystems  Identify Analysis Mechanisms  Identify Key Abstractions  Create Use-Case Realizations  Checkpoints .

Review: What Is a Use-Case Realization?
Use-Case Model Design Model

Use Case

Use-Case Realization

Sequence Diagrams

Collaboration Diagrams

Use Case Class Diagrams

Creating Use-Case Realizations 
Provides traceability from Analysis and Design back to Requirements  The Architect creates the Use-Case Realization

Requirements

Analysis & Design

Use Case

Use-Case Realization

Example: Use-Case Realization
<<use-case realization>> Login
(from Use-Case Realization - Login)

Login
(from Use Case View)

<<use-case realization>> Register for Courses
(from Use-Case Realization - Register for Courses)

Register for Courses
(from Use Case View)

<<use-case realization>> Close Registration
(from Use-Case Realization - Close Registration)

Close Registration
(from Use Case View)

Where Are We? 
Define the High-Level Organization of Subsystems  Identify Analysis Mechanisms  Identify Key Abstractions  Create Use-Case Realizations  Checkpoints

Checkpoints 
General 
Is the package partitioning and layering done in a logical and consistent way?  Have you identified the necessary analysis mechanisms? 

Packages 
Have you provided a comprehensive picture of the services of the packages in upper-level layers?

Checkpoints (cont.) 
Classes 
Are the key entity classes and their relationships 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.?

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

Exercise: Architectural Analysis  Given the following:  Some results from the requirements workflow: ‡ Problem statement ‡ Use-Case model main diagram ‡ Glossary  Some architectural decisions: ‡ (Textually) The upper-level architectural layers and their dependencies (continued«) .

Exercise: Architectural Analysis (cont.)  Identify the following:  The key abstractions .

)  Produce the following:  A list of the key abstractions  Class diagram containing the upper-level architectural layers and their dependencies .Exercise: Architectural Analysis (cont.

Exercise: Review  Compare your key abstractions with the rest of the class  Are the key concepts 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? Payroll System .

Object-Oriented Analysis Module 5: Distribute Behavior to Classes (Use-Case Analysis) .

and entity  Describe how objects collaborate to realize system behavior  Describe class responsibilities  Demonstrate how to create interaction diagrams that accurately model use-case behavior .Objectives  Identify analysis classes from a use-case diagram and use-case specifications  Demonstrate how to use the analysis class stereotypes: boundary. control.

Use-Case Analysis in Context Use-Case Analysis Designer .

Use-Case Analysis Overview Software Architecture Glossary Use-Case Document Modeling Guidelines Supplementary Specifications Analysis Classes Use-Case Realization (identified) Use-Case Analysis Use-Case Realization (developed) Use-Case Model Analysis Model (optional) Design Model .

using use-case realizations.  To note the usage of architectural mechanisms.  To distribute the use-case behavior to those classes.  To identify the responsibilities. . attributes and associations of the classes.Purpose of Use-Case Analysis  To identify the classes which perform the flow of events for a use case.

Overview: Use-Case Analysis Steps  Supplement the Use-Case Description  For each use-case realization  Find Classes from Use-Case Behavior  Distribute Use-Case Behavior to Classes  For each resulting analysis class  Describe Responsibilities  Describe Attributes and Associations  Qualify Analysis Mechanisms  Unify Analysis Classes  Checkpoints .

Where Are We?  Supplement the Use-Case Description  For each use-case realization  Find Classes from Use-Case Behavior  Distribute Use-Case Behavior to Classes  For each resulting analysis class  Describe Responsibilities  Describe Attributes and Associations  Qualify Analysis Mechanisms  Unify Analysis Classes  Checkpoints .

Supplement the Use-Case Description ‡ The system displays a list of course offerings. . ‡ The system retrieves and displays a list of current course offerings from the course catalog legacy database.

the requirements do not change  Focus on enhancing the current flow with internal details .Do the Requirements Change?  Yes ± if you are not careful with the following:  Changes in the order of the flow of events  Adding or deleting steps from the flow of events  No ± if done properly.

Where Are We?  Supplement the Use-Case Description  For each use-case realization  Find Classes from Use-Case Behavior  Distribute Use-Case Behavior to Classes  For each resulting analysis class  Describe Responsibilities  Describe Attributes and Associations  Qualify Analysis Mechanisms  Unify Analysis Classes  Checkpoints .

 Remember: one of RUP¶s characteristics is that it is use-case driven. .  The complete behavior of a use case has to be distributed to analysis classes.Find Classes from Use-Case Behavior  Identify a candidate set of model elements (analysis classes) which are capable of performing the behavior described in use cases.

Review: Class  An abstraction  Describes a group of objects with common:  Properties (attributes)  Behavior (operations)  Relationships Class Name  Semantics Attributes Operations Professor name ProfessorId : UniqueId create() save() delete() change() .

 Have a set of related responsibilities. .  Have a clear description.  Have descriptive names.Guidelines for Class Discovery  Classes should:  Reflect the business.

Where Do You Find Classes? 
Use-case documentation  Use-case models  Glossary  Stakeholder Requests  Supplemental Specification  Vision document  Any project documentation

How Do Classes Relate to the Business Domain? 
Classes should reflect the model of business domain.  Classes should capture the vocabulary of the development of the system.  Classes should identify those things users or implementers use to describe the problem or solution.

Example: Classes and the Business Domain
Student CourseCatalogSystem Schedule

CourseOffering Professor BillingSystem

Course GraduationGown

Dormitory

Fraternity

What Should You Name Your Classes? 
Name classes to reflect what they represent.  The name should be a noun and not have a prefix or suffix.  Typically, capitalize the first letter in every word in the class name.
ourse fferin
imple Names

java awt

ectan le

c hedule
Path Name

Concept: 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.
<<stereotype>>
Stereotype

Class

Example: Stereotype
ock Cl
De cription: Athletic, c demic re not import nt, not lw y the mo t intelligent per on, bully

Jock
De cription: Young, innocent, pl yful, cute nd de ire to ple e the ignific nt dult in their life

child Cl

Child
geek Cl
De cription: Intelligent, like cience fiction, en oy re ding technic l book , weird en e of humor, u u lly work in the oftw re indu try

Geek

What Are Analysis Classes? oundary = = Boundary ontrol Control entity = Entity .

Analysis Classes: A First Step Toward Executables Use Cases Analysis Design Classes Elements Use-Case Analysis Source Code Exec .

What Is a Boundary Class?  Models the interaction between the system¶s surroundings and its inner workings  User-interface classes  Device-interface classes  System-interface classes Boundary  Environment-dependent  GUI-dependent  Communication protocoldependent .

The Role of a Boundary Class
<<boundary>>

<<control>> Customer <<boundary>> <<boundary>>

<<entity>>

<<entity>>

Model interaction between the system and its environment

Boundary Classes and the User Interface

ClassSpecificationForm

Boundary Classes and System Interfaces

CourseCatalogSystem

Guidelines: Boundary Class 
User Interface Classes 
Concentrate on what information is presented to the user  Do NOT concentrate on the UI details 

System and Device Interface Classes 
Concentrate on what protocols must be defined  Do NOT concentrate on how the protocols will be implemented Concentrate on the responsibilities, not the details.

Finding Boundary Classes 
One boundary class per actor/use-case pair

Student

Register for Courses Course Catalog System

RegisterForCoursesForm

CourseCatalogSystem

Practice: Finding Boundary Classes 
There should be at least one boundary object for each actor/use-case pair. 
How many boundary classes do you see?
View Report Card

Student Register for Courses Maintain Professor Information Course Catalog

Login
Maintain Student Information Select Courses to Teach Registrar Professor

Submit Grades

Close Registration

Billing System

Practice Solution: Boundary Classes RegisterForCoursesForm CourseCatalogSystem SelectCoursesForm MaintainStudentInfoForm LoginForm BillingSystem SubmitGradeForm CloseRegistrationForm ReportCardForm MaintainProfessorForm .

What Is a Control Class?  Controls the behavior of a use case  Delegates the work of the use case to other classes  Use-case dependent. environment independent Control .

The Role of a Control Class Coordinate the use-case behavior. .

.Guidelines: Control Class  Control classes should only do sequencing.  A control class should tell other classes to do something and should never do anything except for directing.  Use control classes to decouple boundary and entity classes.

Finding Control Classes  One control class per use case Student Register for Courses Course Catalog System RegistrationController .

Practice: Finding Control Classes  There is one control class for each complex use case.  How many control classes do you see? View Report Card Student Register for Courses Maintain Professor Information Course Catalog Login Maintain Student Information Select Courses to Teach Registrar Professor Submit Grades Close Registration Billing System .

Practice: Solution RegistrationController MaintainProfessorController MaintainStudentController CloseRegistrationController SelectCoursesToTeachController ViewReportCardController SubmitGradesController .

What Is an Entity Class?  Models the key concepts of the system  Usually models information that is long-lived (persistent)  Is environment independent  Can be used in multiple use cases Entity .

.The Role of an Entity Class Store and manage information in the system.

Guidelines: Entity Class  Model the key concepts of the system  Entity classes should contain calculation or validation logic to solve the system problem .

Finding Entity Classes  Potential Sources  Glossary  Business domain model  Use cases  Entity objects identified by examining the nouns and noun phrases in use cases  Nouns found may be  Objects  Descriptions of an object¶s state  External entities and/or actors  None of the above .

filtering nouns approach  Underline noun clauses in the use-case flow of events  Remove: ‡ Redundant candidates ‡ Vague candidates ‡ Actors (out of scope) ‡ Implementation constructs ‡ Attributes (save for later) ‡ Operations .How Do You Filter Nouns?  Traditional.

Pitfalls when Filtering Nouns  When identifying nouns.  Any noun can be disguised as a verb and any verb can be disguised as a noun.  Filtering nouns can identify many unimportant objects.  One term may refer to more than one object. . ‡ Results are dependent on the author¶s writing skills. be aware that  Several terms may refer to the same object.  Natural language is very ambiguous.

. John selects the primary courses: English 101. The system determines that John has all the necessary prerequisites by examining the student record and adds him to the course rosters.Practice: Finding Entity Classes  The ³Create a Schedule Scenario´ John enters the Student ID number 369-52-3449 and the system validates the number.´ From a list of available courses.  Filter the nouns from this description. John indicates the current semester and chooses ³create a new schedule. The system indicates that the activity is complete. The system asks which semester. World History 200. The system prints the student schedule and sends billing information for four courses to the billing system for processing. He then selects the alternate courses: Music Theory 110 and Introduction to Java Programming 180. Geology 110. and College Algebra 110.

Practice: Solution  Catalog: List of all courses being taught in a semester  Schedule: A list of courses for a semester for a student  StudentRecord: List of previously taken courses  Course: An offering for a semester  BillingInformation: Information needed by the billing system actor  CourseRoster: List of students for a specific course offering Catalogue Schedule StudentRecord Course BillingInformation CourseRoster .

Analysis Classes and the MVC Architectural Pattern  Entity class = Model  Boundary class = View  Control class = Controller .

Where Are We?  Supplement the Use-Case Descriptions  For each use-case realization  Find Classes from Use-Case Behavior  Distribute Use-Case Behavior to Classes  For each resulting analysis class  Describe Responsibilities  Describe Attributes and Associations  Qualify Analysis Mechanisms  Unify Analysis Classes  Checkpoints .

.  To determine the responsibilities of analysis classes.Distribute Use-Case Behavior to Classes  Purpose of this step:  To express the use-case behavior in terms of collaborating analysis classes.

 How do objects interact with each other?  They interact through messages.Objects Need to Collaborate  Objects are useless unless they can collaborate together to solve a problem.  No one object can carry out every responsibility on its own. .  Each object is responsible for its own behavior and status.

Concept: Messages  A message is the specification of a communication among objects that conveys information with the expectation that activity ensues.  Objects communicate with messages.  One object asks another object to perform an operation. .

 Clients depend on interface. Improves Resiliency .Review: Encapsulation  Hides implementation from clients.

.Example: Object Interaction  The OrderEntryForm wants Order to calculate the total dollar value for the order. calculateOrderTotal() orderID date salesTotal tax shipDate Message OrderEntryForm Order The class Order has the responsibility to calculate the total dollar value.

 Responsibilities translate into operations and attributes as models are refined. .What Is Class Responsibility?  A responsibility is a contract or obligation of the class.  The class responsibilities are carried out by the corresponding attributes and operations.

How Does an Object ³Advertise´ Responsibilities? Objects advertise responsibilities through operation signatures.  Visibility describes if the operation is visible and can be referenced from classes other than the one they are defined. ‡ (+) Public visibility can be referenced from other classes.  Each operation specifies the name of the operation.  Operations have visibility. ‡ (-) Private visibility cannot be accessed from another class. and the parameters. return type.  Each operation has a unique signature. .

Distribute Use-Case Behavior to Classes  For each use-case flow of events:  Identify analysis classes  Allocate use-case responsibilities to analysis classes  Model analysis class interactions in interaction diagrams Sequence Diagrams Use Case Collaboration Diagrams Use-Case Realization .

1: PerformAnother Responsibility Hierarchical Message Numbering Focus of Control .Review: The Anatomy of Sequence Diagrams Client Object Supplier Object :Client :Supplier Object Lifeline 1: PerformResponsibility This is a sample script. Reflexive Message Message 1.

Review: The Anatomy of Collaboration Diagrams Client Object Link :Client :Supplier 1: PerformResponsibility Supplier Object Message .

Concept: Link Client Object Link :Client :Supplier 1: PerformResponsibility Supplier Object Message .

Guidelines: Allocating Responsibilities to Classes  Use analysis class stereotypes as a guide  Boundary Classes ‡ Behavior that involves communication with an actor  Entity Classes ‡ Behavior that involves the data encapsulated within the abstraction  Control Classes ‡ Behavior specific to a use case or part of a very important flow of events (continued) .

)  Who has the data needed to perform the responsibility? If:  One class has the data . put the responsibility in the new class. and add relationships to classes needed to perform the responsibility .Guidelines: Allocating Responsibilities to Classes (cont.put the responsibility with the data  Multiple classes have the data: ‡ Put the responsibility with one class and add a relationship to the other ‡ Create a new class.

 Collaboration diagrams are most effective for groups new to OO techniques because they  Prevent focusing on procedural design.  Encourages ³Object Think.  Objects can help identify generalization hierarchies among the classes.´ .  Prevent premature generalization.Why Collaboration Diagrams?  Patterns of collaboration emerge.  Objects can be physically arranged to represent collaborations.

 The classes can handle a change in requirements.How Are You Doing?  Things are going well if:  All classes have meaningful. domain-specific names.  There are no ³indispensable´ classes.  Each class has a small set of collaborators. A class that collaborates with everyone needs to be redefined. .

.  A single responsibility gets assigned to several entity classes.  All classes collaborate with all other classes.)  Things are NOT going well if:  A number of classes have no responsibilities.How Are You Doing? (cont.

Example: Collaboration Diagram 5: // display course offerings( ) 6: // display blank schedule( ) : Course Catalog 4: // get course offerings( ) : RegisterForCoursesForm : CourseCatalogSystem 2: // get course offerings( ) 8: // create schedule with offerings( ) 1: // create schedule( ) 7: // select 4 primary and 2 alternate offerings( ) 3: // get course offerings(forSemester) : RegistrationController : Student 10: // add schedule(Schedule) 9: // create with offerings( ) : Schedule : Student .

One Collaboration Diagram Is Not Good Enough Basic Flow Alternate Flow 1 Alternate Flow 2 Alternate Flow 3 AF3 AF1 AF2 Alternate Flow 4 Alternate Flow 5 Alternate Flow n .

Review  What is the purpose of Use-Case Analysis?  What is an analysis class? Name and describe the three analysis stereotypes.  How many interaction diagrams should be produced during Use-Case Analysis? .  Describe some considerations when allocating responsibilities to analysis classes.

especially the use-case flows of events  Key abstractions/classes (continued) .Exercise: Use-Case Analysis  Given the following:  Use-Case Model.

Exercise: Distribute Behavior to Classes  Identify the following for a particular use case:  The analysis classes. along with their: ‡ Brief descriptions ‡ Stereotypes ‡ Responsibilities  The collaborations needed to implement the use case .

Exercise: Distribute Behavior to Classes  Produce the following for a particular use case:  Use-case realization collaboration diagram for at least one of the usecase flows of events .

Exercise: Review  Compare your use-case realization with the rest of the class  Do the collaboration diagrams carry out the use-case flow of events?  Are the stereotypes behaving properly? Payroll System .

Object-Oriented Analysis Module 6: Describe the Analysis Class (Use-Case Analysis) .

Objectives  Describe how to model the static view of a use case  Create a class diagram  Model class relationships on the class diagram  Define initial attributes for an analysis class  Describe event dependencies between classes  Qualify analysis mechanisms for analysis classes .

Where Are We?  Supplement the Use-Case Descriptions  For each use-case realization  Find Classes from Use-Case Behavior  Distribute Use-Case Behavior to Classes  For each resulting analysis class  Describe Responsibilities  Describe Attributes and Associations  Qualify Analysis Mechanisms  Unify Analysis Classes  Checkpoints .

Purpose of Describe Responsibilities  To describe the responsibilities of a class of objects identified from usecase behavior .

Example: View of Participating Classes (VOPC) Class Diagram <<entity>> Student // get tuition() // add schedule() // get schedule() // delete schedule() // has pre-requisites() <<control>> RegistrationController // get course offerings() // get current schedule() // delete current schedule() // submit schedule() // is registration open?() // save schedule() // create schedule with offerings() // update schedule with new selections() <<entity>> Schedule // commit() // select alternate() // remove offering() // level() // cancel() // get cost() // delete() // submit() // save() // any conflicts?() // create with offerings() // update with new selections() <<boundary>> CourseCatalogSystem // get course offerings() <<boundary>> RegisterForCoursesForm // display course offerings() // display blank schedule() // update offering selections() .

Maintaining Consistency: What to Look For  In order of criticality  Redundant responsibilities across classes  Disjointed responsibilities within classes  Class with one responsibility  Class with no responsibilities  Better distribution of behavior  Class that interacts with many other classes .

Where Are We?  Supplement the Use-Case Descriptions  For each use-case realization  Find Classes from Use-Case Behavior  Distribute Use-Case Behavior to Classes  For each resulting analysis class  Describe Responsibilities  Describe Attributes and Associations  Qualify Analysis Mechanisms  Unify Analysis Classes  Checkpoints .

Describe Attributes and Associations Purpose  By defining :  The other classes on which the analysis class depends  The events in other analysis classes about which the class must know  The information that the analysis class is responsible for maintaining .

do not spend time on attribute signatures <<entity>> CourseOfferi umber : Stri = "100" startTime : Time endTime : Time days : Enum numStudents : nt attribute .Review: What Is an Attribute? <<stereotype>> ClassName Attribute : Type = InitValue Attribute : Type = InitValue Attribute : Type = InitValue In analysis.

or perform simple transformations on the information.Attribute Usage  Attributes are used when information is:  Referred to by value. . set.  Accessed by operations that only get.  Uniquely ³owned´ by the objects to which it belongs and no other object references it.

Finding Attributes  Properties/characteristics of identified classes  Information retained by identified classes  ³Nouns´ that did not become classes  Information whose value is the important thing  Information that is uniquely "owned´ by an object  Information that has no behavior .

Concept: Association The semantic relationship between two or more classifiers that specifies connections among their instances  A structural relationship. specifying that objects of one thing are connected to objects of another <<entity>> Student <<entity>> Schedule <<entity>> Course .

a link is an instance of an association Client Object Link :Client :Supplier 1: PerformResponsibility Supplier Object Message .The Relationship Between Links and Associations  An object is an instance of a class  In the same way.

How Do You Find an Association? 1: PerformResponsibility Collaboration Diagram Client :Client :Supplier Link Supplier Class Diagram Client Supplier PerformResponsibility() Association A relationship for every link. .

Practice: What Associations Can You Find? 1: // submit schedule( ) 2: // submit schedule( ) : RegistrationController : Student : Student : RegisterForCoursesForm 8: // any conflicts?( ) 3: // save( ) 4: // submit( ) :Schedule 7: // still open?( ) 9: // add student(Schedule) 6: // has pre-requisites(CourseOffering) :CourseOffering : Student 5: // is selected?( ) 10: // mark as enrolled in( ) :PrimaryScheduleOfferingInfob .

Practice: Solution <<boundary>> RegisterForCoursesForm <<control>> RegistrationController <<entity>> Schedule <<entity>> CourseOffering <<entity>> PrimaryScheduleOfferingInfob <<entity>> Student .

 The name is represented as a label placed midway along the association line. an association may be named.What Is an Association Name?  To clarify its meaning.  An association name is usually a verb or verb phrase. <<control>> RegistrationController manages <<entity>> Schedule .

What Is a Role?  A role specifies the face that a class plays in an association. <<entity>> CourseOffering Instructor <<entity>> Professor Department Head <<entity>> Department .  One or both ends of an association may have role names.  A role name is placed along the association line close to the class it modifies.  Role names are typically nouns or noun phrases.

Reflexive Associations and Roles  In a reflexive association. <<entity>> Course +preRequisites .  Role names must be used in a reflexive association. objects in the same class are related.  Reflexive associations indicate that multiple objects in the same class collaborate together in some way.

Good and Bad Examples of Association Names  Poor examples  A student has a schedule  A department contains a professor  Good examples  A student creates a schedule  A department employs a professor .

Example: Roles and Association Names <<boundary>> RegisterForCoursesForm <<control>> RegistrationController currentSchedule <<entity>> Schedule primaryCourses <<entity>> CourseOffering creates <<entity>> Student .

* .1 <<entity>> CourseOffering 0. one for each end of the association.  For each instance of Course Offering.Review: What Is Multiplicity?  Multiplicity is the number of instances in which one class relates to ONE instance of another class.  For each instance of Professor. there are two multiplicity decisions to make.  For each association. <<entity>> instructor Professor 0. many Course Offerings may be taught.. there may be either one or zero Professor as the instructor..

.* * 1. unlimited)  One or more  Zero or one (optional scalar role)  Specified range  Multiple.Multiplicity Indicators  Unspecified  Exactly one  Zero or more (many..6 .* 0. 4..1 2..4 2. disjoint ranges 1 0..

..* preRequisites 0..* 1 <<entity>> Course 0.What Does Multiplicity Mean?  Multiplicity answers two questions:  Is the association mandatory or optional?  What is the minimum and maximum number of instances that can be linked to one instance? <<entity>> CourseOffering 0.3 .

* multiplicity unless there is clear evidence otherwise  Within ranges. probabilities may be specified ..Guidelines: Multiplicity and Role Names  Focus on realizing the use case  Role names should be nouns  Assume a 0.

.4 ..* <<entity>> 0..Example: Multiplicity <<boundary>> RegisterForCoursesForm 1 1 0..* +primaryCourses <<entity>> CourseOffering 0..1 Schedule 0.1 <<control>> RegistrationController +currentSchedule <<entity>> Student 1 0.

What Is Aggregation?  An aggregation is a special form of association that models a whole-part relationship between an aggregate (the whole) and its parts.1 Part .  An aggregation ³Is a part-of´ relationship..  Multiplicity is represented like other associations. Whole 1 0.

Shared Aggregation  Multiplicity is greater than one for the aggregate  Destroying the aggregate does not necessarily destroy the parts  ³Weak ownership´ .

 Is there an intrinsic asymmetry to the relationship where one class is subordinate to the other?  A door IS part of a car. A car IS NOT part of a door. move the door.Aggregation Tests  Is the phrase ³part of´ used to describe the relationship?  A door is ³part of´ a car.  Are some operations on the whole automatically applied to its parts?  Move the car. .  Are some attribute values propagated from the whole to all or some of its parts?  The car is blue. therefore the door is blue.

. although they are often linked  The relationship is an association. Car 1 0.1 Door  If two objects are usually considered as independent. Car 1 0.Association or Aggregation?  If two objects are tightly bound by a whole-part relationship  The relationship is an aggregation..1 Door .

4 <<entity>> Schedule 1 0.1 Schedule 0.* <<entity>> 0..* .* +primaryCourses <<entity>> CourseOffering 0..Example: Aggregation <<boundary>> RegisterForCoursesForm 1 1 0....1 <<control>> RegistrationController +currentSchedule <<entity>> Student 1 0..

Example: Multiple Associations primaryCourses <<entity>> Schedule alternateCourses <<entity>> CourseOffering <<entity>> Schedule add student to remove student from <<entity>> CourseOffering Multiple associations must reflect multiple roles .

Describe Event Dependencies  Inform objects when an event occurs in another object Database When the database is updated with new information. . the graph needs to be be notified so that it can decide if it needs to update itself.

Concept: Subscribe-Association  Objects of the subscribing class are informed when a particular event has occurred in objects of the associated class <<subscribe>> Subscribing Class Associated Class .

Observer Model <<subscribe>> // Encapsulates application data() // Responds to state queries() // Exposes application functionality() // Notifies view of changes() View // Render the models() // Request updates from models() // Send user gestures to controller() // Allows controller to select view() Controller <<subscribe>> // Defines application behavior() // Maps user actions to model updates() // Selects view for response() // One for each use-case() .  The subscribe-association is the mechanism that makes this communication possible. the model (entity classes) should notify all views (boundary classes) whenever its data changes.Subscribe-Association and MVC  In the MVC pattern.

TransferalHandler <<subscribe>> NoticeWriter Account .Subscribe-Association from Boundary Classes  Boundary objects need to be informed if an event takes place in an entity object.

Subscribe-Association from Entity Classes  Usually an existing association is used <<subscribe>> Station Line .

Subscribe-Association from Control Classes  Usually. the instance of the control object that deals with the event in the entity object is not created until the event actually takes place. <<subscribe>> <<subscribe>> StationSupervisor Station Line .

1 <<subscribe>> currentSchedule registrant 0.Example: Subscribe-Association 1 1 RegisterForCoursesForm RegistrationController 0..1 0...1 0.* <<subscribe>> 1 0..1 Schedule Student ..

Association Type Usage Guidelines Class Boundary Association Communicate or subscribe Communicate Communicate Class Location From a boundary to an entity class Between boundary classes From a boundary to a control class Between control and entity classes Between control classes Between control and boundary classes Between entity classes Control Communicate or subscribe Communicate Communicate Entity Communicate or subscribe .

Where Are We?  Supplement the Use-Case Descriptions  For each use-case realization  Find Classes from Use-Case Behavior  Distribute Use-Case Behavior to Classes  For each resulting analysis class  Describe Responsibilities  Describe Attributes and Associations  Qualify Analysis Mechanisms  Unify Analysis Classes  Checkpoints .

.Purpose of Qualify Analysis Mechanisms  To identify analysis mechanisms (if any) used by the class  To provide additional information about how the class applies the analysis mechanism.

. Analysis mechanisms are used during analysis to reduce the complexity of analysis. 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.Review: Why Use Analysis Mechanisms? Oh no! I found a group of classes that has persistent data. We don¶t know enough yet. and to improve its consistency by providing designers with a shorthand representation for complex behavior. so we can bookmark it and come back to it later.

Describing Analysis Mechanisms  Collect all analysis mechanisms in a list  Draw a map of the client classes to the analysis mechanisms Analysis Class Analysis Mechanism(s)  Identify characteristics of the Analysis Mechanisms .

Legacy Interface Persistence. Security Persistence. Security Persistence. Legacy Interface Distribution .Example: Describing Analysis Mechanisms  Analysis class to analysis mechanism map Analysis Class Student Schedule CourseOffering Course RegistrationController Analysis Mechanism(s) Persistence.

000 per day ‡ Delete: 50 per day .Example: Describing Analysis Mechanisms (cont.000 schedules  Access frequency ‡ Create: 500 per day ‡ Read: 2.000 access per hour ‡ Update: 1.)  Analysis mechanism characteristics  Persistence for Schedule class:  Granularity: 1 to 10 Kbytes per product  Volume: up to 2.

Where Are We?  Supplement the Use-Case Descriptions  For each use-case realization  Find Classes from Use-Case Behavior  Distribute Use-Case Behavior to Classes  For each resulting analysis class  Describe Responsibilities  Describe Attributes and Associations  Qualify Analysis Mechanisms  Unify Analysis Classes  Checkpoints .

Unify Analysis Classes .

Where Are We?  Supplement the Use-Case Descriptions  For each use-case realization  Find Classes from Use-Case Behavior  Distribute Use-Case Behavior to Classes  For each resulting analysis class  Describe Responsibilities  Describe Attributes and Associations  Qualify Analysis Mechanisms  Unify Analysis Classes  Checkpoints .

Checkpoints: Analysis Classes  Are the classes reasonable?  Does the name of each class clearly reflect the role it plays?  Does the class represent a single well-defined abstraction?  Are all attributes and responsibilities functionally coupled?  Does the class offer the required behavior?  Are all specific requirements on the class addressed? (continued) .

Checkpoints: Use-Case Realizations  Have all the main and/or subflows been handled. are their relationships clear and consistent? . including exceptional cases?  Have all the required objects been found?  Has all behavior been unambiguously distributed to the participating objects?  Has behavior been distributed to the right objects?  Where there are several interaction diagrams.

Review  What is the relationship between a link and an association?  What is a subscribe-association?  What is the difference between an association and a role name? .

Exercise: Use-Case Analysis  Given the following:  Use-Case Model. especially the use-case flows of events  Key abstractions/classes  The Supplementary Specification  The possible analysis mechanisms  Model from the previous exercise (continued) .

Exercise: Use-Case Analysis  Identify the following for a particular use case:  Analysis class relationships  Analysis class analysis mechanisms (continued) .

Exercise: Use-Case Analysis  Produce the following:  A class diagram with ‡ Analysis classes and their stereotypes ‡ Relationships (association. aggregation) ‡ Multiplicity ‡ Role and association names  Analysis class to analysis mechanism map .

Exercise: Review  Homogenize all results into one class diagram:  Does the multiplicity support the use case?  Are all relationships supported by a link in an interaction diagram?  Do role and association names make sense?  Are there classes that are ³working´ too much? Payroll System .

Object-Oriented Analysis Module 7: Review the Analysis Model .

Objective  Demonstrate that the analysis model meets general and layer checkpoints. .  Define the criteria for examining the layers of a system.  Provide a checklist for enforcing model consistency.

Where Are We?  Review the Design Purpose  Review the Design Steps  Review the design model as a whole  Review each use-case realization  Documenting Results .

.  Ensure that the design model is consistent with respect to the general design guidelines.Purpose of Review the Design  Verify that the design model fulfills the requirements on the system.  Ensure that the design guidelines fulfill their objectives. and that it serves as a good basis for its implementation.

Role: Design Reviewer  Same profile as the software architect  Needs strong communication skills Design Reviewer .

When Do You Conduct A Review?  One review per iteration Review Iteration .

Where Are We?  Review the Design Purpose  Review the Design Steps  Review the design model as a whole  Review each use-case realization  Documenting Results .

 To detect large-scale quality problems not visible by looking at lower-level elements. .Purpose of Review the Design Model as a Whole  To ensure that the overall structure for the design model is well formed.

Layering Defects  A sample layering Layer Definitions and rationale defined Each layer encapsulates a conceptual boundary .

visible.Concept: Coupling  Coupling describes how strongly one element relates to another element  The goal is to achieve ³loose coupling´ ‡ Loose coupling between classes is small. direct. and has flexible relations with other classes Loose Coupling .

Package Coupling: Package Dependencies  Packages should not be cross-coupled  Packages in lower layers should not be dependent upon packages in upper layers  In general. dependencies should not skip layers (unless specified by the architecture) X = Coupling violation Upper Layer A X A B X Lower Layer B X C .

Class B4 .Class A4 Class A3 Class A2 PackageB + Class B3 + Class B1 .Class B2 Strong Coupling Loose Coupling .Class B2 PackageB + Class B3 + Class B1 .Class A4 Class A3 Class A2 PackageA Class A1 .Package Coupling: Class Relationships  Strive for the loosest coupling possible PackageA Class A1 .Class B4 .

Concept: Cohesion  Cohesion describes how strongly related the responsibilities between design elements can be described  The goal is to achieve ³high cohesion´ ‡ High cohesion between classes is when class responsibilities are highly related .

.Examples: Cohesion PackageA Class A1 0.* 0.4 CourseOffering <<entity>> Course // Create schedule // Close course // Open course // Delete schedule 1 Student High package cohesion Low class cohesion .* Schedule 0...

 The model appears to be able to accommodate reasonably expected future change. .  The design appears to be understandable and maintainable.  The design is appropriate to the task at hand (neither too complex nor too advanced).General Checkpoints  The model is as simple as possible while still achieving the goals of the model.

 Layer boundaries are respected within the design. .  Layers are used to encapsulate conceptual boundaries between different kinds of services and provide useful abstractions that make the design easier to understand.Layers Checkpoints  The rationale for layer definition is clearly presented and consistently applied.

Where Are We?  Review the Design Purpose  Review the Design Steps  Review the design model as a whole  Review each use-case realization  Documenting Results .

Purpose of Review Each Use-Case Realization  To ensure that the behavior of the system (as expressed in use-case realizations) matches the required behavior of the system (as expressed in use cases). Is it correct? . Is it complete?  To ensure that the behavior is allocated appropriately among model elements.

Geology 110. and College Algebra 110. John indicates the current semester and chooses ³create a new schedule.Check For Missing Behavior and Distribution of Behavior  Has all use-case behavior been captured in a diagram? John enters the Student ID number 369-52-3449 and the system validates the number. John selects the primary courses: English 101. The system asks which semester.´ From a list of available courses. He then selects the alternate courses: Music Theory 110 and Introduction to Java Programming 180. The system prints the student schedule and sends billing information for four courses to the billing system for processing. The system indicates that the activity is complete. The system determines that John has all the necessary prerequisites by examining the student record and adds him to the course rosters. : . World History 200.

Enforcing Consistency  Check for:  Duplication of behavior in classes  Consistent responsibilities  Updated collaborations if a class has been split  A class with only one responsibility .

Where Are We?  Review the Design Purpose  Review the Design Steps  Review the design model as a whole  Review each use-case realization  Documenting Results .

Documenting Results: The Review Record  Filled out for each review  Used as a control document .

.Review  What is the purpose of reviewing the design model?  When and how often do you conduct a review?  What criteria should you use to examine the layers of a system?  What is cohesion? Name three kinds of cohesion.

Exercise: Review the Design Model  Given: The design model that you have been working on  Identify: Any quality concerns with the model using the questions in the student notes  Produce: A recommendation to either  Continue work ± the model is considered complete and work should continue  Raise change requests ± the model is incomplete and work should not continue until the defects in the model are addressed .

Object-Oriented Analysis Module 8: A Look Ahead to Design .

Objective  Provide an overview of design activities that still need to be performed:  Define some of the key tasks required in design  Identify how an analysis class maps to a design class  Distinguish the similarities and differences between subsystems and packages .

Where Are We?  Design Overview  Architectural activities ‡ Identify Design Elements ‡ Identify Subsystems and Interfaces ‡ Model design and implementation mechanisms  Designer activities .

Design: A Step Closer to Source Code Use Cases Analysis Design Classes Elements Source Code Exec Design .

concurrency and distribution) .Design: Tasks to Complete  Identification of interfaces  Identification and design of subsystems  Identification and design of design classes  Modeling design and implementation mechanisms  Modeling nonfunctional requirements (for example.

Design Analysis Focuses on understanding the problem Idealized design Behavior Design Focuses on understanding the solution Close to real code Operations and attributes Object lifecycles Nonfunctional requirements A large model Functional requirements A small model .Review: Analysis vs.

Where Are We?  Design Overview  Architectural activities ‡ Identify Design Elements ‡ Identify Subsystems and Interfaces ‡ Model design and implementation mechanisms  Designer activities .

From Analysis Classes to Design Elements Analysis Classes <<boundary>> Design Elements <<control>> <<entity>> <<boundary>> Many-to-Many Mapping .

Identifying Design Classes  An analysis class maps directly to a design class if:  It is a simple class  It represents a single logical abstraction  More complex analysis classes may  Split into multiple classes  Become a package  Become a subsystem (discussed later)  Any combination of the above .

Where Are We?  Design Overview  Architectural activities ‡ Identify Design Elements ‡ Identify Subsystems and Interfaces ‡ Model design and implementation mechanisms  Designer activities .

Subsystems and Interfaces  Subsystems:  Are a cross between a package (that can contain other model elements) and a class (that has behavior)  Realize one or more interfaces that define its behavior Interface <<subsystem>> Subsystem Name Interface Realization (Canonical form) <<subsystem>> Subsystem Name Subsystem Interface Realization (Elided form) .

)  Subsystems :  Completely encapsulate behavior  Represent an independent capability with clear interfaces (potential for reuse)  Model multiple implementation variants <<subsystem>> SubsystemA ClassA1 <<Interface>> InterfaceK X() W() ClassB1 W() Y() W() ClassA2 X() <<subsystem>> SubsystemB ClassB2 X() ClassB3 Z() .Subsystems and Interfaces (cont.

Packages Subsystems  Provide behavior  Completely encapsulate their contents  Are easily Client Class replaced Packages  Don¶t provide behavior  Don¶t completely encapsulate their contents  May not be easily replaced Package B ClassB1 <<subsystem>> Subsystem A ClassB2 Encapsulation is the key.Subsystems vs. .

as long as the interfaces remain unchanged  deployed across a set of distributed computational nodes  changed without breaking other parts of the systems  Subsystems can also be used to:  partition the system into units which can provide restricted security over key resources  represent existing products or external systems in the design (for example. or delivered  developed. components) Subsystems raise the level of abstraction . configured.Subsystem Usage  Subsystems can be used to partition the system into parts which can be independently:  ordered.

Where Are We?  Design Overview  Architectural activities ‡ Identify Design Elements ‡ Identify Subsystems and Interfaces ‡ Model design and implementation mechanisms  Designer activities .

Review: Course Registration Analysis Mechanisms  Persistence  Distribution  Security  Legacy Interface .

read)  Reliability Note: JDBC is the standard Java API for talking to a SQL database. .Design Mechanisms: Persistence: RDBMS: JDBC  Persistence characteristics  Granularity  Volume  Duration  Access mechanism  Access frequency (creation/deletion. update.

. pass) : Connection Statement ResultSet (from java.sql) getString() : string executeQuery(sql : String) : ResultSet executeUpdate(sql : String) : int createStatement() : Statement .sql) 1 getConnection(url.Example: Persistence: RDBMS: JDBC <<role>> PersistentClient (from SamplePersistency Client) The designer fills these roles by applying the mechanism <<role>> PersistentClassList (from SamplePersistentClass) new() add(c: PersistentClass) <<role>> DBClass create() : PersistentClass read(searchCriteria : string) : PersistentClassList update(c : PersistentClass) delete(c : PersistentClass) 1 1 0.sql) (from java.* <<role>> PersistentClass (from SamplePersistentClass) getData() setData() command() new() DriverManager (from java.sql) Connection (from java. user.

5. add(PersistentClass) called for each attribute in the class Add the retrieved course offering to the list to be returned . setData( ) 1. new() 1.Example: Persistence: RDBMS: JDBC: Read : PersistentClient : DBClass : Connection : Statement : ResultSet : PersistentClassList : PersistentClass 1.1. 1.3.4. new( ) Repeat these operations for each element returned from the executeQuery() command. getString( ) 1.7. createStatement( ) The criteria used to access data for the persistent class returns a Statement 1. read(string) 1.6.2. executeQuery(string) The SQL statement built by the DBClass using the given criteria is passed to executeQuery() Create a list to hold all retrieved data 1. The PersistentClassList is loaded with the data retrieved from the database.

Where Are We?  Design Overview  Architectural activities ‡ Identify Design Elements ‡ Identify Subsystems and Interfaces ‡ Model design and implementation mechanisms  Designer activities .

Use-Case Realization Refinement  Identify participating objects  Allocate responsibilities among objects  Model messages between objects  Describe processing resulting from messages  Model associated class relationships Sequence Diagrams Class Diagrams .

Use-Case Realization Refinement Steps  Identify each object that participates in the flow of the use-case  Represent each participating object in a sequence diagram  Incrementally incorporate applicable architectural mechanisms .

Representing Subsystems on a Sequence Diagram  Interfaces  Represent any model element that realizes the interface  Should not send messages  Proxy classes  Represent a specific subsystem  Can send messages Object A Interface Object B Object A Proxy Object B 1: Message 1 2: Message 2 X 1: Message 1 2: Message 2 Invalid message Valid message .

for t dent : t dent : Co rseOfferingList initialize All other analysis classes mapped directly to design classes .Example: Incorporating Subsystem Interfaces Analysis Classes o ndary i lling ystem s mit ill s Design Elements s system illing ystem IBilling ystem mitBill forT ition : Do le. for t dent : t dent o ndary Co rseCatalog ystem get co rse offerings s system Co rse Catalog ystem ICo rseCatalog ystem getCo rseOfferings for emester : emester.

// create schedule( ) 1. // create schedule with offerings( ) 2. // add schedule(Schedule) At this point.2.1.1.1.3. the Submit Schedule subflow is executed .Example: Incorporating Subsystem Interfaces (Before) class that is to be replaced with an interface Analysis : RegisterForCoursesForm : RegistrationController : CourseCatalogSystem : Student 1.1. // get course offerings( ) Student wishes to create a new schedule 1. // display course offerings( ) A list of the available course offerings for this semester are displayed A blank schedule is displayed for the students to select offerings 1. // get course offerings(forSemester) : Schedule : Student 2.1. // create with offerings( ) 2. // display blank schedule( ) 1. // select 4 primary and 2 alternate offerings( ) 2.2.1.1.

Example: Incorporating Subsystem Interfaces (After) Replaced with subsystem interface : RegisterFor CoursesForm : Registration Controller : Student : ICourseCatalog System : Schedule : Student 1: // create schedule( ) 1.1: // get course offerings( ) Student wishes to create a new schedule 1.1.2: // display course offerings( ) A list of the available course offerings for this semester are displayed 1.1.2: // add schedule(Schedule) 1. . point the Submit Schedule subflow is executed.3: // display blank schedule( ) A blank schedule is displayed for the students to select offerings 2: // select 4 primary and 2 alternate offerings( ) 2.1: // create schedule with offerings( ) 2.1: getCourseOfferings(Semester) At this.1: // create with offerings( ) 2.1.

Subsystem Responsibilities  Subsystem responsibilities defined by interface operations  Model interface realizations  Interface operations may be realized by  Internal class operations  Internal subsystem operations <<interface>> ICourseCatalogSystem getCourseOfferings() <<subsystem>> CourseCatalogSystem Subsystem responsibility .

persistence.)  Document design element collaborations in ³interface realizations´  One or more interaction diagrams per interface operation  Class diagrams containing the required design element relationships  Revisit ³Identify Design Elements´  Adjust subsystem boundaries and/or dependencies. etc. classes and/or subsystems)  Allocate subsystem responsibilities to design elements  Incorporate applicable mechanisms (for example. as needed .Distributing Subsystem Responsibilities  Identify new or reuse existing design elements (for example. distribution.

Modeling Convention: Subsystem Interaction Diagrams Subsystem Client Subsystem Proxy Design Element 1 Design Element 2 performResponsibility( ) Op1() subsystem responsibility Op2() Op3() Internal subsystem interactions Op4() Subsystem interface not shown .

point the Submit Schedule subflow is executed.Example: CourseCatalogSystem Subsystem In Context subsystem interface : Student : RegisterFor CoursesForm : Registration Controller : ICourseCatalog System : Schedule : Student 1: // create schedule( ) 2: // get course offerings( ) Student wishes to create a new schedule 3: getCourseOfferings(Semester) 4: // display course offerings( ) A list of the available course offerings for this semester are displayed A blank schedule is displayed for the students to select offerings 5: // display blank schedule( ) subsystem responsibility Legacy RDBMS Database Access 6: // select 4 primary and 2 alternate offerings( ) 7: // create schedule with offerings( ) 8: // create with offerings( ) 9: // add schedule(Schedule) At this. .

what are your two choices?  What is an interface? .  When does an analysis class map directly to a design class?  What is a subsystem? In order to represent the subsystem.Review  List two differences between analysis and design.

Analysis «already conquered! Analysis .Where Are You?  Analysis is the half-way point on the road to a final design  Design is covered in Rational University¶s Object-Oriented Design (OOD) course Design Mt. Design«just getting started! Mt.

Sign up to vote on this title
UsefulNot useful