UNIT 3

Unified Modeling Language & Use Case Modeling

Unified Modeling Language & Use Case Modeling
Contents
Introduction to UML
Modeling Concepts
Types of UML Diagrams with Examples
User-Centered Design
Characteristics of Users
Developing Use - Case Models of Systems
Use-Case Diagram
Use- Case Descriptions
Basics of User Interface Design
Usability Principles
User Interfaces
8/24/2021 2
Introduction to UML
Unified Modeling Language (UML) is a standard for
writing software blue prints.
UML is a language for
# Visualizing
# Specifying
# Constructing
# Documenting
UML is a Language
-A language provides a vocabulary and the rules for combining words
in that vocabulary for the purpose of communication.
-A modeling language is a language whose vocabulary and rules
focus on the conceptual and physical representation of a system.
-A modeling language such as the UML is thus a standard language for
software blueprints.

8/24/2021 3
# The UML Is a Language for Visualizing
-Modeling is often thought to be done mentally, or by just sketching out
a few ideas on a white board.
-However, there are several problems with this.
First, communicating those conceptual models to others is
error-prone unless everyone involved speaks the same language.
Second, there are some things about a software system you
can't understand unless you build models that transcend the textual
programming language.
Third, if the developer who cut the code never wrote down the
models that are in his or her head, that information would be lost
forever or, at best, only partially recreatable from the implementation,
once that developer moved on.
Writing models in the UML addresses these issues.

8/24/2021 4
# The UML Is a Language for Specifying
-Specifying means building models that are precise,
unambiguous, and complete.
-The UML addresses the specification of all the important
analysis, design, and implementation decisions that must
be made in developing and deploying a software-intensive
system.
# The UML Is a Language for Constructing
-The UML is not a visual programming language, but its
models can be directly connected to a variety of
programming languages.
-It is possible to map from a model in the UML to a
programming language such as Java, C++, or Visual Basic,
or even to tables in a relational database or the persistent
store of an object-oriented database.
8/24/2021 5
# The UML Is a Language for Documenting
A healthy software organization produces all sorts of artifacts in
addition to raw executable code. These artifacts include (but are not
limited to)
• Requirements
• Architecture
• Design
• Source code
• Project plans
• Tests
• Prototypes
• Releases
The UML addresses the documentation of a system's architecture and
all of its details. It also provides a language for expressing
requirements and for tests. Finally, the UML provides a language for
modeling the activities of project planning and release management.

8/24/2021 6
Modeling Concepts
- To understand the UML, we need to form a conceptual model of the
language, and this requires learning three major elements: the UML's
basic building blocks, the rules that dictate how those building blocks
may be put together, and some common mechanisms that apply
throughout the UML.
Building Blocks of the UML
The vocabulary of the UML encompasses three kinds of building blocks:
1. Things
2. Relationships
3. Diagrams

(Note: Please refer to the hand written notes shared in the class)

8/24/2021 7
 Building Blocks of the UML
UML Category UML Elements UML Elements
Things Structural Things Classes
Interfaces
Collaborations
Use Cases
Active Classes
Components
Nodes

Behavioral Things Interactions

State Machines
Grouping Things Packages
Annotational Things Notes
Relationships Structural Relationships Dependencies
Aggregations
Associations
Generalizations

Behavioral Relationships Communicates

Includes
Extends
Generalizes
Diagrams Structural Diagrams Class Diagrams
Component Diagrams
Deployment Diagrams
Behavioral Diagrams Use Case Diagrams
Sequence Diagrams
Communication Diagrams
Statechart Diagrams 8
Activity Diagrams
Relationships

Three Relationships in UML

# Dependency
# Association
# Generalization

6-9 9
Dependency: A Uses Relationship
# Dependencies
-occurs when one object depends on another
- if you change one object's interface, you need to
change the dependent object
- arrows point from dependent to needed objects

CardReader
Jukebox
CDCollection

SongSelector
6-10 10
Association: Structural Relationship
# Association
- a relationship between classes indicates some
meaningful or interesting connection
-Associations can be labeled getAccountWithID for example
- BTW: The box with association is an official UML comment, must have that fold ☺

associatio
n

getAccountWithI
Jukebo D JukeboxAccountCollectio
1 1
x n

6-11 11
Associations

# Associations imply
-our knowledge that a relationship must be
preserved for some time (0.01 ms to forever)
♦ Between what objects do we need to remember a
relationship?
• Does a Transaction need to remember Account?
• Would AccountCollection need to remember
Accounts?
Store
AccountCollection Accoun
1 s 0..* t

6-12 12
Notation and Multiplicity Adornments
♦ UML Association:
− a line between two concepts and a name
− they are bi-directional * T
zero or more;
"many"
− can have a multiplicity
− exist in class diagrams 1. *
.
T one or
more

1..5
2 T one to fifty
two

5
Multiplicity T exactly
five
adornments
6-13 13
Association
Names • Read these Type-VerbPhrase-Type
• POST is a Point of Sale Terminal)
• Not shown here: Attributes and Methods
• This just shows associations between objects

6-14 14
Aggregation: A Special Association

♦ Aggregation: whole/part relationships

− An association that models HAS-A relationships
− The objects can exist independently of each other
− No one object is more important than the other
− Place an open diamond on the whole
− School contains a collection of Student objects
School Student
1..* *

− In Java, this is the same as an association, an

instance variable, no special syntax
6-15 15
Composition: A Special Association

♦ Composition: Stronger relationship

− One can not exist without the other
− If the school folds, students live on
♦ but the departments go away with the school
− If a department closes, the school can go on AIC* e.g.
School Department
1 1..*
1..*

*
Student

6-16 16
Types of UML Diagrams

-A diagram is the graphical presentation of a set of elements, most

often rendered as a connected graph of vertices (things) and arcs
(relationships)
The UML includes nine such diagrams:
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. Statechart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram

8/24/2021 17
Class Diagram shows a set of classes, interfaces, and
collaborations and their relationships. These diagrams are
the most common diagram found in modeling object-
oriented systems.
Class diagrams address the static design view of a system.
Object Diagrams shows a set of objects and their
relationships.
These diagrams represent static snapshots of instances of
the things found in class diagrams.
Use case Diagram shows a set of use cases and actors (a
special kind of class) and their relationships. Use case
diagrams address the static use case view of a system.
These diagrams are especially important in organizing and
modeling the behaviors of a system.

8/24/2021 18
Interaction diagrams
Both sequence diagrams and collaboration diagrams are
kinds of interaction diagrams.
An interaction diagram shows an interaction, consisting
of a set of objects and their relationships, including the
messages that may be dispatched among them.
Interaction diagrams address the dynamic view of a system.
A sequence diagram is an interaction diagram that
emphasizes the time-ordering of messages
Collaboration diagram is an interaction diagram that
emphasizes the structural organization of the objects that
send and receive messages.
** Sequence diagrams and collaboration diagrams are
isomorphic, meaning that you can take one and transform it
into the other.

8/24/2021 19
State chart diagram shows a state machine, consisting of
states, transitions, events, and activities.
-State chart diagrams address the dynamic view of a system.
They are especially important in modeling the behavior of
an interface, class, or collaboration and emphasize the
event-ordered behavior of an object, which is especially
useful in modeling reactive systems.
An Activity diagram is a special kind of a statechart
diagram that shows the flow from activity to activity within
a system.
-Activity diagrams address the dynamic view of a system.
They are especially important in modeling the function of a
system and emphasize the flow of control among objects.

8/24/2021 20
Component diagram shows the organizations and
dependencies among a set of components.
Component diagrams address the static implementation
view of a system. They are related to class diagrams in that
a component typically maps to one or more classes,
interfaces, or collaborations.
Deployment diagram shows the configuration of run-time
processing nodes and the components that live on them.
Deployment diagrams address the static deployment view
of an architecture. They are related to component diagrams
in that a node typically encloses one or more components.

8/24/2021 21
 Types of UML Diagrams with Examples
A diagram is the graphical presentation of a set of elements,
most often rendered as a connected graph of vertices (things) and
arcs (relationships)
The UML includes nine such diagrams:
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. State chart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram
8/24/2021 22
 Class Diagram
• A class diagram shows a set of classes, interfaces, and
collaborations and their relationships.
• Class diagrams are used to model the static design view of a
system.
• For the most part, this involves modeling the vocabulary of the
system, modeling collaborations, or modeling schemas.
• Class diagrams are also the foundation for a couple of related
diagrams: Component diagrams and Deployment diagrams.
# Contents of Class Diagrams
Class diagrams commonly contain the following things:
— Classes
— Interfaces
— Collaborations
— Dependency, generalization, and association relationships
Class Diagrams are generally used to
• To model the vocabulary of a system
• To model simple collaborations
• To model a logical database schema
Class Diagram
Modeling a Schema
Use Case Diagram
A use case diagram is a diagram that shows a set of use cases
and actors and their relationships.
Use case diagrams are one of the five diagrams in the UML for
modeling the dynamic aspects of systems (activity diagrams,
statechart diagrams, sequence diagrams, and collaboration
diagrams are four other kinds of diagrams in the UML for
modeling the dynamic aspects of systems).
Use case diagrams are central to modeling the behavior of a
system, a subsystem, or a class. Each one shows a set of use
cases and actors and their relationships.
# Contents of Use case Diagrams
Use case diagrams commonly contain
— Use cases
— Actors
— Dependency, generalization, and association relationships
Use case Diagrams are generally used to
-To model the context of a system
- To model the requirements of a system
Use Case Diagram
Modeling Context of a System
Figure shows the context of a credit card validation system, with
an emphasis on the actors that surround the system.
Customers here are of two kinds (Individual customer and
Corporate customer).
These actors are the roles that humans play when interacting
with the system.
In this context, there are also actors that represent other
institutions, such as
- Retail institution (with which a Customer performs a card
transaction to buy an item or a service) and
- Sponsoring financial institution (which serves as the
clearinghouse for the credit card account). In the real world,
these latter two actors are likely software-intensive systems
themselves.
Modeling the Requirements of a System
Object Diagram
Object diagrams model the instances of things contained in
class diagrams.
An object diagram shows a set of objects and their
relationships at a point in time.
Object diagrams are used to model the static design view or
static process view of a system. This involves modeling a
snapshot of the system at a moment in time and rendering a set
of objects, their state, and their relationships.
# Contents of Object Diagrams
Object diagrams commonly contain
— Objects
— Links
#Object Diagrams are generally used to
— To model object structures
Object Diagram
 Interaction Diagram
Sequence diagram & Collaboration diagram
Sequence diagrams and collaboration diagrams together are called
interaction diagrams
They are used for modeling the dynamic aspects of systems.
An interaction diagram shows an interaction, consisting of a set of
objects and their relationships, including the messages that may be
dispatched among them.
Interaction diagrams commonly contain
• Objects
• Links
• Messages
A sequence diagram is an interaction diagram that emphasizes the
time ordering of messages
A collaboration diagram is an interaction diagram that emphasizes the
structural organization of the objects that send and receive messages.
Sequence Diagram
Sequence diagrams have two features that distinguish them from
collaboration diagrams.
First, there is the object lifeline. An object lifeline is the vertical
dashed line that represents the existence of an object over a
period of time. Most objects that appear in an interaction
diagram will be in existence for the duration of the interaction,
so these objects are all aligned at the top of the diagram, with
their lifelines drawn from the top of the diagram to the bottom.
Second, there is the focus of control. The focus of control is a
tall, thin rectangle that shows the period of time during which an
object is performing an action, either directly or through a
subordinate procedure. The top of the rectangle is aligned with
the start of the action; the bottom is aligned with its completion
(and can be marked by a return message).
Collaboration Diagram
Collaboration diagrams have two features that
distinguish them from sequence diagrams.
First, there is the path, to indicate how one object
is linked to another
Second, there is the sequence number, to indicate
the time order of a message.
The message is prefixed with a number (starting with
the message numbered 1), increasing monotonically for
each new message in the flow of control (2, 3, and so
on).
Sequence diagrams and collaboration diagrams are
semantically equivalent.
Statechart Diagram
Statechart diagram shows flow of control from state to state.
Statechart diagrams are one of the five diagrams in the UML for
modeling the dynamic aspects of systems.
A statechart diagram shows a state machine.
Statechart diagrams are not only important for modeling the
dynamic aspects of a system, but also for constructing executable
systems through forward and reverse engineering.
Statechart Diagram
# Contents of Statechart Diagram
Statechart diagrams commonly contain
• Simple states and composite states
• Transitions, including events and actions
# Statechart diagrams are generally used
To model a reactive object,
 Activity Diagram
-Activity diagrams are used to model the dynamic aspects of a system.
Graphically, an activity diagram is a collection of vertices and arcs.
- An activity diagram shows the flow from activity to activity. An is an
ongoing nonatomic execution within a state machine.
- Activities ultimately result in some action, which is made up of
executable atomic computations that result in a change in state of the
system or the return of a value.
- Actions encompass calling another operation, sending a signal,
creating or destroying an object, or some pure computation, such as
evaluating an expression.
- Activity diagrams may stand alone to visualize, specify, construct,
and document the dynamics of a society of objects, or they may be
used to model the flow of control of an operation.
Activity Diagram
# Contents of Activity Diagram
Activity diagrams commonly contain
• Activity states and action states
• Transitions
• Objects
# Action States and Activity States
Executable, atomic computations are called Action States
because they are states of the
system, each representing the
execution of an action

Figure shows representation of an action state using a

lozenge shape (a symbol with horizontal top and bottom and
convex sides).
Action states can't be decomposed. Furthermore, action states
are atomic, meaning that events may occur, but the work of the
action state is not interrupted.
 Activity states are not atomic, meaning that they may be
interrupted and, in general, are considered to take some duration
to complete.
Activity states can be further decomposed.

Figure above shows that there's no notational distinction

between action and activity states, except that an activity state
may have additional parts, such as entry and exit actions (actions
which are involved on entering and leaving the state,
respectively) and submachine specifications.
# Transitions
A transition is a relationship between two states indicating that
an object in the first state will perform certain actions and enter
the second state when a specified event occurs and specified
conditions are satisfied.
# Branching
Branches are a notational convenience, semantically equivalent
to multiple transitions with guards.
 # Forking and Joining
A fork represents the splitting of a single flow of control into two or more
concurrent flows of control. A fork may have one incoming transition and two
or more outgoing transitions, each of which represents an independent flow of
control.
A join represents the synchronization of two or more concurrent flows of
control. A join may have two or more incoming transitions and one outgoing
transition. Above the join, the activities associated
with each of these paths continues in
parallel.
Joins and forks should balance, meaning
that the number of flows that leave a
fork should match the number of flows
that enter its corresponding join.
# Swimlanes
At times we find it useful, to partition the activity states on an activity
diagram into groups, each
group representing the business
organization responsible for
those activities. Each such group
is called a swimlane because,
visually, each group is divided
from its neighbor by a vertical
solid line, as shown in Figure.
A swimlane specifies a locus of
activities.
Acitivity diagrams are used
To model a workflow
To model an operation
Component Diagram
A component diagram shows a set of components and their
relationships. Graphically, a component diagram is a collection
of vertices and arcs.
Component diagrams are one of the two kinds of diagrams found
in modeling the physical aspects of object-oriented systems. A
component diagram shows the organization and dependencies
among a set of components.
We use component diagrams to model the static implementation
view of a system.
Component Diagram
# Contents of Component Diagram
Component diagrams commonly contain
· Components
· Interfaces
· Dependency, generalization, association, and realization
relationships
# Common Uses of Component Diagram
- To model source code
- To model executable releases
- To model physical databases
- To model physical databases
Deployment diagram
A deployment diagram is a diagram that shows the configuration
of run time processing nodes and the components that live on
them. Graphically, a deployment diagram is a collection of
vertices and arcs.
Deployment diagrams are one of the two kinds of diagrams used
in modeling the physical aspects of an object-oriented system.
# Contents of Deployment diagrams
Deployment diagrams commonly contain
· Nodes
· Dependency and association relationships
Deployment diagram
 # Common Uses of Deployment Diagrams
Deployment diagrams are used in one of three ways.
1. To model embedded systems
2. To model client/server systems
3. To model fully distributed systems

The above slides have clearly explained all UML diagrams with
suitable examples.
User Centred Design

Software development should focus on the needs of users

• Understand your users
• Design software based on an understanding of the users’
tasks
• Ensure users are involved in decision making processes
• Design the user interface following guidelines for good
usability
• Have users work with and give their feedback about
prototypes, on-line help and draft user manuals

8/24/2021 58
The importance of focusing on users

• Reduced training and support costs

• Reduced time to learn the system
• Greater efficiency of use
• Reduced costs by only developing features that are
needed
• Reduced costs associated with changing the system later
• Better prioritizing of work for iterative development
• Greater attractiveness of the system, so users will be
more willing to buy and use it

8/24/2021 59
Characteristics of Users

Software engineers must develop an understanding of

the users
• Goals for using the system
• Potential patterns of use
• Demographics
• Knowledge of the domain and of computers
• Physical ability
• Psychological traits and emotional feelings

8/24/2021 60
Basics of User Interface Design

• User interface design should be done in conjunction

with other software engineering activities.

• Do use case analysis to help define the tasks that the UI

must help the user perform.

• Do iterative UI prototyping to address the use cases.

• Results of prototyping will enable you to finalize the

requirements.

8/24/2021 61
Usability vs. Utility

Does the system provide the raw capabilities to allow the

user to achieve their goal?
• This is utility.

Does the system allow the user to learn and to use the
raw capabilities easily?
• This is usability.

Both utility and usability are essential

• They must be measured in the context of particular
types of users.

8/24/2021 62
Aspects of usability

Usability can be divided into separate aspects:

• Learnability
— The speed with which a new user can become
proficient with the system.
• Efficiency of use
— How fast an expert user can do their work.
• Error handling
— The extent to which it prevents the user from making
errors, detects errors, and helps to correct errors.
• Acceptability.
— The extent to which users like the system.

8/24/2021 63
Some basic terminology of user interface
design
• Dialog: A specific window with which a user can interact, but
which is not the main UI window.
• Control or Widget: Specific components of a user interface.
• Affordance: The set of operations that the user can do at any given
point in time.
• State: At any stage in the dialog, the system is displaying certain
information in certain widgets, and has a certain affordance.
• Mode: A situation in which the UI restricts what the user can do.
• Modal dialog: A dialog in which the system is in a very restrictive
mode.
• Feedback: The response from the system whenever the user does
something, is called feedback.
• Encoding techniques. Ways of encoding information so as to
communicate it to the user.

8/24/2021 64
Usability Principles
1. Do not rely only on usability guidelines – always test
with users.
• Usability guidelines have exceptions; you can only be
confident that a UI is good if you test it successfully
with users.
2: Base UI designs on users’ tasks.
• Perform use case analysis to structure the UI.
3: Ensure that the sequences of actions to achieve a task
are as simple as possible.
• Reduce the amount of reading and manipulation the user
has to do.
• Ensure the user does not have to navigate anywhere to
do subsequent steps of a task.
8/24/2021 65
Usability Principles

4: Ensure that the user always knows what he or she

can and should do next.
• Ensure that the user can see what commands are
available and are not available.
• Make the most important commands stand out.
5: Provide good feedback including effective error
messages.
• Inform users of the progress of operations and of their
location as they navigate.
• When something goes wrong explain the situation in
adequate detail and help the user to resolve the problem.

8/24/2021 66
Usability Principles

6: Ensure that the user can always get out, go back or

undo an action.
• Ensure that all operations can be undone.
• Ensure it is easy to navigate back to where the user
came from.
7: Ensure that response time is adequate.
• Users are very sensitive to slow response time
— They compare your system to others.
• Keep response time less than a second for most
operations.
• Warn users of longer delays and inform them of
progress.

8/24/2021 67
Usability Principles

8: Use understandable encoding techniques.

• Choose encoding techniques with care.
• Use labels to ensure all encoding techniques are fully
understood by users.
9: Ensure that the UI’s appearance is uncluttered.
• Avoid displaying too much information.
• Organize the information effectively.

8/24/2021 68
Usability Principles

10: Consider the needs of different groups of users.

• Accommodate people from different locales and people
with disabilities.
• Ensure that the system is usable by both beginners and
experts.
11: Provide all necessary help.
• Organize help well.
• Integrate help with the application.
• Ensure that the help is accurate.

8/24/2021 69
Usability Principles

12. Be consistent.
• Use similar layouts and graphic designs throughout your
application.
• Follow look-and-feel standards.
• Consider mimicking other applications.

8/24/2021 70
Some encoding techniques

• Text and fonts

• Icons
• Photographs
• Diagrams and abstract graphics
• Colours
• Grouping and bordering
• Spoken words
• Music
• Other sounds
• Animations and video
• Flashing

8/24/2021 71
Example
(bad UI)

8/24/2021 72
Example
(better UI)

8/24/2021 73
Difficulties and Risks in UI Design

• Users differ widely

— Account for differences among users when you
design the system.
— Design it for internationalization.
— When you perform usability studies, try the system
with many different types of users.
• User interface implementation technology changes
rapidly
— Stick to simpler UI frameworks widely used by
others.
— Avoid fancy and unusual UI designs involving
specialized controls that will be hard to change.

8/24/2021 74
Difficulties and Risks in UI Design

• User interface design and implementation can often

take the majority of work in an application:
— Make UI design an integral part of the software
engineering process.
— Allocate time for many iterations of prototyping and
evaluation.
• Developers often underestimate the weaknesses of a
GUI
— Ensure all software engineers have training in UI
development.
— Always test with users.
— Study the UIs of other software.

8/24/2021 75