1902BS403 Software Design with UML

UNIT I : INTRODUCTION TO ON OBJECT ORIENTED TECHNOLOGIES AND THE UML METHOD

1 What is Object-Oriented Analysis?

During object-oriented analysis there is an emphasis on finding and describing the objects or concepts in the
problem domain. For example, in the case of the flight information system, some of the concepts include Plane,
Flight,andPilot.

2 What is Object-Oriented Design?

During object-oriented design (or simply, object design) there is an emphasis on defining software objects and
how they collaborate to fulfill the requirements. The combination of these two concepts shortly known as
object oriented analysis and design..

3 What is Object-Oriented Analysis and Design?

During object-oriented analysis there is an emphasis on finding and describing the objects or concepts in the
problem domain. For example, in the case of the flight information system, some of the concepts include Plane,
Flight, and Pilot. During object-oriented design (or simply, object design) there is an emphasis on defining
software objects and how they collaborate to fulfill the requirements. The combination of these two concepts
shortly known as object oriented analysis and design.

4 What is Analysis and Design?

Analysis emphasizes an investigation of the problem and requirements, rather than a solution. Design
emphasizes a conceptual solution (in software and hardware) that fulfills the requirements, rather than its
implementation. For example, a description of a database schema and software objects.

5 Define Design Class Diagrams

A static view of the class definitions is usefully shown with a design class diagram. This illustrates the
attributes and methods of the classes.

6 What is the UML?

The Unified Modeling Language is a visual language for specifying, constructing and documenting the
artifacts of systems.

7 Draw the use case diagram

1
8 Why is Waterfall is so failure prone?
There isn't one simple answer to why the waterfall is so failure-prone, but it is strongly related to a
key false assumption underlying many failed software projects that the specifications are predictable
and stable and can be correctly defined at the start, with low change rates. This turns out to be far
from accurate and a costly misunderstanding. A study by Boehm and Papaccio showed that a typical
software project experienced a 25% change in requirements. And this trend was corroborated in
another major study of thousands of software projects, with change rates that go even higher35% to
50% for large projects as illustrated in Figure 1.
Why is Waterfall is so failure prone?
There isn't one simple answer to why the waterfall is so failure-prone, but it is strongly related to a
key false assumption underlying many failed software projects that the specifications are predictable
and stable and can be correctly defined at the start, with low change rates. This turns out to be far
from accurate and a costly misunderstanding. A study by Boehm and Papaccio showed that a typical
software project experienced a 25% change in requirements. And this trend was corroborated in
another major study of thousands of software projects, with change rates that go even higher35% to
50% for large projects as illustrated in Figure 1.

Wrote notes on UML Use Case Diagrams

According to the UML specification a use case diagram is “a diagram that shows the relationships among
actors and use cases within a system.” Use case diagrams are often used to:Provide an overview of all or part
of the usage requirements for a system or organization in the form of an essential (Constantine and Lockwood
1999) model or a business model (Rational Corporation 2001)Communicate the scope of a development
project

Model the analysis of your usage requirements in the form of a system use case model (Cockburn 2001a)
9 Draw The Associations Between Use Cases. Diagram

2
10 Draw the UML sequence diagram.

11 Draw the UML class digram

3
12 What is class Normalization
In the data world there is a common process called data normalization by which you organize data in such a
way as to reduce and even eliminate data redundancy, effectively increasing the cohesiveness of data entities.
Can the techniques of data normalization be applied to object schemas? Yes, but this isn’t an ideal approach
because data normalization only deals data and not behavior. We need to consider both when normalizing our
object schema. We need to rethink our approach. Class normalization is a process by which you reorganize the
structure of your object schema in such a way as to increase the cohesion of classes while minimizing the
coupling between them.

13 Write the Core UML Diagrams

Let’s begin with what I consider to be the three core UML diagrams for developing business software: UML
use case diagrams, UML sequence diagrams, and UML class diagrams. These are the diagrams that you will
see used the most in practice – use case diagrams to overview usage requirements, sequence diagrams to
analyze the use cases and map to your classes, and class diagrams to explore the structure of your object-
oriented software (what I like to refer to as your object schema). These three diagrams will cover 80% of your
object modeling needs when building a business application using object technology.
14 What is Object-Oriented Concepts
Agile software developers, including Agile DBAs, need to be familiar with the basic concepts of object-
orientation. The object-oriented (OO) paradigm is a development strategy based on the concept that systems
should be built from a collection of reusable components called objects. Instead of separating data and
functionality as is done in the structured paradigm, objects encompass both. While the object-oriented
paradigm sounds similar to the structured paradigm, as you will see at this site it is actually quite different. A
common mistake that many experienced developers make is to assume that they have been “doing objects” all
along just because they have been applying similar software-engineering principles. To succeed you must
recognize that the OO approach is different than the structured approach
15 What is Polymorphism
Different objects can respond to the same message in different ways, enable objects to interact with one
another without knowing their exact type

4
S. Questions
No.

1 Explain the water fall model

The classical waterfall model is the basic software development life cycle model. It is very simple but idealistic.
Earlier this model was very popular but nowadays it is not used. But it is very important because all the other software
development life cycle models are based on the classical waterfall model.
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. The different sequential phases of the classical waterfall model are shown in the below figure:

Let us now learn about each of these phases in brief detail:

1. Feasibility Study: The main goal of this phase is to determine whether it would be financially and technically
feasible to develop the software.
The feasibility study involves understanding the problem and then determining the various possible strategies to
solve the problem. These different identified solutions are analyzed based on their benefits and drawbacks, The
best solution is chosen and all the other phases are carried out as per this solution strategy.

2. Requirements analysis and specification: The aim of the requirement analysis and specification phase is to
understand the exact requirements of the customer and document them properly. This phase consists of two
different activities.
 Requirement gathering and analysis: Firstly all the requirements regarding the software are gathered from
the customer and then the gathered requirements are analyzed. The goal of the analysis part is to remove
incompleteness (an incomplete requirement is one in which some parts of the actual requirements have been
omitted) and inconsistencies (an inconsistent requirement is one in which some part of the requirement
contradicts some other part).
 Requirement specification: These analyzed requirements are documented in a software requirement
specification (SRS) document. SRS document serves as a contract between the development team and
customers. Any future dispute between the customers and the developers can be settled by examining the SRS
document.

5
 3. Design: The goal of this phase is to convert the requirements acquired in the SRS into a format that can be coded
in a programming language. It includes high-level and detailed design as well as the overall software architecture.
A Software Design Document is used to document all of this effort (SDD)

4. Coding and Unit testing: In the coding phase software design is translated into source code using any suitable
programming language. Thus each designed module is coded. The aim of the unit testing phase is to check
whether each module is working properly or not.

5. Integration and System testing: Integration of different modules are undertaken soon after they have been coded
and unit tested. Integration of various modules is carried out incrementally over a number of steps. During each
integration step, previously planned modules are added to the partially integrated system and the resultant system
is tested. Finally, after all the modules have been successfully integrated and tested, the full working system is
obtained and system testing is carried out on this.
System testing consists of three different kinds of testing activities as described below :
 Alpha testing: Alpha testing is the system testing performed by the development team.
 Beta testing: Beta testing is the system testing performed by a friendly set of customers.
 Acceptance testing: After the software has been delivered, the customer performed acceptance testing to
determine whether to accept the delivered software or reject it.
6. Maintenance: Maintenance is the most important phase of a software life cycle. The effort spent on maintenance
is 60% of the total effort spent to develop a full software. There are basically three types of maintenance :
 Corrective Maintenance: This type of maintenance is carried out to correct errors that were not discovered
during the product development phase.
 Perfective Maintenance: This type of maintenance is carried out to enhance the functionalities of the system
based on the customer’s request.
 Adaptive Maintenance: Adaptive maintenance is usually required for porting the software to work in a new
environment such as working on a new computer platform or with a new operating system.
Advantages of Classical Waterfall Model
The classical waterfall model is an idealistic model for software development. It is very simple, so it can be
considered the basis for other software development life cycle models. Below are some of the major advantages of this
SDLC model:

 This model is very simple and is easy to understand.

 Phases in this model are processed one at a time.
 Each stage in the model is clearly defined.
 This model has very clear and well-understood milestones.
 Process, actions and results are very well documented.
 Reinforces good habits: define-before- design,
design-before-code.
 This model works well for smaller projects and projects where requirements are well
understood.
Drawbacks of Classical Waterfall Model
The classical waterfall model suffers from various shortcomings, basically, we can’t use it in real projects, but we use
other software development lifecycle models which are based on the classical waterfall model. Below are some major
drawbacks of this model:
2 Explain the 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. As the project manager dynamically determines the number of phases, so
the project manager has an important role to develop a product using the spiral model.
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.

6
The below diagram shows the different phases of the Spiral Model: –

Each phase of the Spiral Model is divided into four quadrants as shown in the above figure. The functions of these
four quadrants are discussed below-
1. Objectives determination and identify alternative solutions: Requirements are gathered from the customers
and the objectives are identified, elaborated, and analyzed at the start of every phase. Then alternative solutions
possible for the phase are proposed in this quadrant.
2. Identify and resolve Risks: During the second quadrant, all the possible solutions are evaluated to select the best
possible solution. Then the risks associated with that solution are identified and the risks are resolved using the
best possible strategy. At the end of this quadrant, the Prototype is built for the best possible solution.
3. Develop next version of the Product: During the third quadrant, the identified features are developed and
verified through testing. At the end of the third quadrant, the next version of the software is available.
4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far developed version
of the software. In the end, planning for the next phase is started.
Risk Handling in Spiral Model
A risk is any adverse situation that might affect the successful completion of a software project. The most important
feature of the spiral model is handling these unknown risks after the project has started. Such risk resolutions are
easier done by developing a prototype. The spiral model supports coping up with risks by providing the scope to build
a prototype at every phase of the software development.
The Prototyping Model also supports risk handling, but the risks must be identified completely before the start of the
development work of the project. But in real life project risk may occur after the development work starts, in that case,
we cannot use the Prototyping Model. In each phase of the Spiral Model, the features of the product dated and
analyzed, and the risks at that point in time are identified and are resolved through prototyping. Thus, this model is
7
 much more flexible compared to other SDLC models.
Why Spiral Model is called Meta Model?
The Spiral model is called a Meta-Model because it subsumes all the other SDLC models. For example, a single loop
spiral actually represents the Iterative Waterfall Model . The spiral model incorporates the stepwise approach of
the Classical Waterfall Model . The spiral model uses the approach of the Prototyping Model by building a prototype
at the start of each phase as a risk-handling technique. Also, the spiral model can be considered as supporting
the Evolutionary model – the iterations along the spiral can be considered as evolutionary levels through which the
complete system is built.
Advantages of Spiral Model:
Below are some advantages of the Spiral Model.
1. Risk Handling: The projects with many unknown risks that occur as the development proceeds, in that case,
Spiral Model is the best development model to follow due to the risk analysis and risk handling at every phase.
2. Good for large projects: It is recommended to use the Spiral Model in large and complex projects.
3. Flexibility in Requirements: Change requests in the Requirements at later phase can be incorporated accurately
by using this model.
4. Customer Satisfaction: Customer can see the development of the product at the early phase of the software
development and thus, they habituated with the system by using it before completion of the total product.
Disadvantages of Spiral Model:
Below are some main disadvantages of the spiral model.
1. Complex: The Spiral Model is much more complex than other SDLC models.
2. Expensive: Spiral Model is not suitable for small projects as it is expensive.
3. Too much dependability on Risk Analysis: The successful completion of the project is very much dependent on
Risk Analysis. Without very highly experienced experts, it is going to be a failure to develop a project using this
model.
4. Difficulty in time management: As the number of phases is unknown at the start of the project, so time
estimation is very difficult.

3 Explain the Software Crisis- description

software Crisis is a term used in computer science for the difficulty of writing useful and efficient computer programs
in the required time .software crisis was due to using same workforce, same methods, same tools even though rapidly
increasing in software demand, complexity of software and software challenges. With increase in the complexity of
software, many software problems arise because existing methods were insufficient.
If we will use same workforce, same methods and same tools after fast increasing in software demand, software
complexity and software challenges, then there arise some problems like software budget problem, software efficiency
problem, software quality problem, software managing and delivering problem etc. This condition is called software
crisis.

8
 Causes of Software Crisis:
 The cost of owning and maintaining software was as expensive as developing the software
 At that time Projects was running over-time
 At that time Software was very inefficient
 The quality of software was low quality
 Software often did not meet requirements
 The average software project overshoots its schedule by half
 At that time Software was never delivered
Solution of Software Crisis:
There is no single solution to the [Link] possible solution of software crisis is Software Engineering because
software engineering is a systematic, disciplined and quantifiable approach. For preventing software crisis, there are
some guidelines:
 Reduction in software over-budget
 The quality of software must be high
 Less time needed for software project
 Experience working team member on software project
 Software must be delivered

4
Software Engineering | Rapid application development model (RAD)
Difficulty Level : Basic
Last Updated : 25 May, 2018
The Rapid Application Development Model was first proposed by IBM in 1980’s. The critical feature of this model is the
use of powerful development tools and techniques.
A software project can be implemented using this model if the project can be broken down into small modules wherein
each module can be assigned independently to separate teams. These modules can finally be combined to form the final
product.
Development of each module involves the various basic steps as in waterfall model i.e analyzing, designing, coding and
then testing, etc. as shown in the figure.
Another striking feature of this model is a short time span i.e the time frame for delivery(time-box) is generally 60-90
days.

9
The use of powerful developer tools such as JAVA, C++, Visual BASIC, XML, etc. is also an integral part of the
projects.
This model consists of 4 basic phases:
1. Requirements Planning –
It involves the use of various techniques used in requirements elicitation like brainstorming, task analysis, form
analysis, user scenarios, FAST (Facilitated Application Development Technique), etc. It also consists of the entire
structured plan describing the critical data, methods to obtain it and then processing it to form final refined model.
2. User Description –
This phase consists of taking user feedback and building the prototype using developer tools. In other words, it
includes re-examination and validation of the data collected in the first phase. The dataset attributes are also
identified and elucidated in this phase.
3. Construction –
In this phase, refinement of the prototype and delivery takes place. It includes the actual use of powerful automated
tools to transform process and data models into the final working product. All the required modifications and
enhancements are too done in this phase.
4. Cutover –
All the interfaces between the independent modules developed by separate teams have to be tested properly. The use
of powerfully automated tools and subparts makes testing easier. This is followed by acceptance testing by the user.
The process involves building a rapid prototype, delivering it to the customer and the taking feedback. After validation
by the customer, SRS document is developed and the design is finalised.
Advantages –
 Use of reusable components helps to reduce the cycle time of the project.
 Feedback from the customer is available at initial stages.
 Reduced costs as fewer developers are required.
 Use of powerful development tools results in better quality products in comparatively shorter time spans.
 The progress and development of the project can be measured through the various stages.
 It is easier to accommodate changing requirements due to the short iteration time spans.
Disadvantages –
10
  The use of powerful and efficient tools requires highly skilled professionals.
 The absence of reusable components can lead to failure of the project.
 The team leader must work closely with the developers and customers to close the project in time.
 The systems which cannot be modularized suitably cannot use this model.
 Customer involvement is required throughout the life cycle.
 It is not meant for small scale projects as for such cases, the cost of using automated tools and techniques may
exceed the entire budget of the project.

5 Explain the Object Oriented Analysis process vs. the Structure Analysis Model.
Analysis simple means to study or examine the structure of something, elements, system requirements in detail, and
methodical way. Structured analysis and Object-oriented analysis both are important for software development and are
analysis techniques used in software engineering. But both are different from each other.
1. 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.
Example –

2. 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 development understands and models all
the requirements of the system.
Example –

11
 Difference Between Structured and Object-oriented analysis :

Structured Analysis Object-Oriented Analysis

The main focus is on the process and procedures of the The main focus is on data structure and real-world objects
system. that are important.
It uses System Development Life Cycle (SDLC)
methodology for different purposes like planning,
analyzing, designing, implementing, and supporting an It uses Incremental or Iterative methodology to refine and
information system. extend our design.
It is suitable for well-defined projects with stable user It is suitable for large projects with changing 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 Use case model (find Use
Diagram), Structured English, ER (Entity Relationship) cases, Flow of events, Activity Diagram), the Object model
diagram, CFD (Control Flow Diagram), Data (find Classes and class relations, Object interaction, Object
Dictionary, Decision table/tree, State transition to ER mapping), Statechart Diagram, and deployment
diagram. diagram.
This technique is old and is not preferred usually. This technique is new and is mostly preferred.
6 Explain the Functional Modelling in object oriented analysis and design
Functional Modelling provides the outline that what the system is supposed to [Link] does not describes what is the
need of evaluation of data, when they are evaluated and how they are evaluated apart from all it only represent origin
of data [Link] describes the function of internal processes with the help of DFD (Data Flow Diagram).
Data Flow Diagrams: Function modelling is represented with the help of DFDs. DFD is the graphically representation
of [Link] shows the input, output and processing of the system .When we are trying to create our own business,
website, system, project then there is need to find out how information passes from one process to another so all are
done by DFD. There are number of levels in DFD but upto third level DFD is sufficient for understanding of any
system.
The basic components of the DFD are:
1. External Entity :
External entity is the entity that takes information and gives information to the system. It is represented with
rectangle.
2. Data Flow :
The data passes from one place to another is shown by data flow. Data flow is represented with arrow and some
information written over it.
3. Process :
It is also called function [Link] is used to process all the [Link] there are calculations so all are done in
the process [Link] is represented with circle and name of the process and level of DFD written inside it.
4. Data Store :
12
 It is used to store the information and retrieve the stored [Link] is represented with double parallel lines.
Some Guidelines for creating a DFD:
1. Every process must have meaningful name and number.
2. Level 0 DFD must have only one process.
3. Every data flow and arrow has given the name.
4. DFD should be logical consistent.
5. DFD should be organized in such a way that it is easy to understand.
6. There should be no loop in the DFD.
7. Each DFD should not have more than 6 processes.
8. The process can only connected with process, external entity and data store.
9. External entity cannot be directly connected with external entity.
10. The direction of DFD is left to right and top to bottom representation.

Explain the software quality

1. What is Software Quality? 20

Software quality is a judgment about the value of software from a particular perspective.
Software quality is often decomposed into individual quality characteristics.

User Perspective

From a user perspective there are several characteristics that are important.

 Does the software provide the full range of desired functionality for its intended
purpose?
 Does the software function reliably to produce correct results on correct input?
 Does the software function safely and securely in response to bad input?
 Is the software easy to use?
 Does the software perform responsively or does it seem unnecessarily slow?
 Does the software work well with other software that the user employs?

Operational Perspective

While considering user quality issues to be important, the IT group responsible for deploying
and maintaining software may be concerned with other issues.

 Is the software secure from malicious attacks intended to compromise other

components of IT infrastructure?
 Does the software make good use of computing resources or does it seem to require
more memory and processing power Standard Software Quality Characteristics

ISO/IEC 9126 defines software quality as a structured set of individual quality characteristics.

13
  Functionality
 Reliability
 Usability
 Efficiency
 Maintainability
 Portability

These characteristics are further decomposed into subcharacteristics as shown in the

following table, adapted from Chapter 17 of Software Testing and Quality Assurance: Theory
and Practice by Naik and Tripathy, 2008.

Quality Sub
Definition
Characteristic characteristic

The capability of the software to provide an adequate

Suitability
set of functions for specified tasks and user objectives.

The capability of the software to provide the right or

Accuracy
agreed-upon results or effects.

The capability of the software to interact with one or

Interoperability
Functionality more specified systems.

The capability of the software to prevent unintended

access and resist deliberate attacks intended to gain
unauthorized access to confidential information or to
Security
make unauthorized modifications to information or to
the program so as to provide the attacker with some
advantage or so as to deny service to legitimate users.

The capability of the software to avoid failure as a

Maturity
result of faults in the software.

The capability of the software to maintain a specified

Fault Tolerance level of performance in case of software faults or of
Reliability
infringement of its specified interface.

The capability of the software to reestablish its level of

Recoverability performance and recover the data directly affected in
the case of a failure.

Usability The capability of the software product to enable the

user to understand whether the software is suitable, and
Understandability
how it can be used for particular tasks and conditions of
use.

The capability of the software product to enable the

Learnability
user to learn its applications.

The capability of the software product to enable the

Operability
user to operate and control it.

Attractiveness The capability of the software product to be liked by

14
 the user.

The capability of the software to provide appropriate

Time Behavior response and processing times and throughput rates
when performing its function under stated conditions.
Efficiency
The capability of the software to use appropriate
Resource
resources in an appropriate time when the software
Utilization
performs its function under stated condition.

The capability of the software product to be diagnosed

Analyzability for deficiencies or causes of failures in the software or
for the parts to be modified to be identified.

The capability of the software product to enable a

Changeability
specified modification to be implemented.
Maintainability
The capability of the software to minimize unexpected
Stability
effects from modifications of the software.

The capability of the software product to enable

Testability
modified software to be validated.

The capability of the software to be modified for

different specified environments without applying
Adaptability
actions or means other than those provided for this
purpose for the software considered.

The capability of the software to be installed in a

Installability
specified environment.
Portability
The capability of the software to coexist with other
Coexistence independent software in a common environment
sharing common resources.

The capability of the software to be used in place of

Replaceability other specified software in the environment of that
software.

ISO/IEC 25010 (2011) refines this model with two new top-level categories particularly
related to internet technologies.

 Security
 Compatibility

In essence, the Interoperability and Security subcharacteristics have been promoted to be their
own top-level characteristics.

Quality Metrics

Quality characteristics are high-level concepts which reflect important aspects of quality, but
are not directly measurable. Instead, a software quality plan must define suitable metrics that
can be used to assess one or more quality characteristics or sub characteristics.

15
2. Explain the software process 20
Software Development Life Cycle (SDLC) is a process used by the software industry to
design, develop and test high quality softwares. The SDLC aims to produce a high-quality
software that meets or exceeds customer expectations, reaches completion within times and
cost estimates.
 SDLC is the acronym of Software Development Life Cycle.
 It is also called as Software Development Process.
 SDLC is a framework defining tasks performed at each step in the software
development process.
 ISO/IEC 12207 is an international standard for software life-cycle processes. It aims
to be the standard that defines all the tasks required for developing and maintaining
software.

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.

A typical Software Development Life Cycle consists of the following stages −

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is performed
by the senior members of the team with inputs from the customer, the sales department,
market surveys and domain experts in the industry. This information is then used to plan the
basic project approach and to conduct product feasibility study in the economical,
operational and technical areas.

16
Planning for the quality assurance requirements and identification of the risks associated
with the project is also done in the planning stage. The outcome of the technical feasibility
study is to define the various technical approaches that can be followed to implement the
project successfully with minimum risks.

Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and document the
product requirements and get them approved from the customer or the market analysts. This
is done through an SRS (Software Requirement Specification) document which consists
of all the product requirements to be designed and developed during the project life cycle.

Stage 3: Designing the Product Architecture

SRS is the reference for product architects to come out with the best architecture for the
product to be developed. Based on the requirements specified in SRS, usually more than one
design approach for the product architecture is proposed and documented in a DDS - Design
Document Specification.
This DDS is reviewed by all the important stakeholders and based on various parameters as
risk assessment, product robustness, design modularity, budget and time constraints, the best
design approach is selected for the product.
A design approach clearly defines all the architectural modules of the product along with its
communication and data flow representation with the external and third party modules (if
any). The internal design of all the modules of the proposed architecture should be clearly
defined with the minutest of the details in DDS.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The
programming code is generated as per DDS during this stage. If the design is performed in a
detailed and organized manner, code generation can be accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization and
programming tools like compilers, interpreters, debuggers, etc. are used to generate the
code. Different high level programming languages such as C, C++, Pascal, Java and PHP are
used for coding. The programming language is chosen with respect to the type of software
being developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing
activities are mostly involved in all the stages of SDLC. However, this stage refers to the
testing only stage of the product where product defects are reported, tracked, fixed and
retested, until the product reaches the quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the appropriate
market. Sometimes product deployment happens in stages as per the business strategy of that
organization. The product may first be released in a limited segment and tested in the real
business environment (UAT- User acceptance testing).
Then based on the feedback, the product may be released as it is or with suggested

17
 enhancements in the targeting market segment. After the product is released in the market,
its maintenance is done for the existing customer base.

SDLC Models

There are various software development life cycle models defined and designed which are
followed during the software development process. These models are also referred as
Software Development Process Models". Each process model follows a Series of steps
unique to its type to ensure success in the process of software development.
Following are the most important and popular SDLC models followed in the industry −

 Waterfall Model
 Iterative Model
 Spiral Model
 V-Model
 Big Bang Model
Other related methodologies are Agile Model, RAD Model, Rapid Application Development
and Prototyping Models.

UNIT II: INTRODUCTION TO THE UML LANGUAGE

PART – A (2 Mark Questions with Key)

1 What is UML?
Unified Modeling Language (UML) is a general purpose modelling language. The main aim of
UML is to define a standard way to visualize the way a system has been designed. It is quite similar
to blueprints used in other fields of engineering.
2 What is Structural Diagrams?
Structural Diagrams – Capture static aspects or structure of a system. Structural Diagrams
include: Component Diagrams, Object Diagrams, Class Diagrams and Deployment Diagrams.
3 What is Behavior Diagrams
Behavior Diagrams – Capture dynamic aspects or behavior of the system. Behavior diagrams
include: Use Case Diagrams, State Diagrams, Activity Diagrams and Interaction Diagrams.
4 Write the Object Oriented Concepts Used in UML
Class
Object
Inheritance
abstraction
Encapsulation
polymorphism
5 Draw the hierarchy diagram

18
6 What is Structural Modeling?
Classes diagrams
Objects diagrams
Deployment diagrams
Package diagrams
Composite structure diagram
Component diagram
7 What is Behavioral Modeling?
Activity diagrams
Interaction diagrams
Use case diagrams
8 What is Architectural Modeling
Architectural model represents the overall framework of the system. It contains both structural and
behavioral elements of the system. Architectural model can be defined as the blueprint of the entire
system. Package diagram comes under architectural modeling
9 What is Goals of UML?
A picture is worth a thousand words, this idiom absolutely fits describing UML. Object-oriented
concepts were introduced much earlier than UML. At that point of time, there were no standard
methodologies to organize and consolidate the object-oriented development. It was then that UML
came into picture
10 What is Conceptual Model of UML?
A conceptual model can be defined as a model which is made of concepts and their relationships.
A conceptual model is the first step before drawing a UML diagram. It helps to understand the
entities in the real world and how they interact with each other.
11 What is Object-Oriented Concepts?
UML can be described as the successor of object-oriented (OO) analysis and design. An object
contains both data and methods that control the data. The data represents the state of the object. A
class describes an object and they also form a hierarchy to model the real-world system. The
hierarchy is represented as inheritance and the classes can also be associated in different ways as
per the requirement.
12 What is OO Analysis and Design?
OO can be defined as an investigation and to be more specific, it is the investigation of objects.
Design means collaboration of identified objects.
13 What is the three steps in oo design ?
OO Analysis → OO Design → OO implementation using OO languages

14 What is Role of UML in OO Design?

UML is a modeling language used to model software and non-software systems. Although UML is
used for non-software systems, the emphasis is on modeling OO software applications. Most of the
UML diagrams discussed so far are used to model different aspects such as static, dynamic,
19
 15 What is Things?
Things are the most important building blocks of UML. Things can be –
Structural
Behavioral
Grouping
An notational

PART – B (12 Mark Questions with Key)

S. Questions
No.

1 What is UML?
Unified Modeling Language (UML) is a general purpose modelling language. The main aim of
UML is to define a standard way to visualize the way a system has been designed. It is quite similar
to blueprints used in other fields of engineering.

UML is not a programming language, it is rather a visual language. We use UML diagrams to
portray the behavior and structure of a system. UML helps software engineers, businessmen and
system architects with modelling, design and analysis. The Object Management Group (OMG)
adopted Unified Modelling Language as a standard in 1997. Its been managed by OMG ever since.
International Organization for Standardization (ISO) published UML as an approved standard in
2005. UML has been revised over the years and is reviewed periodically.
Do we really need UML?
 Complex applications need collaboration and planning from multiple teams and hence require a
clear and concise way to communicate amongst them.
 Businessmen do not understand code. So UML becomes essential to communicate with non
programmers essential requirements, functionalities and processes of the system.
 A lot of time is saved down the line when teams are able to visualize processes, user interactions
and static structure of the system.
UML is linked with object oriented design and analysis. UML makes the use of elements and forms
associations between them to form diagrams. Diagrams in UML can be broadly classified as:
1. Structural Diagrams – Capture static aspects or structure of a system. Structural Diagrams
include: Component Diagrams, Object Diagrams, Class Diagrams and Deployment Diagrams.
2. Behavior Diagrams – Capture dynamic aspects or behavior of the system. Behavior diagrams
include: Use Case Diagrams, State Diagrams, Activity Diagrams and Interaction Diagrams.
The image below shows the hierarchy of diagrams according to UML

2
What is Object Oriented Concepts Used in UML?

20
 1. Class – A class defines the blue print i.e. structure and functions of an object.
2. Objects – Objects help us to decompose large systems and help us to modularize our system.
Modularity helps to divide our system into understandable components so that we can build our
system piece by piece. An object is the fundamental unit (building block) of a system which is
used to depict an entity.
3. Inheritance – Inheritance is a mechanism by which child classes inherit the properties of their
parent classes.
4. Abstraction – Mechanism by which implementation details are hidden from user.
5. Encapsulation – Binding data together and protecting it from the outer world is referred to as
encapsulation.
6. Polymorphism – Mechanism by which functions or entities are able to exist in different forms.
Additions in UML 2.0 –
 Software developments methodologies like agile have been incorporated and scope of original
UML specification has been broadened.
 Originally UML specified 9 diagrams. UML 2.x has increased the number of diagrams from 9 to
13. The four diagrams that were added are : timing diagram, communication diagram, interaction
overview diagram and composite structure diagram. UML 2.x renamed statechart diagrams to
state machine diagrams.
 UML 2.x added the ability to decompose software system into components and sub-components.
3
What is Structural UML Diagrams?

1. Class Diagram – The most widely use UML diagram is the class diagram. It is the building block
of all object oriented software systems. We use class diagrams to depict the static structure of a
system by showing system’s classes, their methods and attributes. Class diagrams also help us
identify relationship between different classes or objects.
2. Composite Structure Diagram – We use composite structure diagrams to represent the internal
structure of a class and its interaction points with other parts of the system. A composite structure
diagram represents relationship between parts and their configuration which determine how the
classifier (class, a component, or a deployment node) behaves. They represent internal structure of
a structured classifier making the use of parts, ports, and connectors. We can also model
collaborations using composite structure diagrams. They are similar to class diagrams except they
represent individual parts in detail as compared to the entire class.
3. Objects Diagram – An Object Diagram can be referred to as a screenshot of the instances in a
system and the relationship that exists between them. Since object diagrams depict behaviour
when objects have been instantiated, we are able to study the behaviour of the system at a
particular instant. An object diagram is similar to a class diagram except it shows the instances of
classes in the system. We depict actual classifiers and their relationships making the use of class
diagrams. On the other hand, an Object Diagram represents specific instances of classes and
relationships between them at a point of time.
4. Component Diagram – Component diagrams are used to represent the how the physical
components in a system have been organized. We use them for modeling implementation details.
Component Diagrams depict the structural relationship between software system elements and
help us in understanding if functional requirements have been covered by planned development.
Component Diagrams become essential to use when we design and build complex systems.
Interfaces are used by components of the system to communicate with each other.
5. Deployment Diagram – Deployment Diagrams are used to represent system hardware and its
software. It tells us what hardware components exist and what software components run on
[Link] illustrate system architecture as distribution of software artifacts over distributed targets.
An artifact is the information that is generated by system software. They are primarily used when
a software is being used, distributed or deployed over multiple machines with different
configurations.

6. Package Diagram – We use Package Diagrams to depict how packages and their elements have
been organized. A package diagram simply shows us the dependencies between different packages
and internal composition of packages. Packages help us to organise UML diagrams into
21
 meaningful groups and make the diagram easy to understand. They are primarily used to organise
class and use case diagrams.

4 What is UML diagram?

1. State Machine Diagrams – A state diagram is used to represent the condition of the system or
part of the system at finite instances of time. It’s a behavioral diagram and it represents the
behavior using finite state transitions. State diagrams are also referred to as State
machines and State-chart Diagrams . These terms are often used interchangeably. So simply, a
state diagram is used to model the dynamic behavior of a class in response to time and changing
external stimuli.
2. Activity Diagrams – We use Activity Diagrams to illustrate the flow of control in a system. We
can also use an activity diagram to refer to the steps involved in the execution of a use case. We
model sequential and concurrent activities using activity diagrams. So, we basically depict
workflows visually using an activity diagram. An activity diagram focuses on condition of flow
and the sequence in which it happens. We describe or depict what causes a particular event using
an activity diagram.
3. Use Case Diagrams – Use Case Diagrams are used to depict the functionality of a system or a
part of a system. They are widely used to illustrate the functional requirements of the system and
its interaction with external agents(actors). A use case is basically a diagram representing different
scenarios where the system can be used. A use case diagram gives us a high level view of what the
system or a part of the system does without going into implementation details.
4. Sequence Diagram – A sequence diagram simply depicts interaction between objects in a
sequential order i.e. the order in which these interactions take place. We can also use the terms
event diagrams or event scenarios to refer to a sequence diagram. Sequence diagrams describe
how and in what order the objects in a system function. These diagrams are widely used by
businessmen and software developers to document and understand requirements for new and
existing systems.
5. Communication Diagram – A Communication Diagram(known as Collaboration Diagram in
UML 1.x) is used to show sequenced messages exchanged between objects. A communication
diagram focuses primarily on objects and their relationships. We can represent similar information
using Sequence diagrams; however, communication diagrams represent objects and links in a free
form.
6. Timing Diagram – Timing Diagram are a special form of Sequence diagrams which are used to
depict the behavior of objects over a time frame. We use them to show time and duration
constraints which govern changes in states and behavior of objects.
7. Interaction Overview Diagram – An Interaction Overview Diagram models a sequence of
actions and helps us simplify complex interactions into simpler occurrences. It is a mixture of
activity and sequence diagrams.

5 What is Structural Modeling? 12

Structural modeling captures the static features of a system. They consist of the following −

 Classes diagrams
 Objects diagrams
 Deployment diagrams
 Package diagrams
 Composite structure diagram
 Component diagram
Structural model represents the framework for the system and this framework is the place where all
other components exist. Hence, the class diagram, component diagram and deployment diagrams are
part of structural modeling. They all represent the elements and the mechanism to assemble them.
The structural model never describes the dynamic behavior of the system. Class diagram is the most
22
 widely used structural diagram.

Behavioral Modeling

Behavioral model describes the interaction in the system. It represents the interaction among the
structural diagrams. Behavioral modeling shows the dynamic nature of the system. They consist of
the following −

 Activity diagrams
 Interaction diagrams
 Use case diagrams
All the above show the dynamic sequence of flow in a system.
6 What is Goals of UML?
A picture is worth a thousand words, this idiom absolutely fits describing UML. Object-oriented
concepts were introduced much earlier than UML. At that point of time, there were no standard
methodologies to organize and consolidate the object-oriented development. It was then that UML
came into picture.
There are a number of goals for developing UML but the most important is to define some general
purpose modeling language, which all modelers can use and it also needs to be made simple to
understand and use.
UML diagrams are not only made for developers but also for business users, common people, and
anybody interested to understand the system. The system can be a software or non-software system.
Thus it must be clear that UML is not a development method rather it accompanies with processes to
make it a successful system.
In conclusion, the goal of UML can be defined as a simple modeling mechanism to model all
possible practical systems in today’s complex environment.

S. No. Questions

1. Explain the Role of UML in OO Design

UML is a modeling language used to model software and non-software systems. Although
UML is used for non-software systems, the emphasis is on modeling OO software
applications. Most of the UML diagrams discussed so far are used to model different aspects
such as static, dynamic, etc. Now whatever be the aspect, the artifacts are nothing but
objects.
If we look into class diagram, object diagram, collaboration diagram, interaction diagrams
all would basically be designed based on the objects.
Hence, the relation between OO design and UML is very important to understand. The OO
design is transformed into UML diagrams according to the requirement. Before
understanding the UML in detail, the OO concept should be learned properly. Once the OO
analysis and design is done, the next step is very easy. The input from OO analysis and
design is the input to UML diagrams.

23
As UML describes the real-time systems, it is very important to make a conceptual model
and then proceed gradually. The conceptual model of UML can be mastered by learning the
following three major elements
UML building blocks

 Rules to connect the building blocks

 Common mechanisms of UML
This chapter describes all the UML building blocks. The building blocks of UML can be
defined as −

 Things
 Relationships
 Diagrams

Things

Things are the most important building blocks of UML. Things can be −

 Structural
 Behavioral
 Grouping
 An notational

Structural Things

Structural things define the static part of the model. They represent the physical and
conceptual elements. Following are the brief descriptions of the structural things.
Class − Class represents a set of objects having similar responsibilities.

Interface − Interface defines a set of operations, which specify the responsibility of a class.

Collaboration −Collaboration defines an interaction between elements.

Use case −Use case represents a set of actions performed by a system for a specific goal.

Component −Component describes the physical part of a system.

24
Node − A node can be defined as a physical element that exists at run time.

Behavioral Things

A behavioral thing consists of the dynamic parts of UML models. Following are the
behavioral things −
Interaction − Interaction is defined as a behavior that consists of a group of messages
exchanged among elements to accomplish a specific task.

State machine − State machine is useful when the state of an object in its life cycle is
important. It defines the sequence of states an object goes through in response to events.
Events are external factors responsible for state change

Grouping Things

Grouping things can be defined as a mechanism to group elements of a UML model

together. There is only one grouping thing available −

Package − Package is the only one grouping thing available for gathering structural and
behavioral things.

Annotational Things

Annotational things can be defined as a mechanism to capture remarks, descriptions, and

comments of UML model elements. Note - It is the only one Annotational thing available. A
note is used to render comments, constraints, etc. of an UML element.

25
 Relationship

Relationship is another most important building block of UML. It shows how the elements
are associated with each other and this association describes the functionality of an
application.
There are four kinds of relationships available.

Dependency

Dependency is a relationship between two things in which change in one element also
affects the other.

Association

Association is basically a set of links that connects the elements of a UML model. It also
describes how many objects are taking part in that relationship.

Generalization

Generalization can be defined as a relationship which connects a specialized element with a

generalized element. It basically describes the inheritance relationship in the world of
objects.

Realization

Realization can be defined as a relationship in which two elements are connected. One
element describes some responsibility, which is not implemented and the other one
implements them. This relationship exists in case of interfaces.

2. Explain the UML Diagrams?

UML diagrams are the ultimate output of the entire discussion. All the elements,
relationships are used to make a complete UML diagram and the diagram represents a

26
 system.
The visual effect of the UML diagram is the most important part of the entire process. All
the other elements are used to make it complete.
UML includes the following nine diagrams, the details of which are described in the
subsequent chapters.

 Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 Activity diagram
 State chart diagram
 Deployment diagram
 Component diagramWhat is a Pattern?

A pattern is a commonly occurring reusable piece in software system that provides a certain
set of functionality. The identification of a pattern is also based on the context in which it is
used. So, using patterns in modeling of systems helps in keeping design standardized and
more importantly, minimizes the reinventing of the wheel in the system design. This article is
all about patterns; especially design patterns.

How do Patterns Relate to UML?

The patterns that we encounter need to be captured and documented in a sufficiently

descriptive manner so that they can be referred for future use. UML provides the perfect tools
to do just this. The class diagram in UML can be used to capture the patterns identified in a
system. In addition, UML has a sufficiently extensive and expressive vocabulary to capture
the details of patterns.

Over the previous articles in this series, we explored the different UML diagrams and learned
how to model each of the diagrams in a case study application. Building on this background
we will see how to leverage the usefulness of well-known patterns to make application
designing a lot easier.

To sum up, a pattern should have the following characteristics

 Useful solution
 Reusable
 Contextual
Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides first popularized the concept
of patterns with their book on design patterns. These authors came to be known as the “Gang
Of Four” or GOF. The name stuck ever since and the patterns catalog that they documented is
known as the GOF patterns catalog.

27
Design Patterns

Since a system is made up of static as well as dynamic elements, you will find patterns that
can be used for either of these types. For static elements of a system especially the
architecture and design of a system, there are design patterns – the focus of this article. The
dynamic aspects of a system are abstracted and captured as process patterns. But patterns are
not limited to this. Patterns can be abstracted for the implementation aspects of a system as
well.

Based on how they are to be used, patterns are primarily categorized as:

 Creational
 Structural
 Behavioral

Creational

Creational patterns define mechanisms for instantiating objects. The implementation of the
creational pattern is responsible for managing the lifecycle of the instantiated object. A few
examples of Creational design patterns are listed below.

Factory

One of the easily recognized and frequently used design patterns is the Factory pattern. If you
have designed any object that is responsible for creating and maintaining the lifecycle of
another object, you have used the Factory pattern. Obtaining a database connection in your
application using a connection manager or connection factory object is a good example of the
Factory pattern.

Figure 1. Factory pattern

Singleton

A singleton is another example of a factory pattern. What makes the Singleton pattern unique
is that one and only one instance of the object can exist irrespective of the number of times
the object is instantiated. The most common use of a Singleton pattern is for server

28
applications like a Java based Remote Method Invocation (RMI) server application.

Figure 2. Singleton pattern

Structural

The composition of objects and their organization to obtain new and varied functionality is
the underlying basis of Structural patterns. A few examples of Structural design patterns are
listed below.

Adapter

In the Adapter pattern, an object provides an implementation of an interface used by other

objects in a consistent way. The adapter object wraps different disparate implementations of
the interface and presents a unified interface for other objects to access. A good example of
this is a database driver like an ODBC (Open Database Connectivity) or JDBC (Java
Database Connectivity) driver that wraps the custom database accessing implementation for
different databases and yet, presents a consistent interface that is a published and standardized
API.

Proxy

A Proxy pattern constitutes use of proxy objects during object interaction. A proxy object acts
as a substitute for the actual object. Use of proxy objects is prevalent in remote object
interaction protocols. As an example, when an object needs to interact with a remote object,
say across a network, the most preferred way of encapsulating and hiding the interaction
mechanism is by using a communication between the requesting object and the remote object.

Behavioral

Interaction between different objects is specifically covered by Behavioral patterns. Some

examples of behavioral patterns are given below.

Command

The Command pattern is commonly used for gathering requests from client objects and
packaging them into a single object for processing. The Command pattern allows for having
well defined command interfaces that are implemented by the object that provides the
processing for the client requests packaged as commands.

Iterator

29
A simple mechanism to traverse and access a list of objects is defined by the Iterator pattern.
The Iterator pattern encapsulates the internal implementation of the list while providing a
standardized mechanism for list traversal.

Figure 6. Iterator pattern

30