Benghazi University

Faculty Of Information Technology

Software Analysis & Design Course

Lecturer: Mohamed A. Hagal

Object Oriented Design
1 Introduction

since 1986, software researchers and practitioners have been studying the
discipline of object oriented design. in that time, they have developed a set of
well-defined design principles that aid developers in designing software that is
robust, flexible, maintainable, and reusable.

The basic concepts of object oriented paradigm are relatively easy to understand
and easy to apply. The object oriented approach was invented because of the
difficulties, people were trying to produce quality systems on time and within
budget, especially for large systems with many people involved, so the object
orientation is an outstanding approach for software development

2 Design Concepts

Fundamental software design concepts provide the necessary framework for

getting a program right.

2.1 Abstraction

When we consider a modular solution to any problem, many levels of abstraction

can be posed.

 At the highest level of abstraction, a solution is stated in broad

terms using the language of the problem environment.
 At lower levels of abstraction, a more detailed descriptions of the
solution is provided.

2.1.1 Procedural and data abstractions

Procedural abstraction refers to a sequence of instructions that have a specific and

limited function ( i.e. details are suppressed).

An example of procedural a abstraction would be the word OPEN for a door. OPEN
implies a long sequence of procedural steps ( e.g, walk to the door, reach out and
grasp knob, turn knob and pull door, etc.)

Data abstraction is a named collection of data that describes a data object. For
example, the data abstraction for door would encompass a set of attributes that
describe the door ( e.g., door type, weight, direction, etc.)
It follows that the procedural abstraction OPEN would use of information
contained in the attributes of the data abstraction door.

2.2 Architecture

In the simplest form, the architecture is the structure or organization of program

components (modules), the manner in which these components interact, and the
structure of data that are used by the components.

The architectural design can be represented using one or more of a number of

different models.

Structural models represent architecture as an organized collection of program

components.

Dynamic models address the behaviour aspects of the program architecture,

indicating how the structure or system configuration may change as a function of
external events.

Process models focus on the design of the business that the system must
accommodate.

2.3 Patterns

A design pattern describes a design structure that solves a particular design

problem within a specific context. For example, interactive systems consist of
computational elements, as well as elements to display data, and handle user
inputs.

The intent of each design pattern is to provide a description that enables a

designer to determine:

 Whether the pattern can be applicable to the current work.

 Whether the pattern can be reused ( hence, saving design time).
 Whether the pattern can serve as a guide for developing a similar,
but functionality or structurally different pattern.

Example: Context : User interface must be flexible

Problem : problem description

Solution : Component to save the action performed because we

may need undo.
2.4 Modularity

Software is divided into named and addressable components sometimes called

modules, that are integrated to safety problem requirements.

The perceived complexity of two problems when they are combined is often
greater than the sum of the perceived complexity when each is taken separately.
This leads to a “divide and conquer” strategy. So, it is easier to solve a complexity
problem when you break it into manageable pieces.

2.5 Information Hiding

The concept of modularity leads every software designer to a fundamental

question; How do we decompose a software solution to obtain the best set of
modules?

The principle of information hiding suggests that:

Modules should be specified and designed so that information (algorithms and

data) contained within a module is inaccessible to other modules that no need for
such information.

Hiding implies that effective modularity can be achieved by defining a set of

independent modules that communicate with one another only that information
necessary to achieve software function.

The use of information hiding as a design criterion for modular systems provides
the great benefits when modifications are required during testing and later, during
software maintenance.

Inadvertent errors introduced during modification are less likely to propagate to

other locations with the software.

2.6 Functional independence

Functional independence is achieved by developing modules with "single minded"

and an "aversion" to excessive interaction with other modules.

Software with effective modularity, that is independent modules, is easier to

develop because function may be compartmentalized and interfaces are simplified.
Independent modules are easier to maintain (and test ) because secondary effects
caused by design or code modification are limited, error propagation is reduced,
and reusable modules are possible.

Independence is assessed by two qualitative criteria: cohesion and coupling.

Cohesion is a natural extension of the information hiding concept. A cohesive
module performs a single task, requiring little interaction with other components
in other parts of a program, i.e. a cohesive module should (ideally) do just one
thing.

Coupling is an indication of interconnection among modules in a software

structure. Coupling depends on the interface complexity between modules, what
data pass across the interface,..etc.

Simple connectivity among modules results in software that is easier to

understand and less prone to a “triple effect”, caused when errors occur at one
location and propagate throughout a system.

2.7 Refinement

It is actually a process of elaboration, we begin with a statement of function ( or

description of data) that is defined at a high level of abstraction.

Refinement causes the designer to elaborate on the original statement, providing

more and more detail as each successive refinement (elaboration) occurs.

Abstraction and refinement are complementary concepts. Abstraction enables a

designer to specify procedure and data and yet suppress low-level details. While
refinement helps the designer to reveal low-level details as design progress.
3 Object oriented modelling
3.1 Object modelling technique ( OMT 1991)

OMT was introduced by Rumbaugh in 1991. It uses three different models (

analogous to the old structure SA/SD methodology [Demacro 1978, Yourdon and
Costantine 1979), and then defines a method for integrating them. OMT defines a
system by the following models:

 The Object Model (OM): It depicts the object classes in the system and their
relationship, as well as their attributes and operations, and thus represents
the static structure of the system. The object model is represented
graphically by a class diagram.
 The Dynamic Model (Dm): It captures the essential behaviour of the system
by exploring the behaviour of the objects over time, and the flow of control
and events among the objects. Scenarios of the flow of events are captured
in event-trace diagram. These diagrams, along with state transition
diagrams (state charts), compose the OMT dynamic model.
 The Functional Model (FM): Is a hierarchical set of data flow diagrams (DFD)
of the system and describes its internal process without explicit concern for
how these process are actually performed.

3.2 Object oriented software engineering (OOSE)

OOSE is a simplified version of Jacobson’s object methodology, first introduced in

1987, and later the property of Rational Corporation (recently acquired by IBM).

Covering the full generic life cycle. OOSE process consists of three main phases,
each produces a set of models:

 Analysis: ( Understanding the system and creating conceptual model of it).

o Requirements analysis:
 Eliciting the requirements.
 Modelling the requirements.
Requirements model is produced as a result of this activity.

o Robustness analysis:

Modelling the structure of the system in terms interface, data, and

control object, and also by specifying the subsystems that makeup
the overall system.

Analysis model is produced as a result of this activity.

  Construction: (creating a blueprint of the software and produce the code).
o Creating a blueprint of the software and produce the code.
o Design: ( a design model is produced as the result of this activity).
o Implementation: ( an implementation model including code is
produced).
 Testing: V & V the implemented system, a test model is produced during
this phase.

3.3 The Booch method (1994):

It consists of four steps, the process is iterative, so each of the steps may have to
be done more than once.

Identify classes and objects

Identify semantics of classes and objects

Identify relationships between classes and objects

Specify the interfaces and implementation of classes and objects

The first step aimed to identifying classes and objects. The purpose of this step is
to establish the boundaries of the problem and to obtain a first
decomposition(abstraction form).

The second step is concerned with determining the behaviour and attributes of
each abstraction, and the distribution of responsibilities over components of the
system. (attributes and desired behaviours are identified by analyzing typical usage
scenarios. The semantics of usage scenarios are captured in sequence and
collaboration diagrams ( termed interaction diagram and object diagram,
respectively).

The third step concerned with finding relationships between objects. During
analysis, emphasis is on finding relationships between abstraction. During design,
is about inheritance,... the result is shown in class diagrams, collaboration
diagrams, and so-called module diagrams.
Finally, the abstraction are refined up to a detailed level. A decision is made about
the representation of each abstraction, algorithms are selected, and solution-
oriented classes are added when needed.

In this method, the difficult is to decide when to iterate and what to do in a specific
iteration.
3.4 Unified modelling language (UML)

In 1994, Grady Booch and James Rumbaugh, merging their respective

object-oriented development methods with the goal of creating a
single, standard process for developing OO systems. Ivar Jacobson
joined them in 1995, and the three altered their focus to create a
standard object modelling language instead of a standard object orient
approach or method. The object management group (OMG; the body
responsible for creating and maintain the language specification ), adopted the UML
in 1997, and has continually worked to improve it based on industry
needs. OMG defined UML as, “a graphical language for visualizing,
specifying, constructing, and documenting the artifacts of a software
intensive system”

UML diagrams

1. Use case diagrams: depict the interactions between the system

and external systems and users(Actors). In other words, the
graphically describe the functional behaviour of the system as
seen by the user.
2. Static structure diagrams:
a. Class diagrams: they show object classes that the system is
composed of as well as the relationships between these
object classes.
b. Object diagrams: object diagrams are similar to class, but
instead of depicting object classes, they model actual
object instances- showing the current values of the
instance’s attributes. The object diagram provides the
developer with a “snapshot” of the system’s objects at one
point in time. This diagram is not used as often as a class
diagram but, when used, can help a developer better
understand the structure of the system.
3. Interaction diagrams: consisting of a set of objects, their
relationships, and the messages sent between them. These
diagrams model the dynamic behaviour of the system. These
diagrams as follows:
 a. Sequence diagrams: graphically depict how objects
interact with each other via messages. They illustrate how
messages are sent and received between objects and in
what sequence.
b. Collaboration diagrams: these diagrams are similar to
sequence diagrams, but they do not focusing on the
timing. Instead, they present the interaction (or
collaboration) between object in a network format.
4. State diagrams: they also model the dynamic behaviour of the
system.
a. Statechart diagrams: are used to model the dynamic
behaviour of a particular object. They illustrate the
object’s life cycle – the various states that an object can
assume and the events that cause the object to transition
from one state to another.
b. Activity diagram: are used to graphically depict the
sequential flow of activities of either a business process or
a use case. They also can be used to model action that will
be performed when an operation is executed.
5. Implementation diagrams:
a. Component diagrams: are used to graphically depict the
organization and dependencies of the system’s software
components. They can be used to show how programming
code is divided into modules (or component).
b. Deployment diagrams: describe the physical architecture
in terms of “nodes” for the hardware and software in the
system. They depict the configuration of run-time
software components, processors, and devices that
makeup the system’s architecture.
Use case diagram

Use case typically stand for verb phrases that can be derived from user
requirements and from possible uses of the system actors.

Example: Online chat system.

Use cases are : add user, remove user, receive message and send
message.

Actor: chat user.

Online system

Add user

Remove user

Receive
message

Chat user
Send message

Extend relationship:

Use cases may be related by extend relation. An extend

relationship is a generalization relationship where one use case extends
another use case by adding actions to it.

( extends relationship involves inheritance, because the specialized use

case is subset of the general one ).

Use case 1 General use case

<< extends>>

Use case 2 Specialize use case

Example:

Browse

<< extends>>

search

Because every search, when it commences, requires a browsing activity.

Uses/include relationship:

Uses/include is a generalization relationship where one use case uses

another use case indicating that, as part of the specialized use case, the
behaviour of the general use case will also be included.

( two use cases might not have any kind of inheritance, but one still use
the other for a specific purpose).

Use case 1 General use case

<< uses >>

Use case 2 Specialize use

case

Make << Include >>

Validate Patient
appointment record

a use case includes the functionality described in the

another use case as a part of its business process
Example:

Gives price

<< extends>>

Locate book
Whenever a book is located it has to return the price of the item.
Example: Use case diagram of a computer game:

Computer game

Choose a game type

<<uses>>

Saves information

Player
Makes move Board

<<uses>>

Check legal move

Update itself

Example: A simple library system

Record Booking

Cancel
<<uses>>

Get list

Librarian Record arrived Secretary

A full description of a use case model includes:

 A basic course of events

 An number of alternative and exceptional courses

Basic concept of courses of events. ( This happens in the “normal case” )

For example:

Use case: Record booking

Actor(s): Librarian

Normal course of events:

1. Librarian enters date

2. System displays booking
3. Librarian enters details
4. System records and displays new booking

( often a dialogue between system and user ).

Alternative course of events. ( describe alternative flows )

1. if list is available (i.e. if there are available items to record)

a. librarian enters date
else
a. end use case
3. Librarian enters details
a. If invalid details display message "re-enter the
details"

Exceptional course of events

1. librarian enters date

2. system display booking
3. librarian enters details
4. system asks for confirmation of over sizing booking
5. if “no” use case terminates with no booking made
6. if “yes”, booking record with warning flag
 Example: use case diagram for school database:

The diagram presents a use case diagram of a school administration

system. The system keeps data on students including biographies of
students and academic records. It permits the administration to update,
to produce a printout, and draw statistical information.

The diagram presents two main actors. Secretary and administration.

The administration has the access rights to the system as that a
secretary, and in addition can query the system for statistical results.

School administration system

<<extends>>
Enter student Print student biographic
biographic information file

Update student
view student biographic biographic file
Secretary file

<<extends>>
Enter academic records
Print student grades

<<extends>>

update student record

Administration
Get statistical results
Get query results
Activity diagrams

Activity diagram is similar to flowchart and is used to represent what

happens as the system performs its functions.

An example, Uml activity diagram for eliciting requirements.

Conduct meetings
Elicit requirements

Make list of functions

Make list of constraints, ...etc

Formal prioritization
[yes]
[No]

Use QFD to prioritize Informally prioritize

requirements requirements

Create use cases

Define actors

Draw use case diagram

Write scenario
Synchronization bar
Complete template

Three levels of elaboration.

Ex2: Inquiry about an item in the library

Enter participant Id

Check participant
[Not found]
[found]

Display message Enter item’s

“invalid Id” registration code

search
[Not found] [found]

Display message Browse item’s information

“invalid item reg. code”

Ex3: Return item

Enter item’s reg. code

Search an item
[Not found]
[found]

Display message “invalid Enter return date

item reg. code”
Check date of returns
[Late returns]
[On time]
Generate penalty

Update number of
copies
Classes and objects

A class describes the state of objects in terms of attributes, and

behaviour in terms of methods(operations).

An object is created at run time as an instance of class abstraction,

several objects may be created as instances of a single class.
Class name

Attributes (states)

Methods (behaviour)

Ex1. Some examples of classes for a rent car examples.

Company Car

Ex2. Some class of Library system

Publication Librarian Book

-Name: string
+Id: integer

Add()
Modify()

Associations:

Two analysis classes are related to one another, these relationships are
called associations.
1 manage 1
Manager company

One to one associations

relationship
 1 owns 1..*
Company car

one to many association relationship.

Note: 1..* at least one.

10..20 at least 10 and not more than 20.

* zero or more.

1..* takes 1..*

Student Course

Many to many association relationship.

1..* 1..*
Student Book

Copy

Associations class relationship ( class related with another class by another class).
`

Aggregation:

An aggregation is a relation between classes that models “consist of”

relation, i.e. a relation in which one larger “whole” contains one or more
smaller “parts” classes.
ex1.

X Y

Aggregation relationship. X consists of Y.

ex2.

1..*
Company Branch

ex3.

1..* 1..*
Car Driver

Body Motor

Class diagram.

Composition aggregation

Composition is a strong aggregation is that the whole object is

completely responsible for the part object and the part object can be
associated on to one whole ( the part cannot exist without whole).
Ex1.

Book

1..* 1..* 1..*

Cover Chapter Appendix

1..*
page

*
paragraph

Generalization

A generalization relation models an “is-a” between two classes or one

parent and several children classes, i.e. one class is other’s superclass.
For example, A is generalization of another class B if we can express the
following B is an A.
A Person

Is - a

B student
 Person

+ Id integer
- Name string
- address string

Add()

student Teacher

+Semester integer +status char

- Gpa double -degree string
+Dept string
Add(address, degree,....)
Add() Modify()

Dependency relationship

Class depends on another class if changes in this class follows change in

the next class when depend on.

Customer Order

+name String -date Date

+address String 1 1..* +Invoic_no Integer

Add() Add(No,nm,....)
CalcTotal()

1..* Item
Payment Order_detail
Item_code Integer
+amount double - quantity 1 1..* Description String
- tax -Price double
-weight double
ClacSubTotal() getPrice()
CalcWeight() GetWeight()

Class diagram example.

Summary: The relationship between classes & objects.

- A class is an abstract definition of an object.

- It defines the structure and behaviour of each object in the class.
- It serves as a template for creating objects.

Person

+ Id integer
- Name string
- address string

Add()

student Teacher

+Semester integer +status char

- Gpa double -degree string
+Dept string
Add(address, degree,....)
Add() Modify()

Class diagram
:Person

Id 123
Name “ali”
address “Sert”

: student :Teacher

Semester 2 status “M”

Gpa 2.5 degree “Lecturer”
Dept “SE”

Object diagram
Sequence diagram

UML sequence diagrams model the flow of logic within your system in a
visual manner, enabling you both to document and validate your logic,
and are commonly used for both analysis and design purposes.

A sequence diagram shows object interactions arranged in a time

sequence (i.e. the sequence of messages exchanged between the
objects needed to carry out the functionality of the scenario).

:Object1 :Object2

M1

R1

M2

Instead of three arrows between the two objects, we have two arrows
with a condition on the second arrow.

:Object1 :Object2

M1

M2[result from r1=true]

Notes.....

Reflexive or message can sent to itself(object)

accept

X
reject

Ex.

:student :registrar

Request_reg(name,percente)

check

Ok

Or,,,,,

:student :registrar

Request_reg(name,percente)

Accept[percentage>=70%]
Example. Sequence diagram for a bookstore inventory system. it has
three objects: the customer, the bookstore and the book.

The customer orders a requested book from bookstore, the bookstore

responsible locates it in the books database, if the book is found, the
price is returned to the customer who will pay for it and get the book
from the bookstore.

:customer :bookstore :book

orderbook(title,author)
locate(title,author) check

Book is found

Return price

give price

Gives book

Ex2. When the customer wants to buy a property, he/she has to accept
the agreement conditions displayed by the system. Then, he/she has to
submit his/her credit card number to the many handling subsystem.

In case the number is false, he/she has to resubmit the information

again until the credit card number is a valid one. After this, the system
will retrieve the customer information from the database, update the
information, and mark the property chosen by the customer as sold.
(H.W).
 theBookBorrowerUI : joe : Member c : Copy b : Book
joeUser :
BookBorrowerUI
BookBorrower

borrow(MID, CID)
borrow(Copy)

okToBorrow( )

borrow(Member)
borrow( )

Note: The reason why they’re called sequence diagrams should be

obvious: the sequential nature of the logic is shown via the ordering of
the messages (the horizontal arrows). The first message starts in the top
left corner, the next message appears just below that one, and so on.

Alternatives

Alternatives are used to designate a mutually exclusive choice.

Alternatives allow the modeling of the classic "if then else" logic (e.g., if I
buy three items, then I get 20% off my purchase; else I get 10% off my
purchase).

If you want to show several alternative interactions, use an 'alt'

combined fragment. The combined fragment contains an operand for
each alternative. Each alternative has a guard and contains the
interaction that occurs when the condition for that guard is met.
The following figure shows the sequence starting at the top, with the
bank object getting the check's amount and the account's balance. At
this point in the sequence the alternative combination fragment takes
over. Because of the guard "[balance >= amount]," if the account's
balance is greater than or equal to the amount, then the sequence
continues with the bank object sending the addDebitTransaction and
storePhotoOfCheck messages to the account object. However, if the
balance is not greater than or equal to the amount, then the sequence
proceeds with the bank object sending the addInsuffientFundFee and
noteReturnedCheck message to the account object and the returnCheck
message to itself. The second sequence is called when the balance is not
greater than or equal to the amount because of the "[else]" guard. In
alternative combination fragments, the "[else]" guard is not required;
and if an operand does not have an explicit guard on it, then the "[else]"
guard is to be assumed.
Option

Option used to model a sequence that, given a certain condition, will

occur; otherwise, the sequence does not occur. An option is used to
model a simple "if then" statement (i.e., if there are fewer than five
donuts on the shelf, then make two dozen more donuts). In this case,
‘opt’ will be used instead of ‘alt’.

If you want to show that several messages are conditionally sent under
the same guard, you'll have to use an 'opt' combined fragment. The
combined fragment is shown as a large rectangle with an 'opt' operator
plus a guard, and contains all the conditional messages under that
guard.

Loop

Occasionally you will need to model a repetitive sequence. The loop

combination fragment is very similar in appearance to the option
combination fragment. You draw a frame, and in the frame's namebox
the text "loop" is placed. Inside the frame's content area the loop's
guard is placed towards the top left corner, on top of a lifeline.
Referencing another sequence diagram

When doing sequence diagrams, developers love to reuse existing

sequence diagrams in their diagram's sequences. [Note: It is possible to
reuse a sequence diagram.
This figure shows a sequence diagram that references the sequence
diagrams "Balance Lookup" and "Debit Account." The sequence starts at
the top left, with the customer sending a message to the teller object.
The teller object sends a message to the their Bank object. At that point,
the Balance Lookup sequence diagram is called, with the
accountNumber passed as a parameter. The Balance Lookup sequence
diagram returns the balance variable. Then the option combination
fragment's guard condition is checked to verify the balance is greater
than the amount variable. In cases where the balance is greater than the
amount, the Debit Account sequence diagram is called, passing it the
accountNumber and the amount as parameters. After that sequence is
complete, the withdrawCash message returns cash to the customer.
Break

When the sequence gets to the return value "balance," it checks to see if
the balance is less than the amount. If the balance is not less than the
amount, the next message sent is the addDebitTransaction message,
and the sequence continues as normal. However, in cases where the
balance is less than the amount, then the sequence enters the break
combination fragment and its messages are sent. Once all the messages
in the break combination have been sent, the sequence exits without
sending any of the remaining messages (e.g., addDebitTransaction).

Parallel

Today's modern computer systems are advancing in complexity and at

times perform concurrent tasks. When the processing time required to
complete portions of a complex task is longer than desired, some
systems handle parts of the processing in parallel. The parallel
combination fragment element needs to be used when creating a
sequence diagram that shows parallel processing activities.

The parallel combination fragment is drawn using a frame, and you place
the text "par" in the frame's namebox. You then break up the frame's
content section into horizontal operands separated by a dashed line.
Each operand in the frame represents a thread of execution done in
parallel.
The following figure offers an easy-to-understand example of a
sequence with parallel activities. The sequence goes like this: A
hungryPerson sends the cookFood message to the oven object. When
the oven object receives that message, it sends two messages to itself at
the same time (nukeFood and rotateFood). After both of these messages
are done, the hungryPerson object is returned yummyFood from the
oven object.

Collaboration diagram

A collaboration diagram models interaction among objects. The order in

which messages are passed is indicated with a number.

Collaboration diagrams differ from sequence diagrams in that they

capture ordered sequencing, but without including separate life lines like
in sequence diagrams.
Ex. Collaboration diagram o a bookstore.

3:book is found

:Book :Bookstore

2: locates the book

4:return the price
5:gives mode of order
and payment 6:gives the book

1: orders a book

:Customer

Ex. Collaboration diagram of an ATM system.

1:inser card
3: locates password
9: enters kind
11:enters amount
17:takes cash
18:removes his card
:User :ATM
16:dispense cash
10:requests amount
8:requests kind 4:validate account
2:requests password 12:process transaction

6:bank accept
14:bank transaction succeed
:Bank :Consortium

13:process bank
5:verify card
 :AddAdvert :Client :Campiagn :Advert

:CampaignManager

Loop [ For all clients]

getClients

:AddASdvetUI

StartInterface
SelectClient
ShowClientCampaigns

listCampaigns

Loop * For all client’s campaigns adverts+

getClients

listAdverts

Loop *For all campaign’s adverts+

getAdvertDetails
State Diagrams

State diagrams are used to describe the behaviour of a system. State

diagrams describe all of the possible states of an object as events
occur. Each diagram usually represents objects of a single class and
track the different states of its objects through the system.
Only use state diagrams for classes where it is necessary to understand
the behaviour of the object through the entire system.
The basic elements are rounded boxes representing the state of the
object and arrows indicting the transition to the next state. The activity
section of the state symbol depicts what activities the object will be
doing while it is in that state.

All state diagrams being with an initial state of the object. This is the
state of the object when it is created. After the initial state the object
begins changing states. Conditions based on the activities can
determine what the next state the object transitions to.
Example: Order object

When the object enters the Checking state it performs the activity "check items." After the
activity is completed the object transitions to the next state based on the conditions [all items
available] or [an item is not available]. If an item is not available the order is canceled. If all
items are available then the order is dispatched. When the object transitions to the
Dispatching state the activity "initiate delivery" is performed. After this activity is complete the
object transitions again to the Delivered state.

State diagrams can also show a super-state for the object. A super-state is used when many
transitions lead to a certain state. Instead of showing all of the transitions from each state to
the redundant state a super-state can be used to show that all of the states inside of the
super-state can transition to the redundant state. This helps make the state diagram easier to
read.
Both the Checking and Dispatching states can transition into the Canceled state, so a
transition is shown from a super-state named Active to the state Cancel. By contrast, the
state Dispatching can only transition to the Delivered state, so we show an arrow only from
the Dispatching state to the Delivered state.

Example: Hotel Reservation State Transition Diagram

Note:

You can see that transitions are a reflection of your business rules. For example, you
see that you can attempt to enroll a student in a course only when it is open for
enrolment or full, and that a seminar may be split (presumably into two seminars)
when the waiting list is long enough to justify the split. You can have recursive
transitions, also called self transitions, that start and end in the same state. An
example of which is the student dropped transition when the seminar is full.

Example: top level state diagram of the above example.

Example: ATM-machine
Package Diagram
Packages are an organization of the defined classes into groups. i.e. shows the
breakdown of larger system into logical grouping of small subsystems (i.e., a package
is usually a collection of related classes)

 Allow developer to show how classes could be divided into modules.

 They use the same associations as class-diagrams (aggregation, association,
generalization, dependency,..etc).

Package A
package name

Package B Package C

Example: ATM machine.

The package diagram shows how the various classes are grouped into packages. There
are two "top-level" classes - ATMMain and ATMApplet - which allow the system to
be run (respectively) as an application or as an Applet. (Only one of the two would be
instantiated in any particular use of the system.)

Each of these classes, in turn, depends on the package ATM which contains the class
ATM that represents the system as a whole, and the class Session that represents one
session. ATM depends on Session, and vice versa - since the ATM creates Sessions,
and each Session, in turn, uses the ATM to interact with the customer.

The subpackage transaction contains the classes used to represent individual

transactions that a customer initiates. The class Session depends on the transaction
package because it creates individual transaction objects. These, in turn, again depend
on the ATM to interact with the customer.

The subpackage physical contains the classes that represent the various physical
components of the ATM. For the purposes of this simulation, these are simulated by a
GUI. A real ATM would have quite different classes in this package - classes that
actually control its physical components. The class ATM makes use of these
components, and Session and the various kinds of transaction gain access to them
through ATM to actually perform the needed operations.

Finally, the package banking contains classes that represent the banking enterprise
itself and the information communicated back and forth between the ATM and the
bank - i.e. classes which might be the same in a totally different implementation of an
ATM that interacts with the same bank.

This is, of course, a simulation. However, most of the code that is specific to the
simulation resides in the package physical, plus the two top-level classes. Presumably,
the other classes and packages might be similar in a real system.

See the following example:

Each subsystem depends on the other and each is affected by changes in
others interface.

SubSysA

SubSysA

Example:

Requirements model Specification model

Use case diagram Class diagram

Behavioral diagram

Implementation model

Component & deployment diagrams

 coupling

Subsystem C Subsystem A

Subsystem D Subsystem B

cohesion

- Cohesion between classes in a package while coupling between

classes in different packages.