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 Object-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 Object-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 Object-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 Object-Oriented Analysis and Design with the Unified Process

Identifying Use Cases by Focusing on Users and their Goals Figure 5-1 Identifying Use Cases by Focusing on Users and their Goals Object-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 Object-Oriented Analysis and Design with the Unified Process

Figure 5-2 Events Affecting a Charge Account Processing System that Lead to Use Cases Object-Oriented Analysis and Design with the Unified Process

Types of Events External Events Temporal Events State 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 Object-Oriented Analysis and Design with the Unified Process

External Event Checklist Figure 5-3 External Event Checklist Object-Oriented Analysis and Design with the Unified Process

Temporal Event Checklist Figure 5-4 Temporal Event Checklist Object-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 Object-Oriented Analysis and Design with the Unified Process

Temporal Event Checklist Figure 5-5 Temporal Event Checklist Object-Oriented Analysis and Design with the Unified Process

Figure 5-6 The Sequence of “Transactions” for One Specific Customer Resulting in Many Events Object-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 Object-Oriented Analysis and Design with the Unified Process

Events Deferred until Later Iterations Figure 5-7 Events Deferred until Later Iterations Object-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 Object-Oriented Analysis and Design with the Unified Process

External Events for the RMO Customer Support System Figure 5-8 External Events for the RMO Customer Support System Object-Oriented Analysis and Design with the Unified Process

Temporal Events for the RMO Customer Support System Figure 5-9 Temporal Events for the RMO Customer Support System Object-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 Object-Oriented Analysis and Design with the Unified Process

Figure 5-10 Information about each Event and the Resulting Use Case in an Event Table Object-Oriented Analysis and Design with the Unified Process

The Complete Event Table for the RMO Customer Support System Figure 5-11 The Complete Event Table for the RMO Customer Support System Object-Oriented Analysis and Design with the Unified Process

Problem Domain Classes 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 Object-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 Object-Oriented Analysis and Design with the Unified Process

Figure 5-12 Types of Things Object-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 Object-Oriented Analysis and Design with the Unified Process

Procedure for Developing an Initial List of Things Ask these question about each noun to decide inclusion:- - Is it a unique “Thing” the System needs to know about? - Is it inside the Scope of the System under question? - Does the System need to remember more than one of these items? Ask these question about each noun to decide exclusion:- - Is it really just a synonym for some other things already identified? - Is it just an Output produced from other identified information? - Is it just an Input that results in recording some other information? Ask these questions about each Noun to decide further research:- - Is it likely to be an Attribute about some other Thing already Identified? - Is it something that I might need if assumptions changed? Object-Oriented Analysis and Design with the Unified Process

Partial List of “Things” Based on Nouns for RMO Figure 5-13a Partial List of “Things” Based on Nouns for RMO Object-Oriented Analysis and Design with the Unified Process

Partial List of “Things” Based on Nouns for RMO Figure 5-13b Partial List of “Things” Based on Nouns for RMO Object-Oriented Analysis and Design with the Unified Process

Partial List of “Things” Based on Nouns for RMO Figure 5-13c Partial List of “Things” Based on Nouns for RMO Object-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 Object-Oriented Analysis and Design with the Unified Process

Associations Naturally Occur between Things Figure 5-14 Associations Naturally Occur between Things Object-Oriented Analysis and Design with the Unified Process

Multiplicity of Relationships Figure 5-15 Multiplicity of Relationships Object-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 Object-Oriented Analysis and Design with the Unified Process

Figure 5-16 Attributes and Values Object-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 Object-Oriented Analysis and Design with the Unified Process

Objects Encapsulate Attributes and Methods Figure 5-17 Objects Encapsulate Attributes and Methods Object-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 Object-Oriented Analysis and Design with the Unified Process

An Expanded Domain Model Class Diagram Showing Attributes Figure 5-21 An Expanded Domain Model Class Diagram Showing Attributes Object-Oriented Analysis and Design with the Unified Process

Figure 5-24 A Refined University Course Enrollment Domain Model Class Diagram With an Association Class Object-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 Object-Oriented Analysis and Design with the Unified Process

A Generalization/Specialization Hierarchy Notation for Motor Vehicles Figure 5-25 A Generalization/Specialization Hierarchy Notation for Motor Vehicles Object-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 Object-Oriented Analysis and Design with the Unified Process

Whole-part (Aggregation) Associations Between a Computer and Its Parts Figure 5-27 Whole-part (Aggregation) Associations Between a Computer and Its Parts Object-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 Object-Oriented Analysis and Design with the Unified Process

University Course Enrollment Design Class Diagram (With Methods) Figure 5-29 University Course Enrollment Design Class Diagram (With Methods) Object-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 Object-Oriented Analysis and Design with the Unified Process

Rocky Mountain Outfitters Domain Model Class Diagram Figure 5-31 Rocky Mountain Outfitters Domain Model Class Diagram Object-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) Object-Oriented Analysis and Design with the Unified Process

Rocky Mountain Outfitters Location Diagram Figure 5-32 Rocky Mountain Outfitters Location Diagram Object-Oriented Analysis and Design with the Unified Process

Figure 5-33a Use Case–location Matrix for the Rocky Mountain Outfitters Customer Support System Object-Oriented Analysis and Design with the Unified Process

Figure 5-33b Use Case–location Matrix for the Rocky Mountain Outfitters Customer Support System Object-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 Object-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 Object-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 Object-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 Object-Oriented Analysis and Design with the Unified Process