Chapter 1: History and overview

• Introduction

• Evolution of software engineering

• Process frame work

INTRODUCTION TO SOFTWARE ENGINEERING

Software: Software is (1) Instructions (computer programs) that provide desired features,
function, and performance, when
executed (2) Data structures that enable the programs to adequately manipulate
information, (3) Documents that describe the operation and use of the programs.
Characteristics of Software:
(1) Software is developed or engineered; it is not manufactured in the classical sense.
(2) Software does not “wear out”
(3) Although the industry is moving toward component-based construction, most
software continues to
be custom built.
Software Engineering:
(1) The systematic, disciplined quantifiable approach to the development, operation and
maintenance of
software; that is, the application of engineering to software.
(2) The study of approaches as in (1)

EVOLVING ROLE OF SOFTWARE:

Software takes dual role. It is both a product and a vehicle for delivering a product.
As a product: It delivers the computing potential embodied by computer Hardware or by
a network
of computers.
As a vehicle: It is information transformer-producing, managing, acquiring, modifying,
displaying,
or transmitting information that can be as simple as single bit or as complex as a
multimedia presentation.
Software delivers the most important product of our time-information.
- It transforms personal data
- It manages business information to enhance competitiveness
- It provides a gateway to worldwide information networks
- It provides the means for acquiring information
 The role of computer software has undergone significant change over a span of little
more than 50 years
- Dramatic Improvements in hardware performance
- Vast increases in memory and storage capacity
- A wide variety of exotic input and output options
THE CHANGING NATURE OF SOFTWARE:
The 7 broad categories of computer software present continuing challenges for software
engineers:
1) System software
2) Application software
3) Engineering/scientific software
4) Embedded software
5) Product-line software
6) Web-applications
7) Artificial intelligence software.
System software: System software is a collection of programs written to service other programs.
The systems software is characterized by
- heavy interaction with computer hardware
- heavy usage by multiple users
- concurrent operation that requires scheduling, resource sharing, and sophisticated process
management
- complex data structures
- multiple external interfaces
E.g. compilers, editors and file management utilities.
Application software:
- Application software consists of standalone programs that solve a specific business need.
- It facilitates business operations or management/technical decision making.
- It is used to control business functions in real-time
E.g. point-of-sale transaction processing, real-time manufacturing process control.
Engineering/Scientific software: Engineering and scientific applications range
- from astronomy to volcanology
- from automotive stress analysis to space shuttle orbital dynamics
- from molecular biology to automated manufacturing
E.g. computer aided design, system simulation and other interactive applications.
Embedded software:
- Embedded software resides within a product or system and is used to implement and
control features and functions for the end-user and for the system itself.
- It can perform limited and esoteric functions or provide significant function and control
capability.
E.g. Digital functions in automobile, dashboard displays, braking systems etc.
Product-line software: Designed to provide a specific capability for use by many different
customers, product-line software can focus on a limited and esoteric market place or address
mass consumer markets
E.g. Word processing, spreadsheets, computer graphics, multimedia, entertainment, database
management, personal and business financial applications
Web-applications: WebApps are evolving into sophisticated computing environments that not
only provide standalone features, computing functions, and content to the end user, but also are
integrated with corporate databases and business applications.
Artificial intelligence software: AI software makes use of nonnumerical algorithms to solve
complex problems that are not amenable to computation or straightforward analysis. Application
within this area includes robotics, expert systems, pattern recognition, artificial neural networks,
theorem proving, and game playing.

A PROCESS FRAMEWORK:
➢ Software process must be established for effective delivery of software engineering
technology.
➢ A process framework establishes the foundation for a complete software process by
identifying a small number of framework activities that are applicable to all software projects,
regardless of their size or complexity.
➢ The process framework encompasses a set of umbrella activities that are applicable across
the entire software process.
➢ Each framework activity is populated by a set of software engineering actions
➢ Each software engineering action is represented by a number of different task sets- each a
collection of software engineering work tasks, related work products, quality assurance points,
and project milestones.
In brief
"A process defines who is doing what, when, and how to reach a certain goal."
A Process Framework
- establishes the foundation for a complete software process
- identifies a small number of framework activities
- applies to all s/w projects, regardless of size/complexity.
- also, set of umbrella activities
- applicable across entire s/w process.
- Each framework activity has
- set of s/w engineering actions.
- Each s/w engineering action (e.g., design) has

- collection of related tasks (called task sets):

work tasks
work products (deliverables)
quality assurance points
project milestones.

Generic Process Framework: It is applicable to the vast majority of software projects

- Communication activity
- Planning activity
- Modeling activity
- analysis action
- requirements gathering work task
- elaboration work task
- negotiation work task
- specification work task
- validation work task
- design action
- data design work task
- architectural design work task
- interface design work task
- component-level design work task
- Construction activity
- Deployment activity
1) Communication: This framework activity involves heavy communication and collaboration
with the customer and encompasses requirements gathering and other related activities.
2) Planning: This activity establishes a plan for the software engineering work that follows. It
describes the technical tasks to be conducted, the risks that are likely, the resources that will be
required, the work products to be produced, and a work schedule.
3) Modeling: This activity encompasses the creation of models that allow the developer and
customer to better understand software requirements and the design that will achieve those
requirements. The modeling activity is composed of 2 software engineering actions- analysis and
design.
✓ Analysis encompasses a set of work tasks.
✓ Design encompasses work tasks that create a design model.
4) Construction: This activity combines core generation and the testing that is required to
uncover the errors in the code.
5) Deployment: The software is delivered to the customer who evaluates the delivered product
and provides feedback based on the evolution.
These 5 generic framework activities can be used during the development of small programs, the
creation of large web applications, and for the engineering of large, complex computer-based
systems.
The following are the set of Umbrella Activities.
1) Software project tracking and control – allows the software team to assess progress against
the project plan and take necessary action to maintain schedule.
2) Risk Management - assesses risks that may effect the outcome of the project or the quality of
the product.
3) Software Quality Assurance - defines and conducts the activities required to ensure software
quality.
4) Formal Technical Reviews - assesses software engineering work products in an effort to
uncover and remove errors before they are propagated to the next action or activity.
Chapter 2: Software process models
• waterfall model
• incremental model
• RAD model
• Prototype model
• Spiral model
• Rational unified process

PROCESS MODELS
Prescriptive process models define a set of activities, actions, tasks, milestones, and work
products that are required to engineer high-quality software. These process models are not
perfect, but they do provide a useful roadmap for software engineering work.
A prescriptive process model populates a process framework with explicit task sets for software
engineering actions.

THE WATERFALL MODEL:

The waterfall model, sometimes called the classic life cycle, suggests a systematic sequential
approach to software development that begins with customer specification of requirements and
progresses through planning, modeling, construction, and deployment.
Context: Used when requirements are reasonably well understood.

Advantage:
It can serve as a useful process model in situations where requirements are fixed and work is to
proceed to complete in a linear manner.
The problems that are sometimes encountered when the waterfall model is applied are:
1. Real projects rarely follow the sequential flow that the model proposes. Although the linear
model can accommodate iteration, it does so indirectly. As a result, changes can cause confusion
as the project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly. The waterfall model
requires this and has difficulty accommodating the natural uncertainty that exist at the beginning
of many projects.
3. The customer must have patience. A working version of the programs will not be available
until late in the project time-span. If a major blunder is undetected then it can be disastrous until
the program is reviewed.

INCREMENTAL PROCESS MODELS:

1) The incremental model
2) The RAD model

THE INCREMENTAL MODEL:

Context: Incremental development is particularly useful when staffing is unavailable for a
complete implementation by the business deadline that has been established for the project. Early
increments can be implemented with fewer people. If the core product is well received,
additional staff can be added to implement the next increment. In addition, increments can be
planned to manage technical risks.

The incremental model combines elements of the waterfall model applied in an iterative fashion.
• The incremental model delivers a series of releases called increments that provide
progressively more functionality for the customer as each increment is delivered.
• When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed. The core product is used by the customer. As a result, a plan is
developed for the next increment.
• The plan addresses the modification of the core product to better meet the needs of the
customer and the delivery of additional features and functionality.
• This process is repeated following the delivery of each increment, until the complete product is
produced. For example, word-processing software developed using the incremental paradigm
might deliver basic file management editing, and document production functions in the first
increment; more sophisticated editing, and document production capabilities in the second
increment; spelling and grammar checking in the third increment; and advanced page layout
capability in the fourth increment.

THE RAD MODEL:

Rapid Application Development (RAD) is an incremental software process model that
emphasizes a short development cycle. The RAD model is a “high-speed” adaption of the
waterfall model, in which rapid development is achieved by using a component base construction
approach.
Context: If requirements are well understood and project scope is constrained, the RAD process
enables a development team to create a “fully functional system” within a very short time period.
The RAD approach maps into the generic framework activities.
Communication works to understand the business problem and the information characteristics
that the software must accommodate.
Planning is essential because multiple software teams works in parallel on different system
functions.
Modeling encompasses three major phases- business modeling, data modeling and process
modeling- and establishes design representation that serve existing software components and the
application of automatic code generation.
Deployment establishes a basis for subsequent iterations.
The RAD approach has drawbacks:
For large, but scalable projects, RAD requires sufficient human resources to create the right
number of RAD teams.
If developers and customers are not committed to the rapid-fire activities necessary to complete
the system in a much abbreviated time frame, RAD projects will fail
If a system cannot be properly modularized, building the components necessary for RAD will be
problematic If high performance is an issue, and performance is to be achieved through tuning
the interfaces to system components, the RAD approach may not work; and
RAD may not be appropriate when technical risks are high.

PROTOTYPING:
Prototyping is more commonly used as a technique that can be implemented within the context
of anyone of the process model.

The prototyping paradigm begins with communication. The software engineer and customer
meet and define the overall objectives for the software, identify whatever requirements are
known, and outline areas where further definition is mandatory.
Prototyping iteration is planned quickly and modeling occurs. The quick design leads to the
construction of a prototype. The prototype is deployed and then evaluated by the customer/user.
Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same
time enabling the developer to better understand what needs to be done.
Context:
If a customer defines a set of general objectives for software, but does not identify detailed input,
processing, or output requirements, in such situation prototyping paradigm is best approach.
If a developer may be unsure of the efficiency of an algorithm, the adaptability of an operating
system then he can go for this prototyping method.
Advantages:
The prototyping paradigm assists the software engineer and the customer to better understand
what is to be built when requirements are fuzzy.
The prototype serves as a mechanism for identifying software requirements. If a working

THE SPIRAL MODEL

• The spiral model, originally proposed by Boehm, is an evolutionary software process model
that couples the iterative nature of prototyping with the controlled and systematic aspects of the
waterfall model.
• The spiral model can be adapted to apply throughout the entire life cycle of an application,
from concept development to maintenance.
• Using the spiral model, software is developed in a series of evolutionary releases. During early
iterations, the release might be a paper model or prototype. During later iterations, increasingly
morecomplete versions of the engineered system are produced.
project.” In essence, the spiral, when characterized in this way, remains operative until the
software is retired.
Context: The spiral model can be adopted to apply throughout the entire life cycle of an
application, from concept development to maintenance.
Advantages:
It provides the potential for rapid development of increasingly more complete versions of the
software.

The spiral model is a realistic approach to the development of large-scale systems and software.
The spiral
model uses prototyping as a risk reduction mechanism but, more importantly enables the
developer to apply the prototyping approach at any stage in the evolution of the product.
Draw Backs:
The spiral model is not a panacea. It may be difficult to convince customers that the evolutionary
approach is controllable. It demands considerable risk assessment expertise and relies on this
expertise for success. If a major risk is not uncovered and managed, problems will undoubtedly
occur.

THE UNIFIED PROCESS:

The unified process (UP) is an attempt to draw on the best features and characteristics of
conventional software process models, but characterize them in a way that implements many of
the best principles of agile software development.
The Unified process recognizes the importance of customer communication and streamlined
methods for describing the customer’s view of a system. It emphasizes the important role of
software architecture and “helps the architect focus on the right goals, such as understandability,
reliance to future changes, and reuse“. If suggests a process flow that is iterative and incremental,
providing the evolutionary feel that is essential in modern software development.
A BRIEF HISTORY:
During the 1980s and into early 1990s, object-oriented (OO) methods and programming
languages gained a widespread audience throughout the software engineering community. A
wide variety of object oriented analysis (OOA) and design (OOD) methods were proposed
during the same time period.
During the early 1990s James Rumbaugh, Grady Booch, and Ival Jacobsom began working on a
“Unified method” that would combine the best features of each of OOD & OOA. The result was
UML- a unified modeling language that contains a robust notation fot the modeling and
development of OO systems.
By 1997, UML became an industry standard for object-oriented software development. At the
same time, the Rational Corporation and other vendors developed automated tools to support
UML methods.
Over the next few years, Jacobson, Rumbugh, and Booch developed the Unified process, a
framework for object-oriented software engineering using UML. Today, the Unified process and
UML are widely used on OO projects of all kinds. The iterative, incremental model proposed by
the UP can and should be adapted to meet specific project needs.

PHASES OF THE UNIFIED PROCESS:

The inception phase of the UP encompasses both customer communication and planning
activities. By collaborating with the customer and end-users, business requirements for the
software are identified, a rough architecture for the system is proposed and a plan for the
iterative, incremental nature of the ensuing project is developed.
The elaboration phase encompasses the customer communication and modeling activities of the
generic process model. Elaboration refines and expands the preliminary use-cases that were
developed as part of the inception phase and expands the architectural representation to include
five different views of the software- the use-case model, the analysis model, the design model,
the implementation model, and the deployment model.
The construction phase of the UP is identical to the construction activity defined for the generic
software process. Using the architectural model as input, the construction phase develops or
acquires the software components that will make each use-case operational for end-users. To
accomplish this, analysis and design models that were started during the elaboration phase are
completed to reflect the final version of the software increment.
The transition phase of the UP encompasses the latter stages of the generic construction activity
and the first part of the generic deployment activity. Software given to end-users for beta testing,
and user feedback reports both defects and necessary changes.
The production phase of the UP coincides with the deployment activity of the generic process.
During this phase, the on-going use of the software is monitored, support for the operating
environment is provided, and defect reports and requests for changes are submitted and
evaluated.
Chapter 3 Requirements engineering

3.1 Functional and non-functional requirements

3.2 The software requirements document

3.3 Requirements specification

3.4 Requirements engineering processes

3.5 Requirements elicitation and analysis

3.1 Functional and non-functional requirements

Software system requirements are often classified as functional requirements or
nonfunctional requirements:

1. Functional requirements These are statements of services the system should

provide, how the system should react to particular inputs, and how the system
2. should behave in particular situations. In some cases, the functional requirements
may also explicitly state what the system should not do.
3. 2. Non-functional requirements These are constraints on the services or functions
offered by the system. They include timing constraints, constraints on the
development process, and constraints imposed by standards. Non-functional
requirements often apply to the system as a whole, rather than individual system
features or services.
4. In reality, the distinction between different types of requirement is not as clear-cut
as these simple definitions suggest. A user requirement concerned with security,
such as a statement limiting access to authorized users, may appear to be a
nonfunctional requirement. However, when developed in more detail, this
requirement may generate other requirements that are clearly functional, such as
the need to include user authentication facilities in the system. This shows that
requirements are not independent and that one requirement often generates or
constrains other requirements. The system requirements therefore do not just
specify the services or the features of the system that are required; they also specify
the necessary functionality to ensure that these services/features are delivered
properly.

Functional requirements

The functional requirements for a system describe what the system should do.
These requirements depend on the type of software being developed, the expected
users of the software, and the general approach taken by the organization when
writing requirements. When expressed as user requirements, functional
requirements are usually described in an abstract way that can be understood by
system users. However, more specific functional system requirements describe the
system functions, its inputs and outputs, exceptions, etc., in detail.

Non-functional requirements
Non-functional requirements, as the name suggests, are requirements that are not
directly concerned with the specific services delivered by the system to its users.
They may relate to emergent system properties such as reliability, response time,
and store occupancy. Alternatively, they may define constraints on the system
implementation such as the capabilities of I/O devices or the data representations
used in interfaces with other systems. Non-functional requirements, such as
performance, security, or availability, usually specify or constrain characteristics of
the system as a whole. Non-functional requirements are often more critical than
individual functional requirements. System users can usually find ways to work
around a system function that doesn’t really meet their needs. However, failing to
meet a non-functional requirement can mean that the whole system is unusable. For
example, if an aircraft system does not meet its reliability requirements, it will not
be certified as safe for operation; if an embedded control system fails to meet its
performance requirements, the control functions will not operate correctly.
Although it is often possible to identify which system components implement
specific functional requirements (e.g., there may be formatting components that
implement reporting requirements), it is often more difficult to relate components
to non-functional requirements. The implementation of these requirements may be
diffused throughout the system. There are two reasons for this:
1. Non-functional requirements may affect the overall architecture of a system
rather than the individual components. For example, to ensure that performance
requirements are met, you may have to organize the system to minimize
communications between components.
2. A single non-functional requirement, such as a security requirement, may
generate a number of related functional requirements that define new system
services that are required. In addition, it may also generate requirements that
restrict existing requirements.

3.2 The software requirements document

The software requirements document (sometimes called the software requirements
specification or SRS) is an official statement of what the system developers should
implement. It should include both the user requirements for a system and a detailed
specification of the system requirements. Sometimes, the user and system
requirements are integrated into a single description. In other cases, the user
requirements are defined in an introduction to the system requirements
specification. If there are a large number of requirements, the detailed system
requirements may be presented in a separate document. Requirements documents
are essential when an outside contractor is developing the software system.
However, agile development methods argue that requirements change so rapidly
that a requirements document is out of date as soon as it is written, so the effort is
largely wasted. Rather than a formal document, approaches such as Extreme
Programming (Beck, 1999) collect user requirements incrementally and write these
on cards as user stories. The user then prioritizes requirements for implementation
in the next increment of the system. For business systems where requirements are
unstable, I think that this approach is a good one. However, I think that it is still
useful to write a short supporting document that defines the business and
dependability requirements for the system; it is easy to forget the requirements that
apply to the system as a whole when focusing on the functional requirements for the
next system release. The diversity of possible users means that the requirements
document has to be a compromise between communicating the requirements to
customers, defining the requirements in precise detail for developers and testers,
and including information about possible system evolution. Information on
anticipated changes can help system designers avoid restrictive design decisions
and help system maintenance engineers who have to adapt the system to new
requirements. The level of detail that you should include in a requirements
document depends on the type of system that is being developed and the
development process used. Critical systems need to have detailed requirements
because safety and security have to be analyzed in detail. When the system is to be
developed by a separate company (e.g., through outsourcing), the system
specifications need to be detailed and precise. If an inhouse, iterative development
process is used, the requirements document can be much less detailed and any
ambiguities can be resolved during development of the system.
3.3 Requirements specification
Requirements specification is the process of writing down the user and system
requirements in a requirements document. Ideally, the user and system
requirements should be clear, unambiguous, easy to understand, complete, and
consistent. In practice, this is difficult to achieve as stakeholders interpret the
requirements in different ways and there are often inherent conflicts and
inconsistencies in the requirements. The user requirements for a system should
describe the functional and nonfunctional requirements so that they are
understandable by system users who don’t have detailed technical knowledge.
Ideally, they should specify only the external behavior of the system. The
requirements document should not include details of the system architecture or
design. Consequently, if you are writing user requirements, you should not use
software jargon, structured notations, or formal notations. You should write user
requirements in natural language, with simple tables, forms, and intuitive diagrams.
System requirements are expanded versions of the user requirements that are used
by software engineers as the starting point for the system design. They add detail
and explain how the user requirements should be provided by the system. They may
be used as part of the contract for the implementation of the system and should
therefore be a complete and detailed specification of the whole system. Ideally, the
system requirements should simply describe the external behavior of the system
and its operational constraints. They should not be concerned with how the system
should be designed or implemented. However, at the level of detail required to
completely specify a complex software system, it is practically impossible to exclude
all design information. There are several reasons for this:
1. You may have to design an initial architecture of the system to help structure the
requirements specification. The system requirements are organized according tothe
different sub-systems that make up the system. As I discuss in Chapters 6 and 18,
this architectural definition is essential if you want to reuse software components
when implementing the system.
2. In most cases, systems must interoperate with existing systems, which constrain
the design and impose requirements on the new system.
3. The use of a specific architecture to satisfy non-functional requirements (such as
N-version programming to achieve reliability, discussed in Chapter 13) may be
necessary. An external regulator who needs to certify that the system is safe may
specify that an already certified architectural design be used.
User requirements are almost always written in natural language supplemented by
appropriate diagrams and tables in the requirements document. System
requirements may also be written in natural language but other notations based on
forms, graphical system models, or mathematical system models can also be used.
3.4 Requirements engineering processes
The activities are organized as an iterative process around a spiral, with the output
being a system requirements document. The amount of time and effort devoted to
each activity in each iteration depends on the stage of the overall process and the
type of system being developed. Early in the process, most effort will be spent on
understanding high-level business and non-functional requirements, and the user
requirements for the system. Later in the process, in the outer rings of the spiral,
more effort will be devoted to eliciting and understanding the detailed system
requirements. This spiral model accommodates approaches to development where
the requirements are developed to different levels of detail. The number of
iterations around the spiral can vary so the spiral can be exited after some or all of
the user requirements have been elicited. Agile development can be used instead of
prototyping so that the requirements and the system implementation are developed
together. Some people consider requirements engineering to be the process of
applying a structured analysis method, such as object-oriented analysis (Larman,
2002). This involves analyzing the system and developing a set of graphical system
models, such as use case models, which then serve as a system specification. The set
of models describes the behavior of the system and is annotated with additional
information describing, for example, the system’s required performance or
reliability. Although structured methods have a role to play in the requirements
engineering process, there is much more to requirements engineering than is
covered by these methods. Requirements elicitation, in particular, is a human-
centered activity and people dislike the constraints imposed on it by rigid system
models. In virtually all systems, requirements change. The people involved develop
a better understanding of what they want the software to do; the organization
buying the system changes; modifications are made to the system’s hardware,
software, and organizational environment. The process of managing these changing
requirements is called requirements management,

3.5 Requirements elicitation and analysis

After an initial feasibility study, the next stage of the requirements engineering
process is requirements elicitation and analysis. In this activity, software engineers
work with customers and system end-users to find out about the application
domain, what services the system should provide, the required performance of the
system, hardware constraints, and so on.
Requirements elicitation and analysis may involve a variety of different kinds of
people in an organization. A system stakeholder is anyone who should have some
direct or indirect influence on the system requirements. Stakeholders include
endusers who will interact with the system and anyone else in an organization who
will be affected by it. Other system stakeholders might be engineers who are
developing or maintaining other related systems, business managers, domain
experts, and trade union representatives. A process model of the elicitation and
analysis process is shown in Figure 4.13. Each organization will have its own
version or instantiation of this general model depending on local factors such as the
expertise of the staff, the type of system being developed, the standards used, etc.
The process activities are:
1. Requirements discovery This is the process of interacting with stakeholders of the
system to discover their requirements. Domain requirements from stakeholders and
documentation are also discovered during this activity. There are several
complementary techniques that can be used for requirements discovery, which I
discuss later in this section.
2. Requirements classification and organization This activity takes the unstructured
collection of requirements, groups related requirements, and organizes them into
coherent clusters. The most common way of grouping requirements is to use a
model of the system architecture to identify sub-systems and to associate
requirements with each sub-system. In practice, requirements engineering and
architectural design cannot be completely separate activities.
3. Requirements prioritization and negotiation Inevitably, when multiple
stakeholders are involved, requirements will conflict. This activity is concerned with
prioritizing requirements and finding and resolving requirements conflicts through
negotiation. Usually, stakeholders have to meet to resolve differences and agree on
compromise requirements.
4.Requirements specification The requirements are documented and input into the
next round of the spiral. Formal or informal requirements documents may be
produced
 Chapter 4 and 5 Object Oriented Analysis and Design through UML

The UML is a graphical language for visualizing, specifying, constructing, and documenting the artifacts
of a software-intensive system. The UML gives you a standard way to write a system's blueprints,
covering conceptual things, such as business processes and system functions, as well as concrete things,
such as classes written in a specific programming language, database schemas, and reusable software
components.

Model

A model is a simplification of reality. A model provides the blueprints of a system. A model may be
structural, emphasizing the organization of the system, or it may be behavioral, emphasizing the
dynamics of the system.

Why do we model

We build models so that we can better understand the system we are developing.

Through modeling, we achieve four aims.

1. Models help us to visualize a system as it is or as we want it to be.

2. Models permit us to specify the structure or behavior of a system.
3. Models give us a template that guides us in constructing a system.
4. Models document the decisions we have made.

We build models of complex systems because we cannot comprehend such a system in its entirety.

An Overview of UML

• The Unified Modeling Language is a standard language for writing software blueprints. The UML
may be used to visualize, specify, construct, and document the artifacts of a software-intensive
system.
• The UML is appropriate for modeling systems ranging from enterprise information systems to
distributed Web-based applications and even to hard real time embedded systems. It is a very
expressive language, addressing all the views needed to develop and then deploy such systems.
 The UML is a language for

• Visualizing
• Specifying
• Constructing
• Documenting
• Visualizing The UML is more than just a bunch of graphical symbols. Rather, behind each symbol
in the UML notation is a well-defined semantics. In this manner, one developer can write a model in
the UML, and another developer, or even another tool, can interpret that model unambiguously
• Specifying means building models that are precise, unambiguous, and complete.
• Constructing the UML is not a visual programming language, but its models can be directly
connected to a variety of programming languages
• Documenting a healthy software organization produces all sorts of artifacts in addition to raw
executable code. These artifacts include
o Requirements
o Architecture
o Design
o Source code
o Project plans
o Tests
o Prototypes
o Releases
To understand the UML, you need to form a conceptual model of the language, and this requires
learning three major elements:

1. Things
2. Relationships
3. Diagrams
Things in the UML

There are four kinds of things in the UML:

1 Structural things
2 Behavioral things
3 Grouping things
4 Annotational things

Structural things are the nouns of UML models. These are the mostly static parts of a model,
representing elements that are either conceptual or physical. In all, there are seven kinds of structural
things.

1. Classes
2. Interfaces
3. Collaborations
 4. Use cases
5. Active classes
6. Components
7. Nodes
Class is a description of a set of objects that share the same attributes, operations, relationships, and
semantics. A class implements one or more interfaces. Graphically, a class is rendered as a rectangle,
usually including its name, attributes, and operations.

Interface

1 Interface is a collection of operations that specify a service of a class or component.

2 An interface therefore describes the externally visible behavior of that element.
3 An interface might represent the complete behavior of a class or component or only a part of
that behavior.

An interface is rendered as a circle together with its name. An interface rarely stands alone. Rather, it is
typically attached to the class or component that realizes the interface

Collaboration defines an interaction and is a society of roles and other elements that work together to
provide some cooperative behavior that's bigger than the sum of all the elements. Therefore,
collaborations have structural, as well as behavioral, dimensions. A given class might participate in
several collaborations.

Graphically, collaboration is rendered as an ellipse with dashed lines, usually including only its name
Usecase

• Use case is a description of set of sequence of actions that a system performs that yields an
observable result of value to a particular actor
• Use case is used to structure the behavioral things in a model.
• A use case is realized by collaboration. Graphically, a use case is rendered as an ellipse with solid
lines, usually including only its name

Active class is just like a class except that its objects represent elements whose behavior is concurrent
with other elements. Graphically, an active class is rendered just like a class, but with heavy lines, usually
including its name, attributes, and operations

Component is a physical and replaceable part of a system that conforms to and provides the realization
of a set of interfaces. Graphically, a component is rendered as a rectangle with tabs
Node is a physical element that exists at run time and represents a computational resource, generally
having at least some memory and, often, processing capability. Graphically, a node is rendered as a
cube, usually including only its name

Behavioral Things

are the dynamic parts of UML models. These are the verbs of a model, representing behavior over time
and space. In all, there are two primary kinds of behavioral things

1 Interaction
2 state machine
Interaction

Interaction is a behavior that comprises a set of messages exchanged among a set of objects within a
particular context to accomplish a specific purpose

An interaction involves a number of other elements, including messages, action sequences and links

Graphically a message is rendered as a directed line, almost always including the name of its operation

State Machine

State machine is a behavior that specifies the sequences of states an object or an interaction goes
through during its lifetime in response to events, together with its responses to those events

State machine involves a number of other elements, including states, transitions, events and activities

Graphically, a state is rendered as a rounded rectangle, usually including its name and its sub states
Grouping Things:-

1. are the organizational parts of UML models. These are the boxes into which a model can be
decomposed
2. There is one primary kind of grouping thing, namely, packages.

Package:-

• A package is a general-purpose mechanism for organizing elements into groups. Structural things,
behavioral things, and even other grouping things may be placed in a package
• Graphically, a package is rendered as a tabbed folder, usually including only its name and,
sometimes, its contents

Annotational things are the explanatory parts of UML models. These are the comments you may apply
to describe about any element in a model.

1 A note is simply a symbol for rendering constraints and comments attached to an element or a
collection of elements.
2 Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or
graphical comment

Relationships in the UML:

There are four kinds of relationships in the UML:

1. Dependency
2. Association
3. Generalization
4. Realization
Dependency:-
1 Dependency is a semantic relationship between two things in which a change to one thing may
affect the semantics of the other thing
2 Graphically a dependency is rendered as a dashed line, possibly directed, and occasionally
including a label

Association is a structural relationship that describes a set of links, a link being a connection among
objects.

Graphically an association is rendered as a solid line, possibly directed, occasionally including a label,
and often containing other adornments, such as multiplicity and role names

Aggregation is a special kind of association, representing a structural relationship between a whole and
its parts. Graphically, a generalization relationship is rendered as a solid line with a hollow arrowhead
pointing to the parent

Generalization
in which objects of the specialized element (the child) are more specific than the objects of the
generalized element.
Realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that
another classifier guarantees to carry out. Graphically a realization relationship is rendered as a cross
between a generalization and a dependency relationship

Diagrams in the UML

• Diagram is the graphical presentation of a set of elements, most often rendered as a connected
graph of vertices (things) and arcs (relationships).
• In theory, a diagram may contain any combination of things and relationships.
• For this reason, the UML includes nine such diagrams:
• Class diagram
• Object diagram
• Use case diagram
• Sequence diagram
• Collaboration diagram
• State chart diagram
• Activity diagram
 • Component diagram
• Deployment diagram

Class diagram

A class diagram shows a set of classes, interfaces, and collaborations and their relationships.

Object diagram

• Object diagrams represent static snapshots of instances of the things found in class diagrams
• These diagrams address the static design view or static process view of a system
 • An object diagram shows a set of objects and their relationships

Use case diagram

• A use case diagram shows a set of use cases and actors and their relationships
• Use case diagrams address the static use case view of a system.
• These diagrams are especially important in organizing and modeling the behaviors of a system.

Interaction Diagrams

Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams

Interaction diagrams address the dynamic view of a system

A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages

A collaboration diagram is an interaction diagram that emphasizes the structural organization of the
objects that send and receive messages

Sequence diagrams and collaboration diagrams are isomorphic, meaning that you can take one and
transform it into the other

State chart diagram

• A state chart diagram shows a state machine, consisting of states, transitions, events, and
activities
• State chart diagrams address the dynamic view of a system
• They are especially important in modeling the behavior of an interface, class, or collaboration
and emphasize the event-ordered behavior of an object
Activity diagram

1 An activity diagram is a special kind of a state chart diagram that shows the flow from activity to
activity within a system
2 Activity diagrams address the dynamic view of a system
3 They are especially important in modeling the function of a system and emphasize the flow of
control among objects

Component diagram

• A component diagram shows the organizations and dependencies among a set of components.
• Component diagrams address the static implementation view of a system
• They are related to class diagrams in that a component typically maps to one or more classes,
interfaces, or collaborations
Deployment diagram

• A deployment diagram shows the configuration of run-time processing nodes and the
components that live on them
• Deployment diagrams address the static deployment view of an architecture
Case study:
LIBRARY MANAGEMENT SYSTEM

To model the library management system using ‘Object Oriented Analysis and Designing’
concept and the unified modeling language (UML) objective behind the development of this software is
to model an object oriented system which helps the librarians to easily performs their activities. It must
as a best interface between the librarian and the computer so as to perform the required activities
effectively. It must cover the activities of maintaining the records of issued and received books and

Other things available in the library separately for both faculty and student when by taking the
scenario as a college. Uml diagrams drew below helps us to easily understand how the software is
developed. The diagrams are use-case, sequence, collaborations, class, and activity diagrams.

Use Case Diagram

A use case diagram is a diagram that shows a set of use cases and actors and their relationships.

Use case diagrams commonly contain

▪ Use cases
▪ Actors
▪ Dependency, generalization, and association relationships

Common Uses

• We apply use case diagrams to model the static use case view of a system. This view primarily
supports the behavior of a system
o To model the requirements of a system
Modeling the requirements of a system involves specifying what that system should do (from a point of
view of outside the system), independent of how that system should do it. Here, you'll apply use case
diagrams to specify the desired behavior of the system.

To engineer a use case diagram

o Identify each actor that interacts with the system.

o For each actor, consider the manner in which that actor interacts with the system,
changes the state of the system or its environment, or responds to some event.
o Trace the flow of events in the executable system relative to each actor. Start with
primary flows and only later consider alternative paths.
 o Cluster related flows by declaring a corresponding use case. Consider modeling variants
using extend relationships, and consider modeling common flows by applying include
relationships.
o Render these actors and use cases in a use case diagram, and establish their
relationships.
* Two stereotypes apply to dependency relationships among use cases:

11 Extend Specifies that the target use case extends the behavior of the source

Specifies that the source use case explicitly incorporates the behavior of
12 Include another use case at a location specified by the source

INTERACTION DIAGRAM

An interaction diagram models the dynamic aspects of the system by showing the relationship
among the objects and message they may dispatch. There are two types of interaction diagrams:

1. Sequence diagram
2. collaborationdiagram
SEQUENCE DIAGRAM

Sequence diagram shows the steps to steps what much happen to accomplish a piece of functionality
provided by the system. The components are:

a) Actors
b) Objects
c) Message
d) Lifeline
e) Focus of Control
Sequence diagram for “validate user” scenario

List of actions in “validate user” usecase

1.library user shows id card to library employee

2.library employee verifies with library user database

3. database returns valid user or invalid user

4.if valid user the library user can use library

The requirements identified from “validate” sequence diagram

1. User
2. LibEmp
3. UserDB

Sequence diagram for issue book scenario

 List of actions in “issue book” usecase

1.library user search book catalog

2. book found

3. library user gives library card to lib employee

4. libray emp record in issuebook register

5. libray emp issue book to lib user

The requirements identified from “issue book” sequence diagram

4. User
5. LibEmp
6. Catalog
7. IssueRegiter

COLLABORATION DIAGRAM

Collaboration diagrams displays object interactions organized around object and their links to one
another. The components are:

a) Actor
b) Object
c) Link
d)
Collaboration diagram for “validate user” scenario
collaboration diagram for issue book scenario

Class Diagrams

• A class diagram shows a set of classes, interfaces, and collaborations and their relationships.
• Graphically, a class diagram is a collection of vertices and arcs.
Contents

• Class diagrams commonly contain the following things:

o Classes
o Interfaces
o Collaborations
o Dependency, generalization, and association relationships

Note: Component diagrams and deployment diagrams are similar to class diagrams, except that instead
of containing classes, they contain components and nodes
 Activity Diagrams

o An activity diagram shows the flow from activity to activity. An is an ongoing nonatomic execution
within a state machine.
o Activities ultimately result in some action, which is made up of executable atomic computations that
result in a change in state of the system or the return of a value.
o Actions encompass calling another operation, sending a signal, creating or destroying an object, or
some pure computation, such as evaluating an expression.
o Graphically, an activity diagram is a collection of vertices and arcs.

Contents

o Activity diagrams commonly contain

o Activity states and action states
o Transitions
o Objects
o Like all other diagrams, activity diagrams may contain notes and constraints.

Action States and Activity States

o Executable, atomic computations are called action states because they are states of the system,
each representing the execution of an action.
o We represent an action state using a lozenge shape (a symbol with horizontal top and bottom and
convex sides). Inside that shape, you may write any expression.
o Action states can't be decomposed. Furthermore, action states are atomic, meaning that events may
occur, but the work of the action state is not interrupted.
o Finally, the work of an action state is generally considered to take insignificant execution time.

Transitions

o When the action or activity of a state completes, flow of control passes immediately to the next
action or activity state.
o We specify this flow by using transitions to show the path from one action or activity state to the
next action or activity state.
o In the UML, you represent a transition as a simple directed line

Branching
o As in a flowchart, you can include a branch, which specifies alternate paths taken based on some
Boolean expression.
o We represent a branch as a diamond. A branch may have one incoming transition and two or more
outgoing ones.

Common Modeling Techniques

• To model a workflow,
o Establish a focus for the workflow. For nontrivial systems, it's impossible to show all
interesting workflows in one diagram.
o Select the business objects that have the high-level responsibilities for parts of the overall
workflow. These may be real things from the vocabulary of the system, or they may be more
abstract. In either case, create a swimlane for each important business object.
o Identify the preconditions of the workflow's initial state and the postconditions of the
workflow's final state. This is important in helping you model the boundaries of the
workflow.
o Beginning at the workflow's initial state, specify the activities and actions that take place
over time and render them in the activity diagram as either activity states or action states.
o For complicated actions, or for sets of actions that appear multiple times, collapse these into
activity states, and provide a separate activity diagram that expands on each.

Modeling a Workflow

Activity diagram for library management system

 S.E. ASSIGNMENT QUESTIONS

1. Draw the Activity diagram for bank ATM Applications.

2. Draw the use case diagram for Hospital Management System
3. Draw any two sequence diagrams for Bank ATM Applications.
4. Draw any two collaboration diagrams for Hospital Management System.
5. Draw complete class diagram for bank ATM Applications
6. Draw complete class diagram form Hospital management system