INFORMATION AND

SOFTWARE ASSURANCE
AND SECURITY
 MODULE 1
INTRODUCTION TO
SOFTWARE ENGINEERING
• Importance of software engineering
• Different layers of software engineering
• Challenges in developing software
• Perspective on quality for software
• Different members of the development team
 Part 1
Module 1 Submodule 1
 Module 1
Submodule 1
Software Engineering Definitions and Layers

• Importance of software engineering

• Different layers of software engineering
The term software engineering was popularized during
the 1968 NATO Software Engineering Conference (held in
Garmisch, Germany) by its chairman F.L. Bauer, and has
been in widespread use since.

The field of SE aims to find answers to the many

problems that software development projects are likely
to meet when constructing large software systems.
Such systems are complex
• because of their sheer size,
• because they are developed by a team involving
people from different disciplines, and
• because they will be modified regularly to meet
changing requirements, both during development and
after installation.
The software developed is according to:
Accepted industry practice, with good quality control,
adherence to standards, and in an efficient and timely
manner.

The term software engineering refers to a systematic

procedure that is used in the context of a generally
accepted set of goals for the analysis, design,
implementation, testing and maintenance of software
According to IEEE SOFTWARE ENGINEERING is the
application of a systematic, disciplined, quantifiable
approach to the development, operation, and
maintenance of software.

The discipline of software engineering encompasses

knowledge, tools, and methods for defining software
requirements, and performing software design, software
construction, software testing, and software
maintenance tasks.
SOFTWARE ENGINEERING also draws on knowledge from
fields such as computer engineering, computer science,
management, mathematics, project management, quality
management, software ergonomics, and systems
engineering.
This is according to the author Ronald Leach.
• The software produced should be efficient, reliable,
usable, modifiable, portable, testable, reusable,
maintainable, interoperable, and correct.
• SWEBOOK (Software Engineering Body of
Knowledge) , 2013 defines these characteristics as the
following
The software produced should be:
• Efficient – software made in expected time and
within resources
• Reliable – software performs as expected
• Usable – software can be used properly
• Modifiable – software can be easily changed as
requirement changes
The software produced should be:
• Portable – system can be ported to other
computers without major rewriting of the software
• Testable – software can be easily tested
• Reusable – software can be used again in other
projects
The software produced should be:
• Maintainable – software can be easily
understood and changed overtime if problems
occur
• Interoperable – software can interact with other
systems properly
• Correct - the program produces the correct
output
Software Engineering:
focusing on computer as a
problem-solving tool

Relationship between
computer science and
software engineering

Figure 1.1
Relationship between computer science and software engineering
Over the past years
• Technology has advanced rapidly
• Ordering of food, clothes, or even transportation is done
through smartphones, while on the phone and en route to
your next destination
• With this example, software has grown to provide
humanity with endless opportunities
More complex is the system, the more is the
programming skill needed.

In a nutshell, software engineering is developing

complex software end products by professionals within
time and budget.

Software engineering is often viewed as layered.

 Part 2
Module 1 Submodule 1
 SOFTWARE ENGINEERING IS A
LAYERED TECHNOLOGY AS FOLLOWS:

Figure 1.2
Software engineering layers
SOFTWARE ENGINEERING LAYERS
QUALITY FOCUS
The bedrock that supports software engineering. Any
engineering approach must rest on an organizational
commitment to quality.

Figure 1.2
Software engineering layers
SOFTWARE ENGINEERING LAYERS
PROCESS
It is the glue that holds the technology layers
together and enables rational and timely
developments of computer SW.

Figure 1.2
Software engineering layers
 SOFTWARE ENGINEERING LAYERS
PROCESS
Process defines a framework that must be established for
effective delivery of SW engineering technology.

Figure 1.2
Software engineering layers
 SOFTWARE ENGINEERING LAYERS
PROCESS
It forms the basis for
• management control of software projects
• establishes the context (technical
methods applied)
• Work products (models, documents,
data, reports, form, etc.) are produced, Figure 1.2
• milestones are established, Software engineering layers

• quality is ensured, and change is properly

managed
SOFTWARE ENGINEERING LAYERS
METHODS
• Provide the technical how-to’s for building SW.

Figure 1.2
Software engineering layers
SOFTWARE ENGINEERING LAYERS
METHODS
• Encompasses a broad array of tasks that include
communication, requirements analysis, design
modeling, program construction, testing, and
support.

Figure 1.2
Software engineering layers
SOFTWARE ENGINEERING LAYERS
METHODS
• Rely on a set of basic principles that govern
each area of the technology and include
modeling activities and other descriptive
techniques.

Figure 1.2
Software engineering layers
SOFTWARE ENGINEERING LAYERS
TOOLS
Provide automated and semi automated support
for the process and the methods.

Figure 1.2
Software engineering layers
SOFTWARE ENGINEERING LAYERS
TOOLS
When tools are integrated so that information
created by one tools can be used by another, a
system for the support of SW development, called
CASE (Computer-Aided Software Engineering), is
established

Figure 1.2
SOFTWARE ENGINEERING LAYERS

Figure 1.2
Software engineering layers
 END OF
MODULE 1
SUBMODULE 1

References:
• Pressman, R. S. (2015). Software engineering: a practitioners approach.
New York, NY: McGraw-Hill
• Douglass, B. P. (2016). Agile systems engineering. Waltham, MA: Morgan
Kaufmann.
• Leach, R. J. (2016). Introduction to software engineering. Boca Raton:
Chapman & Hall/CRC.
• Laplante, P. A. (2018). Requirements engineering for software and
systems. Boca Raton: CRC Press.
 END OF
MODULE 1
SUBMODULE 1

References:
• Pressman, R. S. (2015). Software engineering: a practitioners approach.
New York, NY: McGraw-Hill
• Douglass, B. P. (2016). Agile systems engineering. Waltham, MA: Morgan
Kaufmann.
• Leach, R. J. (2016). Introduction to software engineering. Boca Raton:
Chapman & Hall/CRC.
• Laplante, P. A. (2018). Requirements engineering for software and
systems. Boca Raton: CRC Press.
 Part 1
Module 1 Submodule 2
 Module 1
Submodule 2

• The challenges in developing software

• The perspective on quality for software
• Different members of the development team
CHALLENGES IN DEVELOPING SOFTWARE

1. Developing/large/complex software application

CHALLENGES IN DEVELOPING SOFTWARE

2. Effort intensive

This Photo by Unknown Author is licensed under CC BY-

NC-ND
CHALLENGES IN DEVELOPING SOFTWARE

3. High cost (in case the solution is unsuccessful)

This Photo by Unknown Author is licensed under CC BY-NC

This Photo by Unknown

Author is licensed under CC
BY-SA
CHALLENGES IN DEVELOPING SOFTWARE

4. Long development time

This Photo by Unknown Author is licensed under CC BY-

SA-NC

This Photo by Unknown Author is licensed under CC BY-NC-

ND
CHALLENGES IN DEVELOPING SOFTWARE

5. Changing needs for users

This Photo by Unknown Author is licensed under CC BY-SA-NC This Photo by Unknown Author is licensed
under CC BY-SA-NC
CHALLENGES IN DEVELOPING SOFTWARE

6. High risk of failure, reasons of user acceptance,

performance and maintainability

This Photo by Unknown Author is licensed under

CC BY-SA-NC

This Photo by Unknown Author is licensed under CC BY-SA

WHAT IS GOOD SOFTWARE?
PERSPECTIVE ON QUALITY

Dr. David A. Garvin, PhD, a professor of Business

Administration Harvard Business school identified
5 major approaches of defining quality
• The transcendent view
• The product-based view
• The user-based view
• The manufacturing-based view
• The value-based view
 QUALITY: TRANSCENDENT

Transcendent
➢ Quality is an innate excellence (cannot be
defined exactly
➢ Quality is simple, unanalysable recognized only
through experience
 QUALITY: PRODUCT-BASED

Product-Based
➢ Quality is precise, measurable variable in the
components and attributes of a product
➢ Reflects the presence or absence of such
measurable and desired product attributes
 QUALITY: USER-BASED

User-based
➢ Goods that best satisfies user preferences have
the highest quality
 QUALITY: MANUFACTURING
BASED

Manufacturing based
➢ Conformance to requirements
➢ Preventing defects (less expensive than
repair/rework)
➢ Products that follows specification are of high
quality
 QUALITY: VALUE-BASED

Value Based
➢ Provides quality product at an acceptable price
or conformance at an acceptable cost
➢ This approach is becoming the more prevalent
 Part 2
Module 1 Submodule 2
 WHAT IS GOOD SOFTWARE?
• Good software engineering must always include
a strategy for producing quality software
• Three ways of considering quality
– The quality of the product
– The quality of the process
– The quality of the product in the context of
the business environment
 WHAT IS GOOD SOFTWARE?
THE QUALITY OF THE PRODUCT

✓ Users judge external characteristics (e.g., correct functionality,

number of failures, type of failures)
✓ Designers and maintainers judge internal characteristics (e.g.,
types of faults)
✓ Different stakeholders may have different criteria
✓ Need quality models to relate the user’s external view to
developer’s internal view
WHAT IS GOOD SOFTWARE?
THE QUALITY OF THE PRODUCT

• Classic model of software quality factors was suggested by McCall

(McCall et al., 1977)
• McCall’s factors consists of 11 software quality factors
• Similarly models suggested by Deutsch and Willis (1988) and
Evans and Marciniak (1987)
• All these models do not differ substantially from McCall’s model
• McCall factor model provides a practical, up-to-date method for
classifying software requirements (Pressman, 2000).
McCall’s Quality Model

1. Correctness
2. Reliability
3. Efficiency
4. Integrity
5. Usability
6. Maintainability
7. Flexibility
8. Testability
9. Portability
10. Reusability
11. Interoperability
The model was grouped into three categories (product operation
factors, product revision factors, product transition factors)

Correctness
Product
operation factors

Reliability

Efficiency

Maintainability Integrity

Product revision
factors Usability
Flexibility
McCalls Quality
Model

Testability
Portability

Reusability
Product
transition factors
Interoperability

Figure 1.1 McCalls Quality Model

WHAT IS GOOD SOFTWARE? THE
QUALITY OF THE PRODUCT

• These qualities are also subdivided based on the external and

internal qualities
• External quality is the quality of the finished product, the quality
as it appears to the external world, as it comes of the end of the
assembly line. These are factors that are clearly visible to end
users.
• Internal quality is the quality of the product as it is being
constructed, while it is on the assembly line. It is concerned with
internal technical issues of the software
WHAT IS GOOD SOFTWARE? THE
QUALITY OF THE PRODUCT
• In general, users of the software only care about external
qualities, but it is the internal qualities – which deal largely with
the structure of the software – that help developers achieve
external qualities
External quality Integrity
Reliability
Usability
Correctness
Internal quality Efficiency
Maintainability
Testability
Flexibility
Interoperability
Reusability
Portability
Figure 1.2 External and Internal Qualities of Software
What Is Good Software?
The QUALITY OF THE PROCESS

• Quality of the development and maintenance process is as

important as the product quality
• The development process needs to be modeled
• Modeling will address questions such as
– Where to find a particular kind of fault
– How to find faults earlier
– How to build in fault tolerance
– What are alternative activities
What Is Good Software?
The QUALITY OF THE PROCESS

• This is similar to the process called software quality

management (SQM)
• SQM is a management process that aims to develop and
manage the quality of the software in such a way so to best
ensure that the product meets the quality standards expected
by the customer while also meeting any necessary regulatory
and developer requirements is any
What Is Good Software?
The QUALITY OF THE PROCESS

• The following are the Quality management activities that can

ensure the quality of the software

1. Quality assurance
2. Quality planning
3. Quality control
What Is Good Software?
The QUALITY OF THE PROCESS

• The following are the Quality management activities that can

ensure the quality of the software

Quality assurance
– sets up an organized and logical set of organizational
processes and deciding on that software development
standards
– industry best practices paired with those organizational
processes, software developers stand a better chance of
producing higher quality software.
What Is Good Software?
The QUALITY OF THE PROCESS

• The following are the Quality management activities that can

ensure the quality of the software

Quality planning
- Quality planning works at a more granular, project-based level,
- defining the quality attributes to be associated with the output
of the project, and
- how those attributes should be assessed.
What Is Good Software?
The QUALITY OF THE PROCESS

• The following are the Quality management activities that can

ensure the quality of the software

Quality control
- The quality control team tests and reviews software at its
various stages to ensure quality assurance processes and
standards at both the organizational and project level are being
followed.
WHAT IS GOOD SOFTWARE?
THE QUALITY IN THE CONTEXT OF THE
BUSINESS ENVIRONMENT
• Models for process improvement
– SEI’s Capability Maturity Model (CMM)
– ISO 9000
– Software Process Improvement and Capability
dEtermination (SPICE)
WHAT IS GOOD SOFTWARE?
THE QUALITY IN THE CONTEXT OF THE
BUSINESS ENVIRONMENT

✓ Business value is as important as technical value

✓ Business value (in relationship to technical value)
must be quantified
✓ A common approach: return on investment (ROI)
– what is given up for other purposes
✓ ROI is interpreted in different terms: reducing
costs, predicting savings, improving productivity,
and costs (efforts and resources)
 Part 3
Module 1 Submodule 2
REASONS FOR SOFTWARE FAILURE

• schedule slippage (software is not really

time)
• cost overruns ( the software was abandoned
in the middle because of the high costing
requirement)
• does not solve user's problem (not useful)
• poor quality
• poor maintainability
WHAT LEADS TO SUCH PROBLEMS

• No planning of development work

• Deliverables to user not identified
• Poor understanding of user requirement
• No control of review (review and control
systematically ; cost time and resources)
• Technical incompetence (the need to
understand the changes in technologies, new
tools and techniques in recent trends in
technologies )
• Poor understanding of cost and effort both from
user and the developer.
CHALLENGES FACING SOFTWARE
ENGINEERING

• Legacy challenge.
• Heterogeneity challenge.
• Delivery challenge.
WHO DOES SOFTWARE ENGINEERING?

• Customer: the company, organization, or

person who pays for the software system
• Developer: the company, organization, or
person who is building the software system
• User: the person or people who will actually
use the system
Who Does Software Engineering? (cont.)

Participants (stakeholders)
in a software development
project
MEMBERS OF THE DEVELOPMENT TEAM

• Requirement analysts: work with the customers to identify and

document the requirements
• Designers: generate a system-level description of what the system is
suppose to do
• Programmers: write lines of code to implement the design
• Testers: catch faults
• Trainers: show users how to use the system
• Maintenance team: fix faults that show up later
• Librarians: prepare and store documents such as software
requirements
• Configuration management team: maintain correspondence among
various artifacts
MEMBERS OF THE DEVELOPMENT TEAM

Typical roles played by the members of a development

team
 END OF
MODULE 1
SUBMODULE 2

References
• http://www.onquality.info/wp-content/uploads/2010/04/5qualitydef-1.png
• https://www.tutorialspoint.com/software_quality_management/software_quality_management_factors.
htm
• https://resources.saylor.org/wwwresources/archived/site/wp-content/uploads/2012/11/Software-
quality-definitions-and-strategic-issues.pdf
• https://en.wikipedia.org/wiki/Software_quality_management
• https://searchsoftwarequality.techtarget.com/definition/Capability-Maturity-Model
• https://asq.org/quality-resources/iso-9000
• https://en.wikipedia.org/wiki/ISO/IEC_15504
• https://dzone.com/articles/the-challenges-of-legacy-software
• https://codersera.com/blog/challenges-software-developers-face-today/
 INFORMATION AND
SOFTWARE ASSURANCE
AND SECURITY
 MODULE 2
SOFTWARE DESIGN

• Software Architecture types, levels and documentation

• Object modeling terms and concepts, including objects,
attributes, methods, messages, classes, and instances
• Create an Entity Relationship Diagram, Data flow diagram,
Unified Modeling Language, Use Case diagram, Sequence
diagram, and Activity diagram
 MODULE 2
Submodule 1
Concept of Software Architecture

• Software Architecture types, levels and documentation

• Object modeling terms and concepts, including objects,
attributes, methods, messages, classes, and instances
 PART 1
Of Submodule 1 in
Module 2
 SOFTWARE ARCHITECTURE

• Software architecture is commonly used to

describe the organization of software systems.
• An architecture is the definition of the key elements
that constitute a system, their relationships, and
any constraints.
• Generally speaking, architectures of software-
based systems can be classified into several
categories:
 SOFTWARE ARCHITECTURES CATEGORIES:

1. Business architecture
2. Physical architecture
3. Logical architecture
4. Functional architecture
5. Software architecture
6. Technical architecture
7. System architecture
8. Deployment architecture
 SOFTWARE ARCHITECTURES CATEGORIES:

1. Business architecture
- describes the structure of the business tasks performed
by the organization
- these are created by business analysts
 SOFTWARE ARCHITECTURES CATEGORIES:

2. Physical architecture
- describes the structure of the hardware platform(s) or
network(s) on which the system will operate
- physical architecture of a system
 SOFTWARE ARCHITECTURES CATEGORIES:

3. Logical architecture
- describes the structure of the business and application objects.
- Is often part of an object-oriented view of a system.
- Is often created by an object analyst
 SOFTWARE ARCHITECTURES CATEGORIES:

4. Functional architecture
- describes the structure of the potential use cases and the
requirements from a user’s point of view.
- Is often part of an object-oriented view of a system
 SOFTWARE ARCHITECTURES CATEGORIES:

5. Software architecture
- describe the structure of the system into layers, such as
OSI (Open systems interconnection) or layered
architecture of UNIX operating system.
- decomposed to client and server
 SOFTWARE ARCHITECTURES CATEGORIES:

6. Technical architecture
- describes the structure of the major interfaces in the software
architecture.
- Elements include
1. application programming interfaces (APIs),
2. middleware,
3. database management systems,
4. graphical user interfaces, and
5. other glueware or bridgeware needed to interface
components
 SOFTWARE ARCHITECTURES CATEGORIES:

6. Technical architecture
- Decisions to use CORBA, DCOM, Java RMI, or
RPC or even cloud computing, with a protocol such
as HTTP, SOAP, REST, or JSON, would be
reflected in this type of system architecture
 SOFTWARE ARCHITECTURES CATEGORIES:

7. System architecture
- describes the structure of the business, application, and
technical objects and their relationships.
- the description is often created by a systems analysts
 SOFTWARE ARCHITECTURES CATEGORIES:

8. Deployment architecture
- describes the structure of the mapping of the system and
technical architectures onto the physical architecture.
- It includes two views:
1. a static view of the basic files that will be necessary
2. a dynamic view of the concurrent processes and threads,
and the mechanisms for their synchronization and communication.
 SOFTWARE ARCHITECTURES CATEGORIES:

8. Deployment architecture
- a thread on a particular computer or to have an autonomous
agent performing computation would be reflected in this type of
architecture
 SOFTWARE ARCHITECTURE IMPORTANCE

• Software architecture are an enabler for

communication between stakeholders
• The architecture highlights early design
decisions that will have a profound impact on
all software engineering work that follows
 ARCHITECTURAL DESIGN
• The software must be placed into context
• The design should define the external entities (other systems,
devices, people) that the software interacts with and the nature of
the interaction
• A set of architectural archetypes should be identified
• An archetype is an abstraction (similar to a class) that represents
one element of system behavior
• The designer specifies the structure of the system by defining and
refining software components that implement each archetype
 DATA DESIGN (Data modeling concepts)

At the architectural level …

• Design databases to support the application
architecture
• Design of methods for ‘mining’ the content of
multiple databases
• Navigate through existing databases to extract
information.
• Design of a data warehouse
 ENTITY RELATIONSHIP DIAGRAM

• Entity-relationship diagram (ERD) represents all

data objects entered, stored, transformed, and
produced within an application
 ENTITY OR ENTITY TYPES
• An ERD is consists of entities or data objects, data attributes
and relationships with the entities.

• An entity or an entity type or a data object is a representation

of something that has several different properties (attributes)
that must be understood by software. It is anything that produce
or consumes information
 ENTITY OR ENTITY TYPES
Entities:
• Entity instance–person, place, object, event, concept
(often corresponds to a row in a table)
• Entity Type–collection of entities (often corresponds to
a table)
 ENTITY OR ENTITY TYPES
Example of entity or entity types
- A person or a car
- both can have different properties or attributes

Attribute–property or characteristic of an entity or relationship type (often

corresponds to a field in a table)

Figure 2.1
Example of an entity
 RELATIONSHIPS
Entities are connected to one another in different ways.

Example:
- A person and a car

Figure 2.2a A basic connection between data and objects

Figure 2.2b Relationships between data objects
 RELATIONSHIPS

Relationships:
• Relationship instance–link between entities (corresponds to
primary key-foreign key equivalencies in related tables)
• Relationship type–category of relationship…link between entity
types
a) Relationship type
(Completes)

b) Relationship
instances

Figure 2.3
Illustration of relationship types and relationship instances
 PART 2
Of Submodule 1 in
Module 2
 RELATIONSHIPS

• Relationships can have attributes

• Two entities can have more than one type of
relationship between them (multiple
relationships)
• Associative Entity–combination of relationship
and entity
 RELATIONSHIPS
One-to-One (1:1)
• Each entity in the relationship will have exactly one related entity
One-to-Many (1:M) or Many-to-One (M:1)
• An entity on one side of the relationship can have many related entities, but
an entity on the other side will have a maximum of one related entity
Many-to-Many (M:M)
• Entities on both sides of the relationship can have many related entities on
the other side
RELATIONSHIPS (one to many)

A patient history is A patient must have recorded

recorded for one and only at least one history, and can
one patient have many

Figure 2.4
ERD: one to many relationship
RELATIONSHIPS (many to many)

A project must be assigned to at An employee can be assigned to

least one employee, and may be any number of projects, or may not
assigned to many be assigned to any at all

Figure 2.5
ERD: many to many relationship
 RELATIONSHIPS (one to one)

A person is
married to at most
one other person,
or may not be
married at all

Figure 2.6
ERD: one to one relationship
 RELATIONSHIPS
Degree of a relationship is the number of entity types that participate
in it

• Unary Relationship
• Binary Relationship
• Ternary Relationship
 RELATIONSHIPS(Unary)

Entities of
One entity two
related to different Entities of three
another of different types
types related related to each
the same to each other
entity type other

Figure 2.7
ERD: Unary relationship
RELATIONSHIPS(Binary)

Figure 2.8
ERD: Unary relationship
RELATIONSHIPS(Ternary)

Figure 2.9
ERD: Unary relationship
 STRUCTURED DESIGN
A mapping technique, called structured design is often characterized
as a data flow-oriented design method because it provides a
convenient transition from a data flow diagram to software
architecture.
• The transition from information flow (represented as a DFD) to
program structure is accomplished as part of a six step process.
 STRUCTURED DESIGN
These six step processes are:
(1) the type of information flow is established,
(2) flow boundaries are indicated,
(3) the DFD is mapped into the program structure,
(4) control hierarchy is defined,
(5) the resultant structure is refined using design measures and
heuristics, and
(6) the architectural description is refined and elaborated.
 DATA FLOW DIAGRAM

• A data flow diagram (DFD) is a graphical

representation of the "flow" of data through an
information modeling its process aspects.
• A DFD shows what kinds of information will be input
to and output from the system, where the data will
come from and go to, and where the data will be
stored.
 DATA FLOW DIAGRAM

• The DFD takes an input-process-output

view of a system. Data objects are
represented by labeled arrows, and
• Transformations are represented by
circles (also called bubbles).
 DATA FLOW DIAGRAM

• The DFD is presented in a hierarchical

fashion.
• Subsequent data flow diagrams refine the
context diagram, providing increasing detail
with each subsequent level.
DFD SYMBOLS

Figure 2.10
Data flow diagram symbols
 CREATING A SET OF DFD
Here are simple guidelines
(1) the level 0 data flow diagram should depict the software/system as a
single bubble;
(2) primary input and output should be carefully noted;
(3) Refinement should begin by isolating candidate processes, data
objects, and data stores to be represented at the next level;
(4) all arrows and bubbles should be labeled with meaningful names;
(5) information flow continuity must be maintained from level to level, and
(6) one bubble at a time should be refined
 Before we proceed to diagram 0, lets discussed what
SafeHome does.

• 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.
 Before we proceed to diagram 0, lets discussed what
SafeHome does.

• 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.
 Before we proceed to diagram 0, lets discussed what
SafeHome does.

• 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 . . .
EXAMPLE:
SAFEHOME SECURITY FUNCTION
Diagram 0

Figure 2.11
DFD: Diagram 0

Nouns are either external entities (boxes), data or control objects (arrows), or data stores (double lines).
EXAMPLE:SAFEHOME SECURITY
FUNCTION Diagram 1

Figure 2.12
DFD: Diagram 1
EXAMPLE:
SAFEHOME SECURITY FUNCTION
Diagram 2

Figure 2.13
DFD: Diagram 2
 END OF
MODULE 2
SUBMODULE 1

References:
• Pressman, R. S. (2015). Software engineering: a practitioners approach.
New York, NY: McGraw-Hill
• Douglass, B. P. (2016). Agile systems engineering. Waltham, MA: Morgan
Kaufmann.
• Leach, R. J. (2016). Introduction to software engineering. Boca Raton:
Chapman & Hall/CRC.
• Laplante, P. A. (2018). Requirements engineering for software and
systems. Boca Raton: CRC Press.
 MODULE 2
Submodule 2
Software Design Tools

• Unified Modeling Language

• Use Case diagram
• Sequence diagram
• Activity diagram
 Part 1
Module 2 Submodule 2
UNIFIED MODELING LANGUAGE
 UNIFIED MODELING LANGUAGE
• Unified Modeling Language (UML) is “ a standard language for
writing blueprints. UML may be used to visualize, specify,
construct, and document the artifacts of a software-intensive
system”
 Just as building architects create blueprints
 Software architects create UML diagrams
 UNIFIED MODELING LANGUAGE
Two main types of diagrams in the UML
1. Structural Diagram are used to describe the relationship
between classes.
2. Behavioral Diagram can be used to describe the interaction
between people and the thing we refer to as a use case, or how
the actors use the system.
 UNIFIED MODELING LANGUAGE
 It all begins with the construction of a model.
 A model is an abstraction of the underlying problem. The domain is the
actual world from which the problem comes.
 Models consist of objects that interact by sending each other messages.
Think of an object as "alive." Objects have things they know (attributes)
and things they can do (behaviors or operations). The values of an
object's attributes determine its state.
 Classes are the "blueprints" for objects. A class wraps attributes (data)
and behaviors (methods or functions) into a single distinct entity. Objects
are instances of classes.
OBJECTS CONCEPTS

Figure 2.14
Example of an object Parent
OBJECTS CONCEPTS

Figure 2.15
Example of an object Child
OBJECT CONCEPTS AND TERMS

Figure 2.16 Student object and Instructor object

Attributes
• If objects are similar to nouns, attributes are similar
to adjectives that describe the characteristics of an
object
• Some objects might have a few attributes; others
might have dozens state
Methods

• A method defines specific tasks that an object

can perform
• Just as objects are similar to nouns and
attributes are similar to adjectives, methods
resemble verbs that describe what and how an
object does something
USE CASE
 USE CASE DIAGRAM
• Use case diagrams describe what a system does from
the standpoint of an external observer. The emphasis is on
what a system does rather than how.
• Use case diagrams are closely connected to scenarios. A
scenario is an example of what happens when someone
interacts with the system. Here is a scenario for a
managing user digital files.
 USE CASE DIAGRAM EXAMPLE
• Let us say, there is a software application for managing digital music files,
similar to Apple’s iTunes software.
• Some of the things the software might do include:
✓ Download an MP3 music file and store it in the application’s library.
✓ Capture streaming music and store it in the application’s library.
✓ Manage the application’s library (e.g., delete songs or organize them in
playlists).
✓ Burn a list of the songs in the library onto a CD.
✓ Load a list of the songs in the library onto an iPod or MP3 player.
✓ Convert a song from MP3 format to AAC format and vice versa.
 USE CASE DIAGRAM EXAMPLE
• A use case describes how a user interacts with the
system by defining the steps required to accomplish a
specific goal (e.g., burning a list of songs onto a CD).
• A use case provides a big picture of the functionality of
the system.
USE CASE DIAGRAM EXAMPLE

Figure 2.17
Example of Use case diagram
USE CASE DIAGRAM EXAMPLE

Figure 2.18
A use case representing
duplicated activity
SEQUENCE DIAGRAM
 SEQUENCE DIAGRAM
• A sequence diagram is used to show the dynamic
communications between objects during execution of a task. It
shows the temporal order in which messages are sent between
the objects to accomplish that task.
• Sequence diagrams can be used to show the interactions in one
use case or in one scenario of the software system.
SEQUENCE DIAGRAM

Figure 2.19
Example of sequence diagram of a drawing program
 SEQUENCE DIAGRAM

Figure 2.20
Example of sequence diagram of a drawing program with loops
 Part 2
Module 2 Submodule 2
SEQUENCE DIAGRAM

Figure 2.21
Special features included in a sequence diagram
SEQUENCE DIAGRAM: another example

Figure 2.22
Another example of sequence diagram
ACTIVITY DIAGRAM
 ACTIVITY DIAGRAM
• A UML activity diagram depicts the dynamic behavior of a
system or part of a system through the flow of control between
actions that the system performs.
• It is like a flowchart except that an activity diagram can show
concurrent flows.
 ACTIVITY DIAGRAM
• Components:
- action node (rounded rectangle) – tasked performed
by the software system
- flow of control (arrows) – arrow between two action
nodes indicate that the first node will be performed
following the second node
- initial node (solid black dot) – starting point
 ACTIVITY DIAGRAM
- final node (a black dot surrounded by a black circle) –
end of activity
- separation of activities (fork) – consists of one arrow
pointing to it and two or more arrows pointing out
 ACTIVITY DIAGRAM
- synchronization of concurrent flow of control (join) –
a horizontal black bar with two or more incoming arrows
and one outgoing arrow
- decision node (diamond with incoming arrow and two
or more outgoing arrows) – corresponds to a branch in
the flow control based on a condition. Each outgoing
arrow is labeled with a guard (a condition inside square
brackets)
ACTIVITY DIAGRAM

Figure 2.23
Example of an activity diagram
 ACTIVITY DIAGRAM
• Often, the exact division of labor does not matter. But if you do
want to indicate how the actions are divided among the
participants, you can decorate the activity diagram with
swimlanes.
• Swimlanes, as the name implies, are formed by dividing the
diagram into strips or “lanes,” each of which corresponds to one
of the participants.
ACTIVITY DIAGRAM

Figure 2.24
Example of an activity diagram
with swimlanes
 ACTIVITY DIAGRAM
An Activity Diagram resembles a horizontal flowchart that shows the actions
and events as they occur. Activity diagrams show the order in which the
actions take place and identify the outcomes.
Diagram Purpose
• Activity Diagram is typically used for modeling the logic captured in a
specific use case in a use case diagram. Activity diagram can also be
used to model a specific Actor's workflow within the entire system. Activity
diagram can also be used independent of use cases for other purposes
such as to model business process of a system, to model detailed logic of
business rules etc. Activity diagram shows all potential sequence flows in
an activity.
ACTIVITY DIAGRAM EXAMPLE

Figure 2.25
Another example of an activity diagram
 END OF
MODULE 2
SUBMODULE 2

References:
• Pressman, R. S. (2015). Software engineering: a practitioners approach.
New York, NY: McGraw-Hill
• Douglass, B. P. (2016). Agile systems engineering. Waltham, MA: Morgan
Kaufmann.
• Leach, R. J. (2016). Introduction to software engineering. Boca Raton:
Chapman & Hall/CRC.
• Laplante, P. A. (2018). Requirements engineering for software and
systems. Boca Raton: CRC Press.