Homework o case studies

7

Chapter 7:
The Object-Oriented Approach
to Requirements

7

*

Overview of Object-Orientation

• Object contains program logic and necessary attributes in a single unit
• Objects send each other messages and collaborate to support functions of main program
• Each object can be thought of as a Service Provider (self contained):
• Attributes
• Method = service provided (invoked by message)
• Inherit from other objects
• OO analysts develop model of system in terms of objects
• Class diagrams (generic objects, can inherit)
• interaction diagrams, (some) statechart diagrams

7

Systems Analysis and Design in a Changing World,

*

Objects and Inheritance

Automobile

Car

Minivan

Truck

Buick

Toyota

General Concepts:

Object = Thing (e.g., car, buick, minivan)

Each object has attributes plus methods

Inherit* means that all properties (attributes plus methods) are inherited from higher classes

The lower classes can add own attributes and methods after inheriting

Attributes: a1, a2, a3

Methods:m1, m2, m3

Inherit*

Inherit*

a4

Inherit*

a4, a5

m4

7

Systems Analysis and Design in a Changing World, 3rd Edition

*

The Unified Modeling Language and the Object Management Group

• Object-oriented modeling notation is Unified Modeling Language (UML)
• UML was presented to Object Management Group (OMG) as standard modeling technique
• Purpose of Object Management Group (www.omg.org)
• Promote theory and practice of object technology for development of distributed systems
• Provide common architectural framework for OO

7

*

Object-Oriented Approach Models

• Class diagram – definition of system components
• Use case diagrams and use case descriptions – show user roles and how they use the system
• Systems sequence diagrams (SSDs) – define inputs and outputs and sequence of interactions between user and system for a use case
• Statechart diagrams – describe states of each object
• Activity diagrams – describe user activities

7

*

OBJECTS: Inheritance and Class Libraries

Automobile

Car

Minivan

Truck

Buick

Toyota

Class: object type (e.g., car, buick, minivan)

Object: instance of a class (e.g., my car)

Class hierarchies support inheritance (inheritance can be from multiple classes)

Inherit* means that all properties (attributes plus methods) are inherited from higher classes

The lower classes can add own attributes and methods after inheriting

Class library shows the attributes and methods (code) for certain domain (e.g., hospitals)

Developers can build a system by inheritance

Attributes: a1, a2, a3

Methods:m1, m2, m3

Inherit*

Inherit*

a4

Inherit*

a4, a5

m4

7

*

Use Case Diagram

• Graphical models that summarize information about actors and use cases
• System developer
• Looks at system as whole
• Identifies major uses from event table
• Identifies functions to be supported by new system
• Organizes use cases

7

*

Simple Use Case with an Actor

7

*

Use Case Diagram with System Boundary

7

*

Use Case of Customer Support System

7

*

All Use Cases Including Customer

7

*

<<Includes>> Relationships

• Documents situation where one use case requires the services of a common subroutine
• Another use case is developed for this common subroutine
• A common use case can be reused by multiple use cases

7

*

Example of Order-Entry Subsystem with <<Includes>> Use Cases

7

*

Developing a Use Case Diagram

• Approach 1: Starting points for use case development
• Use event table
• Identify all actors of the system
• Identify functions actors perform with system
• Approach 2: start with a high level system and break it down to use cases
• Approach 3: Mixture: start with one and use the other to complete
• Develop flow of activities to identify various scenarios
• Common internal use cases can be identified and separated into different use cases

7

*

Use Case Detailed Descriptions

• Scenario, or use case instance, details sequence of activities within use case
• Shows actor interacting with computer system step-by-step to carry out business activity
• May have several scenarios for single use case
• Analysts prefer to write narrative descriptions of use cases instead of building activity diagrams
• Three levels: brief, intermediate, and fully developed description

7

*

Brief Description of Create New Order
Use Case

7

*

Intermediate Description of the Telephone Order Scenario for Create New Order

7

*

Intermediate Description of the Web
Order Scenario for Create New Order

7

*

Fully Developed Description of Telephone Order Scenario for Create New Order

7

*

Fully Developed Description of Web
Order Scenario for Create New Order

7

*

Activity Diagrams

• Used to document work flow of business process activities for each use case scenario
• Standard UML diagram
• Can support any level of use case description
• Helpful in developing system sequence diagrams

7

*

Activity Diagram: Telephone Order Scenario

7

*

Activity Diagram: Web Order Scenario

7

*

Identifying Inputs and Outputs –
The System Sequence Diagram

• Collaboration diagram
• Emphasizes objects that interact together to support a use case diagram
• May be used alone or with sequence diagram
• System sequence diagram
• Shows sequence of interactions between objects and flow of events in a single use case
• Focuses on message details
• Used more frequently in industry

7

*

Sample System Sequence Diagram (SSD)

7

*

Sequence Diagrams

Customer

Purchasing

Payment

1. Purchase Item

2. Prepare Invoice

3.Ship Item to customer

4. Send Invoice to Customer

5. Make Payment

7

*

SSD Notation

• Actor represented by stick figure – person (or role) that “interacts” with system by entering input data and receiving output data
• Object notation is rectangle with name of object underlined – shows individual object and not class of all similar objects
• Lifeline is vertical line under object or actor to show passage of time for object
• Messages use arrows to show messages sent or received by actor or system

7

*

Repeating Message

7

*

Developing a System Sequence Diagram

• Begin with detailed description of use case from fully developed form or activity diagrams
• Identify input messages
• Describe message from external actor to system using message notation
• Identify and add any special conditions on input message, including iteration and true/false conditions
• Identify and add output return messages

7

*

Simplified Activity Diagram of the Telephone Order Scenario

7

*

SSD of Simplified Telephone Order Scenario for Create New Order Use Case

7

*

SSD of the Web Order Scenario for the Create New Order Use Case

7

*

Problem Domain Modeling –
The Domain Model Class Diagram

• Class diagram is focal point of object-oriented development
• Provides definition of system components
• Contains important class structural information for implementation with object-oriented programming
• Provides conceptual data model to describe classes for database definition
• Consists of problem domain classes and implementation classes

7

*

Example of Domain Model Class Diagram

7

*

RMO Domain Model Class Diagram

7

*

Integrating Object-Oriented Models

• Complete use case diagram is needed to understand total scope of new system
• Domain model class diagrams also should be as complete as possible for entire system
• With iterative approach, only construct use case descriptions, activity diagrams, and system sequence diagrams for use cases in iteration
• Development of a new diagram often helps refine and correct previous diagrams

7

*

Relationships Between OO
Requirements Models

7

*

Use Case Diagram for Inventory System

7

*

Summary

• Object-oriented approach has complete set of diagrams that together document the user’s need and define system requirements
• Requirements specified using following models:
• Domain model class diagrams
• Use case diagrams
• Use case detailed model, either descriptive format or activity diagram
• System sequence diagrams (SSDs)