VIEWS: 3 PAGES: 55 POSTED ON: 4/1/2014
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 2 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 3 Overview ¥Objective: refine information gathered ¥Identify use cases and problem domain classes ¥Model problem domain classes with UML notation ¥Introduce use case modeling 4 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 5 Figure 5-1 Identifying Use Cases by Focusing on Users and their Goals 6 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 7 Figure 5-2 Events Affecting a Charge Account Processing System that Lead to Use Cases 8 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 9 Figure 5-3 External Event Checklist 10 Figure 5-4 Temporal Event Checklist 11 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 12 Figure 5-5 Temporal Event Checklist 13 Figure 5-6 The Sequence of “Transactions” for One Specific Customer Resulting in Many Events 14 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 15 Figure 5-7 Events Deferred until Later Iterations 16 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 17 Figure 5-8 External Events for the RMO Customer Support System 18 Figure 5-9 Temporal Events for the RMO Customer Support System 19 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 20 Figure 5-10 Information about each Event and the Resulting Use Case in an Event Table 21 Figure 5-11 The Complete Event Table for the RMO Customer Support System 22 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 23 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 24 Figure 5-12 Types of Things 25 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 26 Figure 5-13a Partial List of “Things” Based on Nouns for RMO 27 Figure 5-13b Partial List of “Things” Based on Nouns for RMO 28 Figure 5-13c Partial List of “Things” Based on Nouns for RMO 29 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 30 Figure 5-14 Associations Naturally Occur between Things 31 Figure 5-15 Multiplicity of Relationships 32 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 33 Figure 5-16 Attributes and Values 34 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 35 Figure 5-17 Objects Encapsulate Attributes and Methods 36 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 37 Figure 5-21 An Expanded Domain Model Class Diagram Showing Attributes 38 Figure 5-24 A Refined University Course Enrollment Domain Model Class Diagram With an Association Class 39 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 40 Figure 5-25 A Generalization/Specialization Hierarchy Notation for Motor Vehicles 41 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 42 Figure 5-27 Whole-part (Aggregation) Associations Between a Computer and Its Parts 43 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 44 Figure 5-29 University Course Enrollment Design Class Diagram (With Methods) 45 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 46 Figure 5-31 Rocky Mountain Outfitters Domain Model Class Diagram 47 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) 48 Figure 5-32 Rocky Mountain Outfitters Location Diagram 49 Figure 5-33a Use Case–location Matrix for the Rocky Mountain Outfitters Customer Support System 50 Figure 5-33b Use Case–location Matrix for the Rocky Mountain Outfitters Customer Support System 51 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 52 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 53 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 54 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 55
"Chapter 5 - Use Cases and Domain Classes"