Intoduction to UML and OO Analysis 1.0_updated

INTERNAL

January 21, 2009

Introduction to UML & Object Oriented Analysis

Object Oriented ModellingINTERNAL

- 2 -

Course Objectives - OOM

• To understand the concepts of object oriented analysis and design

• To be able to analyze and design a case study of moderate complexity using the object oriented approach


- 3 -

Introduction“Owning an hammer doesn’t make one an architect”

Knowing a OO language like Java is a necessary but insufficient first step to create object systems!

Knowing How to Think in Objects is critical

We will try to cover many possible activities, artifacts, principles and guidelines which help us to effectively think in objects

In all these activities a critical ability in OO Development is to skillfully assign responsibilities to software objects.

In this first part we cover OO Analysis – It’s an investigation of the domain objects (doing the right thing)

In the next part we cover OO Design – where we focus on a conceptual solution that fulfills the requirements .Its about doing the thing right


- 4 -

Overview – OOMI Orientation Session 1

• Introduction

• Introduction to UML– Evolution of UML– Model Views and UML Diagrams

• OO Requirement Analysis– Analysis Approach– Use Case Model– Domain Model


- 5 -

What is UML?

• The Unified Modeling Language (UML) is a family of graphical notations, that help in visualizing, specifying, constructing and documenting software systems.

• It can be used with all processes, throughout the software development life cycle, and across different implementation technologies


- 6 -

Evolution of UML–Rumbaugh - Analysis oriented (OMT*)–Booch - Design and Construction oriented–Jacobson - Use case oriented (OOSE **)

Unification: • The independent methods were evolving towards

one another.• Jim Rumbaugh, Grady Booch and Ivar Jacobson

joined Rational Software Corporation to unify their methods.

• * Object Modeling Technique**Object Oriented Software Engineering

UML 2.0 notations will be used for Object Oriented Modeling during ILP.


- 7 -

Model Views and UML Diagrams

•Use CaseUser View

Behavioral View •Sequence

Structural View •Class

Implementation View •Component

Environment View •Deployment

User view

Use case


- 8 -

Model Views

• User View: Illustrates how the end user views the system

• Structural View: Illustrates the static feature of a model that includes classes, attributes, behaviours and relationship between the classes.

• Behavioral View: Illustrates the interactions between the objects and how the group of objects collaborate in some behaviour

• Component View: illustrate the organizations and dependencies among software components, including source code components, run time

components, or an executable component.

• Deployment View: This view shows a system’s physical layer, revealing which piece of software run on what pieces of hardware.


- 9 -

Object Oriented Analysis

In object oriented approach, in the Analysis phase the emphasis is on discovering and describing objects in the problem domain.

In OO Analysis, focus is on doing the right thing.

OO Analysis includes

1. Use Case Model: •Use Cases : Stories or scenarios of how people use the system•Use Case Diagram : Gives a high level view of how different users interacts with the system (through use cases)

2. Domain Model: A description of the domain from the perspective of objects. In this model we identify the concepts, attributes and associations


- 10 -

Requirements Analysis 1. Identify the users and their goals

2.Develop Use Cases Model

(Use Cases & Use Case Diagram)

3. Develop Domain Model

(Conceptual Class Diagram)


- 11 -

Use Case Model : User View

Use Case Model : Use Cases + Use Case Diagram

•It captures the functionality the system should provide from the user’s perspective

•They do not specify how the system actually implements the system.

•in essence it helps to systematically identify system’s responsibilities in the user requirements perspective


- 12 -

Case Study

get your

hands dirty


- 13 -

Reference Case Study - RequirementABC Bank Automation SystemProblem Statement:

ABC bank plans to automate its current account related activities. A customer can open a current account. There are two types of current accounts:-Cash Credit account and Regular Current account. Cash credit account holders can avail overdraft facility. They can withdraw 10% of their balance amount as overdraft. They cannot withdraw or avail an overdraft if existing overdraft is not paid back. Only privileged customers can open a Cash Credit account. For every 100 transactions made on a regular current account a fee of Rs.100/- is deducted from the account balance. A customer should first provide his details to register in the bank before opening an account. If required he can update his details later. Clerk can view details of registered customers. The customer may have one or more accounts in the bank. He can deposit or withdraw money from his account. He can also close his account. The clerk generates a statement of the transactions performed on an account to verify the account transactions.

Assumption : Customer interacts with the system through the clerk


- 14 -

Reference Case Study – Identify Actors and their goals

?

Goals of Clerk• Adding a new customer• Updating existing customer details• Viewing existing customer details• Opening a current account• Handling transactions such as

withdraw, deposit and overdraft for a current account

• Closing a current account• Generate Transaction statement

1.Stake Holders ?

2.Actors ? • An Actor is a role that a user plays when invoking a

use case.• A single user can represent multiple actors• Actors need not be always human, they can

represent even external systems.

3.Goals of each actor ?

Clerk

ABC

Customer

Bank

ClerkABCCustomer

Bank


- 15 -

Use Cases• Define one use case for each user goal

• Use case express a goal that system must achieve and/or that it must produce

• Use case is a textual description which formally specifies several scenarios.

• A Scenario is a sequence of steps describing an interaction between a user and a system

• A Use Case is a set of scenarios tied together by a common user goal

• Use case has main success scenario and alternate scenarios (extensions) /failure scenarios.


- 16 -

Writing Use Cases – for each actor goalUse Case UC1: Add CustomerLevel: User goalScope: ABC Bank Automation SystemPrimary Actor: ClerkStakeholders and interests:Customer: Wants to register with ABC bank, for availing various current account related activities provided by the bank.Clerk: Wants the system to accurately record the details provided by the customer to register with the bank.ABC Bank: Wants to make customer registration process fast and reliable, Preconditions: noneSuccess Guarantee: Customer details given by the customer is recorded. Customer Id is generated.Main Success Scenario:

1. Customer arrives at ABC bank and provides details for registration. 2. Clerk enters the details into the system3. System validates the customer details.4. System Prompts for confirmation of registration.5. Clerk Confirms registration.– System generates a customer Id for the customer– The customer details are saved in the system– Clerk provides the customer Id to the customer.

Extensions: 3a. Invalid Customer Details

System displays an error message.System displays menu.

5a. Customer requests to stop registration.Clerk cancels registration process.System displays menu

7a. System fails to save the customer details provided.System displays an error message.System displays menu.

• Title <number> <name>

Name should be the goal as a short active verb phrase> • Level <one of: User Goal, Sub function> • Scope <what system is being considered black-box under design> • Stakeholders & their interests• Primary Actor <a role name for the primary actor, or description>

• Preconditions: <what we expect is already the state of the world>

• Success Guarantee:: <the state of the world upon successful completion>

• Main Success Scenario• Extension (s)

Use Case Template


- 17 -

Use Case DiagramUML Use case diagram shows the relationships among actors and use cases within a system.

Goals of Clerk

• Adding a new customer• Updating existing customer details• Viewing existing customer details• Opening a current account• Handling transactions such as

withdraw, deposit and overdraft for a current account

• Closing a current account• Generate Transaction statement

• A use case is represented as a ellipse• Use Cases and actors are connected using associations

Within the same system, use cases relate to each other using generalization, extension or inclusion, Use Case Relations should be sparingly used.

Instead concentrate on the textual description of use case; that's where the real value of the technique lies.


- 18 -

Domain Model Based on User View

Use Case Model

Domain Model

Vision

GlossaryAccount: …Customer: ...

Suggests domain concepts

Scope, goals,actors,

features

Explanation of terms attributes


- 19 -

Domain Model

• A domain model is a visual representation of conceptual classes in a domain

• It’s a conceptual model & Its not a software model.


- 20 -

Discovering Objects for Domain model

Object Oriented methodology favors many different approaches. Some of the methods are listed below:

• List the basic responsibilities that the objects should share. Assign responsibilities to the appropriate objects. Focus on collaborations and responsibilities in the system.

• Create a category list and identify objects in the domain, falling under each category.

• Single out nouns and verbs from the user view/problem statement, and create corresponding classes and operations.


- 21 -

User View suggests domain concepts…Use Case UC1: Add CustomerLevel: User goalScope: ABC Bank Automation SystemPrimary Actor: ClerkStakeholders and interests:Customer: Wants to register with ABC bank, for availing various current account related activities provided by the bank.Clerk: Wants the system to accurately record the details provided by the customer to register with the bank.ABC Bank: Wants to make customer registration process fast and reliable.Preconditions: noneSuccess Guarantee: Customer details given by the customer is recorded. Customer Id is generated.Main Success Scenario:

1. Customer arrives at the bank and provides details for registration. 2. Clerk enters the details into the system3. System validates the customer details.4. System Prompts for confirmation of registration.5. Clerk Confirms registration.– System generates a customer Id for the customer– The customer details are saved in the system– Clerk provides the customer Id to the customer.

Extensions: 3a. Invalid Customer Details

System displays an error message.System displays menu.

5a. Customer requests to stop registration.Clerk cancels registration process.System displays menu

7a. System fails to save the customer details provided.System displays an error message.System displays menu.

2. Customer Id2.Bank

1. Customer Details1.Customer

Attribute CandidatesClassCandidates

Nouns and Noun Phrases Identified from UC1: Add Customer

•Customer Details•Customer•Customer Id•Bank •Clerk **•System ***•Error Message

*Note: Details of clerk is not required in this scenario, so clerk is not considered as a class.**Note: System represents the whole system, its not a candidate for a class.


- 22 -

Domain model - Evolves…

Domain Level Class Diagram based on analysis of UC1 (Reference Case Study)

Five to Fifteen5..15 Zero to Four0..4Six only6One or more1..*Zero or more* Zero or more0..*One only1Zero or one0..1

MeaningNotation

Possible Multiplicity Values


- 23 -

Domain model - Evolves…

Domain Level Class Diagram based on analysis of UC1 & UC4 (Reference Case Study)


- 24 -

Analysis Patterns

• overDraftLimit is an attribute independent of the CashCreditAccount instance

• You may have to know the overdraft Limit for cash credit accounts even when no cash credit account exist.

• Over draft limit is unnecessarily repeated for all the instances of cash credit account.

Solution- Move the overDraftLimit to another class and associate it with CashCreditAccount

Move the overdraftLimit which describes any cashCredit account to a class called cashCreditAccountDescription.

•Now you can get over draft limit of any cash credit a/c even when no cash credit a/c is opened in the system.

•The redundancy of this data is avoided

•This pattern is named as Item-Descriptor Pattern.


- 25 -

Domain Model … Evolves

Domain Level Class Diagram based on analysis of UC1 & UC4 (Reference Case Study)

holds

holds

0…*

0…*

1

1


- 26 -

References

• Larman Craig, Applying UML and Patterns Third Edition, Pearson Education

• Fowler Martin, UML Distilled Third Edition, Addison-Wesley

Documents

Intoduction to UML and OO Analysis 1.0_updated