Exam

Design Methods
CT015-3-2 Version 1
Object Oriented Analysis and

Modelling Part 1
Topics and Structure of the Lesson
- UML Model and Diagram
CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1 Slide <2> of 18
Learning Objectives
• At the end of this lecture, you should be

able to :
-Understand UML Model and Diagram
-Creating UML diagrams in models
Key Terms
• UML
• Model
• Diagram
UML
• Unified Modeling Language

• A standard language for specifying, visualizing, constructing, and
documenting the artifacts of software systems.
• Developed to provide standardized graphical language and
notations for describing object-oriented model
• UML also includes new concepts that were not present in other
major methods at the time, such as extension mechanisms and a
constraint language.
• It was developed in the mid-1990s as a collaborative effort by
James Rumbaugh, Grady Booch and Ivar Jacobson, each of whom
had developed their own notation in the early 1990s
UML Models
• System development focuses on three different models of the

system
– Functional model: describes the functionality of the system
from the user’s point of view
– Object model: describes the structure of the system in terms of
objects, attributes, associations, and operations
– Dynamic model: describes the internal behavior of the system
• We describe UML diagrams for representing these models
UML Model
• Use models to:
– Specify structure, behavior, or both
– Visualize an existing system to improve understanding
– Automate system development (Model-Driven Development)
• UML model files (.emx) contain:
– Model elements
– Diagrams
– Profile information
– User preferences
– Workspace information
Developing multiple model
• You can model a system using

multiple models
– How many models to use
depends on:
• The modelled system and model complexity
• Team development and configuration
management considerations
• Organizational standards and practices
• Your own preference
UML Diagrams
• UML diagrams graphically depict a view of a part of your
model or code
• Different diagrams represent different views of the system
you are developing
• A model element appears in zero or more diagrams
UML diagram versus UML model
• A model can contain one or more diagrams.

• A diagram presents a view of parts of a model.
• A model element that appears only once in your
model can appear in one or more diagrams.
– Different diagrams present different contexts.
UML Views
• There are five different views that the UML aims to
visualize through different modeling diagrams
– User's View
– Structural Views
– Behavioral Views
– Environmental View
– Implementation View
• This is done through different types of UML diagrams.
UML Diagrams Types
How many diagrams do you
need?
• Depends on the artifacts being modeled and the needs of users
– Use diagrams to visualize the system from different
perspectives
– No complex system can be understood in its entirety from
only one perspective
• Model elements can appear in zero or more diagrams
– A class can:
• Appear in zero or more class diagrams
• Be represented in a state machine diagram
• Have instances that appear on a sequence diagram
– Each diagram provides a different perspective
Creating UML diagrams
• Use diagrams to represent different views of the system

or application:
– UML diagrams
– Non-UML (freeform) diagrams
• Create diagrams in:
– Models
– Model elements
• Packages
• Components
• And so on
Freeform diagrams and geometric
shapes
• Freeform diagrams can include UML and non-UML
Elements
– No free-form modelling standards
– Most common that included when creating UML
packages
– Can display geometric shapes and another non-UML
notation
– Use for sketches and other informal modeling
Freeform diagrams and geometric
shapes
Review : Diagram editor
Quick & Review Question
• What is UML?
• List all UML diagram.
• What is free form diagrams?
Summary of Teaching points
• UML Model and Diagram
Q&A
What We Will Cover Next
• Object Oriented Analysis and Modelling

Part 2
Design Methods
CT015-3-2 Version 1

Modelling Part 2
• Overview of UML Notation
Learning Objectives

able to :
-Understand UML diagrams and notations
-Explain UML Extension Mechanisms
Key Terms
• Notations
Use case diagram
• A use case defines a sequence of interactions between the

actor and the system.
• In Use case diagram :
- An actor is depicted as a stick figure
- The system is depicted as a box.
- A use case is depicted as an oval inside the box.
- Communication associations is depicted as line
that connect actors with the use cases
- Relationships among use cases are defined by means of
include and extend relationships.
Use case diagram
Classes and Objects
• Classes and objects are depicted as boxes.

• The class box holds the class name
• Optionally, the attributes and operations of a class may
also be depicted.
Classes and Objects
• To distinguish between a class (the type)

and an object (an instance of the type), an
object name is shown underlined.
• Classes and objects are depicted on

various UML diagrams
Class diagram
• In a class diagram, classes are depicted as

boxes, and the relationships between them
are depicted as lines connecting the boxes.
• 3 main types of relationships between
classes are supported:
- associations
- whole/part relationships
- generalization/specialization
Class diagram
Class diagram
• On each end of the association line joining the classes is

the multiplicity of the association, which indicates how
many instances of one class are related to an instance of
the other class.
Interaction diagram:
Communication diagram
• Shows how cooperating objects
dynamically interact with each other by
sending and receiving messages.
• Objects are shown as boxes,
and lines joining boxes represent
object interconnection.
• Labeled arrows indicate the name
and direction of message transmission
between objects and must be numbered.
• Iteration is indicated by an asterisk (∗)
• An optional condition means that the
message is sent only if the condition is true.
Interaction diagram: Sequence
diagram
• A two-dimensional diagram in which the objects participating in the
interaction are depicted horizontally and the vertical dimension
represents time.
• Starting at each object box is a vertical dashed line, referred to as a
lifeline. (Optionally, each lifeline has an activation bar, depicted as a
double solid line, which shows when the object is executing )
• Labeled horizontal arrows represent messages which sent from the
source object to the destination object.
State machine diagram
• In shorter term statechart

• States are represented by rounded boxes, and
transitions are represented by arrow that connect the
rounded boxes
• Initial state is depicted by an arrow originating from a
small black circle.
• A final state may be depicted by a small black circle
inside a larger white circle
• On the arrow representing the state transition, the notation

Event [condition]/Action is used.
- The Event causes the state transition.
- The optional condition must be true, when the event occur
- Action is performed as a result of the transition.
• Optionally, a state may have any of the following:
- entry action, performed when the state is entered
- exit action, performed on exit from the state
Composite state with orthogonal
substates
• When the composite B is initially entered,
each of the substates B1 and B3 is also
entered.
Packages
• Package is a grouping of model elements

– for example, to represent a system or
subsystem.
• A package is depicted by a folder icon, a
large rectangle with a small rectangle
attached on one corner.
• Packages may also be nested within other
packages.
Packages
• Possible relationships between packages are

dependency and generalization/specialization
relationships.
• Packages may be used to contain classes, objects, or
use cases.
Concurrent communication
diagram
• An active object can be used to
depict a concurrent object, process,
thread, or task.
• Depicted by a rectangular box with
two vertical parallel lines on the left-
and right-hand sides.
• An active object has its own thread
of control and executes concurrently
with other objects.
• A passive object has no thread of
control and executes only when
another object (active or passive)
invokes one of its operations.
• Depicted by a rectangular box
diagram
• Message send between tasks are either asynchronous (loosely
coupled) or synchronous (tightly coupled).
• Use simple messages during analysis modeling when no

decision has yet been made about the type of message
communication.
diagram
Deployment diagrams
• A deployment diagram shows
the physical configuration of the
system in terms of physical nodes
and physical connections
between the nodes, such as
network connections.
• A node is shown as a cube, and
the connection is shown as a line
joining the nodes.
• A deployment diagram is
essentially a class diagram that
focuses on the system’s nodes
UML Extension Mechanism
• UML provides three mechanisms to allow

the language to be extended.
- stereotypes
- tagged values
- constraints.
UML Extension Mechanism :
stereotypes
• defines a new building block that is
derived from an existing UML modeling
element but tailored to the modeler’s
problem
Tagged values
• A tagged value extends the properties of a UML building
block thereby adding new information.
• A tagged value is enclosed in braces in the form {tag =
value}.
• Commas separate additional tagged values.
• For example, a class may be depicted with the tagged
values {version = 1.0, author = Gill}
Constraints
• A constraint specifies a condition that
must be true.
• In UML, a constraint is an extension of the
semantics of a UML element to allow the
addition of new rules or modifications to
existing rules
UML as a Standard
UML 2.0
(2004)
UML 1.5 Model business

(March, ‘03) process
UML UML 1.1

Partners’ (Sept. ‘97)
Expertise
UML 1.0
(Jan. ‘97) Associated more
with software
UML 0.9 and UML 0.91 engineering and
(June ‘96) (Oct. ‘96) system design
Public
Unified Method 0.8 Feedback
(OOPSLA ’95)
Booch ’93 OMT - 2
OOSE Other Booch ‘91 OMT - 1

Methods
• Lists notation in use case diagram

• Describe the difference between active
and passive objects?
• Overview of UML Notation
Q&A

Part 3
Design Methods
CT015-3-2 Version 1

Modelling Part 1
• Software Methodology (COMET)
CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1 Slide <#> of 24
Learning objectives

able to :
– Explain and identify COMET
– Explain comparison of the COMET with
other Software Processes
Key Terms
• COMET
COMET
(Collaborative Object Modeling
and Architectural Design Method)
• An iterative use case–driven and object-oriented method that

specifically addresses - requirements, analysis, and design
modeling phases of the software development life cycle.
• Development process for the COMET method is a use case–based
software process.
• The COMET method ties in the three phases of requirements,
analysis, and design modeling
COMET
(Collaborative Object Modeling
and Architectural Design Method)
COMET Phases:
Requirements modeling
• A requirements model is developed in which the functional
requirements of the system are described in terms of actors
and use cases.
• A narrative description of each use case is developed.
• In this phase, user inputs and active participation are
essential
• Throwaway prototypes can help to clarify the requirements.
COMET Phases:
Analysis modeling
• The use case is realized, to describe the objects that participate in the
use case and their interactions
• Static and dynamic models of the system are developed.
– Static Models
• Defines the structural relationships among problem domain
classes which depicted on class diagrams. Object structuring
criteria are used to determine the objects to be considered for the
analysis model.
– Dynamic Models
• The use cases from the requirements model are realized to show
the objects that participate in each use case and how they interact
with each other which are depicted on either communication
diagrams or sequence diagrams. In the dynamic model, state-
dependent objects are defined using statecharts.
COMET Phases:
Design modeling
• The software architecture is developed, describing
components and their interfaces
• The software architecture of the system is designed
in which the analysis model mapped to an operational
environment.
• The analysis model, with its emphasis on the problem
domain, is mapped to the design model
• Subsystem structuring criteria are provided to
structure the system into subsystems, which are
aggregate or composite objects.
COMET Phases:
Design modeling
• For sequential systems: the emphasis is on the object-
oriented concepts of information hiding, classes, and
inheritance.
• For concurrent systems: such as real-time, client/server,
and distributed applications, it is necessary to consider
concurrent tasking concepts in addition to object-oriented
concepts.
COMET Phases:
Incremental Software Construction
• The software subsystems are incrementally constructed and
integrated into incremental prototypes.
• Select subset of system based on use cases
• This phase consists of:-
- detailed design
- coding
- unit testing
• Gradually constructed and integrated until the whole system
is built.
COMET Phases:
Incremental Software Integration
• The integration testing of each software increment is
performed based on the use cases selected for the
increment.
• Integration testing is a form of white box testing, in which
the interfaces between the objects that participate in
each use case are tested.
• If significant problems are detected in the software
increment, iteration through the requirements modeling,
analysis modeling, and design modeling phases might
be necessary.
COMET Phases:
System testing
• System testing includes the functional testing of
the system
- testing the system against its functional
requirements.
• This testing is black box testing and is based on
the black box use cases
• Any software increment released to the
customer needs to go through the system
testing phase.
Comparison Of The Comet
Life Cycle With Other Software
Processes
Unified Software Development
Process (USDP)
• Also known as RUP - trademark name for
IBM
• A use case–driven software process that
uses the UML notation.
• Consists of 5 workflows and 4 phases and
is iterative.
USDP
COMET vs USDP
• Directly compatible with COMET

– The first three phases even have same names
• USDP’s Testing phase is broken into
COMET’s Incremental Integration and
System Testing phases
– These activities should be performed by
separate teams.
• Incremental Integration -> Development Team
• System Testing -> Testing Team
Spiral
• A risk-driven process model

• Each cycle of the spiral model iterates
through these four quadrants and the
number of cycles is project-specific.
Spiral
COMET vs Spiral
• The COMET method can also be used with the spiral model
when project manager decides what specific technical activity
should be performed in the third quadrant.
 (I) Quadrant : Objective identification
 (II) Quadrant : Risk analysis
 (III) Quadrant : Product development
- Requirement Modeling
- Analysis Modeling
- Design Modeling
 (IV) Quadrant : Cycle planning
• What is COMET?
• List all the phases in COMET.
• Explain the difference between USDP and
COMET life cycle?
Q&A

Part 3 (Continue)
Design Methods
CT015-3-2 Version 1

Modelling Part 2 (Continue)
• Activities in COMET
Learning objectives

able to :
– Understand modeling activities in
COMET
Key Terms
• Black-box use case
Modeling Activities in COMET
• COMET defines the modeling phases

thus:
– Requirements: defining the function of the
system.
– Analysis: Decomposing the problem for better
understanding.
– Design: Producing the solution into a
complete system.
Activities in Requirements Modeling
• The functional requirements of the system

are described in terms of use cases and
actors
• Addressing nonfunctional requirements is
also important at the requirements phase.
Activities in Analysis Modeling
• Emphasis on understanding the problem

in terms of domain objects and the
information passed between them:
– Static Modeling
– Object Structuring
– Dynamic Interaction Modeling
– Dynamic State Machine Modeling
* Important note: Other design issues deferred to design phase, e.g.

active/passive, sync/async, operation invoked
Activities in Analysis Modeling
Activities in Analysis Modeling :
Static Modeling
• Define problem-specific static model*
– Structural view
• Classes defined in terms of attributes
– Emphasis on info modeling of real-world classes
in the problem domain
• Relationships between classes defined
* Important note: Operations are defined in the design

model
Object Structuring
• Determine the objects that participate in each
use case, e.g.
– Entity
– Interface
– Control
– Application logic
• After objects determined, dynamic relationships

are determined in dynamic model
Dynamic Interaction Modeling
• The use cases are refined to show the

interaction among the participating objects
• Communication diagrams or sequence diagrams
are developed
Dynamic State Machine
Modeling
• State-dependent system properties
defined
– Using hierarchical state-charts
– Each state-dependent object determined is
defined in terms of its constituent statechart
Activities in Design Modeling
• During this phase, the analysis model is mapped to a

concurrent design model which is software
architectures, the following activities are performed:
- Integrate the object communication model. Develop
integrated object communication diagram(s). (Ch13)
- Make decisions about subsystem structure and interfaces.
Develop the overall software architecture. Structure the
application into subsystems. (Ch13)
- Make decisions about what software architectural and design
patterns to use in the software architecture. (Ch12, 15, 16,
17, 18)
Subsystem Structure Example
Software Architectural and
Design Patterns Example
- Make decisions about class interfaces. For each subsystem,

design the information hiding classes (passive classes).
Design the operations of each class and the parameters of
each operation. (Ch14)
- Make decisions about how to structure the distributed
application into distributed subsystems, in which subsystems
are designed as configurable components, and define the

message communication interfaces between the components.
(Ch13, 15, 16, and 17).
- Make decisions about the characteristics of objects,

particularly whether they are active or passive. For each
subsystem, structure the system into concurrent tasks (active
objects). (Ch18)
- Make decisions about the characteristics of messages,
particularly whether they are asynchronous or synchronous
(with or without reply). (Ch12, 13, 15, 16, 17, and 18)
• Describe the activities in Requirement

Modeling.
• Explain activities that occur in Analysis
Modeling.
Q&A
• Use Case Modelling
Design Methods
CT015-3-2 Version 1
Use Case Modeling

• Use case notations

• Relationship
CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1

Learning objectives

able to :
– Describe the elements in a use-case
diagram
– Describe the associations and
relationships possible in a use-case
model
– Create a use-case diagram
Key Terms
• Association
• Actor
• System Boundary

Use Case
• A use case defines a sequence of interactions between

one or more actors and the system.
• A use case diagram elements - actors, use cases and
system boundaries.
• The system is defined through the system boundaries.

Use Case Diagram Purpose
• Built in early stages of development

• To demonstrate the different ways that a user might
interact with a system.
• Purpose
– Specify the context of a system
– Capture the requirements of a system
– Validate a systems architecture
– Drive implementation and generate test cases
– Developed by analysts and domain experts

Use Case Notation
• System Boundary
– The use cases of the system are placed inside the system
shape, while the actor who interact with the system are put
outside the system.
– The use cases in the system make up the total requirements of
the system System Name

Use Case Notation
• Use Case
– represents a user goal that can be achieved by accessing the
system or software application
– Use case naming is based on “verb + noun”
– Example: Check Balance
Check Balance

Use Case Notation
• Actor
– Are the entities that interact with a system
– Usually used to represent the users of system
– Actor represents a role that a user can play but not a specific
user

Use Case Notation
• Association
– Actor and use case can be associated to indicate that the actor
participates in that use case
– A single line without any arrowhead

Exercise
• In a XYZ library system, a user can register as client.

While an admin able to view the client details.

Use Case Notation
• Generalization
– Used to represent inheritance relationship between model
elements of same type
– A single line with blank arrowhead

Use Case Notation
• Include
– The behavior for the inclusion use case is inserted into the
behavior defined for the base use case
– The child use case must be completed before parent use case
can be executed
– included use case cannot stand alone and the original use case
is not complete without the included one

Use Case Notation
• No need Include
– A customer can make an order and payment using the system.
• Need Include
– A customer can only make a payment once the order is placed
using the system.

Use Case Notation
• Extend
– A use case conditionally adds steps to another first class use
case
– Base use case is complete (concrete) by itself, defined
independently
– Extending use case is optional, supplementary

Use Case Notation
• No need Extend
– In a system user can make registration or look for help if need
guide to make a registration.
• Need Extend
– In a system user can make registration and able to seek for help
during the registration before complete the process.

Guideline to Draw Use Case
Diagram
• A use case diagram should be as simple as possible
• A use case diagram should be complete
• A use case diagram should represent all interactions with
the use case
• If there are too many use cases or actors, then only the
essential use cases should be represented
• A use case diagram should describe at least a single
module of a system
• If the use case diagram is large, then it should be
generalized

Example of Use Case Diagram

Example of Use Case Diagram

Exercises
1. Draw Use Case Diagram for the following:
When the customer completed the registration, the

admin sends approval notation

Exercises
A student able to register up to four courses per

semester, an admin also may help students to
register for the courses

Exercises
A customer need to make a payment. The customer

have an option to print a receipt upon complete
payment.

Exercises
A lecturer, academic leader and any ABC Tuition Center

employees may view student’s feedback.

• Draw and explain all the elements in use

case.
• State the purposes of Use Case Diagram.
• State six guideline to draw a use case
diagram.

• Use case modelling

• Use case notations
• Relationship

Q&A

• Use Case Specifications

Design Methods
CT015-3-2 Version 1
Use Case Specifications

- Documenting Use Cases in the Use Case

Model
- Use Case Relationships
Learning objectives

able to :
– Documenting use cases
Key Terms
• Dependency
• Pre-condition
• Post-condition
Use Case Description
• Each use case in the use case model need to be

documented in a use case description.
• A textual description of the sequence of
transactions of a use case is needed to
understand what really happens in a use case.
• The flow-of-events is written in terms of what the
system should do, not how the system does it.
Templates for a Use Case
Specifications
Components Description
Use case Each use case is given a name
Description A brief description of the use case
Actors Names the actors in the use case. Generally, primary
actor that initiates the use case. In addition, there may be
secondary actors that also participate in the use case
Preconditions/ One or more conditions that must be true at the start of
Dependency use case, from the perspective of this use case
Postconditions Condition that is always true at the end of the use case
(from the perspective of this use case) if the main
sequence has been followed; for example, customer’s
funds have been withdrawn
<<include>>
View Login
profile
Templates for a Use Case
Specifications
Components Description
Standard Process A series of declarative steps - sequence of interactions
between the actor and the system. The description is in
the form of the input from the actor, followed by the
response of the system
Alternative Narrative description of alternative branches off the main
Process sequence – to complete standard process
Exception Process There may be several alternative branches from the main
sequence – to handle error in standard process
Sample of Use Case Description
Use case UC1_Make Order Request

Description This use case is used to help customer to make an order on the
products they have selected. The purchase can only be made via
credit card.
Actors Customer
Preconditions/ One product at least must be selected by customer to start make
Dependency an order.
Postconditions Delivery order has successfully created.
Standard Process 1- Customer provides order detail
2- System checks customer information
3- System retrieves customer payment information record
4- System checks customer credit card for purchase amount, if
approves, proceed with confirmation
5- Customer confirm the order
6- System create delivery order with order details and customer
details
7- System display success order and display order information to
CT015-3-2 Design Methods
customerObject Oriented Analysis and Modelling Part 1 Slide <10> of 14
Alternative Step 5a: Cancel order

Process 5a.1- The system prompt cancelation successful
5a.2- Terminate the order process
5a.3- Exit the use case
Exception Flow Step 2a: Not login into account / Invalid account
2a.1- The system prompts customer request to login or create an
account
2a.2- The flow continue from step 1
Step 3a: No payment detail found

3a.1- The system prompts customer a page for payment details
3a.2- Once completed, proceed to step 4.
Step 3b: Credit card request denied

3b.1- The system prompts error message.
3b.2- The customer have an option to enter new credit card details
proceed to step 3a, or cancel the order proceed to step 5a.
• Explain flows-of-event.
• Defines preconditions.
- Documenting Use Cases in the Use Case

Model
- Use Case Relationships
Q&A
• Activity Diagram Modeling
Design Methods
CT015-3-2 Version 1
Activity Diagram Modeling

Topic and Structure of the Lesson
- Elements in an activity diagram

- Control and object flows

Learning objectives

able to :
– Describe the kinds of actions in an
activity
– Describe control and object flows
– Create an activity diagram

Activity Diagram
• Depicting the flow of control and

sequencing among activities.
• An activity diagram shows the sequence of
activities, decision nodes, loops, and even
concurrent activities.
• To depict one or more steps in the use
case description.

Activity Diagram
• Activity diagrams can describe system

workflow, use case, class, or operation
behaviour
– Read like a flowchart
• Can model control and dataflow
– Sequential and synchronous actions
CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1 ‹#›
Elements in Activity Diagram
Elements Notation Explanation
Initial Node Indicates the first action
or actions in the activity.
Example:

Control Flow A connector that shows
the flow of control
between actions.
Example:

Action A rectangle with rounded
corners. A step in the
Activity activity, in which the
users or software
perform some task.
Example:

Decisions A diamond represents a decision with
alternate paths. Has one input and two or
more outputs. An incoming token emerges
on just one of the outputs.
Example:

Activity Final Node An end to the activity.
When a token arrives,
the activity terminates.
Example:

Flow Final Node A flow final node terminates a flow.
Unlike the activity final node, which
ends an entire activity.
Example:

Fork node Used to split a single incoming flow into
multiple concurrent flows. It is
represented as a straight, slightly thicker
line in an activity diagram.
Example:

Join node Joins multiple concurrent flows back into a
single outgoing flow. It is represented as a
straight, slightly thicker line in an activity
diagram
Example:

Merge node A merge event brings together multiple flows
that are not concurrent. Bring back together
different decision paths that were created
using a decision-node.
Example:

Activity Partition The individual elements of an activity
Partition 1 Partition 2 diagram can be divided into individual
areas or 'partitions'. Various criteria can
lead to the creation of these partitions:
organization entities, cost centers,
locations, etc:
Example:

Call Behaviour A call behavior action represents a linked
Action call to a separate activity (and its
corresponding activity diagrams)
Example:

Call operation action: modelling
class operations
• A call operation action transmits an operation call
request
• To create, drag an operation onto the
diagram to create a call operation
action
– The action takes the name of the operation

Object flow
• Object flow models the data flow within an activity

• Object flow can only be attached to object nodes or
pins on actions
• Object nodes and object flow provide the
capabilities for explicit data flow modeling
•An object node represents the data participating in
an activity diagram
– It represents an instance of a classifier (such as
a class), as well as the corresponding data and
behaviour
Object Flow

Object Flow
• An object node is an abstract class, and is

specialized by the following object nodes:
• Pins
• Activity parameter nodes
• Data stores

Object Flow : Pins
• Pins are either input pins or output pins

• Pins model where actions and activities
are sending and receiving data

Object Flow: Activity Parameter
• Represent the data parameters coming

into or going out of an activity
– Can send and receive
– May have an associated data type (such
as a class or interface)

Object Flow: Data store
• Used to model persistent data, such as

saving information to a database, or
retrieving information from a database

Object Flows Example

Review
• Draw and explain all the elements in

activity diagram.

2
>
o
f
1
4
- Elements in an activity diagram

- Control and object flows

3
>
o
f
1
4
Q&A

4
>
o
f
1
4
• Static Modeling

Design Methods
CT015-3-2 Version 1
Static Modelling
• Static Modeling
-Notations
-Relationships
Learning objectives

able to :
– Describe static modelling
– Describe the elements in a class
diagram
– Describe the associations and
relationships possible in a class model
– Create a class diagram
Key Terms
• Object
• Associations
• Composition / Aggregation
• Generalization / Specialization
Static Modelling
• Describes static structure of the system being
modeled, which is considered less likely to change
than the functions of the system
• The UML class diagram notation is used to depict
static model
• In OO Analysis Modelling
– Define classes in system
– Defines attributes of classes
– Defines relationships between classes
• In OO Design Modelling
– Defines operations of each class
Object and Classes
• Objects represent “things” in real world

– Provide understanding of real world
– Form basis for a computer solution
• An Object (object instance) is a single “thing”
– E.g., an account, an employee
• A Class (object class) is a collection of
objects with the same characteristics
– E.g., account, employee
Example of code for object and
class
class Student1{ //class
int id;
String name;
public static void main(String args[]){

Student1 s1=new Student1(); //creating an object of Student
System.out.println(s1.id);
System.out.println(s1.name);
}
}
UML notation for objects &
classes
Modeling with class diagrams
• Class diagrams are used to capture static

structure in:
– Conceptual modelling
– Detailed design modelling
– Implementation modelling
Relationship on Class Diagram
• Relationships between classes

– Associations
– Composition / Aggregation
– Generalization / Specialization
• Other type of relationship
– Dependency
– Realization
Relationship on Class Diagram
Association
• Association is
– Static, structural relationship between classes
– E.g, Employee works in Department
• Navigability can be unidirectional or
bidirectional
• Multiplicity of Associations
– Specifies how many instances of one class may
relate to a single instance of another class

Association
Multiplicity of Association
• 1-to-1 association
– Company has President
• 1-to-many association
– Bank manages Account
• Numerically specified association
– Car has 2,4 Door
• Optional association (0 or 1)
– Customer owns Debit Card
• Optional association (0, 1, or many)
– Customer owns Credit Card
• Many-to-Many association
– Course has Student
– Student attends Course
Aggregation
• Aggregation
– Part objects of aggregate object may be created
and deleted independently of aggregate
object.
– it is binary association
– symbolized by a clear white diamond
– “is part of”
• A car needs a wheel to function correctly, but a wheel
doesn’t always need a car. It can also be used with the
bike, bicycle, or any other vehicles but not a particular
car. Here, the wheel object is meaningful even without
the car object. Such type of relationship is called UML
Aggregation relation.
Composition
• Whole and part objects are created, live, die together

• A composition is a stronger relationship than an aggregation
• Often also has a physical association
• “is entirely made of”
• Association between instances
• symbolized by a black diamond
– E.g., Composite class: ATM
– Part classes:
Keypad, CardReader, CashDispenser,
ReceiptPrinter
• The folder could contain many files, while
each File has exactly one Folder parent. If
a folder is deleted, all contained files are
removed as well.
Generalization
• A generalization relationship is one in

which a class shares the structure and
behavior of one or more classes
• Subclass inherits a superclass
• Often described as an “is a” relationship
– E.g., Coupe is a Automobile
Sedan is a Automobile
Dependency
• A dependency relationship describes a case
where one class uses another
• Dependencies may exist between classes
because:
– A message is sent from one class to the other
– One class is part of another's data
– One mentions the other as a parameter to an
operation
Realization
• A realization relationship describes a client

implementing a supplier's specification (an
interface)
Class Diagram Example
CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1 Slide ‹#› of 9
• What is the difference between

aggregation and composition?
• Which relationships can be bidirectional?
• Static Modeling
-Notations
-Relationships
Q&A
• Object and Class Structuring
OBJECT ORIENTED METHODS
CE52604-5
Class Diagram Part 2

Lecture Objectives
At the end of this lecture, you should be able

to:
1.describe what CRC is and how it is used

with respect to class diagram.
2. draw a class diagram based on CRC

specifying attributes and methods.

Keywords
At the end of this lecture You will be able to :
• Class Responsibility Collaboration (CRC)

• Class diagram
• Collaborator
• Responsibility

Analysis & Design
Use Case Diagram Analysis
CRC & Class Diagram Design

What is an Object?
• “Something you can do things to. An

object has state, behavior, and
identity”(Booch, 1994)
• “A Software package that contains a
collection of related data and functions”
• An object represents either a real world or
invented entity

What does an object do?
• holds information - it has what is called a

state and behaviour
• participates proactively or reactively in
processes
• communicates with other objects (client-
server systems)
• allow to use (or reuse) existing software
components

Object Formal Definition
• We mentioned before that an object has :-

• State
• Behavior
• Identity
• But what does this mean?

Object State
• The state of an object is one of the

possible conditions in which it may exist
(Booch, 96)
• The state can change over time
• The state is represented by the values of
an object

State Example 1…
• Here is an example of another object:-

A Car
• The car is stopped
• The engine is off
• The car is currently in a non-moving state.
• Start the engine and change gear and the
car will be in a different state!

State Example 2 …
• The state of a particular object is the values of
its attributes at any particular moment. For
example, a cat might have the following state:
• Name: Max
• Breed: American Shorthair
• Colour: Black, brown & white
• Age: 3 years, 4 months, 8 days
• Weight: 5.1 kg
• Some of these attributes change constantly.
Others stay the same for long periods or forever.

Object Behavior
• “Behavior determines how an object acts

and reacts; its state changes and
interaction with other objects” (Booch, 96)
• The Object Behavior defines how it will
react to other objects
• Each object has a set of operations which
it can perform which determines its
behavior

Object Identity
• Each Object is unique even if its state is

the same as another object
Student
Student_ID Student_Name +Student_ID: Int

+Student_Name: String
Student +EnrollModule()
Class Diagram
ERD

Objects - Our Intuition
• We are all familiar with the idea of an object. We are

surrounded by them: cars, books, people, houses, cats,
etc.
• Objects have attributes/state, e.g. colour, size, age, name.
• Objects also have behavior/method. They can do things,
e.g. grow, breathe, run, stop.

Attributes and Behaviour
Object Attributes Behaviour
Registration number Start

Car Make Stop
Model Turn
Year Accelerate
Colour Flash lights
Cat Name Sleep

Breed Eat
Colour Purr
Age Climb
Weight Scratch

Describing An Object
• How would you describe this to a

computer: A man
• Mr John Smith
• 42 years old
• Brown hair, blue eyes
• Height 1.6m and weight 70kg

CRC
• CRC (class responsibility collaborator)

modeling process for identifying user
requirements.
- An effective, low-tech method for
developers and users to work closely
together to identify and understand
business requirements.
• Consists of class, responsibility and
collaboration.
CRC
• A class represents a collection of similar object

• A responsibility is anything that a class knows
or does.
- Customers have names, customer numbers, and
phone numbers. These are the things that a
customer knows.
- Customers order products, cancel orders, and
make payments. These are the things that a
customer does.

CRC
• Sometimes a class will have a responsibility

to fulfill, but will not have enough information
to do it. When this happens it has to
collaborate with other classes to get the job
done.
-To calculate the order total, the Order object collaborates
with each Order Item object to calculate its own total,
and then adds up all the totals to calculate the overall
total. For each Order Item to calculate its individual
total, it has to collaborate with Item to determine the cost
of the ordered item, multiplying it by the number ordered
CRC

Creating Class Diagram
Scenario
Students are allowed to borrow books, return books and

make advanced bookings for books via a librarian. Students
make payment for books overdue. Students may cancel
bookings. The option of canceling a booking is possible
whilst a book is being borrowed.

Step 1
Step 1: Identify Candidate Classes
Hint:
(i) Classes are nouns
(ii) Just identify the ones that are obvious to you. You
may identify more later.
Candidate Classes:
Student
Book
Booking
Payment

Step 2
Step 2: Draw CRCs for each identified class.
Hint:
(i) Each identified class in step (i) becomes a CRC
with the same name.

Step 3
Step 3: For each CRC, fill what you think might be
the responsibilities & collaboration
Hint:
(i) Collaborators are identified classes – i.e student,
book, etc.
(ii) There could be one responsibility having two
collaborators and vice versa.
(iii) It is possible to have a responsibility with NO
collaborators.
(iv) Each responsibilities should ideally be expressed in
a few words (usually not more than 4) and must
begin with a verb.
Step 3 (continued)

Step 4
Step 4: Map CRC to create a class diagram.
Hint:
(i) Each CRC becomes a class of its own.
(ii) A CRC having two or more collaborators would
mean having similarly two or more connected
classes.
(iii) Responsibility of a CRC would turn out to be
methods of the class
(iv) Methods usually begin with a verb – i.e
generateReport().

Step 4 (continued)

Step 5
Step 5: Further refine class diagram with attributes,
multiplicities, new classes (if found) and new
methods (if found).
Hint:
(i) Every class should have at least one method.
(ii) You may include NEW classes to your class
diagram without worrying about having to make
similar updates to the CRC. Once the class
diagram has been created, all changes will ONLY
reflect the class diagram and no longer the
CRCs.

Step 5 (continued)

In Class Exercise 1
Create a CRC and a class diagram for the scenario below:
Inventory System
In order to generate an invoice a clerk must log in. If a

clerk is a first time user, one must have themselves
registered. There should be an option for a user to register
oneself within the login page. Any user can use the system
to view products online.The option of login is also provided
when a user views products online.

Summary
– describe what CRC is and how it is used with

respect to class diagram.
– draw a class diagram based on CRC
specifying attributes and methods.

Q&A

Design Methods
CT015-3-2 Version 1
Object and Class Structuring

• Object structuring criteria and categories
Learning objectives

able to :
– Describe object structuring criteria and
categories
Key Terms
• Entity object
• Boundary object
• Control object
• Application logic object
• First attempt at determining the software objects

in the system.
– a class is categorized by the role it plays in the
application. Object and class structuring criteria are
provided to assist the designer in structuring a system
into its constituent classes and objects.
• Determines and Categorizes the software
interfaces to the objects developed in the Static
Modeling phase.
• The beginnings of the Dynamic Model
Criteria
• Determine all software objects in system

– Use Object Structuring Criteria
– Guidelines for identifying object
• Structuring criteria depicted using stereotypes
– Stereotype defines a new building block that is derived
from an existing UML modelling element but is tailored to
the modeller's problem
– Depicted using guillemets
«entity», «boundary», «control»
Categories
• The four main categories :
1. Entity object
– represents the class where the data to be saved to or
retrieved from.
2. Boundary object
– Software object that interfaces to and communicates
with the external environment
Device Interface Objects connect to a hardware I/O device.
User Interface Objects provide for human user interaction.
System Interface Objects represent external systems or
subsystems.
Categories
3. Control object
– Software object that provides the overall coordination
for a collection of objects. Control objects may be
coordinator objects, state-dependent control
objects, or timer objects.
4. Application logic object
– Software object that contains the details of the
application logic. Another category is service objects,
which provide services for client objects, typically in
service-oriented architectures and applications.
Classification of application
classes by stereotype
Boundary Object
• Boundary objects are further categorized as:

– User interaction object
Software object that interacts with and interfaces to a
human user.
– Proxy object
Software object that interfaces to and communicates
with an external system or subsystem.
– Device I/O boundary object
Software object that receives input from and/or outputs
to a hardware I/O device.
Boundary :User interaction
• Communicates directly with
the human user, receiving
input from the user and
providing output to the user
via standard I/O devices
such as the keyboard,
visual display, mouse and
GUI.
Boundary : Proxy
• Interfaces to an external system
– Interfaces to an
external system
– Hides details of how
to communicate with
external system
• E.g., Robot Proxy
• Interfaces to external (real-
world) robot
Boundary : Device I/O
• Interfaces to I/O device
• Input object
– E.g., Sensor
Interface
• Output object
– E.g., Actuator
Interface
• I/O (Input/Output) object
– E.g., ATM Card
Reader Interface
Device I/O boundary object
Depicting External Classes and
Boundary Classes
Entity Classes and Objects
• Entity Objects are long living.

– Used by many use cases.
– Store information that persists across use
cases.
E.g., Account, Sensor
• Entity objects are instances of the entity classes
developed in the Static Modeling phase.
• Entity classes often mapped to relational
database during design
Entity Classes and Objects
Example of entity class and object
Control Classes and Objects
• Provides overall coordination for execution of a

group of objects
– Makes overall decisions
– Decides when, and in what order, other
objects participate in interaction sequence
• Entity objects
• Boundary objects
Control Classes and Objects
• Control Objects:
– Coordinator object
Overall decision-making object that determines the
overall sequencing for a collection of related objects.
– State dependent control object
Defined by finite state machine - depicted by using a
statechart.
– Timer object
A control object that is activated by an external timer –
e.g, a real-time clock or operating system clock.
Control :Coordinator object
Example of
coordinator class
and object
Control : state-dependent
Example of
state-dependent
control class and
object
Control : Tmer
Example of a
timer class and
object
Application Logic Classes and
Objects
• 3 kinds of application logic objects:
– Business Logic Object
Defines business specific application logic (rules) for
processing a client request. Usually accesses more
than one entity object
– Algorithm Object
Encapsulates algorithm used in problem domain. More
usual in scientific, engineering, real-time domains
– Service object
Provides a service to other objects and responds to
requests from client objects
Application Logic : business logic
Example of
business logic
class and object
Application Logic : algorithm
Example of
algorithm class
and object
Application Logic: service
Example of service
class and object
• What is boundary object?

• State 3 sub-types of application logic
objects?
• Object structuring criteria and categories
Q&A
• Interaction Modeling
Design Methods
CT015-3-2 Version 1
Interaction Modelling
-Types
-Notations
-Relationships
Learning objectives
• At the end of this lecture, you should be able to :

– Describe the purpose and use of
interaction diagrams
– Describe the elements and relationships
in interaction diagrams
– Create sequence and communication
diagrams
Key Terms
• Communication diagram
• Sequence diagram
Dynamic Modelling
• Determine how objects interact with each other to
support use case:
– Start with external event from actor
– Determine objects needed to support
use case
– Determine sequence of internal events
following external event
– Depict on communication diagram or
sequence diagram
Communication Diagram
• Graphically depicts objects interacting with

each other
– Show objects as boxes
– Show their message interactions as arrows
– Number sequence of messages
Sequence Diagram
• Shows sequence of object interactions in use

case
• Emphasis on messages passed between
objects
– Objects represented by vertical lines
– Messages represented by labeled
horizontal arrows
Message Sequence Description
• Describes sequence of object interactions
– Narrative description
– Corresponds to Communication Diagram or Sequence
Diagram
• Description corresponds to message sequence
numbering on diagrams
– Describe what object does on receiving message
• E.g., every time an object interacts with an entity object
– Describe the object being accessed
– Identify attributes referenced
Use Case Specification
Use case UC1_Make Order Request
Description This use case is used to help customer to make an order on the
products they have selected. The purchase can only be made via
credit card.
Actors Customer
Preconditions/ One product at least must be selected by customer to start make
Dependency an order.
Postconditions Delivery order has successfully created.
Standard Process 1- Customer provides order detail
2- System checks customer information
3- System retrieves customer payment information record
4- System checks customer credit card for purchase amount, if
approves, creates credit card purchase
5- Customer confirm the order
6- System create delivery order with order details and customer
details
7- System display success order and display order information to
customer
Use Case Specification
Alternative Step 3a: No payment detail found

Process 3a.1- The system prompts customer a page for payment details
31.2- Once completed, proceed to step 4.
Exception Flow Step 2a: Not login into account / Invalid account
2a.1- The system prompts customer request to login or create an
account
2a.2- The flow continue from step 1
Step 3b: Credit card request denied

3b.1- The system prompts error message.
3b.2- The customer have an option to enter new credit card details
proceed to step 3a, or cancel the order proceed to step 5a.
Step 5a: Cancel order

5a.1- The system prompt cancelation successful
5a.2- Terminate the order process
5a.3- Exit the use case
Message Sequence Description
for Make Order Request
• 1: Customer provides order detail
• 2: System checks customer information
• 3: System retrieves customer payment information
record
• 4: System checks customer credit card for purchase
amount, if approves, creates credit card purchase
• 5: Customer confirm the order
• 6: System create delivery order with order details and
customer details
• 7: System display success order and display order
information to customer
• Make Order Request use case
Sequence Diagram
• Make Order Request use case
Combined Fragments
• Combined fragment is an interaction fragment which

defines a combination (expression) of interaction
fragments.
• A combined fragment is defined by an interaction
operator and corresponding interaction operands.
• Through the use of combined fragments the user will be
able to describe a number of traces in a compact and
concise manner.
• Purpose: Eliminate repetitive modeling
Combined Fragments
Fragment type Description
Opt Optional. Encloses a sequence that might or might not happen. You can specify, in the
guard, the condition under which it occurs.
Alt Contains a list of fragments that contain alternative sequences of messages. Only one
sequence occurs on any occasion.
You can put a guard in each fragment to indicate under what condition it can run. A guard
of else indicates a fragment that should run if no other guard is true. If all guards are false
and there is no else, then none of the fragments executes.
Loop The fragment repeats some number of times. You can indicate in the guard the condition
under which it should repeat.
Loop combined fragments have the properties Min and Max, which indicate the minimum
and maximum number of times that the fragment can be repeated. The default is no
restriction.
Ref Interaction use is interaction fragment which allows to use (or call) another interaction.
Large and complex sequence diagrams could be simplified with interaction uses. It is also
common reusing some interaction between several other interactions.
Combined Fragments
Alternative
fragment
box Optional
fragment
box
Interaction use
Loop/iterative / reference
fragment box fragment box
Sequence Diagram
• Make Order
Request use
case
Sequence versus Communication
Diagram
• When would you use a sequence versus a

communication diagram?
• What is an interaction use in a sequence
diagram? Why would you use one?
-Types
-Notations
-Relationships
Exercise
Use case UC2_Delete Order
Description This use case is used to help admin to delete an order on the products they
have selected. The delete feature can only be access in admin panel.
Actors Admin
Preconditions/ One product at least must be selected by customer to start make an order.
Dependency
Postconditions Order has successfully deleted.
Standard Process 1- System display list of order
2- Admin select Order, and click delete
3- System request for confirmation
4- Admin confirm the deletion process
6- System delete the order in database
7- System display success deleted order
Alternative None
Exception 1a: No Order Record

1a.1 – System display message no order record found
1a.2 – Exit use case
4a: Admin Cancel Delete Operation

4a.1 – System terminate delete process
4a.2 – Success terminate delete displayed
Exercise
Use case1 UC2_Search Order
Description2 This use case is used to help admin to search an order has been
made by customer.
Actors1 Admin
Preconditions/ At least one order must be exist to use this features.
Dependency1
Postconditions1 Order made by customer has successfully listed.
Standard 1- Admin select order status pending/completed, and submit
Process5 2- System validate the record in database
3- System display list of record based on request status
Alternative1 None
Exception3 1a: No Order Record
1a.1 – System display message no order record found
1a.2 – Exit use case
Q&A
• Finite State Machines
Design Methods
CT015-3-2 Version 1
Finite State Machine

• Finite State Machine Modeling

-Notations
-Relationships

Learning objectives

able to :
– Describe the elements in a state machine
diagram
– Describe the relationships in a state
machine diagram
– Create a state machine diagram

Keywords
• State
• Orthogonal

Finite State Machines
• Also referred to as state machine

• Finite state machines are used for
modeling the control and sequencing view
of a system or object.
• Notations used to define finite state
machines are the state transition,
triggering events and actions.

Finite State Machines
• Shows the behavior of one object of a

single class
– shows all possible states of this object
– shows how the object’s state changes as a
result of messages it receives

States
• State = a recognizable situation that exists over
an interval of time
•The arrival of an event at the finite state machine
usually causes a transition from one state to
another
•Some states represent the state machine waiting
for an event from the external environment

States
Updating
Waiting for Approval
Appointment
Creating Cancelling
Appointment Appointment
Viewing Appointment
List
State Actions
• Actions: Work the system does in response

to events
– States can have entry, exit, and do
activities performed while in the state
• E.g.

State Action
Creating Appointment Cancelling Appointment
Entry/ load appointment Entry/ received request

detail
Do/ saving into database Do/ cancelling the
appointment
Exit/ display message Exit/ display message
Transitions
• A transition is the path taken during a

change of state from one state to the next
in response to a triggeringevent
• Guard condition: Optional condition to be
evaluated; if false, the transition is not taken

State Machines
• State transitions:
Possible paths the
system may take from
one state to another
• Triggering events:
Instantaneous events that
stimulate state transitions

Transitions
Initiate [true]/ get appointment list
Viewing Appointment
List Trigger event or action
Trigger event or action [Guard condition]
Applying
Appointment
Submit Clicked submitted [false]/ request new input

[true]/ Creating
submitted [true]/ sent to approval queue

Creating
Waiting for Approval
Appointment
Orthogonal States
• To model different views of the same

object’s state.
• Are composite states with two or more
regions within the state.
• The two orthogonal statecharts are shown
separated by dashed line

Playing
Radio
Display
Current
Time

Choice Points
• Choice points realize a dynamic

conditional branch
– Outputs transitions, each with a guard
condition, one of which must be true.

Junctions
• Junctions realize a static conditional branch
– Can be used to split or join multiple transitions
– Guard conditions are evaluated before transitions
are fired
• If all guard conditions return false, then remain in the source

Example of state machine
diagram

diagram

diagram

• Which model elements can have

associated state machine diagrams?
• In what cases would you use state
machine diagrams?
• What is a choice point?
• What is a junction?

• Finite State Machine Modeling

-Notations
-Relationships

Q&A

• Revision and Assignment

Discussion/Progress

Design Methods
CT015-3-2 & Version 1
Other UML Diagram

Topic & Structure of The Lesson
• Introduction to other UML diagrams
CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1 Slide ‹308› of 20
Learning Outcomes
• At the end of this topic, You should be able to:

- Have a basic knowledge of other UML diagrams .
Lecture Content
Structure Diagrams
• Object Diagram,
• Component Diagram,
• Package Diagram,
• Deployment Diagram.
Object Diagram
• Is a graph of instances, including objects and

data values.
• A static object diagram is an instance of a class

diagram; it shows a snapshot of the detailed
state of a system at a point in time.
• Use a subset of the elements of a class diagram

in order to emphasize the relationship between
instances of classes at some point in time
Object Diagram
Component Diagram
• Higher level of
abstraction than a
Class Diagram
• Component
diagram shows
components,
provided and
required
interfaces, ports,
and relationships
between them.
Component Diagram
Package Diagram
• Package diagram is UML structure diagram
which shows structure of the designed system at
the level of packages.
• Reflect the organization of packages and their
elements.
Deployment Diagram
• Models the run-time architecture of a system

• Shows the configuration of the hardware
elements (nodes) and shows how software
elements and artifacts are mapped onto those
nodes
Composite Structure Diagram
• Composite Structure Diagram could be

used to show:
- internal structure of a classifier
- classifier interactions with environment
through ports,
- a behavior of a collaboration
Composite Structure Diagram
Overview shows
elements of
internal structure
of structured
classifier - roles,
parts, connectors.
Interaction Diagrams
• Communication Diagram,
• Timing Diagram,
• Interaction Overview Diagram.
• Formerly called a collaboration diagram, is an

interaction diagram that shows similar
information to sequence diagrams but its primary
focus is on object relationships.
Timing Diagram
• Display the change
in state or value of
one or more
elements over time.
It can also show the
interaction between
timed events and the
time and duration
constraints that
govern them.
Interaction Overview Diagram.
• A form of activity
diagram in which
the nodes represent
interaction
diagrams.
Interaction
diagrams can
include sequence,
communication,
interaction overview
and timing diagrams
• Higher level view
Reading
• More details descriptions are available

from:
– http://www.sparxsystems.com/resources/
uml2_tutorial/
Others:
• http://www.tutorialspoint.com/uml/uml_2_o
verview.htm
• http://www.agilemodeling.com/essays/uml
Diagrams.htm
Summary of Main Teaching Points
• Other UML Diagrams
Question and Answer Session
Q&A

Exam

Uploaded by

Exam

Uploaded by

Design Methods

Object Oriented Analysis and

- UML Model and Diagram

• At the end of this lecture, you should be

• Unified Modeling Language

• System development focuses on three different models of the

• We describe UML diagrams for representing these models

• You can model a system using

• A model can contain one or more diagrams.

• This is done through different types of UML diagrams.

• Use diagrams to represent different views of the system

• UML Model and Diagram

• Object Oriented Analysis and Modelling

Object Oriented Analysis and

• Overview of UML Notation

• At the end of this lecture, you should be

• A use case defines a sequence of interactions between the

• Classes and objects are depicted as boxes.

• To distinguish between a class (the type)

• Classes and objects are depicted on

• In a class diagram, classes are depicted as

• On each end of the association line joining the classes is

• In shorter term statechart

• On the arrow representing the state transition, the notation

• Package is a grouping of model elements

• Possible relationships between packages are

• Use simple messages during analysis modeling when no

• UML provides three mechanisms to allow

UML 1.5 Model business

UML UML 1.1

Booch ’93 OMT - 2

OOSE Other Booch ‘91 OMT - 1

• Lists notation in use case diagram

• Overview of UML Notation

• Object Oriented Analysis and Modelling

Object Oriented Analysis and

• Software Methodology (COMET)

• At the end of this lecture, you should be

• An iterative use case–driven and object-oriented method that

• Directly compatible with COMET

• A risk-driven process model

• Software Methodology (COMET)

• Object Oriented Analysis and Modelling

Object Oriented Analysis and

• At the end of this lecture, you should be

• Black-box use case

• COMET defines the modeling phases

• The functional requirements of the system

• Emphasis on understanding the problem

* Important note: Other design issues deferred to design phase, e.g.

* Important note: Operations are defined in the design

• After objects determined, dynamic relationships

• The use cases are refined to show the

• During this phase, the analysis model is mapped to a

- Make decisions about class interfaces. For each subsystem,

are designed as configurable components, and define the

- Make decisions about the characteristics of objects,

• Describe the activities in Requirement

• Software Methodology (COMET)

• Use Case Modelling

Use Case Modeling

• Use case notations

CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1

• At the end of this lecture, you should be

CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1

• A use case defines a sequence of interactions between

CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1

• Built in early stages of development

CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1

CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1

CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1

CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1

CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1

• In a XYZ library system, a user can register as client.

CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1

CT015-3-2 Design Methods Object Oriented Analysis and Modelling Part 1