lecture 9 enterprise systems development ( csc447 ) comsats islamabad muhammad usman, assistant...

51
Lecture 9 E nterprise S ystems D evelopment ( CSC447) COMSATS Islamabad n, Assistant Professor

Upload: moris-ferguson

Post on 02-Jan-2016

220 views

Category:

Documents


0 download

TRANSCRIPT

Lecture 9

Enterprise

Systems

Development( CSC447)

COMSATS Islamabad

Muhammad Usman, Assistant Professor

Domain Model

Domain Models

• Fundamental OO analysis model– Shows important concepts in the domain of

interest– Visual dictionary of concepts & their relationships– Inspiration for SW objects in class diagram– Depicts objects, their attributes, associations

between objects– Does NOT show object’s operations

Register

Item

Store

addressname

Sale

date time

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 domain object

association

attributes

Partial Domain Model – A Visual Dictionary

Domain Model

• It shows an abstraction of the conceptual classes, because there are many other things one could communicate about registers, sales, and so forth.

• Guideline:– Avoid a waterfall-mindset big-modeling effort to

make a thorough or "correct" domain model. it won't ever be either, and such over-modeling efforts lead to analysis paralysis, with little or no return on the investment.

Domain Objects

Sale

dateTime

visualization of a real-world concept in the domain of interest

it is a not a picture of a software class

Conceptual classes not Software Objects

SalesDatabase software artifact; not part of domain model

software class; not part of domain model

Sale

datetime

print()

Conceptual Classes

• The domain model illustrates conceptual classes or vocabulary in the domain.

• Informally, a conceptual class is an idea, thing, or object.• Conceptual class may be considered in terms of its

– Symbol – words or images representing a conceptual class– Intension – the definition of a conceptual class– Extension – the set of examples to which the conceptual class applies

• Example– Symbol – Sale– Intension – represents the event of a purchase transaction, and has a

date and time– Extension – all the examples/instances of sales

A Conceptual Class has a Symbol, Intension, and Extension

Sale

datetime

concept's symbol

"A sale represents the event of a purchase transaction. It has a date and time."

concept's intension

sale-1

sale-3sale-2

sale-4

concept's extension

Domain models

• Don’t confuse with data model– Object might have attributes that aren’t persisted– Object might have no attributes– Such objects wouldn’t be in a data model

Domain Models

• Domain model simpler than full-blown design class model

• Easier for users to understand• Use it to educate users about basic OO

modeling• Reduces tendency for modeler to drill too

deep too quickly

Motivation: Domain Models

• OO modeling lowers the representational gap between our mental and software models.

• Use software class names in the domain layer inspired from names in the domain model, with objects having domain-familiar information and responsibilities.

Lower Representational Gap with OO Modeling

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 domain in creating software classes.

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

1 1

1 1

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.

inspires objects

and names in

Domain Models

• How to create a domain model?– Bounded by the current iteration requirements

under design:• Find the conceptual classes • Draw them as classes in a UML class diagram.• Add associations and attributes

Guideline: How to Find Conceptual Classes?

1. Reuse or modify existing models 2. Use a category list3. Identify noun phrases

Conceptual Class Category Examples

business transactionsGuideline: These are critical (they involve money), so start with transactions.

Sale, PaymentReservation

transaction line itemsGuideline: Transactions often come with related line items, so consider these next.

SalesLineItem

product or service related to a transaction or transaction line itemGuideline: Transactions are for something (a product or service). Consider these next.

ItemFlight, Seat, Meal

where is the transaction recorded?Guideline: Important.

Register, LedgerFlightManifest

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 MonopolyPlayer Passenger, Airline

Conceptual Class Category Examples

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

Sale, Payment MonopolyGame Flight

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

Item, Register Board, Piece, Die Airplane

descriptions of thingsGuideline: See p. 147 for discussion.

ProductDescriptionFlightDescription

catalogsGuideline: Descriptions are often in a catalog.

ProductCatalogFlightCatalog

containers of things (physical or information)

Store, Bin Board Airplane

things in a container Item Square (in a Board) Passenger

other collaborating systems CreditAuthorizationSystemAirTrafficControl

records of finance, work, contracts, legal matters

Receipt, LedgerMaintenanceLog

financial instruments Cash, Check, LineOfCreditTicketCredit

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

DailyPriceChangeListRepairSchedule

Method 3: Finding Conceptual Classes with Noun Phrase Identification

• linguistic analysis:– Identify the nouns and noun phrases in textual

descriptions of a domain, and consider them as candidate conceptual classes or attributes

– Have to differentiate between attribute and class– A weakness of this approach is the imprecision of natural

language– It is recommended in combination with the Conceptual

Class Category List technique.

• The fully dressed use cases are an excellent description to draw from for

Example

• Main Success Scenario (or Basic Flow):1. Customer arrives at a 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.5. Cashier repeats steps 2-3 until indicates done.6. System presents total with taxes calculated.7. Cashier tells Customer the total, and asks for payment.8. Customer pays and System handles payment.9. System logs the completed sale and sends sale and payment

information to the external Accounting (for accounting and commissions) and Inventory systems (to update inventory).

10. System presents receipt.11. Customer leaves with receipt and goods (if any).

Initial POS Domain Model

StoreRegister SaleItem

CashPayment

SalesLineItem

Cashier Customer

ProductCatalog

ProductDescription

Ledger

Guidelines

• Agile Modeling and Maintain the Model in a Tool• Report Object in the domain

– include it in domain model or not?– e.g., Receipt is only a report of Sale and Payment

• Think like a Mapmaker– Use the existing names in the territory. For example, if

developing a model for a library, name the customer a "Borrower" or "Patron" the terms used by the library staff.

– Exclude irrelevant or out-of-scope features.

Guidelines

• How to Model the Unreal World?– e.g., Software for Telecommunication – It requires a high degree of abstraction

• listening carefully to the core vocabulary and concepts that domain experts use.

• A Common Mistake with Attributes vs. Classes– If we do not think of some conceptual class X as a

number or text in the real world, X is probably a conceptual class, not an attribute.

Guidelines

• Objects vs. attributes – Attributes are ‘simple’ data types

• e.g., number, text

– Concepts that are described by simple attributes are objects

• A Store has an address, phone number, etc.

– As another example, consider the domain of airline reservations. Should destination be an attribute of Flight, or a separate conceptual class Airport?

Guidelines: Description classes

• When to model with Description classes– A description class Contain info that describes

something else, very common in OO models• A ProductDescription that records the price, picture,

and text description of an Item.

– If description is not separate from the underlying object, then deletion of the object results in loss of all info about that object

– Also error prone due to data duplication

Guidelines: Description classes

Item

descriptionpriceserial numberitemID

ProductDescription

descriptionpriceitemID

Item

serial number

Describes Better

Worse

1 *

Guidelines : Description classes

• When Are Description Classes Useful? – Add a description class (for example,

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

Guidelines: Associations

• Associations– A meaningful relationship between objects– When knowledge of relationship needs to be preserved.

• For example, do we need to remember what SalesLineItem instances are associated with a Sale instance? Definitely, otherwise it would not be possible to reconstruct a sale, print a receipt, or calculate a sale total.

• A Cashier may look up ProductDescriptions, but there is no need to remember the fact of a particular Cashier looking up particular ProductDescriptions.

– Consider including the following associations in a domain model:• Associations for which knowledge of the relationship needs to be

preserved for some duration ("need-to-remember" associations).• Associations derived from the Common Associations List.

Guidelines: Associations

• Why Should We Avoid Adding Many Associations? – Many lines on the diagram will obscure it with "visual noise.“– focus on "need-to-remember" associations.

• Associations are NOT– A model of data flows– DB foreign keys– Instance variables– SW object connections

• it is a statement that a relationship is meaningful in a purely conceptual perspective in the real domain.– Many, but not all, associations will be implemented eventually

Applying UML: Association Notation

SaleRegisterRecords-current

1 1

association

Applying UML: Association Notation

• An optional "reading direction arrow" indicates the direction to read the association name; it does not indicate direction of visibility or navigation.

SaleRegister Records-current 0..11

association name multiplicity

-"reading direction arrow"-it has no meaning except to indicate direction of reading the association label-often excluded

Applying UML: Association Notation

• Name an association based on a ClassName-VerbPhrase-ClassName format.– Simple association names such as "Has" or "Uses"

are usually poor, as they seldom enhance our understanding of the domain.

– Sale Paid-by CashPayment• bad example (doesn't enhance meaning): Sale Uses

CashPayment

Applying UML: Association Notation

• Applying UML: Roles– Each end of an association is called a role. Roles may optionally have:

• multiplicity expression• name• navigability

• Applying UML: Multiplicity

ItemStore Stocks

*

multiplicity of the role

1

Normally, the multiplicity at a particular moment in time

Applying UML: Association Notation

zero or more; "many"

one or more

one to 40

exactly 5

T

T

T

T

*

1..*

1..40

5

T3, 5, 8

exactly 3, 5, or 8

Applying UML: Association Notation

• Multiple Associations Between Two Classes

Flight Airport

Flies-to

Flies-from

*

* 1

1

Can have more than 1 association between classes.A class can also have an association with itself! Can you think of an example?

Applying UML: Association Notation

• How to Find Associations with a Common Associations List?

Common Associations List.

Category Examples

A is a transaction related to another transaction B CashPaymentSaleCancellationReservation

A is a line item of a transaction B SalesLineItemSale

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

A is a role related to a transaction B CustomerPaymentPassengerTicket

A is a physical or logical part of B DrawerRegisterSquareBoardSeatAirplane

A is physically or logically contained in/on B RegisterStore, ItemShelfSquareBoardPassengerAirplane

A is a description for B ProductDescriptionItemFlightDescriptionFlight

A is known/logged/recorded/reported/captured in B SaleRegisterPieceSquareReservationFlightManifest

Common Associations List.

Category Examples

A is a member of B CashierStorePlayerMonopolyGamePilotAirline

A is an organizational subunit of B DepartmentStoreMaintenanceAirline

A uses or manages or owns B CashierRegisterPlayerPiecePilotAirplane

A is next to B SalesLineItemSalesLineItemSquareSquareCityCity

Example: Associations in the Domain Models

• Transactions related to another transaction Sale Paid-by CashPayment.

• Line items of a transaction Sale Contains SalesLineItem.

• Product for a transaction (or line item) SalesLineItem Records-sale-of Item.

NextGen POS partial domain model.

Register

ItemStore

Sale

CashPayment

SalesLineItem

CashierCustomer

ProductCatalog

ProductDescription

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

Attributes

• Attributes– A logical data value of an object that needs to be

remembered• Some attributes are derived from other attributes

– The usual ‘primitive’ data types• Numbers, characters, Booleans

– Common compound data types• Date, time (or dateTime), address, SSN, phoneNumber,

bar codes, etc.• May become full class objects in design

Attributes

• Include attributes that the requirements (for example, use cases) suggest or imply a need to remember information.– Sale needs a dateTime attribute.– Store needs a name and address.– Cashier needs an ID.

Applying UML: Attribute Notation

Sale

dateTime/ total : Money

attributes

derived attribute

Applying UML: Attribute Notation

Sale

- dateTime : Date- / total : Money

Private visibility attributes

Math

+ pi : Real = 3.14 {readOnly}

Public visibility readonly attribute with initialization

Person

firstNamemiddleName : [0..1]lastName

Optional value

Showing visibility on domain model is probably overkill. We’ll talk about visibility later in the course.

Applying UML: Derived Attribute• The total attribute in the Sale can be calculated or derived

from the information in the SalesLineItems.

SalesLineItem ItemRecords-sale-of 10..1

SalesLineItem ItemRecords-sale-of 0..1 1..*

Each line item records a separate item sale.For example, 1 tofu package.

Each line item can record a group of the same kind of items.For example, 6 tofu packages.

SalesLineItem

/quantity

ItemRecords-sale-of 0..1 1..*

derived attribute from the multiplicity value

Data Types

• Relate with associations, not attributes.

Cashier

namecurrentRegister

Cashier

name

Register

number

Uses

Worse

Better

not a "data type" attribute

1 1

Don’t use an attribute in lieu of an association

Attributes

Flight

Flight

destinationWorse

BetterFlies-to Airport1 1

destination is a complex concept

Two Ways to Indicate a Data Type Property of an Object

OK

OK

ProductDescription

ProductDescription

itemId : ItemID

1Store

Store

address : Address

11 1

ItemID

idmanufacturerCodecountryCode

Address

street1street2cityName...

Do Not Use Attributes as Foreign Keys

Cashier

namecurrentRegisterNumber

Cashier

name

Register

number

Works-on

Worse

Better

a "simple" attribute, but being used as a foreign key to relate to another object

1 1

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 to show in attribute section better

Payment

amount : Money

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

NextGen POS Partial Domain Model

Register

id

ItemStore

nameaddress

Sale

dateTime/ total

CashPayment

amountTendered

SalesLineItem

quantity

Cashier

id

Customer

ProductCatalog

ProductDescription

itemIDdescriptionprice

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

References

• Craig Larman, Applying UML and Patterns, 3rd Edition