8.1.

Phases of Software Development Life Cycle

Introduction

Software is a collection of computer programs and related data that instructs a computer on what
to do and how to do it.

Software should be capable of doing all the functions necessary to perform a task efficiently.
Software must be maintained when it is in use. In this module, we will discuss several processes
or guidelines for software development.

Life Cycle is a manner of looking at processes, in the context of their initial research and
development, expansion, maturing and final stages of evolution and growth.

For example, a butterfly goes through four stages in its life. Each of these stages is different from
the others. The following figure illustrates the life cycle of a butterfly.

Egg - It is the first stage in the life cycle of a butterfly.

Larva - It hatches from the egg. It is also called a caterpillar.

Pupa - When a caterpillar has finished growing, it forms a pupa.

Adult - When the pupa has finished changing, it emerges as an butterfly(adult) or moth.

Adult is the stage when butterfly and moth mate and reproduce. Females lay their eggs on plants
or any other surfaces, and the cycle starts again.

Software Life Cycle Model (SDLC)

The term Software Development Life Cycle(SDLC) is the way of describing the planning,
designing, coding, testing and maintaining a software, as well as the method in which these steps
are implemented.

SDLC is a structure imposed on the development of a software product. All these life cycle
models take a project through several primary phases: a requirements-gathering phase, a design
phase, a construction or an implementation phase, a testing phase and a maintenance phase.
Each phase produces feedback that affects the next phase of the SDLC. For instance, the
requirements gathered during the requirement analysis phase influence the design, which is
translated into working software code during the implementation phase. The software code is
verified against the requirements during the testing phase and the software is maintained when it
is in use during maintenance phase.

Requirements Analysis

During this phase, the needs of the company are outlined. Users (and in some cases, clients)
make their wish-lists about what they would like the software to do. Business Analysts(who
analyze the requirements) ask questions about the intended use of the software system, what type
of data will be processed, how the data can be accessed and how the software should handle the
data in the system. At the end of analysis phase, the development team should have a detailed list
of functions that the software system will perform. In this phase, emphasis is on the system's
goals rather than the way in which the system will achieve those goals.

Design

In the design phase, the results of the requirements analysis phase are translated into software
design plan. Focus shifts from the system's goals to the way in which those goals will be
achieved and how the goals of the requirements gathering phase are achieved. Designers
consider many different criteria, from the hardware and operating system platform that hosts the
software or the solution, to the way the subsystems will communicate with each other.
During the design phase, the designers convert the dreams of the users and managers into reality.
Emphasis is on making a practical, working design for what has been outlined in the
requirements analysis phase.

Construction

During this phase, the output of the design phase is translated into program code. Software that
does not meet the needs of the user or the company is wasteful. During the construction phase,
the main goal of the programmers should be to fulfill the requirements of the users and to meet
the design outlined in the design phase.

Testing

In the testing phase, the results of the implementation/construction phase are run through a series
of tests to verify that it functions and also meets the goals of the requirements phase. A testing
plan is created to describe the unit and system tests that will be performed. Unit testing is
performed on individual software components. The process of integration brings together all the
individual software components to create the complete software system. System testing is then
performed on the complete software system as a whole component.

Please go through the 'Testing and Debugging' module to learn more about testing.

Maintenance

Once the product has been delivered/deployed to customers, it enters the maintenance phase.
During this stage, specialists from the development and testing teams monitor the product 'in the
wild' to see how it is adapting to regular user/customer usage. If customers encounter any
unforeseen problem, the maintenance team would take corrective action and fix the issue.

Refer the links given below to get more information about SDLC.

http://softwarelifecyclepros.com/wp-content/uploads/2012/05/Tutorial-Software-Development-
LifeCycle-SDLC.pdf

http://www.cpe.ku.ac.th/~plw/oop/e_book/ood_with_java_c++_and_uml/ch4.pdf

Types of SDLC Models

There are different life cycle models, each describing approaches to a variety of activities that
take place during the SDLC process. The following section discusses the important SDLC
models given below:

1. Waterfall Model
2. V-Shaped Model

3. Iterative Model

4. Incremental Model

5. Spiral Model

1. Waterfall Model

It is one of the most widely used SDLC models. It is also known as "Classic Life Cycle" or
"Linear Sequential model". This is one of the simplest models to understand and use. This model
is characterized by a series of steps that must be completed in a linear or sequential order. It is
known by the name 'Waterfall' because, we move to the next step after getting input from the
previous step (phase). This is similar to a waterfall where, water flows down to lower steps from
the upper steps. Each phase is completed and verified before the next phase. There is sequential
progression from one phase to another in this model.

The origin of this model is in the construction and manufacturing industry. Since formal software
development processes did not exist at that time, this hardware-oriented process model was
adapted for software development as well.

Waterfall model is not only simple to understand but also very easy to use. The highlight is that,
there are defined phases or steps in the waterfall model life cycle. So also, the preceding phase
must be complete before the next phase starts. After the first phase/step is completed, it is
considered as a stepping stone to the next phase. Though there are a number of life cycle models
that are now used in software development, waterfall model still remains one of the most popular
models.

The waterfall model was originally designed in 1970 by Winston W. Royce. The different phases
in Waterfall model are Requirement analysis, Design, Implementation and Unit Testing,
Integration and System testing, and Maintenance and Operation. The following figure illustrates
the waterfall model.
Following each phase, there is a formal review process that results in the decision to proceed to
the next phase. When one phase is complete, the entire development effort shifts to the next
phase. Cascading the flow from one phase to another is the basis of the Waterfall model.

1.Requirements Analysis

Like in any other project, requirements analysis is the first phase in the Waterfall model also.
During this phase, all the needs or functionality which should be implemented are gathered from
the client and a blue print is created. Analysis phase gives a clear picture of what the software
will be able to do in future. The system is thoroughly studied for pitfalls and incompatibilities.
Later a requirement specification document is created and handed over to the Design team.

2. Design

The Design phase needs a new team to design the software. This is most often done by a System
Analyst/ Designer. It results in the physical design of a system which is designed from the set of
requirements gathered during the requirement phase.

Creating a good design is very important because it describes what is going to get developed in
the implementation phase. The risk factor is very high in a project where there is poor design or
no proper design. A better understanding of the software help us to reduce the risk of failing. A
designer designs everything virtually. An analyst then analyzes everything thoroughly from top
to bottom to ensure that there is no incompatibility or functional error in the design.

System Analysts use UML (We will discuss about this in detail later) tools to design software
systems. Pseudo codes are written by system analysts for developers to refer to during
implementation. Pseudo codes are codes written roughly in English or any other language which
can be read/understand by anyone. It shows how the software actually works.

3. Implementation
Implementation is a critical phase in any software project. This is the most time consuming phase
of the project. In this phase, developers start writing actual code according to the design obtained
from the previous phase. Later, the project is divided into small tasks according to the
functionality or design. These small tasks are called modules or units. Each module is then
assigned to a team of developers, who focus on that particular module. This helps the developers
to implement the system in parallel. Once the development is complete, the project enters its next
phase; testing.

4. Testing

In this phase the software modules are tested by a team of software testers. This process is
known as Unit Testing. Initially, each module is tested for errors. If an error occurs, it is reported
back to developers to fix. After unit testing is completed, all the modules are combined into the
project and tested as a whole for integration errors. The software is tested thoroughly in different
conditions to ensure its quality. This is done by a team called the Quality and Assurance team(a
set of software testers). Please go through the 'Testing and Debugging' module to learn more
about testing.

5. Deployment and Maintenance

In this phase, the software system is deployed safely into the required condition or environment,
based on the user requirements. The software can either be deployed into a server or on a
computer according to the user requirements. The product is then ready for use by the end user.
Later, the software is maintained by the maintenance team to ensure that it is working fine. If an
error occurs, the maintenance team would fix it and continue to ensure the working of the
software.

Advantages of Waterfall Model

It is simple and easy to use.

It is easy to implement and manage because each phase has a specific purpose. Also,
development occurs only in one phase at a time.

This model is appropriate for small development projects, whose requirements are well
understood.

Disadvantages of Waterfall Model

Due to the rigidity of the model, all the requirements must be stated explicitly before
development begins. If requirements are changed or added later, then the project must
start over from the beginning.

If errors are made in requirements-analysis or design, they may not be discovered until
very late in the implementation or testing phase.
Due to these issues, the Waterfall model is inappropriate for complex projects. It should not be
used for developing object-oriented software, for long-term or ongoing projects, or for projects
whose requirements are unknown or are subject to change.

V-Shaped Model

Like the Waterfall model, the V-Shaped life cycle model provides a sequential path of individual
phases that must be completed before development proceeds to the next phase. V-shaped model
means Verification and Validation model.

Validation- It is the assurance that a service, product or system meets the needs of the customer.

Verification- The evaluation of whether or not a product, service, or system complies with the
requirements, specification, or an imposed condition. It is an internal process.

The main difference between V-shaped development model and Waterfall development model is
the early test planning. The following figure is a simplified illustration of the V-shaped life cycle
model.

V-shaped model is applicable to projects where:

Requirements are clearly known and defined in advance.

Software development tools and the technologies are well known

The test plans(for each phase) are developed during each level of verification. Once coding is
complete, testing will be conducted as a part of validation.

Verification phases

Requirements

Requirement analysis (upper left point of the V) is the first step in the verification process. The
requirements are collected by analyzing the needs of the users. User acceptance tests and system
tests are designed as a part of this phase. System and acceptance test design plans focus on
verifying the functionality specified in the requirements definition.

High-level Design

As the V-shaped model moves down the left side, developers will focus on high-level design
architecture and the overall system design. System engineers will analyze and understand the
business of the proposed system or software by studying the user requirements document. Then
they come up with different techniques and possibilities by which the user requirements can be
implemented. If any of the requirements is not feasible, then the user is informed about the issue.

Low-Level Design

Low level design focuses on the design of individual software components or modules. The high-
level design is broken into smaller units or modules and each of them is explained in detail, so
that the developer can start coding directly. Low-level design and unit test design documents are
developed during this stage.

Coding/Development is performed at the bottom of the V-model, during the implementation

phase. Once coding is over, development progresses up the right side of the V-model, moving
through the documents prepared/developed as a part of the verification phase. If any problem
arises during the testing phase, the life cycle reverts to its corresponding development phase.

Validation phases

Unit testing

In computer programming, unit testing is a method by which individual units of source code are
tested to determine if they are fit for use through the documents prepared during Low-level
design. A unit is defined as the smallest testable part of an application or software.

Integration testing

The separate modules will be tested together to find out faults in the interfaces and in the
interaction between integrated components or modules through the documents prepared as a part
of High-level design.

Acceptance and System testing

After the integration test is completed, the focus is on the system and acceptance testing. This is
to check whether the integrated product/software meets the specified requirements or not. This
phase is used to determine whether a software system satisfies the requirements specified in the
requirements analysis phase through the documents prepared as a part of the requirement
analysis phase.

Advantages of V-model

It is very simple and easy to use.

Preparing test plans early in the process gives the V-model a higher chance for success.

Appropriate for small development projects in which requirements are well understood
and defined in advance.

Disadvantages of V-model

Like the Waterfall model, all requirements must be defined at the beginning of the
project. So it is difficult to add or change requirements later in the development process.

All the software development occurs in a single phase, so there are no early working
versions or prototypes.
 The emphasis in test planning is to reduce the risk, but like the Waterfall life cycle model
the V-model also risks time and energy in the absence of careful planning.

Similar to Waterfall model, the V-model is inappropriate for complex projects.

3. Iterative Model

The Iterative model addresses many issues associated with the Waterfall model. In the Iterative
model, analysis is done in the same way as it is done in the Waterfall Model .

An Iterative model does not start with a full specification of requirements. Development begins
by specifying and implementing just a part of the software, which can then be reviewed to
identify further requirements. This process is then repeated to produce the new version of the
software for each cycle in this model. An iterative life cycle model consists of repeating the
following four phases in sequence.

A Requirements phase in which the requirements are gathered and analyzed for the software
development.

A Design phase in which a software solution to meet the requirements is designed. This can be a
new design, or an extension of an earlier design.

An Implementation and test phase, when the software is developed, integrated and tested.

A Review phase in which the software solution is evaluated, the current requirements are
reviewed, and changes and additions to existing requirements are proposed.

For each cycle, a decision has to be made to check whether the software produced by the cycle
will be discarded, or if we can keep it as a starting point for the next cycle (incremental
prototyping). A point will be reached where the requirements are complete and the software can
be delivered or it becomes impossible to enhance the software system as required, and a fresh
start has to be made.

The key to the successful use of an iterative life cycle model is rigorous validation of
requirements, and the verification (including testing) of each version of the software against the
requirements within each cycle.

The first three phases of the Iterative model are more or less an abbreviated form of a Waterfall
life cycle or a sequential V-model. Each cycle produces software that requires testing at the unit
level, for software integration, system integration and an acceptance from the user. As the
software evolves through successive cycles, testing is repeated and extended to verify each
version of the software against the requirements within each cycle.

Advantages of Iterative model

Faster coding, testing and design.

Facilitates the support for changes within the life cycle.

Disadvantages of Iterative model

More time spent in review and analysis phase

Lot of steps need to be followed.

Delay in one phase can have an adverse effect on the software as a whole.

4. Incremental Model

It builds an iterative approach into the waterfall model. Development projects are divided into
several smaller(more manageable) iterations. Each iteration passes through a mini waterfall
process model. Requirement analysis, design, implementation and testing phases are completed
for each iteration. In this model, software is designed, implemented, integrated and tested as a
series of incremental builds. Incremental model may be applicable to projects where:

Requirements are known and well defined, but realization may be delayed.

Basic functionality is required early.

This model is evolutionary, means that a working version of the software is created by the end of
the first iteration, and subsequent iterations build upon the work of earlier iterations.

Low level design is performed during each iteration. Unit testing evaluates the functionality
added during the current iteration on a relatively small amount of new code. . System testing
phase evaluates the way in which the new functionality affects the complete functionality of the
entire software system.

Advantages of Incremental Model

Unlike the waterfall model, the incremental model generates a working prototype early in
the development process.

The iterative nature makes it more flexible when adding or changing requirements

Easier to test and debug because testing is performed incrementally during each iteration.

It is an effective tool for risk management.

Disadvantages of Incremental Model

Like the waterfall process model, the incremental model exhibits some rigidity(the
inability to change) in that phases cannot be overlapped.

Because requirements analysis and design are performed during each iteration and not
before development begins, projects developed using this model may incur errors in early
iterations.

It is less risky than the waterfall model, but it may be inappropriate for large and long
term projects.
5. Spiral Model

It is similar to the incremental life cycle model but incorporates risk analysis. It is divided into
four phases

I.Planning

II.Risk analysis

III.Development/Engineering

IV.Evaluation

A project passes through each of these phases in sequence, in a series of iterations called spirals.
At the beginning of the development process, critical requirements are identified for the first
spiral. The subsequent spirals add functionality to this baseline spiral.This model is represented
by a spiral passing through four quadrants/phases of development.

Requirements analysis or gathering is performed in the planning phase.

In the risk analysis phase, a formal process is undertaken to identify alternative courses of action
and their relative risks. A prototype is also developed during the risk analysis phase.

Software is coded and tested during the development/engineering phase.

In the evaluation phase, the customer/user has an opportunity to evaluate the software before
the project proceeds to the next spiral.

Following Figure illustrates the Spiral life cycle model. The angular component in the diagram
represents the progress in the current spiral, and the radius represents the project cost.
Advantages of Spiral Model

Focus on risk avoidance makes this model ideal for large scale and mission critical
products.

The iterative nature makes it more flexible when adding or changing requirements

Spiral model is built on earlier software development life cycle models, and it borrows
from both the waterfall and incremental models.

Working software code is developed early,thus the user/customer is given with many
opportunities to evaluate the software/output and plenty of time to ease into adoption of
the software

Disadvantages of Spiral model

Cost is considerably more to implement than other software life cycle models.

Risk analysis phase of this model requires highly specific expertise, and the project's
success depends on the output of this phase.
 It is inappropriate for small and medium scale projects.

Summary

All SDLC models share common phases of development:requirements gathering, designing of

the software system, Development of software, and the testing . Waterfall model is one of the
simplest and easiest to use,It consists of five phases that are executed sequentially. The
incremental model applies a series of iterations to the waterfall model. The Spiral model is built
upon the waterfall and incremental models and focuses on risk analysis.

8.2. Introduction to the Unified Modeling Language

Unified Modeling Language (UML) makes it possible to describe systems with pictures and
words. It can be used to model a variety of systems-business systems ,software systems or any
other system.

It is a graphical modeling language that is used to express designs. UML is a standardized

language to specify the components and artifacts of a software system. It describes a notation and
not a process. It does not put forth a single process or method of design, but rather is a
standardized tool that can be used in a design process.

A picture is worth a thousand words, this concept absolutely fits while discussing about UML in
this module. There are a number of goals for developing UML but the most important goal is to
define some general purpose modeling language ,which all modelers can use and also it needs to
be made simple to understand and easy to use.

UML diagrams are not only made for developers but also for common people, business users and
anybody interested to understand the a software or non software. It is clear that UML is not a
development methodology rather than it accompanies with processes to make a successful
system.

UML breaks the complex system into small pieces that can be understood easily. Complex
system can be understood by different developers who are working on different platforms.
Handing over the system or application to new team becomes easier. UML model is not a
platform or system specific. UML unifies all different developers under one roof.

UML Modeling provides following benefits:

We can use UML with all processes throughout the development life cycle and across
different implementation technologies.

Software will behave as we expect it to (fewer surprises).

We will have lower development costs.

 Working with new developers will be easier.

The right decisions are made to prevent poorly written code. Overall cost would be very
less.

We can develop memory and processor efficient systems.

Efficient communication with programmers and outside contractors.

Less system maintenance cost.

UML Standard Diagrams

We prepare UML diagrams to understand a system in simple and better way. A single diagram is
not enough to cover the different aspects of the system. UML defines various kinds of diagrams
to cover all the aspects of a system.

We can also create our own set of diagrams to meet our requirements. UML diagrams are
generally made in an incremental and iterative way.There are two broad categories of UML
diagrams and then are again divided into sub-categories:

Structural Diagrams

Behavioral Diagrams

1. Structural Diagrams

The structural diagram represents the static aspect of the system. These static parts are
represented by classes, interfaces, objects, components and nodes. The four structural diagrams
are,

1.Class diagram

2.Object diagram

3.Component diagram

4.Deployment diagram

2. Behavioral Diagrams

Any system can have two aspects, static and dynamic. A model is considered as complete when
both the system and dynamic aspects are covered fully.
Behavioral diagram basically represents the dynamic aspect of a system. Dynamic aspect can be
further described as the changing or moving parts of a system.UML has the following five types
of behavioral diagrams:

1.Use case diagram

2.Sequence diagram

3.Collaboration diagram

4.State chart diagram

5.Activity diagram

8.3. Developing Use-Case Diagrams

A use case diagram is " a diagram that shows the relationships among use cases and actors within
a system ".

A use case model is comprised of one or more use case diagrams and any supporting
documentation such as actor definition and use case specification. The use case specification
tend to be the primary artifact with use case diagrams filling a supporting role as the " glue " that
keeps your requirements model together. Use case models should be developed from the user
point of view and not from the (often technical) point of view of developers

It is used to

I.Provide an overview of all or part of the usage requirements for an organization or system in
the form of a business model or an essential model.

II.To communicate the scope of a development project .

III.Model your analysis of your usage requirements in the form of a system use case model.

We can also create our own set of diagrams to meet our requirements. UML diagrams are
generally made in an incremental and iterative way.There are two broad categories of UML
diagrams and then are again divided into sub-categories:

There are guidelines for:

Use Cases

Actors

Relationships
System Boundary Boxes

1. Use Cases

A use case specifies a sequence of actions that provide a measurable value to an actor. A use case
is drawn as a horizontal ellipse on a UML use case diagram, as you see in the figure.

Each use case focuses on describing how to achieve a goal or task. A use case should:

Describe what the system shall do to assist the actor in achieving a goal

Not include any details about the screens or user interfaces.

For example, the below use case describes a simple Login.Sequence of steps included in the
Login use case are :

i.System prompts the user to log in.

ii.User enters user name and password in the system.

iii.System verifies the user name and password.

iv.The system logs user on to the system

2. Actors
An actor is an external entity (outside of the system) that interacts with the system by
participating a Use Case. Actors can be in real life people (for example users of the system),
external events and other computer systems.

An actor is an external entity (outside of the system) that interacts with the system by
participating a Use Case. Actors can be in real life people (for example users of the system),
external events and other computer systems.

Actors do not represent the physical systems or people , but their role. This means that when a
person interacts with the system in different ways , he will be represented by several actors.

For example a person that gives customer support by the telephone would be represented by an
actor ' Support Staff '. A person who takes orders from the customer is represented by an actor '
Sales Representative '.

3. Relationships

There are several types of relationships appear on a use case diagram:

Association :

An association can be between " a use case and an actor " or between two use cases.

It is the relationship between an actor and a use case. It indicates that an actor can use a certain
functionality of the business system - the business use case: Association can be represented as
below.
Example : A traveler purchases a transport ticket

In the following figure ,Purchase Ticket is the Use case and the Traveler is the actor. A given
ticket purchase can only be made by one traveler,but a traveler can purchase any number of
tickets(represented as 1..*).This is a type of association relationship

Include Relationship :

It is a relationship between two business use cases that signifies that the business use case on the
side to which the arrow points is included in the use case on the other side of the arrow. For one
functionality that the business system provides, another business functionality is accessed.

Functionality that are accessed repeatedly can be depicted as individual business use cases,
which can be used in multiple ways. In can be represented as below.

Example :

In the following figure , An include relationship points from the CheckOrderStatus use case to
the LogIn use case.It indicate that the CheckOrderStatus use case always includes the behaviors
in the LogIn use case.

The included use case LogIn cannot stand alone and the original use case CheckOrderStatus is
not complete without the LogIn use case.
4. System Boundary Boxes

The rectangle around the use case is called the system boundary box and it indicates the scope of
your system - the use cases inside the rectangle represent the functionality that you intend to
implement.

Sample Use Case Diagrams

Example 1 : Sales Application

There are two actors customer and other is the sales clerk. In this example Sales Clerk checks out
an item is the use case identified.

Use Case Specification: Sales Clerk checks out an item.

i.Customer sets the selected items on counter.

ii.Sales Clerk swipes UPC(Universal Product Code) reader across UPC code on item.

iii.System looks up UPC code in database to retrieve item type ,description and price.

iv.System emits beep sound.

v.System adds price, item type and item description to current invoice.

vi.System calculate price along with the tax details.

Following figure shows what the above use case might look like in UML schematic form. The
use case is drawn as an oval. The actors are represented as stick figures. Actors and use case are
connected using lines.
Example 2 : Bank ATM

An Automated Teller Machine (ATM) or the Automatic Banking Machine (ABM) is banking
subsystem that provides customers with access to financial transactions without the need for a
clerk,cashier or bank teller.

Customer (actor) uses bank ATM to check balance of his/her bank accounts, withdraw cash
,transfer funds and deposit funds(use cases). ATM Technician(actor) provides maintenance and
repairs((use cases). All these use cases also involve Bank as an actor, it is related to customer
transactions or to ATM servicing.

Example 3 : Passenger Services

Following figure illustrates a use case diagram with the actors: the Passenger (1) and the Check-
In representative (2), as well as the business use cases Check-In (3) and Express Check-In (4):
Starting with the Passenger (1)(actor) , we find association lines to two use cases, Check-In (3)
and Express Check-In (4). This means that people, who appear as passengers, can either go
through Check-In, or Express Check-In(which can be conducted without luggage) use case.

Example 4 : Order Management System

The following is a sample use case diagram representing the order management system. If we
look into the use case diagram, 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,it is an
extends(generalization)relationship. Customer(actor) lies outside the system as it is an external
user of the system.
Where can Use Case Diagrams be applied?

Use case diagram is used to gather system requirements and actors.

It specify the events of a system and the flow. It never describes how they are implemented. Use
case diagram can be imagined as a black box where we can see only the input, output and the
function of the black box is known.

These diagrams are used at a very high level of design. High level design is refined again and
again to get a complete picture of the system. A well structured use case also describes some
extra elements such as precondition, post condition and exceptions. These extra elements are
used to make test cases during testing phase.

Following are the places where use case diagrams can be used:

Requirement analysis and high level design phase.

Model the context of a system.

8.4. Examining Other UML Diagrams

Class diagram

Class diagrams are the most popular UML diagrams used for the implementation of software
application. It is very important to learn the how to draw the class diagram.

It is basically a graphical representation of the static view of the system and represents different
aspects of the system. So a collection of class diagrams represent the complete system.
Following figure represents the class diagram. It is divided into four compartments.

I.The top section represents the name the class.

II.The second one show the attributes of the class.

III.The third section describe the operations performed by the class.

IV.The fourth section is optional and it is used to show the extra components

Object Notation:

Object is represented in the same way as the class. The only difference is the name which is
underlined as shown in the figure given below.

An object is the actual implementation of a class .It is also known as the instance of a class.

The following points should be considered while drawing a class diagram:

i.The name of the class should be meaningful.

ii.Each element and their relationships needs to be identified in advance.

iii.Attributes and methods of each class needs to be clearly identified.

iv.Unnecessary properties will make the class diagram complicated,So for each class minimum
number of properties should be specified.

v.Use notes wherever required to describe the aspect of the diagram. Because the class diagram it
should be understandable to the developer.

vi.The diagram needs to be drawn on plain paper and rework as many times as possible to make
it correct before making the final version.

The following figure represents the class diagram of an Order System . The class diagram has
been drawn considering all the points mentioned above:

Where to use Class Diagrams?

Describing the static view of the system.

To show the collaboration among the elements of the static view.

Describing the functionality performed by the system.

 Development of software applications using object oriented languages.

Sequence Diagram

It is used to model the life line of an object, the activation and the message passing. Sequence
diagrams are two-dimensional diagrams: one dimension (usually the vertical) is used to display
evolution through time, the other to distinguish between different objects. An object is a vertical
line with a thick bar on the line which indicates the life line of an object. Message passing is
modeled by arrows pointing from one object to the next at a certain state transition on the life
lines of both objects. When message passing is instantaneous, the arrows are horizontal.

As mentioned the aim of a sequence diagram is to define event sequences, which would have a
desired outcome. The focus is more on the order in which messages occur than the message.
However, the majority of sequence diagrams will communicate what messages are sent and the
order in which they tend to occur.

Lifelines

When drawing a sequence diagram, remember that lifeline notation elements are placed across
the top of the diagram. Lifelines are representative of roles or object instances that take part in
the sequence being modeled. From a visual perspective, lifelines are shown as a box with a
dashed line descending from the center of the bottom edge. Name of the lifeline is placed inside
the box. Additionally, the lifeline name is underlined. What this means is that the lifeline
represents a specific instance of a class in a sequence diagram.

Message

For the sake of readability, the first message of a sequence diagram always starts at the top and is
located on the left side of the diagram. Subsequent messages are then added to the diagram. To
show an object or lifeline sending a message to another object, you draw a line to the receiving
object with a solid arrowhead (if a synchronous call ) or with a stick arrowhead (if an
asynchronous call). The method /message name is placed above the arrowed line. The message
sent to the receiving object represents an method/operation that the receiving object?s class
implements.

Example : Make a call

Below sequence diagram describes the process of making a phone call. The objects involved are
caller, phoneNetwork, the person who is called and an accounting system. Various messages are
passed between the objects.

Activity Diagram
Activity diagrams are related to program flow plans, are used to illustrate activities. It is used for
the description of business processes that describe the functionality of the business system.

In activity diagrams actors can perform use cases together or independently from one another.

It allow us to think functionally. It is possible to explicitly describe parallel events, the activity
diagram is suitable for the illustration of business processes, since business processes rarely
occur in a linear manner and often exhibit parallelisms.

Activity diagrams can be developed in various degrees of detail and can be refined step by step.
In the external view, activity diagrams exclusively represent business processes and activities
from the outside perspective. Refining the activity diagrams does not mean describing process
details that are performed within the business system, which often leads to an unnoticed shift to
the internal view.

Activity

An activity diagram illustrates/represents one individual activity. In our context, an activity

represents a business process Fundamental elements of the activity are actions and control
elements (decision, division, merge, initiation, end,etc).

Elements are connected by activity edges to form the control flow, which can also be called as
flow . The execution of an activity may contain parallel flows. A border can surround an
activity(entire activity diagram).

Action

An action is defined as an individual step within an activity.For example, a calculation step that
is not possible to break down any further. It does not mean that the action cannot be subivided ,
but in this diagram will not be refined further.
An action can contain input and output information The output of one action can be the input of a
subsequent action within an activity. Specific actions are sending signals,calling other actions
and receiving an event.

Calling an Activity(Action)

With the following symbol an activity can be called from within another activity. Calling in itself
is an action, the outcome of the call is an another activity. Activities can be nested within each
other and can be represented with different levels of details.

Accepting a Time Event(Action)

At a particular point in time, this action starts a flow in the activity diagram.A hourglass symbol
is used to represent the acceptance of a time event.

An example of a time event is triggering reminders after the deadline for payment has passed.
Sending Signals(Action)

It means that a signal is being sent to an accepting activity.

The accepting activity accepts the signal with the corresponding action ' accepting an event ' and
can react accordingly(according to the flow that originates from this node in the activity
diagram).

Edge (Control Flow)

Edge is represented by arrows. It connects the individual components of activity diagrams and
illustrate the control flow of an activity.

Within the control flow an incoming arrow starts a single step of an activity, once that step is
completed the flow continues along the outgoing arrow. A name is attached to an edge.

Decision Node

The diamond represents a decision node or a conditional branch point. It has only one input and
two or more outputs.
Each output has a condition attached to it, which can be represented/ written in brackets. If a
condition is met, the flow proceeds along with the appropriate output. An else output can also be
defined.

Merge Node

Merge node has several inputs and only one output. It is used for merging of flows. It is
represented by the diamond given below.

Fork

A fork has only one input and two or more outputs. For the branching of flows in two or more
parallel flows we use a synchronization bar, which is represented as a vertical line or thick
horizontal. Branching allows parallel flows within an activity.
Join

For the consolidation of two or more parallel flows we can use a synchronization bar, which is
represented as a thick vertical or horizontal line. It takes two or more inputs and gives only one
output.

Initial Node

Initial node is the starting point of any activity. An activity can contain more than one initial
node, in this case several flows will start at the beginning of an activity. It is also possible that an
activity has no initial node, but can be initiated by an event .

Activity Final Node

It indicates that an activity is completed. Activity diagram can contain more than one exit in the
form of activity final nodes.
If several parallel flows are present within an activity, all flows are stopped at the time the final
node is reached.

Flow Final Node

It terminates a flow. It is represented as below. Reaching a flow final node has no effect on other
parallel flows that are processed within the activity at the same point in time.

Activity Partition

The individual elements of an activity diagram can be divided into 'partitions' or individual areas.
Various criteria can lead to the creation of these partitions organization entities, locations ,cost
centers, etc.

Individual steps of an activity would be assigned to these partitions. Each partition is set apart
from its neighboring partition by a or vertical horizontal continuous line, from this stems the
term swim lanes. Each partition receives a name. Partitions can be arranged in a two dimensional
manner, in the above diagram the activity diagram is divided into individual cells like a grid.
Example : Passenger Check-in

In the following figure, we can start reading at the initial node or with the acceptance of the
event passenger arrive sat check-in (1), and continue along the arrows of the control flow (2).

The third action Passenger Checks In(3) means that at this point the activity passenger check in
is processed.

If we follow the control flow, next we will come to a decision node or conditional branch (4), if
the check-in is OK then the next step along the control flow can continue. Otherwise (5), the
passenger cannot fly and the passenger task service is completed. This is represented by a the
black dot with border(the activity final node).

After successful check-in (7) we come to a black cross bar. All arrows that come from this black
bar (7) symbolize flows that are processed simultaneously( the luggage is being loaded onto the
airplane (9) and the passenger is boarding the airplane (10) ).

Between point (8) and point (11) the flows are independent from each other. Simultaneously
processed Flows (9 and 10) are merged at the second cross bar (11). It means that only when the
passenger is on the plane (10) and the luggage has been loaded onto the plane (9), then the
control flow continue below the cross bar (11).
In this example, one more action (12) and subsequent to that the final state (13) follow, meaning
that after the passenger is on the plane (10) and the luggage has been loaded onto the plane (9),
the airplane can taxi towards the runway (12).

We can see here that the last action airplane taxis toward runway (12) is only defined as a single
action, even though this process is very complex and could be described in many other activity
diagrams.

Following figure illustrates the activity diagram with partitions .

The above diagram is divided into two partitions passenger (1) and passenger services (2). The
passenger carries out showing ticket at Check-In counter (3), checking luggage (4) and paying
fee (5). All other actions of passenger services (2) and are carried out by passenger services.