Objetc Oriented Analytsis-Atm DFD

CIS490 Software Engineering

Object Oriented Analysis

Object oriented analysis

The world is made of objects. Just open your eyes and ears. They are out there. Bank customers, students, cats, elephants, cars, balls of string, atoms, molecules, tubs of ice cream, Madonna, stars, bureaucrats, Robin Hood. The world is built of objects. Objects are built of smaller objects, and so ad infinitum. Objects combine to make bigger objects. We already live in an object-oriented world.

The first thing an object analyst must do is to remove the scales from his or her eyes. Object modeling consists of looking for objects. Of course, there has to be some boundary. Even sitting at my desk I can see more objects than I could reasonably list. But that is where the beauty of object modeling comes in. It uses observation.

Objects can be described by their attributes and operations. Attributes are the changeable characteristics of an object. Cats have color, size, weight and a preference for either Kit-E-Kat or Whiskers. Operations are the things an object does or can have done to it. Cats can catch mice, eat, miaow, worm up to owners, and be stroked. In our notation we draw an object such as a cat like this.

The name is shown at the top. The attributes are listed underneath. The operations are listed below that. Actually, strictly speaking, this is the most very simple class diagram.

In an object model, all data is stored as attributes of some object. The attributes of an object are manipulated by the operations. The only way of getting at the attributes is through an operation.

In an object model, all functionality is defined by operations. Objects may use each others operations, but the only legal way one object can manipulate another object is through an operation. An operation may inform, say "mass of ball", or change the state of an object, say "throw ball".

Object modeling is about finding objects, their attributes and their operations, and tying them together in an object model. Nothing more. Here are some more objects:

Some of these objects may seem jockey, but they could reasonably be part of a system, be it a computer game or a multimedia story. Do not be constrained to be those dull systems that most software engineers drag out. Object modeling can be used to design lots of things.

By now you should be getting the idea that object modeling is, at its simplest level, very straightforward. The trick comes in knowing what objects are appropriate, and what their appropriate attributes and operations are. It is a question of focus. We will consider some ways of controlling focus later in the course.

How do objects relate to other concepts in design methods? Remember entity-relationship models? SSADM, JSD and so on have a notion of entity. These are really objects. All we are doing in object modeling is relabelling entity modeling. However, we put the emphasis on capturing and grouping together both functions and data (operations and attributes in our terminology). That is the elegant simplicity of object modeling. We will look at object models later which look remarkably like entity-relationship models (because they are). We will now look one powerful way of arranging objects - inheritance hierarchies.

InheritanceOften we will find that there are objects which have something in common. It is then useful to create an abstract object which groups together the common features, and to use inheritance to define the original objects.

For example, consider our two fairy story creatures:

Now we can see that they both have the same operations "arrive" and "meet". We can therefore create an abstract creature

which has the common operations. We can then draw the original objects grouped under the abstract object as follows

Inheritance means that all the attributes and operations of an abstract object are available in the specialized object below. The triangle in the diagram indicates inheritance. The point of the triangle indicates where operations and attributes are inherited from.

Now we can enter a debate about whether nose, teeth and appetite are characteristics of all creatures or not. It they are, we can revise the diagram above as:

By this device Red Riding Hood has also appetite, nose and teeth as operations. The latter two may be of relevance when she goes to charm the woodcutter, provided they are petite and pearly bright respectively. Okay, so let's have some more practical examples for those of you who have to do real work. Firstly, the frighteningly dull student-lecturer example. You can do the same with the equally dull employee-customer example.

The big deal about inheritanceInheritance is considered good for the software re-use and for clarity of description.

Re-useWhen new objects are created which are similar to other objects, they can have many of their attributes and operations ready defined. Let us suppose we now introduce Grandma into our fairy story hierarchy.

Here we get a Grandma who already had an appetite, nose and teeth and who can arrive and meet. Actually these are not in the normal scope of the fairy story, but the principle should be clear.

We might be writing a simple geometry program

Now to add circles we simply put in another object under 2D shape

So the circle object need not define the area and position attributes or the get area operation

It is now possible to buy or obtain ready-built class hierarchies written in object-oriented languages which can be extended in this way to produce a new application. Designing complex class hierarchies takes time and good design requires experience. But the basic principles outlined above, with some intuitive guidelines, are the basis for the design of good, re-usable designs. Re-use can be viewed from two directions. Components can be re-used, which is a sort of bottom-up approach to re-use. Or designs can be re-used. Both elements are important in the production of re-usable software.

RelationshipsObjects can be related in other ways than by inheritance and aggregation. Any relationship between real world objects can be modeled: cats eat canaries, dogs bite postmen, the woodcutter murders the wolf, cars run over little old ladies, employees work for organizations, patients visit hospitals, patients stay in hospitals.

One to one relationshipsIn a one-to-one relationship, one object is associated with exactly one of its related objects. This is modelled by a straight line drawn between the objects. If the relationship is one-way, then an arrow is used to indicate the direction. The line can be labelled.

Thus a man marries one woman (at a time) and a woman marries one man (at a time). A cat eats one canary (before being battered to death by the little old lady who owned the canary). Canaries do not (in general) eat cats, so the eats relationship is one way.

One to many relationshipsSometimes one object can be related to many objects. This is indicated by different marks at the end of the line.

A player plays for one football team. There are at least 11 players for a given football team. Football teams do not play for players.

Many to many relationships

Sometimes objects at either end of a relationship may be related to many objects at the other end

A dog may bite zero or more postmen. A postman may be bitten by zero or more dogs.

A lubricant is recommended for at least one engine. An engine has at least one lubricant recommended for it.

The OOA Process - I

Steps and RulesObjects and Structures

The Steps of OOA - Part 1• identify objects (classes)• identify structures

– generalization - specialization (“ISA”)– whole - parts (“PART-OF”)– association (relationship)

• define attributes

===> Static Objectdiagram===> incomplete Object Dictionary

The Steps of OOA - Part 2

• define services via scenarios– services per object– message passing between objects– coordination of message passing– states and transitions

===> Scenarios===> complete Object Dictionary

OOA - Object

• generalization of a set of real-life entities/objects

• groups a set of attributes (schema)• can be active (services)• has memory (states)• participates in structures• label: typically a noun• specified in the object dictionary

label

label

OOA - Object Class & Instance• A symbol for

an object class and its object instances.

• a description of one or more objects with a uniform set of attributes and services, and the actual object instances belonging to the given class

• “usual way” to model an object

label

OOA - Whole-Part

• groups objects by combining smaller parts into larger units

• forms a hierarchy by– aggregation– decomposition

• cardinalities must be specified(min , max)

• no inheritance

whole

part1 part2

(min,max) (min,max)

(min,max)

(min,max)

OOA - Generalization-Specialization

• groups objects based on similarity of attributes and services

• forms a class hierarchy by– generalization – specialization

• attributes, services, etc. are inherited by the more specialized from the more general objects

gen

spec1 spec2

Employee

Manager Programmer

Inheritancenameaddress

experiencecourses

list of prg-lang.

OOA - Object Class • Object Class only• NO instantiations possible• a generalization of one or more

objects with a uniform set of attributes and services

• can have attributes, services, states

• used in classification structures to organize object hierarchies

label

Employee StudentMultipleInheritance==>InheritanceLattices

nameaddress

MajorGPA

Teaching Assistant

OOA - Association

• provides free mapping between objects

• complements the two predefined structural types

• forms a network of objects by using binary relationship types

• cannot carry attributes• supports access to partner-object

(via “foreign key”)

obj1

obj2

label

(min,max)

(min,max)

Manager Department

manages(1,N) (1,1)

Manages which department? Follow association.Since when? Attribute of ...?

access

OOA

An Example

ATM

atm #

req_withdrwreq_depreq_balancereq_int_rate

ACCOUNT

acct #balancesec-codestate

withdrwdepprov_balance

STD_ACCT SAVINGS_ACCT

add_on_interestprov_int_rate

int_rate

TRANS_REC

trans_typedate_timeamountteller_ID

has

(0,N) (1,1)

Static OOAD Diagram

ATM

atm #

req_withdrwreq_dep

ACCOUNT

acct #balancesec-codestate

withdrwdep

TRANS_REC

trans_typedate-timeamountteller_ID

Scenario 1

withdrw / deposit create

ATM

req_balance

ACCOUNT

acct #balancesec-codestate

prov_balance

Scenario 2

prov_balance

ATM

req_int_rate

ACCOUNT

acct #sec-codestate

SAVINGS_ACCT

prov_int_rate

int_rate

Scenario 3

prov_int_rate

HOW TO ? HOW TO ?

Building an Object Model starts with identifying Objects and Classes. Candidate Objects and Classes can usually be found by

looking at the nouns in the problem statement; they can be physical entities as

well as concepts.

Rules for Identifying ObjectsRules for Identifying Objects

Objects ...• Are actors.Are actors. Objects can be viewed as actors that play a role in the system to be built. For example some of the actors on the stage of the purchasing system are the vendor, the purchaser, the purchase order and the purchase requisition.

• Are nounsAre nouns. Objects often appear as nouns in problem descriptions.Example: "A purchase order cannot be created until a purchase requisition is received."

• Have UniquenessHave Uniqueness. Objects can be uniquely defined. That is instances of one object can be differentiated from another. For example, a person can be male or female. By contrast money has no distinguishing attributes. It only takes on importance as an attribute of some object; for example a bank account.

• Have attributesHave attributes. Objects can be described by one or more attributes. To be distinguishable from one another, objects must have attributes. For example, one automobile is distinguished from another by model, make, colour etc.

• Are data storesAre data stores. Objects are the data stores in a data flow diagram.

ID E N TIF Y IN G O B JE C TS

E V E N T A N D S TA TEO B JE C TS

C O N C E P TU A LO B JE C TS

C O N C R E TEO B JE C TS

E N TITY O B J E C TS U S E R IN TE R F A C E O B J E C TS C O N TR O L O B JE C TS

JA C O B S O N TH R E E TY P E S O F O B J E C TS

An object can beAn object can be::• A tangible thingA tangible thingsomething you can touchExample: plane, car, truck, purchase order, person, book, invoice, target

• A roleA rolethe purpose or assignment of a person, item of equipment or organisationExample: operator, customer, pilot, vendor, purchaser, scheduler

• An incidentAn incidentsomething that happensExample: delivery, attack, landing, telephone call, accident

• An interactionAn interactionobjects that result from associations between other objectsExample: A purchase results from the association of a vendor and a customer.

• A specificationA specificationa representation of rules, standards or criteriaExample: recipe, articles of association, quality criteria

ATM Problem Statement Design the software to support a computerized banking network including

both human cashiers and automatic teller machine (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's

computers. Human cashiers enter account and transaction data. Automatic

teller machines communicate with a central computer which clears

transactions with the appropriate banks.

An automatic teller machine 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

recordkeeping and security provisions. The system must handle concurrent

accesses to the same account correctly. The banks will provide their

network. The cost of the shared system will be apportioned to the banks

according to the number of customers with cash cards.

ATM Problem Statement(SOLUTION)

Design the software to support a computerized banking network including

both human cashiers and automatic teller machine (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's

computers. Human cashiers enter account and transaction data. Automatic

teller machines communicate with a central computer which clears

transactions with the appropriate banks.

An automatic teller machine 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

network. The cost of the shared system will be apportioned to the banks

according to the number of customers with cash cards.

ATM Classes Extraxted From Problem Statement Nouns

Cost

BANK

Customer

Cash

TransactionData

Cashier CONSORTIUMSoftware

System

ATM

Transaction

BankingNetwork

User Receipt

AccountData

Access

BANKCOMPUTER

Cash Card

CashierStationAccount

CentralComputer

SecurityProvision

ExternalInteractor

RecordKeeping

CommunicationLine

Transaction Log

The correct Classes can be The correct Classes can be detected by following the next detected by following the next guidelines: guidelines:

1. Discard redundant Classes

customer and user are redundant , customer and user are redundant , customer is retained because it is customer is retained because it is

more descriptivemore descriptive

2. Discard irrelevant Classes

apportioning cost is outside the apportioning cost is outside the scope of the ATM transaction scope of the ATM transaction

softwaresoftware

3. Discard vague Classes

record keeping is vague in ATM record keeping is vague in ATM problem , this is part of transactionproblem , this is part of transaction

4. Do not model Attributes as Classes

account data is under specified but in account data is under specified but in any case probably describes an any case probably describes an

accountaccount

5. Do not model Operations as Classes

if we are simply building telephones , if we are simply building telephones , then then Call Call is part of the dynamic is part of the dynamic

model not an object classmodel not an object class

6. Do not model implementation constructs

communications links can communications links can be shown as associationsbe shown as associations

communication line is communication line is simply the physical simply the physical

implementation of such a implementation of such a linklink

7. Do not model roles that objects play

the proper class is person(or the proper class is person(or

possibly customer , which possibly customer , which assumes various different roles assumes various different roles

such as owner and driver.such as owner and driver.

VAGUE

cost

BANK

customer

cash

transactiondata

cashier CONSORTIUM

software

system

ATM

transaction

bankingnetworkuser

receipt

accountdata

access

BANKCOMPUTER cash card

cashierstation

account centralcomputer

securityprovision

Externalinteractor

recordkeeping

communicationline

transaction log

Eliminating Necessary Classes From ATM Problem

GOODCLASSES IMPLEMENTATION REDUNDUNT IRRELEVANT ATTRIBUTE

Initial Object Diagram for ATM

Consortium Bank Account

Customer

After identifying Objects and Classes the necessary Associations Associations

between Classes can be identified between Classes can be identified .. Associations can often be found by

looking at the verbs or verb verbs or verb phrasesphrases in the problem statement.

1. Physical location next tonext topart ofpart of

contained incontained in

2. Directed action drivesdrives

3. Communicationtalks totalks to

4. Ownership hashas

part ofpart of

5. Satisfaction of some condition works for works for married tomarried tomanagesmanages

1 Review the concept of associations.

2 Identify verb phrases in problem statements, requirement statements, business rules and concepts of operation. For example:

a customer purchases a book (class=customer, book; association=purchases) a customer complains about a product(class=customer, product ; association=complains about)

3 Eliminate irrelevant associations that are:a) Outside the problem domainb) Specify implementation approaches (e.g. the transaction takes a record lock)

Associations guide-linesAssociations guide-lines

4 Discard actions. Associations describe class structure not transient events. For example "accountant creates a credit note"For example "accountant creates a credit note" describes an action on a credit note it does not imply an association between accountant and credit note that needs to be recorded.

5 Omit derived associations. Omit associations that can be defined in terms of other associations. For example, given the business rule, "a credit note is issued on an invoice for validated customer complaints", an association need not be defined between complaint and invoice. It is redundant as it can be derived by identifying the credit note the complaint was associated with and accessing the related invoice from the is issued on association.

6 Identify associative classes. 7 Define the cardinality of the association

From David Brown BookFrom David Brown Book

Establishing the cardinality:Establishing the cardinality:

sentence = subject + verb + number + objectsentence = subject + verb + number + object

“ customer buys many products”

ATM example :Verb phrases

Banking network includes cashiers and ATMs Banking network includes cashiers and ATMs Consortium shares ATMsConsortium shares ATMsBank provides bank computerBank provides bank computerBank computer maintains accounts Bank computer maintains accounts Bank computer processes transaction against Bank computer processes transaction against account account Bank owns cashier station Bank owns cashier station Cashier enters transaction for accountCashier enters transaction for accountCashier station communication with bank computer Cashier station communication with bank computer ATM accepts cash cardATM accepts cash cardATM interacts with user ATM interacts with user ATM dispenses cashATM dispenses cashATM prints receipts ATM prints receipts System handles concurrent accessSystem handles concurrent accessBanks provide software Banks provide software Cost apportioned to banks Cost apportioned to banks

Implicit verb phrases Implicit verb phrases

Consortium consists of bank Bank holds account Consortium owns central computer System provides record keeping System provides security Customers have cash cards

Knowledge of problem domainKnowledge of problem domain

Cash card accesses accounts Bank employs cashiers

For keeping the correct associations the next

guidelines have to be applied:

1.1. Discard associations Discard associations between Classes that are between Classes that are eliminated .eliminated .ATM case we can eliminate:ATM case we can eliminate:Banking network includes cashiers and Banking network includes cashiers and ATM’sATM’sCost apportioned to banksCost apportioned to banksATM prints receipts ATM prints receipts ATM dispenses cashATM dispenses cashSystem provides record keeping System provides record keeping System provides security System provides security Banks provide software Banks provide software

2.2. Discard implementation Discard implementation associations associations

System handles concurrent System handles concurrent accessaccess is an implementation is an implementation

conceptconcept

3.3. Don't model actionsDon't model actionswe can eliminate:we can eliminate:

ATM accepts cash cardATM accepts cash carddescribes part of the describes part of the

interaction cycle betweeninteraction cycle between an ATM and a customeran ATM and a customerATM interacts with userATM interacts with user

4.4. Decompose ternary Decompose ternary associations if possible into associations if possible into binary associationsbinary associations

Cashier enters transaction for Cashier enters transaction for accountaccount can be broken into: can be broken into:* * Cashier enters transaction Cashier enters transaction andand*transaction concerns account*transaction concerns account

5.5. Don't model associations that Don't model associations that can be derived can be derived

Consortium shares ATMsConsortium shares ATMs is a is a composition of the associations:composition of the associations:

consortium owns central computerconsortium owns central computerandand

central computer communicates with central computer communicates with ATM’sATM’s

Notes

• Be careful not all associations from multiple paths between classes indicate redundancy.

• Although derived associations do not add information , they are useful in the real world and in design, they should be drawn they should be drawn using dotted lines.using dotted lines.

Next the identified associations have to be refined applying the next

guidelines:

1. Find a good name for every association

bank computer maintains bank computer maintains accountsaccounts

is a statement of action ; rephrase is a statement of action ; rephrase asas

bank holds accountbank holds account

2. Add role names to associations if this is

necessary

in the in the works-forworks-for association association

companycompany has the role has the role employeremployer and and

person person has the role has the role employeeemployee

3. Use qualified associations whenever possible

The context combines with the name to uniquely identify the

object

The qualifier The qualifier bank codebank code distinguishes the different distinguishes the different

banks in a consortiumbanks in a consortium

4. Specify multiplicity (cardinality) of associations

5. Find missing associations

cashier authorized on cashier cashier authorized on cashier station is needed if cashiers are station is needed if cashiers are

restricted to specific stationsrestricted to specific stations

Identify AssociationsConsortium Bank Account Customer

Holds

The next step is identifying Attributes .identifying Attributes .Attributes can usually be found in Attributes can usually be found in

nouns with possessive phrases and nouns with possessive phrases and adjectivesadjectives. For derived Attributes it's

important to either label them as derived, or discard them. Link Attributes also have

to be identified. Guidelines for identifying Attributes:

Identifying attributesIdentify the characteristics that are common to all possible instances of objects in the class.

Types of Attribute

Candidate keyCandidate key A set of one or more attributes that uniquely distinguishes one instance of an object from another. For example, an invoice number.

Descriptive attributesDescriptive attributes Facts intrinsic to each instance of the object. For example, invoice date and invoice total.

Referential attributesReferential attributes An attribute that ties an instance of one object to an instance of another. For example, customer code.

Rules for Identifying Attributes Single valued. One instance of an object has exactly one value of each attribute at any given instant in time Atomic. An attribute is atomic - cannot be described by other attributeslegal attribute : phone-numberillegal attribute : shipping address => street-address, city, postcode Uniquely identify the object. A set of attributes (the candidate key) must uniquely identify all instances of the objectlegal candidate key : customer-codeillegal candidate key : last-name A property of the object. Each non-candidate key attribute is a characteristic of the instance named by the candidate key and not of some other non-candidate key attributelegal attributes : invoice = invoice-number + invoice-date + customer-code illegal attribute (street-address): invoice = invoice-number + invoice-date + customer-code + street-address Note that street-address is an attribute of customer not invoice.

1. Don't model Objects as Attributes

boss is an object and salary is an boss is an object and salary is an attributeattribute

2. Use qualifiers wherever possible (names can often be

modeled as qualifier)

employee number is not a unique employee number is not a unique property of person with two jobsproperty of person with two jobs

; it qualifies the association:; it qualifies the association:company employs personcompany employs person

Names Are Often Better Names Are Often Better Modeled As Qualifiers Rather Modeled As Qualifiers Rather

Than Object AttributesThan Object Attributes

3. Don't model identifier attributes that are made to

identify (For example 'Person ID')

4. Model link Attributes

5. Don't model internal values (states) of an Object

6. Don't model fine details

7. Discordant attributesDiscordant attributesAttributes that are very

different from other Attributes of an Object often indicate the need for adding a new Class

Identify AttributesConsortium

BankAccount Customer

bank codebank name

account-codebalancecredit limitaccount type

Holds

Using Inheritance to organize the Class Hierarchy can refine Object Classes. Common aspects of Classes

like Attributes, Operations or Associations can be generalized into Super classesgeneralized into Super classes

and existing Classes can be existing Classes can be specialized into Subclassesspecialized into Subclasses.

Specialization can be found in noun noun phrases with adjectivesphrases with adjectives. Multiple

Inheritance is also possible but should only be used if it is really necessary.

Generalization : Generalization : bottom - upbottom - up

specialization : specialization : top - downtop - down

Top down specialization are often Top down specialization are often apparent from the application apparent from the application

domain like:domain like:

fixed-menufixed-menu

pop-menupop-menu

sliding-menusliding-menu

remember brown notations:remember brown notations:

canbeacanbea and and isakindaisakinda

Remote transactionRemote transaction and and cashier transactioncashier transaction are are

similar and can be similar and can be generalized by generalized by

transactiontransaction

To control the adequateness of the Object Model it is recommended to test several access paths through the Object model

to find missing and unnecessary Classes, missing and unnecessary Associations and incorrect placement of Associations

and Attributes.

The last step for building the Object model is the grouping of sets of Classes that capture a

logical subset of the model into Modules For grouping Classes the analyst should look at

cut points between Classes. The number of bridges between Classes in different Modules

should be minimized.For grouping Classes into Modules it is possible

to look at earlier made Modules, it may be possible to reuse previous made Modules.

ATM modules examples are :ATM modules examples are :

tellers :tellers :

cashier , entry station , cashier , cashier , entry station , cashier , ATMATM

banks:banks:

consortium , bankconsortium , bank

Determine Generalization and Aggregation

Consortium Bank Account Customer

bank-codebank-name

account-codebalancecredit-limitaccount-type

Holds