SOFTWARE DESIGN

WITH UML
Subject Code:U20CBT509
Course Objectives:
• To Understand the object-oriented software development
process
• To Design suitable pattern to develop software models
• To Analyze requirements to create requirements design
model
• To Apply business modeling and modeling languages to
design software
• To Develop correct and robust software deployment models
Course Outcomes:
• After completion of the course, the students will be able to
• CO1 - Decide a suitable software model for a project (K2)
• CO2 - Describe how to model object-oriented languages (K2)
• CO3 - Design a project business model (K3)
• CO4 - Elicit requirements and design a user interface model
(K2)
• CO5 - Create a deployment model (K3)
Text Books:
1. Bernd Bruegge and Allen H. Dutoit, Object-Oriented Software
Engineering: using UML, Patterns, and Java,Third Edition, Pearson,
2010.
2. Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlissides,
Design Patterns: Elements of Reusable Object-Oriented Software,
Addison Wesley, 1994.
3. Grady Booch, Robert Maksimchuk, Michael Engle, Bobbi Young
Ph.D. (Author), Jim Conallen Kelli Houston,Object-Oriented Analysis
and Design with Applications,Addison-Wesley,2007
Reference Books:
1. Craig Larman, “Applying UML and Patterns: An Introduction to
Object-Oriented Analysis and Design and Iterative Development”,
3rd Edition, Pearson Education, 2005.
2. Simon Bennett, Steve Mc Robb and Ray Farmer, “Object Oriented
Systems Analysis and Design Using UML”, Fourth Edition, Mc-Graw
Hill Education, 2010.
3. Martin Fowler, “UML Distilled: A Brief Guide to the Standard Object
Modeling Language”, Third edition, Addison Wesley, 2003.
 UNIT I INTRODUCTION
Software development process: The Waterfall Model
vs. The Spiral Model - The Software Crisis, description
of the real world using the Objects Model. - Classes,
inheritance and multiple configurations. - Quality
software characteristics - Description of the Object-
Oriented Analysis process vs. the Structure Analysis
Model.
 Waterfall Model
• The classical waterfall model is the basic software development life
cycle model. It is very simple but idealistic.
• The classical waterfall model divides the life cycle into a set of phases.
This model considers that one phase can be started after the
completion of the previous phase.
• That is the output of one phase will be the input to the next phase.
• Thus the development process can be considered as a sequential flow
in the waterfall.
• Here the phases do not overlap with each other
Phases of Waterfall Model
 Spiral Model
• Spiral model is one of the most important Software Development Life
Cycle models, which provides support for Risk Handling.
• In its diagrammatic representation, it looks like a spiral with many
loops.
• The exact number of loops of the spiral is unknown and can vary
from project to project.
• Each loop of the spiral is called a Phase of the software development
process.
• The exact number of phases needed to develop the product can be
varied by the project manager depending upon the project risks
• The Radius of the spiral at any point represents the expenses(cost) of
the project so far, and the angular dimension represents the progress
made so far in the current phase.
 The Waterfall Model vs The Spiral Model

S. Waterfall Model Spiral Model

No.

1. The Waterfall model is simple and easy. The spiral model is a lot more complex.

The waterfall model works in a sequential While the spiral model works in the evolutionary
2. method. method.

In the waterfall model errors or risks are identified In the spiral model errors or risks are identified
3. and rectified after the completion of stages. and rectified earlier.

While the spiral model is adopted by

4. The waterfall model is adopted by customers.
developers.

The waterfall model is applicable for small

5. projects.
While the Spiral model is used for large projects.

In waterfall model requirements and early stage While in spiral model requirements and early
6. planning is necessary. stage planning is necessary if required.
8. There is high amount risk in waterfall model. There is low amount risk in spiral model.

Waterfall model is comparatively

9. While cost of spiral model is very expensive.
inexpensive.

Customer involvement is minimum in

10. In the Spiral Model Customer involvement is high.
Waterfall Model

11. It requires least maintenance. It requires typical maintenance.

12. It is based on linear framework type. It is based on linear and iterative framework type.

Testing is done after the coding phase in the Testing is done after the engineering phase in the
13.
development life cycle. development cycle.

14. Reusability is extremely unlikely. To a certain extent, reusability is possible.

Customer control over the administrator is Customers have control over the administrator as
15.
very limited. compared to waterfall model.
The Software Crisis, description of the real
world using the Objects Model
What is meant by software crisis?
• Software crisis is a term used in the early days of computing science
for the difficulty of writing useful and efficient computer programs
in the required time. The software crisis was due to the rapid
increases in computer power and the complexity of the problems that
could not be tackled.
• The software crisis was due to using the same workforce, same
methods, same tools even though rapidly increasing in software
demand, the complexity of software, and software challenges.
• With the increase in the complexity of software, many software
problems arise because existing methods were insufficient
• If we will use the same workforce, same methods, and same tools
after the fast increase in software demand, software complexity, and
software challenges, then there arise some problems like software
budget problems, software efficiency problems, software quality
problems, software managing and delivering problem, etc. This
condition is called a software crisis.
Causes of Software Crisis:
• The cost of owning and maintaining software was as expensive as developing the
software
• At that time Projects were running over-time
• At that time Software was very inefficient
• The quality of the software was low quality
• Software often did not meet user requirements
• The average software project overshoots its schedule by half
• At that time Software was never delivered
• Non-optimal resource utilization.
• Difficult to alter, debug, and enhance.
• The software complexity is harder to change.
• Let’s now understand which factors are contributing to the software crisis.
• Poor project management.
• Lack of adequate training in software engineering.
• Less skilled project members.
• Low productivity improvements.
Solution of Software Crisis:
There is no single solution to the crisis. One possible solution to a
software crisis is Software Engineering because software
engineering is a systematic, disciplined, and quantifiable
approach. For preventing software crises, there are some
guidelines:
•Reduction in software over budget.
•The quality of software must be high.
•Less time is needed for a software project.
•Experienced and skilled people working over the software
project.
•Software must be delivered.
•Software must meet user requirements.
 Classes, inheritance and multiple
configurations
• In the object-oriented design method, the system is viewed as a
collection of objects (i.e., entities). The state is distributed
among the objects, and each object handles its state data.
• For example, in a Library Automation Software, each library
representative may be a separate object with its data and
functions to operate on these data.
• The tasks defined for one purpose cannot refer or change data
of other objects. Objects have their internal data which
represent their state.
• Similar objects create a class. In other words, each object is a
member of some class. Classes may inherit features from the
superclass.
1.Objects: All entities involved in the solution design are known as objects. For example,
person, banks, company, and users are considered as objects. Every entity has some
attributes associated with it and has some methods to perform on the attributes.
2.Classes: A class is a generalized description of an object. An object is an instance of a
class. A class defines all the attributes, which an object can have and methods, which
represents the functionality of the object.
3.Messages: Objects communicate by message passing. Messages consist of the integrity of
the target object, the name of the requested operation, and any other action needed to
perform the function. Messages are often implemented as procedure or function calls.
4.Abstraction In object-oriented design, complexity is handled using abstraction.
Abstraction is the removal of the irrelevant and the amplification of the essentials.
5.Encapsulation: Encapsulation is also called an information hiding concept. The data and
operations are linked to a single unit. Encapsulation not only bundles essential information of
an object together but also restricts access to the data and methods from the outside world.
6.Inheritance: OOD allows similar classes to stack up in a hierarchical manner where the
lower or sub-classes can import, implement, and re-use allowed variables and functions from
their immediate superclasses.This property of OOD is called an inheritance. This makes it
easier to define a specific class and to create generalized classes from specific ones.
7.Polymorphism: OOD languages provide a mechanism where methods performing similar
tasks but vary in arguments, can be assigned the same name. This is known as
polymorphism, which allows a single interface is performing functions for different types.
Depending upon how the service is invoked, the respective portion of the code gets
Quality software characteristics:
Software is defined as a collection of computer programs, procedures, rules, and
data. Software Characteristics are classified into six major components
These components are described below:

• Functionality:
It refers to the degree of performance of the software against its intended
purpose. Required functions are:
• Reliability:
A set of attributes that bears on the capability of software to maintain its level of
performance under the given condition for a stated period of time. Required functions
are:
• Efficiency:
It refers to the ability of the software to use system resources in the most effective and
efficient manner. The software should make effective use of storage space and
executive command as per desired timing requirements. Required functions are:
• Usability:
It refers to the extent to which the software can be used with ease. the amount of
effort or time required to learn how to use the software. Required functions are:
• Maintainability:
It refers to the ease with which the modifications can be made in a software system to
extend its functionality, improve its performance, or correct errors. Required functions
are:
• Portability:
A set of attributes that bears on the ability of software to be transferred from one
environment to another, without or minimum changes. Required functions are:
Software is developed or engineered; it is not manufactured in the classical sense:
• Although some similarities exist between software development and hardware manufacturing, few
activities are fundamentally different.
• In both activities, high quality is achieved through good design, but the manufacturing phase for
hardware can introduce quality problems than software.
The software doesn’t “wear out.”:
• Hardware components suffer from the growing effects of many other environmental factors. Stated
simply, the hardware begins to wear out.
• Software is not susceptible to the environmental maladies that cause hardware to wear out.
• When a hardware component wears out, it is replaced by a spare part.
• There are no software spare parts.
• Every software failure indicates an error in design or in the process through which design was
translated into machine-executable code. Therefore, the software maintenance tasks that
accommodate requests for change involve considerably more complexity than hardware
maintenance. However, the implication is clear—the software doesn’t wear out. But it does
deteriorate.
The software continues to be custom-built:
• A software part should be planned and carried out with the goal that it tends to be reused in various
projects.
• Current reusable segments encapsulate the two information and the preparation that is applied to
the information, empowering the programmer to make new applications from reusable parts.
• In the hardware world, component reuse is a natural part of the engineering process.
Structured Analysis:
• Structured analysis is a method of development that allows and gives permission to
the analyst to understand and know about the system and all of its activities in a
logical way. It is simply a graphic that is used to specify the presentation of the
application.
Object-Oriented Analysis:
• Object-Oriented Analysis (OOA) is a technical approach generally used for analyzing and
application designing, system designing, or even business designing just by applying
object-oriented programming even with the use of visual modeling throughout the
process of development to just simply guide the stakeholder communication and quality
of the product. it is actually a process of discovery where a team of developers
understands and models all the requirements of the system.
 Structured Analysis Object-Oriented Analysis

• The main focus is on the process and procedures of • The main focus is on data structure and real-world objects
the system. that are important.

• It uses System Development Life Cycle (SDLC)

methodology for different purposes like planning, • It uses Incremental or Iterative methodology to refine and
analyzing, designing, implementing, and supporting extend our design.
an information system.

• It is suitable for well-defined projects with stable • It is suitable for large projects with changing user
user requirements. requirements.
• Risk while using this analysis technique is high and • Risk while using this analysis technique is low and
reusability is also low. reusability is also high.

• Structuring requirements include DFDs (Data Flow • Requirement engineering includes the Use case model
Diagram), Structured Analysis, ER (Entity (find Use cases, Flow of events, Activity Diagram), the
Relationship) diagram, CFD (Control Flow Object model (find Classes and class relations, Object
Diagram), Data Dictionary, Decision table/tree, and interaction, Object to ER mapping), Statechart Diagram,
the State transition diagram. and deployment diagram.

• This technique is old and is not preferred usually. • This technique is new and is mostly preferred.