Domain model:

Each patient is on a single ward and is under the care of a single team of doctors. A patient may
be treated by any number of doctors but they must all be in the team that cares for the patient. A
doctor can treat any number of patients. The team leader accepts ultimate responsibility, legally
and otherwise, for the care of all the patients referred to him/her, even with many of the minuteto-minute decisions being made by subordinates.

Domain model - Patient, Doctors and Treatments

UML Structural Diagram:

UML structural diagrams are categorized as follows: class diagram, object diagram, component
diagram, and deployment diagram.

Class Diagram

A class diagram models the static view of a system. It comprises of the classes, interfaces, and
collaborations of a system; and the relationships between them.

Class Diagram of a System

Let us consider a simplified Banking System.
A bank has many branches. In each zone, one branch is designated as the zonal head office that
supervises the other branches in that zone. Each branch can have multiple accounts and loans. An
account may be either a savings account or a current account. A customer may open both a
savings account and a current account. However, a customer must not have more than one savings
account or current account. A customer may also procure loans from the bank.
The following figure shows the corresponding class diagram.

Classes in the system:

Bank, Branch, Account, Savings Account, Current Account, Loan, and Customer.

Relationships:

A Bank hasa number of Branches : composition, onetomany

A Branch with role Zonal Head Office supervises other Branches : unary association,
oneto-many

A Branch hasa number of accounts : aggregation, onetomany

From the class Account, two classes have inherited, namely, Savings Account and Current Account.

A Customer can have one Current Account : association, onetoone

A Customer can have one Savings Account : association, onetoone

A Branch hasa number of Loans : aggregation, onetomany

A Customer can take many loans : association, onetomany

Object Diagram
An object diagram models a group of objects and their links at a point of time. It shows the
instances of the things in a class diagram. Object diagram is the static part of an interaction
diagram.
Example : The following figure shows an object diagram of a portion of the class diagram of the
Banking System.

Component Diagram
Component diagrams show the organization and dependencies among a group of components.
Component diagrams comprise of:

Components

Interfaces

Relationships

Packages and Subsystems (optional)

Component diagrams are used for:

constructing systems through forward and reverse engineering.

modeling configuration management of source code files while developing a system using
an object-oriented programming language.

representing schemas in modeling databases.

modeling behaviors of dynamic systems.

Example
The following figure shows a component diagram to model a systems source code that is
developed using C++. It shows four source code files, namely, myheader.h, otherheader.h,
priority.cpp, and other.cpp. Two versions of myheader.h are shown, tracing from the recent version
to its ancestor. The file priority.cpp has compilation dependency on other.cpp. The file other.cpp has
compilation dependency on otherheader.h.

Deployment Diagram
A deployment diagram puts emphasis on the configuration of runtime processing nodes and their
components that live on them. They are commonly comprised of nodes and dependencies, or
associations between the nodes.

Deployment diagrams are used to:

model devices in embedded systems that typically comprise of software-intensive collection

of hardware.

represent the topologies of client/server systems.

model fully distributed systems.

Example
The following figure shows the topology of a computer system that follows client/server architecture.
The figure illustrates a node stereotyped as server that comprises of processors. The figure
indicates that four or more servers are deployed at the system. Connected to the server are the
client nodes, where each node represents a terminal device such as workstation, laptop, scanner,
or printer. The nodes are represented using icons that clearly depict the real-world equivalent.

The Sequence Diagram:

The sequence diagram is having four objects (Customer, Order, SpecialOrder and NormalOrder).
The following diagram has shown the message sequence for SpecialOrder object and the same
can be used in case of NormalOrder object. Now it is important to understand the time sequence of
message flows. The message flow is nothing but a method call of an object.
The first call is sendOrder () which is a method of Order object. The next call is confirm ()which is a
method

of SpecialOrder object

and

the

last

call

is Dispatch

() which

is

method

ofSpecialOrder object. So here the diagram is mainly describing the method calls from one object to
another and this is also the actual scenario when the system is running.

The Collaboration Diagram:

The second interaction diagram is collaboration diagram. It shows the object organization as shown
below. Here in collaboration diagram the method call sequence is indicated by some numbering
technique as shown below. The number indicates how the methods are called one after another.
We have taken the same order management system to describe the collaboration diagram.
The method calls are similar to that of a sequence diagram. But the difference is that the sequence
diagram does not describe the object organization where as the collaboration diagram shows the
object organization.

Now to choose between these two diagrams the main emphasis is given on the type of
requirement. If the time sequence is important then sequence diagram is used and if organization is
required then collaboration diagram is used.

How to draw Activity Diagram?

Activity diagrams are mainly used as a flow chart consists of activities performed by the system. But
activity diagram are not exactly a flow chart as they have some additional capabilities. These
additional capabilities include branching, parallel flow, swimlane etc.
Before drawing an activity diagram we must have a clear understanding about the elements used in
activity diagram. The main element of an activity diagram is the activity itself. An activity is a
function performed by the system. After identifying the activities we need to understand how they
are associated with constraints and conditions.
So before drawing an activity diagram we should identify the following elements:

Activities

Association

Conditions

Constraints

Once the above mentioned parameters are identified we need to make a mental layout of the entire
flow. This mental layout is then transformed into an activity diagram.
The following is an example of an activity diagram for order management system. In the diagram
four activities are identified which are associated with conditions. One important point should be
clearly understood that an activity diagram cannot be exactly matched with the code. The activity
diagram is made to understand the flow of activities and mainly used by the business users.
The following diagram is drawn with the four main activities:

Send order by the customer

Receipt of the order

Confirm order

Dispatch order

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

How to draw Class Diagram?

Class diagrams are the most popular UML diagrams used for construction of software applications.
So it is very important to learn the drawing procedure of class diagram.
Class diagrams have lot of properties to consider while drawing but here the diagram will be
considered from a top level view.
Class diagram is basically a graphical representation of the static view of the system and
represents different aspects of the application. So a collection of class diagrams represent the
whole system.
The following points should be remembered while drawing a class diagram:

The name of the class diagram should be meaningful to describe the aspect of the system.

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. Because unnecessary
properties will make the diagram complicated.

Use notes when ever required to describe some aspect of the diagram. Because 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
rework as many times as possible to make it correct.

Now the following diagram is an example of an Order System of an application. So it describes a

particular aspect of the entire application.

First of all Order and Customer are identified as the two elements of the system and they
have a one to many relationship because a customer can have multiple orders.

We would keep 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 ().

So the following class diagram has been drawn considering all the points mentioned above:

How to draw
UML behavioral diagrams visualize, specify, construct, and document the dynamic aspects of a
system. The behavioral diagrams are categorized as follows: use case diagrams, interaction
diagrams, statechart diagrams, and activity diagrams.

UML Behavioral Diagram:

Use Case Model

(a) Use case
A use case describes the sequence of actions a system performs yielding visible results. It shows
the interaction of things outside the system with the system itself. Use cases may be applied to the
whole system as well as a part of the system.

(b) Actor
An actor represents the roles that the users of the use cases play. An actor may be a person (e.g.
student, customer), a device (e.g. workstation), or another system (e.g. bank, institution).
The following figure shows the notations of an actor named Student and a use case called
Generate Performance Report.

(c) Use case diagrams

Use case diagrams present an outside view of the manner the elements in a system behave and
how they can be used in the context.
Use case diagrams comprise of:

Use cases

Actors

Relationships like dependency, generalization, and association

Use case diagrams are used:

To model the context of a system by enclosing all the activities of a system within a
rectangle and focusing on the actors outside the system by interacting with it.

To model the requirements of a system from the outside point of view.

Example

Let us consider an Automated Trading House System. We assume the following features of the
system:

The trading house has transactions with two types of customers, individual customers and
corporate customers.

Once the customer places an order, it is processed by the sales department and the
customer is given the bill.

The system allows the manager to manage customer accounts and answer any queries
posted by the customer.

Interaction Diagrams
Interaction diagrams depict interactions of objects and their relationships. They also include the
messages passed between them. There are two types of interaction diagrams:

Sequence Diagrams

Collaboration Diagrams

Interaction diagrams are used for modeling:

the control flow by time ordering using sequence diagrams.

the control flow of organization using collaboration diagrams.

Sequence Diagrams
Sequence diagrams are interaction diagrams that illustrate the ordering of messages according to
time.
Notations : These diagrams are in the form of two-dimensional charts. The objects that initiate the
interaction are placed on the xaxis. The messages that these objects send and receive are placed
along the yaxis, in the order of increasing time from top to bottom.
Example : A sequence diagram for the Automated Trading House System is shown in the following
figure.

Collaboration Diagrams
Collaboration diagrams are interaction diagrams that illustrate the structure of the objects that send
and receive messages.
Notations : In these diagrams, the objects that participate in the interaction are shown using
vertices. The links that connect the objects are used to send and receive messages. The message
is shown as a labeled arrow.
Example : Collaboration diagram for the Automated Trading House System is illustrated in the
figure below.

StateChart Diagrams
A statechart diagram shows a state machine that depicts the control flow of an object from one
state to another. A state machine portrays the sequences of states which an object undergoes due
to events and their responses to events.
StateChart Diagrams comprise of:

States: Simple or Composite

Transitions between states

Events causing transitions

Actions due to the events

State-chart diagrams are used for modeling objects which are reactive in nature.
Example
In the Automated Trading House System, let us model Order as an object and trace its sequence.
The following figure shows the corresponding statechart diagram.

Activity Diagrams
An activity diagram depicts the flow of activities which are ongoing non-atomic operations in a state
machine. Activities result in actions which are atomic operations.
Activity diagrams comprise of:

Activity states and action states

Transitions

Objects

Activity diagrams are used for modeling:

workflows as viewed by actors, interacting with the system.

details of operations or computations using flowcharts.

Example
The following figure shows an activity diagram of a portion of the Automated Trading House
System.

What is SDLC?
SDLC is a process followed for a software project, within a software organization. It consists of a
detailed plan describing how to develop, maintain, replace and alter or enhance specific software.
The life cycle defines a methodology for improving the quality of software and the overall
development process.

The following figure is a graphical representation of the various stages of a typical SDLC.

Waterfall Model design

Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure
success of the project. In "The Waterfall" approach, the whole process of software development is
divided into separate phases. In Waterfall model, typically, the outcome of one phase acts as the
input for the next phase sequentially.
Following is a diagrammatic representation of different phases of waterfall model.

The sequential phases in Waterfall model are:

Requirement Gathering and analysis: All possible requirements of the system to be

developed are captured in this phase and documented in a requirement specification doc.

System Design: The requirement specifications from first phase are studied in this phase
and system design is prepared. System Design helps in specifying hardware and system
requirements and also helps in defining overall system architecture.

Implementation: With inputs from system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality which is referred to as Unit Testing.

Integration and Testing: All the units developed in the implementation phase are integrated
into a system after testing of each unit. Post integration the entire system is tested for any
faults and failures.

Deployment of system: Once the functional and non functional testing is done, the product
is deployed in the customer environment or released into the market.

Maintenance: There are some issues which come up in the client environment. To fix those
issues patches are released. Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer environment.

All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the defined
set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model". In
this model phases do not overlap.

What is Agile?
Agile model believes that every project needs to be handled differently and the existing methods
need to be tailored to best suit the project requirements. In agile the tasks are divided to time boxes
(small time frames) to deliver specific features for a release.
Iterative approach is taken and working software build is delivered after each iteration. Each build is
incremental in terms of features; the final build holds all the features required by the customer.
Here is a graphical illustration of the Agile Model:

Agile thought process had started early in the software development and started becoming popular
with time due to its flexibility and adaptability.
The most popular agile methods include Rational Unified Process (1994), Scrum (1995), Crystal
Clear,

Extreme

Programming

(1996),

Adaptive

Software

Development,

Feature

Driven

Development, and Dynamic Systems Development Method (DSDM) (1995). These are now
collectively referred to as agile methodologies, after the Agile Manifesto was published in 2001.
Following are the Agile Manifesto principles

Individuals and interactions - in agile development, self-organization and motivation are

important, as are interactions like co-location and pair programming.

Working software - Demo working software is considered the best means of

communication with the customer to understand their requirement, instead of just depending
on documentation.

Customer collaboration - As the requirements cannot be gathered completely in the

beginning of the project due to various factors, continuous customer interaction is very
important to get proper product requirements.

Responding to change - agile development is focused on quick responses to change and

continuous development.

Unified process:

Project Lifecycle (Phases of Unified Process)[edit]

The Unified Process divides the project into four phases:

Inception

Elaboration

Construction

Transition

Inception Phase[edit]
Inception is the smallest phase in the project, and ideally it should be quite short. If the Inception
Phase is long then it may be an indication of excessive up-front specification, which is contrary to the
spirit of the Unified Process.
The following are typical goals for the Inception phase.

Establish a justification or business case for the project

Establish the project scope and boundary conditions

Outline the use cases and key requirements that will drive the design tradeoffs

Outline one or more candidate architectures

Identify risks

Prepare a preliminary project schedule and cost estimate

The Lifecycle Objective Milestone marks the end of the Inception phase.
Develop an approximate vision of the system, make the business case, define the scope, and
produce rough estimate for cost and schedule.

Elaboration Phase[edit]
During the Elaboration phase the project team is expected to capture a healthy majority of the
system requirements. However, the primary goals of Elaboration are to address known risk factors
and to establish and validate the system architecture. Common processes undertaken in this phase
include the creation of use case diagrams, conceptual diagrams (class diagrams with only basic
notation) andpackage diagrams (architectural diagrams).
The architecture is validated primarily through the implementation of an Executable Architecture
Baseline. This is a partial implementation of the system which includes the core, most architecturally
significant, components. It is built in a series of small, time boxed iterations. By the end of the
Elaboration phase the system architecture must have stabilized and the executable architecture

baseline must demonstrate that the architecture will support the key system functionality and exhibit
the right behavior in terms of performance, scalability and cost.
The final Elaboration phase deliverable is a plan (including cost and schedule estimates) for the
Construction phase. At this point the plan should be accurate and credible, since it should be based
on the Elaboration phase experience and since significant risk factors should have been addressed
during the Elaboration phase.

Construction Phase[edit]
Construction is the largest phase in the project. In this phase the remainder of the system is built on
the foundation laid in Elaboration. System features are implemented in a series of short, timeboxed
iterations. Each iteration results in an executable release of the software. It is customary to write full
text use cases during the construction phase and each one becomes the start of a new iteration.
Common UML (Unified Modelling Language) diagrams used during this phase include Activity,
Sequence, Collaboration, State (Transition) and Interaction.

Transition Phase[edit]
The final project phase is Transition. In this phase the system is deployed to the target users.
Feedback received from an initial release (or initial releases) may result in further refinements to be
incorporated over the course of several Transition phase iterations. The Transition phase also
includes system conversions and user training.

Scrum Definition
Scrum is a framework within which people can address complex adaptive problems, while
productively and creatively delivering products of the highest possible value.
Scrum is a process framework that has been used to manage complex product development since
the early 1990s. Scrum is not a process or a technique for building products; rather, it is a
framework within which you can employ various processes and techniques. Scrum makes clear the
relative efficacy of your product management and development practices so that you can improve.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and
rules. Each component within the framework serves a specific purpose and is essential to Scrums
success and usage.
The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and
interaction between them. The rules of Scrum are described throughout this tutorial.
Note - Across the industry, there are misconceptions that Scrum means no documentation, scrum
team consists of only developers, and so on. It is not entirely so; we will give clarifications on these
in later sections.

Scrum Process Framework

In Scrum, the prescribed events are used to create regularity. All events are time-boxed events,
such that every event has a maximum duration. The events are described more elaborately in the
subsequent chapters.