SS ZG514 Object Oriented Analysis and Design

BITS Pilani
Pilani Campus

BITS Pilani
Pilani Campus

Lecture Session-3
01- 08-13
3

Use Case Diagrams

4
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Fully Dressed Version Template

5
BITS Pilani, Pilani Campus

Full Dressed Use Case ATM Withdraw Funds

6
BITS Pilani, Pilani Campus

Full Dressed Use Case ATM Withdraw Funds

7
BITS Pilani, Pilani Campus

Full Dressed Use Case ATM Withdraw Funds

8
BITS Pilani, Pilani Campus

Steps to write a use case (Important)

Step 1: Find the boundaries of the system (Context diagram, In/out list). Step 2: Brainstorm and list the primary actors. (Actor List) Step 3: Brainstorm and list the primary actors' goals against the system. (Actor-Goal List) Step 4: Write the outermost summary level use cases covering all the above. Step 5: Reconsider & revise the strategic use cases. Add, subtract, merge goals. Step 6: Pick a use case to expand or write a narrative to get acquainted with the material.

BITS Pilani, Pilani Campus

Steps to write a use case (Continue)

Step 7: Fill in the stakeholders, interests, preconditions and guarantees. Double check them. Step 8: Write the main success scenario. Check it against the interests and the guarantees. Step 9: Brainstorm and list possible failure conditions and alternate success conditions. Step 10: Write how the actors and system should behave in each extension. Step 11: Break out any sub use case that needs its own space. Step 12: Start from the top and readjust the use cases. Add, subtract, merge. Double check for completeness, readability, failure conditions.

BITS Pilani, Pilani Campus

BITS Pilani, Pilani Campus

Use case diagram for Monopoly system

12
BITS Pilani, Pilani Campus

Use Case UC1: Play Monopoly Game

Scope : Monopoly application Level : user goal Primary actor : Observer Stakeholder and Interests: Observer: wants to easily observe the output of the game simulation. Main Success Scenario: 1. Observer requests new game initialization, enters number of players. 2. Observer starts play. 3. System displays game trace for next player move Repeat Step 3 until a winner or Observer cancels. Extensions: *a. At any time, System fails: 1. Observer restarts System. 2. System detects prior failure, reconstructs state, and prompts to 13 continue. BITS Pilani, Pilani Campus

Other Requirements
While the primary requirements of a computer system tend to be the functional requirements, i.e.,the list of activities that the system must perform, it is also necessary to capture an number of other requirements to build a system, called non-functional requirements. in a Vision Statement, Glossary, Business (Domain) Rules and Supplementary Specification. Produce only the required (or enough) documentation to produce the desired results efficiently and effectively. Documentation costs money and takes time.
14
BITS Pilani, Pilani Campus

Other Requirement Artifacts

Supplementary Specification Captures and identifies other kinds of attributes, such as reports, documentation, packaging, supportability, licensing, and so forth. Glossary Captures terms and definitions; it can also play the role of a data dictionary. Vision Summarizes the `vision` of the project an executive summary. Business Rules (or Domain Rules) Capture long-living and spanning rules or policies, such as tax laws, that transcend one particular application.

15
BITS Pilani, Pilani Campus

Domain Model

BITS Pilani, Pilani Campus

Use Case Relationships

Use cases, in turn, influence many other analysis, design, implementation, project management and test artifacts. Business Model
Domain Model

VISION Use Case Model GLOSSARY SUPPLEMENTARY SPECIFICATION Interaction Diagrams

Requirements

Design

17
BITS Pilani, Pilani Campus

Objectives
What is domain model

UML notation of domain model

Identify Classes, attributes, associations

BITS Pilani, Pilani Campus

Domain Model
Illustrate meaningful conceptual classes in a realworld problem domain
Identify conceptual classes or domain objects Show associations between them Indicate their attributes when appropriate

No operations/methods Visual dictionary

relevant vocabulary of the domain important abstractions information content
BITS Pilani, Pilani Campus

Objectives Of A Domain Model

Identify concepts related to current development cycle requirements

Create initial conceptual model Identify the conceptual classes. Draw them as classes in a UML class diagram. Identify attributes Add associations and attributes
20
BITS Pilani, Pilani Campus

A Domain Model Is Conceptual

Conceptual Class:

Software Artifacts:
Sale amt item SalesDatabase

vs.

Sale Double amt; Item item; void print()

BITS Pilani, Pilani Campus

Domain Model UML Notation

Illustrated using a set of class diagrams for which no operations are defined. It may contain: Domain Objects or Conceptual Classes Associations between conceptual classes

Attributes of conceptual classes

BITS Pilani, Pilani Campus

Identify Conceptual Classes By Category List

Common Candidates for classes include: Tangible objects, Descriptions, Roles, Places, Transactions, Containers, Systems, Abstract nouns, Rules, Organizations, Events, Processes, Written Materials, Catalogs, Records, Financial Instruments and Services
BITS Pilani, Pilani Campus

 Identify Nouns and Noun Phrases in textual descriptions of the domain. Fully dressed Use Cases are good for this type of linguistic analysis. Its not strictly a mechanical process

Identify Conceptual Classes By Noun Phrase

Words may be ambiguous

Different phrases may represent the same concepts.

BITS Pilani, Pilani Campus

Steps To Create A Domain Model

Identify Candidate Conceptual classes Draw them in a Domain Model Add associations necessary to record the relationships that must be retained Add attributes necessary for information to be preserved Apply existing Analysis Patterns

BITS Pilani, Pilani Campus

Conceptual Models - Association

Objective
Identify associations within a conceptual model distinguish between need-to-know associations from comprehension-only associations

Associations derived from the Common associations list Represented as a solid line between objects
the association is inherently bi-directional may contain a cardinality or multiplicity value optionally contains an arrow for easy reading

BITS Pilani, Pilani Campus

Associations
An association is a relationship between classes that indicate some meaningful and interesting relationship
All associations needs to preserve for some duration are discovered and discard all other, theoretical associations in our domain model.

Product
*Prod No. Description Unit Price Qty in Stock

Customer

buys

*A/c No. Name Address Phone No. Balance

BITS Pilani, Pilani Campus

Finding Associations
High priority associations

A is a physical or logical part of B A is physically or logically contained in/on B A is a member of B A is related to a transaction B A owns B

BITS Pilani, Pilani Campus

Association Guidelines
Focus on those associations for which knowledge of the relationship needs to be preserved for some duration (need-to-know associations) More important associations to identify concepts than

Too many associations tend to confuse the conceptual model Avoid showing associations redundant or derivable
BITS Pilani, Pilani Campus

Naming Associations
Association names should start with a capital letter (same as concepts, objects) eg PaidBy, Paid-by Noun phrases help identify objects/concepts Verb phrases help identify associations Use hyphens to separate words when a phrase is used to name something
BITS Pilani, Pilani Campus

Roles in Associations
Each of the two ends of an association is called a role. Roles have name multiplicity expression navigability

BITS Pilani, Pilani Campus

Multiplicity
Multiplicity defines how many instances of type A can be associated with one instance of type B at a particular moment in time Multiplicity indicates the number of objects of one class that may be related to a single object of an associated class Can be one of the following types
*, 1 to 1, 1 to 0..*, 1 to 1..*, 1 to n, 1 to 1..n

Product
*Prod No. Description Unit Price Qty in Stock

Customer

Teacher
*Employee No. Name Age Sex Salary

buys

teaches
1

Course

*A/c No. Name Address Phone No. Balance

*Course No. *Date Room No. Max Enrol

BITS Pilani, Pilani Campus

Association Role
The "face" that a class plays in the association.

BITS Pilani, Pilani Campus

Multiplicity Values

BITS Pilani, Pilani Campus

Multiple Associations
Two classes may have multiple associations between them in a UML class diagram; this is not uncommon:

Multiple associations between two types

BITS Pilani, Pilani Campus

How to Find Associations?

what need to know associations are necessary given our current list of candidate concepts? Using a list of association categories.
Association Category A is a transaction related to another transaction B A is a product or service for a transaction (or line item) B A is a line item of a transaction B Examples CashPayment-Sale CancellationReservation Item-SalesLineItem Flight-Reservation SalesLineItem-Sale

BITS Pilani, Pilani Campus

Attributes
Attribute - is a logical data value of an object.
It is a named property of a class describing values held by each object of the class

Attribute Type: A specification of the external behavior and/or the implementation of the attribute Include the following attributes in a domain model those for which the requirements suggest or imply a need to remember information For example, a sale receipt normally includes a date and time attribute
BITS Pilani, Pilani Campus

UML Attribute Notation

Attributes reside in the second compartment of a concept box Format is name: type Attributes should be pure data values Attributes in a conceptual model should preferably be simple attributes or pure data values Common simple attribute types include
boolean, date, number, string, time

BITS Pilani, Pilani Campus

Types Of Attributes
Pure data values - expressed as attributes; they do not illustrate specific behaviors;
Example - Phone number A Person can have many Phone numbers

Non-primitive attribute types represent attributes as non-primitive types (concepts or objects) if it is composed of separate sections (name of a person) there are operations associated with it such as validation it is a quantity with a unit (payment has a unit of currency)

BITS Pilani, Pilani Campus

Problem Statement for ATM

Design the software to support a computerised banking network including both human cashiers and automated teller machines (ATMs) to be shared by a consortium of banks. Each bank provides its own computer to maintain its own accounts and process transactions against them. Cashier stations are owned by individual banks and communicate directly with their own bank computers. Human cashiers enter account and transaction data. ATMs communicate with a central computer which clears transactions with the appropriate banks. an ATM accepts a cash card, interacts with the user, communicates with the central system to carry out the transaction, dispenses cash and prints receipts. The system requires appropriate record keeping and security provisions. The system must handle concurrent accesses to the same account correctly. The banks will provide their own software for their their own computers; you are to design the software for the ATMs and the network. The cost of the shared system will be apportioned to the banks according to the number of customers with cash cards.
BITS Pilani, Pilani Campus

Noun Phrase Analysis

Identifying objects From the nouns in the problem statement Eliminate the redundant irrelevant - those unrelated to the problem Vague - ill-defined boundary, very broad in scope attributes - things that describe an object operations - things that manipulate objects implementation constructs - extraneous to real world must be eliminated from analysis model, needed during design, but not now.
BITS Pilani, Pilani Campus

Identify Objects and Classes

BITS Pilani, Pilani Campus

Candidate classes for ATM Example

BITS Pilani, Pilani Campus

Analysis: Identify Objects and Classes

BITS Pilani, Pilani Campus

Analysis: Identify Objects and Classes

BITS Pilani, Pilani Campus

Domain Modeling - Identifying classes

e.g. ATM system - Potential Object List Software Central Computer Banking Network Cash Card Cashier User ATM Cash Consortium Receipt Bank Computer System Account Recordkeeping provision Transaction security provision Cashier station Access Account data Cost Transaction Data Customer

BITS Pilani, Pilani Campus

Object Modeling Keeping the right classes

Object Access Account Account data ATM Bank Computer Banking Network Cash Cash Card Cashier Cashier station Central Computer Consortium Cost Customer Receipt Recordkeeping provision Security Provision Software System Transaction Transaction Data User Elimination Reason Implementation * Attribute * * Vague Attribute * * * * * Irrelevant * Attribute Vague Vague Implementation Vague * Vague Redundant

KEEP: KEEP: Account, ATM, Account, Bank, ATM, Bank Computer, Bank, Cash Cards, Cashier, Bank Computer, Cashier Station, Cash Cards, Central Computer, Cashier, Customer, Consortium, Transaction Cashier Station,

Central Computer, Consortium, Customer, Transaction

BITS Pilani, Pilani Campus

Object Modeling - Data Dictionary

Prepare a Data Dictionary/Description of each class Account - a single account in a bank against which transaction can be applied. Accounts may be of various types, at least checking or saving. A customer can hold more than one account. ATM - a station that allows customers to enter their own transactions using cash cards as identification. The ATM interacts with the customer to gather transaction information, sends the transaction information to the central computer for validation and processing, and dispense cash to the user. Bank - .
BITS Pilani, Pilani Campus

Analysis: Identify Associations

BITS Pilani, Pilani Campus

Analysis: Identify Associations

BITS Pilani, Pilani Campus

Analysis: Identify Associations

BITS Pilani, Pilani Campus

Initial Domain Model

0..* Consortium Consists of Bank Holds 0..* Account Concern s Accesses Has Customer

Owns Central Computer

0..* Communicates with Communicates with

Owns

Owns Employs 0..*

Bank Computer0..*

Cashier

Concerns

Communicates with 0..*

0..* Cashier Station

Entered 0..*

0..*

Has

Cashier transaction

0..*
ATM Entered On

Entered On 0..* Remote transaction 0..* Authorised by

0..*
Cash Card 0..*

BITS Pilani, Pilani Campus

Complex Attributes
It is desirable to show non-primitive attributes as concepts in a conceptual model

Destination a Complex concept

Flight

destination Flies-to
1 1

Flight

Airport

BITS Pilani, Pilani Campus

Domain Model
concept or domain object Sales LineItem quantity 1..* association Stocked-in Contained-in 1 Sale attributes date time 1 Paid-by 1 Payment amount Store address name 1 Houses 1..* Register Captured-on 1 1 0..1 Records-sale-of 1 Item

0..1

BITS Pilani, Pilani Campus

Dos and Donts in Conc. Model

55
BITS Pilani, Pilani Campus

Think of Conceptual Classes in terms of

Conceptual Classes An idea, thing, or object Defined as: Symbol words or image representation Intension the definition Extension set of examples Example: Symbol = Sale Intension = represents the event of a purchase transaction and has a date/time Extension = all examples of sales or the set of all sales instances
BITS Pilani, Pilani Campus

Domain Model Conceptual Class

Sale date time concept's symbol

"A s ale rep res ents the eve nt of a purchas e tran saction. It has a date and time."

concept's intens ion

sale-1 sale-2

sale-3

concept's extension

sale-4

BITS Pilani, Pilani Campus

Domain models are a stepping step to design

UP Domain Model Stakeholder's view of the noteworthy concepts in the domain. A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter. This reduces the representational gap. This is one of the big ideas in object technology. Payment amount: Money getBalance(): Money 1 Pays-for 1 date: Date startTime: Time getTotal(): Money ... Payment amount inspires objects and names in Sale Sale 1 Pays-for 1 date time

UP Design Model The object-oriented developer has taken inspiration from the real world domain in creating software classes. Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.

BITS Pilani, Pilani Campus

Finding Conceptual Classes

Three main strategies:
Reuse or modify existing models! (do this as much as possible!); Think hard and use a category list; Identify noun phrases in requirements;

All 3 strategies should be used initially :

even if that leads to much overlapping; it should not take too long anyway; best way to arrive at a rich set of conceptual classes;

BITS Pilani, Pilani Campus

Category List
Using a Category List
Class Category Use a list Conceptual of categories and see if they applyExamples within the transactions problem domain : this yields candidate conceptual classes. business Sale, Payment Guideline: These are critical (they involve money), so start with transactions. transaction line items SalesLineItem Guideline: Transactions often come with related line items, so consider these next.

where is the transaction recorded? Guideline: Important.

product or service related to a transaction or transaction line item Guideline: Transactions are for something (a product or service).

Register, Ledger

Item

BITS Pilani, Pilani Campus

Continued Conceptual Class Category roles of people or organizations related to the transaction; actors in the use case Guideline: We usually need to know about the parties involved in a transaction. place of transaction; place of service Examples Cashier, Customer, Store MonopolyPlayer Passenger, Airline Store Airport, Plane, Seat

noteworthy events, often with a time or place we need to remember

physical objects Guideline: This is especially relevant when creating device-control software, or simulations.

Sale, Payment MonopolyGame Flight

Item, Register Board, Piece, Die Airplane

catalogs Guideline: Descriptions are often in a catalog.

descriptions of things

ProductCatalog FlightCatalog
ProductDescription FlightDescription
BITS Pilani, Pilani Campus

Continued Conceptual Class Category containers of things (physical or information) things in a container other collaborating systems Examples Store, Bin Board Airplane Item Square (in a Board) Passenger CreditAuthorizationSyste m AirTrafficControl Receipt, Ledger MaintenanceLog Cash, Check, LineOfCredit TicketCredit DailyPriceChangeList RepairSchedule

records of finance, work, contracts, legal matters financial instruments

schedules, manuals, documents that are regularly referred to in order to perform work

BITS Pilani, Pilani Campus

A Common Mistake - Classes As Attributes

Rule: If we do not think of a thing as a number or text in the real world, then it is probably a conceptual class. If it takes up space, then it is likely a conceptual class.

A Store is not an attribute of a Sale A Destination is not an attribute of a flight

BITS Pilani, Pilani Campus

Using a Noun Phrases Identification

Requirements must be read very closely (especially fullydressed use cases) and nouns or sequences of nouns identified: This yields candidate conceptual classes.

Example from the Process Sale fully dressed use case note: restrict to current requirements (e.g. cash payment only)

BITS Pilani, Pilani Campus

Using a Noun Phrases Identification

Main Success Scenario (or Basic Flow) 1. Customer arrives at POS checkout with goods and/or services to
purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules. Cashier repeats steps 3-4 until indicates done. 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment. 8. System logs completed sale and sends sale and payment information to the external Accounting system (for accounting and commissions) and Inventory system (to update inventory). 9. System presents receipt. 10. Customer leaves with receipt and goods (if any).
BITS Pilani, Pilani Campus

Using a Noun Phrases Identification

Extensions (or Alternative Flows): [] Paying by cash: Cashier enters the cash amount tendered. System presents the balance due, and releases the cash drawer. Cashier deposits cash tendered and returns balance in cash to Customer. System records the cash payment Using these approaches we end up with candidate conceptual classes: Some will be outside the current requirements (e.g. price rules); Some will be redundant (e.g. goods is better described by item); BITS Pilani, Pilani Campus

Concepts in POS domain

POST Item Sale Store Payment SalesLineItem Product Specification ProductCatalog Customer Cashier Manager
67
BITS Pilani, Pilani Campus

POS Conceptual Classes

There is no correct list of conceptual classes!

Register Item Store Sale

Sales LineItem

Cashier

Customer

Ledger

Cash Payment

Product Catalog

Product Description

Initial POS Domain Model

BITS Pilani, Pilani Campus

Description Classes
Think about description classes when creating an initial list of conceptual classes (or during refactoring): A description class contains information that describes something else;
Item description price serial number itemID Worse

ProductDescription description price itemID Describes 1 Item

Better serial number

BITS Pilani, Pilani Campus

Description Class
Add a description class (for example, Product Description) when:

There needs to be a description about an item or service, independent of the current existence of any examples of those items or services. Deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained, but was incorrectly associated with the deleted thing. It reduces redundant or duplicated information.
BITS Pilani, Pilani Campus

Associations
An association is a relationship between classes that indicate some meaningful and interesting relationship there is a need to remember what SalesLineItem instances are associated with a Sale.
association

Register

Records-current 1 1

Sale

BITS Pilani, Pilani Campus

Associations
Naming

Class Name -Verb Phrase- Class Name Sale Paid-by Cash Payment Sale Uses Cash Payment (bad example) Player Is-on Square Player Has Square (bad example) Readable and meaningful Avoid Has or Uses
BITS Pilani, Pilani Campus

Multiplicity
The

multiplicity value communicates how many instances can be validly associated with another, at a particular moment, rather than over a span of time.

BITS Pilani, Pilani Campus

Finding Associations
By reading the current, relevant, requirements and asking ourselves what information is needed to fulfil these requirements: what need to know associations are necessary given our current list of candidate concepts Using a list of association categories.

Association Category A is a transaction related to another transaction B A is a product or service for a transaction (or line item) B A is a line item of a transaction B

Examples CashPayment-Sale Item-SalesLineItem SalesLineItem-Sale

BITS Pilani, Pilani Campus

Finding Associations
Continued Association Category Examples

A is a role related to a transaction B

A is a physical or logical part of B

Customer-Payment
Drawer-Register Square-Board Register-Store

A is physically or logically contained in/on B

A is a description for B A is known/logged/recorded/reported/captured in B

ProductDescription-Item Sale-Register Piece-Square

BITS Pilani, Pilani Campus

Finding Associations
Association Category A is a member of B A is an organizational subunit of B

Continued

Examples Customer-Payment Cashier-Store Player-MonopolyGame DepartmentStore Cashier-Register Player-Piece SalesLineItem-SalesLineItem Square-Square

BITS Pilani, Pilani Campus

A is an organizational subunit of B A uses or manages or owns B

A is next to B

Records-sale-of Product Description Contains 1 1 0..1 Sales LineItem 1 Recordsaccountsfor 1 Used-by Describes 1..*

Ledger

Product Catalog

*
Store Stocks 1 1

*
Item

1 1..* Contained-in 1 Sale Logscompleted

1..*

Houses

1..* Register

*
Captured-on 0..1 1

Partial POS Domain Model

Works-on 1 Cashier

Paid-by 1 CashPayment

Is-for 1 Customer

BITS Pilani, Pilani Campus

Relate with associations, not attributes

Cashier Worse name currentRegister not a "data type" attribute

Cashier Better name

Uses

Register number

BITS Pilani, Pilani Campus

Ways To Indicate Data Type Property

Address Store 1 1 street1 street2 cityName ...

ItemID OK Product Description 1 1 id manufacturerCode countryCode

OK

Product Description itemId : ItemID

Store address : Address

BITS Pilani, Pilani Campus

Modeling Quantities
Payment amount : Number

not useful

Payment

Has-amount

Quantity 1 amount : Number

Is-in

Unit 1 ...

*
Payment amount : Quantity

quantities are pure data values, so are suitable to show in attribute section

better

Payment amount : Money

variation: Money is a specialized Quantity whose unit is a currency

BITS Pilani, Pilani Campus

NextGen POS Partial Domain Model

Records-sale-of Product Description Contains 1 1 0..1 Sales LineItem quantity 1..* Contained-in 1 Sale dateTime / total 1 Paid-by 1 CashPayment amountTendered 1 Logscompleted 1 Recordsaccountsfor 1 Used-by 1..* itemID description price Describes Ledger Product Catalog

*
Store Stocks name address 1 1

*
Item

1..*

Houses

1..* Register id 1

*
Captured-on 1 0..1

Is-for 1 Customer

Works-on 1 Cashier id

BITS Pilani, Pilani Campus

Monopoly Partial Domain Model

BITS Pilani, Pilani Campus

Summary
A domain model -its concepts , terminology, and the relationships Identifying classes, attributes, associations

UML Notation of domain model

A relatively useful model has been created for the domain of the POS application, Monopoly.
BITS Pilani, Pilani Campus