objectives -...

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


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


Overview

Objective: refine information gathered

Identify use cases and problem domain classes

Model problem domain classes with UML notation

Introduce use case modeling


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


Figure 5-1Identifying Use Cases by Focusing on Users and their Goals


Event DecompositionEvent decomposition

Develops use cases based on system response to events Perceives system as black box interfacing with external environmentKeeps focus on EBPs and business requirements

Analysts delegated particular events to decomposeResult of the decomposition:

List of use cases triggered by business events Use cases at the right level of analysis


Figure 5-2Events Affecting a Charge Account Processing System that Lead to Use Cases


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


Figure 5-3External Event Checklist


Figure 5-4Temporal Event Checklist


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


Figure 5-5Temporal Event Checklist


Figure 5-6The Sequence of “Transactions” for One Specific Customer

Resulting in Many Events


Identifying Events (continued)

Identify technology dependent eventsExample: logon depending on system controls

Defer specifying technology dependent eventsPerfect technology assumption:

Separates technology dependent events from functional requirements ◘Unlimited processing and storage capacity ◘Equipment does not malfunction◘Users have ideal skill sets


Figure 5-7Events Deferred until Later Iterations


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


Figure 5-8External Events for the RMO Customer Support System


Figure 5-9Temporal Events for the RMO Customer Support System


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


Figure 5-10Information about each Event and the Resulting Use Case in an Event Table


Figure 5-11The Complete Event Table for the RMO Customer Support System


Problem Domain ClassesProblem 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 domainObjects that interact in the system

Identify and understand things in problem domainKey initial steps in defining requirements


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


Figure 5-12Types of Things


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


Figure 5-13aPartial List of “Things” Based on Nouns for RMO


Figure 5-13bPartial List of “Things” Based on Nouns for RMO


Figure 5-13cPartial List of “Things” Based on Nouns for RMO


Associations among ThingsAnalyst 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 thingsUnary (recursive), binary, n-ary


Figure 5-14Associations Naturally Occur between Things


Figure 5-15Multiplicity of Relationships


Attributes of ThingsSpecific 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


Figure 5-16Attributes and Values


Classes and ObjectsDomain 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


Figure 5-17Objects Encapsulate Attributes and Methods


Domain Model Class Diagram Notation

Class diagram keyGeneral class symbol: rectangle with three sectionsSections convey name, attributes, and behaviors Methods (behaviors) not shown in domain model class diagramLines connecting rectangles show associationsMultiplicity reflected above connecting lines

Domain class objects reflect business concern, policies, and constraints


Figure 5-21An Expanded Domain Model Class Diagram Showing Attributes


Figure 5-24A Refined University Course Enrollment Domain Model Class

Diagram With an Association Class


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


Figure 5-25A Generalization/Specialization Hierarchy Notation for Motor Vehicles


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 hierarchiesAggregation: 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


Figure 5-27Whole-part (Aggregation) Associations Between a Computer and Its Parts


Hierarchies in Class Diagram Notation (continued)

Design Class DiagramsModels classes into precise software analogsIncludes domain class information plus methodsTriangle symbol between classes indicates inheritanceProperties of attributes are shown with curly braces

Class fundamentalsInstances of a class (objects) manage their own dataAbstract classes are not instantiated (created) Subclasses inherit attributes/behaviors from superclass


Figure 5-29University Course Enrollment Design Class Diagram (With Methods)


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


Figure 5-31Rocky Mountain Outfitters Domain Model Class Diagram


Locations and the Crud MatrixLocation 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)


Figure 5-32Rocky Mountain Outfitters Location Diagram


Figure 5-33aUse Case–location Matrix for the Rocky Mountain Outfitters

Customer Support System


Figure 5-33bUse Case–location Matrix for the Rocky Mountain Outfitters

Customer Support System


Use Cases, the Domain Model, and Iteration Planning

Select use cases for further developmentIdentify risks to determine priority Core architecture typically selected/implemented first

Transition into elaboration phaseConverting use cases into softwareIteratively integrate software components into more complex systemsBegin testing of software


SummaryRequirements 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


Summary (continued)Multiple associations among classesAttributes: specific information about a thingActual software classes include behaviors (methods) and attributes UML class diagrams show classes, attributes, methods, and associationsDomain model class diagram show domain classes in the users’ work environment


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

objectives -...

Documents