chapter05
DESCRIPTION
object oriented analysis and design with the unified processTRANSCRIPT
2Object-Oriented Analysis and Design with the Unified Process
Objectives
Explain how events can be used to identify use cases that define requirements
Identify and analyze events and resulting use cases
Explain how the concept of problem domain classes also defines requirements
Identify and analyze domain classes needed in the system
3Object-Oriented Analysis and Design with the Unified Process
Objectives (continued)
Read, interpret, and create a Unified Modeling Language (UML) domain model class diagram and design class diagram
Use a CRUD matrix to study the relationships between use cases and problem domain classes
4Object-Oriented Analysis and Design with the Unified Process
Overview
Objective: refine information gathered
Identify use cases and problem domain classes
Model problem domain classes with UML notation
Introduce use case modeling
5Object-Oriented Analysis and Design with the Unified Process
Events and Use Cases Use case
Activity the system carries out
Entry point into the modeling process
Event decomposition: help identify use cases
Elementary business processes (EBPs)
Basic unit of analysis
Initiated by event occurring at specific time and place
Discrete system response that adds business value
6Object-Oriented Analysis and Design with the Unified Process
Figure 5-1Identifying Use Cases by Focusing on Users and their Goals
7Object-Oriented Analysis and Design with the Unified Process
Event Decomposition
Event decomposition Develops use cases based on system response to events Perceives system as black box interfacing with
external environment Keeps focus on EBPs and business requirements
Analysts delegated particular events to decompose Result of the decomposition:
List of use cases triggered by business events Use cases at the right level of analysis
8Object-Oriented Analysis and Design with the Unified Process
Figure 5-2Events Affecting a Charge Account Processing System that Lead to Use Cases
9Object-Oriented Analysis and Design with the Unified Process
Types of Events
External Events
Occur outside the system
Usually caused by external agent
Temporal Events
Occurs when system reaches a point (deadline) in time
State Events
Asynchronous events responding to system trigger
10Object-Oriented Analysis and Design with the Unified Process
Figure 5-3External Event Checklist
11Object-Oriented Analysis and Design with the Unified Process
Figure 5-4Temporal Event Checklist
12Object-Oriented Analysis and Design with the Unified Process
Identifying Events
Three rules of thumb
Distinguish events from prior conditions
Can the transaction complete without interruption?
Is the system waiting for next transaction?
Trace sequence of events initiated by external agent
Isolate events that actually touch the system
13Object-Oriented Analysis and Design with the Unified Process
Figure 5-5Temporal Event Checklist
14Object-Oriented Analysis and Design with the Unified Process
Figure 5-6The Sequence of “Transactions” for One Specific Customer
Resulting in Many Events
15Object-Oriented Analysis and Design with the Unified Process
Identifying Events (continued)
Identify technology dependent events Example: logon depending on system controls
Defer specifying technology dependent events Perfect technology assumption:
Separates technology dependent events from functional requirements
◘ Unlimited processing and storage capacity
◘ Equipment does not malfunction
◘ Users have ideal skill sets
16Object-Oriented Analysis and Design with the Unified Process
Figure 5-7Events Deferred until Later Iterations
17Object-Oriented Analysis and Design with the Unified Process
Events in the Rocky Mountain Outfitters Case
Developing list of external events
Identify all people and organizational units that want something from the system
Developing list of temporal events
Identify regular reports and statements that system must produce at certain times
18Object-Oriented Analysis and Design with the Unified Process
Figure 5-8External Events for the RMO Customer Support System
19Object-Oriented Analysis and Design with the Unified Process
Figure 5-9Temporal Events for the RMO Customer Support System
20Object-Oriented Analysis and Design with the Unified Process
Looking At Each Event and the Resulting Use Case
Enter use cases in an event table
Event table includes rows and columns
Each row is a record linking an event to a use case
Columns represent key information
RMO event table anatomizes customer support system
21Object-Oriented Analysis and Design with the Unified Process
Figure 5-10Information about each Event and the Resulting Use Case in an Event Table
22Object-Oriented Analysis and Design with the Unified Process
Figure 5-11The Complete Event Table for the RMO Customer Support System
23Object-Oriented Analysis and Design with the Unified Process
Problem Domain Classes
Problem domain Set of work-related “things” in system component
◘ Things have data representation within system
Examples: products, orders, invoices, customers
OO approach to things in problem domain Objects that interact in the system
Identify and understand things in problem domain Key initial steps in defining requirements
24Object-Oriented Analysis and Design with the Unified Process
Types of Things
Things can be identified with methodology
Separate the tangible from the intangible
Include information from all types of users
Ask important questions about nature of event
“What actions upon things should be acknowledged and recorded by the system?”
Example case: customer placing an order
25Object-Oriented Analysis and Design with the Unified Process
Figure 5-12Types of Things
26Object-Oriented Analysis and Design with the Unified Process
Procedure for Developing an Initial List of Things
List nouns users mention when discussing system
Event table as source of potential things
Use cases, external agents, triggers, response
Select nouns with questions concerning relevance
Further research may be needed
27Object-Oriented Analysis and Design with the Unified Process
Figure 5-13aPartial List of “Things” Based on Nouns for RMO
28Object-Oriented Analysis and Design with the Unified Process
Figure 5-13bPartial List of “Things” Based on Nouns for RMO
29Object-Oriented Analysis and Design with the Unified Process
Figure 5-13cPartial List of “Things” Based on Nouns for RMO
30Object-Oriented Analysis and Design with the Unified Process
Associations among Things
Analyst document entity associations ( relationships) Example: “Is placed by” and “works in”
Associations apply in two directions Customer places an order An order is placed by a customer
Multiplicity: the number of associations One to one or one to many
The associations between types of things Unary (recursive), binary, n-ary
31Object-Oriented Analysis and Design with the Unified Process
Figure 5-14Associations Naturally Occur between Things
32Object-Oriented Analysis and Design with the Unified Process
Figure 5-15Multiplicity of Relationships
33Object-Oriented Analysis and Design with the Unified Process
Attributes of Things Specific details of things are called attributes
Analyst should identify attributes of things
Identifier (key): attribute uniquely identifying thing
Examples: Social Security number, vehicle ID number, or product ID number
Compound attribute is a set of related attributes
Example: multiple names for the same customer
34Object-Oriented Analysis and Design with the Unified Process
Figure 5-16Attributes and Values
35Object-Oriented Analysis and Design with the Unified Process
Classes and Objects Domain model class diagram as UML class
OOA applies domain model class diagram to things
Problem domain objects have attributes
Software objects encapsulate attributes and behaviors
Behavior: action that the object processes itself
Software objects communicate with messages
Information system is a set of interacting objects
36Object-Oriented Analysis and Design with the Unified Process
Figure 5-17Objects Encapsulate Attributes and Methods
37Object-Oriented Analysis and Design with the Unified Process
Domain Model Class Diagram Notation
Class diagram key General class symbol: rectangle with three
sections Sections convey name, attributes, and behaviors Methods (behaviors) not shown in domain model
class diagram Lines connecting rectangles show associations Multiplicity reflected above connecting lines
Domain class objects reflect business concern, policies, and constraints
38Object-Oriented Analysis and Design with the Unified Process
Figure 5-21An Expanded Domain Model Class Diagram Showing Attributes
39Object-Oriented Analysis and Design with the Unified Process
Figure 5-24A Refined University Course Enrollment Domain Model Class
Diagram With an Association Class
40Object-Oriented Analysis and Design with the Unified Process
Hierarchies in Class Diagram Notation
Generalization/specialization notation
Inheritance hierarchy
Rank things the more general to the more special
◘ Motor vehicle class includes trucks, cars, buses
Classification: means of defining classes of things
Superclass: generalization of a class
Subclass: specialization of a class
41Object-Oriented Analysis and Design with the Unified Process
Figure 5-25A Generalization/Specialization Hierarchy Notation for Motor Vehicles
42Object-Oriented Analysis and Design with the Unified Process
Hierarchies in Class Diagram Notation (continued)
Whole-part Hierarchy Notation “The whole is equal to the sum of the parts”
Two types of whole-part hierarchies Aggregation: association with independent parts
◘ Example: keyboard is part of computer system Composition: association with dependent part
◘ Example: CRT and monitor
Multiplicity applies to whole-part relationships
43Object-Oriented Analysis and Design with the Unified Process
Figure 5-27Whole-part (Aggregation) Associations Between a Computer and Its Parts
44Object-Oriented Analysis and Design with the Unified Process
Hierarchies in Class Diagram Notation (continued)
Design Class Diagrams Models classes into precise software analogs Includes domain class information plus methods Triangle symbol between classes indicates inheritance Properties of attributes are shown with curly braces
Class fundamentals Instances of a class (objects) manage their own data Abstract classes are not instantiated (created) Subclasses inherit attributes/behaviors from superclass
45Object-Oriented Analysis and Design with the Unified Process
Figure 5-29University Course Enrollment Design Class Diagram (With Methods)
46Object-Oriented Analysis and Design with the Unified Process
The Rocky Mountain Outfitters Domain Class
Diagram
Derives from noun list developed in Figure 5-13
RMO domain class diagram shows attribute
Models do not show methods
Problem domain classes reflect high-level view of RMO use cases
47Object-Oriented Analysis and Design with the Unified Process
Figure 5-31Rocky Mountain Outfitters Domain Model Class Diagram
48Object-Oriented Analysis and Design with the Unified Process
Locations and the Crud Matrix
Location diagrams store data for future reference Shows need for network connections Creates awareness of geographic reach
Use case–location matrix: shows where use cases are performed
Use case–domain class matrix: highlights access requirements Example: The RMO CRUD (create, read, update,
and delete)
49Object-Oriented Analysis and Design with the Unified Process
Figure 5-32Rocky Mountain Outfitters Location Diagram
50Object-Oriented Analysis and Design with the Unified Process
Figure 5-33aUse Case–location Matrix for the Rocky Mountain Outfitters
Customer Support System
51Object-Oriented Analysis and Design with the Unified Process
Figure 5-33bUse Case–location Matrix for the Rocky Mountain Outfitters
Customer Support System
52Object-Oriented Analysis and Design with the Unified Process
Use Cases, the Domain Model, and Iteration Planning
Select use cases for further development Identify risks to determine priority
Core architecture typically selected/implemented first
Transition into elaboration phase Converting use cases into software
Iteratively integrate software components into more complex systems
Begin testing of software
53Object-Oriented Analysis and Design with the Unified Process
Summary Requirements discipline defines business functions
Key concepts: use cases and problem domain classes
Use cases derive from elementary business processes (EBPs)
Three event types: external, temporal, and state
Problem domain class: category based on OOA
54Object-Oriented Analysis and Design with the Unified Process
Summary (continued) Multiple associations among classes
Attributes: specific information about a thing
Actual software classes include behaviors (methods) and attributes
UML class diagrams show classes, attributes, methods, and associations
Domain model class diagram show domain classes in the users’ work environment
55Object-Oriented Analysis and Design with the Unified Process
Summary (continued) Design class diagram models software classes
Generalization/specialization hierarchies allow inheritance from a superclass to a subclass
Whole-part hierarchies allow a collection of objects to be associated as a whole and its parts
Requirements are also defined with location diagrams, and matrices