Program No-2

Objective: Draw the use case diagram and specify the role of each of the actors. Also state the
precondition, post condition and function of each use case.

The use case model for the Supermarket Prize Scheme described in Lesson 5.2 is shown in fig. 2.1.
As discussed earlier, the use cases correspond to the high level functional requirements. From the
problem description, we can identify three use cases: “register-customer”, “register-sales”, and
“select-winners”. As a sample, the text description for the use case “register-customer” is shown.

Fig. 2.1 Use case model for Supermarket Prize Scheme

Text description
U1: register-customer: Using this use case, the customer can register himself by providing the
necessary details.
Scenario 1: Mainline sequence
1. Customer: select register customer option.
2. System: display prompt to enter name, address, and telephone number.
3. Customer: enter the necessary values.
4. System: display the generated id and the message that the customer has been successfully
registered.
Scenario 2: at step 4 of mainline sequence
1. System: displays the message that the customer has already registered.
Scenario 2: at step 4 of mainline sequence 1. System: displays the message that some input
information has not been entered. The system display a prompt to enter the missing value.
The description for other use cases is written in a similar fashion.
The use case model for the Tic-tac-toe problem is shown in fig. 2.2. This software has only one use
case “play move”. Note that the use case “get-usermove” is not used here. The name “get-user-
move” would be inappropriate because the use cases should be named from the users’ perspective.

Fig. 2.2: Use case model for tic-tac-toe game

Text Description
Each ellipse on the use case diagram should be accompanied by a text description. The text
description should define the details of the interaction between the user and the computer and other
aspects of the use case. It should include all the behavior associated with the use case in terms of the
mainline sequence, different variations to the normal behavior, the system responses associated with
the use case, the exceptional conditions that may occur in the behavior, etc. The behavior description
is often written in a conversational style describing the interactions between the actor and the
system. The text description may be informal, but some structuring is recommended. The following
are some of the information which may be included in a use case text description in addition to the
mainline sequence, and the alternative scenarios.
Contact persons: This section lists the personnel of the client organization with whom the use case
was discussed, date and time of the meeting, etc.
Actors: In addition to identifying the actors, some information about actors using this use case
which may help the implementation of the use case may be recorded.
Pre-Condition: The preconditions would describe the state of the system before the use case
execution starts.
Post-Condition: This captures the state of the system after the use case has successfully completed.
Non-Functional Requirements: This could contain the important constraints for the design and
implementation, such as platform and environment conditions, qualitative statements, response time
requirements, etc.
 Program No-3
Objective: Draw the activity diagram.

Overview:

Activity diagram is another important diagram in UML to describe dynamic aspects of the system.

Activity diagram is basically a flow chart to represent the flow from one activity to another activity.
The activity can be described as an operation of the system.

So the control flow is drawn from one operation to another. This flow can be sequential, branched or
concurrent. Activity diagrams deals with all type of flow control by using different elements like
fork, join etc.

Purpose:

The basic purposes of activity diagrams are similar to other four diagrams. It captures the dynamic
behaviour of the system. Other four diagrams are used to show the message flow from one object to
another but activity diagram is used to show message flow from one activity to another.

Activity is a particular operation of the system. Activity diagrams are not only used for visualizing
dynamic nature of a system but they are also used to construct the executable system by using
forward and reverse engineering techniques. The only missing thing in activity diagram is the
message part.

It does not show any message flow from one activity to another. Activity diagram is some time
considered as the flow chart. Although the diagrams looks like a flow chart but it is not. It shows
different flow like parallel, branched, concurrent and single.

So the purposes can be described as:

Draw the activity flow of a system.

Describe the sequence from one activity to another.

Describe the parallel, branched and concurrent flow of the system.

How to draw Activity Diagram?

Activity diagrams are mainly used as a flow chart consists of activities performed by the system. But
activity diagram are not exactly a flow chart as they have some additional capabilities. These
additional capabilities include branching, parallel flow, swimlane etc.

Before drawing an activity diagram we must have a clear understanding about the elements used in
activity diagram. The main element of an activity diagram is the activity itself. An activity is a
function performed by the system. After identifying the activities we need to understand how they
are associated with constraints and conditions.

So before drawing an activity diagram we should identify the following elements:

Activities

Association

Conditions

Constraints

Once the above mentioned parameters are identified we need to make a mental layout of the entire
flow. This mental layout is then transformed into an activity diagram.

The following is an example of an activity diagram for order management system. In the diagram
four activities are identified which are associated with conditions. One important point should be
clearly understood that an activity diagram cannot be exactly matched with the code. The activity
diagram is made to understand the flow of activities and mainly used by the business users.

The following diagram is drawn with the four main activities:

Send order by the customer

Receipt of the order

Confirm order

Dispatch order

After receiving the order request condition checks are performed to check if it is normal or special
order. After the type of order is identified dispatch activity is performed and that is marked as the
termination of the process.
Where to use Activity Diagrams?

The basic usage of activity diagram is similar to other four UML diagrams. The specific usage is to
model the control flow from one activity to another. This control flow does not include messages.

The activity diagram is suitable for modeling the activity flow of the system. An application can
have multiple systems. Activity diagram also captures these systems and describes flow from one
system to another. This specific usage is not available in other diagrams. These systems can be
database, external queues or any other system.

Now we will look into the practical applications of the activity diagram. From the above discussion
it is clear that an activity diagram is drawn from a very high level. So it gives high level view of a
system. This high level view is mainly for business users or any other person who is not a technical
person.

This diagram is used to model the activities which are nothing but business requirements. So the
diagram has more impact on business understanding rather implementation details.

Following are the main usages of activity diagram:

Modeling work flow by using activities.

Modeling business requirements.
High level understanding of the system's functionalities.
Investigate business requirements at a later stage.
 Program No-4
Objetive:- a sequence diagra Draw the sequence diagram for any two scenarios.

Theory:-

Sequence diagrams, commonly used by developers, model the interactions between objects in a
single use case. They illustrate how the different parts of a system interact with each other to carry
out a function, and the order in which the interactions occur when a particular use case is executed.

In simpler words,m shows different parts of a system work in a ‘sequence’ to get something done.

A sequence diagram represents the scenario or flow of events in one single use case. The message
flow of the sequence diagram is based on the narrative of the particular use case.

Sequence Diagram of an Online Exam System

Sequence Diagram Example of a School Management System
 Program No. 5
Objective:- Draw the collaboration diagram.

Theory:- A collaboration diagram, also called a communication diagram or interaction diagram, is

an illustration of the relationships and interactions among software objects in the Unified Modeling
Language (UML).

UML collaboration/communication diagrams like UML sequence diagrams, are used to explore the
dynamic nature of your software. Collaboration diagrams show the message flow between objects in
an OO application, and also imply the basic associations (relationships) between classes.

There are guidelines for:

1.General issues

2.Messages

3.Links

1. General

Figure 1. An Instance-Level UML Collaboration diagram.

1.Use Instance-Level Diagrams To Explore Object Design Issues. Instance-level UML
Collaboration diagrams, such as the one shown in Figure 1, depict interactions between objects
(instances). Instance-level diagrams are typically created to explore the internal design of object-
oriented software.

2.Use Specification-Level Diagrams to Explore Roles. Specification-level UML Collaboration

diagrams, such as the one shown in Figure 4, are used to analyze and explore the roles taken by
domain classes within a system.

3.Collaboration Diagrams Do Not Model Process Flow.

4.When Sequence Is Important Use a Sequence Diagram.

5.Apply Sequence Diagram Guidelines To Instance-Level Collaboration Diagrams. Because UML

Collaboration diagrams depict an alternate view of the same information as UML Sequence
diagrams much of the same style advice applies.

2. Messages

Figure 2 presents the notation for invoking messages on UML Collaboration diagrams. For example
in Figure 1 the message 1.2: orderTotal := calculateTotal() indicates a sequence number of 1.2, there
is no loop occuring, a return value of orderTotal and an invoked method named calculateTotal().

Figure 2. The basic notation for invoking a message on a collaboration diagram.

sequenceNumber loopIndicator: returnValue := methodName(parameters)

Figure 3. A UML Coll

aboration diagram depicting concurrent message invocations.

1. Indicate a Return Value Only When It Isn't Clear

2. Indicate Parameters Only When They Aren't Clear

3. Depict an Arrow For Each Message

4. Consolidate Getter Invocations. When you have several getters invoked in a row a good short
cut is to model a single message such as getInfo() in Figure 1 to act as a placeholder.

5. Indicate Concurrent Threads With Letters. In Figure 3 you see that some messages are
preceded by the letters A, B, C, and D indicating that those messages are being processed
concurrently.

3. Links

The lines between the classifiers depicted on a UML Collaboration diagram represent instances of
the relationships - including associations, aggregations, compositions, and dependencies - between
classifiers.

Figure 4. A Specification-Level UML Collaboration diagram.

1. Model "Bare" Links On Instance-Level Collaboration Diagrams

2. Show Role-Pertinent Information on Specification-Level Diagrams. In Figure 4 you see that

the roles taken by classes as well as the high-level multiplicities (either blank or an asterisk to
represent many) are depicted.

3. Prefer Roles on Links Instead of Within Classes

4. Indicate Navigability Sparingly

5. Links Should Be Consistent Static Relationships

 Program no. 7
Objective:-Draw the state chart diagram.

Theory:-

A state diagram, also called a state machine diagram or statechart diagram, is an illustration of the
states an object can attain as well as the transitions between those states in the Unified Modeling
Language (UML).

Statechart diagram is used to describe the states of different objects in its life cycle. So the emphasis
is given on the state changes upon some internal or external events. These states of objects are
important to analyze and implement them accurately.

Statechart diagrams are very important for describing the states. States can be identified as the
condition of objects when a particular event occurs.

Before drawing a Statechart diagram we must have clarified the following points:

 Identify important objects to be analyzed.

 Identify the states.

 Identify the events.

The following is an example of a Statechart diagram where the state of Order object is analyzed.

The first state is an idle state from where the process starts. The next states are arrived for events like
send request, confirm request, and dispatch order. These events are responsible for state changes of
order object.

During the life cycle of an object (here order object) it goes through the following states and there
may be some abnormal exists also. This abnormal exit may occur due to some problem in the
system. When the entire life cycle is complete it is considered as the complete transaction as
mentioned below.

The initial and final state of an object is also shown below.

 Program No. 8
Objective:-Draw The component diagram.

Theory:-

A component diagram describes the organization and wiring of the physical components in a system.
Component diagrams are often drawn to help model implementation details and double-check that
every aspect of the system's required functions is covered by planned development.

In the first version of UML, components included in these diagrams were physical: documents,
database table, files, and executables, all physical elements with a location. In the world of UML 2,
these components are less physical and more conceptual stand-alone design elements such as a
business process that provides or requires interfaces to interact with other constructs in the system.
The physical elements described in UML 1, like files and documents, are now referred to as artifacts.
A UML 2 component may contain multiple physical artifacts if they naturally belong together.

Steps to Creating a Component Diagram

 Take stock of everything needed to implement the planned system. For example, for a simple
e-commerce system, you'll need components that describe products, orders, and customer
accounts.

 Create a visual for each of the components.

 Describe the organization and relationships between components using interfaces, ports, and
dependencies.
Basic Component Diagram Symbols and Notations
Component
A component is a logical unit block of the system, a slightly higher abstraction than classes. It is
represented as a rectangle with a smaller rectangle in the upper right corner with tabs or the word
<component> written above the name of the component to help distinguish it from a class.

Interface
An interface (small circle or semi-circle on a stick) describes a group of operations used (required)
or created (provided) by components. A full circle represents an interface created or provided by the
component. A semi-circle represents a required interface, like a person's input.

Dependencies
Draw dependencies among components using dashed arrows.

Port
Ports are represented using a square along the edge of the system or a component. A port is often
used to help expose required and provided interfaces of a component.

Online Shopping
UML Component Diagram Example