Introduction to Computer Science

1
(No Transcript)
2
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

3
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

4
Overview

• Objective refine information gathered
• Identify use cases and problem domain classes
• Model problem domain classes with UML notation
• Introduce use case modeling

5
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

6
Figure 5-1 Identifying Use Cases by Focusing on
Users and their Goals
7
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

8
Figure 5-2 Events Affecting a Charge Account
Processing System that Lead to Use Cases
9
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

10
Figure 5-3 External Event Checklist
11
Figure 5-4 Temporal Event Checklist
12
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

13
Figure 5-5 Temporal Event Checklist
14
Figure 5-6 The Sequence of Transactions for One
Specific Customer Resulting in Many Events
15
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

16
Figure 5-7 Events Deferred until Later Iterations
17
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

18
Figure 5-8 External Events for the RMO Customer
Support System
19
Figure 5-9 Temporal Events for the RMO Customer
Support System
20
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

21
Figure 5-10 Information about each Event and the
Resulting Use Case in an Event Table
22
Figure 5-11 The Complete Event Table for the RMO
Customer Support System
23
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

24
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

25
Figure 5-12 Types of Things
26
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

27
Figure 5-13a Partial List of Things Based on
Nouns for RMO
28
Figure 5-13b Partial List of Things Based on
Nouns for RMO
29
Figure 5-13c Partial List of Things Based on
Nouns for RMO
30
 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

31
Figure 5-14 Associations Naturally Occur between
Things
32
Figure 5-15 Multiplicity of Relationships
33
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

34
Figure 5-16 Attributes and Values
35
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

36
Figure 5-17 Objects Encapsulate Attributes and
Methods
37
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

38
Figure 5-21 An Expanded Domain Model Class
Diagram Showing Attributes
39
Figure 5-24 A Refined University Course
Enrollment Domain Model Class Diagram With an
Association Class
40
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

41
Figure 5-25 A Generalization/Specialization
Hierarchy Notation for Motor Vehicles
42
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

43
Figure 5-27 Whole-part (Aggregation) Associations
Between a Computer and Its Parts
44
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

45
Figure 5-29 University Course Enrollment Design
Class Diagram (With Methods)
46
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

47
Figure 5-31 Rocky Mountain Outfitters Domain
Model Class Diagram
48
Locations and the Crud Matrix

• Location diagrams store data for future reference
• Shows need for network connections
• Creates awareness of geographic reach
• Use caselocation matrix shows where use cases
  are performed
• Use casedomain class matrix highlights access
  requirements 
• Example The RMO CRUD (create, read, update, and
  delete)

49
Figure 5-32 Rocky Mountain Outfitters Location
Diagram
50
Figure 5-33a Use Caselocation Matrix for the
Rocky Mountain Outfitters Customer Support System
51
Figure 5-33b Use Caselocation Matrix for the
Rocky Mountain Outfitters Customer Support System
52
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

53
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

54
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

55
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