Software Engineering requirements & Development of Analysis &

Design models.

SL NAME OF THE TOPICS PAGE NUMBER

NO.
Software Engineering core principles,
1 Communication, Planning, Modeling, Construction & 3-5
Deployment principles.
Requirements Engineering Tasks, Initiating the
2 requirement process. 5

Analysis approaches of software & preparation of

3 Analysis model using Data modeling, Concepts, 5-9
Objectoriented Analysis, Flow oriented model, Class-
Based model, Behavioral Model.
Design approaches of software & preparation of
4 design model using Design concepts, Design model, 10-14
and pattern based design.
1.
1.1 Software Engineering core principles:
There are Seven basic principles of software engineering.They are:

1.Manage using a phased life-cycle plan.

2.Perform continuous validation.
3.Maintain disciplined product control.
4.Use modern programming practices.
5.Maintain clear accountability for results.
6.Use better and fewer people.
7.Maintain a commitment to improve the process.

1.2 Communication in Software Engineering:

Great communication is the most important characteristic for success as a software engineer. It turns out
software engineers, like other knowledge-workers, spend a ton of time collaborating across IM, email, reading
designs, reviewing code and going to meetings. Our job often involves working across many parts of the
company communicating with product management, account management, support, operations, sales,
customers and of course with our peers and managers. As their career develops, software engineers end up
spending most of their time communicating rather than actually coding. Ask any engineering manager, VP or
CTO and most will tell you that their job is mostly about communication. Of course, managers need to
communicate well but this is also true for individual contributors (IC). All of the senior IC engineers (Staff,
Principal, Fellows, etc) I’ve ever met spend a ton of time communicating.

1.3 Project Planning in Software Engineering:

Before starting a software project, it is essential to determine the tasks to be performed and properly manage
allocation of tasks among individuals involved in the software development. Hence, planning is important as it
results in effective software development
Estimating the subsequent attributes of the project:
 Project size:
What’s going to be downside quality in terms of the trouble and time needed to develop the product?
 Cost:
What proportion is it reaching to value to develop the project?
 Duration:
However long is it reaching to want complete development?
 Effort:
What proportion effort would be required?
The effectiveness of the following designing activities relies on the accuracy of those estimations.
 planning force and alternative resources
 workers organization and staffing plans
 Risk identification, analysis, and abatement designing
 Miscellaneous arranges like quality assurance plan, configuration, management arrange, etc.
1.4 Software Modeling:
The software modeling community is primarily concerned with reducing the gap between
problem and software implementation through the use of models that describe complex systems at
multiple levels of abstraction and from a variety of perspectives. A model is an abstraction of some
aspect of an existing or planned system. Models are created to serve particular purposes, for
example, to present a human-understandable description of some aspect of a system or to present
information in a form that can be mechanically analyzed.

1.5 Software Construction:

Software construction is a software engineering discipline. It is the detailed creation of working
meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging. It
is linked to all the other software engineering disciplines, most strongly to software design and software testing.

Software construction fundamentals

Software construction fundamentals include

 minimizing complexity
 anticipating change
 constructing for verification
 reuse
 standards in construction.
The first four concepts apply to design as well as to construction. The following sections define these concepts and
describe how they apply to construction.

1.6 Deployment principles in Software Engineering:

Software deployment is all of the activities that make a software system available for use. The general deployment
process consists of several interrelated activities with possible transitions between them. These activities can occur
at the producer side or at the consumer side or both. Because every software system is unique, the
precise processes or procedures within each activity can hardly be defined. Therefore, "deployment" should be
interpreted as a general process that has to be customized according to specific requirements or characteristics.[2
Deployment Principles:

 Release
 Installation and activation
 Deactivation
 Uninstallation
 Update
 Built-in update
 Version tracking

2.
2.1 Requirements Engineering Tasks:
Requirement engineering consists of seven different tasks as follow:

i)Inception
Inception is a task where the requirement engineering asks a set of questions to establish a software
process.
ii)Elicitation
Elicitation means to find the requirements from anybody.
iii)Elaboration
In this task, the information taken from user during inception and elaboration and are expanded and
refined in elaboration.
iv)Negotiation
In negotiation task, a software engineer decides the how will the project be achieved with limited
business resources.
v)Specification
In this task, the requirement engineer constructs a final work product.
vi)Validation
The work product is built as an output of the requirement engineering and that is accessed for the
quality through a validation step.
vii)Requirement management
It is a set of activities that help the project team to identify, control and track the requirements and
changes can be made to the requirements at any time of the ongoing project.

2.2 Initiating the requirement process in Software Engineering:

Requirement Engineering is the process of defining, documenting and maintaining the requirements. It
is a process of gathering and defining service provided by the system. Requirements Engineering Process
consists of the following main activities:
 Requirements elicitation
 Requirements specification
 Requirements verification and validation
 Requirements management
3.
3.1 Analysis approaches of software & preparation of Analysis model using Data modeling:
Analysis Model is a technical representation of the system. It acts as a link between system description and
design model. In Analysis Modelling, information, behavior and functions of the system is defined and
translated into the architecture, component and interface level design in the design modeling.
Objectives of Analysis Modelling:
 1. It must establish a way of creation of software design.
2. It must describe requirements of customer.
3. It must define set of requirements which can be validated, once the software is built.
Elements of Analysis Model:

 Data Dictionary: It is a repository that consists of description of all data objects used or
produced by software. ...
 Entity Relationship Diagram (ERD): ...
 Data Flow Diagram (DFD): ...
 State Transition Diagram: ...
 Process Specification: ...
 Control Specification: ...
 Data Object Description:

Analysis Rules of Thumb

The rules of thumb that must be followed while creating the analysis model.

The rules are as follows:

 The model focuses on the requirements in the business domain. The level of abstraction must be high i.e
there is no need to give details.
 Every element in the model helps in understanding the software requirement and focus on the information,
function and behaviour of the system.
 The consideration of infrastructure and nonfunctional model delayed in the design.
For example, the database is required for a system, but the classes, functions and behavior of the database
are not initially required. If these are initially considered then there is a delay in the designing.
 Throughout the system minimum coupling is required. The interconnections between the modules is known
as 'coupling'.
 The analysis model gives value to all the people related to model.
 The model should be simple as possible. Because simple model always helps in easy understanding

3.2 Concepts of data modeling:

 Analysis modeling starts with the data modeling.

 The software engineer defines all the data object that proceeds within the system and the
relationship between data objects are identified.

3.3 Object Oriented Analysis:

Object Oriented Analysis (OOA) is process of discovery where a development team understands and models
the requirements of the system. In OOA requirements are organized as objects. It integrates all the process and
data. But in others or traditional structural analysis both process and data are considered independently/separately.
They use flow chart/structure charts for process and ER diagrams for data. It is based in a set of basic principles,
which are as follows-
1. The information domain is modeled.
2. Behavior is represented.
3. Function is described.
4. Data, functional, and behavioral models are divided to uncover greater detail.
 5. Early models represent the essence of the problem, while later ones provide implementation
details.

Functionalities of OOA:
The core activities in OOA are given bellow:
o Find the objects
o Organize the objects by creating object model diagram
o Explain how the objects communicates with each others
o Set the characteristic or behavior of the objects
o Set the internal of the objects

Advantages/Disadvantages of Object Oriented Analysis:

Advantages Disadvantages

Focuses on data rather than the procedures as Functionality is restricted within objects. This
in Structured Analysis. may pose a problem for systems which are
intrinsically procedural or computational in
nature.

The principles of encapsulation and data hiding It cannot identify which objects would generate
help the developer to develop systems that an optimal system design.
cannot be tampered by other parts of the
system.

The principles of encapsulation and data hiding The object-oriented models do not easily show
help the developer to develop systems that the communications between the objects in the
cannot be tampered by other parts of the system.
system.

It allows effective management of software All the interfaces between the objects cannot be
complexity by the virtue of modularity. represented in a single diagram.

It can be upgraded from small to large systems

at a greater ease than in systems following
structured analysis.

3.4 Flow oriented model:

The flow oriented modeling represents how data objects are transformed at they move through the
system. Derived from structured analysis, flow models use the data flow diagram, a modeling notation that
depicts how input is transformed into output as data objects move through the system. Each software function
that transforms data is described by a process specification or narrative. In addition to data flow, this modeling
element also depicts control flow.
Data Flow Diagram :
The data flow diagram represents the flows of data between different process in a business. It is a graphical technique
that depicts information flow and transforms that are applied as data from input to output. It provides a simple, intuitive
method for describing business processes without focusing on the details of computer systems. DFDs are attractive
techniques because they provide what users do rather than what computers do. In DFD, there are four symbols are used
:

1. Process :

The circle represents the process. An activity that changes or transforms data flows. Since they transform incoming data
to outgoing data, all processes must have inputs and outputs on a DFD.

2. Data Flow :

The labeled arrows indicate incoming and outgoing data flow. Movement of data between external entities, processes
and data stores is represented with an arrow symbol, which indicates the direction of flow.

3. Data Store :

The rectangle represents an external entity. A data store does not generate any operations but simply holds data for
later access.

4. External Entity :

In Data Flow Diagrams external entities produce and consume data that flows between the entity and the
system being diagrammed.

3.5 Class-Based model:

Class-based modeling is a stage of requirements modeling. In the context of software
engineering, requirements modeling examines the requirements a proposed software application or
system must meet in order to be successful. Typically, requirements modeling begins with scenario-
based modeling, which develops a use case that will help with the next stages, like data and class-based
modeling. Class-based modeling takes the use case and extracts from it the classes, attributes, and
operations the application will use. Like all modeling stages, the end result of class-based modeling is
most often a diagram or series of diagrams, most frequently created using UML, Unified Modeling
Language.
 Class based modeling represents the object. The system manipulates the operations.
The elements of the class based model consist of classes and object, attributes, operations, class – responsibility -
collaborator (CRS) models.
Classes
Classes are determined using underlining each noun or noun clause and enter it into the simple table.

Classes are found in following forms:

 External entities: The system, people or the device generates the information that is used by the computer
based system.
 Things: The reports, displays, letter, signal are the part of the information domain or the problem.
 Occurrences or events: A property transfer or the completion of a series or robot movements occurs in the
context of the system operation.
 Roles: The people like manager, engineer, salesperson are interacting with the system.
 Organizational units: The division, group, team are suitable for an application.
 Places: The manufacturing floor or loading dock from the context of the problem and the overall function of the
system.
 Structures: The sensors, computers are defined a class of objects or related classes of objects.
 Attributes
Attributes are the set of data objects that are defining a complete class within the context of the problem.
For example, 'employee' is a class and it consists of name, Id, department, designation and salary of the employee are
the attributes.
 Operations
The operations define the behavior of an object.

3.6 Behavioral Model:

Behavioral models describe the internal dynamic aspects of an information system that
supports the business processes in an organization. During analysis, behavioral models describe
what the internal logic of the processes is without specifying how the processes are to be
implemented. Later, in the design and implementation phases, the detailed design of the operations
contained in the object is fully specified. In this chapter, we describe three Unified Modeling
Language (UML) diagrams that are used in behavioral modeling (sequence diagrams, communication
diagrams, and behavioral state machines) and CRUDE (create, read, update, delete, execute)
matrices.

OBJECTIVES

 Understand the rules and style guidelines for sequence and communication diagrams and behavioral
state machines
 Understand the processes used to create sequence and communication diagrams, behavioral state
machines, and CRUDE matrices
 Be able to create sequence and communication diagrams, behavioral state machines, and CRUDE
matrices
 Understand the relationship between the behavioral models and the structural and functional models
4.
4.1 Design approaches of software & preparation of design model using Design
concepts:

Software Design is the process to transform the user requirements into some suitable form, which
helps the programmer in software coding and implementation. During the software design phase, the
design document is produced, based on the customer requirements as documented in the SRS
document. Hence the aim of this phase is to transform the SRS document into the design document.
The following items are designed and documented during the design phase:
 Different modules required.
 Control relationships among modules.
 Interface among different modules.
 Data structure among the different modules.
 Algorithms required to implement among the individual modules.
Objectives of Software Design:
1. Correctness:
A good design should be correct i.e. it should correctly implement all the functionalities of the system.
2. Efficiency:
A good software design should address the resources, time and cost optimization issues.
3. Understandability:
A good design should be easily understandable, for which it should be modular and all the modules are
arranged in layers.
4. Completeness:
The design should have all the components like data structures, modules, and external interfaces, etc.
5. Maintainability:
A good software design should be easily amenable to change whenever a change request is made from
the customer side.
Software Design Concepts:
Concepts are defined as a principal idea or invention that comes in our mind or in thought to
understand something. The software design concept simply means the idea or principle behind the
design. It describes how you plan to solve the problem of designing software, the logic, or thinking
behind how you will design software. It allows the software engineer to create the model of the
system or software or product that is to be developed or built. The software design concept provides
a supporting and essential structure or model for developing the right software. There are many
concepts of software design and some of them are given below:

Following points should be considered while designing a Software:

 1. Abstraction- hide relevant data
Abstraction simply means to hide the details to reduce complexity and increases efficiency or quality.
Different levels of Abstraction are necessary and must be applied at each stage of the design process so
that any error that is present can be removed to increase the efficiency of the software solution and to
refine the software solution. The solution should be described in broadways that cover a wide range of
different things at a higher level of abstraction and a more detailed description of a solution of software
should be given at the lower level of abstraction.
2. Modularity- subdivide the system
Modularity simply means to divide the system or project into smaller parts to reduce the complexity of the
system or project. In the same way, modularity in design means to subdivide a system into smaller parts
so that these parts can be created independently and then use these parts in different systems to
perform different functions. It is necessary to divide the software into components known as modules
because nowadays there are different software available like Monolithic software that is hard to grasp for
software engineers. So, modularity is design has now become a trend and is also important.
3. Architecture- design a structure of something
Architecture simply means a technique to design a structure of something. Architecture in designing
software is a concept that focuses on various elements and the data of the structure. These components
interact with each other and use the data of the structure in architecture.
4. Refinement- removes impurities
Refinement simply means to refine something to remove any impurities if present and increase the
quality. The refinement concept of software design is actually a process of developing or presenting the
software or system in a detailed manner that means to elaborate a system or software. Refinement is
very necessary to find out any error if present and then to reduce it.
5. Pattern- a repeated form
The pattern simply means a repeated form or design in which the same shape is repeated several times
to form a pattern. The pattern in the design process means the repetition of a solution to a common
recurring problem within a certain context.
6. Information Hiding- hide the information
Information hiding simply means to hide the information so that it cannot be accessed by an unwanted
party. In software design, information hiding is achieved by designing the modules in a manner that the
information gathered or contained in one module is hidden and it cant be accessed by any other
modules.
7. Refactoring- reconstruct something
Refactoring simply means to reconstruct something in such a way that it does not affect the behavior or
any other features. Refactoring in software design means to reconstruct the design to reduce and
complexity and simplify it without affecting the behavior or its functions. Fowler has defined refactoring as
“the process of changing a software system in a way that it won’t affect the behavior of the design and
improves the internal structure”.
Different levels of Software Design:
There are three different levels of software design. They are:
1. Architectural Design:
The architecture of a system can be viewed as the overall structure of the system & the way in which
structure provides conceptual integrity of the system. The architectural design identifies the software as a
system with many components interacting with each other. At this level, the designers get the idea of the
proposed solution domain.
2. Preliminary or high-level design:
Here the problem is decomposed into a set of modules, the control relationship among various modules
identified and also the interfaces among various modules are identified. The outcome of this stage is
called the program architecture. Design representation techniques used in this stage are structure chart
and UML.
3. Detailed design:
Once the high level design is complete, detailed design is undertaken. In detailed design, each module is
examined carefully to design the data structure and algorithms. The stage outcome is documented in the
form of a module specification document.
 4.2 Design model:

A design model in Software Engineering is an object-based picture or pictures that represent the
use cases for a system. Or to put it another way, it is the means to describe a system's implementation
and source code in a diagrammatic fashion. This type of representation has a couple of advantages. First,
it is a simpler representation than words alone. Second, a group of people can look at these simple
diagrams and quickly get the general idea behind a system. In the end, it boils down to the old adage, 'a
picture is worth a thousand words.'

Following are the types of design elements:

1. Data design elements

 The data design element produced a model of data that represent a high level of abstraction.
 This model is then more refined into more implementation specific representation which is
processed by the computer based system.
 The structure of data is the most important part of the software design.
2. Architectural design elements
 The architecture design elements provides us overall view of the system.
 The architectural design element is generally represented as a set of interconnected subsystem
that are derived from analysis packages in the requirement model.
The architecture model is derived from following sources:
 The information about the application domain to built the software.
 Requirement model elements like data flow diagram or analysis classes, relationship and
collaboration between them.
 The architectural style and pattern as per availability.
3. Interface design elements
 The interface design elements for software represents the information flow within it and out of
the system.
 They communicate between the components defined as part of architecture.
Following are the important elements of the interface design:
1. The user interface
2. The external interface to the other systems, networks etc.
3. The internal interface between various components.

4. Component level diagram elements

 The component level design for software is similar to the set of detailed specification of each
room in a house.
 The component level design for the software completely describes the internal details of the
each software component.
 The processing of data structure occurs in a component and an interface which allows all the
component operations.
 In a context of object-oriented software engineering, a component shown in a UML diagram.
 The UML diagram is used to represent the processing logic.

5. Deployment level design elements

 The deployment level design element shows the software functionality and subsystem that
allocated in the physical computing environment which support the software.
 Following figure shows three computing environment as shown. These are the personal
computer, the CPI server and the Control panel.

4.3 Pattern based design:

In software engineering, a design pattern is a general repeatable solution to a commonly occurring
problem in software design. A design pattern isn't a finished design that can be transformed directly into code.
It is a description or template for how to solve a problem that can be used in many different situations.

Usage of Design Pattern

Design Patterns have two main usages in software development.
Common platform for developers
Design patterns provide a standard terminology and are specific to particular scenario. For example,
a singleton design pattern signifies use of single object so all developers familiar with single design
pattern will make use of single object and they can tell each other that program is following a
singleton pattern.
Best Practices
Design patterns have been evolved over a long period of time and they provide best solutions to
certain problems faced during software development. Learning these patterns helps unexperienced
developers to learn software design in an easy and faster way.
Types of Design Patterns
As per the design pattern reference book Design Patterns - Elements of Reusable Object-Oriented
Software , there are 23 design patterns which can be classified in three categories: Creational, Structural and
Behavioral patterns. We'll also discuss another category of design pattern: J2EE design patterns.
S.N. Pattern & Description
1 Creational Patterns
These design patterns provide a way to create objects while hiding the creation logic, rather
than instantiating objects directly using new operator. This gives program more flexibility in
deciding which objects need to be created for a given use case.

2 Structural Patterns
These design patterns concern class and object composition. Concept of inheritance is used
to compose interfaces and define ways to compose objects to obtain new functionalities.

3 Behavioral Patterns
These design patterns are specifically concerned with communication between objects.

4 J2EE Patterns
These design patterns are specifically concerned with the presentation tier. These patterns
are identified by Sun Java Center.