Object-Oriented Systems Analysis and Design Using UML

Chapter 18
Object-Oriented Systems
Analysis and Design Using UML
Systems Analysis and Design

Kendall & Kendall
Sixth Edition
Major Topics
• Object-oriented concepts and

terminology
• CRC (Class, Responsibility&
Collaborator) Cards
• Unified Modeling Language
• Use case and other UML diagrams
• Relationships
Kendall & Kendall © 2005 Pearson Prentice Hall 18-2
Diskusi ?
• Apa keuntungan membuat program

dengan konsep OOP ?

Mengapa OOP memiliki
keuntungan?
• OOP sangat cocok untuk pembuatan aplikasi
besar (modularity)
• OOP memungkinkan kita untuk melakukan
update ataupun maintenance tanpa
merombak dari nol (framework concept)
• OOP didesain untuk pembuatan aplikasi
dibuat secara tim

Object-Oriented Overview
• Object-oriented (o-o) techniques work well
in situations where complicated systems are
undergoing continuous maintenance,
adaptation, and design.
• The Unified Modeling Language (UML) is
an industry standard for modeling object-
oriented systems.

Goals of O-O Analysis
• Reusability is the main goal.

• Maintaining systems is an important
goal.
• Making a change in one object has a
minimal impact on other objects.

Object-Oriented Concepts
Definitions and concepts:
• An object, represents a real-world thing or
event.
• Objects may be customers, items, orders
and so on.
• Objects may be GUI displays or text
areas on a display.

Object-Oriented Concepts
Definitions and concepts (continued):
• Objects are represented by and grouped into
classes.
• A class, or group of related objects has a set of
shared attributes and behaviors.
• Instantiate is a term used when an object is created
from a class.
• Attributes are properties of a class possessed by all
objects.
• A method is an action that can be requested from any
object in the class.

Class Symbol

Inheritance
• Inheritance is when a new class is
created from another class.
• The original class is the parent or base
class.
• The new class is the child or derived
class.
• The child class receives the attributes
and methods of the parent class.

CRC Cards
Class, responsibilities, and collaborators
(CRC) cards are used to represent the
responsibilities of classes and the
interaction between the classes.

Creating CRC Cards
Analysts create CRC cards by:
• Finding all the nouns and verbs in a
problem statement.
• Creating scenarios that are actually
walkthroughs of system functions.
• Identifying and refining responsibilities into
smaller and smaller tasks, if possible.

Creating CRC Cards
Analysts create CRC cards by
(continued):
• Determining how tasks are fulfilled by
objects or interact with other things.
• Identifying responsibilities that evolve into
methods or operations.

The Unified Modeling
Language (UML)
UML has three categories:
• Things, the objects.
• Relationships, the glue that holds things
together.
• Diagrams, categorized as either structure
or behavioral.

Two General Groupings of
Things
There are two general groupings of things in
UML:
• Structural things that define the conceptual and
physical structures of an O-O system and are
described by nouns.
• Behavioral things/ Diagram, the verbs of a UML
model that represent the behavior of the system
and the states of the system before, during,
and after the behaviors occur.

Structural Things
Structural things are the most common
and include:
• Classes.
• Use cases.
• Interfaces.

Behavioral Things/Diagrams
Behavioral things include:
• Interactions.
• State machines.

Types of Relationships
There are two types of relationships that
hold things together:
• Structural relationships tie things together
in structural diagrams.
• Behavioral relationship are used in
behavioral diagrams.

Structural Relationships
Structural relationships are:
• Dependencies (Ketergantungan).
• Aggregations (Hub Kuat/Part-of).
• Associations (Hub Lemah/Is-a).
• Generalizations (Kesimpulan).

Behavioral Relationships
• Behavioral relationships are:

• Communicates.
• Includes.
• Extends.
• Generalizes.

Structural Diagrams
Structural things are the most common
and include:
• Class and object diagrams.
• Use case diagrams.
• Component diagrams.
• Deployment diagrams.

Behavioral Things/Diagrams
Behavioral things include:
• Use case diagrams.
• Sequence diagrams.
• Collaboration diagrams.
• Statechart diagrams.
• Activity diagrams.

Commonly Used UML Diagrams
The most commonly used UML diagrams

are:
• Use case diagram, describing how the
system is used.
• The starting point for UML modeling.
• Use case (not a diagram).
• Activity diagram.
• Each use case may create one activity diagram.


(continued):
• Sequence diagram, showing the sequence
of activities and class relationships.
• Each use case may create one or more
sequence diagrams.
• A collaboration diagram is an alternative to a
sequence diagram.


(continued):
• Class diagram, showing classes and
relationships.
• Sequence diagrams and CRC cards are used to
determine classes.
• Statechart diagram.
• Each class may create a statechart diagram,
useful for determining class methods.

Overview of UML Diagrams

Use Case Diagram
• A use (yoos) case describes what the
system does, not how it does the work.
• The use case model reflects the view of the
system of the user outside of the system.
• Symbols are:
• Actor, a stick figure.
• Use case, an oval.
• Connecting lines.

Actors
• Represent role played by one or more
users
• Exist outside of the system
• May be a person, another system, a
device, such as a keyboard or Web
connection
• Can initiate an instance of a use case
• May interact with one or more use cases and a
use case may involve one or more actors

Actors (Continued)
• Actors may be divided into two groups:

• Primary actors supply data or receive
information from the system
• Secondary actors help to keep the
system running or provide help
• Help desk, analysts, programmers, etc.

Use Case
• Consists of three things:

• An actor (user) that initiates an event.
• An event that triggers a use case.
• The use case that performs the actions
triggered by the event.

Use Case (Continued)
• Better to create fewer use cases

• 20 use cases for a large system
• 50 use cases would be the maximum
for a large system
• Can nest use cases, if needed

Use Case Relationships
• Communicates
• Connect an actor to a use case
• Includes
• Use case contains a behavior that is
common to more than one use case.
• The common use case is included in other
use cases.
• Dotted arrow points toward common use
case.
(Continued)
• Extends
• A different use case handles variations or
exceptions from the basic use case.
• Arrow goes from extended to basic use
case.
• Generalizes
• One thing is more general than another
thing.
• Arrow points to the general thing.

Steps for Creating a
Use Case Model
The steps required to create a use case
model are:
• Review the business specifications and
identify the actors within the problem
domain.
• Identify the high-level events and develop
the primary use cases that describe the
events and how actors initiate them.

Steps for Creating a
Use Case Model
• The steps required to create a use case

model are (continued):
• Review each primary use case to
determine possible variations of flow
through the use case.
• Develop the use case documents for all
primary use cases and all important use
case scenarios.

Use Case Scenario
• A use case scenario may be created for
the standard flow through the use case.
• Other scenarios may be created for
variations on the main flow.
• A use case includes:
• Use case identifiers and initiators.
• Steps performed.
• Conditions, assumptions, and questions.
Activity Diagrams
• Activity diagrams show the sequence of

activities in a process, including
sequential and parallel activities.
• Symbols are used for activities,
decisions and so on.
• Arrows represent events that connect
the activities.

Activity Diagram Symbols

Creating Activity Diagrams
• Ask what happens first, second, and so

on.
• Determine if the activities happen in
sequence or parallel.
• Examine all the scenarios for a use
case.

Swimlanes
• Included on activity diagrams to show
partitioning
• Show which activities:
• Occur on a browser
• Occur on a server
• Happen on a mainframe
• Are done by external partners
• Help to divide tasks among team members

Swimlane Boundaries
When an event crosses swimlane
boundaries, data must be transmitted.
• A Web form is sent to a server.
• Data are placed into middleware to
transmit it between a server and a
mainframe.
• Data are transmitted to and from an
external partner.

Sequence Diagrams
• Sequence diagrams show a succession
of interactions between classes or
object instances over time.
• It also shows the processing described
in a single scenario.
• The leftmost object is the starting
object.
• Time sequence is from top to bottom.
Sequence Diagrams
(Continued)
• Horizontal arrows represent messages

or signals sent between classes.
• Solid arrowheads represent synchronous
calls, the sending class waits for a
response.
• Half or open arrowheads represent
asynchronous calls, those sent without
waiting for a returning signal.

Message Name Formats
Message names may be in the following
formats:
messageName()
messageName(parameter1, parameter2, …)
messageName(parameterType:parameterName)(defaultValue)

Sequence Diagram Example

Collaboration Diagrams
• Collaboration Diagrams show the same

information as a sequence diagram.
• The emphasis is on the organization of
the objects.
• Sequence is shown by including a
sequence number on the message.

Collaboration Diagram Example

Class Diagrams
• Class diagrams show classes, attributes,

and operations or methods.
• A class is shown as a rectangle.

Class Diagram Attributes
• Attributes are either:

• Private (the norm), indicated by a minus
sign.
• Public, indicated by a plus sign.
• Protected, indicated by a pound sign (#).
• Attributes may include the type of data and
any initial value.
• Methods are usually public.
Method Overloading
• Method overloading is including the

same method several times in a class.
• The method signature, its name and
parameters, and type of parameters,
must be different.

Types of Classes
• Classes fall into several categories:

• Entity classes.
• Boundary or interface classes.
• Abstract classes.
• Control classes.
• Each class may use a special symbol,
called a UML stereotype.

Entity Classes
• Entity classes represent real-world

items.
• Attributes are those stored for the
entity.
• Methods work with the entity.

Boundary or Interface Classes
• Provide a means for users to work with

the system.
• Display screens, windows, dialogue
boxes, touch-tone telephone, external
systems.
• Methods required to send or reset the
display screen, or to produce a report.

Abstract Classes
• Abstract classes are the parent or
general class in a
generalization/specialization
relationship.
• Abstract classes may not be directly
instantiated.
• Only the child classes can create
objects.

Control or Active Classes
• Control or active classes are used to
control the flow of activities.
• Many small control classes may be
included to achieve reuse.
• Attributes are those needed temporarily
by the control class.
• Methods are those used in control
activities .

Sequence Diagram Example Using
Class Stereotype Symbols

Relationships on a Class Diagram
• Relationships are the connections

between classes and include:
• Associations, showing the one-to-many
relationships between classes.
• An asterisk (*) is used to represent many.
• Association classes are used to break up a
many-to-many association between
classes.

Association Class Example

Whole/Part Relationships
• One class represents the whole, other

classes represent the parts contained in
the whole.
• Three types of whole/part relationships:
• Aggregation.
• Collection.
• Composition.

Aggregation
• Aggregation is a “has a” relationship.

• The whole is composed of the sum of
the parts.
• If the whole is removed, the part may
still exist.
• The diamond at the end of the line is
not filled in.

Collection
• Consists of a whole and its members

• Examples are a library with books or a
voting district with voters
• If the part is removed, the whole
retains its identity
• A weak association

Composition
• The whole has a responsibility for the

parts, and is a stronger relationship.
• If the whole is removed, the parts are
removed
• Shown with a filled-in diamond on the
line
• Example: an insurance policy with riders
Whole/Part Example

Generalization/Specialization
Diagrams
• Generalization/specialization or gen/spec diagrams
show the relationship between a more general thing
and a specific kind of thing.
• This relationship is described as an “is a”
relationship.
• For example: a car is a vehicle, a truck is a vehicle.
• Generalization relationship is used to model
inheritance.
• General class is a parent, base, or superclass.
• Specialized class is a child, derived, or subclass.

Polymorphism
• Polymorphism or method overriding is

when a method is defined in several
classes in a gen/spec relationship.
• The subclass overrides the parent class
attributes and/or methods.
• If a number of classes are involved, the
most specific class is used.

Gen/Spec Example

Finding Classes
Classes may be discovered:
• During interviews or JAD sessions.
• During brainstorming sessions.
• By using CRC cards.
• By examining use cases, looking for nouns.
• Each noun may lead to a candidate or potential
class.

Determining Class Methods
Class methods may be determined by:
• Using a CRUD matrix.
• Looking at messages sent between classes.
• The receiving class must have the message
name as a method.
• Using statechart diagrams.

Statechart Diagrams
• Statechart diagrams show class states and
the events that cause them to transition
between states.
• It is also called a state transition diagram
• An event happens at a specific time and
place.
• They cause a change of state, or the
transition “fires”

Statechart Diagrams
(Continued)
• Each time an object changes state,

some of its attributes must change.
• There must be a method to change the
attributes.
• Often there is a display screen or Web
form to enter the attributes.

Statechart Diagrams
(Continued)
• Statechart diagrams are not created for all
classes.
• They are created when:
• A class has a complex life cycle.
• An instance of a class may update its attributes in
a number of ways through the life cycle.
• A class has an operational life cycle.
• Two classes depend on each other.
• The object’s current behavior depends on what
happened previously.

Statechart Example

Packages
• Containers for other UML things

• Show system partitioning
• Indicate which use cases or classes are
grouped into a subsystem
• Can show component packages
• Can be physical subsystems
• Use a folder symbol
Package Example

Steps Used in UML
The steps used in UML are:
• Define the use case model.
• Continue UML diagramming to model the system.
during the systems analysis phase.
• Develop the class diagrams.
• Draw statechart diagrams.
• Begin systems design by refining the UML
diagrams.
• Document your system design in detail.

Object-Oriented Systems Analysis and Design Using UML

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Object-Oriented Systems Analysis and Design Using UML

Uploaded by

Copyright:

Available Formats

Chapter 18

Systems Analysis and Design

• Object-oriented concepts and

• Apa keuntungan membuat program

Kendall & Kendall © 2005 Pearson Prentice Hall 18-3

Kendall & Kendall © 2005 Pearson Prentice Hall 18-4

Kendall & Kendall © 2005 Pearson Prentice Hall 18-5

• Reusability is the main goal.

Kendall & Kendall © 2005 Pearson Prentice Hall 18-6

Kendall & Kendall © 2005 Pearson Prentice Hall 18-7

Kendall & Kendall © 2005 Pearson Prentice Hall 18-8

Kendall & Kendall © 2005 Pearson Prentice Hall 18-9

Kendall & Kendall © 2005 Pearson Prentice Hall 18-10

Kendall & Kendall © 2005 Pearson Prentice Hall 18-11

Kendall & Kendall © 2005 Pearson Prentice Hall 18-12

Kendall & Kendall © 2005 Pearson Prentice Hall 18-13

Kendall & Kendall © 2005 Pearson Prentice Hall 18-15

Kendall & Kendall © 2005 Pearson Prentice Hall 18-16

Kendall & Kendall © 2005 Pearson Prentice Hall 18-17

Kendall & Kendall © 2005 Pearson Prentice Hall 18-18

Kendall & Kendall © 2005 Pearson Prentice Hall 18-19

Kendall & Kendall © 2005 Pearson Prentice Hall 18-20

• Behavioral relationships are:

Kendall & Kendall © 2005 Pearson Prentice Hall 18-21

Kendall & Kendall © 2005 Pearson Prentice Hall 18-22

Kendall & Kendall © 2005 Pearson Prentice Hall 18-23

The most commonly used UML diagrams

Kendall & Kendall © 2005 Pearson Prentice Hall 18-24

The most commonly used UML diagrams

Kendall & Kendall © 2005 Pearson Prentice Hall 18-25

The most commonly used UML diagrams

Kendall & Kendall © 2005 Pearson Prentice Hall 18-26

Kendall & Kendall © 2005 Pearson Prentice Hall 18-27

Kendall & Kendall © 2005 Pearson Prentice Hall 18-28

Kendall & Kendall © 2005 Pearson Prentice Hall 18-29

• Actors may be divided into two groups:

Kendall & Kendall © 2005 Pearson Prentice Hall 18-30

• Consists of three things:

Kendall & Kendall © 2005 Pearson Prentice Hall 18-31

• Better to create fewer use cases

Kendall & Kendall © 2005 Pearson Prentice Hall 18-32

Kendall & Kendall © 2005 Pearson Prentice Hall 18-35

Kendall & Kendall © 2005 Pearson Prentice Hall 18-36

• The steps required to create a use case

Kendall & Kendall © 2005 Pearson Prentice Hall 18-37

• Activity diagrams show the sequence of

Kendall & Kendall © 2005 Pearson Prentice Hall 18-39

Kendall & Kendall © 2005 Pearson Prentice Hall 18-40

• Ask what happens first, second, and so

Kendall & Kendall © 2005 Pearson Prentice Hall 18-41

Kendall & Kendall © 2005 Pearson Prentice Hall 18-42

Kendall & Kendall © 2005 Pearson Prentice Hall 18-43

• Horizontal arrows represent messages

Kendall & Kendall © 2005 Pearson Prentice Hall 18-45

Kendall & Kendall © 2005 Pearson Prentice Hall 18-46

Kendall & Kendall © 2005 Pearson Prentice Hall 18-47

• Collaboration Diagrams show the same

Kendall & Kendall © 2005 Pearson Prentice Hall 18-48

Kendall & Kendall © 2005 Pearson Prentice Hall 18-49

• Class diagrams show classes, attributes,

Kendall & Kendall © 2005 Pearson Prentice Hall 18-50

• Attributes are either:

• Method overloading is including the