Index: Sr. No. Name of The Experiments Remarks
Index: Sr. No. Name of The Experiments Remarks
Index: Sr. No. Name of The Experiments Remarks
Sr. No.
Introduction
10
11
12
13
14
Remarks
Introduction
Experiment-1
OBJECTIVE
Requirements
Categorization of Requirements
Based on the target audience or subject matter, requirements can be classified into different
types, as stated below:
User requirements: They are written in natural language so that both customers can verify
their requirements have been correctly identified
System requirements: They are written involving technical terms and/or specifications, and
are meant for the development or testing teams
Requirements can be classified into two groups based on what they describe:
Functional requirements (FRs): These describe the functionality of a system -- how a
system should react to a particular set of inputs and what should be the corresponding output.
Non-functional requirements (NFRs): They are not directly related what functionalities are
expected from the system. However, NFRs could typically define how the system should
behave under certain situations. For example, a NFR could say that the system should work
with 128MB RAM. Under such condition, a NFR could be more critical than a FR.
Non-functional requirements could be further classified into different types like:
Product requirements: For example, a specification that the web application should use
only plain HTML, and no frames
Performance requirements: For example, the system should remain available 24x7
Organizational requirements: The development process should comply to SEI CMM level
4
Functional Requirements
Experiment No 2
OBJECTIVE
o
o
o
o
Tracking Progress
Gantt Chart:
Bar chart format.
Useful to monitor project status at any point in time.
PERT Chart:
Flowchart format.
Illustrate task dependencies and critical path.
STARTING A NEW PROJECT
You can create a Project from a Template File by choosing File > New from the menu. In the
New File dialog box that opens, select the Project Templates tab and select the template that
suits your project best and click OK. (You may choose a Blank Project Template and
customize it)
Once a new Project page is opened, the Project Information dialog box opens.
Enter the start date or select an appropriate date by scrolling down the list. Click OK. Project
automatically enters a default start time and stores it as part of the dates entered and the
application window is displayed.
Views
Views allow you to examine your project from different angles based on what information
you want displayed at any given time. You can use a combination of views in the same
window at the same time.
Project Views are categorized into two types:
Task Views (5 types)
Resource Views (3 types)
The Project worksheet is located in the main part of the application window and displays
different information depending on the view you choose. The default view is the Gantt Chart
View.
Goals of any project need to be defined in terms of tasks. There are four major types of tasks:
1. Summary tasks - contain subtasks and their related properties
2. Subtasks - are smaller tasks that are a part of a summary task
3. Recurring tasks - are tasks that occur at regular intervals
4. Milestones - are tasks that are set to zero duration and are like interim goals in the project
LINKS
Tasks are usually scheduled to start as soon as possible i.e. the first working day after the
project start date.
Dependencies
Dependencies specify the manner in which two tasks are linked. Because Microsoft Project
must maintain the manner in which tasks are linked, dependencies can affect the way a task
is scheduled. In a scenario where there are two tasks, the following dependencies exist:
Finish to Start Task 2 cannot start until task 1 finishes.
Start to Finish Task 2 cannot finish until task 1 starts.
Start to Start Task 2 cannot start until task 1 starts.
Finish to Finish Task 2 cannot finish until task 1 finishes.
CONSTRAINTS
Certain tasks need to be completed within a certain date. Intermediate deadlines may need to
be specified. By assigning constraints to a task you can account for scheduling problems.
To apply a constraint:
1. Open the Task Information dialog box.
2. Click the Advanced tab and open the Constraint type list by clicking on the drop-down
arrow and select it.
3. Select a date for the Constraint and click OK.
RESOURCES
Once you determine that you need to include resources into your project you will need to
answer the following questions:
What kind of resources do you need?
How many of each resource do you need?
Where will you get these resources?
How do you determine what your project is going to cost?
Resources are of two types - work resources and material resources.
Work resources complete tasks by expending time on them. They are usually people and
equipment that have been assigned to work on the project.
Material resources are supplies and stocks that are needed to complete a project.
A new feature in Microsoft Project 2000 is that it allows you to track material resources and
assign them to tasks
To assign a resource to a task:
1. Open the Gantt Chart View and the Assign Resources Dialog box.
2. In the Entry Table select the tasks for which you want to assign resources.
3. In the Assign Resources Dialog box, select the resource (resources) you want to assign.
4. Click the Assign button.
Experiment No 3
Theory
Data Flow Diagram
DFD provides the functional overview of a system. The graphical representation easily
overcomes any gap between user and system analyst and analyst and system designer in
understanding a system. Starting from an overview of the system it explores detailed design
of a system through a hierarchy. DFD shows the external entities from which data flows into
the process and also the other flows of data within a system. It also includes the
transformations of data flow by the process and the data stores to read or write a data.
Graphical notations for Data Flow Diagram
Term
Notation
Remarks
External
entity
Process
Data store
Data flow
Process: Processes are represented by circle. The name of the process is written into the
circle. The name of the process is usually given in such a way that represents the
functionality of the process. More detailed functionalities can be shown in the next Level if it
is required. Usually it is better to keep the number of processes less than 7 [i]. If we see that
the number of processes becomes more than 7 then we should combine some the processes to
a single one to reduce the number of processes and further decompose it to the next level [2] .
External entity: External entities are only appearing in context diagram [2]. External entities
are represented by a rectangle and the name of the external entity is written into the shape.
These send data to be processed and again receive the processed data.
Data store: Data stares are represented by a left-right open rectangle. Name of the data store
is written in between two horizontal lines of the open rectangle. Data stores are used as
repositories from which data can be flown in or flown out to or from a process.
Data flow: Data flows are shown as a directed edge between two components of a Data Flow
Diagram. Data can flow from external entity to process, data store to process, in between two
processes and vice-versa.
Context diagram and leveling DFD
We start with a broad overview of a system represented in level 0 diagrams. It is known as
context diagram of the system. The entire system is shown as single process and also the
interactions of external entities with the system are represented in context diagram.
Further we split the process in next levels into several numbers of processes to represent the
detailed functionalities performed by the system. Data stores may appear in higher level
DFDs.
Numbering of processes : If process p in context diagram is split into 3 processes p1,
p2and p3 in next level then these are labeled as 0.1, 0.2 and 0.3 in level 1 respectively.
Let the process p3 is again split into three processes p31, p32 and p33 in level 2, so,
these are labeled as 0.3.1, 0.3.2 and 0.3.3 respectively and so on.
Balancing DFD: The data that flow into the process and the data that flow out to the process
need to be match when the process is split into in the next level[2]. This is known as
balancing
a
DFD.
Note :
1. External entities only appear in context diagram[2] i.e, only at level 0.
2. Keep number of processes at each level less than 7[i].
3. Data flow is not possible in between two external entities and in between two data stores[i].
4. Data cannot flow from an External entity to a data store and vice-versa[i].
Case Study
1 : A Library Information System for Institute
The Institute has been recently setup to provide state-of-the-art research facilities in the field
of Software Engineering. Apart from research scholars (students) and professors, it also
includes quite a large number of employees who work on different projects undertaken by the
institution.
As the size and capacity of the institute is increasing with the time, it has been proposed to
develop a Library Information System (LIS) for the benefit of students and employees of the
institute. LIS will enable the members to borrow a book (or return it) with ease while sitting
at his desk/chamber. The system also enables a member to extend the date of his borrowing if
no other booking for that particular book has been made. For the library staff, this system
aids them to easily handle day-to-day book transactions. The librarian, who has
administrative privileges and complete control over the system, can enter a new record into
the system when a new book has been purchased, or remove a record in case any book is
taken off the shelf. Any non-member is free to use this system to browse/search books
online. However, issuing or returning books is restricted to valid users (members) of LIS
only.
The final deliverable would a web application, which should run only within the institute
LAN. Although this reduces security risk of the software to a large extent, care should be
taken no confidential information (eg., passwords) is stored in plain text.
Figure 1 shows the context-level DFD for LIS. The entire system is represented with a single
circle (process). The external entities interacting with this system are members of LIS, library
staff, librarian, and non-members of LIS. Two database are used to keep track of member
information and details of books in the library.
Let us focus on the external entity, Member. In order to issue or return books a member has
to login to the system. The data flow labeled with "Login credentials" indicate the step when
a member authenticates himself by providing required information (user ID, password). The
system in turn verifies the user credentials using information stored in the members database.
If all information are not provided correctly, the user is shown a login failure message.
Otherwise, the user can continue with his operation. Note that a DFD does not show
conditional flows. It can only summarize the information flowing in and out of the system.
The data flow with the label "Requested book details" identify the information that the user
has to provide in order to issue a book. LIS checks with the books database whether the given
book is available. After a book has been issued, the transaction details is provided to the
member.
The level-1 DFD is shown in figure 2. Here, we split the top-level view of the system into
multiple logical components. Each process has a name, and a dotted-decimal number in the
form 1.x. For example, the process "Issue book" has the number 1.2, which indicates that in
the level 1 DFD the concerned process is numbered 2. Other processes are numbered in a
similar way.
Exercise:
1. Design a DFD for AMT transaction.
User registration
User login
Profile update
Draw a Level 1 DFD to depict the above data flow and the corresponding processes. Should
there be any data store in the DFD?
Solution:
Experiment No 4
Attributes of Entity
Attributes are the characteristics describing any entity belonging to an entity set. Any entity
in a set can be described by zero or more attributes.
For example, any student has got a name, age, an address. At any given time a student can
study only at one school. In the school he would have a roll number, and of course a grade in
which he studies. These data are the attributes of the entity set Student.
Keys
One or more attribute(s) of an entity set can be used to define the following keys:
Super key: One or more attributes, which when taken together, helps to uniquely identify an
entity in an entity set. For example, a school can have any number of students. However, if
we know grade and roll number, then we can uniquely identify a student in that school.
Candidate key: It is a minimal subset of a super key. In other words, a super key might
contain extraneous attributes, which do not help in identifying an object uniquely. When such
attributes are removed, the key formed so is called a candidate key.
Primary key: A database might have more than one candidate key. Any candidate key
chosen for a particular implementation of the database is called a primary key.
Weak Entity
An entity set is said to be weak if it is dependent upon another entity set. A weak entity can't
be uniquely identified only by it's attributes. In other words, it doesn't have a super key.
For example, consider a company that allows employees to have travel allowance for their
immediate family. So, here we have two entity sets: employee and family, related by "Can
claim for". However, family doesn't have a super key. Existence of a family is entirely
dependent on the concerned employee. So, it is meaningful only with reference to employee.
Mapping Cardinalities
One of the main tasks of ER modeling is to associate different entity sets. Let's consider two
entity sets E1 and E2 associated by a relationship set R. Based on the number of entities in
E1 and E2 are associated with, we can have the following four type of mappings:
One to one: An entity in E1 is related to at most a single entity in E2, and vice versa
One to many: An entity in E1 could be related to zero or more entities in E2. Any entity in
E2 could be related to at most a single entity in E1.
Many to one: Zero or more number of entities in E1 could be associated to a single entity in
E2. However, an entity in E2 could be related to at most one entity in E1.
Many to many: Any number of entities could be related to any number of entities in E2,
including zero, and vice versa.
ER Diagram
From a given problem statement we identify the possible entity sets, their attributes, and
relationships among different entity sets. Once we have these information, we represent them
pictorially, called an entity-relationship (ER) diagram.
Notation
Entity set
Attribute
Entity
attributes
with
Remarks
Name of the set is
written inside the
rectangle
Name of the attribute
is written inside the
ellipse
Roll is the primary
key; denoted with an
underline
Related
sets
Name
of
the
relationship is written
inside the diamond
enity
Relationship
cardinality
Relationship
with
weak
entity set
Importance of ER modeling
Figure - 01 shows the different steps involved in implementation of a (relational) database.
Exercise:
1. From the following problem statement identify the possible entity sets, their
attributes and relationships.
SE VLabs Inc. is a young company with a few departments spread across the country. As of
now, the company has a strength of 200+ employees.
Each employee works in a department. While joining, a person has to provide a lot of
personal and professional details including name, address, phone #, mail address, date of
birth, and so on. Once all these information are furnished, a unique ID is generated for each
employee. He is then assigned a department in which he will work.
There are around ten departments in the company. Unfortunately, two departments were
given same names. However, departments too have ID's, which are unique.
Solution:
Cab drivers are given a identification card while joining. The ID card contains his name,
permanent address, phone number, date of joining, duration of contract. Also, an unique
alphanumeric code is assigned to each number.
The agency provides service from 8 AM to 8 PM. Whenever any passenger books a cab, an
available cab is allocated for him. The booking receipt given to the passenger contains the car
#, source and destination places. Once he reaches the destination, he signs on a duplicate
copy of the receipt and gives back to the driver. Driver must submit this duplicate copy
signed by the passenger at the agency for confirmation.
To evaluate their quality of service, the agency also wants a (optional) customer satisfaction
survey, where passengers can provide feedback about their journey through the agency's
website.
Solution:
Experiment No 5
Objective: General study of UML
What is UML
Why the UML is necessary
How to represent UML components in diagrams
Theory:
Introduction
The heart of object-oriented problem solving is the construction of a model. The model
abstracts the essential details of the underlying problem from its usually complicated real world.
Several modeling tools are wrapped under the heading of the UML, which stands for Unified
Modeling Language. The purpose of this course is to present important highlights of the UML.
At the center of the UML are its nine kinds of modeling diagrams, which we describe here.
Actors are stick figures. Use cases are ovals. Communications are lines that link actors to use
cases.
A use case diagram is a collection of actors, use cases, and their communications. We've put
Make Appointment as part of a diagram with four actors and four use cases. Notice that a single use
case can have multiple actors.
determining features (requirements). New use cases often generate new requirements as
the system is analyzed and the design takes shape.
communicating with clients. Their notational simplicity makes use case diagrams a good
way for developers to communicate with clients.
generating test cases. The collection of scenarios for a use case may suggest a suite of test
cases for those scenarios.
Class diagrams
A Class diagram gives an overview of a system by showing its classes and the relationships
among them. Class diagrams are static -- they display what interacts but not what happens when they
do interact.
The class diagram below models a customer order from a retail catalog. The central class is
the Order. Associated with it are the Customer making the purchase and the Payment. A Payment
is one of three kinds: Cash, Check, or Credit. The order contains OrderDetails (line items), each
with its associated Item.
UML class notation is a rectangle divided into three parts: class name, attributes, and operations.
Names of abstract classes, such as Payment, are in italics. Relationships between classes are the
connecting links.
Our class diagram has three kinds of relationships.
An association has two ends. An end may have a role name to clarify the nature of the
association. For example, an OrderDetail is a line item of each Order.
A navigability arrow on an association shows which direction the association can be traversed or
queried. An OrderDetail can be queried about its Item, but not the other way around. The arrow also
lets you know who "owns" the association's implementation; in this case, OrderDetail has an Item.
Associations with no navigability arrows are bi-directional.
The multiplicity of an association end is the number of possible instances of the class associated
with a single instance of the other end. Multiplicities are single numbers or ranges of numbers. In our
example, there can be only one Customer for each Order, but a Customer can have any number of
Orders.
This table gives the most common multiplicities.
Multiplicities
0..1
0..* or *
1
1..*
Meaning
zero or one instance. The notation n . . m indicates n to m instances.
no limit on the number of instances (including none).
exactly one instance
at least one instance
Every class diagram has classes, associations, and multiplicities. Navigability and roles are optional
items placed in a diagram to provide clarity.
Packages and object diagrams
To simplify complex class diagrams, you can group classes into packages. A package is a
collection of logically related UML elements. The diagram below is a business model in which the
classes are grouped into packages.
Packages appear as rectangles with small tabs at the top. The package name is on the tab or
inside the rectangle. The dotted arrows are dependencies. One package depends on another if
changes in the other could possibly force changes in the first.
Object diagrams show instances instead of classes. They are useful for explaining small
pieces with complicated relationships, especially recursive relationships.
This small class diagram shows that a university Department can contain lots of other Departments.
The object diagram below instantiates the class diagram, replacing it by a concrete example.
Each rectangle in the object diagram corresponds to a single instance. Instance names are
underlined in UML diagrams. Class or instance names may be omitted from object diagrams as long
as the diagram meaning is still clear.
Sequence diagrams
Class and object diagrams are static model views. Interaction diagrams are dynamic. They
describe how objects collaborate.
A sequence diagram is an interaction diagram that details how operations are carried out -what messages are sent and when. Sequence diagrams are organized according to time. The time
progresses as you go down the page. The objects involved in the operation are listed from left to right
according to when they take part in the message sequence.
Below is a sequence diagram for making a hotel reservation. The object initiating the
sequence of messages is a Reservation window.
The Reservation window sends a makeReservation() message to a HotelChain. The
HotelChain then sends a makeReservation() message to a Hotel. If the Hotel has available rooms,
then it makes a Reservation and a Confirmation.
Each vertical dotted line is a lifeline, representing the time that an object exists. Each arrow is
a message call. An arrow goes from the sender to the top of the activation bar of the message on the
receiver's lifeline. The activation bar represents the duration of execution of the message.
In our diagram, the Hotel issues a self call to determine if a room is available. If so, then the
Hotel creates a Reservation and a Confirmation. The asterisk on the self call means iteration (to
make sure there is available room for each day of the stay in the hotel). The expression in square
brackets, [ ], is a condition.
Collaboration diagrams
Collaboration diagrams are also interaction diagrams. They convey the same information as
sequence diagrams, but they focus on object roles instead of the times that messages are sent. In a
sequence diagram, object roles are the vertices and messages are the connecting links.
The object-role rectangles are labeled with either class or object names (or both). Class names
are preceded by colons ( : ).
Each message in a collaboration diagram has a sequence number. The top-level message is
numbered 1. Messages at the same level (sent during the same call) have the same decimal prefix but
suffixes of 1, 2, etc. according to when they occur.
State chart diagrams
Objects have behaviors and state. The state of an object depends on its current activity or
condition. A statechart diagram shows the possible states of the object and the transitions that cause
a change in state.
Our example diagram models the login part of an online banking system. Logging in consists
of entering a valid social security number and personal id number, then submitting the information for
validation.
Logging in can be factored into four non-overlapping states: Getting SSN, Getting PIN,
Validating, and Rejecting. From each state comes a complete set of transitions that determine the
subsequent state.
States are rounded rectangles. Transitions are arrows from one state to another. Events or
conditions that trigger transitions are written beside the arrows. Our diagram has two self-transition,
one on Getting SSN and another on Getting PIN.
The initial state (black circle) is a dummy to start the action. Final states are also dummy
states that terminate the action.
The action that occurs as a result of an event or condition is expressed in the form /action.
While in its Validating state, the object does not wait for an outside event to trigger a transition.
Instead, it performs an activity. The result of that activity determines its subsequent state.
Activity diagrams
An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart
diagrams are related. While a statechart diagram focuses attention on an object undergoing a process
(or on a process as an object), an activity diagram focuses on the flow of activities involved in a
single process. The activity diagram shows the how those activities depend on one another.
Activity diagrams can be divided into object swimlanes that determine which object is
responsible for which activity. A single transition comes out of each activity, connecting it to the
next activity.
A transition may branch into two or more mutually exclusive transitions. Guard
expressions (inside [ ]) label the transitions coming out of a branch. A branch and its subsequent
merge marking the end of the branch appear in the diagram as hollow diamonds.
A transition may fork into two or more parallel activities. The fork and the subsequent join of the
threads coming out of the fork appear in the diagram as solid bars.
Component and deployment diagrams
A component is a code module. Component diagrams are physical analogs of class diagram.
Deployment diagrams show the physical configurations of software and hardware.
The following deployment diagram shows the relationships among software and hardware
components involved in real estate transactions.
Experiment No 6
Objective: UML Use Case Diagram
Draw the lines around the system and actors lie outside the system.
2.
3.
4.
Identify the functionality the way of interacting actors with system and specify the
behavior of actor.
5.
6.
7.
Se the relationship among the use cases and in between actor and use cases.
8.
9.
Purpose:
The purpose of use case diagram is to capture the dynamic aspect of a system. But this definition is
too generic to describe the purpose.
Because other four diagrams (activity, sequence, collaboration and Statechart) are also having the
same purpose. So we will look into some specific purpose which will distinguish it from other four
diagrams.
Use case diagrams are used to gather the requirements of a system including internal and external
influences. These requirements are mostly design requirements. So when a system is analyzed to
gather its functionalities use cases are prepared and actors are identified.
Now when the initial task is complete use case diagrams are modelled to present the outside view. So
in brief, the purposes of use case diagrams can be as follows:
Used to gather requirements of a system.
Used to get an outside view of a system.
Identify external and internal factors influencing the system.
Use case diagrams are considered for high level requirement analysis of a system. So when the
requirements of a system are analyzed the functionalities are captured in use cases.
So we can say that uses cases are nothing but the system functionalities written in an organized
manner. Now the second things which are relevant to the use cases are the actors. Actors can be
defined as something that interacts with the system.
The actors can be human user, some internal applications or may be some external applications. So in
a brief when we are planning to draw an use case diagram we should have the following items
identified.
Functionalities to be represented as an use case
Actors
Relationships among the use cases and actors.
Use case diagrams are drawn to capture the functional requirements of a system. So after
identifying the above items we have to follow the following guidelines to draw an efficient
use case diagram.
The name of a use case is very important. So the name should be chosen in such a way so that it can
identify the functionalities performed.
Give a suitable name for actors.
Show relationships and dependencies clearly in the diagram.
Do not try to include all types of relationships. Because the main purpose of the diagram is to identify
requirements.
Use note when ever required to clarify some important points.
The following is a sample use case diagram representing the order management system. So if
we look into the diagram then we will find three use cases (Order, Special Order and Normal
Order) and one actor which is customer.
The Special Order and Normal Order use cases are extended from Order use case. So they
have extends relationship. Another important point is to identify the system boundary which
is shown in the picture. The actor Customer lies outside the system as it is an external user of
the system.
Experiment No 7
Objective: UML Class Diagram
Study about
Class diagrams are the most popular UML diagrams used for construction of software
applications. So it is very important to learn the drawing procedure of class diagram.
Class diagrams have lot of properties to consider while drawing but here the diagram will be
considered from a top level view.
Class diagram is basically a graphical representation of the static view of the system and
represents different aspects of the application. So a collection of class diagrams represent the
whole system.
The following points should be remembered while drawing a class diagram:
The name of the class diagram should be meaningful to describe the aspect of the system.
So the following class diagram has been drawn considering all the points mentioned above:
EXPERIMENT NO. 8
Objective : Study of Object Diagram
Object diagrams are derived from class diagrams so object diagrams are dependent upon
class diagrams.
Object diagrams represent an instance of a class diagram. The basic concepts are similar for
class diagrams and object diagrams. Object diagrams also represent the static view of a
system but this static view is a snapshot of the system at a particular moment.
Object diagrams are used to render a set of objects and their relationships as an
instance.
Purpose:
The purpose of a diagram should be understood clearly to implement it practically. The
purposes of object diagrams are similar to class diagrams.
The difference is that a class diagram represents an abstract model consists of classes and
their relationships. But an object diagram represents an instance at a particular moment
which is concrete in nature.
It means the object diagram is more close to the actual system behaviour. The purpose is to
capture the static view of a system at a particular moment. So the purpose of the object diagram
can be summarized as:
relationships
of
system
Now after this the following things are to be decided before starting the construction of
the diagram:
The object diagram should have a meaningful name to indicate its purpose. The most important
elements are to be identified.
EXPERIMENT NO. 9
UML Component Diagram
Component diagrams are different in terms of nature and behaviour. Component
diagrams are used to model physical aspects of a system.
Now the question is what are these physical aspects? Physical aspects are the elements
like executables, libraries, files, documents etc which resides in a node.
So component diagrams are used to visualize the organization and relationships
among components in a system. These diagrams are also used to make executable systems.
Purpose:
Component diagram is a special kind of diagram in UML. The purpose is also different from
all other diagrams discussed so far. It does not describe the functionality of the system
but it describes the components used to make those functionalities.
So from that point component diagrams are used to visualize the physical components in a
system. These components are libraries, packages, files etc.
Component diagrams can also be described as a static implementation view of a system.
Static implementation represents the organization of the components at a particular moment. A
single component diagram cannot represent the entire system but a collection of diagrams are
used to represent the whole. So the purpose of the component diagram can be summarized as:
Visualize the components of a system.
Construct executables by using forward and reverse engineering.
Describe the organization and relationships of the components.
This diagram is very important because without it the application cannot be implemented efficiently. A
well prepared component diagram is also important for other aspects like application performance,
maintenance etc.
So before drawing a component diagram the following artifacts are to be identifiedclearly:
Files used in the system.
Libraries and other artifacts relevant to the application. Relationships among the artifacts.
Now after identifying the artifacts the following points needs to be followed:
Use a meaningful name to identify the component for which the diagram is to be drawn.
Prepare a mental layout before producing using tools.
Use notes for clarifying important points.
The following is a component diagram for order management system. Here the artifacts are
files. So the diagram shows the files in the application and their relationships. In actual
the component diagram also contains dlls, libraries, folders etc.
In the following diagram four files are identified and their relationships are produced.
Component diagram cannot be matched directly with other UML diagrams discussed so far.
Experiment No 10
UML Deployment Diagram
Deployment diagrams are used to visualize the topology of the physical components of a
system where the software components are deployed. So deployment diagrams are used to
describe the static deployment view of a system. Deployment diagrams consist of nodes
and their relationships.
Purpose:
The name Deployment itself describes the purpose of the diagram. Deployment diagrams
are used for describing the hardware components where software components are
deployed. Component diagrams and deployment diagrams are closely related. Component
diagrams are used to describe the components and deployment diagrams shows how they are
deployed in hardware.
UML is mainly designed to focus on software artifacts of a system. But these two diagrams
are special diagrams used to focus on software components and hardware components.
So most of the UML diagrams are used to handle logical components but deployment
diagrams are made to focus on hardware topology of a system. Deployment diagrams are
used by the system engineers.
The purpose of deployment diagrams
2.
3.
4.
5.
6.
7.
diagram.
How to draw Deployment Diagram? Deployment diagram represents the deployment view
of a system. It is related to the component diagram. Because the components are deployed using the
deployment diagrams. A deployment diagram consists of nodes. Nodes are nothing but physical
hardwares used to deploy the application.
Deployment diagrams are useful for system engineers. An efficient deployment diagram is very
important because it controls the following parameters
Performance
Scalability
Maintainability
Portability
The following deployment diagram is a sample to give an idea of the deployment view of order
management system. Here we have shown nodes as:
Monitor
Modem
Caching server
Server
The application is assumed to be a web based application which is deployed in a clustered
environment using server 1, server 2 and server 3. The user is connecting to the application using
internet. The control is flowing from the caching server to the clustered environment.
So the following deployment diagram has been drawn considering all the points mentioned above:
EXPERIMENT NO. 11
UML Interaction Diagram
From the name Interaction it is clear that the diagram is used to describe some type of
interactions among the different elements in the model. So this interaction is a part of
dynamic behaviour of the system.
This interactive behaviour is represented in UML by two diagrams known as Sequence
diagram and Collaboration diagram. The basic purposes of both the diagrams are similar.
Sequence diagram emphasizes on time sequence of messages and collaboration diagram
emphasizes on the structural organization of the objects that send and receive messages.
The purposes of interaction diagrams are to visualize the interactive behaviour of the system.
Now visualizing interaction is a difficult task. So the solution is to use different types of
models to capture the different aspects of the interaction.
That is why sequence and collaboration diagrams are used to capture dynamic nature but
from a different angle.
So the purposes of interaction diagram can be describes as:
Following are two interaction diagrams modelling order management system. The first
diagram is a sequence diagram and the second is a collaboration diagram.
The Sequence Diagram:
The sequence diagram is having four objects (Customer, Order, Special-order and Normal
Order).
The following diagram has shown the message sequence for Special-order object and the
same can be used in case of Normal Order object. Now it is important to understand the time
sequence of message flows. The message flow is nothing but a method call of an object.
The first call is sendOrder () which is a method of Order object. The next call is confirm ()
which is a method of SpecialOrder object and the last call is Dispatch () which is a method of
SpecialOrder object. So here the diagram is mainly describing the method calls from one
object to another and this is also the actual scenario when the system is running.
EXPERIMENT NO. 12
The Collaboration Diagram:
The second interaction diagram is collaboration diagram. It shows the object organization as
shown below. Here in collaboration diagram the method call sequence is indicated by some
numbering technique as shown below. The number indicates how the methods are called one
after another. We have taken the same order management system to describe the
collaboration diagram.
The method calls are similar to that of a sequence diagram. But the difference is that the
sequence diagram does not describe the object organization where as the collaboration
diagram shows the object organization.
Now to choose between these two diagrams the main emphasis is given on the type of
requirement. If the time sequence is important then sequence diagram is used and if
organization is required then collaboration diagram is used
Purpose:
Statechart diagram is one of the five UML diagrams used to model dynamic nature of a system. They
define different states of an object during its lifetime. And these states are changed by events. So
Statechart diagrams are useful to model reactive systems. Reactive systems can be defined as a
system that responds to external or internal events.
Statechart diagram describes the flow of control from one state to another state. States are defined as
a condition in which an object exists and it changes when some event is triggered. So the most
important purpose of Statechart diagram is to model life time of an object from creation to
termination.
Statechart diagrams are also used for forward and reverse engineering of a system. But the main
purpose is to model reactive system.
Following are the main purposes of using Statechart diagrams:
To model dynamic aspect of a system.
To model life time of a reactive system.
To describe different states of an object during its life time.
Define a state machine to model states of an object.
EXPERIMENT NO. 13
UML Activity Diagram
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 form 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
behavior 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.
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:
After receiving the order request condition checks are performed to check if it is normal or
special order. After the type of order is