Uml modelling

Unified Modeling Language

The UML is a complete language that is used to design, visualize, construct and document
systems. It is largely based on the object-oriented paradigm and is an essential tool for
developing robust and maintainable software systems.

Visual Case includes eight powerful UML Diagrams. Objects that you've defined can be
displayed on multiple diagrams, and many objects can be exploded (or decomposed) into new
diagrams.

UML Diagrams in Visual Case

Use Case Diagram The Use Case Diagram describes the system functionality
as a set of Use Cases which represent discrete tasks.
Actors interact with the system to complete the tasks.

Class Diagram The Class Diagram describes the structure of the software
system. This is the core diagram for object-oriented
design.

Sequence Diagram The Sequence Diagram describes messages exchanged

between classes to accomplish tasks.

Collaboration The Collaboration Diagram describes interactions

Diagram between classes and associations.

State Diagram State Diagrams model the dynamic behaviour of a system

by showing the various states that an object can get into
and the transitions that occur between the states.

Activity Diagram The Activity Diagram describes the activities of a class in

response to internal events.

Component Diagram The Component Diagram describes the structure and

dependencies among software components.

Deployment Diagram The Deployment Diagram describes the physical layout of

software components.
 Collaboration Diagram
Collaboration diagrams belong to a group of UML diagrams called Interaction
Diagrams. Collaboration diagrams, like Sequence Diagrams, show how objects
interact over the course of time. However, instead of showing the sequence of
events by the layout on the diagram, collaboration diagrams show the sequence
by numbering the messages on the diagram. This makes it easier to show how
the objects are linked together, but harder to see the sequence at a glance.
Type:
The message type can be:

• Call,
• Create,
• Destroy, or
• Return

Sequence Diagram
A sequence diagram in Unified Modelling Language (UML) is a kind of interaction diagram
that shows how processes operate with one another and in what order. It is a construct of a
Message Sequence Chart.

Sequence diagrams are sometimes called event diagrams, event scenarios, and timing
diagrams

Difference B/W Collaboration and

sequence diagram
Sequence diagrams specify interaction in a time sequence manner which may be among
objects and/or classes. These diagrams are created during early elaboration phase where
each flow of the use case is defined in terms of sequences, i.e. after each step what is
going to happen next. This kind of representation is very helpful to understand & discuss
the use cases with the customer, where both can come out with all possible functional
aspects.

On the other hand collaboration diagram provides a direct interaction among the
object. These diagram seem to used more in the design phase of the development when
you are designing the implementation of the relationship.

Depicting synchronous messages with and without

priority call back mechanism
A message indicates a communication between objects. The order of messages from top to
bottom on your diagram should be the order in which the messages occur.

A message can be from an object to itself.

A return message indicates a response from a message (rather than a new message) and is
shown on the diagram as a dashed line.

A recursive message is one that calls itself.

An asynchronous message doesn't block the object that makes the call so that the object can
carry on with it's own processing without waiting for a response.

INTERACTION DIAGRAM
Interaction diagrams describe how groups of objects collaborate in order to
implement the behaviour described by the use cases.
 Activity diagrams
Activity diagrams are a variation of state diagrams which show the sequence of activity
states (states that are doing something). The diagram can show conditional and parallel
behaviour.

The initial state is the starting state with reference to the behaviour that the diagram explains.
Each activity diagram should have only one initial state. A final state represents one of the
possible ending states.

ADVANCED BEHAVIOURAL MODELLING

When we refer to external events, we mean those that pass between the system and
its actors (actors are external to the system). Conversely, internal events are passed
between objects that live inside of the system.

As mentioned above, in the UML, we model four kinds of events:

• Signals
• Calls
 • Passing of time
• Change in state

Signals

Signals are named objects that are asynchronously thrown by one object and
caught by another. The most common use for internal signals is as exceptions.
Although signals are generally not modelled explicitly, the UML provides the
ability to model a signal as a stereotyped class, The UML uses a dependency
relationship, stereotyped as <<send>> to indicate that an operation sends a signal.

Call Events

A call event represents the dispatch of an operation to trigger a state transition in a

state machine. Whereas a signal is an asynchronous event, a call is a synchronous
event, meaning that control is handed over and to the receiver until some operation
is completed, then control is passed back to the sender.

Time and Change Events

A change event is modeled by the keyword 'when' followed by a boolean

expression (evaluates to either true or false) depending on either an absolute or
continuous test. In this case, the event is generated when the condition becomes
true.

Sending and Receiving

An instance of a class (an object) can send or receive signals or events. When an
object sends a signal, it continues along its flow of control without waiting for a
return from the receiver (asynchronous). When an object sends an event, such as to
invoke an operation, it waits for the receiver to complete the specified operation,
before control is returned to the sender (synchronous).

State machines and Event

A state machine is a behavior that specifies the sequences of various states an
object may go through in its lifetime, in response to events.

A state is a condition or situation in the life of an object during which it satisfies

some condition, performs an activity, or waits for an event.

An event is the specification for a significant occurrence, that has the

characteristics of time and space. In the context of state machines, an event
provides the trigger for a state transition.
A transition is the relationship between two states, indicating that an object in the
first state will perform certain actions to enter the second state, when a specific
event occurs under a particular set of conditions.

An activity is ongoing non-atomic execution within a state machine.

An action is an executable atomic computation that results in a change in state of

the model or the return of a value.

States are rendered as rounded rectangles, and transitions are shown as solid
directed lines, as in fig 21-1, p 289, along with events and actions.

State machines are useful in modeling the dynamic aspects of a system by

specifying the lifetime of an object or an entire system, and in illustrating the way
objects to events. When an event occurs, some activity will take place, depending
on the current state of the object. Activities result in some action, changing the
state of the object.

State machines can be viewed in two ways:

1. Activity Diagrams - emphasize the flow of control from activity to activity,

by focusing on activities that take place within the object.
2. State chart Diagrams - (chap 24) emphasize the potential states of the
objects and the transitions among those states, by focusing on the event-
ordered behaviour of an object.

Component Diagram
Component diagrams show how the physical components of a system are organized.

A component is a distributable unit of software.

The component diagram allows you to combine deployment nodes with components to show
which components run on each node (i.e. hardware).
 States
States

A state is a condition or situation in the life of an object during which it satisfies

some condition, performs an activity, or waits for an event.

States can include several parts, given on the bottom of p 291 and top of p 292.

1. Name
2. Entry/exit actions
3. Internal transitions
4. Substates:-

Substates help to simplify the modeling of complex behaviors in the UML.

As its name implies, a substate is a state that is nested inside another state.
There are two types of substates that we will be concerned with depending
on the type of behavior we are modeling: Sequential Substates and
Concurrent Substates.

5. Deferred events

Deferred Events

A deferred event is a list of events whose occurrence in the state is

postponed until a state in which the listed events are not deferred becomes
active, at which time they occur and may trigger transitions as if they had
just occurred.

Internal Transitions

Internal transitions are handled without changing the state. This differs from
self-transitions which trigger a new transition and action whenever you
leave and reenter the same state
 Transition
Transitions

A transition is the relationship between two states, indicating that an object in the
first state will perform certain actions to enter the second state, when a specific
event occurs under a particular set of conditions. On such a change of state, a
transition is said to fire.

Transitions consist of five parts, listed on p 293:

1. Source state
2. Event trigger
3. Guard condition
4. Action
5. Target state

These parts are also shown in fig 21-3, p 293. A self-transition is one whose source
and target states are the same. It is worth noting that a transition may have multiple
sources (representing a join from multiple concurrent states) or multiple targets
(representing a fork to multiple concurrent states).
Event Trigger

An event is the specification for a significant occurrence, that has the

characteristics of time and space. Examples of event triggers are given in fig 21-3.
It is possible to have a triggerless transition, represented by a transition with no
event trigger. A triggerless transition is triggered implicitly when its source state
has completed its activity.

Guard Condition

A guard condition is evaluated only after the trigger event for its transition occurs.
A guard transition is evaluated just once for each transition at the time the event
occurs, but is may be evaluated again if the transition is retriggered.

Action

An action is an executable atomic computation. Actions, by definition, cannot be

interrupted by an event and therefore run to completion. In contrast, an activity
may be interrupted by other events.

The UML's state machines have a number of advanced features that help manage
complex behavioral models. These are summarized in fig 21-4, p 296 as entry
action, exit action, internal transitions, activity, deferred event.

Entry and Exit Actions

Entry and Exit Actions are used in situations where you want to dispatch the same
action whenever you enter or leave a state, regardless of the transition that led you
there.

Activities

The UML provides the special 'do' transition (fig 21-4) to specify the work that's to
be done inside a state after the entry action is dispatched.
 Deployment Diagram
The deployment diagram shows how the components of the completed system are
physically related (i.e. what hardware will the system be running on and how will it all be
connected).

Each node represents a computational unit such as a piece of hardware.

The connections between the nodes show the system interaction paths.

Usecase
The use case diagrams describe system functionality as a set of tasks that the system must
carry out and actors who interact with the system to complete the tasks.

Use Case:
Each use case on the diagram represents a single task that the system needs
to carry out. Buy a Product, Add Client, Make Purchase and Validate
Order Information are all examples of use cases. Some use cases may
include or extend a task represented by another use case. For example, in
order to make a purchase, the order information will need to be validated.
Actor:
An actor is anything outside the system that interacts with the system to
complete a task. It could be a user or another system. The actor "uses" the
use case to complete a task. System Administrator, Credit Authentication
System, Accounting System and Web Client are all examples of actors.
Often, it is useful to look at the set of use cases that an actor has access to
-- this defines the actor's overall role in the system.

Association:
The association is the link that is drawn between and actor and a use case. It indicates which
actors interact with the system to complete the various tasks.

Includes:
Use the includes link to show that one use case includes the task described by another use
case. For example, saving a Visual Case project includes saving the diagrams and saving the
project settings. Sometimes the word "Uses" is used instead of "Includes".
Generalization:
The generalization link is an informal way of showing that one use case is similar to another
use case, but with a little bit of extra functionality. One use case inherits the functionality
represented by another use case and adds some additional behaviour to it.

Extends:
The extends link is used to show that one use case extends the task described by another use
case. It's very similar to generalization, but is much more formalized.

The use case that is extended is always referred to as the base use case and has one or more
defined extension points. The extension points show exactly where extending use cases are
allowed to add functionality. The extending use case doesn't have to add functionality at all
of the base use case's extension points. The extension link indicates which extension points
are being used.

Association, Aggregation and Composition

The association link indicates that two classes have a relationship: a student attends a school;
a student takes courses.

Each association link has two ends which are called roles. Each role has a name, a
multiplicity, a navigability and a type.

Multiplicity:
The multiplicity of a role indicates how many objects can participate in the relationship. In
the example above, a school has many students and each student attends only one school.

Navigability:
Sometimes a role has an arrow indicating its navigability. This shows which class has the
responsibility for maintaining the relationship between the classes. In the example above, the
school class has a responsibility for knowing which students attend. Therefore, you don't
have to explicitly define a getStudents operation in the school class (although you may) since
it is already implicitly defined by the navigability of the association.
Type:
The role can have one of three types: association, composition or aggregation.

Associations indicate that the two classes have a relationship as discussed above.
Composition and aggregation indicate something more about the relationship:

Composition indicates that one class belongs to the other. A polygon is made up of several
points. If the polygon is destroyed, so are the points.

Aggregation is similar to composition, but is a less rigorous way of grouping things. An

order is made up of several products, but a product continues to exist even if the order is
destroyed.

Interfaces and Realizations

An interface is essentially a class with no implementation. It contains a list of public

operations that can be implemented by other classes and has no attributes. The classes that
implement the interface don't need to know anything about how the interface is implemented.

Realization links are used in the example above to indicate that ClientArray and
PurchaseOrder implement the operations in Sortable. Use the display field on the
realization's property page to specify text that should appear next to the realization link on
your diagram.
Component

Composite

Usecase
Activity