CMT 311 -

FUNDAMENTALS OF
SOFTWARE
ENGINEERING
Module 3: Software Modeling
Learning Objectives
• Software Design
• Software Design Notation
• Software Design Concept
• Software Design Strategy/Approaches
• Two Approaches for Analysis & Design
• Data Flow Diagram (DFD) created using Structured Analysis Technique
• Structure Charts - Invocation / Call
• OOAD methods Three major steps

Module 3: Software Modeling 2

• Software Modeling and Design - ppt download (slideplayer.com)

• MOD 5 Software design | PPT (slideshare.net)

Module 3: Software Modeling 3

What is Architectural Modeling?
• Recall that we have characterized architecture as the set of principal design decisions
made about a system
• We can define models and modeling in those terms
• An architectural model is an artifact that captures some or all of the design decisions
that comprise a system’s architecture
• Architectural modeling is the reification and documentation of those design
decisions
• How we model is strongly influenced by the notations we choose:
• An architectural modeling notation is a language or means of capturing design
decisions.

4
How do We Choose What to Model?
• Architects and other stakeholders must make critical
decisions:
1. What architectural decisions and concepts should be
modeled,
2. At what level of detail, and
3. With how much rigor or formality
– These are cost/benefit decisions
• The benefits of creating and maintaining an architectural
model must exceed the cost of doing so

5
Stakeholder-Driven Modeling

• Stakeholders identify
aspects of the system they
are concerned about
• Stakeholders decide the
relative importance of these
concerns
• Modeling depth should
roughly mirror the relative
importance of concerns

From Maier and Rechtin, “The Art of Systems Architecting” (2000)

6
Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
What do We Model?
• Basic architectural elements
• Components
• Connectors
• Interfaces
• Configurations
• Rationale – reasoning behind decisions

7
Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
What do We Model? (cont’d)
• Elements of the architectural style
• Inclusion of specific basic elements (e.g., components, connectors, interfaces)
• Component, connector, and interface types
• Constraints on interactions
• Behavioral constraints
• Concurrency constraints
• …

8
What do We Model? (cont’d)
• Static and Dynamic Aspects
• Static aspects of a system do not change as a system
runs
• e.g., topologies, assignment of components/connectors to
hosts, …
• Dynamic aspects do change as a system runs
• e.g., state of individual components or connectors, state of a
data flow through a system, …

9
What do We Model? (cont’d)
• Functional and non-functional aspects of a system
• Functional
• “The system prints medical records”
• Non-functional
• “The system prints medical records quickly and confidentially.”
• Architectural models tend to be functional
• It is often important to capture non-functional decisions
• Even if they cannot be automatically or deterministically interpreted or
analyzed

10
Important Characteristics of Models
• Ambiguity
• A model is ambiguous if it is open to more than one interpretation
• Accuracy and Precision
• Different, but often conflated concepts
• A model is accurate if it is correct, conforms to fact, or deviates from correctness within
acceptable limits
• A model is precise if it is sharply exact or delimited

11
Software Design Components
• Principle
• Criteria (this lecture)
• Techniques (this lecture)

Module 3: Software Modeling 12

Range of Cohesion High Cohesion Coincidental Low Functional
Sequential

• Communicational
• Procedural
• Temporal
• Logical
• Coincidental
• Low

Module 3: Software Modeling 13

Sequential Cohesion
• The output of one component is the input to another.
• Occurs naturally in functional programming languages
• Good situation

Module 3: Software Modeling 14

Example Retrieve customer
Data Retrieve customer order

• Generate invoice
• Get and edit input data.

Module 3: Software Modeling 15

Functional Cohesion – Highly cohesive

• Definition: Every essential element to a single computation is

contained in the component.
• A functionally cohesive module performs one and only one problem
related task.
• Ideal situation.

Module 3: Software Modeling 16

Examples Calculate Net Pay

• A complex module with numerous sub modules may still be

functionally cohesive if all of its subordinate modules are only
performed to carry out the task of the parent module.
• For example, Calculate Net Pay is functionally cohesive although it
contains many different functions (e.g., calculate taxable deductions,
calculate tax, calculate CPP deduction).

Module 3: Software Modeling 17

 Scale of Cohesion Vs Maintainability
• General Rule of Cohesion

• A module will be cohesive if most of the methods defined in a class use most of the data
members most of the time.
• If we find different subsets of data within the same module being manipulated by separate
groups of functions then the module is not cohesive and should be broken down as shown
below.
i. Extensibility:- Extendibility is the ease of adapting software products to changes of
specification.
ii. Extensibility:- For small programs change is usually not a difficult issue; but as software
grows bigger, it becomes harder and harder to adapt. A large software system often looks
to its maintainers as a giant house of cards in which pulling out any one element might
cause the whole structure to collapse

Module 3: Software Modeling 18

iii. Extensibility:- We need extendibility because at the basis of all
software lies some human phenomenon and hence indecisiveness

Module 3: Software Modeling 19

Principles for achieving Extensibility

• Design simplicity: a simple architecture will always be easier to adapt

to changes than a complex one
• Decentralization: the more autonomous the modules, the higher the
likelihood that a simple change will affect just one module, or a small
number of modules, rather than triggering off a chain reaction of
changes over the whole system.

Module 3: Software Modeling 20

Problem Statement
• In the electric subsystem of the house where there are electric wires
and appliances running.
• Each appliance is having it’s own functionality and working.
• Each appliance is having it’s own clear boundary into which it works.
• Task is to identify level of coupling and cohesion in the scenario.
• Write a scenario which should reverse the solution

Module 3: Software Modeling 21

Solution to example
• The given scenario is having no interdependency and each appliance
is encapsulated within its own boundary so the system is having low
or no coupling but high level of cohesion.
• Hint for Task ii: “Central”

Module 3: Software Modeling 22

Open / Close Principle
• Bertrand Meyer:- “Software entities like classes, modules and
functions should be closed but open for extension.
• Closed:- The source code of the module inviolate; no one is allowed
to make changes to the code the module can be used without risk

Module 3: Software Modeling 23

Open / Close Principle Open
• The module is open for extension according to new requirements the
module can be extended to behave in new and different ways.

Module 3: Software Modeling 24

Open / Closed Principle

• A module that is open for extension is a module whose behavior can

be altered to suit new requirements.
• A module that is closed for modification is a module whose source
code is frozen and cannot be changed.

Module 3: Software Modeling 25

The “Open/Closed principle” – Usage in an object oriented
paradigm

• The Open/Closed principle can be applied in object oriented

paradigms with the help of inheritance and polymorphism:
• The interface of the module becomes an abstract class A
• If needed new Subclasses of A can be derived; these subclasses may
extend A

Module 3: Software Modeling 26

Software Design Notation
• Design notations are used when planning and should be able to
communicate the purpose of a program without the need for formal
code.
• Commonly used design notations are:
i. flow charts
ii. structure diagrams

Module 3: Software Modeling 27

• During the design phase there are two things of interest:
i. the design of the system
ii. the producing of which is the basic objective of this phase, and
iii. the process of designing itself
• It is for the latter that principles and methods are needed.
• In addition, while designing, a designer needs to record his thoughts
and decisions and to represent the design so that he can view it and
play with it.
• For this, design notations are used.

Module 3: Software Modeling 28

• Design notations are largely meant to be used during the process of
design and are used to represent design or design decisions.
• They are meant largely for the designer so that he can quickly represent
his decisions in a compact manner that he can evaluate and modify.
• These notations are frequently graphical.
• Once the designer is satisfied with the design he has produced, the
design is to be precisely specified in the form of a document.
• Whereas a design represented using the design notation is largely to be
used by the designer, a design specification has to be so precise and
complete that it can be used as a basis of further development by other
programmers.
• Often, design specification uses textual structures, with design notation
helping understanding.
Module 3: Software Modeling 29
Structure Chart
• Structure Chart represents the hierarchical structure of modules.
• It breaks down the entire system into the lowest functional modules
and describes the functions and sub-functions of each module of a
system in greater detail.

Module 3: Software Modeling 30

What is a Structure Chart?
• Structure Chart partitions the system into black boxes (functionality of
the system is known to the users, but inner details are unknown).
i. Inputs are given to the black boxes and appropriate outputs are
generated.
ii. Modules at the top level are called modules at low level.
iii. Components are read from top to bottom and left to right.
iv. When a module calls another, it views the called module as a black
box, passing the required parameters and receiving results.

Module 3: Software Modeling 31

Symbols in Structured Chart
1. Module
• It represents the process or task of the system. It is of three types:
i. Control Module: A control module branches to more than one
submodule.
ii. Sub Module: Sub Module is a module which is the part (Child) of
another module.
iii. Library Module: Library Module are reusable and invokable from
any module.

Module 3: Software Modeling 32

Module 3: Software Modeling 33
2. Conditional Call

• It represents that control module can select any of the sub module on
the basis of some condition.

Module 3: Software Modeling 34

3. Loop (Repetitive call of module)
• It represents the repetitive execution of module by the sub module.
• A curved arrow represents a loop in the module.

All the submodules cover by the loop repeat

execution of module.

Module 3: Software Modeling 35

4. Data Flow
• It represents the flow of data between the modules.
• It is represented by a directed arrow with an empty circle at the end.

Module 3: Software Modeling 36

4. Data Flow
• It represents the flow of data between the modules.
• It is represented by a directed arrow with an empty circle at the end.

Module 3: Software Modeling 37

5. Control Flow
• It represents the flow of control between the modules.
• It is represented by a directed arrow with a filled circle at the end.

Module 3: Software Modeling 38

6. Physical Storage
• It is that where all the information are to be stored.

Module 3: Software Modeling 39

Example
• Structure chart for an Email server

Module 3: Software Modeling 40

Types of Structure Chart
i. Transform Centered Structure: These type of structure chart are
designed for the systems that receives an input which is
transformed by a sequence of operations being carried out by one
module.
ii. Transaction Centered Structure: These structure describes a
system that processes a number of different types of transaction.

Module 3: Software Modeling 41

 Software Design Strategy
• It involves designing interfaces, data structures, and modules that meet the
system's requirements.
• A well-thought-out system design strategy is vital for successful product
development.
• It provides a roadmap to handle the complexity and scalability of the
program effectively.
• Software design is a process to conceptualize the software requirements into
software implementation.
• Software design takes the user requirements as challenges and tries to find
optimum solution.
• While the software is being conceptualized, a plan is chalked out to find the
best possible design for implementing the intended solution.
Module 3: Software Modeling 42
• There are multiple variants of software design.
i. Structured Design
• Structured design is a conceptualization of problem into several well-
organized elements of solution.
• It is basically concerned with the solution design.
• Benefit of structured design is, it gives better understanding of how the
problem is being solved.
• Structured design also makes it simpler for designer to concentrate on the
problem more accurately.
• Structured design is mostly based on ‘divide and conquer’ strategy where a
problem is broken into several small problems and each small problem is
individually solved until the whole problem is solved.

Module 3: Software Modeling 43

• The small pieces of problem are solved by means of solution modules.
• Structured design emphasis that these modules be well organized in
order to achieve precise solution.
• These modules are arranged in hierarchy.
• They communicate with each other.
• A good structured design always follows some rules for communication
among multiple modules, namely -
i. Cohesion - grouping of all functionally related elements.
ii. Coupling - communication between different modules.
• A good structured design has high cohesion and low coupling
arrangements.

Module 3: Software Modeling 44

 ii. Function Oriented Design
• In function-oriented design, the system is comprised of many smaller sub-
systems known as functions.
• These functions are capable of performing significant task in the system.
• The system is considered as top view of all functions.
• Function oriented design inherits some properties of structured design
where divide and conquer methodology is used.
• This design mechanism divides the whole system into smaller functions,
which provides means of abstraction by concealing the information and
their operation.
• These functional modules can share information among themselves by
means of information passing and using information available globally.
Module 3: Software Modeling 45
• Another characteristic of functions is that when a program calls a function,
the function changes the state of the program, which sometimes is not
acceptable by other modules.
• Function oriented design works well where the system state does not matter
and program/functions work on input rather than on a state.

Module 3: Software Modeling 46

Design Process
• The whole system is seen as how data flows in the system by means
of data flow diagram.
• DFD depicts how functions changes data and state of entire system.
• The entire system is logically broken down into smaller units known as
functions on the basis of their operation in the system.
• Each function is then described at large.

Module 3: Software Modeling 47

Object Oriented Design
• Object oriented design works around the entities and their
characteristics instead of functions involved in the software system.
• This design strategies focuses on entities and its characteristics.
• The whole concept of software solution revolves around the engaged
entities.

Module 3: Software Modeling 48

 Important concepts of Object Oriented
Design:
i. Objects - All entities involved in the solution design are known as objects. For
example, person, banks, company and customers are treated as objects. Every
entity has some attributes associated to it and has some methods to perform on
the attributes.
ii. Classes - A class is a generalized description of an object. An object is an instance
of a class. Class defines all the attributes, which an object can have and methods,
which defines the functionality of the object.
• In the solution design, attributes are stored as variables and functionalities are
defined by means of methods or procedures.
iii. Encapsulation - In OOD, the attributes (data variables) and methods (operation
on the data) are bundled together is called encapsulation. Encapsulation not only
bundles important information of an object together, but also restricts access of the
Module 3: Software Modeling 49
data and methods from the outside world. This is called information hiding.
iv. Inheritance - OOD allows similar classes to stack up in hierarchical
manner where the lower or sub-classes can import, implement and re-
use allowed variables and methods from their immediate super classes.
This property of OOD is known as inheritance. This makes it easier to
define specific class and to create generalized classes from specific
ones.
v. Polymorphism - OOD languages provide a mechanism where
methods performing similar tasks but vary in arguments, can be
assigned same name. This is called polymorphism, which allows a single
interface performing tasks for different types. Depending upon how the
function is invoked, respective portion of the code gets executed.

Module 3: Software Modeling 50

Design Process
• Software design process can be perceived as series of well-defined
steps.
• Though it varies according to design approach (function oriented or
object oriented, yet It may have the following steps involved:
i. A solution design is created from requirement or previous used
system and/or system sequence diagram.
ii. Objects are identified and grouped into classes on behalf of
similarity in attribute characteristics.
iii. Class hierarchy and relation among them is defined.
iv. Application framework is defined.
Module 3: Software Modeling 51
 Software Design Approaches
• Here are two generic approaches for software designing:
i. Top Down Design
• We know that a system is composed of more than one sub-systems and it
contains a number of components.
• Further, these sub-systems and components may have their on set of sub-
system and components and creates hierarchical structure in the system.
• Top-down design takes the whole software system as one entity and then
decomposes it to achieve more than one sub-system or component based on
some characteristics.
• Each sub-system or component is then treated as a system and decomposed
further.
• This process keeps on running until the lowest level of system in the top-down
hierarchy is achieved. Module 3: Software Modeling 52
• Top-down design starts with a generalized model of system and keeps
on defining the more specific part of it.
• When all components are composed the whole system comes into
existence.
• Top-down design is more suitable when the software solution needs
to be designed from scratch and specific details are unknown.

Module 3: Software Modeling 53

 ii. Bottom-up Design
• The bottom up design model starts with most specific and basic
components.
• It proceeds with composing higher level of components by using basic or
lower level components.
• It keeps creating higher level components until the desired system is not
evolved as one single component.
• With each higher level, the amount of abstraction is increased.
• Bottom-up strategy is more suitable when a system needs to be created
from some existing system, where the basic primitives can be used in the
newer system.
• Both, top-down and bottom-up approaches are not practical individually.
Instead, a good combination ofModule
both is used.
3: Software Modeling 54
Two Approaches for Analysis & Design
• There are two main approaches to software analysis and design,
namely:
i. Function-Oriented Approach and
ii. Object-Oriented Approach.

Module 3: Software Modeling 55

i. Function-Oriented Approach
• Function Oriented Design is an approach to software design where
the design is decomposed into a set of interacting units where each
unit has a clearly defined function.
• Design Notations are primarily meant to be used during the process
of design and are used to represent design or design decisions.
• For a function-oriented design, the design can be represented
graphically or mathematically by the following:

Module 3: Software Modeling 56

Module 3: Software Modeling 57
ii. Object-Oriented Approach

• An object can be defined as a data field that has unique attributes and
behavior.
• OOP focuses on the objects that developers want to manipulate
rather than the logic required to manipulate them.
• This approach to programming is well-suited for programs that are
large, complex and actively updated or maintained.
• The main aim of Object Oriented Design (OOD) is to improve the
quality and productivity of system analysis and design by making it
more usable.

Module 3: Software Modeling 58

• Object-oriented programming (OOP) is a fundamental programming
paradigm used by nearly every developer at some point in their
career.
• OOP is the most popular programming paradigm used for software
development and is taught as the standard way to code for most of a
programmer’s educational career.
• Another popular programming paradigm is functional programming.

Module 3: Software Modeling 59

Benefits of OOP for software engineering
i. OOP models complex things as reproducible, simple structures
ii.Reusable, OOP objects can be used across programs
iii.
Polymorphism allows for class-specific behavior
iv.Easier to debug, classes often contain all applicable information to
them
v. Securely protects sensitive information through encapsulation

Module 3: Software Modeling 60

Building blocks of OOP

i. Classes
ii. Objects
iii. Methods
iv. Attributes

Module 3: Software Modeling 61

Data Flow Diagram (DFD) created using
Structured Analysis Technique
• A Data-Flow Diagram (DFD) is a graphical visualization of the
movement of data through an information system.
• DFDs are one of the three essential components of the structured-
systems analysis and design method (SSADM).
• A DFD is process centric and depicts 4 main components.
• All data flow diagrams include four main elements:
i. Entity
ii. Process
iii. data store and
iv. data flow. Module 3: Software Modeling 62
• External Entity – Also known as actors, sources or sinks, and
terminators, external entities produce and consume data that flows
between the entity and the system being diagrammed.
• Data flow diagrams are used to graphically represent the flow of data
in a business information system.
• DFD describes the processes that are involved in a system to transfer
data from the input to the file storage and reports generation.

Module 3: Software Modeling 63

 Why DFD?
• DFD graphically representing the functions, or processes, which capture,
manipulate, store, and distribute data between a system and its
environment and between components of a system.
• The visual representation makes it a good communication tool between User
and System designer.
• Structure of DFD allows starting from a broad overview and expand it to a
hierarchy of detailed diagrams.
• DFD has often been used due to the following reasons:
i. Logical information flow of the system
ii. Determination of physical system construction requirements
iii. Simplicity of notation
iv. Establishment of manual and Module
automated systems requirements
3: Software Modeling 64
 Structured Analysis Technique
• Structured analysis is a process-oriented approach.
• The technique is simple in concept: the analyst defines what the system
should do before deciding how it should do it.
• The new systems specification evolves from a series of data flow
diagrams.
• Structured systems analysis is a specific technique for systems
analysis that covers all activities from initial understanding of the
problem through to specification and high-level design of the software
system.
• The technique embodies four main concepts: dataflow diagrams, a data
dictionary, data store structuring, and process logic representations.
Module 3: Software Modeling 65
 Structure Charts - Invocation / Call
• A structure chart represents the software architecture, i.e. the various
modules making up the system, the dependency (which module calls which
other modules), and the parameters that are passed among the different
modules.
• Hence, the structure chart representation can be easily implemented using
some programming language.
• Since the main focus in a structure chart representation is on the module
structure of the software and the interactions among different modules, the
procedural aspects (e.g. how a particular functionality is achieved) are not
represented.

Module 3: Software Modeling 66

• The basic building blocks which are used to design structure charts
are the following:
i. Rectangular boxes: Represents a module.
ii. Module invocation arrows: Control is passed from one module to
another module in the direction of the connecting arrow.
iii. Data flow arrows: Arrows are annotated with data name; named
data passes from one module to another module in the direction of
the arrow.
iv. Library modules: Represented by a rectangle with double edges.
v. Selection: Represented by a diamond symbol.
vi. Repetition: Represented by a loop around the control flow arrow.

Module 3: Software Modeling 67

OOAD methods Three major steps
• We know that the Object-Oriented Modelling (OOM) technique
visualizes things in an application by using models organized around
objects.
• Any software development approach goes through the following
stages −
i. Analysis,
ii. Design, and
iii. Implementation.

Module 3: Software Modeling 68

• In object-oriented software engineering, the software developer
identifies and organizes the application in terms of object-oriented
concepts, prior to their final representation in any specific
programming language or software tools.

Module 3: Software Modeling 69

Phases in Object-Oriented Software
Development
• The major phases of software development using object–oriented
methodology are object-oriented analysis, object-oriented design, and
object-oriented implementation.
i. Object–Oriented Analysis
• In this stage, the problem is formulated, user requirements are identified,
and then a model is built based upon real–world objects.
• The analysis produces models on how the desired system should function
and how it must be developed.
• The models do not include any implementation details so that it can be
understood and examined by any non–technical application expert.

Module 3: Software Modeling 70

ii. Object–Oriented Design
• Object-oriented design includes two main stages, namely, system
design and object design.

Module 3: Software Modeling 71

System Design
• In this stage, the complete architecture of the desired system is
designed.
• The system is conceived as a set of interacting subsystems that in turn
is composed of a hierarchy of interacting objects, grouped into
classes.
• System design is done according to both the system analysis model
and the proposed system architecture.
• Here, the emphasis is on the objects comprising the system rather
than the processes in the system.

Module 3: Software Modeling 72

Object Design

• In this phase, a design model is developed based on both the models

developed in the system analysis phase and the architecture designed
in the system design phase.
• All the classes required are identified.
• The designer decides whether −
i. new classes are to be created from scratch,
ii. any existing classes can be used in their original form, or
iii. new classes should be inherited from the existing classes.

Module 3: Software Modeling 73

Object–Oriented Implementation and Testing

• In this stage, the design model developed in the object design is

translated into code in an appropriate programming language or
software tool.
• The databases are created and the specific hardware requirements
are ascertained.
• Once the code is in shape, it is tested using specialized techniques to
identify and remove the errors in the code.

Module 3: Software Modeling 74

***END***

Module 3: Software Modeling 75