Basic Structural Modeling: Classes, Relationships, common Mechanisms, and diagrams.

(notes
in unit 1)

Class &Object Diagrams: Terms, concepts, modelling

techniques for Class & Object Diagrams.

Class diagram for hospital management system

Left side Class Diagram and Right side Object Diagram
UML Class Notation
 Classes are depicted as rectangle boxes, each containing three compartments for the
class name, attributes, and methods. You can draw a link while using the lines utilized in
class diagrams.

 Visibility notations indicate the access level of attributes and methods. Common
visibility notations include:

 + for public (visible to all classes)

 - for private (visible only within the class)

 # for protected (visible to subclasses)

 ~ for package or default visibility (visible to classes in the same package)

Basic Object Diagram Symbols and Notations
Object Names:
Every object is actually symbolized like a rectangle, that offers the name from the object and its
class underlined as well as divided with a colon.

Object Attributes:
 Similar to classes, you are able to list object attributes inside a separate compartment.
However, unlike classes, object attributes should have values assigned for them.

Links:
 Links tend to be instances associated with associations. You can draw a link while using
the lines utilized in class diagrams.

Theory of Class and Object Diagram

Class Diagram vs. Object Diagram

In UML, object diagrams provide a snapshot of the instances in a system and the
relationships between the instances. By instantiating the model elements in a class diagram,
you can explore the behavior of a system at a point in time.

Classes are the most important building block of any object-oriented system. A class is a
description of a set of objects that share the same attributes, operations, relationships, and
semantics. A class implements one or more interfaces.

You can use classes to represent software things, hardware things, and even things that are
purely conceptual.

Class Diagrams:

TERMS AND CONCEPTS

A class diagram is a diagram that shows a set of classes, interfaces, and collaborations

and their relationships. Graphically, a class diagram is a collection of vertices and arcs.

Common Properties:

A class diagram is just a special kind of diagram and shares the same common properties

as do all other diagrams name and graphical content that are a projection into a model.
What distinguishes a class diagram from other kinds of diagrams is its particular content.

Contents:

Class diagrams commonly contain the following things:

• Classes

• Interfaces

• Collaborations

• Dependency, generalization, and association relationships. Like all other diagrams, class

diagrams may contain notes and constraints.

Common Uses :

You use class diagrams to model the static design view of a system. This view primarily

supports the functional requirements of a system the services the system should provide to
its end users.
COMMON MODELING TECHNIQUES

1.Modeling Simple Collaborations

To model a collaboration,

• Identify the mechanism you'd like to model. A mechanism represents some function or

behavior of the part of the system you are modeling that results from the interaction of a
society of classes, interfaces, and other things.

• For each mechanism, identify the classes, interfaces, and other collaborations that
participate in this collaboration. Identify the relationships among these things as well.

2. Modeling a Logical Database Schema

To model a schema,

• Identify those classes in your model whose state must transcend the lifetime of their

applications.

• Create a class diagram that contains these classes. You can define your own set of
stereotypes and tagged values to address database-specific details.

• Expand the structural details of these classes. In general, this means specifying the details
of their attributes and focusing on the associations and their multiplicities that relate these
classes.

Q What is Object and Object Diagrams:

An object represents a concrete instance of a class at a specific point in time within a

system. While a class acts as a blueprint defining common attributes and behaviors, an
object is a tangible realization of that blueprint, possessing unique values for its attributes.

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.

TERMS AND CONCEPTS: An object diagram is a diagram that shows a set of objects and
their relationships at a point in time. Graphically, an object diagram is a collection of vertices
and arcs.

Common Properties: An object diagram is a special kind of diagram and shares the same
common properties as all other diagrams that is, a name and graphical contents that are a
projection into a model.
Contents

Object diagrams commonly contain

•Objects

•Links

Like all other diagrams, object diagrams may contain notes and constraints.

Sometimes you'll want to place classes in your object diagrams as well, especially when you

want to visualize the classes behind each instance.

Common Uses

You use object diagrams to model the static design view or static process view of a

system just as you do with class diagrams, but from the perspective of real or prototypical

instances. This view primarily supports the functional requirements of a system that is, the

services the system should provide to its end users. Object diagrams let you model static
data structures.

COMMON MODELING TECHNIQUES

Modeling Object Structures

•Identify the mechanism you'd like to model. A mechanism represents some function or
behavior of the part of the system you are modeling that results from the interaction of a
society of classes,interfaces, and other things.

• Create a collaboration to describe a mechanism.

• For each mechanism, identify the classes, interfaces, and other elements that participate
in this collaboration; identify the relationships among these things as well.

•Consider one scenario that walks through this mechanism. Freeze that scenario at a
moment in time, and render each object that participates in the mechanism.

•Expose the state and attribute values of each such object, as necessary, to understand the

scenario.

•Similarly, expose the links among these objects, representing instances of associations
among them.
Basic Behavioral Modeling: Use cases, Use case
Diagrams,
Use case
Use cases capture important things about a system by describing the
interactions between users (actors) and the system to achieve specific goals,
which defines system requirements, functionality, and scope. They clarify what
the system does for end-users, serve as a common communication tool for
stakeholders, and facilitate project planning

What is a Use Case Diagram in UML?

(A use case diagram is a diagram that shows a set of use cases and actors and their
relationships.)

A Use Case Diagram is a type of Unified Modeling Language (UML) diagram that represents the
interaction between actors (users or external systems) and a system under consideration to
accomplish specific goals. It provides a high-level view of the system's functionality by
illustrating the various ways users can interact with it.

Use case Notation:-

Use Case Diagram Relationships

1. Association Relationship
TheAssociation Relationship represents a communication or interaction between an actor and a
use case. It is depicted by a line connecting the actor to the use case. This relationship signifies
that the actor is involved in the functionality described by the use case.

2. To represent complex relationships between different use cases, we can use the extend and
include relationships.
 Extend relationship: The use case is optional and comes after the base use case. It is
represented by a dashed arrow in the direction of the base use case with the notation
<<extend>>.

 Include relationship: The use case is mandatory and part of the base use case. It is
represented by a dashed arrow in the direction of the included use case with the
notation <<include>>.

Terms and Concepts

Name:-
Every use case must have a name that distinguishes it from other use cases. A name is a textual
string. That name alone is known as a simple name; a path name is the use case name prefixed
by the name of the package in which that use case lives.

Use Cases and Actors

A use case involves the interaction of actors and the system. An actor represents a coherent set
of roles that users of use cases play when interacting with these use cases. Actors can be human
or they can be automated systems. For example, in modeling a bank, processing a loan involves,
among other things, the interaction between a customer and a loan officer
Use Cases and Flow of Events
A use case describes what a system (or a subsystem, class, or interface) does but it does not
specify how it does it. When you model, it's important that you keep clear the separation of
concerns between this outside and inside view.
How Use Cases Are Used : System Analysis: Business analysts use them to understand user
needs and organize system requirements.
 Software Development: They guide the entire software development lifecycle, from
planning and design to testing and documentation.
  User Documentation: They can form the basis for user manuals and online help content.

Use case diagram for ATM system

Basic Behavioral Modeling (Activity Diagrams)
Notation for Activity diagram

Symbol Name Description

Represents the beginning of a process or workflow in

Start symbol an activity diagram. It can be used by itself or with a
note symbol that explains the starting point.

Indicates the activities that make up a modeled

process. These symbols, which include short descrip-
Activity symbol
tions within the shape, are the main building blocks of
an activity diagram.

Shows the directional flow, or control flow, of the ac-

Connector sym- tivity. An incoming arrow starts a step of an activity;
bol once the step is completed, the flow continues with
the outgoing arrow.

Combines two concurrent activities and re-introduces

Joint symbol/
them to a flow where only one activity occurs at a
Synchronization
time. Represented with a thick vertical or horizontal
bar
line.

Splits a single activity flow into two concurrent activi-

Fork symbol ties. Symbolized with multiple arrowed lines from a
join.

Represents a decision and always has at least two

paths branching out with condition text to allow users
Decision symbol to view options. This symbol represents the branching
or merging of various flows with the symbol acting as
a frame or container.

Allows the diagram creators or collaborators to com-

municate additional messages that don't fit within the
Note symbol diagram itself. Leave notes for added clarity and
specification.
Symbol Name Description

Send signal Indicates that a signal is being sent to a receiving ac-

symbol tivity.

Demonstrates the acceptance of an event. After the

Receive signal
event is received, the flow that comes from this ac-
symbol
tion is completed.

Represents the end of a specific process flow. This

symbol shouldn’t represent the end of all flows in an
Flow final sym-
activity; in that instance, you would use the end sym-
bol
bol. The flow final symbol should be placed at the end
of a process in a single activity flow.

Marks the end state of an activity and represents the

End symbol
completion of all flows of a process.

Activity diagrams help people on the business and

development sides of an organization come together to
understand the same process and behavior.
Benefits of activity diagrams
Activity diagrams present a number of benefits to users. Consider creating
an activity diagram to:
 Demonstrate the logic of an algorithm.
 Describe the steps performed in a UML use case.
 Illustrate a business process or workflow between users and the system.
 Simplify and improve any process by clarifying complicated use cases.
 Model software architecture elements, such as method, function, and
operation.

Activity Diagrams
Terms and Concepts An activity diagram shows the flow from activity to activity. An is an
ongoing nonatomic execution within a state machine.
Contents
Activity diagrams commonly contain
· Activity states and action states
· Transitions
· Objects
Action States and Activity States In the flow of control modeled by an activity
diagram, things happen. You might evaluate some expression that sets the value of an attribute
or that returns some value. Alternately, you might call an operation on an object, send a signal
to an object, or even create or destroy an object.These executable, atomic computations are
called action states because they are states of the system, each representing the execution of an
action.

Swimlanes You'll find it useful, especially when you are modeling workflows of business
processes, to partition the activity states on an activity diagram into groups, each group
representing the business organization responsible for those activities. In the UML, each 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.

Figure : Swimlanes
 object
flow
Object Flow
 object flow indicates the participation of an object in a flow of control, it is represented with the help of dependency re-
lationships.

Basic Behavioral Modeling (State Machine or state

chart or state diagram) State diagrams, also known as state machines or finite
state machines, are a visual representation of how a system or process
behaves over time. They consist of a set of states, transitions between
states, and events that trigger those transitions.

A state machine diagram models the behavior of a single object, specifying the sequence of events that
an object goes through during its lifetime in response to events.

As an example, the following state machine diagram shows the states that a door goes through during its
lifetime.

The door can be in one of three states: "Opened", "Closed" or "Locked". It can respond to the events
Open, Close, Lock and Unlock. Notice that not all events are valid in all states; for example, if a door is
opened, you cannot lock it until you close it. Also notice that a state transition can have a guard condition
attached: if the door is Opened, it can only respond to the Close event if the condition doorWay->isEmpty
is fulfilled. The syntax and conventions used in state machine diagrams will be discussed in full in the fol-
lowing sections.

1. Initial state
We use a black filled circle represent the initial state of a System or a Class.

2. Final State
We use a filled circle within a circle notation to represent the final state in a
state machine diagram.
3. Fork
We use a rounded solid rectangular bar to represent a Fork notation with in-
coming arrow from the parent state and outgoing arrows towards the newly
created states. We use the fork notation to represent a state splitting into two
or more concurrent states.
4. Join
We use a rounded solid rectangular bar to represent a Join notation with in -
coming arrows from the joining states and outgoing arrow towards the com-
mon goal state. We use the join notation when two or more states concur-
rently converge into one on the occurrence of an event or events
5. States
A state is denoted by a round-cornered rectangle with the name of the state written
inside it.

6. Transitions

Transitions from one state to the next are denoted by lines with arrowheads. A transition may have a trig-
ger, a guard and an effect, as below.

7. Self-Transitions

A state can have a transition that returns to itself, as in the following diagram. This is
most useful when an effect is associated with the transition.
8. Compound States

A state machine diagram may include sub-machine diagrams, as in the example below.

In UML, each thing that happens is modeled as an event. An event is the specifica-
tion of a significant occurrence that has a location in time and space. A signal, passing
of time and change in state are asynchronous events. Calls are generally synchronous
events, representing invocation of an operation.
UML allows us to represent events graphically as shown below. Signals may be represented as
stereotyped classes and other events are represented as messages associated with transitions which
cause an object to move from one state to another.

Event and signals

Types of Events
Events may be external or internal and asynchronous or synchronous.
Asynchronous events are events that can happen at arbitrary times eg:- signal, the passing of
time, and a change of state.
Synchronous events, represents the invocation of an operation eg:- Calls
External events are those that pass between the system and its actors.
Internal events are those that pass among the objects that live inside the system

In UML, we can model four kinds of events namely: signals, calls, passing of time and
change in state.

Signals: A signal is a named object that is sent asynchronously by one object

and then received by another. Exceptions are the famous examples for signals. A signal
may be sent as the action of a state in a state machine or as a message in an interac-
tion. The execution of an operation can also send signals.
In UML, we model the relationship between an operation and the events using a depen-
dency stereotyped with “send”, which indicates that an operation sends a particular sig-
nal.
Call Events:A call event represents the dispatch of an operation from one object to another. A
call event may trigger a state change in a state machine. A call event, in general, is synchronous. This
means that the sender object must wait until it gets an acknowledgment from the receiver object which
receives the call event. For example, consider the states of a customer in an ATM application:

Time and Change Events

A time event represents the passage of time. In UML, we model the time event using the “after” keyword
followed by an expression that evaluates a period of time.
A change event represents an event that represents a change in state or the satisfaction of some condi-
tion. In UML, change event is modeled using the keyword “when” followed by some Boolean expression.
Applications of State Machine Diagram
Below are the main use cases of state machine diagram:
 State Machine Diagrams are very useful for modeling and visualizing the
dynamic behavior of a system.
 They are also used in UI design where they help to illustrate how the in-
terface changes in response to user actions, helping designers to create a
better use experience.
 In game design, state machine diagrams can help model the behavior of
characters or objects, detailing how they change states based on player
interactions or game events
 In embedded systems, where hardware interacts with software to perform
tasks, State Machine Diagrams are valuable for representing the control
logic and behavior of the system.
 (this is just
forunderstanding)

State machine or state chart or state diagram for vending machine

Process and thread Processes and Threads
 A process is a heavyweight flow that can execute concurrently with other processes.

 A thread is a lightweight flow that can execute concurrently with other threads within the
same process.

 An active object is an object that owns a process or thread and can initiate control activity.

 An active class is a class whose instances are active objects.

 Graphically, an active class is rendered as a rectangle with thick lines. Processes and threads
are rendered as stereotyped active classes.