ss zg514-l4.pptfdsf

7/27/2019 SS ZG514-L4.pptfdsf

1/82

BITS PilaniPilani Campus


SS ZG514Object Oriented Analysisand Design


2/82


Lecture Session-301- 08-13

3


3/82

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

Use Case Diagrams

4


4/82

BITS Pilani, Pilani Campus

5

Fully Dressed Version Template


5/82


Full Dressed Use Case ATM

Withdraw Funds

6


6/82



Withdraw Funds

7


7/82BITS Pilani, Pilani Campus


Withdraw Funds

8



Step 1: Find the boundaries of the system (Contextdiagram, In/out list).

Step 2: Brainstorm and list the primary actors. (ActorList)

Step 3: Brainstorm and list the primary actors' goalsagainst the system. (Actor-Goal List)

Step 4: Write the outermost summary level use casescovering 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.

Steps to write a use case (Important)



Step 7: Fill in the stakeholders, interests, preconditions andguarantees. Double check them.

Step 8: Write the main success scenario. Check it againstthe 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 ownspace.

Step 12: Start from the top and readjust the use cases. Add,subtract, merge. Double check for completeness,readability, failure conditions.

Steps to write a use case (Continue)



12

Use case diagram for Monopoly

system

U C UC1 Pl M l



13

Scope : Monopoly applicationLevel : 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 tocontinue.

Use Case UC1: Play Monopoly

Game



While the primary requirements of a computer system tendto 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-functionalrequirements.

in aVision Statement, Glossary, Business (Domain)Rules and Supplementary Specification.

Produce only the required (or enough)documentation to produce the desired resultsefficiently and effectively. Documentation costs money and takes time.

Other Requirements

14



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 ofa data dictionary.Vision

Summarizes the `vision` of the projectan executive summary.

Business Rules (or Domain Rules) Capture long-living and spanning rules or policies, such as

tax laws, that transcend one particular application.

Other Requirement Artifacts

15



Domain Model



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

Use Case Relationships

17

Domain Model

Use Case Model

Interaction DiagramsDesign

Requirements

Business Model

VISION

GLOSSARY

SUPPLEMENTARY

SPECIFICATION



What is domain model

UML notation of domain model

Identify Classes, attributes, associations

Objectives



Illustrate meaningful conceptual classes in a real-world 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

Domain Model



20

Identify concepts related to current development cyclerequirements

Create initial conceptual model

Identify the conceptual classes. Draw them as classes in a UML class

diagram.

Identify attributesAdd associations and attributes

Objectives Of A Domain Model



Conceptual Class:

A Domain Model Is Conceptual

Sale

amt

item

SalesDatabase

Sale

Double amt;Item item;

void print()

Software Artifacts:

vs.



Illustrated using a set of class diagrams for which nooperations are defined.

It may contain:

Domain Objects or Conceptual Classes

Associations between conceptual classes

Attributes of conceptual classes

Domain Model UML Notation



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

Identify Conceptual Classes By

Category List


23/82


Identify Nouns and Noun Phrases in textualdescriptions of the domain.

Fully dressed Use Cases are good for this typeof linguistic analysis.

Its not strictly a mechanical process

Words may be ambiguous

Different phrases may represent the sameconcepts.

Identify Conceptual Classes By

Noun Phrase


24/82


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

Steps To Create A Domain Model


25/82


Objective Identify associations within a conceptual model

distinguish between need-to-know associations fromcomprehension-only associations

Associations derived from the Common associationslist

Represented as a solid line between objects the association is inherently bi-directional may contain a cardinalityormultiplicityvalue

optionally contains an arrow for easy reading

Conceptual Models - Association


26/82


An association is a relationship between classesthat indicate some meaningful and interesting

relationship

All associations needs to preserve for some duration arediscovered and discard all other, theoretical associations inour domain model.

Associations

Customer

*A/c No.Name

AddressPhone No.Balance

Product

*Prod No.DescriptionUnit PriceQty in Stock

buys

* *


27/82


High priority associations

A is a physical or logical part ofB

A is physically or logically contained

in/on B

A is a member ofB

A is related to a transaction B

A owns B

Finding Associations


28/82


Focus on those associations for which knowledgeof the relationship needs to be preserved forsome duration (need-to-know associations)

More important to identify concepts thanassociations

Too many associations tend to confuse theconceptual model

Avoid showing redundant or derivable

associations

Association Guidelines


29/82


Association names should start with acapital letter (same as concepts, objects)

eg PaidBy, Paid-by

Noun phrases help identifyobjects/concepts

Verb phrases help identify associations

Use hyphens to separate words when aphrase is used to name something

Naming Associations


30/82


Each of the two ends of an association is called arole. Roles have

Roles in Associations

name

multiplicity expression

navigability


31/82


Multiplicitydefines how many instances of type Acan be associated with one instance of type B ata particular moment in time

Multiplicity indicates the number of objects of one

class that may be related to a single object of anassociated class

Can be one of the following types *, 1 to 1, 1 to 0..*, 1 to 1..*, 1 to n, 1 to 1..n

Multiplicity

Customer

*A/c No.Name

AddressPhone No.Balance

Product

*Prod No.DescriptionUnit PriceQty in Stock

buys

* *

Course

*Course No.*DateRoom No.Max Enrol

Teacher

*Employee No.Name

AgeSexSalary

teaches

*1


32/82


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

Association Role


33/82


Multiplicity Values


34/82


Two classes may have multiple associations between themin a UML class diagram; this is not uncommon:

Multiple associations between two types

Multiple Associations


35/82


what need to know associations are necessary givenour current list of candidate concepts?

Using a list of association categories.

How to Find Associations?

Association Category Examples

A is a transaction related to anothertransaction B

CashPayment-Sale

Cancellation-Reservation

A is a product or service for a transaction(or line item) B

Item-SalesLineItem

Flight-Reservation

A is a line item of a transaction B SalesLineItem-Sale


36/82


Attribute - is a logical data value of an object.

Attributes

Include the following attributes in a domain model

those for which the requirements suggest or implya need to remember information

For example, a sale receipt normally includes a dateand time attribute

It is a named property of a class describingvalues held by each object of the class

Attribute Type: A specification of the externalbehavior and/or the implementation of theattribute


37/82


Attributes reside in the second compartment ofa concept box

Format is name: type

Attributes should be pure data values

Attributes in a conceptual model should preferablybe simple attributes or pure data values

Common simple attribute types include boolean, date, number, string, time

UML Attribute Notation


38/82


Pure data values - expressed as attributes; they donot illustrate specific behaviors; Example - Phone number

A Person can have many Phone numbers

Types Of Attributes

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)


39/82


Design the software to support a computerised banking networkincluding both human cashiers and automated teller machines(ATMs) to be shared by a consortium of banks. Each bank providesits own computer to maintain its own accounts and processtransactions against them. Cashier stations are owned by individualbanks and communicate directly with their own bank computers.

Human cashiers enter account and transaction data. ATMscommunicate with a central computer which clears transactionswith the appropriate banks. an ATM accepts a cash card, interactswith the user, communicates with the central system to carry outthe transaction, dispenses cash and prints receipts. The system

requires appropriate record keeping and security provisions. Thesystem must handle concurrent accesses to the same accountcorrectly. The banks will provide their own software for their theirown computers; you are to design the software for the ATMs andthe network. The cost of the shared system will be apportioned tothe banks according to the number of customers with cash cards.

Problem Statement for ATM


40/82


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.

Noun Phrase Analysis


41/82


Identify Objects and Classes


42/82


Candidate classes for ATM Example

A l i


43/82


Analysis:


Analysis:


44/82


Analysis:



45/82


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

Domain Modeling - Identifying classes

Obj M d li


46/82


Object Modeling

Keeping the right classes

KEEP:Account,ATM,Bank,Bank Computer,

Cash Cards,Cashier,Cashier Station,Central Computer,Consortium, Customer,Transaction

Object Elimination ReasonAccess Implementation

Account *

Account data Attribute

ATM *

Bank Computer *

Banking Network Vague

Cash AttributeCash Card *

Cashier *

Cashier station *

Central Computer *

Consortium *

Cost Irrelevant

Customer *Receipt Attribute

Recordkeeping provision Vague

Security Provision Vague

Software Implementation

System Vague

Transaction *

Transaction Data VagueUser Redundant

KEEP:Account,ATM,

Bank,Bank Computer,Cash Cards,Cashier,Cashier Station,Central Computer,Consortium,Customer,Transaction


47/82


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 transactioninformation to the central computer for validation and

processing, and dispense cash to the user.

Bank - .

Object Modeling - Data Dictionary

Analysis:


48/82


Analysis:

Identify Associations


49/82


Analysis: Identify Associations


50/82


Analysis: Identify Associations


51/82


Initial Domain Model

Consortium Bank Account

Customer

Cash Card

Central Computer Bank Computer Cashier

Cashier StationCashier transaction

Remote transactionATM

Consists of Holds

Communicateswith

Has

Owns

Entered On

Concerns

Concerns

Authorised by

Has

Accesses

Entered On

Communicateswith

Owns

Communicateswith

OwnsEmploys

Entered

0..*

0..*

0..*

0..*

0..*

0..*

0..* 0..*

0..*

0..*

0..*

0..*0..*

0..*


52/82


It is desirable to show non-primitive attributes as conceptsin a conceptual model

Complex Attributes

Flight

Airport11Flies-to

Flight

destination

Destination a

Complex concept


53/82


Register

Item

Store

addressname

Sale

datetime

Payment

amount

SalesLineItem

quantity

Stocked-in

*

Houses

1..*

Contained-in

1..*

Records-sale-of

0..1

Paid-by

1

1

1

1

1

1

0..1

1

Captured-on

conceptor domainobject

association

attributes

Domain Model


54/82

BITS Pilani, Pilani Campus55

Dos and Donts in Conc. Model

Think of Conceptual Classes


55/82


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 purchasetransaction and has a date/time

Extension = all examples of sales or the set of all salesinstances

Think of Conceptual Classesin terms of


56/82


Domain Model Conceptual Class

Sale

datetime

concept's symbol

"A s ale represents the eventof a purchase transaction. Ithas a date and time."

concept's intension

sale-1

sale-3sale-2

sale-4

concept's extension

Domain models are a


57/82


Payment

amount

Sale

datetime

Pays-for

Payment

amount: Money

getBalance(): Money

Sale

date: DatestartTime: Time

getTotal(): Money. . .

Pays-for

UP Domain ModelStakeholder's view of the noteworthy concepts in the domain.

UP Design ModelThe object-oriented developer has taken inspiration from the real world domainin creating software classes.

Therefore, the representational gap between how stakeholders conceive thedomain, and its representation in software, has been lowered.

1 1

1 1

A Payment in the Domain Modelis a concept, but a Payment inthe Design Model is a softwareclass. They are not the samething, but the former inspiredthenaming and definition of thelatter.

This reduces the representationalgap.

This is one of the big ideas inobject technology.

inspiresobjects

andnames in

Domain models are astepping step to design


58/82


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;

Finding Conceptual Classes


59/82


Using a Category ListUse a list of categories and see if they apply within

the problem domain : this yields candidate conceptual classes.

Category List

Conceptual Class Category Examples

business transactions

Guideline: These are critical (they involve money), so start

with transactions.

Sale, Payment

transaction line items

Guideline: Transactions often come with related line items,

so consider these next.

SalesLineItem

where is the transaction recorded?

Guideline: Important.

Register, Ledger

product or service related to a transaction or

transaction line item

Guideline: Transactions are for something (a product or

service).

Item

Continued


60/82



roles of people or organizations related to the

transaction; actors in the use caseGuideline: We usually need to know about the parties

involved in a transaction.

Cashier, Customer, Store

MonopolyPlayerPassenger, Airline

place of transaction; place of service Store

Airport, Plane, Seat

noteworthy events, often with a time or place weneed to remember

Sale, PaymentMonopolyGame Flight

physical objects

Guideline: This is especially relevant when creating

device-control software, or simulations.

Item, Register Board,

Piece, Die Airplane

catalogs

Guideline: Descriptions are often in a catalog.

ProductCatalog

FlightCatalog

descriptions of things ProductDescription

FlightDescription

Continued


61/82



containers of things (physical or information) Store, Bin Board

Airplane

things in a container Item Square (in a Board)

Passenger

other collaborating systems CreditAuthorizationSyste

m

AirTrafficControl

records of finance, work, contracts, legal matters Receipt, Ledger

MaintenanceLog

financial instruments Cash, Check,

LineOfCreditTicketCredit

schedules, manuals, documents that are regularly

referred to in order to perform work

DailyPriceChangeList

RepairSchedule

A Common Mistake Classes As


62/82


Rule: If we do not think of a thing as a number ortext 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

A Common Mistake - Classes As

Attributes


63/82


Requirements must be read very closely (especially fully-dressed 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)

Using a Noun Phrases Identification

U i N Ph Id tifi ti


64/82


Main Success Scenario (or Basic Flow)

1. Customer arrives at POS checkout with goods and/or services topurchase.

2. Cashierstarts a new sale.

3. Cashier enters item identifier.

4. System records sale line item and presents item description, price, andrunning total. Price calculated from a set ofprice rules.

Cashier repeats steps 3-4 until indicates done.

5. System presents total with taxes calculated.

6. Cashier tells Customer the total, and asks forpayment.

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).


U i N Ph Id tifi ti


65/82


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 incash to Customer.

System records the cash payment

Using these approaches we end up with candidateconceptual classes:

Some will be outside the current requirements (e.g.price rules);

Some will be redundant (e.g. goods is better

described by item);



66/82

BITS Pilani, Pilani Campus67

POSTItem

Sale

Store

PaymentSalesLineItem

Product Specification

ProductCatalog

CustomerCashier

Manager

Concepts in POS domain

POS Conceptual Classes


67/82


There is no correctlist of conceptual classes!

POS Conceptual Classes

StoreRegister SaleItem

CashPayment

SalesLineItem

Cashier Customer

ProductCatalog

ProductDescription

Ledger

Initial POS Domain Model

D i i Cl


68/82


Think about description classes when creating an initial list ofconceptual classes (or during refactoring):

A description class contains information that describes

something else;

Item

description

price

serial number

itemID

ProductDescription

description

price

itemID

Item

serial number

Describes Better

Worse

1 *

Description Classes

D i ti Cl


69/82


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 ofany examples of those items or services.

Deleting instances of things they describe (forexample, Item) results in a loss of information

that needs to be maintained, but was incorrectlyassociated with the deleted thing.

It reduces redundant or duplicated information.

Description Class

A i ti


70/82


An association is a relationship between classes thatindicate some meaningful and interesting relationship

SaleRegisterRecords-current

1 1

association

there is a need to remember whatSalesLineItem

instancesare associated with a Sale.

Associations

Associations


71/82


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

Associations


72/82


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.

Fi di A i ti


73/82


By reading the current, relevant, requirements and askingourselves what information is needed to fulfil these

requirements: what need to know associations arenecessary given our current list of candidate concepts

Using a list of association categories.


A is a transaction related to another transaction B CashPayment-Sale

A is a product or service for a transaction (or line

item) B

Item-SalesLineItem

A is a line item of a transaction B SalesLineItem-Sale




74/82


Continued


A is a role related to a transaction B Customer-Payment

A is a physical or logical part of B Drawer-Register

Square-Board

A is physically or logically contained in/on B Register-Store

A is a description for B ProductDescription-Item

A is known/logged/recorded/reported/captured in B Sale-Register

Piece-Square




75/82


Continued


A is a member of B Customer-Payment

A is an organizational subunit of B Cashier-StorePlayer-MonopolyGame

A is an organizational subunit of B DepartmentStore

A uses or manages or owns B Cashier-Register

Player-Piece

A is next to B SalesLineItem-SalesLineItem

Square-Square


Records-sale-of


76/82


Register

ItemStore

Sale

CashPayment

SalesLineItem

CashierCustomer

ProductCatalog

Product

Description

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in1..*

0..1

Paid-by Is-for

Logs-completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-accounts-

for

1

1

Partial POS

Domain Model


77/82


Cashier

name

currentRegister

Cashier

name

Register

numberUses

Worse

Better

not a "data type" attribute

1 1

Relate with associations, not attributes

Ways To Indicate Data Type


78/82


OK

OK

Product

Description

Product

Description

itemId : ItemID

1Store

Store

address : Address

11 1

ItemID

idmanufacturerCode

countryCode

Address

street1street2

cityName

...

Ways To Indicate Data Type

Property

d l


79/82


Modeling Quantities

Payment

amount : Number

Payment Quantity

amount : Number

Unit

...

Payment

amount : Quantity

Has-amount1*

Is-in1*

not useful

quantities are pure data

values, so are suitable toshow in attribute section better

Payment

amount : Money

variation: Money is a

specialized Quantity whose

unit is a currency

NextGen POS Partial Domain


80/82


NextGen POS Partial Domain

Model

Register

id

ItemStore

name

address

Sale

dateTime

/ total

CashPayment

amountTendered

Sales

LineItem

quantity

Cashier

id

Customer

Product

Catalog

Product

Description

itemID

description

price

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-

completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-

accounts-for

1

1

l i l i d l


81/82


Monopoly Partial Domain Model

S


82/82

Summary

A domain model -its concepts , terminology, andthe relationships

Identifying classes, attributes, associations

UML Notation of domain model

A relatively useful model has been created for thedomain of the POS application, Monopoly.

ss zg514-l4.pptfdsf

Documents