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
12/1/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.

12/1/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.

12/1/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.
12/1/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.

12/1/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)

12/1/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 ☺

association

getAccountWithID
Jukebox JukeboxAccountCollection
1 1

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?
Stores
AccountCollection Account
1 0..*

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..52
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

12/1/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.

12/1/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.

12/1/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.

12/1/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.

12/1/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
12/1/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
12/1/2021 26
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
objects

ti
m
e
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 of control 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.

Figure: Branching
 # 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, i.e,
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 (UCD)

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

12/1/2021 59
The importance of focusing on users/
Benefits of UCD
• 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

12/1/2021 60
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

12/1/2021 61
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.

12/1/2021 62
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.

12/1/2021 63
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.

12/1/2021 64
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.

12/1/2021 65
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.
12/1/2021 66
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.

12/1/2021 67
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.

12/1/2021 68
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.

12/1/2021 69
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.

12/1/2021 70
Usability Principles

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

12/1/2021 71
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

12/1/2021 72
Example
(bad UI)

12/1/2021 73
Example
(better UI)

12/1/2021 74
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.

12/1/2021 75
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.

12/1/2021 76