1. Study and implementation of class diagrams.

Class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing, and documenting different
aspects of a system but also for constructing executable code of the software
application.
Class diagram describes the attributes and operations of a class and also the
constraints imposed on the system. The class diagrams are widely used in the
modeling of objectoriented systems because they are the only UML diagrams, which
can be mapped directly with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations,
and constraints. It is also known as a structural diagram.

Class diagram For Library Management System:

Refer one example of library management system:

Purpose of Class Diagrams
The purpose of class diagram is to model the static view of an application. Class
diagrams are the only diagrams which can be directly mapped with object-oriented
languages and thus widely used at the time of construction.
UML diagrams like activity diagram, sequence diagram can only give the sequence
flow of the application, however class diagram is a bit different. It is the most popular
UML diagram in the coder community.
The purpose of the class diagram can be summarized as −
• Analysis and design of the static view of an application.
• Describe responsibilities of a system.
• Base for component and deployment diagrams.
• Forward and reverse engineering.

How to Draw a Class Diagram?

Class diagrams are the most popular UML diagrams used for construction of software
applications. It is very important to learn the drawing procedure of class diagram.
Class diagrams have a 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. 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.
• Each element and their relationships should be identified in advance.
• Responsibility (attributes and methods) of each class should be clearly identified
• For each class, minimum number of properties should be specified, as unnecessary
properties will make the diagram complicated.
• Use notes whenever required to describe some aspect of the diagram. At the end of the
drawing it should be understandable to the developer/coder.
• Finally, before making the final version, the diagram should be drawn on plain paper and
reworked as many times as possible to make it correct.
The following diagram is an example of an Order System of an application. It
describes a particular aspect of the entire application.
• First of all, Order and Customer are identified as the two elements of the system. They
have a one-to-many relationship because a customer can have multiple orders.
 • Order class is an abstract class and it has two concrete classes (inheritance relationship)
SpecialOrder and NormalOrder.
• The two inherited classes have all the properties as the Order class. In addition, they have
additional functions like dispatch () and receive ().
The following class diagram has been drawn considering all the points mentioned
above.

Where to Use Class Diagrams?

Class diagram is a static diagram and it is used to model the static view of a system.
The static view describes the vocabulary of the system.
Class diagram is also considered as the foundation for component and deployment
diagrams. Class diagrams are not only used to visualize the static view of the system
but they are also used to construct the executable code for forward and reverse
engineering of any system.
Generally, UML diagrams are not directly mapped with any object-oriented
programming languages but the class diagram is an exception.
Class diagram clearly shows the mapping with object-oriented languages such as
Java, C++, etc. From practical experience, class diagram is generally used for
construction purpose.
In a nutshell it can be said, class diagrams are used for −
• Describing the static view of the system.
 • Showing the collaboration among the elements of the static view.
• Describing the functionalities performed by the system.
• Construction of software applications using object oriented languages.

2. Study and implementation of Use Case Diagrams.

To model a system, the most important aspect is to capture the dynamic behavior.
Dynamic behavior means the behavior of the system when it is running/operating.
Only static behavior is not sufficient to model a system rather dynamic behavior is
more important than static behavior. In UML, there are five diagrams available to
model the dynamic nature and use case diagram is one of them. Now as we have to
discuss that the use case diagram is dynamic in nature, there should be some internal
or external factors for making the interaction.
These internal and external agents are known as actors. Use case diagrams consists
of actors, use cases and their relationships. The diagram is used to model the
system/subsystem of an application. A single use case diagram captures a particular
functionality of a system.
Hence to model the entire system, a number of use case diagrams are used.

Use case diagram of Library management System:

Purpose of Use Case Diagrams
The purpose of use case diagram is to capture the dynamic aspect of a system.
However, this definition is too generic to describe the purpose, as other four diagrams
(activity, sequence, collaboration, and Statechart) also have the same purpose. 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. Hence,
when a system is analyzed to gather its functionalities, use cases are prepared and
actors are identified.
When the initial task is complete, use case diagrams are modelled to present the
outside view.
In brief, the purposes of use case diagrams can be said to be as follows −
• Used to gather the requirements of a system.
• Used to get an outside view of a system.
• Identify the external and internal factors influencing the system.
• Show the interaction among the requirements are actors.

How to Draw a Use Case Diagram?

Use case diagrams are considered for high level requirement analysis of a system.
When the requirements of a system are analyzed, the functionalities are captured in
use cases.
We can say that use cases are nothing but the system functionalities written in an
organized manner. The second thing which is relevant to use cases are the actors.
Actors can be defined as something that interacts with the system.
Actors can be a human user, some internal applications, or may be some external
applications. When we are planning to draw a use case diagram, we should have the
following items identified.
• Functionalities to be represented as use case
• Actors
• Relationships among the use cases and actors.
Use case diagrams are drawn to capture the functional requirements of a system.
After identifying the above items, we have to use the following guidelines to draw an
efficient use case diagram
• The name of a use case is very important. 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, as the main purpose of the diagram is to
identify the requirements.
• Use notes whenever required to clarify some important points.
Following is a sample use case diagram representing the order management system.
Hence, if we look into the diagram then we will find three use cases (Order,
SpecialOrder, and NormalOrder) and one actor which is the customer.
The SpecialOrder and NormalOrder use cases are extended from Order use case.
Hence, they have extended 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.

Where to Use a Use Case Diagram?

As we have already discussed there are five diagrams in UML to model the dynamic
view of a system. Now each and every model has some specific purpose to use.
Actually these specific purposes are different angles of a running system.
To understand the dynamics of a system, we need to use different types of diagrams.
Use case diagram is one of them and its specific purpose is to gather system
requirements and actors.
Use case diagrams specify the events of a system and their flows. But use case
diagram never describes how they are implemented. Use case diagram can be
imagined as a black box where only the input, output, and the function of the black
box is known.
These diagrams are used at a very high level of design. This high level design is
refined again and again to get a complete and practical picture of the system. A well-
structured use case also describes the pre-condition, post condition, and exceptions.
These extra elements are used to make test cases when performing the testing.
Although use case is not a good candidate for forward and reverse engineering, still
they are used in a slightly different way to make forward and reverse engineering.
The same is true for reverse engineering. Use case diagram is used differently to
make it suitable for reverse engineering.
In forward engineering, use case diagrams are used to make test cases and in
reverse engineering use cases are used to prepare the requirement details from the
existing application.
Use case diagrams can be used for −
• Requirement analysis and high level design.
• Model the context of a system.
• Reverse engineering.
• Forward engineering.

3. Study and implementation of Entity Relationship Diagrams.

ER Diagram for Library management System:

Customers, employees, cards, media, and library branches – correspond to entities

in the Entity-Relationship model, and the operations to be done on those entities –
holds, checkouts, and so on– correspond to relationships. However, a good design
will minimize redundancy and attempt to store all the required information in as
small a space as possible.
 Notice that the information about books and videos has been separated from the Media
entity. This allows the database to store multiple copies of the same item without
redundancy. The Status entity has also been separated from Media in order to save
space. The Hold relationship stores the entry's place in line (denoted by "queue"); it
can be used to create a waiting list of interested customers. The Librarian entity is
functionally an extension to Customer, so each Librarian also has a customer
associated with it. The librarians will have access to the same features as customers,
but they will also perform administrative functions, such as checking media in and out
and updating customers' fines.

Physical database Design:

(Please refer ER Design and accordingly Table design)

The next step was to create the physical database and input some sample data. In order
to turn the relational design into a database, we ran the following script in UNCC's
Oracle database:

CREATE TABLE Status ( code INTEGER, description CHAR(30),

PRIMARY KEY (code) ); CREATE TABLE Media( media_id INTEGER,
code INTEGER, PRIMARY KEY (media_id),

FOREIGN KEY (code) REFERENCES Status );

CREATE TABLE Book(ISBNCHAR(14), title CHAR(128),

author CHAR(64), year INTEGER, dewey INTEGER,
price REAL, PRIMARY KEY (ISBN) );
CREATE TABLE BookMedia( media_id INTEGER, ISBN CHAR(14),
PRIMARY KEY (media_id), FOREIGN KEY (media_id)
REFERENCES Media,

FOREIGN KEY (ISBN) REFERENCES Book);

CREATE TABLE Customer( ID INTEGER, name CHAR(64), addr

CHAR(256), DOB CHAR(10), phone CHAR(30), username
CHAR(16), password CHAR(32), PRIMARY KEY (ID), UNIQUE
(username) );

CREATE TABLE Card( num INTEGER, fines REAL, ID INTEGER,

PRIMARY KEY (num), FOREIGN KEY (ID)
REFERENCES Customer );

CREATE TABLE Checkout( media_id INTEGER, num

INTEGER, since CHAR(10), until CHAR(10),
PRIMARY KEY (media_id),

FOREIGN KEY (media_id) REFERENCES Media,

FOREIGN KEY (num) REFERENCES Card );

CREATE TABLE Location( name CHAR(64), addr

CHAR(256), phone CHAR(30), PRIMARY KEY (name)
);

CREATE TABLE Hold( media_id INTEGER, num INTEGER, name

CHAR(64), until CHAR(10), queue INTEGER, PRIMARY KEY
(media_id, num),

FOREIGN KEY (name) REFERENCES Location,

FOREIGN KEY (num) REFERENCES Card,

FOREIGN KEY (media_id) REFERENCES Media );

CREATE TABLE Stored_In( media_id INTEGER, name char(64), PRIMARY KEY

(media_id),
 FOREIGN KEY (media_id) REFERENCES Media
ON DELETE CASCADE, FOREIGN KEY (name)
REFERENCES Location );

CREATE TABLE Librarian( eid INTEGER, ID INTEGER

NOT NULL, Pay REAL, Loc_name CHAR(64) NOT
NULL, PRIMARY KEY (eid),

FOREIGN KEY (ID) REFERENCES Customer

ON DELETE CASCADE, FOREIGN KEY
(Loc_name) REFERENCES Location(name) );

CREATE TABLE Video( title CHAR(128), year INTEGER,

director CHAR(64), rating REAL, price REAL,
PRIMARY KEY (title, year) );

CREATE TABLE VideoMedia( media_id INTEGER, title

CHAR(128), year INTEGER, PRIMARY KEY (media_id),
FOREIGN KEY (media_id) REFERENCES Media,
FOREIGN KEY (title, year) REFERENCES Video );

The next script populated the database with sample data:

INSERT INTO Customer(ID, name, addr, DOB, phone, username,

password) VALUES (60201, 'Jason L. Gray', '2087 Timberbrook
Lane, Gypsum, CO 81637', '09/09/1958', '970-273-9237',
'jlgray', 'password1');

INSERT INTO Customer(ID, name, addr, DOB, phone, username,

password) VALUES (89682, 'Mary L. Prieto', '1465 Marion
Drive, Tampa, FL 33602', '11/20/1961', '813-487-4873',
'mlprieto', 'password2');

INSERT INTO Customer(ID, name, addr, DOB, phone, username, password) VALUES
(64937, 'Roger Hurst', '974 Bingamon Branch Rd, Bensenville, IL
60106', '08/22/1973', '847-221-4986', 'rhurst', 'password3');
INSERT INTO Customer(ID, name, addr, DOB, phone, username,
password) VALUES (31430, 'Warren V. Woodson', '3022
Lords Way, Parsons, TN 38363', '03/07/1945', '731-845-0077',
'wvwoodson', 'password4');

INSERT INTO Customer(ID, name, addr, DOB, phone, username,

password) VALUES (79916, 'Steven Jensen', '93 Sunny Glen Ln,
Garfield Heights, OH 44125', '12/14/1968', '216-789-6442',
'sjensen', 'password5');

INSERT INTO Customer(ID, name, addr, DOB, phone, username,

password) VALUES (93265, 'David Bain', '4356 Pooh Bear Lane,
Travelers Rest, SC 29690', '08/10/1947', '864-610-9558', 'dbain',
'password6');

INSERT INTO Customer(ID, name, addr, DOB, phone, username,

password) VALUES (58359, 'Ruth P. Alber', '3842 Willow Oaks
Lane, Lafayette, LA 70507', '02/18/1976', '337-316-3161',
'rpalber', 'password7');

INSERT INTO Customer(ID, name, addr, DOB, phone, username,

password) VALUES (88564, 'Sally J. Schilling', '1894 Wines
Lane, Houston, TX 77002', '07/02/1954', '832-366-9035',
'sjschilling', 'password8');

INSERT INTO Customer(ID, name, addr, DOB, phone, username,

password) VALUES (57054, 'John M. Byler', '279 Raver Croft
Drive, La Follette, TN 37766', '11/27/1954', '423-592-8630',
'jmbyler', 'password9');

INSERT INTO Customer(ID, name, addr, DOB, phone, username,

password) VALUES (49312, 'Kevin Spruell', '1124 Broadcast
Drive, Beltsville, VA 20705', '03/04/1984', '703-953-1216',
'kspruell', 'password10');

INSERT INTO Card(num, fines, ID) VALUES ( 5767052, 0.0, 60201);

INSERT INTO Card(num, fines, ID) VALUES ( 5532681, 0.0, 60201);

INSERT INTO Card(num, fines, ID) VALUES ( 2197620, 10.0, 89682);

INSERT INTO Card(num, fines, ID) VALUES ( 9780749, 0.0, 64937);

INSERT INTO Card(num, fines, ID) VALUES ( 1521412, 0.0, 31430);

INSERT INTO Card(num, fines, ID) VALUES ( 3920486, 0.0, 79916);

INSERT INTO Card(num, fines, ID) VALUES ( 2323953, 0.0, 93265);

INSERT INTO Card(num, fines, ID) VALUES ( 4387969, 0.0, 58359);

INSERT INTO Card(num, fines, ID) VALUES ( 4444172, 0.0, 88564);

INSERT INTO Card(num, fines, ID) VALUES ( 2645634, 0.0, 57054);

INSERT INTO Card(num, fines, ID) VALUES ( 3688632, 0.0, 49312);

INSERT INTO Location(name, addr, phone) VALUES

('Texas Branch', '4832 Deercove Drive, Dallas, TX
75208', '214-948-7102');

INSERT INTO Location(name, addr, phone) VALUES

('Illinois Branch', '2888 Oak Avenue, Des Plaines, IL 60016',
'847-953-8130');

INSERT INTO Location(name, addr, phone) VALUES

('Louisiana Branch', '2063 Washburn Street, Baton Rouge,

LA 70802', '225-346-0068');

INSERT INTO Status(code, description) VALUES (1,

'Available'); INSERT INTO Status(code, description)
VALUES (2, 'In Transit'); INSERT INTO Status(code,
description) VALUES (3, 'Checked Out'); INSERT INTO
Status(code, description) VALUES (4, 'On Hold');
INSERT INTO Media( media_id, code) VALUES (8733, 1);

INSERT INTO Media( media_id, code) VALUES (9982, 1);

INSERT INTO Media( media_id, code) VALUES (3725, 1);

INSERT INTO Media( media_id, code) VALUES (2150, 1);

INSERT INTO Media( media_id, code) VALUES (4188, 1);

INSERT INTO Media( media_id, code) VALUES (5271, 2);

INSERT INTO Media( media_id, code) VALUES (2220, 3);

INSERT INTO Media( media_id, code) VALUES (7757, 1);

INSERT INTO Media( media_id, code) VALUES (4589, 1);

INSERT INTO Media( media_id, code) VALUES (5748, 1);

11

INSERT INTO Media( media_id, code) VALUES (1734, 1);

INSERT INTO Media( media_id, code) VALUES (5725, 1);

INSERT INTO Media( media_id, code) VALUES (1716, 4);

INSERT INTO Media( media_id, code) VALUES (8388, 1);

INSERT INTO Media( media_id, code) VALUES (8714, 1);

INSERT INTO Book(ISBN, title, author, year, dewey,

price) VALUES ('978-0743289412', 'Lisey''s Story',
'Stephen King', 2006, 813, 10.0);
INSERT INTO Book(ISBN, title, author, year, dewey,
price) VALUES ('978-1596912366', 'Restless: A
Novel', 'William Boyd', 2006, 813, 10.0);

INSERT INTO Book(ISBN, title, author, year, dewey,

price) VALUES ('978-0312351588', 'Beachglass',
'Wendy Blackburn', 2006, 813, 10.0);

INSERT INTO Book(ISBN, title, author, year, dewey, price)

VALUES ('978-0156031561', 'The Places In Between',
'Rory Stewart', 2006, 910, 10.0);

INSERT INTO Book(ISBN, title, author, year, dewey,

price) VALUES ('978-0060583002', 'The Last
Season', 'Eric Blehm', 2006, 902, 10.0);

INSERT INTO Book(ISBN, title, author, year, dewey, price)

VALUES ('978-0316740401', 'Case Histories: A Novel',
'Kate Atkinson', 2006, 813, 10.0);

INSERT INTO Book(ISBN, title, author, year, dewey, price)

VALUES ('978-0316013949', 'Step on a Crack', 'James
Patterson, et al.', 2007, 813, 10.0);

INSERT INTO Book(ISBN, title, author, year, dewey, price)

VALUES ('978-0374105235', 'Long Way Gone:
Memoirs of a Boy Soldier',

'Ishmael Beah', 2007, 916, 10.0);

INSERT INTO Book(ISBN, title, author, year, dewey, price)

VALUES ('978-0385340229', 'Sisters', 'Danielle Steel', 2006,

813, 10.0);

INSERT INTO BookMedia(media_id, ISBN) VALUES (8733,

'978-0743289412'); INSERT INTO BookMedia(media_id, ISBN)
VALUES (9982, '978-1596912366'); INSERT INTO
BookMedia(media_id, ISBN) VALUES (3725, '978-
1596912366'); INSERT INTO BookMedia(media_id, ISBN)
VALUES (2150, '978-0312351588'); INSERT INTO
BookMedia(media_id, ISBN) VALUES (4188, '978-
0156031561'); INSERT INTO BookMedia(media_id, ISBN)
VALUES (5271, '978-0060583002'); INSERT INTO
BookMedia(media_id, ISBN) VALUES (2220, '978-
0316740401'); INSERT INTO BookMedia(media_id, ISBN)
VALUES (7757, '978-0316013949'); INSERT INTO
BookMedia(media_id, ISBN) VALUES (4589, '978-
0374105235'); INSERT INTO BookMedia(media_id, ISBN)
VALUES (5748, '978-0385340229');

INSERT INTO Checkout(media_id, num, since, until) VALUES

(2220, 9780749, '02/15/2007', '03/15/2007');

INSERT INTO Video(title, year, director, rating, price) VALUES

('Terminator 2: Judgment Day', 1991, 'James Cameron', 8.3,
20.0);

INSERT INTO Video(title, year, director, rating, price) VALUES

('Raiders of the Lost Ark', 1981, 'Steven Spielberg', 8.7, 20.0);

INSERT INTO Video(title, year, director, rating, price)

VALUES ('Aliens', 1986, 'James Cameron', 8.3,
20.0);

INSERT INTO Video(title, year, director, rating, price)

VALUES ('Die Hard', 1988, 'John McTiernan',

8.0, 20.0);

INSERT INTO VideoMedia(media_id, title,

year) VALUES ( 1734, 'Terminator 2: Judgment

Day', 1991);
INSERT INTO VideoMedia(media_id, title, year) VALUES

( 5725, 'Raiders of the Lost Ark', 1981);

INSERT INTO VideoMedia(media_id, title,
year) VALUES
( 1716, 'Aliens', 1986);

INSERT INTO VideoMedia(media_id, title, year) VALUES

( 8388, 'Aliens', 1986);

INSERT INTO VideoMedia(media_id, title, year) VALUES

( 8714, 'Die Hard', 1988);

INSERT INTO Hold(media_id, num, name, until,

queue) VALUES (1716, 4444172, 'Texas

Branch', '02/20/2008', 1);

INSERT INTO Librarian(eid, ID, pay,

Loc_name) Values (2591051, 88564,
30000.00, 'Texas Branch');

INSERT INTO Librarian(eid, ID, pay,

Loc_name) Values (6190164, 64937,
30000.00, 'Illinois Branch');

INSERT INTO Librarian(eid, ID, pay, Loc_name)

Values (1810386, 58359, 30000.00,

'Louisiana Branch');

INSERT INTO Stored_In(media_id, name) VALUES(8733, 'Texas

Branch'); INSERT INTO Stored_In(media_id, name)
VALUES(9982, 'Texas Branch'); INSERT INTO
 Stored_In(media_id, name) VALUES(1716, 'Texas Branch');
INSERT INTO Stored_In(media_id, name) VALUES(1734, 'Texas
Branch'); INSERT INTO Stored_In(media_id, name)
VALUES(4589, 'Texas Branch'); INSERT INTO
Stored_In(media_id, name) VALUES(4188, 'Illinois Branch');
INSERT INTO Stored_In(media_id, name) VALUES(5271,
'Illinois Branch'); INSERT INTO Stored_In(media_id, name)
VALUES(3725, 'Illinois Branch'); INSERT INTO
Stored_In(media_id, name) VALUES(8388, 'Illinois Branch');
INSERT INTO Stored_In(media_id, name) VALUES(5748,
'Illinois Branch'); INSERT INTO Stored_In(media_id, name)
VALUES(2150, 'Louisiana Branch'); INSERT INTO
Stored_In(media_id, name) VALUES(8714, 'Louisiana Branch');
INSERT INTO Stored_In(media_id, name) VALUES(7757,
'Louisiana Branch'); INSERT INTO Stored_In(media_id, name)
VALUES(5725, 'Louisiana Branch');

4. Study and implementation of Sequence diagram.

Sequence diagram is the most common kind of interaction diagram, which focuses on
the message interchange between a number of lifelines. Sequence diagram describes an
interaction by focusing on the sequence of messages that are exchanged, along with their
corresponding occurrence specifications on the lifelines.
From the term Interaction, it is clear that the diagram is used to describe some type of
interactions among the different elements in the model. This interaction is a part of dynamic
behavior of the system.
This interactive behavior is represented in UML by two diagrams known as Sequence
diagram and Collaboration diagram. The basic purpose 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.

Purpose of Interaction Diagrams

The purpose of interaction diagrams is to visualize the interactive behavior of the system.
Visualizing the interaction is a difficult task. Hence, the solution is to use different types of
models to capture the different aspects of the interaction.
Sequence and collaboration diagrams are used to capture the dynamic nature but from a
different angle.
The purpose of interaction diagram is −
• To capture the dynamic behaviour of a system.
• To describe the message flow in the system.
• To describe the structural organization of the objects.
• To describe the interaction among objects.

How to Draw an Interaction Diagram?

As we have already discussed, the purpose of interaction diagrams is to capture the dynamic
aspect of a system. So to capture the dynamic aspect, we need to understand what a dynamic
aspect is and how it is visualized. Dynamic aspect can be defined as the snapshot of the
running system at a particular moment
We have two types of interaction diagrams in UML. One is the sequence diagram and the
other is the collaboration diagram. The sequence diagram captures the time sequence of the
message flow from one object to another and the collaboration diagram describes the
organization of objects in a system taking part in the message flow.
Following things are to be identified clearly before drawing the interaction diagram
• Objects taking part in the interaction.
• Message flows among the objects.
• The sequence in which the messages are flowing.
• Object organization.
Following are two interaction diagrams modeling the order management system. The first
diagram is a sequence diagram and the second is a collaboration diagram

The Sequence Diagram

The sequence diagram has four objects (Customer, Order, SpecialOrder and NormalOrder).
The following diagram shows the message sequence for SpecialOrder object and the same
can be used in case of NormalOrder object. 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. The following diagram mainly describes the method calls from one
object to another, and this is also the actual scenario when the system is running.

Where to Use Interaction Diagrams?

We have already discussed that interaction diagrams are used to describe the dynamic nature
of a system. Now, we will look into the practical scenarios where these diagrams are used. To
understand the practical application, we need to understand the basic nature of sequence and
collaboration diagram.
The main purpose of both the diagrams are similar as they are used to capture the dynamic
behaviour of a system. However, the specific purpose is more important to clarify and
understand.
Sequence diagrams are used to capture the order of messages flowing from one object to
another. Collaboration diagrams are used to describe the structural organization of the objects
taking part in the interaction. A single diagram is not sufficient to describe the dynamic aspect
of an entire system, so a set of diagrams are used to capture it as a whole.
Interaction diagrams are used when we want to understand the message flow and the structural
organization. Message flow means the sequence of control flow from one object to another.
Structural organization means the visual organization of the elements in a system.
Interaction diagrams can be used −
• To model the flow of control by time sequence.
 • To model the flow of control by structural organizations.
• For forward engineering.
• For reverse engineering.

Sequence diagram for library management system:

5. Study and implementation of State Transition Diagrams.
The name of the diagram itself clarifies the purpose of the diagram and other details. It
describes different states of a component in a system. The states are specific to a
component/object of a system.
A Statechart diagram describes a state machine. State machine can be defined as a machine
which defines different states of an object and these states are controlled by external or internal
events.
Activity diagram explained in the next chapter, is a special kind of a Statechart diagram. As
Statechart diagram defines the states, it is used to model the lifetime of an object.

Purpose of Statechart Diagrams

Statechart diagram is one of the five UML diagrams used to model the dynamic nature of a
system. They define different states of an object during its lifetime and these states are
changed by events. Statechart diagrams are useful to model the 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.
The most important purpose of Statechart diagram is to model lifetime of an object from
creation to termination.
Statechart diagrams are also used for forward and reverse engineering of a system. However,
the main purpose is to model the reactive system.
Following are the main purposes of using Statechart diagrams −
• To model the dynamic aspect of a system.
• To model the life time of a reactive system.
• To describe different states of an object during its life time.
• Define a state machine to model the states of an object.

How to Draw a Statechart Diagram?

Statechart diagram is used to describe the states of different objects in its life cycle. Emphasis
is placed 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 should clarify the following points −
• Identify the important objects to be analyzed.
• Identify the states.
 • Identify the events.
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
the 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 exits. This abnormal exit may occur due to some problem in the
system. When the entire life cycle is complete, it is considered as a complete transaction as
shown in the following figure. The initial and final state of an object is also shown in the
following figure.

Where to Use Statechart Diagrams?

From the above discussion, we can define the practical applications of a Statechart diagram.
Statechart diagrams are used to model the dynamic aspect of a system like other four diagrams
discussed in this tutorial. However, it has some distinguishing characteristics for modeling the
dynamic nature.
Statechart diagram defines the states of a component and these state changes are dynamic in
nature. Its specific purpose is to define the state changes triggered by events. Events are
internal or external factors influencing the system.
Statechart diagrams are used to model the states and also the events operating on the system.
When implementing a system, it is very important to clarify different states of an object during
its life time and Statechart diagrams are used for this purpose. When these states and events
are identified, they are used to model it and these models are used during the implementation
of the system.
If we look into the practical implementation of Statechart diagram, then it is mainly used to
analyze the object states influenced by events. This analysis is helpful to understand the
system behavior during its execution.
The main usage can be described as −
• To model the object states of a system.
• To model the reactive system. Reactive system consists of reactive objects.
• To identify the events responsible for state changes.
• Forward and reverse engineering.

State-chart diagram for Library management system:

6. Study and implementation of Data Flow Diagrams.

Data Flow Diagram

Data flow diagram is graphical representation of flow of data in an information system. It is

capable of depicting incoming data flow, outgoing data flow and stored data. The DFD does
not mention anything about how data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of
control in program modules. DFDs depict flow of data in the system at various levels. DFD
does not contain any control or branch elements.

Types of DFD
Data Flow Diagrams are either Logical or Physical.

• Logical DFD - This type of DFD concentrates on the system process, and flow of
data in the system.For example in a Banking software system, how data is moved
between different entities.
• Physical DFD - This type of DFD shows how the data flow is actually implemented
in the system. It is more specific and close to the implementation.
DFD Components
DFD can represent Source, destination, storage and flow of data using the following set of
components -

• Entities - Entities are source and destination of information data. Entities are
represented by a rectangles with their respective names.
• Process - Activities and action taken on the data are represented by Circle or Round-
edged rectangles.
• Data Storage - There are two variants of data storage - it can either be represented as
a rectangle with absence of both smaller sides or as an open-sided rectangle with only
one side missing.
• Data Flow - Movement of data is shown by pointed arrows. Data movement is shown
from the base of arrow as its source towards head of the arrow as destination.
Levels of DFD

• Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the
entire information system as one diagram concealing all the underlying details. Level
0 DFDs are also known as context level DFDs.
• Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1
DFD depicts basic modules in the system and flow of data among various modules.
Level 1 DFD also mentions basic processes and sources of information.

• Level 2 - At this level, DFD shows how data flows inside the modules mentioned in
Level 1.
Higher level DFDs can be transformed into more specific lower level DFDs with
deeper level of understanding unless the desired level of specification is achieved.
DFD for Library Management System
DFD for few interaction in Hospital Management System
7. Study and implementation of Collaboration Diagrams.

The Collaboration Diagram

It shows the object organization as seen in the following diagram. In the collaboration
diagram, the method call sequence is indicated by some numbering technique. The number
indicates how the methods are called one after another. We have taken the same order
management system to describe the collaboration diagram.
Method calls are similar to that of a sequence diagram. However, difference being the
sequence diagram does not describe the object organization, whereas the collaboration
diagram shows the object organization.
To choose between these two diagrams, emphasis is placed on the type of requirement. If the
time sequence is important, then the sequence diagram is used. If organization is required,
then collaboration diagram is used.

Drawbacks of a Collaboration Diagram

• Collaboration diagrams can become complex when too many objects are present
within the system.
• It is hard to explore each object inside the system.
• Collaboration diagrams are time consuming.
• The object is destroyed after the termination of a program.
• The state of an object changes momentarily, which makes it difficult to keep track of
every single change the occurs within an object of a system.

Collaboration diagram Example

Following diagram represents the sequencing over student management system:

 Collaboration diagram for student management system

The above collaboration diagram represents a student information management system. The
flow of communication in the above diagram is given by,

1. A student requests a login through the login system.

2. An authentication mechanism of software checks the request.
3. If a student entry exists in the database, then the access is allowed; otherwise, an error
is returned.

Collaboration diagram for Library Management System

8. Study and implementation of Activity Diagrams.
Activity diagram is another important diagram in UML to describe the dynamic aspects of the
system.
Activity diagram is basically a flowchart to represent the flow from one activity to another
activity. The activity can be described as an operation of the system.
The control flow is drawn from one operation to another. This flow can be sequential,
branched, or concurrent. Activity diagrams deal with all type of flow control by using different
elements such as fork, join, etc

Purpose of Activity Diagrams

The basic purposes of activity diagrams is 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 the 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 the
activity diagram is the message part.
It does not show any message flow from one activity to another. Activity diagram is
sometimes considered as the flowchart. Although the diagrams look like a flowchart, they are
not. It shows different flows such as parallel, branched, concurrent, and single.
The purpose of an activity diagram 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 an Activity Diagram?

Activity diagrams are mainly used as a flowchart that consists of activities performed by the
system. Activity diagrams are not exactly flowcharts 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.
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.
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 is mainly used by the business
users
Following diagram is drawn with the four main activities −
• Send order by the customer
• Receipt of the order
• Confirm the order
• Dispatch the 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.
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 the 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.
We will now 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. The
diagram has more impact on business understanding rather than on implementation details.
Activity diagram can be used for −
• Modeling work flow by using activities.
• Modeling business requirements.
• High level understanding of the system's functionalities.
• Investigating business requirements at a later stage.

Activity Diagram Library Management System:

9. Study and implementation of Component Diagrams:
Component diagrams are different in terms of nature and behavior. Component diagrams are
used to model the physical aspects of a system. Now the question is, what are these physical
aspects? Physical aspects are the elements such as executables, libraries, files, documents, etc.
which reside in a node.
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 of Component Diagrams

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.
Thus from that point of view, 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
is used to represent the whole.
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.

How to Draw a Component Diagram?

Component diagrams are used to describe the physical artifacts of a system. This artifact
includes files, executables, libraries, etc
The purpose of this diagram is different. Component diagrams are used during the
implementation phase of an application. However, it is prepared well in advance to visualize
the implementation details.
Initially, the system is designed using different UML diagrams and then when the artifacts are
ready, component diagrams are used to get an idea of the implementation.
This diagram is very important as without it the application cannot be implemented efficiently.
A well-prepared component diagram is also important for other aspects such as application
performance, maintenance, etc.
Before drawing a component diagram, the following artifacts are to be identified clearly −
• Files used in the system.
• Libraries and other artifacts relevant to the application.
 • Relationships among the artifacts.
After identifying the artifacts, the following points need to be kept in mind.
• Use a meaningful name to identify the component for which the diagram is to be drawn.
• Prepare a mental layout before producing the using tools.
• Use notes for clarifying important points.
Following is a component diagram for order management system. Here, the artifacts are files.
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
as it is drawn for completely different purpose.
The following component diagram has been drawn considering all the points mentioned
above.

Where to Use Component Diagrams?

We have already described that component diagrams are used to visualize the static
implementation view of a system. Component diagrams are special type of UML diagrams
used for different purposes.
These diagrams show the physical components of a system. To clarify it, we can say that
component diagrams describe the organization of the components in a system.
Organization can be further described as the location of the components in a system. These
components are organized in a special way to meet the system requirements.
As we have already discussed, those components are libraries, files, executables, etc. Before
implementing the application, these components are to be organized. This component
organization is also designed separately as a part of project execution.
Component diagrams are very important from implementation perspective. Thus, the
implementation team of an application should have a proper knowledge of the component
details
Component diagrams can be used to −
• Model the components of a system.
• Model the database schema.
• Model the executables of an application.
• Model the system's source code.

Component diagram for Library management system

10. Study and implementation of Deployment Diagrams.
Deployment diagrams are used to visualize the topology of the physical components of a
system, where the software components are deployed.
Deployment diagrams are used to describe the static deployment view of a system.
Deployment diagrams consist of nodes and their relationships.

Purpose of Deployment Diagrams

The term 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 the software artifacts of a system. However, these two
diagrams are special diagrams used to focus on software and hardware components.
Most of the UML diagrams are used to handle logical components but deployment diagrams
are made to focus on the hardware topology of a system. Deployment diagrams are used by
the system engineers.
The purpose of deployment diagrams can be described as −
• Visualize the hardware topology of a system.
• Describe the hardware components used to deploy software components.
• Describe the runtime processing nodes.

How to Draw a 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 hardware used to
deploy the application.
Deployment diagrams are useful for system engineers. An efficient deployment diagram is
very important as it controls the following parameters −
• Performance
• Scalability
• Maintainability
• Portability
Before drawing a deployment diagram, the following artifacts should be identified −
• Nodes
• Relationships among nodes
Following is a sample deployment diagram to provide 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 connects to the application using
the Internet. The control flows from the caching server to the clustered environment.
The following deployment diagram has been drawn considering all the points mentioned
above.

Where to Use Deployment Diagrams?

Deployment diagrams are mainly used by system engineers. These diagrams are used to
describe the physical components (hardware), their distribution, and association.
Deployment diagrams can be visualized as the hardware components/nodes on which the
software components reside.
Software applications are developed to model complex business processes. Efficient software
applications are not sufficient to meet the business requirements. Business requirements can
be described as the need to support the increasing number of users, quick response time, etc.
To meet these types of requirements, hardware components should be designed efficiently and
in a cost-effective way.
Now-a-days software applications are very complex in nature. Software applications can be
standalone, web-based, distributed, mainframe-based and many more. Hence, it is very
important to design the hardware components efficiently.
Deployment diagrams can be used −
• To model the hardware topology of a system.
• To model the embedded system.
• To model the hardware details for a client/server system.
• To model the hardware details of a distributed application.
• For Forward and Reverse engineering.

Deployment diagram for Library Management System:

Software Cost Estimation
For any new software project, it is necessary to know how much it will cost to develop and
how much development time will it take. These estimates are needed before development is
initiated, but how is this done? Several estimation procedures have been developed and are
having the following attributes in common.

1. Project scope must be established in advanced.

2. Software metrics are used as a support from which evaluation is made.
3. The project is broken into small PCs which are estimated individually.
To achieve true cost & schedule estimate, several option arise.
4. Delay estimation
5. Used symbol decomposition techniques to generate project cost and schedule
estimates.
6. Acquire one or more automated estimation tools.

Uses of Cost Estimation

1. During the planning stage, one needs to choose how many engineers are required for
the project and to develop a schedule.
2. In monitoring the project's progress, one needs to access whether the project is
progressing according to the procedure and takes corrective action, if necessary.

Cost Estimation Models

A model may be static or dynamic. In a static model, a single variable is taken as a key
element for calculating cost and time. In a dynamic model, all variable are interdependent,
and there is no basic variable.
Static, Single Variable Models: When a model makes use of single variables to calculate
desired values such as cost, time, efforts, etc. is said to be a single variable model. The most
common equation is:

C=aLb

Where C = Costs
L= size
a and b are constants

The Software Engineering Laboratory established a model called SEL model, for estimating
its software production. This model is an example of the static, single variable model.

E=1.4L0.93
DOC=30.4L0.90
D=4.6L0.26

Where E= Efforts (Person Per Month)

DOC=Documentation (Number of Pages)
D = Duration (D, in months)
L = Number of Lines per code

Static, Multivariable Models: These models are based on method (1), they depend on
several variables describing various aspects of the software development environment. In
some model, several variables are needed to describe the software development process, and
selected equation combined these variables to give the estimate of time & cost. These models
are called multivariable models.

WALSTON and FELIX develop the models at IBM provide the following equation gives a
relationship between lines of source code and effort:

E=5.2L0.91

In the same manner duration of development is given by

D=4.1L0.36

The productivity index uses 29 variables which are found to be highly correlated productivity
as follows:

Where Wi is the weight factor for the ithvariable and Xi={-1,0,+1} the estimator gives Xione
of the values -1, 0 or +1 depending on the variable decreases, has no effect or increases the
productivity.

Example: Compare the Walston-Felix Model with the SEL model on a software
development expected to involve 8 person-years of effort.
a. Calculate the number of lines of source code that can be produced.
b. Calculate the duration of the development.
c. Calculate the productivity in LOC/PY
d. Calculate the average manning

Solution:

The amount of manpower involved = 8PY=96persons-months

(a)Number of lines of source code can be obtained by reversing equation to give:

Then

L (SEL) = (96/1.4)1⁄0.93=94264 LOC

L (SEL) = (96/5.2)1⁄0.91=24632 LOC

(b)Duration in months can be calculated by means of equation

D (SEL) = 4.6 (L) 0.26

= 4.6 (94.264)0.26 = 15 months
D (W-F) = 4.1 L0.36
= 4.1 (24.632)0.36 = 13 months

(c) Productivity is the lines of code produced per persons/month (year)

(d)Average manning is the average number of persons required per month in the project
COCOMO Model
Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.COCOMO is one
of the most generally used software estimation models in the world. COCOMO predicts the
efforts and schedule of a software product based on the size of the software.

The necessary steps in this model are:

1. Get an initial estimate of the development effort from evaluation of thousands of

delivered lines of source code (KDLOC).
2. Determine a set of 15 multiplying factors from various attributes of the project.
3. Calculate the effort estimate by multiplying the initial estimate with all the
multiplying factors i.e., multiply the values in step1 and step2.

The initial estimate (also called nominal estimate) is determined by an equation of the form
used in the static single variable models, using KDLOC as the measure of the size. To
determine the initial effort Ei in person-months the equation used is of the type is shown
below

Ei=a*(KDLOC)b

The value of the constant a and b are depends on the project type.

In COCOMO, projects are categorized into three types:

1. Organic
2. Semidetached
3. Embedded

1.Organic: A development project can be treated of the organic type, if the project deals with
developing a well-understood application program, the size of the development team is
reasonably small, and the team members are experienced in developing similar methods of
projects. Examples of this type of projects are simple business systems, simple inventory
management systems, and data processing systems.

2. Semidetached: A development project can be treated with semidetached type if the

development consists of a mixture of experienced and inexperienced staff. Team members
may have finite experience in related systems but may be unfamiliar with some aspects of the
order being developed. Example of Semidetached system includes developing a new
operating system (OS), a Database Management System (DBMS), and complex
inventory management system.

3. Embedded: A development project is treated to be of an embedded type, if the software

being developed is strongly coupled to complex hardware, or if the stringent regulations on
the operational method exist. For Example: ATM, Air Traffic control.
For three product categories, Bohem provides a different set of expression to predict effort (in
a unit of person month)and development time from the size of estimation in KLOC(Kilo Line
of code) efforts estimation takes into account the productivity loss due to holidays, weekly
off, coffee breaks, etc.

According to Boehm, software cost estimation should be done through three stages:

1. Basic Model
2. Intermediate Model
3. Detailed Model

1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the
project parameters. The following expressions give the basic COCOMO estimation model:

Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months

Where

KLOC is the estimated size of the software product indicate in Kilo Lines of Code,

a1,a2,b1,b2 are constants for each group of software products,

Tdev is the estimated time to develop the software, expressed in months,

Effort is the total effort required to develop the software product, expressed in person
months (PMs).

Estimation of development effort

For the three classes of software products, the formulas for estimating the effort based on the
code size are shown below:

Organic: Effort = 2.4(KLOC) 1.05 PM

Semi-detached: Effort = 3.0(KLOC) 1.12 PM

Embedded: Effort = 3.6(KLOC) 1.20 PM

Estimation of development time

For the three classes of software products, the formulas for estimating the development time
based on the effort are given below:

Organic: Tdev = 2.5(Effort) 0.38 Months

Semi-detached: Tdev = 2.5(Effort) 0.35 Months

Embedded: Tdev = 2.5(Effort) 0.32 Months

Some insight into the basic COCOMO model can be obtained by plotting the estimated
characteristics for different software sizes. Fig shows a plot of estimated effort versus product
size. From fig, we can observe that the effort is somewhat superliner in the size of the
software product. Thus, the effort required to develop a product increases very rapidly with
project size.

The development time versus the product size in KLOC is plotted in fig. From fig it can be
observed that the development time is a sub linear function of the size of the product, i.e. when
the size of the product increases by two times, the time to develop the product does not double
but rises moderately. This can be explained by the fact that for larger products, a larger number
of activities which can be carried out concurrently can be identified. The parallel activities can
be carried out simultaneously by the engineers. This reduces the time to complete the project.
Further, from fig, it can be observed that the development time is roughly the same for all three
categories of products. For example, a 60 KLOC program can be developed in approximately
18 months, regardless of whether it is of organic, semidetached, or embedded type.
From the effort estimation, the project cost can be obtained by multiplying the required effort
by the manpower cost per month. But, implicit in this project cost computation is the
assumption that the entire project cost is incurred on account of the manpower cost alone. In
addition to manpower cost, a project would incur costs due to hardware and software required
for the project and the company overheads for administration, office space, etc.

It is important to note that the effort and the duration estimations obtained using the
COCOMO model are called a nominal effort estimate and nominal duration estimate. The
term nominal implies that if anyone tries to complete the project in a time shorter than the
estimated duration, then the cost will increase drastically. But, if anyone completes the
project over a longer period of time than the estimated, then there is almost no decrease in the
estimated cost value.

Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and
development time for each of the three model i.e., organic, semi-detached & embedded.

Solution: The basic COCOMO equation takes the form:

Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC

(i)Organic Mode
 E = 2.4 * (400)1.05 = 1295.31 PM
D = 2.5 * (1295.31)0.38=38.07 PM

(ii)Semidetached Mode

E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM

(iii) Embedded Mode

E = 3.6 * (400)1.20 = 4772.81 PM

D = 2.5 * (4772.8)0.32 = 38 PM

Example2: A project size of 200 KLOC is to be developed. Software development team has
average experience on similar type of projects. The project schedule is not very tight.
Calculate the Effort, development time, average staff size, and productivity of the project.

Solution: The semidetached mode is the most appropriate mode, keeping in view the size,
schedule and experience of development time.

Hence E=3.0(200)1.12=1133.12PM
D=2.5(1133.12)0.35=29.3PM

P = 176 LOC/PM

2. Intermediate Model: The basic Cocomo model considers that the effort is only a function
of the number of lines of code and some constants calculated according to the various
software systems. The intermediate COCOMO model recognizes these facts and refines the
initial estimates obtained through the basic COCOMO model by using a set of 15 cost drivers
based on various attributes of software engineering.

Classification of Cost Drivers and their attributes:

(i) Product attributes -

o Required software reliability extent

o Size of the application database
o The complexity of the product

Hardware attributes -
 o Run-time performance constraints
o Memory constraints
o The volatility of the virtual machine environment
o Required turnabout time

Personnel attributes -

o Analyst capability
o Software engineering capability
o Applications experience
o Virtual machine experience
o Programming language experience

Project attributes -

o Use of software tools

o Application of software engineering methods
o Required development schedule

The cost drivers are divided into four categories:

Intermediate COCOMO equation:

E=ai (KLOC) bi*EAF

D=ci (E)di

Coefficients for intermediate COCOMO

Project ai bi ci di

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

3. Detailed COCOMO Model: Detailed COCOMO incorporates all qualities of the standard
version with an assessment of the cost driver?s effect on each method of the software
engineering process. The detailed model uses various effort multipliers for each cost driver
property. In detailed cocomo, the whole software is differentiated into multiple modules, and
then we apply COCOMO in various modules to estimate effort and then sum the effort.

The Six phases of detailed COCOMO are:

1. Planning and requirements

2. System structure
3. Complete structure
4. Module code and test
5. Integration and test
6. Cost Constructive model

The effort is determined as a function of program estimate, and a set of cost drivers are given
according to every phase of the software lifecycle.

What is a Gantt Chart?

Introduction

Gantt chart is a type of a bar chart that is used for illustrating project schedules. Gantt charts
can be used in any projects that involve effort, resources, milestones and deliveries.
At present, Gantt charts have become the popular choice of project managers in every field.
Gantt charts allow project managers to track the progress of the entire project. Through Gantt
charts, the project manager can keep a track of the individual tasks as well as of the overall
project progression.
In addition to tracking the progression of the tasks, Gantt charts can also be used for tracking
the utilization of the resources in the project. These resources can be human resources as well
as materials used.
Gantt chart was invented by a mechanical engineer named Henry Gantt in 1910. Since the
invention, Gantt chart has come a long way. By today, it takes different forms from simple
paper based charts to sophisticated software packages.

The Use

As we have already discussed, Gantt charts are used for project management purposes. In
order to use Gantt charts in a project, there are a few initial requirements fulfilled by the
project.
First of all, the project should have a sufficiently detailed Work Breakdown Structure (WBS).
Secondly, the project should have identified its milestones and deliveries.
In some instances, project managers try to define the work break down structure while creating
Gantt chart. This is one of the frequently practised errors in using Gantt charts. Gantt charts
are not designed to assist WBS process; rather Gantt charts are for task progress tracking.
Gantt charts can be successfully used in projects of any scale. When using Gantt charts for
large projects, there can be an increased complexity when tracking the tasks.
This problem of complexity can be successfully overcome by using computer software
packages designed for offering Gantt chart functionalities.

One way to create a project plan is to use a work breakdown structure, a technique for splitting
tasks into sub-tasks and creating a task hierarchy. Gantt applications will generally allow you
to reflect the project hierarchy in the Gantt's task list at the left of the chart.

A Gantt chart is a type of horizontal bar chart commonly used in project management, which
is a visual view of tasks scheduled overtime. It provides a graphical visualization of a
schedule that helps to plan, coordinate, and track specific tasks (or elements) in a project.
Gantt chart boils down multiple tasks and timelines into a single page. Using a Gantt chart
allows all stakeholders to perceive the same schedule information, sets mutually understood
expectations, and conducts their efforts according to the desired protocol. The Gantt chart
tool provides a visual timeline for the start and end of tasks, making it clear how tasks are
interrelated and perhaps rely on the completion of another before one can start.
PERT vs Gantt Chart
PERT charts are network diagrams that use boxes to represent tasks and arrows to present
dependencies between tasks. The boxes are laid out from left to right, but there is no fixed
Y-axis with dates. The first box, or root, is centered vertically on the left side, and the
subsequent tasks can be drawn anywhere along the Y-axis. Arrows can point to the right, up
or down, but never to the left.
Gantt charts are bar graphs. The X-axis contains dates and the Y-axis lists separate tasks.
On each line of the Y-axis, the chart depicts a bar positioned to extend from the task’s start
date to its end date. Tasks are listed in the start-date order.