SOFTWARE DESIGN

Lecturer Dr: Reem Razzaq

Class 3
Time:
Department: Businesses Information Technology (BIT) 1
 Outline

 Software Design
 Software Design Patterns
 Introduction To Software Design Representations
 Software Design Approaches
 Software Architectures

2
“Introduction to Software Engineering”, Second Edition
 Outline
Software Design

 Software design (SDsn.): is a process to conceptualize the

software requirements into software implementation.
 SDsn. takes the user requirements as challenges and tries to
find optimum solution and the best possible design for
implementing the intended solution.
 The requirement specifications are human readable and
understandable documents, to which a computer has nothing to
do.
 SDsn. is the intermediate stage between human-readable
requirements and actual code.

3
“Introduction to Software Engineering”, Second Edition
 SoftwareOutline
Design Patterns

 One possible way of designing software is to attempt to match

the problem to be solved with a preexisting software system
that solves the same type of problem.
 This approach reduces at least a portion of the software design
to pattern matching.
 The effectiveness depends upon a set of previously developed
software modules and some way of recognizing different
patterns.
1- Creational patterns: describe human–computer interfaces, like
a menu-driven system and an event-driven system.

4
“Introduction to Software Engineering”, Second Edition
 SoftwareOutline
Design Patterns

2- Structural patterns: are conceptualization of problem into several well-

organized elements of solution.
• 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.
• The small pieces of problem are solved as modules. These modules are
arranged in hierarchy. They communicate with each other.
• A good structured design rules for communication among multiple
modules, they are:
A- Cohesion - grouping of all functionally related elements.
B- Coupling - communication between different modules.
A good structured design has high cohesion and low coupling
arrangements.

5
“Introduction to Software Engineering”, Second Edition
 SoftwareOutline
Design Patterns

3- Behavioral patterns: like OO design, and distributed

system (such as Cloud Computing and Software as a Service
(SaaS) model).

6
“Introduction to Software Engineering”, Second Edition
 Outline
Introduction To Software Design Representations

 There are several ways to describe a software system:

1- The software can be described by the flow of control through the system
like flowchart.
2- The software can be described by the flow of data through the system like
Data Flow Diagram .
3- The software can be described by the actions performed by the system
like UML .
4- The software can be described by the objects that are acted on by the
system like class diagram in an object-oriented system, Entity-
Relationship Model, and pseudocode.

7
“Introduction to Software Engineering”, Second Edition
 Introduction To Software Design
Outline
Representations (Cont.)
Example : A Pseudocode Description of a Hypothetical Computer System
GET login_id as input from keyboard
Compare Input to entries in login_id database
IF not a match THEN
WAIT 10 seconds
SET error_count to 1
REPEAT
PROMPT user for new login_id
IF login_id matches database
THEN PROMPT for password
ELSE increment error_count
WAIT 10 seconds
END IF
IF error_count > 3 EXIT password PROMPT
END REPEAT
ELSE
GET password as input from keyboard
Compare password entries in password databaseSoftware Design ◾ 169
IF error THEN
EXIT
ELSE
BEGIN login process
END IF 8
“Introduction to Software Engineering”, Second Edition
 Outline
Software Design Approaches

Here are two generic approaches for software designing:

1- Top Down Design
• 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.
• Top-down design is more suitable when the software solution needs to be
designed from scratch and specific details are unknown.

9
“Introduction to Software Engineering”, Second Edition
 Outline
Software Design Approaches (Cont.)

2- Bottom-up Design
• this model starts with most specific and basic 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 of both is used.

10
“Introduction to Software Engineering”, Second Edition
 Outline
Software Architectures

Software Architecture: is used to describe the organization of

software systems.
An architecture: is the key elements that constitute a system,
their relationships, and any constraints.
architectures of software-based systems can be classified into
several categories:
1- A business architecture describes the structure of the business
tasks performed by the organization and the mechanisms by
which the system supports these business tasks.

11
“Introduction to Software Engineering”, Second Edition
 Outline
Software Architectures

2- A physical architecture describes the structure of the

hardware platform(s) or network(s) on which the system will
operate. Often, much of the physical architecture of a system is
greatly simplified by the use of a cloud.
3- A logical architecture describes the structure of the business
and application objects. This architecture is often part of an
object-oriented view of a system.

12
“Introduction to Software Engineering”, Second Edition
 Outline
Software Architectures

4- A functional architecture describes the structure of the

potential use cases and the requirements from a user’s point of
view.

5- A software architecture describes the structure of the system

into layers, such as the OSI (Open Systems Interconnection)
seven-layer model of data communications or the layered
architecture of the UNIX operating system.

13
“Introduction to Software Engineering”, Second Edition
 Outline
Software Architectures

6- A technical architecture describes the structure of the major

interfaces in the software architecture. Elements of a technical
architecture include the application programming interfaces
(APIs), middleware, database management systems (DBMS),
graphical user interfaces (GUI).

7- A deployment architecture describes the structure of the

mapping of the system and technical architectures onto the
physical architecture.
Deployment diagrams show the hardware for your system, the
software that is installed on that hardware, and the middleware
used to connect the disparate machines to one another.
14
“Introduction to Software Engineering”, Second Edition
Structure diagram
Behavior diagram
Interaction diagram
 References
Outline

 Software Engineering Tutorial, Simply Easy Learning, 

Copyright 2014 by Tutorials Point (I) Pvt. Ltd.



18
“Introduction to Software Engineering”, Second Edition
THANK YOU

19
 3- CODING

Lecturer: dr Reem Razzaq

Lecture 7.
Class 3
Time: 1
Department: Businesses Information Technology (BIT)
 Outline

 Choice Of Programming Language

 Coding Styles
 Coding Standards
 Coding, Design, Requirements, And Change
 Coupling Can Be Dangerous
 Some Coding Metrics

2
“Introduction to Software Engineering”, Second Edition
 Choice Of Programming
Outline Language

 The choice of a programming language for

implementation of a system is often made on nontechnical
grounds.
some aspects may be more important than the perceived
technical advantages of any particular language. Such as:
1- Market pressures,
2- The availability of particular compilers,
3- Existence of software tools and development
environments,
4- The experience of the software engineering staff

3
“Introduction to Software Engineering”, Second Edition
 Choice Of Programming
Outline Language

Technical issues in programming-language selection

include such things as:
1- Ease of integration with existing software components,
2- Adherence to technical mandates(‫)اﻻلتزام بتفويض فني‬,
3- real-time or other performance requirements,
4- The need to keep staff members happy by giving them
access to new technologies.

4
“Introduction to Software Engineering”, Second Edition
 Choice Of Programming
Outline Language (Cont.)

 A software system with many components, most of

which are loaded or removed during system operation,
is very likely to be written in Java.
 A software system that makes extensive use of UNIX
or Linux system calls will probably be written in C or,
less likely, in C++.

5
“Introduction to Software Engineering”, Second Edition
 Coding
Outline
Styles

1- The way that you could organize your code can make it easier to read or
more efficient.
2- The amount of internal documentation required is to keep the
documentation within the source code.
3- This ensures that documentation will be available, regardless of any
external documents that may be lost or any changes in project personnel
(‫)الموظفين‬.

Standards for coding

1. White space
a. Blank lines
b. Spacing
c. Indentation
d. Continuation lines
e. Braces and parentheses
6
“Introduction to Software Engineering”, Second Edition
 CodingOutline
Styles (Cont.)

2. Comments
3. Standard naming conventions (‫)مصطﻼحات التسمية القياسية‬
a. Name formats
b. General guidelines for variable names

Standards for program organization

1. Program files
2. Encapsulation and information hiding
3. Readme file
4. Header files
5. Source files

7
“Introduction to Software Engineering”, Second Edition
 Coding
Outline
Standards

Software development organizations are doing

everything they can to reduce costs and simplify
their systems.
 At the same time, software is becoming more
complex, thus forcing development
organizations to produce more detailed systems
with fewer resources.
The motto (‫ )شعار‬of many organizations seems to
be “More! Better! Cheaper! Faster!”

8
“Introduction to Software Engineering”, Second Edition
 Coding
Outline
Standards

A coding standard will include the following:

1- Conventions for naming variables
a. require meaningful names
b. compatible with compilers.
2- Conventions for naming files
a. have all the features of variable naming standards.
b. should reflect the contents of the file.
c. easy to determine the appropriateness for future
potential reuse of the source code file.

9
“Introduction to Software Engineering”, Second Edition
 Coding Standards
Outline (Cont.)

3- Conventions for organizing source code files into directories.

a. Each directory represents a subsystem.
b. developing high-level directories whose names are related to
the functionality of the subsystem whose code is included in the
directory and its subdirectories.
4- Conventions for the size or complexity of source code
5- Requirements for documentation of source code
6- Restrictions in the use of certain functions

10
“Introduction to Software Engineering”, Second Edition
 Coding, Design, Requirements,
Outline And Change

Changes in software design can occur during coding for

several reasons:
1- Changes in technology have made portions of the design
obsolete or irrelevant.
2- Software libraries have been changed or reorganized.
3- The supposedly reusable software components do not work as
promised.
4- The reusable software components are not of high quality.
5- The compiler did not generate sufficiently fast executable code
to meet the real-time requirements of the system on its target
operating system environment.

11
“Introduction to Software Engineering”, Second Edition
 Coupling Can
Outline
Be Dangerous

 In general, the less coupling between modules, the better,

at least from the perspective of using modules as
components.
 Coupling-based testing is based on the premise that system
errors occur most frequently at unit boundaries and where
they interface.
 Modules with the most coupling must require the most
testing effort.

12
“Introduction to Software Engineering”, Second Edition
 Coupling Can
Outline
Be Dangerous

There are many types of coupling. ordered from greatest

amount of coupling to smallest amount:
1- Content coupling:
• is the highest level of coupling between modules.
• One module modifies or relies on the internal local data of another
module.
• Changing one module’s data will change the dependent module.
2- Common coupling:
• occurs when two or more modules share the same global data (e.g.,
a global variable).
• In common coupling, changing the shared resource in a single
module implies changing all the modules using it.

13
“Introduction to Software Engineering”, Second Edition
 Coupling Can Outline
Be Dangerous (Cont.)

3- Control coupling:
• occurs when one module is able to control the logic of another, by
passing it information on what to do (e.g., by passing a what-to-do
flag).
• Therefore, in control coupling, execution of a loop or program
branch depends upon the parameter.
4- Stamp coupling and data coupling:
• occurs when modules share data through parameters.
• Parameters may be used in a calculation, but they do not affect
logical flow (loops, branches) of the receiving module.
5- External coupling:
• occurs when two modules use data that is external to both.
• The external data may have a specified format, communications
protocol, or device interface.
14
“Introduction to Software Engineering”, Second Edition
 Coupling Can Outline
Be Dangerous (Cont.)
6- Message coupling:
• is a very low level of coupling in which modules do not communicate
with each other through parameters.
• The communicating modules use a public interface, such as messages
or events, to exchange parameter-less messages.
• message coupling is more spread in object-oriented systems.

7- No coupling, also known as weak coupling:

• is when modules do not appear to communicate with one another at
all.
• each module might use up system resources, making it hard for the
other module to execute.
• It can be very hard to find such errors without extreme stress testing.

15
“Introduction to Software Engineering”, Second Edition
 Some Coding
OutlineMetrics

There are two commonly used types of metrics:

1- Control Flow Metrics, which attempt to describe the possible execution

paths of a program.
2- Coupling Metrics, which treat the interfaces between program subunits.

16
“Introduction to Software Engineering”, Second Edition
THANK YOU

17