Introduction to Computer Science

1
Modeling and the Requirements Discipline
Chapter 4 -6
2
Figure 4-1 Activities of the Requirements
Discipline
3
Steps for Requirements Discipline

• Gather Detailed Information
• Define Requirements
• Prioritize Requirements
• Develop User Interface Dialogs
• Evaluate Requirements with Users

4
System Requirements

• System requirements consist of capabilities and
  constraints
• System requirements fall into two categories
• Functional
• Nonfunctional

5
Techniques for Information Gathering

• Review Existing Reports, Forms Procedure
  Descriptions
• Interviews Discussions with Users
• Observe Document Business Processes
• Build Prototypes
• Questionnaires
• Joint Application Design Sessions

6
Figure 4-14 A Simple Activity Diagram to
Demonstrate a Workflow
7
Models and Modeling

• Purpose
• Types
• Mathematical models
• Descriptive models
• Graphical models
• Logical models specify processes
• Physical models are based on logical models

8
Figure 4-5 UML Diagrams used for Modeling
9
Validating the Requirements

• Two basic approaches to validating requirements
• Predictive development
• Adaptive development (embodied in UP)
• Alternatives to developing costly prototypes
• Structured walkthrough

10
Events and Use Cases

• Use case
• List users and see what they do
• List current functions that the system provides
  or are needed
• Event decomposition

11
Events

• Types of Events
• External Events
• Temporal Events
• State Events
• Identifying Events

12
Figure 5-2 Events Affecting a Charge Account
Processing System that Lead to Use Cases
13
Figure 5-10 Information about each Event and the
Resulting Use Case in an Event Table
14
Problem Domain Classes

• Problem domain
• OO approach to things in problem domain
• Identify and understand things in problem domain

15
Figure 5-12 Types of Things
16
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

17
Figure 5-13b Partial List of Things Based on
Nouns for RMO
18
 Associations among Things

• Analyst document entity associations (
  relationships)
• Associations apply in two directions
• Multiplicity the number of associations  
• The associations between types of things

19
Figure 5-14 Associations Naturally Occur between
Things
20
Attributes of Things

• Specific details of things are called attributes
• Analyst should identify attributes of things
• Identifier (key) attribute uniquely identifying
  thing
• Compound attribute is a set of related attributes

21
Classes and Objects

• Domain model class diagram as UML class
• 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

22
Figure 5-17 Objects Encapsulate Attributes and
Methods
23
Figure 5-21 An Expanded Domain Model Class
Diagram Showing Attributes
24
Hierarchies in Class Diagram Notation

• Generalization/specialization notation
• Classification means of defining classes of
  things
• Whole-part Hierarchy Notation
• Two types of whole-part hierarchies
• Multiplicity applies to whole-part relationships

25
Figure 5-31 Rocky Mountain Outfitters Domain
Model Class Diagram
26
Figure 6-1 Requirements Diagrams With UML Models
27
The Use Case Diagram

• Actors
• Notation for use case diagrams
• Automation boundary
• Includes
• Ways to identify additional use cases

28
Figure 6-2 A Simple Use Case with an Actor
29
Figure 6-3 A Use Case Diagram of the Order-Entry
Subsystem for RMO, Showing a System Boundary
30
Figure 6-6 An Example of the Order-entry
Subsystem With Includes Use Cases
31
Use Case Detailed Descriptions

• Use cases have internal complexity
• Use case descriptions written at (3) levels of
  detail
• Brief
• Intermediate
• Fully developed
• Activity Diagram Description

32
Figure 6-10 Fully Developed Description of
Telephone Order Scenario for Create New Order Use
Case
33
Figure 6-12 Activity Diagram of the Telephone
Order Scenario
34
Identifying Inputs and Outputsthe System
Sequence Diagram

• System sequence diagram (SSD)
• Actor interacts with the system via
  input/output
• Parts
• Objects
• Lifeline
• Messages

35
Figure 6-14 Sample System Sequence Diagram
36
 
Figure 6-15 Repeating Message (A) Detailed
Notation (B) Alternate Notation
37
Developing a System Sequence Diagram

• Begin with detailed description of use case
• Fully developed form
• Activity diagrams
• (4) step process for turning activity diagram
  into SSD  
• 1 Identify the input messages
• 2 Describe messages from external actor to
  system
• 3 Identify/apply special conditions to input
  messages
• 4 Identify and add the output return messages 

38
Figure 6-16 A Simplified Diagram of the Telephone
Order Scenario
39
Figure 6-19 Simple Statechart for a Printer
40
Identifying the Object Behavior?the Statechart
Diagram

• Guidelines to help identify states
• Check naming convention for status conditions
• Simple states reflect simple conditions such as
  On
• Complex states labeled with verb phrases
• Active states usually not labeled with nouns
• Describe only states of being of the object
  itself
• Status conditions reported to management/customers
  
• Concurrency
• Composite States

41
Figure 6-20 Sample Composite States for the
Printer Object
42
Figure 6-21 Concurrent Paths for the Printer in
the On State
43
Rules for Developing Statecharts

• 1 Select the classes that will require
  statecharts
• 2 List all the status conditions for each group
  
• 3 Specify transitions that cause object to
  leave the identified state
• 4 Sequence state-transition combinations in
  correct order
• 5 Identify concurrent paths.
• 6 Look for additional transitions
• 7 Expand each transition as appropriate
• 8 Review and test each statechart

44
Figure 6-27 Second-cut Statechart for Order
45
Integrating Object-Oriented Models

• Primary (or source) models
• Use case diagram
• Problem domain class diagram
• CRUD analysis validates model completeness
• Construction of one model depends on another
• Models capturing processes of new system
• Use case diagram and models to lower left
• Models capturing information about classes
• Class diagrams and dependencies

46
Figure 6-28 Relationships among OO Requirements
Models