SOFTWARE ENGINEERING

(CSE 2014)
Presidency School of Computer Science and
Engineering
 Assessment Schedule
Course Outcome Duration In
S. No Assessment type Contents Marks Weightage DATE
Number Hours

10.09.24 -
1 Surprise Test - 1 Module 1 CO1 30 Mins 10 5%
14.09.24
22.10.24 -
2 Assignment - 1 Module 2 CO2 1 week 10 5%
26.10.24
15.10.24 -
3 Mid Term Module 1 & 2 CO1 & CO2 90 Mins 50 25%
21.10.24
11.11.24 -
4 Surprise Test - 2 Module 3 CO3 30 Mins 10 5%
15.11.24
09.12.24 -
5 Assignment - 2 Module 4 CO4 1 week 10 5%
14.12.24
16.12.24 -
6 Presentation Module 3 & 4 CO3 & CO4 30 Mins 10 5%
20.12.24
CO1, CO2, 05.01.25 -
7 End Term Module – 1 to 4 180 Mins 100 50%
CO3,CO4 15.01.25
 Module - 2
Software Requirements, Analysis and Design

Requirements Engineering: Eliciting requirements, Functional and non- Functional requirements,

Software Requirements Specification (SRS), Requirement Analysis and validation. Requirements
modelling- Introduction to Use Cases, Activity diagram and Swim Lane diagram. CASE-
Characteristics of CASE Tools, Architecture of a CASE Environment.
Design: Design concepts, Architectural design, Component based design, User interface design.
CO2: Identify the requirements, analysis and appropriate
design models for a given application
L12: Requirement Engineering: Eliciting Requirements

LO: Define Requirement Engineering

CONTENTS

Requirements Engineering:
1. Eliciting requirements
2. Functional and non- Functional requirements
3. Software Requirements Specification (SRS)
4. Requirement Analysis and validation.
Requirements Engineering
• Requirement is a capability or condition required from the system.

• Requirements engineering is the process of gathering, analyzing,

documenting, validating, and managing requirements.

• The main goal: clearly understand the customer requirements and

systematically organize these requirements in the SRS.

• Software Requirements specification (SRS) document.

 Requirements Engineering
It encompasses seven distinct tasks:
• Inception - The project's scope, goals, and requirements are identified and
defined.
• Elicitation - The process of gathering and discovering requirements from
stakeholders, users, and other sources.
• Elaboration - The process of refining, detailing, and expanding on the
initially gathered requirements to create a comprehensive and precise
specification.
• Negotiation - The process of resolving conflicts and reaching agreements
among stakeholders regarding the requirements of a system.
 Requirements Engineering
• Specification – It is a detailed, precise description of the system's
requirements, capturing the intended functions, behaviors, and constraints
of the system being developed.
• Validation - The process of ensuring that the documented requirements
accurately reflect the needs and expectations of the stakeholders.
• Management - The processes, practices, and tools used to oversee and
control the activities related to gathering, documenting, analyzing,
prioritizing, and maintaining requirements.
 Eliciting Requirements
• Also called Requirements gathering.
• It combines elements of problem solving, elaboration, negotiation and
specification.
• Collaborative team oriented approach
• Stakeholders work together to identify the problem,
• propose elements of the solution,
• negotiate different approaches and
• specify a preliminary set of solution requirements.
Eliciting Requirements
Collaborative Requirements Gathering:
Different approaches:
• Meeting are conducted and Attended by both Software Engineers and other
Stakeholders.

• Rules for preparation and participation are established.

• An agenda is Suggested
• Formal enough – to cover all important points
• Informal Enough – To encourage the free flow of ideas.
 Eliciting Requirements
Collaborative Requirements Gathering:
Different approaches:
• A facilitator (customer, developer or outsider) controls the meeting.

• A definition mechanism (worksheets, flipcharts, or wall stickers or an

electronic bulletin board, chat room or virtual forum ) is used.
L13: Functional and Non Functional Requirements

LO: Describe the types of requirements

Types of Requirements
1. Functional Requirements:
• Specify the functions and behaviors the software must perform.

• Examples: User login, data retrieval, transaction processing.

• A functional requirement can express a if/then relationship

• Examples: If an alarm is received from a sensor, the system will report

the alarm and halt until the alarm is acknowledged and cleared.
Types of Requirements
2. Non Functional Requirements:
• The quality constraints that the system must satisfy according to the
project contract.

• The priority or extent to which these factors are implemented varies from
one project to other.

• They are also called non-behavioral requirements.

Types of Requirements
2. Non Functional Requirements:
• A system can meet its functional requirements and fail to meet its
nonfunctional requirements.
• Define the software's characteristics and expected user experience (UX).
• Sub Categories:
• Performance
• Usability
• Scalability
• Security
• Portability
Types of Requirements
2. Non Functional Requirements:

• Ex: The pages of this web portal must load within 0.5 seconds.
 FUNCTIONAL REQUIREMENTS NON FUNCTIONAL REQUIREMENTS
A non-functional requirement defines the quality attribute of a
1. A functional requirement defines a system or its component.
software system.

It places constraints on “How should the software system fulfill

2. It specifies “What should the software system do?”
the functional requirements?”

Non-functional requirement is specified by technical peoples e.g.

3. Functional requirement is specified by User.
Architect, Technical leaders and software developers.

4. It is mandatory. It is not mandatory.

5. It is captured in use case. It is captured as a quality attribute.
6. Defined at a component level. Applied to a system as a whole.

7. Helps you verify the functionality of the software. Helps you to verify the performance of the software.

8. Functional Testing like System, Integration, End to End, API Non-Functional Testing like Performance, Stress, Usability,
testing, etc are done. Security testing, etc are done.

9. Usually easy to define. Usually more difficult to define.

L14: Software Requirements Specification (SRS)

LO: Illustrate SRS with examples

SRS-Software Requirement Specification
• Formal document that provides the complete description of the proposed
software.

• i.e., what the software will do without describing how it will do so..

• It is an important document required in software development.

Need for SRS
• Customers and users rely more on and better understand a written formal
document than some technical specification.

• It provides basis for later stages of software development, viz., design, coding,
testing, standard compliances, delivery, and maintenance.

• It acts as the reference document for the validation and verification of the
work products and final software.
Need for SRS:

• It is treated as an agreement on the features incorporated in the final system

of project between customer and the supplier.
• A good quality SRS ensures high quality software product.
• A high quality SRS reduces development effort (schedule, cost, and
resources).
Characteristics of good SRS:
• Correctness: A SRS is said to be correct if it covers all the requirements that
are actually expected from the system.
• Unambiguity: A SRS is said to be unambiguous if all the requirements
stated have only 1 interpretation.
• Completeness: A complete SRS should cover every aspect of the system,
leaving no gaps or ambiguities that could lead to misunderstandings,
incomplete implementations, or missed functionalities.
• Consistency: Requirements in SRS are said to be consistent if there are no
conflicts between any set of requirements.
Characteristics of good SRS:

• Stability: Refers to the extent to which the requirements remain consistent

and unchanged throughout the software development lifecycle.

• Verifiability : A SRS is verifiable if there exists a specific technique to

quantifiably measure the extent to which every requirement is met by the
system.

• Modifiability: A SRS should be made as modifiable as possible and should

be capable of easily accepting changes to the system to some extent.
Characteristics of good SRS:

• Testability : A SRS should be written in such a way that it is easy to

generate test cases and test plans from the document.

• Traceability: One should be able to trace a requirement to design

component and then to code segment in the program.
SRS Format:
1. Introduction
• Purpose of this document
• Scope of this document
• Overview

2. General description

3. Functional Requirements

4. Interface Requirements

Dept. of CSE, SOE, Presidency University

26
SRS Format:
5. Performance Requirements

6. Design Constraints

7. Non-Functional Attributes

8. Preliminary Schedule and Budget

9. Appendices

Dept. of CSE, SOE, Presidency University

27
SRS - Introduction
• Purpose of this document:
- Main aim is to describe the purpose and necessity of the document
• Scope of this document:
- To describe the overall working, main objective of document and also a
development cost and time.
• Overview:
- It’s simply summary or overall review of product.

Dept. of CSE, SOE, Presidency University

28
SRS – General Description
• Describe the general functions of product

• Includes
• Product Perspective
• User Classes and Characteristics
• Operating Environment
• Design and Implementation Constraints
• Assumptions and Dependencies

Dept. of CSE, SOE, Presidency University

29
SRS – Functional Requirements

• Describing the possible outcome of software system which includes effects

due to operation of program.

• All functional requirements which may include calculations, data

processing, etc. are placed in a ranked order.

Dept. of CSE, SOE, Presidency University

30
SRS – Interface Requirements

• Describing how software program communicates with each other or users

either in form of any language, code, or message.

• Ex: Memory, Data Streams etc.

Dept. of CSE, SOE, Presidency University

31
SRS – Performance Requirements

• How a software system performs desired functions under specific

condition is explained.

• It also explains required time, required memory, maximum error rate, etc.

Dept. of CSE, SOE, Presidency University

32
SRS – Design Constraints

• Constraints which simply means limitation or restriction are specified and

explained for design team.

• Ex: use of a particular algorithm, hardware and software limitations, etc.

Dept. of CSE, SOE, Presidency University

33
SRS : Non-Functional Attributes

• Attributes that are required by software system for better performance.

• Example: Security, Portability, Reliability, Reusability, Application

compatibility, Data integrity, Scalability capacity, etc.

Dept. of CSE, SOE, Presidency University

34
SRS – Preliminary Schedule and Budget

• Initial version and budget of project plan are explained.

• Includes overall time duration required and overall cost required for
development of project

Dept. of CSE, SOE, Presidency University

35
 SRS : Appendices

• Additional information like references from where information is gathered,

definitions of some specific terms, acronyms, abbreviations, etc. are given
and explained.

Dept. of CSE, SOE, Presidency University

36
 SRS : Example

..\..\..\..\..\Users\jose2\Downloads\ReqView-Example_Software_Requirements
_Specification_SRS_Document (1).pdf
(sample SRS document)

Dept. of CSE, SOE, Presidency University

37
Case Study: Create an SRS document for Hospital
Management System/Online Bookstore System
L15: Requirement Analysis and Validation

LO: Describe the process of requirements validation

Requirements Analysis and Validation
• Many projects fail:
• Because they start implementing the system without determining whether
they are building what the customer really wants.
• It is important to learn:
• Requirements analysis and specification techniques carefully.
Requirements Analysis and Validation

• Goals:
• Fully understand the user requirements.
• Remove inconsistencies, anomalies, etc. from requirements.
• Document requirements properly in an SRS document.
Requirements Analysis
Consists of two distinct activities:
• Requirements Gathering and Analysis
• Specification
• Who involved in RAS?
• System Analyst
• Collects data pertaining to the product.
• Analyzes collected data:
• To understand what exactly needs to be done.
• Writes the Software Requirements Specification (SRS)
document.
Requirements Analysis

• Final output of this phase:

Software Requirements Specification (SRS) Document.
• The SRS document is reviewed by the customer.
Reviewed SRS document forms the basis of all future development
activities.
Requirements Analysis

• Analyst gathers requirements through:

• Observation of existing systems,
• Studying existing procedures,
• Discussion with the customer and end-users,
• Analysis of what needs to be done, etc.
Requirements Analysis
Requirements Gathering:
• Also known as Requirements Elicitation.

• If the project is to automate some existing procedures

• Analyst can immediately obtain:

• Input and output formats

• Accurate details of the operational procedures
Requirements Analysis
Requirements Gathering :
• In the absence of a working system,
• Lot of imagination and creativity are required.
• Interacting with the customer to gather relevant data:
• Requires a lot of experience.
• Some desirable attributes of a good system analyst:
• Good interaction skills,
• Imagination and creativity,
• Experience.
Requirements Analysis
Requirements Gathering Activities:
1. the existing documentation
2. Interview
3. Task analysis
4. Scenario analysis
5. Form analysis
 Requirements Validation
• The process of checking that requirements defined for development and define
the system that the customer really wants.

• To check issues related to requirements, we perform requirements validation.

• Is each requirement consistent with the overall objective for the

system/product?

• Have all requirements been specified at the proper level of abstraction? That is,
do some requirements provide a level of technical detail that is inappropriate at
this stage?

Dept. of CSE, SOE, Presidency University

48
 Requirements Validation
• Is
the requirement really necessary or does it represent an add-on feature that
may not be essential to the objective of the system?

• Is each requirement bounded and unambiguous?

• Does each requirement have attribution? That is, is a source (generally, a

specific individual) noted for each requirement?

• Do any requirements conflict with other requirements?

Dept. of CSE, SOE, Presidency University

49
 Requirements Validation
• Is
each requirement achievable in the technical environment that will house
the system or product?

• Is each requirement testable, once implemented?

• Doesthe requirements model properly reflect the information, function and

behavior of the system to be built.

Dept. of CSE, SOE, Presidency University

50
 Requirements Validation
• Hasthe requirements model been “partitioned” in a way that exposes
progressively more detailed information about the system.

• Have requirements patterns been used to simplify the requirements model.

Have all patterns been properly validated? Are all patterns consistent with
customer requirements?

Dept. of CSE, SOE, Presidency University

51
L16: Requirements Modelling- Introduction to Use Cases

LO: Illustrate the functional requirements with the help of use

case diagrams
 Requirements Modelling
• Uses a combination of diagrams and text to depict requirements in a way that
is easier to understand.
• Through modelling we can examine the system from various perspectives.
• Use case Diagram:
• It is a behavior diagram show the dynamic behavior of the objects in a
system, which can be described as a series of changes to the system
over time.
• Describes a system's functional requirements in terms of use cases.
• It is a model of the system's intended functionality (use cases) and its
environment (actors).

Dept. of CSE, SOE, Presidency University

53
 Requirements Modelling
• Use Case Diagram
• UML: Unified Modelling Language
• Standard Modelling Language
• consisting of an integrated set of diagrams
• Developed to help system and software developers
• For specifying, visualizing, constructing, and documenting the artifacts of
software systems, as well as for business modeling and other non-software
systems.
• A proper use case diagram depicts a high-level overview of the relationship
between use cases, actors, and systems.

Dept. of CSE, SOE, Presidency University

54
 Requirements Modelling
• Use case diagram components
• System :

• Actor
Actors are basically users of the SUD who are external entities (people or other
systems) who interact with the SUD to achieve a desired goal. Actors are represented as
stick figures.
• Types of Actors:
• Primary Actor
The Actor(s) using the system to achieve a goal.
• Secondary Actor
Actors that the system needs assistance from to achieve the primary actors goal.

Dept. of CSE, SOE, Presidency University

55
 Requirements Modelling
• Use case diagram components
• Use Case
• A use case is a collection of possible sequences of interactions between the
SUD and its Actors, relating to a particular goal.
• The collection of Use Cases should define all system behavior relevant to
the actors to assure them that their goals will be carried out properly.
• A use case is drawn as a horizontal ellipse.

Dept. of CSE, SOE, Presidency University

56
 Requirements Modelling
• Use case diagram components
Use Cases:
• Hold Functional Requirements in an easy to read, easy to track text format.

• Represents the goal of an interaction between an actor and the system.

• The goal represents a meaningful and measurable objective for the actor.

• Records a set of paths (scenarios) that traverse an actor from a trigger event
(start of the use case) to the goal (success scenarios).

Dept. of CSE, SOE, Presidency University

57
 Requirements Modelling
• Use case diagram components
• Records a set of scenarios that traverse an actor from a trigger event toward a
goal but fall short of the goal (failure scenarios).

• Are multi-level: one use case can use/extend the functionality of another.

• Use Case Names Begin With a Strong Verb

• Use Cases are named using the domain terminologies

Dept. of CSE, SOE, Presidency University

58
 Requirements Modelling
• Use case diagram components
Use Cases Do Not…
• Specify user interface design. They specify the intent, not the action detail

• Mock up screens/ Prototype may be included depicting the functionality

• Specify implementation detail (unless it is of particular importance to the

actor to be assured that the goal is properly met)

Dept. of CSE, SOE, Presidency University

59
 Requirements Modelling
• Use case diagram components
• Use Case Relationships (Associations)
• Associations between actors and use cases are indicated in use case diagrams
by solid lines.
• An association exists whenever an actor is involved with an interaction
described by a use case.
• There are several types of relationships that may appear on a use case diagram:
• An association between an actor and a use case
• An association between two use cases
• A generalization between two actors
• A generalization between two use cases

Dept. of CSE, SOE, Presidency University

60
 Requirements Modelling
• Use case diagram components
• Includes Relationship
• "X includes Y" indicates that the task "X" has a subtask "Y"; that is, in the
process of completing task "X", task "Y" will be completed at least once.

• Extends Relationship
• "X extends Y" indicates that "X" is a task of the same type as "Y", but "X" is
a special, more specific case of doing "Y".
• That is, doing X is a lot like doing Y, but X has a few extra processes to it that
go above and beyond the things that must be done in order to complete Y.

Dept. of CSE, SOE, Presidency University

61
Requirements Modelling
• Use case Diagram

Association
Use Case 1 <<include>> Use Case 3
relationship

Generalization

Actor
Use Case 2 <<extend>> Use Case 4

Dept. of CSE, SOE, Presidency University

62
Requirements Modelling
• Use case Diagram – Airline Reservation System
Reservation System

Add Reservation

Cancel Reservation

Ticket Clerk
Check-in Passenger <<include>> Weigh Luggage

<<include>>

Assign Seat <<extend>> Assign Window Seat

<<extend>>

Assign Aisle Seat

Dept. of CSE, SOE, Presidency University

63
Requirements Modelling
• Use case Diagram – Online Shopping System

Dept. of CSE, SOE, Presidency University

64
Requirements Modelling
• Use case Diagram – Bank Transaction System

Dept. of CSE, SOE, Presidency University

65
Requirements Modelling
• Use case Diagram – ATM Transaction

Dept. of CSE, SOE, Presidency University

66
L17: Activity Diagram and Swimlane Diagram

LO: Illustrate the dynamic behaviour of the system with the

help of activity diagrams
Requirements Modelling
Activity Diagram
• Important Diagram in UML
• To describe the dynamic aspects of the system.
• It is basically a flowchart to represent the flow from one activity to another
activity.
• The activity can be described as an operation of the system.
• The control flow is drawn from one operation to another.
• This flow can be sequential, branched, or concurrent.
• It deals with all type of flow control by using different elements such as fork,
join, etc

Dept. of CSE, SOE, Presidency University

68
Requirements Modelling
Purpose of Activity Diagram
• It captures the dynamic behavior of the system.

• used for visualizing the dynamic nature of a system.

How to Draw:
• Activity diagrams are not exactly flowcharts as they have some additional
capabilities.

• These additional capabilities include branching, parallel flow, swimlane, etc.

Dept. of CSE, SOE, Presidency University

69
Requirements Modelling
Basic Components of an Activity Diagram
• Action: A step in the activity wherein the users or software perform a given task.
• The actions are symbolized with round-edged rectangles.
• Decision node: A conditional branch in the flow that is represented by a
diamond.
• It includes a single input and two or more outputs.
• Control flows: Another name for the connectors that show the flow between
steps in the diagram.
• Start node: Symbolizes the beginning of the activity. The start node is
represented by a black circle.
• End node: Represents the final step in the activity. The end node is represented
by an outlined black circle.

Dept. of CSE, SOE, Presidency University

70
Requirements Modelling
Activity Diagrams: Components

Connector

Dept. of CSE, SOE, Presidency University

71
Requirements Modelling
Activity Diagrams:

Dept. of CSE, SOE, Presidency University

72
Requirements Modelling

Dept. of CSE, SOE, Presidency University

73
L18: Activity Diagram and Swimlane Diagram

LO: Illustrate the dynamic behaviour of the system with the

help of swim lane diagrams
Requirements Modelling
Swimlane Diagrams
• UML has no specific Swimlane diagram.
• It is a special case under Activity diagram.
• Swimlane diagram is also graphical representation of the System.
• Swimlane diagrams are also known as the Rummler-Brache diagram or a
cross-functional diagram.
• Swimlanes are sometimes called functional bands.
• It simply describes who is responsible for the activities being performed in
the activity diagram and how they are responsible.

Dept. of CSE, SOE, Presidency University

75
Requirements Modelling
Symbols used in Swimlane Diagram :
• “Parallel Segment” is the extra symbol in swimlane diagram along with all
symbols of Activity Diagram.

• Responsibilities are represented as “Parallel Segments” that divide the

diagram vertically , like the lanes in a swimming pool hence the name
“swimlane”.

Dept. of CSE, SOE, Presidency University

76
Requirements Modelling
Swimlane Diagrams

Dept. of CSE, SOE, Presidency University

77
Requirements Modelling
Swimlane Diagrams

Dept. of CSE, SOE, Presidency University

78
Requirements Modelling
Swimlane Diagrams

Dept. of CSE, SOE, Presidency University

79
L19: Case- Characteristics of CASE tools

LO: Describe the characteristics of CASE tools

CASE support in Software Life Cycle
• Computer aided software engineering (CASE) is the implementation of
computer facilitated tools and methods in software development.

• CASE is used to ensure a high-quality and defect-free software.

• CASE ensures a check-pointed and disciplined approach.

• It helps designers, developers, testers, managers and others to see the project
milestones during development.

• CASE can also help as a warehouse for documents related to projects, like
business plans, requirements and design specifications.
Dept. of CSE, SOE, Presidency University
81
CASE support in Software Life Cycle
• Major advantage of CASE is: The delivery of the final product, which is more
likely to meet real-world requirements as it ensures that customers remain
part of the process.

• CASE illustrates a wide set of labor-saving tools that are used in software
development.

• It generates a framework for organizing projects and to be helpful in

enhancing productivity

Dept. of CSE, SOE, Presidency University

82
CASE Tools

• The essential idea of CASE tools is that in-built programs can help to analyze
developing systems in order to enhance quality and provide better outcomes.

• CASE tool became part of the software lexicon, and big companies like IBM
were using these kinds of tools to help create software.

Dept. of CSE, SOE, Presidency University

83
CASE tools Diagramming Tools

• Helps in diagrammatic and graphical representations of the data and system

processes.

• Represents system elements, control flow and data flow among different
software components and system structure in a pictorial form.

• For example, Flow Chart Maker tool for making state-of-the-art flowcharts

Dept. of CSE, SOE, Presidency University

84
CASE tools Computer Display and Report Generators

• Helps in understanding the data requirements and the relationships involved.

Dept. of CSE, SOE, Presidency University

85
 CASE tools Analysis Tools
• Focuses on inconsistent, incorrect specifications involved in the diagram and data
flow

• Helps in collecting requirements, automatically check for any irregularity,

imprecision in the diagrams, data redundancies or erroneous omissions.

For example,
(i) Accept 360, Accompa, CaseComplete for requirement analysis.
(ii) Visible Analyst for total analysis.

Dept. of CSE, SOE, Presidency University

86
 CASE tools Documentation Generators
• Helps in generating user and technical documentation as per standards.

• Creates documents for technical users and end users.

• For example, Doxygen, DrExplain, Adobe RoboHelp for documentation.

Dept. of CSE, SOE, Presidency University

87
 CASE tools Code Generators
• Aids in the auto generation of code, including definitions, with the help of the
designs, documents and diagrams

Dept. of CSE, SOE, Presidency University

88
 Advantages of the CASE approach
• As special emphasis is placed on redesign as well as testing, the servicing
cost of a product over its expected lifetime is considerably reduced.

• The overall quality of the product is improved as an organized approach is

undertaken during the process of development.

• Chances to meet real-world requirements are more likely and easier with a
computer-aided software engineering approach.

• CASE indirectly provides an organization with a competitive advantage by

helping ensure the development of high-quality products

Dept. of CSE, SOE, Presidency University

89
 Disadvantages of the CASE approach
• Cost: Using case tool is a very costly.
• Mostly firms engaged in software development on a small scale do not invest
in CASE tools because they think that the benefit of CASE are justifiable
only in the development of large systems.
• Learning Curve: In most cases, programmers productivity may fall in the
initial phase of implementation , because user need time to learn the
technology.
• Many consultants offer training and on-site services that can be important to
accelerate the learning curve and to the development and use of the CASE
tools.

Dept. of CSE, SOE, Presidency University

90
 Characteristics of CASE Tools
1) Standard Methodology :
A CASE tool should support standard software development methodologies
and modelling techniques. Presently, CASE tools use UML.
2) Flexibility :
A CASE tool must provide flexibility and options to the user for editors
and other tools.
3) Strong Integration :
CASE tools must be integrated with all stages of software development.
This means that if a change is made in a model, it must reflect in the code
documentation and all related design.

Dept. of CSE, SOE, Presidency University

91
 Characteristics of CASE Tools
4) Integration with Testing Software :
CASE tools should provide interfaces for automatic testing tools. This helps in
regression and other testing software's under changing conditions.
5) Support for Reverse Engineering :
CASE tools should be as that it can create complex models from existing code.
6) Online Help :
CASE tools offer online tutorials.

Dept. of CSE, SOE, Presidency University

92
L20: Architecture of CASE Environment

LO: Describe the CASE architecture

 Architecture of Computer Aided Software Engineering (CASE) Environment

• A database for storing information.

• An object management system for managing variations made to the information.

• A tools control mechanism for coordinating the use of the CASE tools.

• A user interface for establishing a consistent pathway between the tools and user
actions.

Dept. of CSE, SOE, Presidency University

94
Architecture of Computer Aided Software Engineering (CASE) Environment

Dept. of CSE, SOE, Presidency University

95
 Architecture of Computer Aided Software Engineering (CASE) Environment

User Interface Layer

• It is made up of an interface toolkit that is standardized.

• It implements a common protocol which is used for presentation.

• The components of the interface are a library which contains display objects
and software that facilitates management of interface between human and
computer.

Dept. of CSE, SOE, Presidency University

96
 Architecture of Computer Aided Software Engineering (CASE) Environment

User Interface Layer

• With the help of these two components the individual CASE tools and
components can communicate with each other consistently.

• The tool access mechanism, use of mouse and keyboard, menu names, object
names, icons and screen layout are described in the presentation tool.

• The tool access mechanism, use of mouse and keyboard, menu names, object
names, icons and screen layout are described in the presentation tool.

Dept. of CSE, SOE, Presidency University

97
 Architecture of Computer Aided Software Engineering (CASE) Environment

Tools Layer
• The behavior of the tools within the environment is controlled by the Tools
Management Services (TMS).

• TMS carries out multitask communication and synchronization in case

multitasking is performed by executing multiple tools at a time.

• This is done by gathering metrics on the usage of the tools, coordinating the
information flow between the repository and management system to the tools.

Dept. of CSE, SOE, Presidency University

98
 Architecture of Computer Aided Software Engineering (CASE) Environment

Object Management Layer

• A mechanism that enables in tool incorporation is the essence of the software
that is present in this layer of the framework architecture.

• Each case tool has been plugged into the object management layer.

• The OML and the CASE repository works in unison to provide integration
services.

Dept. of CSE, SOE, Presidency University

99
 Architecture of Computer Aided Software Engineering (CASE) Environment

Object Management Layer

• The tools are coupled with the repository by this set of standard modules.
Apart from all these functions, the OML also support change control, status
accounting and audits.

• Configuration management services such as the task of classifying those

configuration objects that perform version control are also executed by it.

Dept. of CSE, SOE, Presidency University

100
 Architecture of Computer Aided Software Engineering (CASE) Environment

Shared Repository Layer

• It is made up of those access control functions with the help of which the
object management layer interacts with the CASE database that is present in
this layer.

• Shared repository layers and object management helps in attaining data

integration.

Dept. of CSE, SOE, Presidency University

101
L21: Design: Design Concepts, Architectural Design

LO: Explain in detail about Architectural design

 Software Design
• It covers the set of principles, concepts, and practices that lead to the development of a
high - quality system or product.

• Goal of design engineering is to produce a model or representation that depict:

• Firmness – program should not have any bug that inhibits its functions.
• Commodity – suitable to its intended use.
• Delight - pleasurable to use

• The design model provides detail about software data structures, architecture, interfaces,
and components that are necessary to implement the system.

Dept. of CSE, SOE, Presidency University

103
Translating Analysis model to Design model

Dept. of CSE, SOE, Presidency University

104
 Translating Analysis model to Design model
• Data/class design - Created by transforming the analysis model class-based elements into classes
and data structures required to implement the software .
• Architectural design - defines the relationships among the major structural elements of the
software, it is derived from the class-based elements and flow-oriented elements of the analysis
model.
• Interface design - describes how the software elements, hardware elements, and end-users
communicate with one another, it is derived from the analysis model scenario-based elements,
flow-oriented elements, and behavioral elements.
• Component-level design - created by transforming the structural elements defined by the software
architecture into a procedural description of the software components using information obtained
from the analysis model class-based elements, flow-oriented elements, and behavioral elements.

Dept. of CSE, SOE, Presidency University

105
Quality Guidelines
A design should exhibit an architecture

 A design should be modular;

 A design should contain distinct representations of data, architecture,

interfaces, and components.

A design should lead to data structures that are appropriate for the classes to
be implemented and are drawn from recognizable data patterns.

Dept. of CSE, SOE, Presidency University

106
 Quality Guidelines
A design should lead to components that exhibit independent functional
characteristics.

A design should lead to interfaces that reduce the complexity of connections

between components and with the external environment.

A design should be derived using a repeatable method that is driven by information

obtained during software requirements analysis.

A design should be represented using a notation that effectively communicates its

meaning.

Dept. of CSE, SOE, Presidency University

107
 Software Quality Attributes
The Quality attributes of design name as “FURPS’ are as follows:

1. Functionality: It evaluates the feature set and capabilities of the program.

2. Usability: It is assessed by considering human factors overall aesthetics,

consistency, and documentation.

3. Reliability: It is evaluated by measuring parameters like the frequency and

severity of failure, the accuracy of output results, the ability to recover from failure,
and the predictability of the program.

Dept. of CSE, SOE, Presidency University

108
 Software Quality Attributes
The Quality attributes of design name as “FURPS’ are as follows:

4. Performance: It is measured by considering processing speed, response time,

resource consumption, throughput, and efficiency.

5. Supportability: It combines the ability to extend the program adaptability,

serviceability, Testability, Compatibility and Configurability are the terms using
which a system can be easily installed and found the program easily.

Dept. of CSE, SOE, Presidency University

109
 Software design Concepts
• It is an idea or principle behind the design.

• It describes how you plan to solve the problem of designing software.

• It also shows the logic or thinking behind how you will design software.

• It provides a supporting and Essential structure or model.

Dept. of CSE, SOE, Presidency University

110
 Software design Concepts
1. Abstraction
2. Architecture
3. Design Pattern
4. Modularity
5. Information Hiding
6. Functional Independence.
7. Refinement
8. Refactoring
9. Object Oriented Design

Dept. of CSE, SOE, Presidency University

111
 Software design Concepts
1. Abstraction
• It is used to hide background details or unnecessary implementation about the
data.

• Procedural Abstraction: It refers to a sequence of instructions that have a

specific and limited function.

• Data Abstraction: It is a named collection of data that describes a data object.

Dept. of CSE, SOE, Presidency University

112
 Software design Concepts
2. Architecture
• It is the structure of program modules where they interact with each other in a
specialized way.
• Structural Properties: It represents different types of components, modules,
objects and relationship between these.
• Extra-Functional Properties: Address Performance, Capacity, Reliability,
Security, Adaptability, and other System Characteristics.
• Families of related Systems: The architectural design should draw upon
repeatable patterns. The design should have the ability to reuse architectural
building blocks.

Dept. of CSE, SOE, Presidency University

113
 Software design Concepts
3. Patterns
• It means a repeated form or design in which the same shape is repeated several times
to form a pattern.
• It describes a design structure that solves a particular design problem within a specific
context and amid “forces” that may have an impact on the manner in which the pattern
is applied and used.
4. Separation of Concerns:
• A concern is a feature or behavior that is specified as part of the requirements model
for the software
• By separating concerns into smaller, and therefore more manageable pieces, a
problem takes less effort and time to solve.

Dept. of CSE, SOE, Presidency University

114
Software design Concepts
5. Modularity:
• Software is divided into separately named and addressable components,
sometimes called modules, which are integrated to satisfy problem
requirement.
• It leads to a “divide and conquer” strategy. – it is easier to solve a complex
problem when you break into a manageable pieces.
• Refer fig. that state that effort (cost) to develop an individual software module
does decrease if total number of modules increase.
• However as the no. of modules grows, the effort (cost) associated with
integrating the modules also grows.

Dept. of CSE, SOE, Presidency University

115
Modularity and software cost

Dept. of CSE, SOE, Presidency University

116
Software design Concepts
5. Information Hiding:
• Modules should be specified and designed in such a way that the data
structures and algorithm details of one module are not accessible to other
modules.
• They pass only that much information to each other, which is required to
accomplish the software functions.
• This way of hiding unnecessary details in modules is referred to as
Information Hiding.

Dept. of CSE, SOE, Presidency University

117
Software design Concepts
6. Functional Independence:
• It is the concept of separation and related to the concept of modularity,
abstraction and information hiding.
• Criteria 1: Coupling
• The degree in which module is “connected” to other module in the system.
• Low coupling necessary in good software.
• Criteria 2: Cohesion
• The degree in which module perform functions in inner module in the system.
• High Cohesion necessary in good software.

Dept. of CSE, SOE, Presidency University

118
Software design Concepts
7. Refinement
• It is a top - down design approach.
• It is a process of elaboration.
• A program is established for refining levels of procedural details.
• It helps you to reveal low - level details as design progresses.
8. Refactoring
• It is the process of changing the internal software system in a way that it does
not change the external behavior of the code still improves its internal
structure.

Dept. of CSE, SOE, Presidency University

119
Software design Concepts
9. Object Oriented Design Concepts
• It is a popular design approach for analyzing and designing an application.

• It is faster.

• High quality software will be created in low - cost development.

Dept. of CSE, SOE, Presidency University

120
Design Classes
• Each of the software team should define a set of design classes.

• Classes should describe the elements of problem domain and that should
focus the customer requirement.

• It should create a new set of design classes that must support the business
solutions.

Dept. of CSE, SOE, Presidency University

121
Architectural Design
1.1 Software Architecture:
• It is the structure or structures of the system which comprise software
components, the externally visible properties of those components, and the
relationships among them.

1.2 Importance of Software Architecture

• Representations of software architecture are an enabler for communication
between all parties (stakeholders) interested in the development of a
computer-based system.

Dept. of CSE, SOE, Presidency University

122
Architectural Design
1.2 Importance of Software Architecture

• The architecture highlights early design decisions that will have a profound
impact on all software engineering work that follows.

• Architecture “constitutes a relatively small, intellectually graspable mode of

how the system is structured and how its components work together”

Dept. of CSE, SOE, Presidency University

123
Architectural Design
1.3 Architectural Styles:
• An architectural style is a transformation that is imposed on the
design of an entire system.

• Each style describes a system category that encompasses:

1. Set of components (e.g., a database, computational modules) that perform a

function required by a system

Dept. of CSE, SOE, Presidency University

124
Architectural Design
1.3 Architectural Styles:
2. Set of connectors that enable “communication, coordination and
cooperation” among components.

3. Constraints that define how components can be integrated to form the

system.

4. Models that enable a designer to understand the overall properties of a

system by analyzing the known properties of its constituent parts.

Dept. of CSE, SOE, Presidency University

125
Architectural Design
Types of Architectural Styles:
• Data-centered architectures
• Data flow architectures
• Call and return architectures
• Layered architectures

Dept. of CSE, SOE, Presidency University

126
Architectural Design
Data Centered Architectures:

Dept. of CSE, SOE, Presidency University

127
Architectural Design
Data Centered Architectures:
• The data is centralized and accessed frequently by other components, which
modify data.

• The main purpose of this style is to achieve integrality of data.

• It consists of different components that communicate through shared data

repositories.

• The components access a shared data structure and are relatively independent, in
that, they interact only through the data store.

Dept. of CSE, SOE, Presidency University

128
Architectural Design
Data flow architectures:

Dept. of CSE, SOE, Presidency University

129
Architectural Design
Data flow architectures:

• The whole software system is seen as a series of transformations on

consecutive pieces or set of input data, where data and operations are
independent of each other.

• In this approach, the data enters into the system and then flows through the
modules one at a time until they are assigned to some final destination
(output or a data store).

Dept. of CSE, SOE, Presidency University

130
Architectural Design
Call and return architectures:

Dept. of CSE, SOE, Presidency University

131
Architectural Design
Call and return architectures:
• Call and return architectures are the most dominant architectures since the
inception of software development.

• They decompose the main program into a number of program components which,
in turn, may invoke other program components.

• They enable code modularity.

• They are easy to scale and modify.

• If interfaces are not well defined they may lead to tight data coupling.
Dept. of CSE, SOE, Presidency University
132
Architectural Design
Object oriented architectures:
• The components of a system encapsulate data and the operations that must be
applied to manipulate the data.

• Communication and coordination between components are accomplished via

message passing

Dept. of CSE, SOE, Presidency University

133
Architectural Design
Layered architectures:

Dept. of CSE, SOE, Presidency University

134
Architectural Design
Layered architectures:
• The lowest layer includes system support software—typically database and
operating system support.

• The next layer is the application layer that includes the components
concerned with the application functionality and utility components that are
used by other application components.

Dept. of CSE, SOE, Presidency University

135
Architectural Design
Layered architectures:
• The third layer is concerned with user interface management and providing
user authentication and authorization, with the top layer providing user
interface facilities.

• Of course, the number of layers is arbitrary. Any of the layers in Figure could
be split into two or more layers.

Dept. of CSE, SOE, Presidency University

136
L22: User interface design

LO: Describe the golden rules of user interface design

and principles of UID
Schneiderman’s Eight Golden Rules for Interface Design
• Ben Shneiderman is an American scientist with a strong expertise in the field
of human-machine interaction.

• Many of his works are fundamental to today's human-machine interaction, for

example the creation of the "Treemap".

• Shneiderman proposed a collection of these principles derived from his

experience, which, after being refined, developed and explained, are
applicable to interactive systems.

Dept. of CSE, SOE, Presidency University

138
Schneiderman’s Eight Golden Rules for Interface Design
1. Strive for Consistency
2. Enable Frequent Users to Use Shortcuts
3. Offer Informative Feedback
4. Design Dialog to Yield Closure
5. Offer Simple Error Handling
6.Permit Easy Reversal of Actions
7. Support Internal Locus of Control
8. Reduce Short-Term Memory Load

Dept. of CSE, SOE, Presidency University

139
User Interface Design Steps
• It is an iterative process defined with the help of a spiral model.
• The designing of an interface starts from the mid of the spiral.

Dept. of CSE, SOE, Presidency University

140
User Interface Design Steps
The model encompasses four different phases those are:

• Interface Analysis and Modelling

• Design
• Construction
• Validation

Interface Analysis and Modelling

• Before designing any solution, you need to know what actually you have to
design. We have to study the user’s profile who will use this interface.

Dept. of CSE, SOE, Presidency University

141
User Interface Design Steps
• In this phase, the designer must understand the people who will interact with
the system using the interface.

• What type of task the user has to perform to achieve the goal?

• Further, the designer must investigate the content that has to present as a part
of the interface.

• The designer must also analyze the environment where the user will interact
with the system via an interface.

Dept. of CSE, SOE, Presidency University

142
User Interface Design Steps
Interface Design:
• After completing the interface analysis, the designer identifies the task that
the end-user requires.
• Interface designing is also an iterative process.
• The designer first identifies the objects and the operations performed on
those objects.
• The designer also has to define the events that would change the state of the
user interface.
• Further, the designer has to outline each state of the user interface as it would
appear to the end-user.

Dept. of CSE, SOE, Presidency University

143
User Interface Design Steps
Interface Construction:
• After identifying the objects, operations and events the designer creates
a prototype.

• This prototype helps in the evaluation of the real-world scenario.

• This process is also iterative and the construction continues till the prototype
is approved for conducting real-world scenarios.

Dept. of CSE, SOE, Presidency University

144
User Interface Design Steps
Interface validation:
• The validation phase is performed to see whether the interface can perform
user tasks along with all the variations in the real world.

• Like, as to whether the interface can perform all general user tasks?

• Is it easy to use, and understand and we can accept it as a useful tool?

Dept. of CSE, SOE, Presidency University

145
L23: Component based design

LO: Describe the steps for Component level design

Component Level Design
• Ambler [Amb02b] suggests the following guidelines:
• Components: Naming conventions should be established for components
that are specified as part of the architectural model and then refined and
elaborated as part of the component-level model.

• Interfaces: Interfaces provide important information about communication

and collaboration.

• Dependencies and Inheritance: For improved readability, it is a good idea to

model dependencies from left to right and inheritance from bottom (derived
classes) to top (base classes).

Dept. of CSE, SOE, Presidency University

147
Conducting Component level Design
Steps for designing:
1. Identify all design classes that correspond to the problem domain.
2. Identify all design classes that correspond to the infrastructure domain.
3. Elaborate all design classes that are not acquired as reusable components.
4. Describe persistent data sources (databases and files) and identify the
classes required to manage them.
5. Develop and elaborate behavioral representations for a class or component.
6. Elaborate deployment diagrams to provide additional implementation detail.
7. Refactor every component-level design representation and always consider
alternatives.

Dept. of CSE, SOE, Presidency University

148
THANK YOU

Dept. of CSE, SOE, Presidency University

149