Course Content

Module 1:
• Introduction to Software Engineering
• Software Development Life Cycle- Classical Waterfall Model, Iterative
Waterfall Model, Prototyping Model, Evolutionary Model, Spiral Model
• Requirements Analysis and Specification
• Formal System Specification
• Software Design: Software Design Strategies, Software Analysis & Design
Tools
• Structured Design

Module 2:
• Object Modelling Using UML
• Use Case Diagram
• Class Diagrams
• Interaction Diagrams

• Activity and State Chart Diagram

Course Content
Module 3:
• Coding
• Testing : Black-Box Testing, White-Box Testing, Debugging, Integration and
System Testing
• Software Maintenance, Software Maintenance Process Models
• Software Reliability and Quality Management, Reliability Growth Models
Introduction
• What is software engineering?

The application of a systematic, disciplined,

quantifiable approach to the development,
operation and maintenance of software (IEEE)

• Software engineering is a branch of computer

science, which uses well-defined engineering
concepts required to produce efficient, durable,
scalable, in-budget and on-time software products
Introduction

• Why does software needs to be engineered?

• Large software

• Cost

• Dynamic nature

• Scalability

• Quality management
Course Content
• Characteristics of good Software
Operational Transitional Maintenance
•budget • portability •modularity
•usability • interoperability •maintainability
•efficiency • reusability •flexibility
•correctness • adaptability •scalability
•functionality
•dependability
•security
•safety
Software Development Life Cycle/Process Model
• Process model is a descriptive and diagrammatic
representation of the software life cycle

• It maps the different activities performed on a

software product from its inception to retirement .

• Activities:
• Feasibility study
• Requirement Analysis and Specification
• Design • Specification;
• Coding and Unit testing • Design;
• Integration and System testing • Validation;
• maintenance • Evolution
Process Model

• Why process models?

• Types of process models:

❑Classical Waterfall Model

❑Iterative Waterfall Model

❑Prototyping Model

❑Evolutionary Model

❑Spiral Model
 Process Model:
• Classical Waterfall Model

• Shortcoming of the classical waterfall model

 Process Model:
• Iterative Waterfall Model
• Strength
❑ Disciplined approach
❑ Careful checking by the Software Quality Assurance
Group at the end of each phase.
❑ Testing in each phase.
❑ Documentation available at the end of each phase.
• Weakness
❑ It is difficult to respond to changing customer
requirements - only appropriate when the requirements
are well-understood and changes fairly limited
❑ The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
❑ A working version of the program will not be available
until late in the project time-span
❑ Feedback from one phase to another might be too late
and hence expensive.
Process Model
• Prototyping model:
Process Model
• Need for Prototype:
• To illustrate to customer various aspect of s/w
• how the user interface might look like
• how the input data format might be designed
• how the s/w will produce outputs e.g.
messages, reports,
• It is impossible to get the perfect s/w in the first
attempt
• For critical examination of technical issues by
developers
• When is a prototype needed
• User req. are not complete
• Technical issues are not clear
Process Model
• Types of Prototype:

• Throwaway Prototype
A throwaway prototype is not part of the final product. Throwaway
prototypes should:
• be fast to build;
• help to clarify requirements and prevent misunderstanding;

• warn implementers of possible difficulties

• Evolutionary Prototype
• Evolutionary prototypes become part of the final product.

• They are usually written in the final language of the application

• Incremental Prototype
• the product is developed as a sequence of working components
• Strength
❑Requirements can be set earlier and more reliably
❑Customer sees results very quickly.
❑Customer is educated in what is possible, helping to
refine requirements.
❑Requirements can be communicated more clearly and
completely

• Weakness
❑Requires a rapid prototyping tool and expertise in using
it–a cost for the development organisation
❑Smoke and mirrors - looks like a working version, but it is
not.
Process Model
• Evolutionary model:
Process Model
• Advantages:
❑User gets a chance to experiment partially
developed system
❑Reduce the error because the core modules get
tested thoroughly.

• Disadvantages:
❑It is difficult to divide the problem into several
versions that would be acceptable to the
customer which can be incrementally
implemented & delivered.
Process Model
• Spiral model:
Process Model: Spiral model (cont’d)
❑ First quadrant (Objective Setting)
• During the first quadrant, it is needed to identify the
objectives of the phase.
• Examine the risks associated with these
objectives.
❑ Second Quadrant (Risk Assessment and
Reduction)
• A detailed analysis is carried out for each identified
project risk.
• Steps are taken to reduce the risks. For example, if
there is a risk that the requirements are
inappropriate, a prototype system may be
developed.
Process Model: Spiral model (cont’d)
❑ Third Quadrant (Development and Validation)
• Develop and validate the next level of the product
after resolving the identified risks.

❑ Fourth Quadrant (Review and Planning)

• Review the results achieved so far with the
customer and plan the next iteration around the
spiral.
• Progressively more complete version of the
software gets built with each iteration around the
spiral.
Process Model: Spiral model (cont’d)
• When to use the Spiral model:
• The spiral model is suitable for development of
technically challenging software products that
are prone to several kinds of risks.

• However, this model is much more complex than

the other models – this is probably a factor
deterring its use in ordinary projects
 Process Model: V model
Operation &
Maintenance

Verification & Validation

Acceptance
Req. Analysis
Testing
and Specification

Software Design System Testing

Unit & Integration

Program Design
Testing

Coding
 Process Model: V model
Advantages of V-model:
• Simple and easy to use.
• Testing activities like planning, test designing happens well
before coding. This saves a lot of time. Hence higher chance
of success over the waterfall model.
• Proactive defect tracking – that is defects are found at early
stage.
• Avoids the downward flow of the defects.
• Works well for small projects where requirements are easily
understood.

Disadvantages of V-model:
• Very rigid and least flexible.
• Software is developed during the implementation phase, so
no early prototypes of the software are produced.
• If any changes happen in midway, then the test documents
along with requirement documents has to be updated.
 Agile methods
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
Manifesto for Agile Software Development

We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.
 Agile methods
The Agile methods:

• Rational Unified Process (1994),

• Scrum (1995),

• Extreme Programming (1996),

• Adaptive Software Development,

• Feature Driven Development, and

• Dynamic Systems Development Method (DSDM)

(1995).
Requirement Analysis and Specification

(Requirements Engineering)
 Requirements Analysis and Specification/
Requirements Engineering
• What are Requirements?

are the descriptions of the system services and

constraints that are generated during req.
gathering

• What is Requirements Engineering?

is the process of establishing the services that the

customer requires from a system and the
constraints under which it will operate and even
be developed
 Requirements Engineering

• Requirements Engineering Process?

Feasibility
Study Req. Elicitation
and Analysis
Req.
Specification

Feasibility Req.
Report Validation
System
models User and System
Req.

Req. Document.
 Requirements Engineering

• Types of Requirements:

• User Req.
- Statements in NL plus diagrams of services the system provides
and its operational constraints
- Written for customers

• System Req.
- Structured and detailed description of the system’s services
and operational constraints

- defines what should be implemented

 Requirements Engineering
• Example:

• User Req.- definition

-The Software must provide a means of accessing external files
created by other tools

• System Req.- Specification

- facility for the user to defined the type of external file
- each external file should have an associated tool for viewing
the file

- each external file must have an icon on the desktop

- the user must be able to click the icon to view the file using the
associated tool
 Requirements Engineering

• Types of Requirements:

• Functional Req. (FR)

- Statements of the specific services that the software should
provide.

• Non Functional Req. (NFR)

- the constraints on the services offered by the system e.g.
efficiency constraints, operational constraint, development
process constraints (use of standards), etc.
 Requirements Engineering
• Functional Req. (FR)

• E.g. For a Library System (LIBSYS)

F1: Search Book
Input: author’s name
output: book details and location in the lib..
 Requirements Engineering

• FR Documentation:

• The state at which the data is to be input to the

system,

• its input data domain,

• the output data domain, and

• the type of processing to be carried on the input

data to obtain the output data
 Requirements Engineering
• Example: Cash withdrawal from ATM
R1: withdraw cash
Description: The withdraw cash function first determines the type of account that the user
has and the account number from which the user wishes to withdraw cash. It checks the
balance to determine whether the requested amount is available in the account. If enough
balance is available, it outputs the required cash; otherwise it generates an error message
R1.1: select withdraw amount option
Input: “withdraw amount” option
Output: user prompted to enter the account type
R1.2: select account type
Input: user option
Output: prompt to enter amount
R1.3: get required amount
Input: amount to be withdrawn in integer values greater than 100 and less
than 10,000 in multiples of 100.
Output: The requested cash and printed transaction statement.
Processing: the amount is debited from the user’s account if sufficient
balance is available, otherwise an error message displayed
 Requirements Engineering

• Non Functional Req. (NFR)

NFR

Product Req. Org. Req. External Req.

Efficiency Reliability Portability Interoperability

Ethical Req.
Req. Req. Req. Req.

Usability Delivery Implementation Standards Legislative

Req. Req. Req. Req. Req.

Performance
Req. Space Req.
Privacy Req. Safety Req.
 Requirements Engineering

• NFR Example: for the LIBSYS

• Product Req.:
the LIBSYS user interface shall be implemented as simple
HTML page without frames or Java Applets

• Organization Req.:
the software development process and deliverable docs shall
conform to the process and deliverables specified in ISO 9001

• External Req.:
the system shall not disclose customers’ personal information
apart from their name and ref ID to the operators of the system
 Requirements Engineering

• NFR Example: for the LIBSYS

• Product Req.:
the LIBSYS user interface shall be implemented as simple
HTML page without frames or Java Applets

• Organization Req.:
the software development process and deliverable docs shall
conform to the process and deliverables specified in ISO 9001

• External Req.:
the system shall not disclose customers’ personal information
apart from their name and ref ID to the operators of the system
 Requirement Analysis and Specification
• Properties of a good SRS document:

• Concise

• Structured

• Black-box view

• Conceptual integrity

• Response to undesired events

• Verifiable.
 Requirement Analysis and Specification
Problems without a SRS document
• Without developing the SRS document, the system would not
be implemented according to customer needs.

• Software developers would not know whether what they are

developing is what exactly required by the customer.

• Without SRS document, it will be very much difficult for the

maintenance engineers to understand the functionality of the
system.

• It will be very much difficult for user document writers to write

the users’ manuals properly without understanding the SRS
document.
 Requirement Analysis and Specification
Problems with an unstructured specification

• It would be very much difficult to understand that document.

• It would be very much difficult to modify that document.

• Conceptual integrity in that document would not be shown.

• The SRS document might be ambiguous and inconsistent.

 Requirements Engineering
• Requirements Modeling
• Structured Approach: data and processes are kept separate
• Object-Oriented Approach: definition of classes and how
they collaborate

• Types/Elements of Requirements models:

Scenario-based models Class models

e.g.: e.g.:
User stories Class diagram
Use cases Collaboration
Data model
diagrams
e.g.:
ERD
Software
Requirements
Behavioral models Flow models
e.g.: e.g.:
Sequence diagram DFD
State diagram
 Requirements Engineering
• Scenario-based model models requirements from the point of
view of various system “actors”

• Data model depict the information domain for the problem

• Class-oriented model models that represent object-oriented

classes (attributes and operations) and the manner in which
classes collaborate to achieve system requirements

• Flow-oriented model represent the functional elements of the

system and how they transform data as it moves through the
system

• Behavioral model depict how the software behaves as a

consequence of external “events” over time
 Requirement Analysis and Specification
The requirements model objectives:

(1) to describe what the customer requires

(2) to establish a basis for the creation of a software design

(3) to define a set of requirements that can be validated once

the software is built

System
Description
Analysis
model
Design
model
 Requirements Engineering
• Scenario-based Modeling:
• Developing Use Cases

• A use case tells a stylized story about how an end

user (playing one of a number of possible roles)
interacts with the system under a specific set of
circumstances.

• The story may be narrative text, an outline of tasks

or interactions, a template-based description, or a
diagrammatic representation.

• They depict the software or system from the end

user’s point of view.
 Requirements Engineering
• A Use Cases should address the following questions:

• Who is the primary actor, the secondary actor(s)?

• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the story is described?
• What variations in the actor’s interaction are possible?
• What system information will the actor acquire, produce, or change?
• Will the actor have to inform the system about changes in the
external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?
 Requirements Engineering
• Use Case Template
Use case:
Primary actor:.
Goal in context:
Preconditions:
Trigger:
Scenario:
Exceptions:
Priority:
When available:
Frequency of use:
Channel to actor:
Secondary actors:
Channels to secondary actors:
Open issues:
 Requirements Engineering
• Use Case Example:
Use case: InitiateMonitoring
Primary actor: Homeowner.
Goal in context: To set the system to monitor sensors when the homeowner
leaves the house or remains inside.
Preconditions: System has been programmed for a password and to recognize
various sensors.
Trigger: The homeowner decides to “set” the system, i.e., to turn on the
alarm functions.
Scenario:
1. Homeowner: observes control panel
2. Homeowner: enters password
3. Homeowner: selects “stay” or “away”
4. Homeowner: observes read alarm light to indicate that SafeHome has been armed
Exceptions:
1. Control panel is not ready: homeowner checks all sensors to determine which are
open; closes them.
2. Password is incorrect (control panel beeps once): homeowner reenters correct
password.
3. Password not recognized: monitoring and response subsystem must be contacted to
reprogram password.
4. Stay is selected: control panel beeps twice and a stay light is lit; perimeter sensors
are
activated.
5. Away is selected: control panel beeps three times and an away light is lit; all sensors
are activated.
Priority: Essential, must be implemented
When available: First increment
Frequency of use: Many times per day
Channel to actor: Via control panel interface
Secondary actors: Support technician, sensors
Channels to secondary actors:
Support technician: phone line
Sensors: hardwired and radio frequency interfaces
Open issues:
1. Should there be a way to activate the system without the use of a password or with
an abbreviated password?
2. Should the control panel display additional text messages?
3. How much time does the homeowner have to enter the password from the time the
first key is pressed?
4. Is there a way to deactivate the system before it actually activates?
 Requirement Analysis and Specification
Use case Diagram
SafeHome

Configure
System

Initiate
Monitoring

Access
Camera Cameras
Survelance
 Requirements Engineering
Data Modeling:
• Data model defines all data objects that are processed
within a S/W system, the relationships between the data
objects, and other information that is pertinent to the
relationships.
• ERD

• Encapsulates data only i.e. attributes

• Data object: is a representation of composite information

that must be understood by software e.g. Person, Car, etc.

• Relationships: owns
Person Car
Insured to
drive
 Requirements Engineering
Class-based Modeling:
• Is the identification and representation of the objects, the
operations on the objects, and relationships between the
objects

• Classes: objects with common attributes and behaviors

• Identifying [Analysis] classes, attributes and operations:

• performing grammatical parse on use cases/ user
stories developed for the system to be built

• Noun/noun phrase indicates class

• Verb indicate operations

 Requirements Engineering
Potential Classes show up as:
• External entities (e.g., other systems, devices, people) that
produce or consume information

• Things (e.g., reports, displays, letters, signals) that are part of

the information domain for the problem.

• Roles (e.g., manager, engineer, salesperson) played by people

who interact with the system.

• Organizational units (e.g., division, group, team) that are

relevant to an application.
 Requirements Engineering
Use case example:
The SafeHome security function enables the homeowner to configure the
security system when it is installed, monitors all sensors connected to the
security system, and interacts with the homeowner through the Internet, a PC, or
a control panel.
During installation, the SafeHome PC is used to program and configure the
system. Each sensor is assigned a number and type, a master password is
programmed for arming and disarming the system, and telephone number(s) are
input for dialing when a sensor event occurs.
When a sensor event is recognized, the software invokes an audible alarm
attached to the system. After a delay time that is specified by the homeowner
during system configuration activities, the software dials a telephone number of a
monitoring service, provides information about the location, reporting the nature
of the event that has been detected. The telephone number will be redialed every
20 seconds until telephone connection is obtained.
The homeowner receives security information via a control panel, the PC, or a
browser, collectively called an interface. The interface displays prompting
messages and system status information on the control panel, the PC ,or the
browser window. Homeowner interaction takes the following form . . .
 Requirements Engineering
Use case example:
Potential classes General classification
homeowner role or external entity
sensor external entity
control panel external entity
installation occurrence
system thing
number, type Not an object, Attributes of sensor
master password thing
telephone number thing
sensor event occurrence
audible alarm Thing or external entity
monitoring service Organisation or external entity
 Requirements Engineering
6 Selection Characteristics (Coad and Yourdon, 91) :
Characteristics description
1. Retain information The potential class will be useful during analysis only if
information about it must be remembered so that the
system can function
2. Needed service The potential class must have a set of identifiable
operations that can change the value of its attributes in
some way
3. Multiple attributes Classes with major information; a class with a single
attribute may probably be better represented as an
attribute of another class
4. Common attributes A set of attributes can be defined for the potential class
5. Common operations A set of operations can be defined for the potential class
6. Essential requirement External entities that appear in the problem space and
produce or consume information essential to the operation
of any solution for the system will almost always be defined
as classes in the requirements model
 Requirements Engineering
Applying the 6 selection characteristics:
Potential classes General classification
homeowner Rejected: 1 and 2 fail, even thou 6 applies
sensor Accepted: all apply
control panel Accepted : all apply
installation Rejected:
system Accepted: all apply
number, type Rejected: 3 fails, attribute of sensor
master password Rejected: 3 fails
telephone number Rejected: 3 fails
sensor event Accepted : all apply
audible alarm Accepted : 2, 3, 4, 5, 6 apply
monitoring service Rejected: 1 and 2 fail, even thou 6 applies
 Requirements Engineering
Categories of class:

• Entity classes (a.k.a. model or business classes)

• Boundary classes: creates interfaces e.g. interactive

screens and printed reports

• Controller classes: manage a “unit of work” from start to

finish
 Requirements Engineering
Defining the attributes of class:
• The data items that describes the class in the problem context
• Thus, attempt to answer the question:

What data items(composite and/or elementary) fully define

this class in the context of the problem at hand?”

e.g.
• Sensor: roomLocation, active

• System: systemID, phoneNumber, masterPassword,

numberOfTries, etc.
 Requirements Engineering
Defining the operations of class:
Four broad categories of operations:

• Operations that manipulate data (e.g., adding, deleting,

reformatting, selecting)

• Operations that perform computation

• Operations that inquire about the state of an object, and

• Operations that monitor an object for the occurrence of a

controlling event
 Requirements Engineering
Defining the operations of class:
Example:
from the use case narrative, the sensor is assigned a number
and type or a master password is programmed for arming
and disarming the system.” Thus:

• an assign() operation is relevant for the Sensor class.

• a program() operation will be applied to the System class.

• The system can be armed- arm() – and disarmed -disarm()

-are operations that apply to System class.
 Requirements Engineering
The class representation:

System

systemID
phoneNumber
masterPassword
numberOfTries

program()
arm()
disarm()
display()
dial()
 Requirements Engineering
Class-Responsibility-Collaborator (CRC) modeling:

• A CRC model is really a collection of standard index cards

that represent classes.

• The intent is to develop an organized representation of

classes

• The cards are divided into three sections:

 Requirements Engineering
Class-Responsibility-Collaborator (CRC) modeling:
Class:
Class:
Class:Sensor
Control Panel
Class:
Description: System
…..
Description:
Description:…..
…..
Description: …..
Responsibility:
Responsibility: Collaborator:
Collaborator:
Responsibility: Collaborator:
Responsibility:
systemID Collaborator:
systemID
systemID
systemID
phoneNumber
phoneNumber
phoneNumber
phoneNumber
masterPassword Control Panel
masterPassword
masterPassword Control
ControlPanel
Panel
masterPassword
numberOfTries Control
Sensor Panel
numberOfTries
numberOfTries Sensor
Sensor
numberOfTries Sensor
 Requirements Engineering
• Responsibilities are simply anything the class knows or does

Guidelines for allocating responsibilities to classes

(Wirfs-Brock et al., 90):
1. System intelligence should be distributed among classes

2. Each responsibility should be stated as general as

possible

3. Information and behaviors related to it should reside

within the same class
4. Information about one thing should be localized within a
single class not distributed across multiple classes

5. Responsibilities should be shared among classes when

appropriate
 Requirements Engineering
• Collaborators are those classes that are required to provide a
class with the information needed to complete a responsibility

• Collaborations represent requests from a client to a server in

fulfillment of a client responsibility.

• An object collaborates with another object if, to fulfill a

responsibility, it needs to send the other object any messages.

• From the client’s point of view, each of its collaborations is

associated with a particular responsibility implemented by the
server
• Generic Relationship:
• is-part-of relationship
• has-knowledge-of relationship
• depend-upon relationship
 Requirements Engineering
CRC model review:

1. The cards are distributed within the review team members. Cards that
collaborate should be separated

2. All use-case scenarios should be organized into categories.

3. The review leader reads the use case and when the name of a named
object is read, a token is passed to the person holding the
corresponding class index card.

4. When the token is passed, the holder of the card is asked to describe
the responsibilities noted on the card. The group determines whether
the responsibilities satisfies the use-case requirement.

5. If the responsibilities and collaborations do not satisfy the use case,

modifications are made to the cards.
 Requirements Engineering
UML diagrams:
1. Use Case Diagram
2. Class Diagram
3. Object Diagram
4. Activity Diagram
5. Sequence Diagram
6. Collaboration Diagram
7. State Machine Diagram
8. Component Diagram
9. Deployment Diagram
10. Package Diagram
11. Swim Lane Diagram
Other Diagrams:
1. DFD
2. ERD
3. Petri-Net
4. Decision Table
 Requirements Engineering
Flow-based Modeling: Data Flow & Control Flow
• Data Flow Model: is an input-process-output view of a
system using DFD
• In DFD
• labeled arrows rep data object
• circles (bubbles) rep transformation
• The 1st model rep the whole system – Level 0 DFD
• Subsequent levels progressively breaks the system
into functions
• Guidelines for DFD modeling
• Level 0 depicts the system as a single bubble
• Primary inputs and output should be identified
• All arrows and bubbles should be given
meaningful names
• Ensure information flow continuity
• One bubble at a time should be refined
 Requirements Engineering
Flow-based Modeling: Data Flow & Control Flow
• Data Flow Model:
Control
Display Panel
User commands information Display
Control
and data
Panel

SafeHome Alarm type

Alarm
Software

Sensors Sensor status

Telephone
number tone Telephone
line
 Requirements Engineering
Flow-based Modeling: Data Flow & Control Flow

• Control Flow Model

• Control specification (CSPEC) –behavioral: State
transition diagram or state chart diagram

• Process specification (PSPEC): describes all the flow

model processes at the end of the refinement
• Narrative text
• PDL
• Mathematical equations
• Tables
• Activity diagram
 Requirements Engineering
Behavior Modeling:
• behavioral model indicates how software will respond to
external events or stimuli.
• Steps to create behavioral models:

i. Evaluate all use cases to fully understand the

sequence of interaction within the system.

ii. Identify events that drive the interaction sequence and

understand how these events relate to specific objects.

iii. Create a sequence for each use case.

iv. Build a state diagram for the system.

v. Review the behavioral model to verify accuracy and

consistency.
 Requirements Engineering
Behavior Modeling:
• Identifying events:
The homeowner uses the keypad to key in a four-digit
password. The password is compared with the valid password
stored in the system. If the password is incorrect, the control
panel will beep once and reset itself for additional input. If the
password is correct, the control panel awaits further action.

• For each event, identify the following:

• An actor for each event
• Information exchanged
• Any conditions or constraints listed
• E.g.:
1. Homeowner transmit the event (password entered) to the ControlPanel

• Allocate every event to the objects involved

 Requirements Engineering
Behavior Modeling:
Timer ≤ lockedTime
• Build a state diagram for the system.
• Passive state
• Active state Timer > lockedTime Locked

Password is incorrect & numOfTries < maxTries

Key hit numOfTries > maxTries

Reading Comparing
Password
Entered
Do: validatePassword Password is
correct

Selecting

Activation successful

State diagram for ControlPanel class

 Requirements Engineering
Behavior Modeling:
• Create a sequence for each use case

Homeowner ControlPanel System Sensors

System Reading
ready A

Password entered
Request lookup
Comparing

Result
Password is correct Request activation
numOfTries > maxTries
Locked
Timer > lockedTime
A

Selecting

Activation successful Activation successful

 Requirements Engineering
Requirements modeling for WebApps
• Why?
• Size and complexity
• Number of stakeholders
• WebApp team size and the level of team work
• The level of organizational dependence on the WebApp

• Inputs:
• Stakeholders and user categories
• Business context
• Informational and applicative goals
• Usage scenarios
• Representation: NL Description, rough outlines, sketches, etc

• Req modeling structures the input using formally defined

representation schemes, producing rigorous models as output
 Requirements Engineering
Requirements modeling for WebApps
• Output:
• Content model: identifies the full spectrum of content to be provided by
the WebApp. Content includes text, graphics and images, video, and
audio data. Rep: List or using Data Tree

• Interaction model: describes the manner in which users interact with

the WebApp. Rep: use case, seq diagram, state diagram or user
interface prototypes

• Functional model: defines the operations that will be applied to

WebApp content and describes other processing functions that are
independent of content but necessary to the end user. Rep: activity diag

• Navigation model: defines the overall navigation strategy for the

WebApp. Rep: site map

• Configuration model: describes the environment and infrastructure in

which the WebApp resides. Rep: List or UML deployment diagram
 Requirements Engineering
Requirements modeling Rules of Thumb:
• The model should focus on requirements that are visible within
the problem or business domain. The level of abstraction
should be relatively high.

• Each element of the requirements model should add to an

overall understanding of software requirements and provide
insight into the information domain, function, and behavior
of the system.

• Delay consideration of infrastructure and other nonfunctional

models until design. That is, a database may be required, but
the classes necessary to implement it, the functions required
to access it, and the behavior that will be exhibited as it is
used should be considered only after problem domain analysis
has been completed.
 Requirements Engineering
Requirements modeling Rules of Thumb (cont’d):

• Minimize coupling throughout the system.

• Be certain that the requirements model provides value to all

stakeholders. Each constituency has its own use for the
model. For example, business stakeholders should use the
model to validate requirements; designers should use the
model as a basis for design; QA people should use the model
to help plan acceptance tests.

• Keep the model as simple as it can be. Don’t create additional

diagrams when they add no new information. Don’t use
complex notational forms, when a simple list will do.
 Requirements Engineering
Requirement Validation
• Is each requirement consistent with the overall objectives for
the system/product?
• Have all requirements been specified at the proper level of
abstraction?
• 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?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment
that will house the system or product?
• Is each requirement testable, once implemented?
• Does the requirements model properly reflect the information,
function, and behavior of the system to be built?
Stage Activity Score
1 Group Project 10%
Project Proposal
• Brief Description
• Objective
• Scope
• Methodology/Justification
• Deadline : 1/7/16
2 Requirement Analysis & spec 30%
• SRS: (15%)
• FR
• User Req
• Syst spec
• NFR
• Req. models (15%)
• Deadline: 15/7/16
3 Design 30%
• Architecture
• Interface
• Components
• Deadline : 22/7/16
4 Coding 20%
Deadline: 5/8/16
5 Testing 10%
Software Design
 Design
What is Software Design?

• Software Design consist of the set of principles, concepts

and practices that lead to the development of a high-quality
system or product.

• It is the creative process of transforming the problem into a

solution

• Quality: firmness, commodity and delight

 Design
Software Design Concept

Addresses the following questions:

• What criteria can be used to partition software into

individual components?

• How is function or data structure detail separated from a

conceptual representation of the software?

• What uniform criteria define the technical quality of a

software design?
 Design
Software Design Concept:

• Abstraction

• Separation of Concerns

• Modularity

• Information hiding

• Functional Independence

• Refinement

• Refactoring
 Design
Software Design Quality:
Quality guidelines:

1. A design should exhibit an architecture that

• has been created using recognizable architectural
styles or patterns,
• is composed of components that exhibit good design
characteristics
• can be implemented in an evolutionary fashion, thereby
facilitating implementation and testing.

2. A design should be modular

3. A design should contain distinct representations of data,

architecture, interface and components
 Design
Software Design Quality:
Quality guidelines:

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

5. A design should lead to components that exhibit independent

functional characteristics.

6. A design should lead to interfaces that reduce the complexity of

connections between components and with the external
environment.

7. A design should be derived using a repeatable method that is driven

by information obtained during software requirements analysis.

8. A design should be represented using a notation that effectively

communicates its meaning.
 Design
Software Design Quality:
Quality attributes:
Hewlett-Packard [Gra87] developed a set of software quality
attributes that has been given the acronym FURPS:

• Functionality: feature set, capability and security of the sys

• Usability: aesthetics, consistency and documentation

• Reliability: frequency and severity of failure; ability to

recover from failure

• Performance: process speed, response time, resource

consumption, throughput and efficiency

• Sustainability: extensibility, adaptability and serviceability

 Design
Software Design Process
Design Tasks:

1. Design appropriate data structure for data objects and their attributes

2. Select appropriate architectural style for the software

3. Partition the analysis model into design subsystems

4. Create design classes or components

5. Design interfaces with external systems/devices

6. Design the user interface

7. Conduct component level design

8. Develop a deployment model

 Design
Software Design model
Component-level
design
Scenario-based Flow models
models e.g.:
e.g.: DFD
User stories
Use cases
Interface
Design
Software
Requirements Architectural Design
Class models Behavioral
e.g.: models
Class diagram e.g.:
Collaboration Sequence Data/Class Design
diagrams diagram
State diagram

Design Model

Translating requirements model into design model

 Design
Data design

• Refinement of the high level abstraction of data (in the

requirements engineering phase) progressively into
implementation specific representation

• At program component level – Data Structure and related

algorithm

• At application level – Database

• At business level – Data warehouse

 Design

Architecture Design

• The blueprint of the software depicted as a set of

interconnected subsystems

• Overall view of the software i.e., the “big picture”

• Derived from:
• DFD
• Analysis classes
• Architectural style and pattern
Interface Design
Design
• The User Interface (UI)

• External Interfaces to other systems, devices, network – other

producer/consumer of information

• Internal Interface between the components of the design

Component-level Design
• The internal detail of each software component

• Data structure of all local objects for each component

• The algorithmic detail for all processing in each component

• The interface that allow access to each component

 Design
Deployment level Design
• Physical allocation of Functionality and subsystem within computing environment

• E.g. UML Deployment diagram

• Descriptor form
• Instance form
Web Server
HomeOwnerAccess
Control Panel
Security

PC
ExternalAccess

Security Surveillance

HomeManagement Communication
 Design
Software Architectural Design

Software Architecture of a program/computing system is

the structure(s) of the system, which comprise software
components, the externally visible properties of those
components and relationship among them

Why is it important?

• Communication between stakeholders

• Specifies design decision that impact quality

• High level view of the structure of the software and its

constituent components and their relationships
 Design
Software Architectural Design

Architectural Genres (application domain)

•Artificial intelligence •Medical

•Commercial and nonprofit •Military
•Communication •Operating system
•Content authoring •Platforms
•Devices •Scientific
•Entertainment and sport •Tools
•Financial •Transportations
•Games •Utilities
•Government
•Industrial
•Legal
 Design
Software Architectural Design

Architectural Styles

• Describes the general image of software systems

• It is a template for construction

• It establishes a structure for all components of the system

• It is a transformation that is imposed on the design of the

entire system
 Design
Adv
Architectural Styles • Openness
Disadv
• Shared data must be in a form
• Data-Centered architecture acceptable to all client software
Client Client
Client Software Software Client
Software Software

Client Data Store Client

Software (repository or blackboard) Software

Client Client
Software Client Client Software
Software Software
 Design
Architectural Styles
• Data-Flow architecture
Pipes
Filter Filter

Filter Filter Filter Filter

Filter Filter Filter

Adv
• Ease understanding
• Filter reusability Filter
• Easy maintenance
• Concurrent execution of filters

Disadv
• Batch processing, not good for interactive
application
• Duplicate preparatory functions in several fiters
 Design
Architectural Styles
• Call and Return architectures
• Main program/subprogram architecture
• Remote procedure call architecture

Main Program

Controller Controller Controller

subprogram subprogram subprogram

Application Application Application Application Application

subprogram subprogram subprogram subprogram subprogram

Application Application
subprogram subprogram
 Design
Architectural Styles
• Object-Oriented architectures – UML Class Diagram
• Layered architectures
Adv
User Interface layer • Great use of abstraction at each
layer
• Easy addition/removal of layer since
Application layer interaction is restricted
• Modification is easy
Utility layer
Disadv
Core • Not easy to structure requirements
layer into layers
• Extra coordination required between
layers
 Design
Architectural Styles
• Distributed system architectures
• Client-server architecture

Adv
• User get needed information when and in the
form they need it

Disadv
• Needs sophisticated security
• Sophisticated system management
• Sophisticated application development
 Design
Architectural Design
• Representing the System in context
• Architectural Context Diagram

Superordinate systems

Used by

Target System
Uses
Uses Peers
Actors
Depends on

Subordinate systems
 Design
Architectural Design
• Refining the architecture into Components
• Source of top-level components: (depending on the approach)
• OO approach:
• Business domain - Analysis classes identified in RE
• Infrastructure domain – memory management, database
and communication components
• Specialized components – interfaces depicted in ACD

• E.g. SafeHome security system

• External communication management
• Control Panel processing
• Detector management
• Alarm processing
 Design
Architectural Design
• E.g. SafeHome security system

SafeHome
executive

External
communication
Security
management

GUI Internet
interface
Control panel Detector Alarm
processing management processing
 Design
Architectural Design
• Refining the architecture into Components
• Non-OO approach - Structure design
• Is a data flow-oriented design method that maps DFD
into software architecture (structure chart) using the
following steps:

1. Determine the type of information flow:

transformation or transaction
2. Indicate the flow boundaries
3. Map the DFD into program structure
4. Define the control hierarchy
5. Refine the structure using design measures and
heuristics
6. Elaborate the architecture
 Design
Architectural Design
• Refining the architecture into Components
• Non-OO approach - Structure design
• Transform Analysis/Mapping
1. Divide the DFD into 3 parts: afferent branch,
transform center and efferent branch

2. Draw one functional component each for the 3 parts

and place them under a root module

3. Factoring: add sub-functions to the high level

functional component above. Repeat until all
bubbles in the DFD is added to the structure chart

• Transaction Analysis/Mapping
• Every transaction path forms a functional component
 Design
Component-level Design

• What is a Component?

“. . . a modular, deployable, and replaceable part of a

system that encapsulates implementation and exposes
a set of interfaces.”

OMG Unified Modeling Language Specification

 Design
Component-level Design – OO approach
Employee
computePayChecks
Name
DoB
Sex
computeSalary() Salary
computeAge() Computation

<<interface>> Employee
computePayCheck
surname: string
computeSalary() firstname: string
computeEarnings() Middlename: string
computeDeductions() DoB: date
preparePayslips() sex: character
computeSalary()
computeEarnings()
computeDeductions()
preparePayslips()
 Design
Component-level Design – traditional approach

computeSalary

float totalEarning
float totalDeduction
int month
int year
string bank
string emplyeeName
int staffID totalEarning=computeEarning(staffID)
computeSalary()
totalDeduction =computeDeductions(staffID)
computeEarnings(ID)
netPay= totalEarning – totalDeduction
computeDeductions(ID) .
.
preparePayslips(ID) .
.
.
 Design
Component-level Design
Principles for Designing Class based Components

• The Open-Closed Principle (OCP):

“A module [component] should be open for extension
but closed for modification”

• The Liskov Substitution Principle (LSP):

“Subclasses should be substitutable for their base
classes”

• Dependency Inversion Principle (DIP):

“Depend on abstractions. Do not depend on
concretions”
 Design
Component-level Design

Principles for Designing Class based Components

• The Interface Segregation Principle (ISP):

“Many client-specific interfaces are better than one
general purpose interface”

• The Common Closure Principle (CCP):

“Classes that change together belong together.”

• The Common Reuse Principle (CRP):

“Classes that aren’t reused together should not be grouped
together”
 Design
Component-level Design
Cohesion:

• Functional cohesion
• Layered cohesion
• Communicational cohesion

Coupling:
• Content coupling
• Common coupling
• Control coupling
• Stamp coupling
• Routine call coupling
• Type use coupling
• Import coupling
• External coupling