1

START AT 31 MARCH END 8 APRIL

PHASE5(CONCEPTUAL AND SEQUENCE MODEL)

2

What is a conceptual model or domain model?

• A domain model is a representation of real-world conceptual classes, not of software components.

• It is not a set of diagrams describing software classes, or software objects with responsibilities.

3

Conceptual (Domain) Model

A domain model illustrates meaningful concepts in a problem domain.

It’s a representation of real-world things, not software components.

It’s a set of static structure diagrams; no operations are defined.

It may show:

Concepts: is an idea, thing, or object.

Attributes of concepts.

Associations between concepts.

4

Example: Library System

University library system requirements Books and journals – the library contains books and journals. It

may have several copies of a given book. Some of the books are for short term loans only. All other books may be borrowed by any library member for three weeks. Only members of staff may borrow journals. Members of the library can normally borrow up to six items at a time, but members of staff can borrow up to 12 items at a time. New books and journals arrive regularly, and old ones are sometimes disposed of. The current year’s journals are sent away to be bound into volumes at the end of each year.

Borrowing – it is essential that the system keeps track of when books and journals are borrowed and returned. The new system should also produce reminders when a book is overdue. There may in future be a requirement for uses to be able to extend the loan of a book if it is not reserved.

Browsing – this system should allow users to search for a book on a particular topic, by a particular author, etc., to check whether a copy of the book is available for loan and, if not ,to reserve the book. Anybody can browse in the library.

P. Stevens, R. Pooley. Using UML: Software Engineering with Objects and Components. Addison-Wesley, 2000

5

6

Patron

Loan

Librarian

Book

Library

7

Strategies to Identify Conceptual Classes

A central distinction between object-oriented and structured analysis: division by concepts (objects) rather than division by functions.Two techniques are presented in the following sections:Identify noun (and noun phrases) in textual descriptions of the problem domain, and consider them as concepts or attributes.

Use cases are excellent description to draw for this analysis.

8

System Response Actor Action1. This use case begin

when Borrower arrives at the checkpoint after browsing a list of resources to borrow.

3. The system will check member ship and calculate the number of resources, check resources overdue then issues loans card for it.

2. The Library Clerk records the resources for registered borrowers.

5. Logs the completed borrowing.

4. The clerk will give borrower resources with loan card.

5.The Borrower will leave with resources and load card.

Expanded Use Case Format : Borrow Resources

9

Alternatives: Line 2. Borrower are not register cancel borrowing operation.Line 3. Borrower exceed the number of allowed resources clerk not record extra resources

Expanded Use Case Format Example: Borrow Resources(cont.)

10

Disadvantages of Noun Phrase Identification The imprecision of natural language.

Different noun phrases may represent the same conceptual class or attribute, among other ambiguities.

Nouns do not always result in classes, or objects in the problem domain.

In many cases, the nouns, especially subjects to sentences, refer to:

1) An entire assembly or a computer software configuration,

2) A sub assembly or a software component,

3) An attribute,

4) Service.

11

Use a Conceptual Class Category List

Example Concept Category

Resources Physical or tangible objects.

Resource Specification Specifications, designs, or descriptions of things.

Library Places.

Borrowing , Payment Transactions.

Check Point Transaction line items.

Clerk ,Borrower Roles of people.

Library Containers of other things.

* See complete list in Larman 2nd edition, P.G. 134 - 135.

12

Identify noun (and noun phrases) in use case description

Borrower

Membership

Payment Resource

Specification

Loan

Check Point

Borrowing Library

Resources Library Clerk

THE NEED FOR SPECIFICATION OR DESCRIPTION CONCEPTUAL CLASSES

• Add a specification or description conceptual class (for example, Product-Specification)

• when:• There needs to be a descriptionabout 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, due to the incorrect association of information with the deleted thing.• It reduces redundant or duplicated information.

Book_Description

Title, Author,

Resources

ISBN

14

Adding Associations

•An Association is relationship between concepts between concepts that indicate some meaningful an interesting connection

15

Valid Attributes Types

Keep attributes simple.

The type of an attribute should NOT normally be a complex domain concept, such as Sale or Airport.

Attributes in a Domain Model should preferably be:

Pure data values: Boolean, Date, Number, String,...

Simple attributes: color, phone number, zip code, universal product code (UPC),...

16

A COMMON MISTAKE WITH ATTRIBUTES VS. CLASSES CONT.

WITH EXAMPLE

In the real world, a store is not considered a number or text the term suggests a legal entity, an organization, and something that occupies space. Therefore, Store should be a conceptual class.As another example, consider the domain of airline reservations. Should destination be an attribute of Flight, or a separate conceptual class Airport?

In the real world, a destination airport is not considered a number or text it is a massive thing that occupies space. Therefore, Airport should be a concept.

17

APPLYING UML: ATTRIBUTE NOTATION

18

ASSOCIATIONS An association is a relationship between classes

(more precisely, instances of those classes) that indicates some meaningful and interesting connection.

19

THE UML NOTATION FOR ASSOCIATIONS

22

MULTIPLICITY• Multiplicity defines how many instances of a

class A can be associated with one instance of a class B.

Multiplicity on association

23

MULTIPLICITY VALUES

Partial conceptual Model

25

26

Cashier

customer

Items

Sale

Sale line itemPOS

Store

Conceptual Model of POS

SEQUENCE MODEL

SEQUENCE DIAGRAMS

• Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system.• A sequence diagram shows the sequence of

interactions that take place during a particular use case or use case instance.• The objects and actors involved are listed along

the top of the diagram, with a dotted line drawn vertically from these. • Interactions between objects are indicated by

annotated arrows.

Chapter 5 System modeling 29

BASIC MESSAGE SYNTAX

• The UML has a standard syntax for message expressions:• return := message(parameter : parameterType) :

returnType.• A sequence diagram may optionally show the

return from a message

31

System Response Actor Action1. This use case begin

when Borrower arrives at the checkpoint after browsing a list of resources to borrow.

3. The system will check member ship and calculate the number of allowed resources, and record them check resources overdue then issues loans card for it.

2. The Library Clerk records the resources for registered borrowers.

5. Logs the completed borrowing.

4. The clerk will return borrower resources with loan card.

5.The Borrower will leave with resources and load card.

Expanded Use Case Format : Borrow Resources

32

Alternatives: Line 2. Borrower are not register cancel borrowing operation.Line 3. Borrower exceed the number of allowed resources clerk not record extra resources

Expanded Use Case Format Example: Borrow Resources(cont.)

VERB-PHRASE OF HIGH-LEVEL USE CASE: BORROW RESOURCES

• From the use case typical course of events high level verb-phrase.1. Borrow Resources.2. records the resources for registered borrowers.3. check member ship.4. calculate the number of resources 5. Record resources.6. check resources overdue.7. issues loans card.8. return borrower resources with loan card.9. Logs the completed borrowing.10. leave with resources and load card.

35

A FIRST LOOK AT SEQUENCE DIAGRAMS

• Illustrates how objects interacts with each other.• Emphasizes time ordering of messages.• Can model simple sequential flow, branching,

iteration, recursion and concurrency.

36

A SEQUENCE DIAGRAM - EXAMPLE 1

member:LibraryMember

book:Book:BookCopy

borrow(book)ok = mayBorrow()

[ok] borrow(member)setTaken(member)

37

A SEQUENCE DIAGRAM

member:LibraryMember

book:Book:BookCopy

borrow(book)ok = mayBorrow()

[ok] borrow(member)setTaken(member)

X-Axis (objects)

Y-Axis (tim

e)

ObjectLife Line

message

Activation box

condition

38

OBJECT

• Object naming:• syntax: [instanceName][:className]• Name classes consistently with your

class diagram (same classes).

• The Life-Line represents the object’s life during the interaction

book:Book

39

MESSAGES

• An interaction between two objects is performed as a message sent from one object to another.• If object obj1 sends a message to another

object obj2 some link must exist between those two objects.

40

MESSAGES (CONT.)

• A message is represented by an arrow between the life lines of two objects.• Self calls are also allowed• The time required by the receiver object to

process the message is denoted by an activation-box.

• A message is labeled at minimum with the message name.• Arguments and control information (conditions,

iteration) may be included.

41

RETURN VALUES

• Optionally indicated using a dashed arrow with a label indicating the return value.• Don’t model a return value when it is obvious what is

being returned, e.g. getTotal()• Model a return value only when you need to refer to it

elsewhere, e.g. as a parameter passed in another message.

• Prefer modeling return values as part of a method invocation, e.g. ok = isValid()

42

OBJECT CREATION

• An object may create another object via a <<create>> message.

:A :B

<<create>>

Constructor

:A

<<create>> :B

Preferred

43

OBJECT DESTRUCTION

• An object may destroy another object via a <<destroy>> message.• An object may destroy itself.• Avoid modeling object destruction unless

memory management is critical.

:A :B

<<destroy>>

44

CONTROL INFORMATION

• Condition• syntax: ‘[‘ expression ’]’ message-label• The message is sent only if the condition is true• example:

• Iteration• syntax: * [ ‘[‘ expression ‘]’ ] message-label• The message is sent many times to possibly multiple

receiver objects.

[ok] borrow(member)

45

CONTROL INFORMATION (CONT.)

• Iteration examples:

:Driver

*[until full] insert()

:Bus

The syntax of

expressions is not a

standard

:CompoundShape :Shape

*draw()draw()

46

EXAMPLE 2

47

EXAMPLE 3

48

EXAMPLE 4

print(doc,client)Client

:PrintServer :Queue:PrinterProxy

enqueue(job)

status

Printing A Document

job=dequeue()

[job]print(job.doc)

[job] done(status)

Repeated forever with 1 min interludes

49

EXAMPLE 5 ATM transaction

50

EXAMPLE 6

• scenario decription – The San Francisco Servicing Department requests that a car with the VIN# 12345 be repaired.  The car availability is queried for a pickup date of 3-14-01 and a return date of 3-15-01.  The system returns that the car is not reserved during those dates.  The Servicing Department books the car for servicing.  The system confirms the booking.