1

2
Please read this disclaimer before proceeding:

This document is confidential and intended solely for the educational purpose of
RMK Group of Educational Institutions. If you have received this document through
email in error, please notify the system manager. This document contains proprietary
information and is intended only to the respective group / learning community as
intended. If you are not the addressee you should not disseminate, distribute or
copy through e-mail. Please notify the sender immediately by e-mail if you have
received this document by mistake and delete this document from your system. If
you are not the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this information is
strictly prohibited.

3
 22IT404
APPLICATION SYSTEM DESIGN WITH UML

Department : Information Technology

Batch/Year : 2022-2026/ II
Created by : Dr.Rajitha Jasmine R

Dr. M.Jayaprakash
Date : 10-01-2024

4
1.TABLE OF CONTENTS

SLIDE
S.NO. CONTENTS
NO.
1 CONTENTS 5

2 COURSE OBJECTIVES 9

3 PRE REQUISITES (COURSE NAMES WITH CODE) 10

4 SYLLABUS (WITH SUBJECT CODE, NAME, LTPC DETAILS) 11

5 COURSE OUTCOMES (6) 13

6 CO- PO/PSO MAPPING 14

7 LECTURE PLAN –UNIT 1 16

8 ACTIVITY BASED LEARNING –UNIT 1

9 CROSSWORD PUZZLE 18
10 VIDEO LINK-QUIZ 19
11 TEST YOURSELF 20
12 LECTURE NOTES – UNIT 1

13 1.Software development process 21

1.1 The Waterfall Model vs. The Spiral Model.

14 24

15 1.2 SOFTWARE PROCESS 26

16 1.2.1. PROCESS FLOW 29

17 1.3 SDLC MODELS 30

18 1.3.1.1. WATERFALL MODELS 32

19 1.3.1.2 V MODELS 33

20 1.3.1.3 INCREMENTAL MODELS 35

21 1.4. RAD MODELS 36
22 1.4.1.5 EVOLUTIONARY MODELS 37

5
 Table of Contents SLIDE
S.NO. CONTENTS
NO.

22 INTRODUCTION TO AGILITY 39

The Software Crisis

23 44

Description of the real world using the Objects Model. -

24 Classes, inheritance and multiple configurations

Quality software characteristics

25 46

Description of the Object Oriented Analysis process vs. the

26 Structure Analysis Model. 47

Introduction to the UML Language. Standards

27 48

Elements of the language

Description of Design Patterns

28 49

29 ASSIGNMENT 1- UNIT 1 63

30 PART A Q & A (WITH K LEVEL AND CO) 64

31 PART B Q s (WITH K LEVEL AND CO) 68

32 SUPPORTIVE ONLINE CERTIFICATION COURSES 69

REAL TIME APPLICATIONS IN DAY TO DAY LIFE AND TO

33 70
INDUSTRY

34 CONTENTS BEYOND THE SYLLABUS 71

35 ASSESSMENT SCHEDULE 72

36 PRESCRIBED TEXT BOOKS & REFERENCE BOOKS 73

37 MINI PROJECT SUGGESTIONS 74

6
 2. COURSE OBJECTIVES

• Understand the fundamentals of object-oriented

modelling
• Capture the requirements specification for an intended
software system
• Translate the analysis phase to design modelling
• Design with static UML diagrams.
• Design with the UML dynamic and implementation
diagrams.
• Understand the concepts of Design Patterns

7
 3. PRE REQUISITES

PRE-REQUISITE CHART

SYSTEM DESIGN WITH UML

22IT404--APPLICATION

CS8494-SOFTWARE
ENGINEERING

20IT502-OBJECT
ORIENTED SYSTEM DESIGN

CS8491-DATA STRUCTURES

8
4. ASD WITH UML SYLLABUS LTPC

OBJECTIVES:
3003

The Course will enable learners to:

• Understand the fundamentals of object-oriented
modeling
• Capture the requirements specification for an intended
software system
• Translate the analysis phase to design modeling
• Design with static UML diagrams.
• Design with the UML dynamic and implementation
diagrams.
• Understand the concepts of Design Patterns
UNIT I INTRODUCTION TO AN OBJECT-ORIENTED
TECHNOLOGIES AND UML 9+6
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. - Descriptionof the Object Oriented
Analysis process vs. the Structure Analysis Model. Introduction to the
UML Language. Standards. -Elements of the language. -
Generaldescription of various models. -The process of Object
Oriented software development.-Description of Design Patterns.
. List of Exercise/Experiments
1. Develop Problem statement for software System
UNIT II REQUIREMENT ANALYSIS AND STATIC DIAGRAMS 9+6
Analysis of system requirements. -Actor definitions. -Writing a case
goal. –Use Case Diagrams. -Use Case Relationships. - Use case
Modeling – Relating Use cases – include, extend and
generalization – When to use Use-cases- The Class Diagram
Model. -Attributes descriptions. - Operations descriptions. -
Connections descriptions in the Static Model. - Association,
Generalization, Aggregation, Dependency, Interfacing, Multiplicity.
Package Diagram Model. - Description of the model. -White box,
black box. -Connections between packagers. - Interfaces. - Create
Package Diagram. Drill Down

9
 List of Exercise/Experiments
1.Document the Software Requirements Specification
(SRS) for the identified system

UNIT III INTERACTION DIAGRAMS 9+6

Description of goal. -Defining UML Method, Operation,
Object Interface, Class. - Sequence Diagram. -Finding
objects from Flow of Events. - Describing the process
of finding objects using a Sequence Diagram. -
Describing the process of finding objects using a
Collaboration Diagram
List of Exercise/Experiments
1. Using the identified scenarios, find the interaction
between objects and represent them using UML
Sequence Diagram
UNIT IV DYNAMIC AND IMPLEMENTATION
DIAGRAMS 9+6
Description of the State Diagram. -Events Handling. -
Description of the Activity Diagram. - Exercise in State
Machines. Component Diagram Model. - Physical
Aspect. -Logical Aspect.- Connections and
Dependencies. -User face. - Initial DB design in a UML
environment. Deployment Model.- Processors. -
Connections. - Components. -Tasks. -Threads. -
Signals and Events
List of Exercise/Experiments

1.DrawrelevantStateChartandActivityDiagramsforthesam
esystem.
2. Develop UML Component and Deployment diagram

10
UNIT V DESIGN PATTERNS 9+6
Design Patters – SOLID Principle – Standard
Architecture Principles - Java Blue Print Patterns –
Structural. Behavioural and Creational Patterns –
Reference Implementations

List of Exercise/Experiments

1.Evaluate the different pattern interactions between

various physical components and the user, managing a
design solution through visual representations.

11
 5.COURSE OUTCOME

Cognitive/
Expected
Course Affective Level
Course Outcome Statement Level of
Code of the Course
Attainment
Outcome
Course Outcome Statements in Cognitive Domain
To understand business problem Apply
C404.1 60%
statement in object-oriented notation K3
Covert the analysis phase to design Analyse
C404.2 60%
modeling. K4
Identify various scenarios based on Understand
C404.3 software requirements 60%
K2
Implement Static diagrams and Apply
C404.4 Dynamic modeling using UML 60%
K3
Modeling
To build an extendable and scalable Analyse
C404.5 60%
solution using Design patterns K4
Develop and implement simple Apply
C404.6 applications that make use of classes, 60%
K3
packages and interfaces
Course Outcome Statements in Affective domain

C404.7 Attend the classes regularly Respond (A2) 95%

C404.8 Submit the Assignments regularly. Respond (A2) 95%

Participation in Seminar/Quiz/ Group
C404.9 Discussion/ Collaborative learning and Valuing (A3) 95%
content beyond syllabus

12
 6.CO-PO/PSO MAPPING

Correlation Matrix of the Course Outcomes to

Programme Outcomes and Programme Specific
Outcomes Including Course Enrichment Activities

Programme Outcomes (POs), Programme Specific Outcomes (PSOs)

P P P P P P P P P P P P PS PS PS
Course O O O O O O O O O O O O O O O
Outcomes 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3
(Cos)
K3
K K A
K4 K5 /K A2 A3 A3 A3 A3 A2 K3 K3 K3
3 5 3
5

K
C305.1 3 2 1 1 3 3 3 3 3
3

K
C305.2 3 3 2 2 3 3 3 3 3
4

K
C305.3 2 1 2 3 3 3
2
5
K
C305.4 3 2 1 1 3 3 3 3 3
3

K
C305.5 3 3 2 2 3 3 3 3 3
4

K
C305.6 3 2 1 1 3 3 2 2 2
3

A
C305.7 3
2

A
C305.8 2 2 2 3
2

A
C305.9 3 3 3 3 3
3

C305 3 3 2 2 3 1 1 1 3 3 3 3 3 3 3

13
 UNIT I
INTRODUCTION TO AN OBJECT-ORIENTED
TECHNOLOGIES AND UML

14
 LECTURE PLAN – UNIT I
UNIT I INTRODUCTION TO AN OBJECT-ORIENTED TECHNOLOGIES AND UML

Sl.N
o
PROPOSED ACTUAL
NO OF LECTURE LECTURE PERTAININ TAXONOMY MODE OF
TOPIC
PERIODS G CO(s) LEVEL DELIVERY

PEROID PERIOD

Introduction to
02-01-2024
1 Software 1 02-01-2024 CO1 K2 MD1
Engineering

03-01-2024
Software Process 1 CO1 K2 MD1
2
Software
Development 1 04-01-2024 CO1 K2 MD1
3
Process models

Introduction to
Agility 1 05-01-2024 CO1 K3 MD1
4

Description of
the real world
5 06-01-2024
using the 1 CO1 K3 MD1
Objects
Model.

Classes,
6 inheritance and
multiple 09-01-2024
1 CO1 K2 MD1
configurations. -
Quality software
characteristics

10-01-2024
Agile process 1 CO1 K2 MD1
7

Introduction
to the UML 1
11-01-2024
CO1 K2 MD1
8
Language

Elements of
9 12-01-2024
the language 1 CO1 K2 MD1
15
 LECTURE PLAN – UNIT I

UNIT I INTRODUCTION TO AN OBJECT-ORIENTED TECHNOLOGIES AND

UML
Sl.
No
PROPOSED ACTUAL
NO OF LECTURE LECTURE PERTAININ TAXONOMY MODE OF
TOPIC PERIOD
G CO(s) LEVEL DELIVERY
S
PEROID PERIOD

Description
1
of the real
world using 1 22-01-2024 CO1 K2 MD1
the Objects
Model.
Classes,
inheritance and
2 multiple 22-01-2024
1 CO1 K2 MD1
configurations. -
Quality software
characteristics

The process
3 of Object
Oriented 1 22-01-2024 CO1 K2 MD1
software
development

Description
of Design 1 24-01-2024 CO1 K3 MD1
4
Patterns

5 28-01-2024
Lab Exercise 1 1 CO1 K3 MD1

6
Lab Exercise 2 29-01-2024
1 CO1 K2 MD1
16
 LECTURE PLAN – UNIT I

ASSESSMENT COMPONENTS MODE OF DELEIVERY

AC 1. Unit Test MD 1. Oral presentation
AC 2. Assignment MD 2. Tutorial
AC 3. Course Seminar MD 3. Seminar
AC 4. Course Quiz MD 4 Hands On
AC 5. Case Study MD 5. Videos
AC 6. Record Work MD 6. Field Visit
AC 7. Lab / Mini Project
AC 8. Lab Model Exam
AC 9. Project Review

17
ACTIVITY BASED LEARNING – UNIT I

COMPLETE THE PUZZLES GIVEN BELOW

18
 ACTIVITY BASED LEARNING – UNIT I

QUIZ- LINK

Unit I:
Software Engineering:

https://quizizz.com/join/quiz/5ea2c608298254001d6fa416/start?from=s
oloLinkShare&referrer=5f16995403ff63001f3fdbba
SDLC:

https://quizizz.com/join/quiz/58f4d29f4d8adb1000732aec/start?from=so
loLinkShare&referrer=5f16995403ff63001f3fdbba
Software process Models:

https://quizizz.com/join/quiz/59dbd6bd3f22201000c481f8/start?from=so
loLinkShare&referrer=5f16995403ff63001f3fdbba

https://quizizz.com/join/quiz/5e10a684b2c152001bbdae63/start?from=s
oloLinkShare&referrer=5f16995403ff63001f3fdbba

SOFTWARE ENGINEERING VIDEO QUIZ-https://youtu.be/WpVoJq8hR6Q

19
Test Yourself

1. RAD stands for

a) Relative Application Development
b) Rapid Application Development
c) Rapid Application Document
d) None of the mentioned

2. Which one of the following is not a phase of Prototyping Model?

a) Quick Design
b) Coding
c) Prototype Refinement
d) Engineer Product

3. SDLC stands for

a) Software Development Life Cycle
b) System Development Life cycle
c) Software Design Life Cycle
d) System Design Life Cycle

4. The spiral model was originally proposed by

a) IBM
b) Barry Boehm
c) Pressman
d) Royce

5. Project risk factor is considered in which model?

a. Spiral model.

b. Waterfall model.

c. Prototyping model

d. None of the above.

20
 UNIT I

SOFTWARE PROCESS AND AGILE DEVELOPMENT

1.1 SOFTWARE PROCESS

INTRODUCTION
The Computer has been used for commercial purposes. With every aspect of
computer development, software engineers have been tasked to solve larger and
complex programs and in a cost effective and efficient manner. Also the development
and maintenance of software product has become an important criterion.
What is Software?
Software is
1. instructions (Computer programs) that when executed provide desired
features, function and performance;
2. Data structures that enable the programs to adequately manipulate
information; and
3. Document that describe the operation and use of the programs

Characteristics of Software

Software is developed or engineered and not manufactured.

Software doesn’t wear out.
Although the industry is moving toward component-based construction, most
software continues to be custom built.

Categories of Computer Software

System software is a set of programs that serve other programs.

Application software is stand-alone programs that solve a specific

business need.

21
 Embedded software is the software that 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. Eg: microwave oven, Air Conditioner, washing machine etc

Product-line software provide a specific capability for use by many different

customers. Eg: word processor.
Web applications called “WebApps,” provide a wide array of applications.

Artificial intelligence software makes use of non numerical algorithms to solve

complex problems. Eg: Expert systems, Robotics, Neural networks etc.

ATTRIBUTES OF GOOD SOFTWARE

The software should deliver the required functionality and performance to the user
and should be maintainable, dependable and usable.

Maintainability: Software should be written in such a way that it may evolve to

meet the changing needs of customers. This is a critical attribute because software
change is an inevitable consequence of a changing business environment.

Dependability: Software dependability has a range of characteristics, including

reliability, security and safety. Dependable software should not cause physical or
economic damage in the event of system failure.

Efficiency: Software should not make any wasteful use of system resources such
as memory and processor cycles. Efficiency therefore includes responsiveness,
processing time, memory utilization, etc.

Usability: Software must be usable, without undue effort, by the type of user for
whom it is designed. This means that it should have an appropriate user interface
and adequate documentation

22
SOFTWARE ENGINEERING:

Definitions:

Software Engineering (IEEE Standard): The application of a

systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is,
the application of engineering to software.

Software engineering is a modeling activity. Software

engineers deal with complexity through modeling, by focusing
at any one time on only the relevant details and ignoring
everything else. In the course of development, software
engineers build many different models of the system and of the
application domain.

Software engineering is a problem-solving activity. Models

are used to search for an acceptable solution. This search is
driven by experimentation. Software engineers do not have
infinite resources and are constrained by budget and deadlines.
Given the lack of a fundamental theory, they often have to rely
on empirical methods to evaluate the benefits of different
alternatives.

23
 Software engineering is a knowledge acquisition
activity. In modeling the application and solution
domain, software engineers collect data, organize it
into information, and formalize it into knowledge.
Knowledge acquisition is not sequential, as a single
piece of additional data can invalidate complete
models.

Software engineering is a rationale-driven activity. When

acquiring knowledge and making decisions about the system
or its application domain, software engineers also need to
capture the context in which decisions were made and the
rationale behind these decisions. Rationale information,
represented as a set of issue models, enables software
engineers to understand the implication of a proposed
change when revisiting a decision.

24
Object-oriented methods combine the application domain and
solution domain modeling activities into one. The application
domain is first modeled as a set of objects and relationships. This
model is then used by the system to represent the real-world
concepts it manipulates. A train traffic control system includes train
objects representing the trains it monitors. A stock trading system
includes transaction objects representing the buying and selling of
commodities. Then, solution domain concepts are also modeled as
objects. The set of lines used to depict a train or a financial
transaction are objects that are part of the solution domain. The idea
of object-oriented methods is that the solution domain model is a
transformation of the applicationdomain model.

25
 Need For Software Engineering
Ability to solve complex programming problems

How to break large projects into smaller and manageable parts?

Learn techniques of:

Specification, design, interface development, testing, project management etc.,

To acquire skills to be a better programmer:

Higher productivity

Better Quality Program

1.2SOFTWARE ENGINEERING – A LAYERED

TECHNOLOGY
Software engineering is a layered technology

tools

methods

Process

a “quality” focus

Fig: Software Engineering Layers

26
Any engineering approach (including software engineering) must rest on an

organizational commitment to quality.

The bedrock that supports software engineering is a quality focus.

The foundation for software engineering is the process layer.

Software engineering process is the glue that holds the technology layers

together and enables rational and timely development of computer software.

Process defines a framework that must be established for effective delivery

of software engineering technology.

The software process forms the basis for management control of software

projects and establishes the context in which technical methods are applied,

work products (models, documents, data, reports, forms, etc.) are produced,

milestones are established, quality is ensured, and change is properly

managed.

Software engineering methods provide the technical “how to’s” for building

software.

Methods encompass a broad array of tasks that include communication,

requirements analysis, design modeling, program construction, testing, and

support.

Tools provide automated or semi-automated support for the process and

methods.

27
1.3 SOFTWARE PROCESS
Software engineering methods rely on a set of basic principles that govern each
area of the technology and include modeling activities and other descriptive
techniques.

Software engineering tools provide automated or semiautomated support for the

process and the methods. When tools are integrated so that information created
by one tool can be used by another, a system for the support of software
development, called computer-aided software engineering, is established.

A process is a collection of activities, actions, and tasks that are performed when
some work product is to be created.

Each framework activity is populated by a set of software engineering actions—

a collection of related tasks that produces a major software engineering work
product (e.g., design is a software engineering action).

An activity strives to achieve a broad objective (e.g., communication with

stakeholders) and is applied regardless of the application domain, size of the
project, complexity of the effort, or degree of rigor with which software
engineering is to be applied.

An action (e.g., architectural design) encompasses a set of tasks that produce a

major work product (e.g., an architectural design model).

A task focuses on a small, but well-defined objective (e.g., conducting a unit

tests) that produces a tangible outcome.

28
Defining a Framework Activity:

Defining refers to specifying what actions are appropriate for a framework

activity, given the nature of the problem to be solved, the characteristics of
the people doing the work, and the stakeholders.

For a small software project, the communication activity includes contacting

the stakeholder, discuss the requirements, generate a brief statement of the
requirement and get the review and approval of it from the stakeholder.

For complex Projects, the communication activity might have six distinct
actions: inception, elicitation, elaboration, negotiation, specification, and
validation.

Identifying a Task Set

A task set defines the actual work to be done to accomplish the

objectives of a software engineering action.

A list of the task to be accomplished

A list of the work products to be produced

A list of the quality assurance filters to be applied

Eg: For a small project, the task set may include:

Make a list of stakeholders for the project.

Informal meeting with stake holders to identify the functions required

Discuss requirements and build a final list.

Prioritize requirements.

Choose the task sets that achieve the goal and still maintain quality and agility.

29
1.3.1.ProcessFlow:

Process flow describes how the framework activities and the actions and tasks
that occur within each framework activity are organized with respect to sequence
and time

Linear process flow executes each of the five activities in

sequence.

An iterative process flow repeats one or more of the activities

before proceeding to the next.

30
 An evolutionary process flow executes the activities in a circular manner.
Each evolution leads to a more complete version of the software.

A parallel process flow executes one or more activities in parallel with other
activities.

1.4. SOFTWARE DEVELOPMENT LIFE CYCLE MODELS:

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.

There are two types of Process Models

Prescriptive Process Models

Specialized Process Models

Fig: Steps in SDLC models

31
PRESCRIPTIVE PROCESS MODELS

Waterfall Model

Incremental Models

Incremental Model

RAD Model

Evolutionary Models

Prototyping

Spiral Model

Concurrent Development Model

Specialized Models
Component Based Model

Formal Models

Aspect Oriented development Models

The Unified Process

32
1.4.1 PRESCRIPTIVE PROCESS MODELS
Prescriptive process models focus on detailed definition, identification, and
application of process activities and tasks.

Their intent is to improve system quality, make projects more manageable, make
delivery dates and costs more predictable, and guide teams of software engineers
as they perform the work required to build a system.

Prescriptive process models -an orderly approach to software

development

Fig: Perspective Process Model

33
 1.4.1.1 Waterfall Model

This is also referred as classic life cycle or linear - sequential model

It is the oldest paradigm for SE.

This model is used for developing projects where the requirements are
well defined and reasonably stable, it leads to a linear fashion.

Waterfall model suggests a systematic, sequential approach to

software development.

Phases:

Communication: Customer specification of requirements

Planning - identifying the work task, analyzing the risk involved,

scheduling the project and estimating the effort and time needed
to complete the project etc

Modeling which involves translating the requirements gathered

into a design

Construction – converting the design into the executable code and

testing to uncover the errors.

Deployment includes delivery of the product and evaluation of the

software.

Problems/ Drawbacks:

Real projects rarely follow the sequential process flow.

The linear model can accommodate iteration, but it does so indirectly which
can cause confusion as the project team proceeds.

34
 It is difficult for the customer to state all requirements explicitly.

The customer must have patience. A working version of the program will not be
available until late in the project time span. A major blunder, if undetected until
the working program is reviewed, can be disastrous

The linear nature of the classic life cycle leads to “blocking states” in which
some project team members must wait for other members of the team to
complete dependent tasks. The time spent waiting can exceed the time spent on
productive work. The blocking states tend to be more prevalent at the beginning
and end of a linear sequential process.

Fig Waterfall Model

Reference Video

Software Process Models

https://www.youtube.com/watch?v=U5Q3TFi9LRA

35
 It can serve as a useful process model in situations where requirements are
fixed and work is to proceed to completion in a linear manner

1.4.2 V-Model
A variation of waterfall model is referred as V model which includes the
quality assurance actions associated with communication, modeling and early
code construction activities.

Team first moves down the left side of the V to refine the problem
requirements.

Once code is generated, the team moves up the right side of the V,
performing a series of tests that validate each of the models created.

The V-model provides a way of visualizing how verification and validation

actions are applied at the different stages of development.

Fig : V Model

36
1.4.1.3. INCREMENTAL PROCESS MODELS
Incremental models construct a partial implementation of a total system and
then slowly add increased functionality

The incremental model prioritizes requirements of the system and then

implements them in groups.

Each subsequent release of the system adds function to the previous

release, until all designed functionality has been implemented.

It combines elements of both linear and parallel process flows.

Each linear sequence produces deliverable increments of the software.

The first increment is the core product with many supplementary features.

After implementation and evaluation, 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 includes additional features and functionality.

This process is repeated following the delivery of each increment, until the
complete product is produced.

Fig: Incremental Model

37
 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.

It should be noted that the process flow for any increment can incorporate
the prototyping paradigm.

The incremental process model focuses on the delivery of an operational

product with each increment.

Incremental development can be used when staffing is unavailable for a

complete implementation by the business deadline that has been established
for the project. If the core product is well received, then additional staff if
required can be added to implement the next increment.

Increments can be planned to manage technical risks.

1.4.1.4.RAD (Rapid Application Development)

RAD model is based on prototyping and iterative development with no

specific planning involved.

Different phases of RAD model include

Business Modeling

On basis of the flow of information and distribution between various business

channels, the product is designed.

Data Modeling

The information collected from business modeling is refined into a set of data
objects that are significant for the business

38
Process Modeling

The data object that is declared in the data modeling phase is transformed to
achieve the information flow necessary to implement a business function

Application Generation

Automated tools are used for the construction of the software, to convert process
and data models into prototypes

Testing and Turnover

As prototypes are individually tested during every iteration, the overall testing
time is reduced in RAD.

Fig : RAD Model

39
 Advantages

Use of reusable components helps to reduce the cycle time of the

project.

Encourages user involvement

Reduced cost.

Flexible and adaptable to changes

Disadvantages

For large 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, then project will fail.

If a system cannot properly be modularized, building the

components necessary for RAD will be problematic.

The use of powerful and efficient tools requires highly skilled

professionals.

Customer involvement is required throughout the life cycle.

1.4.1.5 Evolutionary Models

In some cases the requirement changes over time, for such projects

evolutionary approach can be used where a limited version is delivered to

meet competitive pressure.

In this model, a set of core product and requirements is well understood, but

the details and extension have yet to be defined.

It is iterative that enables to develop increasingly more complete version of

the software.

40
 Two types of evolutionary approaches are there namely

Prototyping and

Spiral models.

PROTOTYPING
The process of building a preliminary design, trying it out, refining it,
and trying again has been called an iterative process of systems
development.

Prototyping is more explicitly iterative than the conventional life cycle,

and it actively promotes system design changes.

Prototyping consists of building an experimental system rapidly and

inexpensively for end users to evaluate.

By interacting with the prototype, users can get a better idea of their
information requirements.

The prototype can be used as a template to create the final system.

The prototype is a working version of the system or part of the system,

but it is meant to be only a preliminary model. After implementing, the
prototype will be further refined until it conforms precisely to users’
requirements.

When to use:

Customer defines a set of general objectives but does not identify detailed
requirements or the developer may not be sure of the efficiency of an algorithm.

Phases:

Begins with communication by meeting with stakeholders to define the objective,

identify whatever requirements are known, outline areas where further definition
is necessary.

41
A quick plan for prototyping and modeling is determined.

Quick design focuses on a representation of those aspects the software that will
be visible to end users.

Design leads to the construction of a prototype which will be deployed and

evaluated. Stakeholder’s comments will be used to refine requirements.

Advantages and Disadvantages of Prototyping:

Prototyping is most useful when there is some uncertainty about

requirements or design solutions.

Because prototyping encourages end-user involvement

throughout the systems development life cycle, it is more
likely to produce systems that fulfill user requirements.

If the completed prototype works reasonably well, there is no need for

reprogramming and redesign.

Quick
plan
communication
Modeling
Quick design

Deployment
delivery & Construction
feedback of prototype

Fig : Prototyping Model

42
SPIRAL MODEL

Spiral model couples the iterative nature of prototyping with the systematic
aspects of the waterfall model

It is a risk-driven process model generator that is used to guide multi-stakeholder

concurrent engineering of software intensive systems.

Two main distinguishing features:

Cyclic approach for incrementally growing a system’s degree of definition and

implementation while decreasing its degree of risk.

Set of anchor point milestones for ensuring stakeholder commitment to feasible

and mutually satisfactory system solutions.

A series of evolutionary releases are delivered.

During the early iterations, the release might be a model or

prototype. During later iterations, increasingly more complete
version of the engineered system are produced.

Fig : Spiral Model

43
 The first circuit in the clockwise direction might result in the product
specification; subsequent passes around the spiral might be used to develop a
prototype and then progressively more sophisticated versions of the software.

After each iteration, the project plan has to be refined. Cost and schedule are
adjusted based on feedback. Also, the number of iterations will be adjusted by
project manager.

Advantages & disadvantages:

Good to develop large-scale system as software evolves as the process progresses and
risk should be understood and properly reacted to.

Prototyping is used to reduce risk

It is difficult to convince customers that it is controllable as it demands considerable

risk assessment expertise.

Three Concerns on Evolutionary Processes

First concern is that prototyping poses a problem to project planning because of the
uncertain number of cycles required to construct the product.

Second, it does not establish the maximum speed of the evolution. If the evolution
occurs too fast, without a period of relaxation, it is certain that the process will fall into
chaos. On the other hand, if the speed is too slow then productivity could be affected.

Third, software processes should be focused on flexibility and extensibility rather than
on high quality. The speed of the development should be prioritized over zero defects.
Extending the development in order to reach high quality could result in a late delivery
of the product when the opportunity niche has disappeared.

Reference Video

Software Development Models

https://www.youtube.com/watch?v=DRDD7UWX2y4

44
Need for Object Oriented Programming

• In structured programming where the focus is only on the functionality

and not on the data or state of the real life entities.

• In structured programming approach, as the amount of data and

complexity of functionality increases, it becomes difficult to manage
the code.

• Hence, there is a need for a programming paradigm which not only

focuses on the functionality but also on the data or state of real life
entities.

• This is possible with a different paradigm of programming known

as Object Oriented Programming.

• Object Oriented Programming(OOP) is a type of programming approach

which enables the programmers to work with real life entities

• Eg) Customer, Trainee, Employee, Company, Product, Food, Book, etc.

• OOP helps a programmer in breaking down the code into smaller

modules.

• These modules (classes) will have state(represented by

attributes/variables) and functionality (represented by
behavior/methods).

• These modules can then be used for representing the individual real life
entities known as objects.

• E.g. - We can have a class named Customer to represent

the state and behavior of all customers. Each individual customer can
then be represented using an object of the Customer class.
• OOP has many advantages. Some of them are listed below:

• Modularity

• Scalability

• Data hiding

• Real life scenario

• Java, C#, Simula, JavaScript, Python, C++, Visual Basic .NET, Ruby,

Scala, PHP etc. are some of the popular object-oriented

programming languages.
Object Oriented Programming

Object Oriented Programming is a Methodology or Paradigm to design a Program/Software

application based on objects. Objects are real-world entity. Any things we see, that could be
differentiated from another is called object. Objects should have a well defined boundary.

Refer: https://www.youtube.com/watch?v=qwS-BCOCB-A

Characteristics of Object Oriented Programming

Objects

• Objects are real-world entity such as book, cat, house, pencil, person, etc. Any things we
see, that could be differentiated from another is called object. Objects should have a well
defined boundary. An object consists of:

• State: It is represented by attributes of an object. It also reflects the properties of an

object.

• Behavior: It is represented by methods of an object. It also reflects the response of an

object with other objects.
• Identity: It gives a unique name to an object and enables one object to interact with
other objects.

Examples of Object

Every object has its own set of properties, which defines the state of the object and its own
behavior. The properties (data) and the behaviors (methods or function that operate on the
data) are combined into a single unit, so that the data can be accessed only by those
functions and not by the outside world.

Object

The value assigned to the properties defines the state of an object and also differentiate
one object from the other.
 Breed = Dachshund
Age = 1
Color = Coral
Size = Small

Breed = Bulldog
Age = 3
Color = Brown
Size = Big

Breed = Bulldog
Age = 2
Color = Black
Size = Medium

Objects interact with each other to provide solutions to the real-

world problems through the functions. For eg. in a railway
reservation application the objects train and passenger interact with
each other through the functionalities like booking a ticket,
cancelation of tickets, etc.

Train

Properties Behavior
−Train No. −reserveticket()
−Train Name −cancelticket()
−No. of seat −checkavailability()

reserveticket()
Class

• A class is a blueprint or a template from which individual objects

are created. A class is a group of objects which have common
properties. It represents the set of properties or methods that are
common to all objects of one type. It is a logical entity. It can't be
physical. A class can contain any of the following variable types.

• Local variables − Variables defined inside methods, constructors or

blocks are called local variables. The variable will be declared and
initialized within the method and the variable will be destroyed
when the method has completed.

• Instance variables − Instance variables are variables within a class

but outside any method. These variables are initialized when the
class is instantiated. Instance variables can be accessed from inside
any method, constructor or blocks of that particular class.

• Class variables − Class variables are variables declared within a

class, outside any method, with the static keyword.

A class can have any number of methods to access the value of

various kinds of methods. In the above example, barking(), hungry()
and sleeping() are methods.

Abstraction

• Abstraction is the process used to hide certain details and only

show the essential features of the object. In other words, it deals
Encapsulation

• Encapsulation is defined as the wrapping up of data under a single unit. It

is the mechanism that binds together code and the data it manipulates.
Encapsulation is a protective shield that prevents the data from being
accessed by the code outside this shield.

• Technically in encapsulation, the variables or data of a class is hidden

from any other class and can be accessed only through any member
function of own class in which they are declared.

• As in encapsulation, the data in a class is hidden from other classes, so it

is also known as data-hiding.

• Encapsulation can be achieved by declaring all the variables in the class as

private

• Inheritance

• Inheritance is the mechanism by which one object is allowed to derive

the properties (fields and methods) of another. The class whose features
are inherited is known as super class (or a base class or a parent class).
The class that inherits the other class is known as sub class (or a derived
class, extended class, or child class). The subclass can add its own fields
and methods in addition to the superclass fields and methods.

• Inheritance supports reusability, i.e. when we want to add new features

to an existing entity, we can derive our new entity from the existing using
inheritance. This enables reusing the fields and methods of the existing
class.

Types of Inheritance
 Multi-level Inheritance

Single Class A
Inheritance

Class A
Class B

Class B
Class C

Hierarchical Inheritance Multiple Inheritance

Class A Class A Class B

Class B Class B Class C

Polymorphism

• Polymorphism is the ability of an object to take on many forms. Polymorphism is a

concept by which a single action can be performed by different ways. The most common
use of polymorphism in OOP occurs when a parent class reference is used to refer to a
child class object.

There are two types of polymorphism:

• Compile time polymorphism or Static Polymorphism or Static Binding or Early Binding –

implemented using method overloading

• Runtime polymorphism or Dynamic Polymorphism or Dynamic Binding or Late Binding –

implemented using method overriding

Method overloading is defining more than one method using same name but having
different number or type of parameters. Method overriding the redefine the base class
functions in a derived class.
Object Oriented Programming Vs Procedural Programming

Object Oriented Programming Procedural Programming

4. Objects communicate with each other 4. Functions communicate with each
via functions, so data seems to be other via data, so data seems to be
more secure less secure

Object Oriented Programming Procedural Programming

1. Basic building blocks are object and 1. Basic building blocks are function
its object centric and its algorithm centric

2. Bottom up approach 2. Top down approach

3. Easy to modify 3. Complex code

Refer:
https://drive.google.com/file/d/1RjO6Q8PHd9hTkY3Uogz4eVc35UHI
O224/view?usp=sharing
Class

• Classes are basic concepts of Object Oriented Programming which

revolve around the real life entities.

• A class is a blueprint / template / prototype for creating objects.

• A class used to define user defined data-type.

• A class is a collection of data members (Fields) and member functions

(Methods).

• A class is a logical grouping of data and functions.

• When a class is defined, no memory is allocated.

Declaring class in Java.

Every class in Java can be composed of the following elements:

• fields
• methods
• constructors
Syntax:

Access modifier class ClassName

fields;

methods;

constructors;

This is a class declaration. The class body (the area between the
braces) contains all the code that provides for the life cycle of the
objects created from the class:

constructors for initializing new objects, declarations for the fields

that provide the state of the class and its objects, and methods to
implement the behavior of the class and its objects.

Example code to declare a class:

Class declarations can include these components, in order:

• Modifiers such as public, private, and a number of others.

• The class name, with the initial letter capitalized by convention.

• The name of the class's parent (superclass), if any, preceded by the keyword extends. A
class can only extend (subclass) one parent.

• A comma-separated list of interfaces implemented by the class, if any, preceded by the

keyword implements. A class can implement more than one interface.

• The class body, surrounded by braces, {}.

Objects

Objects are basic concepts of Object Oriented Programming which revolve around the real
life entities. A Java program creates many objects, interact by invoking methods.

Through these object interactions, a program can carry out various tasks, such as
implementing a GUI, running an animation, or sending and receiving information over a
network. Once an object has completed the work for which it was created, its resources are
recycled for use by other objects.

Creating Object

• An object is an instance of a class.

• When an object is instantiated / created memory is allocated.

• A software object maintains its state in variables and implements its behaviour with
methods.

• Objects are the building blocks of Object Oriented Programming

Using new keyword

The new keyword is used to create objects

Syntax:
ClassName objectName = new ClassName();
Example:

Employee empOne = new Employee(“Vijayakumar S”);

Object Creation has three parts

1. Declaration: Variable declarations that associate a variable name with an

object type.

2. Instantiation: The new keyword is a Java operator that creates the object.

3. Initialization: The new operator is followed by a call to a constructor, which

initialize the new object.

Methods

A method is defined as a sequence of some declaration and execution

statements. These statements gather together to perform a specific task. A
function or a method must be defined before it is used anywhere in the
program.

Syntax :
[access-specifier] [modifier] return-type function-name ([parameter list])
{
body of the function/method;
}

1. Access specifier

It can be public or protected or private or default. It is optional to use an access

specifier while defining a method.
2. Modifier

It can be static, final, synchronized, transient, and volatile. It is optional to

use a modifier

3. Return-Type

It specifies the type of value that the return statement of the function
returns. It may be any valid Java data type. If no value is being returned,
we use the return type as void.

4. Function-name

The name of the function should be a valid Java identifier. The naming
conventions generally followed for method names are:

✔ It should be meaningful.

✔ It should begin with a lowercase letter. For names having multiple

words, we use the camelCase naming convention.

For example:
✔ printReportCard()
✔ getMarks()

• The method name should generally begin with a verb followed by one
or more nouns.

For example:
✔ readData
✔ findFile
✔ calculateInterestAmount

5. Parameter list

The parameter list is a comma-separated list of variables of a function

referred to as arguments or parameters. A function may be without any
parameters and in this case, the parameter list is empty.
6. Method Body

The body of the Java method should be enclosed within curly braces{}
containing all the code to perform operations and tasks .

static members

In Java, static members are those which belong to the class which can be
accessed without instantiating the class. The static keyword can be used
with methods, fields, classes (inner/nested), blocks.

Example method definition:

Constructors

• Constructor initializes an object when it is created.

• Constructor has the same name as its class.

• Constructor is syntactically similar to a method.

• Constructors have no explicit return type.

• Constructors are used to give initial values to the instance variables or

to perform any other start-up procedures.

• All classes have constructors, whether programmer define one or not.

• Java automatically provides a default constructor that initializes all

member variables to default values.
• Once programmer defines own constructor, the system defined default
constructor is no longer used.

Syntax:
class ClassName
{
ClassName()
{
// Initialization Statements;
}
}

Java allows two types of constructors:

• No argument Constructors (Also called as Default Constructor)

• Parameterized Constructors

No Argument Constructors - User Defined Default Constructor

• No argument constructors of Java does not accept any parameters.

• Constructor which is defined in the class by the programmer is known

as user-defined default constructor.

• These constructors the instance variables of a method will be initialized

with fixed values for all objects.
Description of the Object Oriented
Analysis process vs. the Structure
Analysis Model
Structured Analysis and Object-Oriented Analysis (OOA) are two distinct
methodologies used in software development. Comparison of the Object-Oriented
Analysis process vs. the Structured Analysis Model:
•Structured Analysis
Emphasizes the functional decomposition of a software system into
smaller, independent functions
Does not provide the object orientation and encapsulation benefits of
OOA, making it more difficult to manage and maintain large systems over
time.
Has a limited ability to model complex relationships between objects
•Object-Oriented Analysis (OOA):
Focuses on the objects involved in a software system, modeling them as
instances of classes that encapsulate both data and behavior.
Follows a bottom-up approach, building complex systems from smaller,
simpler objects that can be more easily understood.
Models the relationships and interactions between objects, providing a
more comprehensive and object-centered view of the software systemIn
summary, while Structured Analysis emphasizes functional decomposition,
Object-Oriented Analysis focuses on modeling objects and their
interactions, providing benefits such as object orientation, encapsulation,
and the ability to model complex relationships between objects.

61
software crisis
The software crisis refers to the recurring problems in system
development caused by software development issues that
cause the entire system to be late, over budget, not
responsive to user and customer requirements, and difficult to
use, maintain, and enhance. The term was coined in the late
1960s to describe the difficulties in writing useful and efficient
computer programs in the required time. The crisis was due
to the rapid increases in computer power and the complexity
of the software, which led to many software problems
because existing methods were inadequate. The crisis
prompted the development of structured programming and
software engineering principles. The software crisis
underscores the importance of process refinement,
collaboration, and adaptable methodologies, shaping modern
software engineering practices. There is no single solution to
the crisis, but software engineering is a disciplined and
quantifiable approach that can help prevent software crises.

62
1. Some proposed solutions to the software crisis include:Reduction
in software over budget: Implementing cost-effective strategies
and efficient project management techniques can help reduce the
financial burden of software development projects

2. Improving software quality: Ensuring that software meets user

requirements and is reliable, maintainable, and easy to enhance is
crucial for addressing the software crisis

3. Less time needed for software projects: Adopting agile

methodologies, such as Scrum or Kanban, can help reduce the
time required for software development while maintaining high
quality

4. Experienced and skilled people working on the software project:

Hiring and retaining experienced software developers and
engineers can help improve the quality of software and reduce the
likelihood of crises

5. Software engineering principles: Adopting structured programming

and software engineering principles can help prevent software
crises by providing a disciplined and quantifiable approach to
software development

6. Functional programming with Haskell: Some companies have

found success in using functional programming languages like
Haskell, which can help reduce bug repair and improve software
development efficiency

63
1.6 INTRODUCTION TO AGILITY

What is Agility?

Agility is effective (rapid and adaptive) response to change (changes in team

members, new technology, requirements etc) that may have an impact on the
product being developed.

It encourages effective communication in structure and attitudes among all

team members, technological and business people, software engineers and
managers.

It emphasizes rapid delivery of operational software and de-emphasizes the

importance of intermediate work products (not always a good thing);

It involves the customer in the development team and works to eliminate the
“us and them” attitude that continues to pervade many software projects

It recognizes that planning in an uncertain world has its limits and that a
project plan must be flexible.

Agility can be applied to any software process but it is essential that the
process should support incremental delivery strategy that gets working
software to the customer as rapidly as feasible for the product type and
operational environment.

Agility and the Cost of Change

The cost of change increases nonlinearly as a project progresses.

It is easy to accommodate a change in the early stages of a project and cost

will be minimal but in case of major functional change, it requires a
modification to the architectural design, construction, testing etc. so the Costs
escalate quickly.

A well-designed agile process may “flatten” the cost of change curve by

coupling the incremental delivery with agile practices such as continuous unit
testing and pair programming.

64
 Fig: Development schedule
Agility Principles

Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes

harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of

months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a
development team is face–to–face conversation.

65
Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and

users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity – the art of maximizing the amount of work not done – is essential.

The best architectures, requirements, and designs emerge from self–organizing

teams.

At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.

Human Factors

“Agile development focuses on the talents and skills of individuals,

molding the process to specific people and teams.” i.e. The process
molds to the needs of the people and team, not the other way
around.

The key traits that must exist among the people on an agile team are:

Competence.

Common focus.

Collaboration.

Decision-making ability.

Fuzzy problem-solving ability.

Mutual trust and respect.

Self-organization.

66
Agile Process

Agile software process addresses a number of key assumptions say:

It is difficult to predict in advance which software requirements will persist

and which will change. It is equally difficult to predict how customer
priorities will change as the project proceeds.

For many types of software, design and construction are interleaved. It is

difficult to predict how much design is necessary before construction is used
to prove the design.

Analysis, design, construction, and testing are not as predictable (from a

planning point of view) as we might like.

An agile process must be adaptable in order to manage the

unpredictability.

An agile software process must adapt incrementally.

Agile SDLC model is a combination of iterative and incremental process

models with focus on process adaptability and customer satisfaction by
rapid delivery of working software product.

Agile Methods break the product into small incremental builds.

Each build is incremental in terms of features and the final build holds all the
features required by the customer.

Every iteration involves cross functional teams working simultaneously on various

areas like −

Planning

Requirements Analysis

Design

Coding

Testing

67
Advantages:

Rapid Functionality development

Promotes team work

Adaptable to changing requirements

Delivers early partial working solutions.

Flexible and Easy to manage.

Disadvantages

Not suitable for complex projects/dependencies.

Depends heavily on customer interaction, so if customer is not

clear, team can be driven in the wrong direction.

Prioritizing changes can be difficult where there are multiple

stakeholders.

Note:

Agile methods include Rational Unified Process, Scrum, Extreme Programming,

Adaptive Software Development, Crystal clear, Feature Driven Development, and
Dynamic Systems Development Method. These are now collectively referred to as
Agile Methodologies.

Fig: Agile Development Models

68
Quality software characteristics

The characteristics of quality software, also known as system

quality attribut The characteristics of quality software,
also known as system quality attributes, include various
aspects that contribute to the overall quality of a
software product. Some of these characteristics are:
 Functionality: The software's ability to provide the
functions that meet stated and implied needs
 Reliability: The software's ability to maintain a
specified level of performance under stated
conditions for a specified period
 Usability: The software's ease of use and its ability to
be understood, learned, and operated
 Performance efficiency: The software's performance
relative to the amount of resources used under
stated conditions
 Security: The software's ability to prevent
unauthorized access and to protect data from
damage or theft
 Compatibility: The software's ability to coexist with
other independent systems without causing
unacceptable interactions
 Maintainability: The software's ability to be
modified
These characteristics are essential for building a
functional and high-quality software product
They are used to evaluate the performance and
effectiveness of the software and are crucial for its
success in meeting user and business needs.

69
UNIT I UML AND USE CASE DIAGRAMS

Introduction

Object Oriented analysis and design skills are essential for the creation of
well-designed, robust, and maintainable software using OO technologies and
languages such as Java or C#.

Requirements analysis and OOA/D needs to be presented and practiced in

the context of some development process. In this case, an agile (light ,flexible)
approach to the well-known Unified Process (UP) is used as the sample
iterative development process are taken . It includes

Apply principles and patterns to create better object designs.

Iteratively follow a set of common activities in analysis and design, based

on an agile approach to the UP as an example.

Create frequently used diagrams in the UML notation.

What is Analysis and Design?

Analysis (do the right thing )emphasizes an investigation of the

problem and requirements, rather than a solution. For example, if a new online
trading system is desired, how will it be used? What are its functions?

Design (do the thing right ) 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. Design ideas often exclude low-level or "obvious" detail.

What is Object-Oriented Analysis and Design?

Object-Oriented Analysis : It 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.
 Object-Oriented Design : It emphasis on defining software objects
and how they collaborate to fulfill the requirements. For example, a Plane
software object may have a tail Number attribute and a get Flight History method.

During implementation or object-oriented programming, design objects are

implemented, such as a Plane class in Java.

Figure Object-orientation emphasizes representation of

objects.
 Define Use Cases : Requirements analysis may include stories or scenarios
of how people use the application; these can be written as use cases. They are a
popular tool in requirements analysis. For example, the Play a Dice Game use case:

Play a Dice Game: Player requests to roll the dice. System presents results:
If the dice face value totals seven, player wins; otherwise, player loses.

Define a Domain Model

There is an identification of the concepts, attributes, and associations that

are considered important. The result can be expressed in a domain model that
shows the important. domain concepts or objects.

Figure 2. Partial domain model of the dice game.

iii) Assign Object Responsibilities and Draw Interaction Diagrams

Object-oriented design is concerned with defining software objects their

responsibilities and collaborations. It shows the flow of messages between
software objects, and thus the invocation of methods.
 For example, the sequence diagram in Figure 3 illustrates an OO software
design, by sending messages to instances of the DiceGame and Die classes.

Notice that although in the real world a player rolls the dice, in the
software design the DiceGame object "rolls" the dice (that is, sends messages to
Die objects). Software object designs and programs do take some inspiration from
real-world domains, but they are not direct models or simulations of the real
world.

Figure Sequence diagram illustrating messages between software

objects.

iv) 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.

For example, in the dice game, an inspection of the sequence diagram

leads to the partial design class diagram shown in Figure 4. Since a play message
is sent to a DiceGame object, the DiceGame class requires a play method, while
class Die requires a roll and get FaceValue method.
 Figure . Partial design class diagram.

What is the UML?

The Unified Modeling Language is a visual language for specifying,

constructing and documenting the artifacts of systems. The word visual in the
definition is a key point the UML is the de facto standard diagramming notation
for drawing or presenting pictures. The standard is managed, and was created, by
the Object Management Group. It was first added to the list of OMG adopted
technologies in 1997.

UML is composed of 9 graphical diagrams:

1.Class Diagram-describes the structure of a system by showing the system’s

classes ,their attributes, and the relationships among the classes.

2.Use Case Diagram-describes the functionality provided by a system in terms

of actors, their goals represented as use cases, and any dependencies among
those use cases.

3.Behaviour Diagram

a. Interaction Diagram

i. Sequence Diagram-shows how objects communicate with each other

in terms of a sequence of messages .Also indicates the lifespan of objects relative
to those messages.
 ii. Communication diagram: how the interactions between objects or
parts in terms of sequenced messages

b. State Chart Diagram –describes the states and state transitions of the
system.

c. Activity Diagram-describes the business and operational step-by step –

workflows of components in a system.an activity diagram shows he overall flow of
control.

4.Implementation Diagram

a. Component Diagram-describes how a software system is split up into

components and shows the dependencies among these components.

b.Deployment Diagram-describes the hardware used in system

implementations and the execution environments and artifacts deployed on the
hardware.

Three Ways to Apply UML

UML as sketch : Informal and incomplete diagrams created to explore

difficult parts of the problem or solution space, exploiting the power of visual
languages.

UML as blueprint : Relatively detailed design diagrams used either for

1) Reverse Engineering : UML tool reads the source or binaries and

generates UML package, class, and sequence diagrams to visualize and
better understanding of existing code in UML diagrams .

2) Forward Engineering : code generation . Before programming, some

detailed diagrams can provide guidance for code generation (e.g., in
Java), either manually or automatically with a tool. It's common that the
diagrams are used for some code, and other code is filled in by a
developer while coding

UML as programming language : Complete executable specification of a

software system in UML. Executable code will be automatically generated
 Three Perspectives to Apply UML

The same UML class diagram notation can be used to draw pictures of
concepts in the real world or software classes in Java.

1. Conceptual perspective - the diagrams are interpreted as describing

things in a situation of the real world or domain of interest.

2. Specification (software) perspective - the diagrams (using the

same notation as in the conceptual perspective) describe software abstractions
or components with specifications and interfaces, but no commitment to a
particular implementation (for example, not specifically a class in C# or Java).

3. Implementation (software) perspective - the diagrams describe

software implementations in a particular technology (such as Java).

Figure 5:Conceptual Perspective and Software Perspective.

UML Notation

A Project, whose purpose is to develop a software

system, is composed of a number of Activities. Each
Activity is in turn composed of a number of Tasks. A
Task consumes Resources and produces a
WorkProduct. A WorkProduct can be either a
System, a Model, or a Document. Resources are
either Participants, Time, or Equipment. A
graphical representation of these concepts is shown in
Figure 1-1. Each rectangle represents a concept. The lines
among the rectangles represent different relationships
between the concepts. For example, the diamond shape
indicates aggregation: a Project includes a number of
Activities, which includes a number of Tasks. The
triangle shape indicates a generalization relationship;
Participants, Time, and Equipment are specific
kinds of Resources. Figure 1-1 is represented in the
Unified Modeling Language (UML) notation.

77
Software engineering concepts depicted as a UML class diagram

78
 Participants and Roles
Developing a software system requires the collaboration of many
people with different backgrounds and interests. The client orders
and pays for the system. The developers construct the system. The
project manager plans and budgets the project and coordinates the
developers and the client. The end users are supported by the
system. We refer to all the persons involved in the project as
participants. We refer to a set of responsibilities in the project or
the system as a role. A role is associated with a set of tasks and is
assigned to a participant. The same participant can fill multiple
roles.

Consider a TicketDistributor system:

TicketDistributor is a machine that distributes tickets for trains.

Travelers have the option of selecting a ticket for a single trip or for multiple
trips, or selecting a time card for a day or a week. The
TicketDistributor computes the price of the requested ticket based on
the area in which the trip will take place and whether the traveler is a child or
an adult. The TicketDistributor must be able to handle several
exceptions, such as travelers who do not complete the transaction, travelers
who attempt to pay with large bills, and resource outages, such as running out
of tickets, change, or power.

79
 Systems and Models
We use the term system as a collection of interconnected parts. Modeling is
a way to deal with complexity by ignoring irrelevant details. We use the
term model to refer to any abstraction of the system. A
TicketDistributor for an underground train is a system. Blueprints
for the TicketDistributor, schematics of its electrical wiring, and
object models of its software are models of the TicketDistributor.
Note that a development project is itself a system that can be modeled. The
project schedule, its budget, and its planned deadlines are models of the
development project.

Work Products

A work product is an artifact that is produced during the development,

such as a document or a piece of software for other developers or for the
client. We refer to a work product for the project’s internal consumption as
an internal work product. We refer to a work product that must be
delivered to a client as a deliverable. Deliverables are generally defined
prior to the start of the project and specified by a contract binding the
developers with the client. Table 1-2 describes examples of work products
for the TicketDistributor example.

Activities, Tasks, and Resources

An activity is a set of tasks that is performed toward a specific purpose. For

example, requirements elicitation is an activity whose purpose is to define with the
client what the system will do.

80
 Delivery is an activity whose purpose is to install the
system at an operational location. Management is an activity
whose purpose is to monitor and control the project such that it
meets its goals (e.g., deadline, quality, budget). Activities can be
composed of other activities. The delivery activity includes a
software installation activity and an operator training activity.
Activities are also sometimes called phases
A task represents an atomic unit of work that can be
managed: A manager assigns it to a developer, the developer
carries it out, and the manager monitors the progress and
completion of the task. Tasks consume resources, result in work
products, and depend on work products produced by other
tasks.
Resources are assets that are used to accomplish work.
Resources include time, equipment, and labor. When planning a
project, a manager breaks down the work into tasks and assigns
them to resources.

Requirements specify a set of features that the system must have. A

functional requirement is a specification of a function that the system
must support, whereas a nonfunctional requirementis a constraint on
the operation of the system that is not related directly to a function of the
system.

81
 Notations, Methods, and Methodologies
A notation is a graphical or textual set of rules for representing a
model. The Roman alphabet is a notation for representing words.
UML (Unified Modeling Language [OMG, 2009]), the notation we
use throughout this book, is a notation for representing object-
oriented models. The use of notations in software engineering is
common and predates object-oriented concepts. Data flow diagrams
[De Marco, 1978] is a notation for representing systems in terms of
data sources, data sinks, and data transformations. Z [Spivey, 1989]
is a notation for representing systems based on set theory.
A method is a repeatable technique that specifies the steps
involved in solving a specific problem. A recipe is a method for
cooking a specific dish. A sorting algorithm is a method for ordering
elements of a list. Rationale management is a method for justifying
change. Configuration management is a method for tracking change.
A methodology is a collection of methods for solving a class of
problems and specifies how and when each method should be used.
A seafood cookbook with a collection of recipes is a methodology
for preparing seafood if it also contains advice on how ingredients
should be used and what to do if not all ingredients are available.
Royce’s methodology [Royce, 1998], the Object Modeling
Technique (OMT [Rumbaugh et al., 1991]), the Booch methodology
[Booch, 1994], and Catalysis [D’Souza & Wills, 1999] are object-
oriented methodologies for developing software.

82
 Software development methodologies decompose the process into
activities. OMT provides methods for three activities: Analysis,
which focuses on formalizing the system requirements into an
object model, System Design, which focuses on strategic decisions,
and Object Design, which transforms the analysis model into an
object model that can be implemented. The OMT methodology
assumes that requirements have already been defined and does not
provide methods for eliciting requirements. The Unified Software
Development Process also includes an Analysis activity and treats
System Design and Object Design as a single activity called Design.
The Unified Process, unlike OMT, includes a Requirements Capture
activity for eliciting and modeling requirements. Catalysis, while
using the same notations as the Unified Process, focuses more on
reuse of design and code using patterns and frameworks. All of
these methodologies focus on dealing with complex systems.
Software Development activities deal with the complexity
by constructing and validating models of the application
domain or the system. Development activities include

• Requirements Elicitation
• Analysis
• System Design
• Object Design
• Implementation
• Testing

83
Introduction to the UML Language Standards

UML is a notation that resulted from the unification of

OMT (Object Modeling Technique [Rumbaugh et al.,
1991]), Booch [Booch, 1994], and OOSE (Object-
Oriented Software Engineering [Jacobson et al., 1992]).
UML has also been influenced by other object-oriented
notations, such as those introduced by Mellor and Shlaer
[Mellor & Shlaer, 1998], Coad and Yourdon [Coad et
al., 1995], Wirfs-Brock [Wirfs-Brock et al., 1990], and
Martin and Odell [Martin & Odell, 1992].

The goal of UML is to provide a standard notation that can be

used by all object-oriented methods and to select and integrate
the best elements of precursor notations. For example, UML
includes the use case diagrams introduced by OOSE and uses
many features of the OMT class diagrams. UML also includes
new concepts that were not present in other major methods at
the time, such as extension mechanisms and a constraint
language. UML has been designed for a broad range of
applications. Hence, it provides constructs for a broad range of
systems and activities (e.g., distributed systems, analysis,
system design, deployment).

84
System development focuses on three
different models of the system
The functional model, represented in UML with use
case diagrams, describes the functionality of the system
from the user’s point of view.
• The object model, represented in UML with class
diagrams, describes the structure of the system in
terms of objects, attributes, associations, and
operations. During requirements and analysis, the
object model starts as the analysis object model and
describes the application concepts relevant to the
system. During system design, the object model is
refined into the system design object model and
includes descriptions of the subsystem interfaces.
During object design, the object model is refined into
the object design model and includes detailed
descriptions of solution objects.
• The dynamic model, represented in UML with
interaction diagrams, state machine diagrams, and
activity diagrams, describes the internal behavior of
the system. Interaction diagrams describe behavior as
a sequence of messages exchanged among a set of
objects, whereas state machine diagrams describe
behavior in terms of states of an individual object and
the possible transitions between states. Activity
diagrams describe behavior in terms control and data
flows.

85
Elements of UML Language

The Unified Modeling Language (UML) is a general-

purpose visual modeling language that provides a
standard notation for many types of diagrams, which
can be roughly divided into three main groups: behavior
diagrams, interaction diagrams, and structure diagrams

The elements of the UML language include various

types of diagrams, such as use case diagrams, class
diagrams, sequence diagrams, activity diagrams, state
machine diagrams, and component diagrams

These diagrams represent different aspects of a

software system, such as its functionality, structure,
behavior, and interactions with external systems. UML
model elements are abstractions of structural or
behavioral features of the system being modeled and
add semantic content to a model

The UML language is used to help system and software

developers specify, visualize, construct, and document
the artifacts of software systems, as well as for business
modeling and other non-software systems

86
 USECASE Diagram
Use cases are used during requirements elicitation and
analysis to represent the functionality of the system. Use
cases focus on the behavior of the system from an external
point of view. A use case describes a function provided by
the system that yields a visible result for an actor. An actor
describes any entity that interacts with the system (e.g., a
user, another system, the system’s physical environment).
The identification of actors and use cases results in the
definition of the boundary of the system, that is, in
differentiating the tasks accomplished by the system and the
tasks accomplished by its environment. The actors are
outside the boundary of the system, whereas the use cases
are inside the boundary of the system.
For example, Figure 2-1 depicts a use case diagram for a
simple watch. The WatchUser actor may either consult
the time on their watch (with the ReadTime use case) or
set the time (with the SetTime use case). However, only
the WatchRepairPerson actor can change the battery
of the watch (with the ChangeBattery use case).

87
The above diagram shows the UML use case diagram which
describes the functionality of a simple watch. The WatchUser
actor may either consult the time on her watch (with the
ReadTime use case) or set the time (with the SetTime use
case). However, only the WatchRepairPerson actor can
change the battery of the watch (with the ChangeBattery
use case). Actors are represented with stick figures, use cases
with ovals, and the boundary of the system with a box enclosing
the use cases

CLASS DIAGRAM
Class diagrams are used to describe the structure of the
system. Classes are abstractions that specify the
common structure and behavior of a set of objects.
Objects are instances of classes that are created,
modified, and destroyed during the execution of the
system. An object has state that includes the values of its
attributes and its links with other objects.
Class diagrams describe the system in terms of
objects, classes, attributes, operations, and their
associations. For example, Figure 2-2 is a class diagram
describing the elements of all the watches of the
SimpleWatch class. These watch objects all have an
association to an object of the PushButton class, an
object of the Display class, an object of the Time
class, and an object of the Battery class. The
numbers on the ends of associations denote the number
of links each SimpleWatch object can have with an
object of a given class. For example, a SimpleWatch
has exactly two PushButtons, one Display, two
Batteries, and one Time. Similarly, all
PushButton, Display, Time, and Battery
objects are associated with exactly one SimpleWatch
object.

88
A UML class diagram describing the elements of a simple
watch.

At the analysis level, associations represent

existence relationships. For example, a
SimpleWatch requires the correct number of
PushButtons, Displays, Batteries, and
Time. In this example, the association is
symmetrical: PushButton cannot perform its
function without a SimpleWatch. UML also
allows for one-directional relationships, which we
describe in Section 2.4.2. At the implementation
level, associations are realized as references (i.e.,
pointers)to objects.

89
Interaction Diagrams

Interaction diagrams are used to formalize the dynamic behavior of

the system and to visualize the communication among objects. They
are useful for identifying additional objects that participate in the use
cases. We call objects involved in a use case participating objects.
An interaction diagram represents the interactions that take place
among these objects. For example, Figure 2-3 is a special form of
interaction diagram, called a sequence diagram, for the SetTime use
case of our simple watch. The left-most column represents the
WatchUser actor who initiates the use case. Labeled arrows
represent stimuli that an actor or an object sends to other objects. In
this case, the WatchUser presses button 1 twice and button 2
once to set her watch a minute ahead. The SetTime use case
terminates when the WatchUser presses both buttons
simultaneously.

90
A UML sequence diagram for the Watch. The left-most
column represents the timeline of the WatchUser actor
who initiates the use case. The other columns represent the
timeline of the objects that participate in this use case.
Object names are underlined to denote that they are
instances (as opposed to classes). Labeled arrows are stimuli
that an actor or an object sends to other objects.

State Machine Diagrams

State machine diagrams describe the dynamic
behavior of an individual object as a number of states
and transitions between these states. A state
represents a particular set of values for an object.
Given a state, a transition represents a future state the
object can move to and the conditions associated with
the change of state. For example, Figure 2-4 is a state
machine diagram for the Watch. A small black circle
initiates that BlinkHours is the initial state. A circle
surrounding a small black circle indicates that
StopBlinking is a final state. Note that this diagram
represents different information than the sequence
diagram of Figure 2-3. The sequence diagram focuses
on the messages exchanged between objects as a
result of external events created by actors. The state
machine diagram focuses on the transitions between
states as a result of external events for an individual
object.

91
1. Activity Diagrams

92
Activity Diagrams
An activity diagram describes the behavior of a system in terms
of activities. Activities are modeling elements that represent the
execution of a set of operations. The execution of an activity
can be triggered by the completion of other activities, by the
availability of objects, or by external events. Activity diagrams
are similar to flowchart diagrams in that they can be used to
represent control flow (i.e., the order in which operations occur)
and data flow (i.e., the objects that are exchanged among
operations). For example, Figure 2-5 is an activity diagram
representing activities related to managing an Incident.
Rounded rectangles represent activities; arrows between
activities represent control flow; thick bars represent the.
synchronization of the control flow. The activity diagram of
Figure 2-5 depicts that the AllocateResources,
CoordinateResources, and DocumentIncident can
be initiated only after the OpenIncident activity has been
completed. Similarly, the ArchiveIncident activity can be
initiated only after the completion of AllocateResources,
Coordinate–Resources, and DocumentIncident.
These latter three activities, however, can occur concurrently.

93
 An example of a UML activity diagram. Activity diagrams
represent behavior in terms of activities and their
precedence constraints. The completion of an activity
triggers an outgoing transition, which in turn may initiate
another activity.

Refer. This below link for UML Diagrams

https://www.javatpoint.com/uml

94
The process of Object Oriented software
development.
The process of Object-Oriented software development
involves several phases, including object-oriented analysis,
object-oriented design, and object-oriented
implementation and testing

. In the object-oriented analysis phase, the problem is

formulated, user requirements are identified, and a model is
built based on real-world objects. The object-oriented
design phase involves designing the internal details of the
classes and their associations, including the data structure
for each attribute and the algorithms for the operations. In
the object-oriented implementation and testing phase, the
design model developed in the object design phase is
translated into code, databases are created, and specific
hardware requirements are ascertained. Once the code is in
shape, it is tested using specialized techniques to identify
and remove errors in the code

. The process of Object-Oriented software development is

iterative, and developers cycle through the last four steps
several times to refine the software product

95
The key principles of Object-Oriented Programming (OOP) are:

Encapsulation: Encapsulation is the process of hiding internal

data and implementation details of an object from other parts
of the program. This helps to protect the integrity of the object
and makes it easier to maintain and update the software

Abstraction: Abstraction is the process of focusing on the

essential aspects of an object and ignoring the non-essential
details. This helps to simplify the software design and make it
easier to understand and use

Inheritance: Inheritance is the process of creating new classes

based on existing classes. This allows developers to reuse
existing code and create new classes that are similar to but not
identical to the existing classes. This helps to reduce code
duplication and improve code reusability

Polymorphism: Polymorphism is the ability of an object to take

on multiple forms or behaviors. This allows objects to be
treated as a member of a class rather than as an individual
object. This helps to improve code flexibility and
maintainabilityThese principles are the foundation of OOP and
help to create software that is modular, reusable, and easy to
maintain. By using these principles, developers can create
software that is more efficient, scalable, and adaptable to
changing requirements.

96
Description of Design Patterns
Design patterns are formalized best practices that provide
solutions to common problems in software design. They are like
pre-made blueprints that can be customized to solve recurring
design problems in specific contexts

. Design patterns are not specific pieces of code, but rather

general concepts for solving particular problems . There are three
main types of design patterns:

Creational patterns: These patterns are designed for class

instantiation and can be either class-creation patterns or
object-creational patterns

Structural patterns: These patterns focus on the class

structure and composition, aiming to increase the
functionality of the class(es) involved without changing
much of their composition

Behavioral patterns: These patterns are designed based on

how one class communicates with others, addressing
issues related to communication and interaction between
classes Design patterns are often used in Object-Oriented
Programming (OOP) languages like Java, and they can
help improve code readability, maintainability, and
reusability

97
creational design patterns
Some examples of creational design patterns include:

Singleton Pattern: Ensures that a class has only one instance

and provides a global point of access to it

Factory Method Pattern: Allows a class to defer instantiation

to subclasses

Abstract Factory Pattern: Provides an interface for creating

related or dependent objects without specifying the objects

Builder Pattern: Separates the construction of a complex

object from its representation, allowing the same construction
process to create different representations

Prototype Pattern: Specifies the kind of object to create using

a prototypical instance, and creates new objects by cloning
this prototype

Object Pool Pattern: Avoids expensive acquisition and release

of resources by recycling objects that are no longer in use

These patterns help to create objects in a controlled manner,

reducing complexities and instability in the software design

98
Structural design patterns
Structural design patterns are concerned with how classes and objects can be
composed to form larger structures. They simplify the structure by identifying
relationships and focusing on how classes inherit from each other and how they
are composed from other classes

. Some examples of structural design patterns include:

Adapter Pattern: Adapts one interface for a class into one that a client
expects

Bridge Pattern: Decouples an abstraction from its implementation so that

the two can vary independently

Composite Pattern: A tree structure of objects where every object has the
same interface

Decorator Pattern: Adds additional functionality to an object at runtime

where subclassing would result in an unwieldy class hierarchy

Facade Pattern: Provides a simplified interface to a library, a framework,

or any other complex set of classes

Flyweight Pattern: Shares common parts of state between objects to fit

more objects into the available amount of RAM

Proxy Pattern: Provides a substitute or placeholder for another object,

controlling access to the original objectThese patterns help to create
flexible and efficient structures in software design, allowing objects with
incompatible interfaces to collaborate and simplifying the structure of the
application

99
Behavioural design patterns
Behavioural design patterns in software engineering are concerned
with algorithms and the assignment of responsibilities between
objects. They identify common communication patterns among
objects, thus increasing flexibility in carrying out communication

Some examples of behavioural design patterns include the Observer

pattern, Strategy pattern, State pattern, Template Method pattern, and
Memento pattern

These patterns help in defining how objects interact and

communicate with each other, allowing for more flexible and
maintainable software designs

Observer Pattern: Defines a one-to-many dependency

between objects so that when one object changes state, all its
dependents are notified and updated automatically

Strategy Pattern: Defines a family of algorithms,

encapsulates each one, and makes them interchangeable.
Algorithms can be selected on the fly, using composition

State Pattern: Allows an object to change its behavior when

its internal state changes. The object will appear to change its
class

100
Template Method Pattern: Defines the skeleton of an
algorithm in a method, deferring some steps to
subclasses. Algorithms can be selected on the fly, using
inheritance

Visitor Pattern: Separates an algorithm from an object

structure by moving the algorithm into a separate class
called a visitor. This allows the algorithm to be changed
without changing the classes of the objects

Command Pattern: Encapsulates a request as an

object, thereby letting you parameterize clients with
different requests, queue or log requests, and support
undoable operations

Iterator Pattern: Provides a way to access the

elements of an aggregate object sequentially without
exposing its underlying representation These patterns
help in defining how objects interact and communicate
with each other, allowing for more flexible and
maintainable software designs

101
 ASSIGNMENT – UNIT I

1. Assume that you are the technical manager of a software development

organization. A client approached you for a software solution. The
problems stated by the client have uncertainties which lead to loss if it
not planned and solved. Which software development model you will
suggest for this project – justify. Explain that model with its pros and
cons and neat sketch (K3)

2. Compare the various Software development process models (K3)

3. Differentiate Waterfall and Spiral Model in detail

4. Explain the OOP concepts

5. Explain UML diagams with examples

102
 PART A- UNIT-1

1. What is Software Engineering?/ Write the IEEE definition of

software engineering (K2),CO1

Software Engineering is the establishment and use of sound engineering

principles in order to obtain economically software that is reliable and
works efficiently on real machines.

Software Engineering (IEEE Standard): (1) The application of a systematic,

disciplined, quantifiable approach to the development, operation, and
maintenance of software

2. What are the umbrella activities of a software process? (K2),CO1

Software project tracking and control.

Risk management.
Software Quality Assurance
Formal Technical Reviews.

Software Configuration Management.

Work product preparation and production.
Reusability management.

Measurement.

3. What does Verification and Validation represents? (K2), CO1

Verification represents the set of activities that are carried out to

confirm that the software correctly implements the specific
functionality.

Validation represents the set of activities that ensure that the software
that has been built is satisfying the customer requirements

103
 PART A- UNIT-1

4. What are the characteristics of the software? (K2), CO1

Software is engineered, not manufactured.

Software does not wear out.

Most software is custom built rather than being assembled from components

5. Define Software Process.. (K2),CO1

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.

6. List out the fundamental activities of software process (K2),CO1

Communication: This framework activity involves heavy communication and

collaboration with the customer (and other stakeholders’) and encompasses
requirements gathering and other related activities.

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.

Modeling: This activity encompasses the creation of models that allow the
developer and the customer to better understand software requirements and the
de sign that will achieve those requirements.

Construction: This activity combines code generation (either manual or

automated) and the testing that is required to uncover errors in the code.

Deployment: The software (as a complete entity or as a partially completed

increment) is delivered to the customer who evaluates the delivered product and
provides feedback based on the evaluation

104
 PART A- UNIT-1

7. What are the advantages and disadvantages of size measure? (K2),CO1

Advantages:

 Artifact of software development which is easily counted.

 Many existing methods use LOC as a key input.

 A large body of literature and data based on LOC already exists.

Disadvantages:

 This method is dependent upon the programming language.

 This method is well designed but shorter program may get suffered.

 It does not accommodate non procedural languages.

 In early stage of development it is difficult to estimate LOC

8. List deficiencies in waterfall model . (K2).CO2

Disadvantages of a Waterfall Model

If requirements may change the Waterfall model may not work.

Many believe it is impossible to make one stage of the projects life cycle perfect.

Difficult to estimate time and cost for each stage of the development process.

Constant testing of the design is needed.

Blocking states

9. What are the advantages of evolutionary prototyping? (K2),CO2

i. Fast delivery of the working system.

ii. User is involved while developing the system.

iii. More useful system can be delivered.

105
 PART A- UNIT-1

10. What are the drawbacks of RAD model? (K2),CO2

Disadvantages of RAD Model:

(1) For large, but scalable projects, RAD requires sufficient human resources to
create the right number of RAD teams;

(2) 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;

(3) If a system cannot be properly modularized, building the components necessary

for RAD will be problematic;

(4) 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;

(5) RAD may not be appropriate when technical risks are high (e.g., when a new
application makes heavy use of new technology).

11. What are the pros and cons of iterative development model? (K2),CO2

Advantages:

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 (if required) can be added to implement
the next increment. In addition, increments can be planned to manage technical
risks.

Disadvantages

Used when requirements are well understood

Multiple independent deliveries are identified

106
 PART A- UNIT-1

Work flow is in a linear (i.e., sequential) fashion within an increment and is

staggered between increments

Iterative in nature; focuses on an operational product with each increment

Provides a needed set of functionality sooner while delivering optional

components later

Useful also when staffing is too short for a full-scale development

12. What are the challenges in software? (K2),CO1

Copying with legacy systems

Heterogeneity challenge

Delivery times challenge

13. What are the drawbacks of spiral model? (K2),CO2

It is based on customer communication.

If the communication is not proper then the software product that gets
developed will not be the up to the mark.

It demands considerable risk assessment.

If the risk assessment is done properly then only the successful product can be
obtained.

14. Name the Evolutionary process Models. (K2),CO2

 Incremental model

 Spiral model

 WIN-WIN spiral model

 Concurrent Development

107
 PART A- UNIT-1

15. List out the characteristics of OOP.

1. Programs are divided into objects.
2. Data is hidden.
3. Objects communicate with each other, by sending messages
and receiving responses.
4. It follows bottom-up approach.

16. What are the Advantages of Design Patterns?

The List of Advantages,

1. A pattern provides us code reusability, testability
and extensibility.
2. A pattern provides us to enabling large scale
reuse of S/W code.
3. A pattern helps us to improve developer
communication.
4. Patterns capture expert knowledge and design.
It’s make expertise widely available.
5. Pattern allows us to change the design of your
application more readily.
6. Pattern allows us to easily test the seam of an
application.

108
17. What are the main Categories of (GoF) Pattern?

The “design patterns” are divided in to three main

categories and it’s depending on the problem and its
solutions. The categories are,

Creational Patterns – The creational patterns are

ones that create objects for you, rather than having
you instantiate objects directly. This pattern gives us
more flexibility in deciding which objects need to be
created for a given case.
Structural Patterns - These concern class and object
composition. They use inheritance to compose
interfaces and define ways to compose objects to
obtain new functionality.
Behavioural Patterns – The most of these design
patterns are specifically concerned with
communication between objects or classes.

109
 PART B- UNIT 1

1. Explain iterative waterfall and spiral model for software life cycle and various
activities in each phase. (K2), CO2

2.Compare the various Software Development Process Models(K3),CO2

3.Explain in detail about the software process(K2),CO1

4. Explain verification and validation. With suitable example(K2),CO1

6.Explain the process model that combines the elements of waterfall and iterative
fashion(K2), CO2

7.Explain the following: (K2),CO2

a)Waterfall model

b)Spiral model

c)RAD model

8.Explain in detail the various Software Development life cycle processes. (k2),CO2

9. Explain in detail about Agile Methodology (k2),CO2

10. Discuss the Concepts in OOPs. (K2),CO2

11. Explain the various UML Diagrams with Examples(K2)

110
 SUPPORTIVE ONLINE COURSES – UNIT I

https://swayam.gov.in/explorer?searchText=software+engineering

https://www.coursera.org/learn/software-processes

https://www.coursera.org/specializations/software-development-
lifecycle

https://www.coursera.org/learn/software-design-development-
life-cycle

111
 REAL TIME APPLICATION- UNIT I
As per the KPMG Survey, on average, about 70 % of all IT-related projects fail to
meet their objectives, and one of the main reason is the selection of the wrong
software development process/model.

A software house owner explained in an agile conference “We were facing

problems like over commitment and under delivery, unsatisfied customers,
missing deadlines and unhappy team. We switched our development model, and
it all turned out to be ok.”

Just selecting a model that suits your criteria can avoid these problems.

For example, if requirements are all clear and written down, you might have to
choose a different model if requirements are not clear and constant changes are
expected.

Waterfall
Probably the oldest and most straightforward SDLC (software development life
cycle) development model, Waterfall follows a sequential model (like a waterfall)
with requirements analysis, design, coding, testing and implementation in such a
manner that the development does not move to next phase until the previous
phase is completed. That is why it is called the linear sequential software
development life cycle.

Iterative
Repetition is the keyword for the iterative model. Instead of having clear and
known requirements or waiting for them, a team starts development on the
known features, tests and then evaluate further requirements, develops, tests and
so on until the whole thing is done.

Agile
Agile, the most widely used software development methodology is Agile, has
become the industry standard, be it software development, App development or
Game development.

112
 CONTENT BEYOND SYLLABUS – UNIT I

SOFTWARE PROJECT MANAGEMENT

Software project management refers to the branch of project management
dedicated to the planning, scheduling, resource allocation, execution, tracking and
delivery of software and web projects.

Project management in software engineering is distinct from traditional project

management in that software projects have a unique lifecycle process that
requires multiple rounds of testing, updating, and customer feedback. Most IT-
related projects are managed in the agile style, in order to keep up with the
increasing pace of business, and iterate based on customer and stakeholder
feedback.

ProWorkflow

ProWorkflow is a web-based project management software that enables users to

manage tasks and projects, track time, organize contacts, and generate reports for
their business. It is a productivity application that provides a comprehensive set of
features, yet still easy to use for all members of the team. Aside from the great tools
and functionality from the software, customers also enjoy free quality support
through consultations and trainings that help get their businesses up and running.

Jira

Jira is an agile project management software used by development teams to

plan, track, and release software. It is a popular tool designed specifically and used
by agile teams. Aside from creating stories, planning sprints, tracking issues, and
shipping up-to-date software, users also generate reports that help improve teams,
and create their own workflows. As part of Atlassian, it integrates with many tools
that enable teams to manage their projects and products from end to end. Jira
Software is built for every member of your software team to plan,track, and release
great software. Every team has a unique process for shipping software. Use an out-
of-the-box workflow, or create one to match the way your team works.

113
 ASSESSMENT SCHEDULE

Tentative schedule for the Assessment During 2020-

2021 odd semester

Name of the
S.NO Start Date End Date Portion
Assessment

1 UNIT TEST 1 UNIT 1

2 IAT 1 UNIT 1 & 2

3 UNIT TEST 2 UNIT 3

4 IAT 2 UNIT 3 & 4

5 REVISION 1 UNIT 5 , 1 & 2

6 REVISION 2 UNIT 3 & 4

7 MODEL ALL 5 UNITS

114
 PRESCRIBED TEXT BOOKS AND REFERENCE BOOKS

TEXT BOOKS:

1. Bernd Bruegge and Allen H. Dutoit, Object-

Oriented Software Engineering: using UML, Patterns,
and Java.., 2010
2. Erich Gamma, Richard Helm, Ralph Johnson, and
John M. Vlissides, Design Patterns: Elements of
Reusable Object-Oriented Software. First Edition

REFERENCES:

1.Erich Gamma, and Richard Helm, Ralph Johnson,

John Vlissides, ―Design patterns: Elements of
Reusable Object-Oriented Softwareǁ, Addison-
Wesley, 1995.
2.Martin Fowler, ―UML Distilled: A Brief Guide to the
Standard Object Modeling Languageǁ, Third edition,
Addison Wesley, 2000
3.Craig Larman, ―Applying UML and Patterns: An
Introduction to Object- Oriented Analysis and Design
and Iterative Developmentǁ, Third Edition, Pearson
Education, 2005
4.AliBahrami-ObjectOrientedSystemsDevelopment-
McGrawHillInternationalEdition - 1999

115
Mini Project Suggestion
To develop a mini-project by using the following Use Cases listed
below:

Use Case 1
POS (Point of Sale) Terminal
Features to be handled:-
1. Order Entry,
2. Item Management and Categorization,
3. Tax Calculation,
4. Payment Mode, Payment Status, User Management

Use Case 2
Hotel Room Management
Features to be handled:-
1. Rooms type and Category
2. Check in and Check Out
3. Room occupation Status
4. Room Service Request
5. Guests Management and allocation Room 6. Billing Calculation,
User management

Use Case 3
Banking Portal
1. Funds Transfer within Same Bank, Intra Bank

2. Forex Conversion

3. Bene Management
4. Customer and Accounts Management 5. Funds Transfer Transaction
Status

116
Use Case 4
Mobile Phone Service Center
1. Mobile Phone Parts Management
2. Mobile Phone Models
3. Service Request Registration
4. Service Request Status Check
5. Service Request Engineer Allocation 6. Payment
7. Customer Management

117
 MINI PROJECT SUGGESTIONS

1.Student Mark Analysis System

Problem Statement:

Computerized Student Mark Analysis System analysis the marks obtained

by the students and generate various reports of an Institution.

It needs to maintain the record of all the students and staff of an Institution.

It should be able to perform basic operations such as:

Add New Student and Staff details

Update Student and Staff Details

Delete Student and Staff Details.

View Results

Generate Reports:

Branch-wise Student Report

Grade-wise Student Report

Subject-wise Student Report

Year-wise Student Report

118
MINI PROJECT SUGGESTIONS

2. Quiz System

Problem Statement:

Online Quiz System allows different categories of candidates to attend

online test on various domains according to their required skill set.

It needs to maintain the record of all the participants by System Administrator.

It should be able to perform basic operations such as:

Registration/SignIn

Update Participant Details.

Delete Participant Details.

Add domain questions for various levels (Easy/Moderate/Difficult)

Attend Quiz & Display Score.

Generate Participant Report.

119
 MINI PROJECT SUGGESTIONS

3.Ticket Reservation System

Problem Statement:

Online Ticket Reservation System allows the user to book/cancel the

tickets online from their place where the internet connectivity is feasible without
standing in the queue for a long time.

It needs to maintain the record of all the train details, station details and
passenger details of a particular train.

It should be able to perform basic operations such as:

Registration/SignIn

Add/Update/Delete Train Details

Check Availability of seats

Book Tickets

Cancel Tickets

Payment

120
 MINI PROJECT SUGGESTIONS

4.Expert System

Problem Statement:

Expert System is used to identify an ailment by its symptoms and

prescribes an appropriate medicine corresponding to the disease. It is well known
that developing countries are facing lots of shortage of medical expertise.

It needs to maintain the record of all the symptoms and its prescribed medicines.

It should be able to perform basic operations such as:

Registration/SignIn

Add/Update/Delete Symptom Details

Querying about Symptoms

121
 MINI PROJECT SUGGESTIONS

5.Course Registration System

Problem Statement:

Computerize Online Course Registration System and register students for

various courses based on the availability of seats and course instructor and generate
various reports.

It needs to maintain the record of all the courses, seats available, course
instructors and duration.

It should be able to perform basic operations such as:

Add new Courses and Course Instructors details

Update Courses and Course Instructors details

Delete Courses and Course Instructors details

View Registration status

Generate Reports:

Course-wise Registration Report

Courses Availability Report

Course Instructor Availability Report

Year-wise Registration Report

Courses and Course Instructors Report

122
 MINI PROJECT SUGGESTIONS

6.Platform assignment System for the Trains in a Railway

Station

Problem Statement:

Computerize Platform assignment for the trains arriving to the railway

station and generate various reports.

It needs to maintain the record of Number of platforms, Number of trains arriving

and leaving the station and time details.

It should be able to perform basic operations such as:

Add new platform and train details

Update platform and train details

Delete platform and train details

View platform status

Generate Reports:

Trains arriving and leaving the station Report

Platform assignment details Report on a particular date and between dates

Platform available status Report for any instant

123
 Thank you

Disclaimer:

This document is confidential and intended solely for the educational purpose of
RMK Group of Educational Institutions. If you have received this document through
email in error, please notify the system manager. This document contains proprietary
information and is intended only to the respective group / learning community as
intended. If you are not the addressee you should not disseminate, distribute or
copy through e-mail. Please notify the sender immediately by e-mail if you have
received this document by mistake and delete this document from your system. If
you are not the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this information is
strictly prohibited.

124