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

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

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

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

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 .

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

ajor Concepts in Use-Case Modeling  An actor represents anything that interacts with the system. Actor Use Case .  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.

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. View Report Card Student Register for Courses Login .  A model of the system¶s intended functionality (use cases) and its environment (actors).

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.

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

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

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

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 .

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

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. external changes?  What information must be modified or created in the system? . 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.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 .  The name may be several words in length.Naming the Use Case  The name indicates what is achieved by its interactions with the actor(s).

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

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 .

explaining terms. Includes the days of the week and times it is offered. 2. 2.3 Course Catalog: The unabridged catalog of all courses offered by the university. which may be unfamiliar to the reader of the use-case descriptions or other project documents.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.1 Course: A class offered by the university. this document can be used as an informal data dictionary. Often. Introduction This document is used to define terminology specific to the problem domain. 2. Definitions The glossary contains the working definitions for the key concepts in the Course Registration System. . capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information. Glossary 2.Glossary Course Registration System Glossary 1.

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 .

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: Use-Case Model  Is the use-case model understandable?  By studying the use-case model.

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? .

intuitive. 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? .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? .

 What is the difference between a scenario and a use case? .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.

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

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

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

 Are there differences? Do you agree with the differences? Why? 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.

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. designing it for performance. yEvolve a robust architecture for the system. . yAdapt the design to match the implementation environment.

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

Analysis and Design Discipline .

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

system requirements. Use-Case Realization Designer Package/ Subsystem Class . and software design techniques.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 .

Analysis vs. 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 and Design Is Not Top-Down or BottomUp Subsystems Top Down Use Cases Design Classes Bottom Up .

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

Philippe Kruchten. Rich Reitman.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. Rational (derived from Mary Shaw) .

. 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.

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. installation communication .

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. simple.  Help synchronize the content of different models. and understandable by a wide range of stakeholders.

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.  Partial implementations can be deployed. .  Progress is measured by assessing implementations.  Initial iterations enable early user feedback.  Testing and integration are continuous.  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 .

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

Object-Oriented Analysis Module 4: Architectural Analysis .

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

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 .

installation communication .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.

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.

whose details may be analysis/design patterns .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.

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.

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

Architectural Pattern: Layers .

Typical Layering Approach Specific functionality General functionality .

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

Review: What Is a Package?  A general-purpose mechanism for organizing elements into groups.  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.

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 .

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

so bookmark it and come back to it later. We don¶t know enough yet.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. 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.

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.

update.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 .

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

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.So«How Do I Discover Analysis Mechanisms?  By identifying that a common subproblem exists and assigning a name to name it. These mechanisms are identified by:  Previous knowledge and experience.  The software architect is responsible for identifying analysis mechanisms. .

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.?

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

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«) .

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

)  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) .

Objectives  Identify analysis classes from a use-case diagram and use-case specifications  Demonstrate how to use the analysis class stereotypes: boundary. control. 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 .

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 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. .  To distribute the use-case behavior to those classes.  To note the usage of architectural mechanisms.

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 .

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

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 .

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.  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.

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 clear description.Guidelines for Class Discovery  Classes should:  Reflect the business.  Have descriptive names.  Have a set of related responsibilities.

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. .

 A control class should tell other classes to do something and should never do anything except for directing. .Guidelines: Control Class  Control classes should only do sequencing.  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 .

How Do You Filter Nouns?  Traditional. 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 .

 Any noun can be disguised as a verb and any verb can be disguised as a noun.  Natural language is very ambiguous.Pitfalls when Filtering Nouns  When identifying nouns.  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. .  Filtering nouns can identify many unimportant objects.

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

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.

 Each object is responsible for its own behavior and status. .  No one object can carry out every responsibility on its own.  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.

.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.Review: Encapsulation  Hides implementation from clients. Improves Resiliency .

.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.

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

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

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 .

Reflexive Message Message 1.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.

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 .Guidelines: Allocating Responsibilities to Classes (cont. and add relationships to classes needed to perform the responsibility . put the responsibility in the new class.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.

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

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

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

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 .

 Describe some considerations when allocating responsibilities to analysis classes.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? .

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

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 .

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

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

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 .

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

 A role name is placed along the association line close to the class it modifies.  One or both ends of an association may have role names.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 .  Role names are typically nouns or noun phrases.

 Role names must be used in a reflexive association. <<entity>> Course +preRequisites . objects in the same class are related.Reflexive Associations and Roles  In a reflexive association.  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 .

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

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

* preRequisites 0.* 1 <<entity>> Course 0..3 ..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..

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

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

 Multiplicity is represented like other associations.  An aggregation ³Is a part-of´ relationship.. Whole 1 0.1 Part .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.

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

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

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

..Example: Aggregation <<boundary>> RegisterForCoursesForm 1 1 0.* +primaryCourses <<entity>> CourseOffering 0.* .1 <<control>> RegistrationController +currentSchedule <<entity>> Student 1 0....* <<entity>> 0.1 Schedule 0..4 <<entity>> Schedule 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 .

 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. 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() .Subscribe-Association and MVC  In the MVC pattern.

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

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

<<subscribe>> <<subscribe>> StationSupervisor 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.

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

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.Review: 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. . 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. We don¶t know enough yet.

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 .

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

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

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. 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. are their relationships clear and consistent? .

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? .

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  Given the following:  Use-Case Model.

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

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

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. . and that it serves as a good basis for its implementation.  Ensure that the design guidelines fulfill their objectives.

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 .

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

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

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 . visible.

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 B4 .Package Coupling: Class Relationships  Strive for the loosest coupling possible PackageA Class A1 .Class B2 PackageB + Class B3 + Class B1 .Class A4 Class A3 Class A2 PackageB + Class B3 + Class B1 .Class B2 Strong Coupling Loose Coupling .Class A4 Class A3 Class A2 PackageA Class A1 .

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 .

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

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

 Layers are used to encapsulate conceptual boundaries between different kinds of services and provide useful abstractions that make the design easier to understand.  Layer boundaries are respected within the design.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 .

Is it correct? .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 complete?  To ensure that the behavior is allocated appropriately among model elements.

and College Algebra 110. The system determines that John has all the necessary prerequisites by examining the student record and adds him to the course rosters. The system prints the student schedule and sends billing information for four courses to the billing system for processing.´ From a list of available courses. John indicates the current semester and chooses ³create a new schedule. The system indicates that the activity is complete. He then selects the alternate courses: Music Theory 110 and Introduction to Java Programming 180. John selects the primary courses: English 101. The system asks which semester.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. Geology 110. : . 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 .

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. concurrency and distribution) .

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.

.Subsystems vs. 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.

configured.Subsystem Usage  Subsystems can be used to partition the system into parts which can be independently:  ordered. 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 .

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 .

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

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) 1 getConnection(url.sql) Connection (from java.sql) (from java.. pass) : Connection Statement ResultSet (from java. user.sql) getString() : string executeQuery(sql : String) : ResultSet executeUpdate(sql : String) : int createStatement() : Statement .* <<role>> PersistentClass (from SamplePersistentClass) getData() setData() command() new() DriverManager (from java.

setData( ) 1. The PersistentClassList is loaded with the data retrieved from the database.Example: Persistence: RDBMS: JDBC: Read : PersistentClient : DBClass : Connection : Statement : ResultSet : PersistentClassList : PersistentClass 1.2.5.4.6.7. createStatement( ) The criteria used to access data for the persistent class returns a Statement 1. getString( ) 1. read(string) 1.3. new() 1. add(PersistentClass) called for each attribute in the class Add the retrieved course offering to the list to be returned .1. 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. new( ) Repeat these operations for each element returned from the executeQuery() command. 1.

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 .

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 : Co rseOfferingList initialize All other analysis classes mapped directly to design classes . 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.

1. the Submit Schedule subflow is executed .1.1. // create 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.1. // create with offerings( ) 2.Example: Incorporating Subsystem Interfaces (Before) class that is to be replaced with an interface Analysis : RegisterForCoursesForm : RegistrationController : CourseCatalogSystem : Student 1. // add schedule(Schedule) At this point.1.2.3.1.1. // display blank schedule( ) 1. // get course offerings( ) Student wishes to create a new schedule 1.2. // select 4 primary and 2 alternate offerings( ) 2. // get course offerings(forSemester) : Schedule : Student 2. // create schedule with offerings( ) 2.

2: // display course offerings( ) A list of the available course offerings for this semester are displayed 1.1: // get course offerings( ) Student wishes to create a new schedule 1.1: // create with offerings( ) 2.2: // add schedule(Schedule) 1.Example: Incorporating Subsystem Interfaces (After) Replaced with subsystem interface : RegisterFor CoursesForm : Registration Controller : Student : ICourseCatalog System : Schedule : Student 1: // create schedule( ) 1.1.1: getCourseOfferings(Semester) At this.1.1: // create schedule with offerings( ) 2. .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. point the Submit Schedule subflow is executed.

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. classes and/or subsystems)  Allocate subsystem responsibilities to design elements  Incorporate applicable mechanisms (for example. etc. distribution.)  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.Distributing Subsystem Responsibilities  Identify new or reuse existing design elements (for example. as needed .

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 .

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. . point the Submit Schedule subflow is executed.

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.

Design«just getting started! Mt.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. Analysis «already conquered! Analysis .

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.