Instructor Notes

:

Object Oriented Analysis and Design
Education and Research

Page 1

Instructor Notes:

Object Oriented Analysis and Design
OOAD is generic name for Analysis and Design Methods for an Object Oriented Application. Unified Modelling Language provides a set of standard notations and diagrams for OO Analysis and Design. Rational Unified Process provides a process framework, addressing all the aspects of an OO Application Development Life Cycle.

6-2

Page 2

Instructor Notes:

Agenda
Advantage of Modelling System Analysis and Design Introduction to Object Orientation (OO) Unified Modelling Language (UML) OO Analysis
– Logical Object Modelling (LOM) – Use Case Analysis

OO Design
– Application Architecture – Object Interaction Diagram (Sequence diagram) – Physical Object Model – Physical Data Model

6-3

Page 3

Instructor Notes:

Model
A model is an abstract representation of a system constructed from a perspective to understand the system prior to building or modifying it. A static (or structural) model can be viewed as a “blueprint” of a system, or as a "snapshot" of a system's parameters at a specific point in time. A dynamic (or behavioural) model is a collection of procedures or behaviours that, taken together, reflect the behaviour of a system over time.

6-4

Page 4

Instructor Notes:

Dog House

6-5

Page 5

Instructor Notes:

Residence

6-6

Page 6

Instructor Notes:

High Rise Office Building

6-7

e.g. Construction of a new building: (pic above: 88-storey PETRONAS Twin

Towers, Malaysia)
1. An important concern: how will it behave under high-winds? 1. Option 1: Build a physical model, and subject it to wind tunnel tests 1. Might learn some interesting things, but materials in the small scale might not behave exactly as they do in large 2. Option 2: build a mathematical model and subject it to simulations 1. We will learn some different things, and will also be able to play with more new scenarios than with the physical model in option 1 3. By rigorously and continuously testing the models, we’ll end up with a far higher level of confidence that the system we have modeled will behave as we expect it to in the real world

In the software world: 1. Model a system through the eyes of a database developer: 1. Likely to focus on entity-relationship models that push behavior into triggers and stored procedures 2. Model the system through the eyes of an analyst 1. Like to end up with models that are procedural, with data flowing from process to process 3. Through the eyes of an OO developer 1. End up with a system of classes and objects and their interactions Any of the above approaches might be right for a given application and development culture, depending on the needs.

Page 7

Instructor Notes:

Why Model?
Dog house vs. Residence vs. High-rise tower
– Dog house: low complexity, can build without modeling. Need only wood, nails and a few basic tools – Residential house: higher complexity, can still model some parts informally, but need to set expectations and manage change – High-rise multi-storied office building:
• High complexity • Larger team size

– Need common “blueprints” and models to communicate

6-8

Curiously, a lot of projects start out intending to build highrises - but approach the problem as if they were building a dog house !

Page 8

Instructor Notes:

Advantages of Modelling
Models make it easier to express complex ideas.
– For example, an architect builds a model to communicate ideas more easily to clients

The cost of the modelling analysis is much lower than the cost of similar experimentation conducted with a real system Models enhance learning and better understanding of the real system Model has scope for modification

6-9

Page 9

Instructor Notes:

Systems Analysis and Design
Analysis:
– Model user requirements – Model input-output relationships – Model the “what”, not the “how” – Output: Analysis Model

Design:
– Devise the means to the end – Model the “how”, not the “what” – Output: Design Model

6 - 10

Page 10

Instructor Notes:

Data Modelling
• • A tool for analysis A tool for design

pays Citizen Tax

6 - 11

Page 11

Instructor Notes:

Process Modelling
A tool for analysis A “weak” tool for design

cust-no Print cust statement cust-stmt

CUSTOMERS

6 - 12

Page 12

Instructor Notes:

Stages in Process Modelling
As is -Physical Model As is - Logical Model To be - Logical Model To be - Physical Model

Stages in Influx BPE
Need for change in process/IT behavior

As-Is Modeling

Process Analysis

To-Be Modeling

Enactment Definition

Software Functional Requirements

6 - 13

Page 13

Instructor Notes:

Event-Partitioning
Event: an external trigger to the system, to which the system needs to respond All functionality delivered by the system is in response to events Typically involves the following 4 steps:
– The Event list is defined and a bubble, or process, is drawn for each event in the event list – The bubble is named by describing the response that the system should make to the associated event – Appropriate inputs and outputs are drawn so that the bubble will be able to make its required response, and stores are drawn, as appropriate, for communication between bubbles – The resulting first-cut DFD is checked against the context diagram and event list for completeness and consistency

6 - 14

One of the longest running ways to think about an enterprise application is as a system that reacts to events from the outside world. This is a way of thinking that became established in the structured design community in the second half of the 80's.

Page 14

Instructor Notes:

Structured Systems Analysis and Design
Data Model + Process Model Loose coupling
– “Data” / “Function” divide

Structured Programming
– “Data” / “Function” divide continues

6 - 15

Page 15

Instructor Notes:

What is OO?
Object orientation is an approach to organizing software by combining data and methods Basic paradigm: Collaborating Objects;
– originally mooted by
• SIMULA • Ada, • SmallTalk

6 - 16

Page 16

Instructor Notes:

OO Principles
Philosophical Principles;
– Encapsulation: A grouping mechanism – Information Hiding: Restrict Visibility or Access [Attributes accessed or changed ONLY via operations of object] – Abstraction: Describe significant features only, ignore (relatively) unnecessary details.This creates layers of detail – Classification: Group things together based on commonality

Driving principles:
• Maintainability, Extensibility • Reusability • Interoperability

6 - 17

Page 17

Instructor Notes:

Basic Concepts - 1
Object:
– "A set of related data and functions" (Wirfs-Brock) – "An abstraction of a real-world entity or concept with crisp boundaries and meaning for the problem at hand" (Rumbaugh) – "A living, breathing blob of intelligence that knows how to act in a given situation" (Steve Jobs)

Class:
– “A group of objects with similar properties, common behaviour, common relationships, and common semantics”

An Object is an Instance of a Class Abstract Class
– A class which is not instantiated in an object

Concrete Class
– A class which is instantiated in one or more objects

6 - 18

Page 18

Instructor Notes:

Basic Concepts - 2
Attribute (Data):
– Data value held by an object – Values of its attributes determine the state of the object

Operation (Method):
– A function that applies to objects in a class. – A class's data must be accessed only by its own methods

Interface
– A set of behaviors (a set of operations) offered by a class

Message:
– Invocation of an operation on an object – Message-passing is the only way one object can execute another object's methods

6 - 19

Page 19

Instructor Notes:

Basic Concepts - 3
Association
– The relationship between two classes that specifies connections amongst their instances

Aggregation
– A special form of association that signifies a whole part relationship. – Example: Vehicle – Example: Country Wheel State City

6 - 20

Page 20

Instructor Notes:

Defining Characteristics of OO
Encapsulation
– "Hiding" of internal, implementation details of an object: let both function and data be owned by objects. – In OO an object is encapsulated e.g.
Data and process (attributes and operations) are a single unit.

Generalization (Inheritance)
– A mechanism that allows classes to share attributes and operations, based on specialization. – Objects can be classified and categorized; let an object inherit the attributes and behaviour of its parent classes

6 - 21

Page 21

Instructor Notes:

Defining Characteristics of OO
Polymorphism
– The property by which an operation may behave differently on different classes. – The behaviours induced by a given message depends on the object to which the message is passed. – The same stimulus means different things to different objects: let the receiver interpret a stimulus (message). Note: The Object Management Group (the OO standards body) does not include polymorphism in its reference model

6 - 22

Page 22

Instructor Notes:

The Unified Modelling Language (UML)
The Unified Modelling Language (UML) is a language for specifying, constructing, visualizing, and documenting the software system and its components.

6 - 23

Page 23

Instructor Notes:

Visualizing
UML is a graphical language Notations of UML are well-defined

6 - 24

Page 24

Instructor Notes:

Specifying
Building models that are precise, unambiguous, and complete

6 - 25

Page 25

Instructor Notes:

Constructing
UML is not a programming language However, its models can be directly connected to a variety of programming languages It is possible to map from a model in the UML to:
– OO Languages such as Java, C++, or C# – Tables in a relational database – The persistent store of an object-oriented database

Modern UML tools help construct an application in its target language

6 - 26

Page 26

Instructor Notes:

Documenting
The UML addresses the documentation of a system's architecture and all of its details
– Requirements – Architecture – Design – Source code – Project plans – Tests – Prototypes – Releases

6 - 27

Page 27

Instructor Notes:

The Value of UML
Is an open standard Supports the entire software development lifecycle Supports diverse applications areas Is based on experience and needs of the user community Supported by (almost) all OOAD tools. Some leading UML tools are
– IBM Rational Rose – IBM Rational XDE – Borland Together

6 - 28

Page 28

Instructor Notes:

Evolution of the UML
2005 OMG, RTF OMG Acceptance, Nov 1997 public feedback Final submission to OMG, Sep ‘97 UML partners June ´96

UML 2.0 UML 1.1
UML 1.0

UML 0.9

October ‘95

Unified Method 0.8

Other methods

Booch method (Booch)
6 - 29

OMT (Rumbaugh)

OOSE (Jacobson)

Page 29

Instructor Notes:
Again, this is a slide you do not need to spend a lot of time on. You might just want to point out one or two contributors of special interest to your audience. For example, for a telephony audience, you might point out Harel and his state charts.

Contributions to UML
Booch Rumbaugh Jacobson
Meyer
Before and after conditions

Fusion

Operation descriptions, Message numbering

Harel
State charts

Embley
Singleton classes, High-level view

Gamma, et.al
Frameworks, patterns, notes Shlaer - Mellor Object Lifecycles

Wirfs-Brock Odell
Classification Responsibilities

6 - 30

UML development included incorporating ideas from numerous other methodologists. The main challenge was constructing an approach that was simple yet allowed the modeling of a broad range of systems. The conceptual framework was established quickly but the notational semantics took more time. Active collaboration with other industry leaders has brought unique expertise and experience into the UML effort. The UML effort was supported by a large cross-section of the industry. Partners in the UML effort included HP, ICON Computing, IBM, I-Logix, Intellicorp, MCI Systemhouse, Microsoft, ObjecTime, Oracle, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software, Taskon, and Unisys. These partners provided contributors, reviewers, and advocates for the standardization efforts. In the end, a modeling language was created that has already stood up to the test of widespread use in the industry and to the scrutiny of international standardization efforts.

Page 30

Instructor Notes:

Building Blocks of UML
Things Relationships Extension Mechanisms Diagrams

6 - 31

Page 31

Instructor Notes:

Things - Structural
Nouns of the model Mostly static parts of a model
– Use Case, Class, Component, Interface, Collaboration (Use Case Realization)
Use Case Use Case Class Class
Employee
Place Order

Component Component

Name EmpNo GetName() GetEmpNo()

UI

Interface Interface
BankAccount

Use Case Realization Use Case Realization

Chain of Responsibility

6 - 32

Active classes initiate and control the flow of activity, while passive classes store data and serve other classes. Show active classes with a thicker border.

Page 32

Instructor Notes:

Things - Behavioural
Dynamic parts of UML models – Interaction, State machine

Interaction Interaction

State Machine State Machine State Machine State Machine

Display

Waiting

6 - 33

Page 33

Instructor Notes:

Things - Grouping
Organisational parts of UML
– Package, Subsystem
Package Package System & Subsystem System & Subsystem

6 - 34

Page 34

Instructor Notes:

Things - Annotational
Explanatory parts of UML
– Note

Note Note

6 - 35

Page 35

Instructor Notes:

Relationships – Dependency
Dependency
– A semantic relationship between two things in which a change to one thing (the independent thing) may affect the semantics of the other thing (the dependent thing) – Dependencies are using relationships.

6 - 36

Page 36

Instructor Notes:

Relationships – Association
A structural relationship that describes a set of links

6 - 37

Page 37

Instructor Notes:

Relationships – Generalization
“Is a kind of” relationship

6 - 38

Page 38

Instructor Notes:

UML Extensions: Stereotypes & Constraints
User-defined extensions of the UML are enabled through the use of stereotypes and constraints. Constraints are assumptions or relationships among model elements specifying conditions and propositions that must be maintained as true otherwise the system described by the model would be invalid.

Stereotype

Constraint

<<Interface>>

* Person 1

WorkFor {subset} ManagerOf

* Department 1

Customer

6 - 39

Page 39

Instructor Notes:

UML Diagrams
Each diagram is a “view” into a model
– Presented from the aspect of a particular stakeholder – Provides a partial representation of the system – Is semantically consistent with other views

In UML notation, there are nine standard diagrams
– Four Static / Structural diagrams
• • • • • • • • • Class diagram Object diagram Component diagram Deployment diagram Use case diagram Sequence diagram Collaboration diagram Statechart diagram Activity diagram

– Five Dynamic / Behavioral diagrams

6 - 40

UML provides several types of diagrams that help articulate the application design.

Page 40

Instructor Notes:

Class Diagram
Class diagram is the set of classes, interfaces, and collaborations and their relationships Captures the vocabulary of the system Build and refined throughout development Purpose
– Model static design view of the system
• Model vocabulary of the system • Specify collaborations • Specify logical database schema

Developed by analysts, designers, and implementers

6 - 41

Page 41

Instructor Notes:

Class Diagram

6 - 42

Page 42

Instructor Notes:

Object Diagram
Object diagram is a set of objects and their relationship at a point in time Captures objects and links Represents static snapshots of instances of the things found in class diagrams built during analysis and design Purpose
– Model data/object structures – Specify static snapshots

Developed by analysts, designers, and implementers Note: The object diagram does not show messages across the objects.

6 - 43

Page 43

Instructor Notes:

Object Diagram

6 - 44

Page 44

Instructor Notes:

Component Diagram
Component diagram shows the organizations and dependencies among a set of components built as part of architectural specification Represents the static implementation view of a system Purpose
– Organize source code – Construct an executable release – Specify a physical database

Developed by architects and programmers

6 - 45

Page 45

Instructor Notes:

Component Diagram

Access

Update

UI

6 - 46

Page 46

Instructor Notes:

Component Diagram

6 - 47

Page 47

Instructor Notes:

Deployment Diagram
Deployment diagram is the configuration of run-time processing nodes (and the components there in) and their relationships Captures the topology of the hardware where the system executes Built as part of architectural specification Purpose
– Specify the distribution of components – Identify performance bottlenecks

Developed by architects, networking engineers, and system engineers

6 - 48

Page 48

Instructor Notes:

Deployment Diagram

Node 1: AdminServer

Access

Update

Node 2: MyPC

UI

6 - 49

Page 49

Instructor Notes:

Deployment Diagram

6 - 50

Page 50

Instructor Notes:

Use Case Diagram
A use case diagram is a diagram that shows set of use cases and actors and their relationship Captures system functionality as seen by users Built in early stages of development Purpose
– Specify the context of a system – Capture the requirements of a system – Validate a system’s architecture – Drive implementation and generate test cases

Developed by analysts and domain experts

6 - 51

Page 51

Instructor Notes:

Use Case Diagram

6 - 52

Page 52

Instructor Notes:

Activity Diagram
An activity diagram is a behavioural diagram that shows flow of control from activity to activity An activity diagram captures dynamic behaviour (activity-oriented)
– Activity diagrams may be created for use cases, classes, and/or operations

Purpose
– Model workflow – Model operations

Can be developed by domain experts, analysts and/or designers and programmers for different purpose

6 - 53

Page 53

Instructor Notes:

Activity Diagram

6 - 54

Page 54

Instructor Notes:

Interaction Diagrams
An interaction diagram is a graphical representation of interactions between objects There are two kinds of interaction diagrams
– Sequence diagrams – Collaboration diagrams

Each provides a different view of the same interaction
– Sequence diagrams are time ordered – Collaboration diagrams may include data flow

Interaction diagrams are developed by designers Note: Sequence diagram and collaboration diagram are semantically equivalent

6 - 55

Page 55

Instructor Notes:

Sequence Diagram
A sequence diagram is an interaction diagram that emphasizes the time ordering of messages Captures dynamic behaviour (time-oriented) Purpose
– Model flow of control over time – Model executables

6 - 56

Page 56

Instructor Notes:

Sequence Diagram

This is a sample script

6 - 57

Page 57

Instructor Notes:

Collaboration Diagram
A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects sending and receiving the messages Captures dynamic behaviour (message-oriented) Purpose
– Model flow of control over the structural organization of the objects

Note: Collaboration diagrams are preferable over sequence diagrams in case of complex flows, involving branching and iterations.

6 - 58

Page 58

Instructor Notes:

Collaboration Diagram

6 - 59

Page 59

Instructor Notes:

Statechart Diagram
Statechart shows a state machine, consisting of states, transitions, events, and activities. Captures dynamic behaviour (event-oriented) Purpose
– Model object lifecycle – Model reactive objects (user interfaces, devices, etc.) – Note: Activity diagram is a special case of statechart diagram where state is an activity state

Statechart diagrams are developed by designers

6 - 60

Page 60

Instructor Notes:

Statechart Diagram
Captures dynamic behaviour (event-oriented)

6 - 61

Page 61

Instructor Notes:
It is important to keep the discussion of this slide at a very high level. Examples of the 5 views are not provided. You may wish to go to the white board and show some examples. Several examples from earlier in this module can be used. For example, The sample use case diagram can illustrate the use-case view. The sample class diagram can illustrate the logical view. Also mention that the UML provides the notation we use to visualize these views.

The 4+1 View Model of Architecture (RUP)

Logical View
Analysts/ Designers Structure

Implementation View
Programmers Software management

End-user Functionality

Process View
System Integrators Performance Scalability Throughput

Use-Case View Deployment View
System Engineering System topology Delivery, installation communication

6 - 62

Many different parties are interested in the architecture (e.g., the system analyst, the designers, the end uses, etc.). To allow these parties or stakeholders to communicate, discuss and reason about architecture, we need to have an architectural representation that they understand. Because different stakeholders have different concerns and because architecture is quite complex, multiple views are required to represent architecture adequately. An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns,and omitting entities that are not relevant to this perspective. While many views of architecture can be useful, the Rational Unified Process identifies 4+1 views as a standard set: The logical view addresses the functional requirements of the system. It is an abstraction of the design model, identifying major design packages, subsystems and classes. The implementation view describes the organization of static software modules in the development environment, in terms of packaging, layering, and configuration management. The process view addresses the concurrent aspect of the system at run-time: tasks, threads or processes, and their interactions. The deployment view shows how the various executables and other run-time components are mapped onto the underlying platforms or computing nodes. The use-case view contains a few key scenarios or use cases that are used to drive the architecture and to validate it.
Page 62

Instructor Notes:
The UML emphasizes a graphical language for representing models, but provides little/no guidance on when and how to use these diagrams. This is an area where the RUP helps. It describes the kinds of project artifacts needed, including diagrams, and puts them in the context of an overall project plan.

UML Diagrams
State State State State Diagrams Class Diagrams Class Diagrams Diagrams Diagrams Diagrams

Use Case Use Case Use Case Use Case Diagrams Activity Diagrams Activity Diagrams Diagrams Diagrams Diagrams Scenario Scenario Scenario Scenario Diagrams Sequence Diagrams Sequence Diagrams Diagrams Diagrams Diagrams

Use Case Use Case Use Case Use Case Diagrams Use Case Diagrams Use Case Diagrams Diagrams Diagrams Diagrams

State State State State Diagrams Object Diagrams Object Diagrams Diagrams Diagrams Diagrams

Model

State State State State Diagrams State Diagrams State Diagrams Diagrams Diagrams Diagrams

Scenario Scenario Scenario Scenario Diagrams Collaboration Diagrams Collaboration Diagrams Diagrams Diagrams Diagrams

Deployment Deployment Diagram Diagram

Component Component Component Diagrams Component Diagrams Component Diagrams Component Diagrams

Diagrams Diagrams

6 - 63

In building a visual model of a system, many different diagrams are needed to represent different views of the system. The UML provides a rich notation for visualizing our models. This includes the following key diagrams: Use Case diagrams to illustrate user interactions with the system. Class diagrams to illustrate logical structure. Object diagrams to illustrate objects and links. State diagrams to illustrate behavior. Component diagrams to illustrate physical structure of the software. Deployment diagrams to show the mapping of software to hardware configurations. Interaction diagrams (i.e., collaboration and sequence diagrams) to illustrate behavior. Activity diagrams to illustrate the flow of events in a use case.

Page 63

Instructor Notes:

OO Analysis and Design

6 - 64

Page 64

Instructor Notes:

OOAD Process
Analysis Phase
– Build the Use Case Model
• • • • Identify the Actors – Who is using the system? Identify the Use Cases – What are the users doing with the system? Complete the Use Case Diagram Elaborate Use Cases

– Build the Logical Object Model (LOM)
• Identify Classes (Entity Classes) and their Relationships • Identify Class Attributes • Complete the Logical Object Model (Class Diagram)

Design Phase
– Build the Physical Object Model (POM)
• Identify Class Methods using Interaction Diagrams (Sequence and/or Collaboration diagrams) • Define the Application Architecture (Identify Boundary & Control Classes)

– Build the Physical Data Model
6 - 65

Page 65

Instructor Notes:

OO Analysis
OO Analysis concerns with determining the System Requirements and identifying classes and their relationships that make up the application OOA approach
– Use Cases
• Use-Case Driven SDLC • Use Case Identification • Use-Case Elaboration • Include, Extend relationships

– Class Diagrams
• Classes • Associations • Aggregation ("part-of") • Inheritance (“kind-of”)

6 - 66

Page 66

Instructor Notes:

Use-Cases and Actors
Use-Case: A technique to capture business process from the user’s perspective i.e., a way of documenting system functionality expected by the user. “A use-case is a processing sequence which the system is required to perform to fulfil a functionality desired by a user” (Jacobson) “A use case defines a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor.” (RUP) Actor: “Defines a coherent set of roles that users of the system can play when interacting with it. An actor instance can be played by either an individual or an external system.” (RUP)
6 - 67

Page 67

Instructor Notes:

“Use-Case driven” Development
In use-case driven project environments, use cases defined for the system are the basis for the entire development process Lifecycle of the use-case continues beyond requirements to cover analysis, design, implementation, and testing

6 - 68

Page 68

Instructor Notes:

“Use-Case driven” SDLC
Use-cases in Software Development Lifecycle
Requirements Analysis/ Design / Development Testing

Identified

Analyzed

Verified

Authored

Designed

Accepted

Agreed

Implemented

6 - 69

This life cycle diagram is not intended to imply that analysis cannot be started until all the use cases have been agreed on or even until any use cases have been agreed on. The diagram is just saying that you cannot consider the analysis of a use case to be completed before the use case authoring has been completed and the use case itself agreed on. Figure above is arranged to emphasize the three main applications for the use cases: • Requirements: the identification, authoring and agreement of the use cases and their descriptions for use as a requirement specification. • Development: the analysis, design, and implementation of a system based on the use cases. The implementation part is outside the scope of this course. • Testing: the use-case-based verification and acceptance of the system produced. The details of how to undertake use-case-based testing is outside the scope of this course.

Page 69

Instructor Notes:

Use-Case Lifecycle
The use-case model and its relationship to the other software development models

The Use-Case Model

Expressed in terms of

Realized by

Implemented by

Verified by

Class…

Pass Fail

The Glossary / Domain Model

Analysis and Design Models

Implementation Model

Test Model

6 - 70

Although primarily a requirement-capture technique, use cases have a significant role to play in the ongoing planning, control, development, and testing of the system. It is this unification of the software development process that makes use-cases such a powerful technique. To get the full benefit of using use cases, they should be placed at the heart of all the software development and project planning activities.

Page 70

Instructor Notes:

Identifying Use Cases from Influx Workflow Model
From activities in To-Be Business Workflow : interactive and automated activities are candidates for use-case

6 - 71

Page 71

Instructor Notes:

Use Case Elaboration
Elaborate Use Case by adopting a Template such as one shown here (From Pride) Key Sections
– Main Flow – Alternate Flow – Pre-conditions – Post conditions
Title Actors Status Description Flow of Events Subflow/Alternate Flows/ Scenarios Special Requirements Assumptions Pre-conditions Post-conditions User interface Business Rules Entities/Busines s Concepts Related Use Cases Issues Reference
<Use-case name – indicate the goal of the use-case> <Name of actors invoking use-case, you can mention whether they are the initiating or participating actors> <Open, Closed, On-hold, Suspended, Canceled> <Textual description of the use-case (Keep it as precise as possible)> <Steps of the use-case (Primary flow of events). Describe them as a bulleted/ numbered list> <Alternative paths to the primary flow of events above>

<Performance requirements Any user interface related specifics, implementation concerns, testing concerns> 1. <What are the requirements for this use-case to run, list of conditions that should exist before the use case can be executed> <What state the system is in after use-case runs> <Reference to UI prototype or specific screen and UI related notes> <Any domain specific knowledge or algorithms or validation rules (relevant to this use-case)> <This is optional. You can list obvious entities/business concepts picked from this use-case. E.g. Order, customer, item> <This is optional. List all Use Cases include, extend or specialize this use case> <Clarifications required from user Any questions related to use-case > Requirement #: Documents: Persons: Use-case Authors:

6 - 72

Page 72

Instructor Notes:

Structuring Use Case Model
Why Structure
– Simplify the original use case – Reuse behaviour – Make easier to understand – Make easier to maintain

Relationship between Actor and Use Case Relationship between Use Case and Use Case Relationship between Actor and Actor

6 - 73

Page 73

Instructor Notes:

Relationship between Actor and Use Case

<<communicate>>

Customer

Order

What is the significance of direction of the arrow?

6 - 74

Page 74

Instructor Notes:

Relationship between Use Case and Use Case
Include
– Included Use Case is fully executed. – Not conditional.

Extend
– Extended Use Case functionality inserted into base use case. – Only when extending condition is true.

6 - 75

Page 75

Instructor Notes:

Include Relationship - Motivation

Check Balance

Customer

Withdraw Cash
Check Balance Main Flow 1. Customer Logs On System confirms log on name Customer enters password System confirms password System displays options …. Customer selects option …. …

Check Statement

2. 3. 4. 5. 6. 7.

A1: Not valid logon A2: Not valid password

6 - 76

Page 76

Instructor Notes:

Include Relationship

Check Balance

<<include>>

<<include>>

Customer

Withdraw Cash

<<include>>

Validate Customer

Check Statement

Validate Customer Main Flow

Check Balance Main Flow 1. 2. 3. 4. Include “Validate Customer” System displays options …. Customer selects option …. …

1. 2. 3. 4.

Customer Logs On System confirms log on name Customer enters password System confirms password

A1: Not valid logon A2: Not valid password

6 - 77

Page 77

Instructor Notes:

Extend Relationship - Motivation

Open Account
Open Account Main Flow

Account Admin

1. 2. 3. 4.

System presents options. Account Admin selects Open Account. System presents options Customer – New / Existing. Account Admin selects “Existing”. System presents account open form. ..

Add Customer
Add Customer Main Flow 1. 2. 3. 4. Account Admin selects “New Customer”. System presents customer form. Account Admin enters required information… …

5. 6.

A1: Customer not valid. 1.1 ... A2: New Customer 2.1 Account Admin selects “New Customer”. 2.2 System presents customer form. 2.3 Account Admin enters required information 2.4 ...

6 - 78

Page 78

Instructor Notes:

Extend Relationship

Open Account

<<extend>>

Account Admin

Open Account Main Flow 1. 2. System presents options. Account Admin selects Open Account. System presents options Customer – New / Existing. Account Admin selects “Existing”. System presents account open form. ..

Add Customer
Add Customer This use case extends the Open Account use case at extension point “New Customer” Main Flow 1. 2. 3. 4. Account Admin selects “New Customer”. System presents customer form. Account Admin enters required information… …

3. 4. 5. 6.

A1: Customer not valid. 1.1 ... Extension Points: The “New Customer” extension point occurs at Step 4 in the Main Flow.

6 - 79

Page 79

Instructor Notes:

Relationship between Actors- Motivation

Read Personal Details

Employee Modify Address

Manager

Modify Personal Details

Administrator

Set Access Permissions

6 - 80

Page 80

Instructor Notes:

Relationship between Actor and Actor

Read Personal Details

Employee Modify Address

Manager

Modify Personal Details

Administrator

Set Access Permissions

6 - 81

Page 81

Instructor Notes:

Finding Classes
Look for nouns and noun phrases in the Use-Cases
– E.g. Customer, Client, ATM Machine

All classes must make sense in the application domain
– Defer design / implementation classes (e.g. DBAccess) till design phase

One should be able to identify few attributes of a class
– If you can not identify more than one attribute, perhaps the noun is an attribute, and not a class

An analysis class must have multiple instances, and there should be a need to store them Review the class purpose, and remove redundant/fuzzy candidate classes Class names should be singular, and capitalize 1st letter of each word
– E.g. LoanWindow

6 - 82

Page 82

Instructor Notes:

Data Model
Data Model Entity

Object Model
Object Model Class Object Association Generalization (Inheritance) Multiplicity Class Diagram

Entity Instance Relationship Sub Type Cardinality & Optionality ERD

6 - 83

Page 83

Instructor Notes:

ERD

UML Class Diagram
ERD UML
0..*

0..1

1

1..*

aggregation
6 - 84

Page 84

Instructor Notes:

Sample Associations

0..* Employee theEmployee

1 Department cost center

0..10 Product item

1..* Warehouse

1 Project

1 Manager

6 - 85

Page 85

Instructor Notes:

Sample Object Model

superclass

EMPLOYEE

COMPANY COMPANY

REGULAR EMPLOYEE

0..*
TRAINEE

takes

1..*
COURSE

subclasses

6 - 86

Page 86

Instructor Notes:

The Object Model - new features
Depiction of Operations Modelling of Generalization Special relationships – Aggregation and Composition

6 - 87

Page 87

Instructor Notes:

Generalization
Vehicle color velocity position Stop() Start() Turn_left() Accelerate() WaterVehicle and its subclasses inherit the variables and methods of Vehicle WaterVehicle displacement JetSki and SailBoat could override or extend the inherited methods JetSki engineCapacity Accelerate() Stop() Turn_right() ... SailBoat noOfSails Accelerate() Stop() Turn right() ... Subclasses are specialized versions of the Superclass

6 - 88

Page 88

Instructor Notes:

Aggregation and Composition
Aggregation “a-part-of” relationship Transitive (A is part of B, B part of C, then A part of C) Asymmetric (A is part of B - does not imply B is part of A) Example: Shipment Order, made up of several products
Shipment Product

Composition A strong form of Aggregation Lifetime of the 'part' is controlled by the 'whole'
Polygon Points

6 - 89

Composition indicates that one class belongs to the other. A polygon is made up of several points. If the polygon is destroyed, so are the points. Aggregation is similar to composition, but is a less rigorous way of grouping things. An order is made up of several products, but a product continues to exist even if the order is destroyed.

Page 89

Instructor Notes:

So, O-O Analysis is.....
Data component
– Identification of Classes (Entiy Classes) – Logical Object Modelling

Behavioural component
– Use Case Identification – Use Cases Elaboration – Use Case Model – So, still a data / function divide?

6 - 90

Page 90

Instructor Notes:

Use Cases vs. Classes
Use Case depicts the functionality that system has to support. Objects have to work together to achieve the needed functionality. Analyze the participation of classes in Use Cases.
– List participating Entity Classes in Use Case descriptions – Participation matrix – CRUD (Create, Read, Update, Delete) analysis

6 - 91

Page 91

Instructor Notes:

Use Case - Class Participation Matrix
UC 1 UC 2 UC 3 UC 4 UC 5 UC 6 Class 1 Class 2 Class 3 Class 4 Class 5 Class 6 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Above Diagram Lists all Identified Use Case all Candidate Business Classes (Except Abstract Classes)

Candidate Class 3 does not participate in any use case. What does this imply? One of the following possibilities is likely:
– Use Cases are incomplete – Candidate Class 3 is not really a valid class for the problem.

6 - 92

Page 92

Instructor Notes:

Exercise 1: Banking Transaction System
A bank has 3 kinds of accounts: savings, current and deposit. Savings accounts pay an interest rate of 3% and can be of cheque or non-cheque type. Cheque accounts require a minimum balance of Rs. 250/-. Deposit accounts pay interest rates dependent on the period and amount. Loans can be availed against deposit accounts, provided the customer has a good credit rating with the bank, upto 80% of the deposit amount. The following transactions have to be supported:

+Opening a/c +Credit and withdrawal transactions; +Request for loan +Interest calculations; +Report on total loan disbursed (from-dt, to-dt); +Total funds in bank (in all a/cs, specified a/cs)
Identify Actors and Use Cases Draw a Use Case Diagram in Rational Rose Write brief outline of one Use Case Develop a Logical Object Model Draw the Logical Object Model (Class Diagram) in Rational Rose

6 - 93

Page 93

Instructor Notes:

Use Case Model
Open Savings Account
<<include>>

<<include>>

Validate Customer Teller Open Current Account
<<include>>

Open Deposit Account

Withdraw

Credit

Loan Admin

Request for Loan

6 - 94

Page 94

Instructor Notes:

Use Case Outline
Name of Use Case: Initiating actor: Business context: Inputs: Output to actor: Main flow: Open Savings Account Teller A prospective customer may request account admin to open a savings account Customer Details Account Number
– – – – – – – Systems asks New / Existing Customer Teller selects Existing Customer (A1) System asks for Customer Details Teller Supplies Customer Details System validates Customer Details (A2) Teller confirms Account Creation System opens a Savings Account A1: Teller Selects New Customer A2: (Customer validation fails) Systems displays message saying customer not eligible and the reason

Alternate flow:
– – –

6 - 95

Page 95

Instructor Notes:

Logical Object Model
Cust omer
Cust ID : Integer Name : String 1..*

owns
0..*

Account
Account No : Long Date of Opening : Date 0..*

Ac count Transact ion Transac tion ID : Int eger Ty pe : String Amount : Double

Savings Account
Ba lance : Dou ble Ch eck : Boo lea n

Current Account Balance : Double Overdraft Limit : Double

Loan
Loan ID : Integer Amount : Double

availed against
0.. * 1

Deposit Account Maturity _Date : Dat e Maturity _Amt : Double

6 - 96

Page 96

Instructor Notes:

Exercise 2 – Singapore State University
Singapore State University (SSU)
– Course Registration System
• Process of assigning professors to courses • Registration of students to courses

To be completed in batches of 2 people

SSU - Problem Statement

6 - 97

Page 97

Instructor Notes:

Exercise 2.1 - Identifying Actors
Exercise: Identify Actors: 15 mins Helpful questions
– Who is interested in a certain requirement? – Where in the organization is the system used? – Who will benefit from the use of the system? – Who will supply the system with this information, use this information, and remove this information? – Who will support and maintain this system? – Does the system use an external resource? – Does one person play several different roles? – Do several people play the same role? – Does the system interact with a legacy system?

After Actor identification, add a brief description for each actor to the model: 10 mins

6 - 98

Page 98

Instructor Notes:

2.1 Solution
Remember, an Actor may
Only input information to the system Only receive information from the system Both input and receive information to and from the system

-

Actors in the SSU Course Registration System
The above questions are answered as follows:

Students want to register for courses Professors want to select courses to teach The Registrar must create the curriculum and generate a catalog for each semester The Registrar must maintain all the information about courses, professors, and students The Billing System must receive billing information from the system. Based on the above answers, the following actors have been identified:
Student, Professor, Registrar, and the Billing System

-

Actor descriptions for this system:
Student: a person who is registered to take classes at the University Professor: a person who is certified to take classes at the University Registrar: the person who is responsible for the maintenance of the SSU Course Registration system Billing System: the external system responsible for student billing

6 - 99

Page 99

Instructor Notes:

Exercise 2.2 – Identify Use-Cases
Exercise: Identify UCs: 20 mins Helpful questions
– What are the tasks of each actor? – Will any actor create, store, change, remove, or read information in the system? – What use case will create, store, change, remove, or read this information? – Will any actor need to inform the system about sudden, external changes? – Does any actor need to be informed about certain occurrences in the system? – What use cases will support and maintain the system? – Can all functional requirements be performed by the use cases?

6 - 100

Page 100

Instructor Notes:

Solution 2.2
Remember, an Use Case represents
The functionality provided by the system. That is, what capabilities will be provided by an actor by the system?

-

Use Cases in the SSU Course Registration System (The above questions are answered as follows)
The following needs must be addressed by the system: The Student actor needs to use the system to register for courses After the course selection process is completed, the Billing System must be supplied with Billing information The Professor actor needs to use the system to select the courses to teach for a semester, and must be able to receive a course roster from the system The Registrar is responsible for the generation of the course catalog for a semester, and for the maintenance of all information about the curriculum, the students, and the professors needed by the system.

-

Based on the above answers, the following Use Cases have been identified: - Register for courses - Select courses to teach - Request course roster - Maintain course information - Maintain professor information - Maintain student information - Create course catalog

6 - 101

Page 101

Instructor Notes:

Actor – UC mapping
Use-Cases identified:
– Register for courses – Select courses to teach – Request course roster – Maintain course information – Maintain student information – Maintain professor information – Create course catalog <--Student <--Professor <--Professor <--Registrar <--Registrar <--Registrar <--Registrar

6 - 102

Page 102

Instructor Notes:

Exercise 2.3 - Creating Use Case diagram
Create the master use case diagram for Exercise 2 (10 mins)

6 - 103

A USE CASE diagram is a graphical view of some or all of the actors, use cases, and their interactions identified for a system.

Page 103

Instructor Notes:

Solution 2.3
Fig: Main Use Case Diagram

Select courses to teach Student Register for courses Request course roster Billing System Maintain professor information Maintain course information Professor

Create course catalog

Registrar

Maintain student information

6 - 104

Page 104

Instructor Notes:

Solution 2.3 (cont’d)
Fig: Additional Use Case Diagram

Professor

Select Courses To Teach <<include>>

Request course roster <<include>>

Validate user

6 - 105

Page 105

Instructor Notes:

Exercise 2.4 - Defining an Use Case
Brief description of Use-Case: Select Courses To Teach (10 mins)
– Document flow of events for the Use-Case – When and how the use-case starts and ends – What interaction the use case has with the actors – What data is needed by the use case – The normal sequence of events for the use case – The description of any alternate or exceptional flows

6 - 106

Page 106

Instructor Notes:

Solution 2.4
X X.1 X.2 X.3 X.4 Flow of Events for the <name> Use Case Preconditions Main Flow Subflows (if applicable) Alternative Flows

where X is a number from 1 to the number of use cases.

Use Case - Select Courses To Teach

6 - 107

The flow of events documentation is typically created in the Elaboration phase in an iterative manner. At first, only a brief description of the steps needed to carry out the normal flow of the use case (i.e. what functionality is provided by the use case) is written. As analysis progresses, the steps are fleshed out to add more detail. Finally, the exceptional flows are added to the use case (the “what…if” part of the flow of events).

Page 107

Instructor Notes:

OO Design
Application Architecture - Identifying classes other than Entity (analysis) classes:
– Boundary Classes • UI Classes • DB Classes • Interface Classes – Control Classes

Assignment of Operations to Classes
– Sequence Diagram

Physical Object Model Physical Data Model
6 - 108

Page 108

Instructor Notes:

Architectural Concerns
Simplification of design / coding Maintainability Reuse

6 - 109

Page 109

Instructor Notes:

Architecture
Entity Classes
– Business Classes / Analysis Classes

Boundary Classes
– Data Base (DB) Classes – User Interface (UI) Classes – Interface Classes

Control Classes
– Coordination and sequencing – Policy
Confirms to Model View Controller (MVC) Pattern

Each of these class types can have inheritance hierarchies of their own.
A given inheritance hierarchy consists of only one type of class - entity, interface or control.

6 - 110

Page 110

Instructor Notes:

Finding Entity Classes
Find noun and noun-phrases that are part of the problem domain First step is to examine responsibilities documented in the flow of events for the identified use cases “Model” in MVC terminology E.g. Professor
Professor Entity Class

6 - 111

Covered earlier under “Finding Classes”

Page 111

Instructor Notes:

Finding Boundary Classes
They handle the communication between the system surroundings and the inside of the system They can provide the interface to a user or to another system Typically Database, UI, Interface classes Boundary classes chosen at the Elaboration phase are typically at a high-level
– E.g. an UI window could be included, but not each of its dialog boxes and buttons

“View” in MVC terminology

Account Form Boundary Class 6 - 112

e.g. Account UI screen is a boundary class at this stage

Page 112

Instructor Notes:

Finding Control Classes
Control classes coordinate the events needed to realize the behavior specified in the use-case These classes contain the business logic required to control the sequence of events
Account Manager Control Class

Choose carefully. Keep business logic relevant to entity classes within those classes – only separate out sequencing logic into control classes
– E.g. in adding courses for the semester, which class knows how to add the course to a student’s list? Student class, Course class or control class?

In the early stages of the Design phase, a Control class is added for each actor/use case pair. “Controller” in MVC terminology

6 - 113

Control class: used to model sequencing behavior for use-cases. In the early stages of the Elaboration phase, a Control class is added for each actor/use case pair. As A&D continues, control classes may be eliminated, split up or combined.

Page 113

Instructor Notes:
Introductions, instructor and students. Get to know everyone. Find out •Their technical background (i.e., software development and OO experience), •What they do in their jobs, •What they are expecting from the course i.e., why are they here), and •How they plan to use the information they receive. Discuss how the student objectives fit into the presented course objectives. Once you have identified the objectives, they can be used as guidelines to measure the effectiveness of the course throughout the week. Capture this on an easel page so you can hang it up and keep referencing it. Introduce yourself. Hand out business cards. Note: The student introductions and expectation-setting is done after the course has been introduced because it tends to focus the students’ goals and expectations a bit.

Documenting Classes
Should state the purpose of the class, and not the structure E.g. Student class:
– Information needed to register and bill students. A student is someone currently registered to take classes at the University

Wrong documentation:
– The name, address, and phone number of a Student

6 - 114

Difficulty in naming or documenting a class may be an indication that it is not a good abstraction.

Page 114

Instructor Notes:

Sequence Diagram

: Teller

: Account UI

: Savings Account

: Customer

: Customer DB

: Account DB

1: Open Savigs Account 2: New Account 3: Validate 4: Get

5: Create

Use Case – Open Savings Account, Main Flow

6 - 115

Page 115

Instructor Notes:
Introductions, instructor and students. Get to know everyone. Find out •Their technical background (i.e., software development and OO experience), •What they do in their jobs, •What they are expecting from the course i.e., why are they here), and •How they plan to use the information they receive. Discuss how the student objectives fit into the presented course objectives. Once you have identified the objectives, they can be used as guidelines to measure the effectiveness of the course throughout the week. Capture this on an easel page so you can hang it up and keep referencing it. Introduce yourself. Hand out business cards. Note: The student introductions and expectation-setting is done after the course has been introduced because it tends to focus the students’ goals and expectations a bit.

Exercise 2.6 - Sequence diagram
Draw a complete sequence diagram for “Add a Course Offering” scenario (Use Case: Select Courses To Teach) (10 mins)

6 - 116

Page 116

Instructor Notes:
Introductions, instructor and students.

Solution 2.6
Fig: Sequence diagram – Select Courses to Teach

:Professor

:ProfessorCourseOptions

Get to know everyone. Find out •Their technical background (i.e., software development and OO experience), •What they do in their jobs, •What they are expecting from the course i.e., why are they here), and •How they plan to use the information they receive. Discuss how the student objectives fit into the presented course objectives. Once you have identified the objectives, they can be used as guidelines to measure the effectiveness of the course throughout the week. Capture this on an easel page so you can hang it up and keep referencing it. Introduce yourself. Hand out business cards. Note: The student introductions and expectation-setting is done after the course has been introduced because it tends to focus the students’ goals and expectations a bit.

:course :AddACourseOffering :ProfessorCourseManager

Enter password Enter password Enter semester Add an offering display Select Math 101 getOfferings(course) Display offerings Select Offering
setProfessor(Professor, Course, CourseOffering) setProfessor(Professor, CourseOffering)

getOfferings( )

6 - 117

Page 117

Instructor Notes:

Model Validation: Scenario walk-through
Go thru the high-risk scenarios as represented by a sequence or collaboration diagram Since each message represents behavior of the receiving class, verify that each message is captured as an operation on the class diagram Verify that two interfacing objects have a pathway for communication via either an association or aggregation For each class represented on the class diagram, make sure the class participates in at least one scenario For each operation listed for a class, verify that either the operation is used in at least one scenario or it is included for completeness Finally verify that each object shown in a sequence or collaboration belongs to a class on the class diagram

6 - 118

Page 118

Instructor Notes:

Physical Object Model
LOM + Boundary Classes + Control Classes + Operations Physical Object Model (POM) POM provides a complete design representation of application OO Tools such as Rational Rose can generate skeleton code from a POM

6 - 119

Page 119

Instructor Notes:

Physical Data Model
1. 1st cut design
1. 2. 3. Only business classes map to tables One table per class Standard ERD rules apply

2.
o o o

Inheriting classes – refine the above using one option
Retain all class tables Eliminate abstract superclass tables Eliminate child class tables

6 - 120

Page 120

Instructor Notes:

Case Study: Order Processing System

Case Study Doc

6 - 121

Page 121

Instructor Notes:

Summary
System Analysis and Design
– Data modelling – Process modelling

Introduction to Object Orientation (OO)
– Object, Class, Attribute, Method – Association, Aggregation, Encapsulation, Generalization, Polymorphism

Unified Modelling Language (UML)
– Static Diagrams: Use Case, Class, Object, Component, Deployment – Dynamic Diagrams: Sequence, Collaboration, Statechart, Activity

OO Analysis
– Logical Object Modelling (LOM) – Use Case Analysis

OO Design
– – – – Application Architecture Object Interaction Diagram (Sequence diagram) Physical Object Model (POM) Physical Data Model (PDM)

6 - 122

Page 122

Instructor Notes:

References
Grady Booch, Object Solutions, Addison-Wesley, 1995. Grady Booch , Object Oriented Analysis and Design. Grady Booch, Ivar Jacobson, and James Rumbaugh, Unified Modelling Language 1.3, White paper, Rational Software Corp., 1998. Grady Booch, Jim Rumbaugh, and Ivar Jacobson, Unified Modelling Language-User's Guide, Addison-Wesley, 1999. Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard, Object-Oriented Software Engineering-A Use Case Driven Approach, Wokingham, England, Addison-Wesley, 1992. Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999. James Rumbaugh, Blaha, Premerlani, Eddy & Lorensen Object Oriented Modeling and Design.

6 - 123

Page 123

Instructor Notes:

References (contd.)
Philippe Kruchten, The 4+1 View Model of Architecture, pp.42-50, IEEE Software, 12 (6), November 1995. Philippe Kruchten, A Rational Development Process, CrossTalk, 9 (7), pp.11-16, STSC, Hill AFB, UT. Philippe Kruchten, Rational Unified Process-An Introduction, AddisonWesley, 1999. Philippe Kruchten, Rational Unified Process: Best Practices for Software Development Teams A Rational Development Process Terry Quatrani, Visual Modelling with Rational Rose and UML, Addison-Wesley, 1992.

6 - 124

Page 124