Docstoc

Chapter 5 - Use Cases and Domain Classes

Document Sample
Chapter 5 - Use Cases and Domain Classes Powered By Docstoc
					                  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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:4/1/2014
language:English
pages:55