OOAD

Unit-3

Nested State Diagram:

A nested state diagram is used to model the complex system as the regular state diagram is
inadequate in describing the large and complex problem. The nested state diagram is the
concept of advanced state modelling.

Conventionally a complex system has much redundancy. This redundancy can be resolved by
restructuring the complex system. One method to restructure complex system is to expand the
state that has certain sub states.

Expanding States

The complex system can be restructured by implementing sub diagrams to a high-level diagram
and this can be done by expanding the states that have multiple sub states. This is just like we
use macros in the programming language.

To get a better understanding of this let us consider an example of a vending machine. B At

the beginning the machine is idle, now, a person comes and insert some coins into the vending
machine and select an item. If the selected item is not available or the amount inserted is
insufficient then the machine would wait for the person to take another action.

If the amount is sufficient and the item is available then the machine would dispense the
selected item and deduct the required amount from the inserted amount and would return the
remaining change. The diagram below shows you the state diagram of the vending machine.

Observe the state dispense may have multiple substates so it is expanded in the lower level
state diagram, which is also termed as submachine. The term submachine is defined as a state
diagram which is triggered by another high-level state diagram.
In the UML notation, the sub machine is denoted by the state name followed by a colon and
the corresponding submachine name. Conceptually a submachine is just like the subroutines in
the programming language.

The other method to model the complex system is using nested states.

Nested States

Nested states, is a deeper alternative to expanding states. When a state has multiple sub states
then they could be nested and enclosed in a contour and could be labelled as the composite
state name. Consider an example of a nested state for a phone line.
In the figure above, you can observe that the Active state is the composite state. The states
DialTone, Dialing, BusyTone and so on all are the nested state enclosed in a composite Active
state. You are allowed to nest the states to an arbitrary length. Every nested state inside the
composite Active state when receives the event ‘onHook’, the corresponding state transits to
the Idle state.

Let us understand nested states with one more example of ‘car transmission. Observe that there
are three states inside CarTransmission state diagram i.e. reverse, neutral and forward. Among
these three states, the forward state has three nested states i.e. First, Second and Third.

At any nested state of Forward gear composite state, selecting N would transit the
corresponding state to the neutral state. Being in a neutral state, selecting F would transit you
to the Forward state.

But here by default, the First nested state in the Forward contour is the initial state and the
control is in the First state. Here the Forward is just an abstract state. You can notice that the
event Stop is shared by all the three nested state. That means if the car is in any Forward gear
the stopping event would transit the car to the First state.

In the nested state diagram, the entry and exit activities allow the state to indicate entry and
exit without worrying about before the state is active and what happens after the state get active.

Whenever a state is transiting into a nested state or transiting out of the nested state it may be
due to the execution several, entry and exit activities if the transition is occurring across several
levels of the nested state. The entry activity is transiting inside the nested state and the exit
activity is transiting outside the several states just like the subroutine calls in a programming
language.

Generalization:

Generalization is the process of extracting common characteristics from a set of classes and
abstracting them into a more general superclass or interface. It embodies the “is-a” relationship,
where a subclass is said to be a specialized version of its superclass, inheriting its attributes and
behaviors while potentially adding or modifying its own.

Importance of Generalization in OOAD

 • Code Reusability: Generalization enables the reuse of code by allowing common
attributes and behaviors to be inherited by multiple classes.

• Abstraction: Generalization promotes abstraction by identifying commonalities

among classes and abstracting them into a higher-level superclass.

• Ease of Maintenance: By defining common characteristics in a superclass, changes

made to those characteristics propagate to all subclasses, reducing the need for
redundant modifications.

• Polymorphism: Generalization facilitates polymorphism, allowing objects of different

subclasses to be treated interchangeably through their common superclass interface.

• Hierarchical Organization: Generalization provides a structured way to organize

classes into hierarchies, making the system easier to understand and maintain.

Relation of class and state models:

Class Model: describes the structure of objects in a system, their identity, their relationships
to other objects, their attributes and their operations. Our goal in constructing a class model is
to capture those concepts from the real world that are important to an application. In modeling
an engineering problem, the class model should contain terms familiar to engineers. Class
diagrams express the class model. Classes define the attribute values carried by each object and
the operations that each object performs or undergoes.
State Model: describes those aspects of objects concerned with time and the sequencing of
operations – events that mark changes, states that context for events and the organization of
events and states. State diagrams express the state model. Each state diagram shows the state
and event sequences permitted in a system for one class of objects. Actions and events in a
state diagram become operations on objects in the class model.

Use-Case Model

The Use-case model is defined as a model which is used to show how users interact with the
system in order to solve a problem. As such, the use case model defines the user's objective,
the interactions between the system and the user, and the system's behavior required to meet
these objectives.

Various model elements are contained in use-case model, such as actors, use cases, and the
association between them.

We use a use-case diagram to graphically portray a subset of the model in order to make the
communication simpler. There will regularly be a numerous use-case diagram which is related
to the given model, each demonstrating a subset of the model components related to a specific
purpose. A similar model component might be appearing on a few use-case diagrams; however,
each use-case should be consistent. If, in order to handle the use-case model, tools are used
then this consistency restriction is automated so that any variations to the component of the
model (changing the name, for instance) will be reflected automatically on each use-case
diagram, which shows that component.
Packages may include a use-case model, which is used to organize the model to simplify the
analysis, planning, navigation, communication, development and maintenance.

The use-case model acts as an integrated thread in the development of the entire system. The
use-case model is used like the main specification of the system functional requirements as the
basis for design and analysis, as the basis for user documentation, as the basis of defining test
cases, and as an input to iteration planning.

Components of Basic Model

There are various components of the basic model:

1. Actor
2. Use Case
3. Associations

Actor

Usually, actors are people involved with the system defined on the basis of their roles. An actor
can be anything such as human or another external system.

Use Case

The use case defines how actors use a system to accomplish a specific objective. The use cases
are generally introduced by the user to meet the objectives of the activities and variants
involved in the achievement of the goal.

Associations

Associations are another component of the basic model. It is used to define the associations
among actors and use cases they contribute in. This association is called communicates-
association.

How to Draw a Use-Case Diagram?

If we want to draw a use case diagram in UML first, we must study the complete system
appropriately. We need to find out every function which is offered by the system. When we
find out all the system's functionalities then we convert these functionalities into a number of
use cases, and we use these use-cases in the use case diagram.

A use case means essential functionality of any working system. When we organize the use
cases, then next we need to enlist the numerous actors or things that will collaborate with the
system. These actors are used to implement the functionality of a system. Actors can be
someone or something. It can likewise be a private system's entity. The actors should be
pertinent to the functionality or a system in which the actors are interacting.

When we enlist the use cases and actors, then next, we need to find the relationship of a specific
actor with the system or a use case. An actor should find the total number of ways in order to
cooperate with the system. One actor can interact with the numerous use cases simultaneously,
or it may interact with the multiple-use cases concurrently.

We have to follow the following rules while drawing use-case for any framework:

• The use case name and actor name should be meaningful and related to the system.
• The actor's interaction with the use case should be well-described and in a
comprehensible manner.
• Use annotations wherever they are essential.
• If the actor or use case has many relationships, then display only important interactions.

Basic Use-Case Diagram Symbols and Notations

There are following use-case diagram symbols and notations:

System

With the help of the rectangle, we can draw the boundaries of the system, which includes use-
cases. We need to put the actors outside the system's boundaries.

Use-Case

With the help of the Ovals, we can draw the use-cases. With the verb we have to label the ovals
in order to represent the functions of the system.

Actors

Actors mean the system's users. If one system is the actor of the other system, then with the
actor stereotype, we have to tag the actor system.

Relationships

With the simple line we can represent relationships between an actor and use cases. For
relationships between use-case, we use arrows which are labeled either "extends" or "uses".
The "extends" relationship shows the alternative options under the specific use case. The "uses"
relationship shows that single use-case is required to accomplish a job

The below figure shows the working of the student management system:

Sequence Model (Sequence Diagram):

The sequence diagram represents the flow of messages in the system and is also termed as an
event diagram. It helps in envisioning several dynamic scenarios. It portrays the
communication between any two lifelines as a time-ordered sequence of events, such that these
lifelines took part at the run time. In UML, the lifeline is represented by a vertical bar, whereas
the message flow is represented by a vertical dotted line that extends across the bottom of the
page. It incorporates the iterations as well as branching.

Purpose of a Sequence Diagram

1. To model high-level interaction among active objects within a system.

2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.
Notations of a Sequence Diagram

Lifeline

An individual participant in the sequence diagram is represented by a lifeline. It is positioned

at the top of the diagram.

Actor

A role played by an entity that interacts with the subject is called as an actor. It is out of the
scope of the system. It represents the role, which involves human users and external hardware
or subjects. An actor may or may not represent a physical entity, but it purely depicts the role
of an entity. Several distinct roles can be played by an actor or vice versa.

Activation

It is represented by a thin rectangle on the lifeline. It describes that time period in which an
operation is performed by an element, such that the top and the bottom of the rectangle is
associated with the initiation and the completion time, each respectively.
Messages

The messages depict the interaction between the objects and are represented by arrows. They
are in the sequential order on the lifeline. The core of the sequence diagram is formed by
messages and lifelines.

Following are types of messages enlisted below:

ADVERTISEMENT

• Call Message: It defines a particular communication between the lifelines of an

interaction, which represents that the target lifeline has invoked an operation.

• Return Message: It defines a particular communication between the lifelines of

interaction that represent the flow of information from the receiver of the corresponding
caller message.

• Self Message: It describes a communication, particularly between the lifelines of an

interaction that represents a message of the same lifeline, has been invoked.

• Recursive Message: A self message sent for recursive purpose is called a recursive
message. In other words, it can be said that the recursive message is a special case of
 the self message as it represents the recursive calls.

• Create Message: It describes a communication, particularly between the lifelines of

an interaction describing that the target (lifeline) has been instantiated.

• Destroy Message: It describes a communication, particularly between the lifelines of

an interaction that depicts a request to destroy the lifecycle of the target.

• Duration Message: It describes a communication particularly between the lifelines of

an interaction, which portrays the time passage of the message while modeling a
system.

Diagram

The sequence diagram represents the flow of messages in the system and is also termed as an
event diagram. It helps in envisioning several dynamic scenarios. It portrays the
communication between any two lifelines as a time-ordered sequence of events, such that these
lifelines took part at the run time. In UML, the lifeline is represented by a vertical bar, whereas
the message flow is represented by a vertical dotted line that extends across the bottom of the
page. It incorporates the iterations as well as branching.

Purpose of a Sequence Diagram

1. To model high-level interaction among active objects within a system.

2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.
Notations of a Sequence Diagram

Lifeline

An individual participant in the sequence diagram is represented by a lifeline. It is positioned

at the top of the diagram.

Actor

A role played by an entity that interacts with the subject is called as an actor. It is out of the
scope of the system. It represents the role, which involves human users and external hardware
or subjects. An actor may or may not represent a physical entity, but it purely depicts the role
of an entity. Several distinct roles can be played by an actor or vice versa.

Activation

It is represented by a thin rectangle on the lifeline. It describes that time period in which an
operation is performed by an element, such that the top and the bottom of the rectangle is
associated with the initiation and the completion time, each respectively.
Messages

The messages depict the interaction between the objects and are represented by arrows. They
are in the sequential order on the lifeline. The core of the sequence diagram is formed by
messages and lifelines.

Following are types of messages enlisted below:

ADVERTISEMENT

• Call Message: It defines a particular communication between the lifelines of an

interaction, which represents that the target lifeline has invoked an operation.

• Return Message: It defines a particular communication between the lifelines of

interaction that represent the flow of information from the receiver of the
corresponding caller message.

• Self Message: It describes a communication, particularly between the lifelines of an

interaction that represents a message of the same lifeline, has been invoked.

• Recursive Message: A self message sent for recursive purpose is called a recursive
message. In other words, it can be said that the recursive message is a special case of
the self message as it represents the recursive calls.
 • Create Message: It describes a communication, particularly between the lifelines of
an interaction describing that the target (lifeline) has been instantiated.

• Destroy Message: It describes a communication, particularly between the lifelines of

an interaction that depicts a request to destroy the lifecycle of the target.

• Duration Message: It describes a communication particularly between the lifelines of

an interaction, which portrays the time passage of the message while modeling a
system.

• Example of a Sequence Diagram

An example of a high-level sequence diagram for online bookshop is given below.
Any online customer can search for a book catalog, view a description of a particular
book, add a book to its shopping cart, and do checkout.
Activity Model (Activity Diagram):

In UML, the activity diagram is used to demonstrate the flow of control within the system
rather than the implementation. It models the concurrent and sequential activities.

The activity diagram helps in envisioning the workflow from one activity to another. It put
emphasis on the condition of flow and the order in which it occurs. The flow can be sequential,
branched, or concurrent, and to deal with such kinds of flows, the activity diagram has come
up with a fork, join, etc.

It is also termed as an object-oriented flowchart. It encompasses activities composed of a set

of actions or operations that are applied to model the behavioral diagram.

Components of an Activity Diagram

Following are the component of an activity diagram:

Activities

The categorization of behavior into one or more actions is termed as an activity. In other words,
it can be said that an activity is a network of nodes that are connected by edges. The edges
depict the flow of execution. It may contain action nodes, control nodes, or object nodes.

The control flow of activity is represented by control nodes and object nodes that illustrates the
objects used within an activity. The activities are initiated at the initial node and are terminated
at the final node.
Activity partition /swimlane

The swimlane is used to cluster all the related activities in one column or one row. It can be
either vertical or horizontal. It used to add modularity to the activity diagram. It is not necessary
to incorporate swimlane in the activity diagram. But it is used to add more transparency to the
activity diagram.

Forks

ADVERTISEMENT

Forks and join nodes generate the concurrent flow inside the activity. A fork node consists of
one inward edge and several outward edges. It is the same as that of various decision
parameters. Whenever a data is received at an inward edge, it gets copied and split crossways
various outward edges. It split a single inward flow into multiple parallel flows.

Join Nodes

Join nodes are the opposite of fork nodes. A Logical AND operation is performed on all of the
inward edges as it synchronizes the flow of input across one single output (outward) edge.
Pins

It is a small rectangle, which is attached to the action rectangle. It clears out all the messy and
complicated thing to manage the execution flow of activities. It is an object node that precisely
represents one input to or output from the action.

Notation of an Activity diagram

Activity diagram constitutes following notations:

Initial State: It depicts the initial stage or beginning of the set of actions.

Final State: It is the stage where all the control flows and object flows end.

Decision Box: It makes sure that the control flow or object flow will follow only one path.

Action Box: It represents the set of actions that are to be performed.

Example of an Activity Diagram

An example of an activity diagram showing the business flow activity of order processing is
given below.

Here the input parameter is the Requested order, and once the order is accepted, all of the
required information is then filled, payment is also accepted, and then the order is shipped. It
permits order shipment before an invoice is sent or payment is completed.
Use-case Relationships:
In UML, a relationship is a connection between model elements. A UML relationship is a type
of model element that adds semantics to a model by defining the structure and behavior
between the model elements.
UML relationships are grouped into the following categories:

Category Function

Activity edges Represent the flow between activities

Associations Indicate that instances of one model element are connected to instances of
another model element

Dependencies Indicate that a change to one model element can affect another model
element

Generalizations Indicate that one model element is a specialization of another model element

Realizations Indicate that one model element provides a specification that another model
element implements

Transitions Represent changes in state

You can set properties and use keywords to create variations of these relationships.

The following topics describe the relationships that you can use in use-case diagrams:

• Association relationships
In UML models, an association is a relationship between two classifiers, such as
classes or use cases, that describes the reasons for the relationship and the rules that
govern the relationship.
• Generalization relationships
In UML modeling, a generalization relationship is a relationship in which one model
element (the child) is based on another model element (the parent). Generalization
relationships are used in class, component, deployment, and use-case diagrams to
indicate that the child receives all of the attributes, operations, and relationships that
are defined in the parent.
• Include relationships
In UML modeling, an include relationship is a relationship in which one use case (the
base use case) includes the functionality of another use case (the inclusion use case).
The include relationship supports the reuse of functionality in a use-case model.
• Extend relationships
In UML modeling, you can use an extend relationship to specify that one use case
(extension) extends the behavior of another use case (base). This type of relationship
reveals details about a system or application that are typically hidden in a use case.