Software Engineering - 2018 Faculty of Engineering Helwan University

1. 1
‫ر‬َ‫ـد‬ْ‫ق‬‫ِـ‬‫ن‬،،،‫لما‬‫اننا‬ ‫نصدق‬ْْ‫ق‬ِ‫ن‬‫ر‬َ‫د‬
Faculty of Engineering - Helwan University

2. 2
 The main goal of the software engineering process is the
production of software that:
 Functions properly
 On time
 Within budget
 Meets end-users’ needs
 Software Design is a key piece of this process

3. 3
 Software design deals with transforming the customer
requirements, as described in the SRS document, into a form
(a set of documents) that is suitable for implementation in a
programming language.
 Software Design is a problem-solving process whose objective
is to find and describe a way:
 To implement the system’s functional requirements...
 While respecting the constraints imposed by the quality,
platform and process requirements...
• including the budget
 And while adhering to general principles of good quality
 A good software design is seldom arrived by using a single
step procedure but rather through several iterations through
a series of steps.

4. 4
 Design activities can be broadly classified into three
important parts:
 Very High-Level Design – Software Architecture.
 High-level design.
 Detailed design.

5. 5
 High-level design means
1. Identification of different modules
2. The control relationships among them
3. The definition of the interfaces among these modules.
 The outcome of high-level design is called the program
structure.
 The representation of a high-level design.
 Structure chart (a tree-like diagram)
 Jackson diagram.
 Warnier-Orr.

6. 6
 During detailed design, the data structure and the
algorithms of the different modules are designed.
 The outcome of the detailed design stage is usually
known as the module-specification document.

7. 7
 Component: Any piece of software or hardware that has
a clear role.
 A component can be isolated, allowing you to replace it
with a different component that has equivalent
functionality.
 Many components are designed to be reusable.
 Conversely, others perform special-purpose functions.
 Module: A component that is defined at the
programming language level
 For example, Methods, Classes and Packages are modules
in Java.

8. 8
 System: A logical entity, having a set of definable
responsibilities or objectives, and consisting of
hardware, software or both.
 A system can have a specification which is then
implemented by a collection of components.
 A system continues to exist, even if its components are
changed or replaced.
 The goal of requirements analysis is to determine the
responsibilities of a system.
 Subsystem:
 A system that is part of a larger system, and which has a
definite interface.

9. 9
 The aim of analysis is to
 Understand the problem
 Eliminate any deficiencies in the requirement specification
such as incompleteness, inconsistencies, etc.
 The aim of design is to produce a model that will
provide a seamless transition to the coding phase.

10. 10
 Different modules required to implement the design
solution.
 Control relationship among the identified modules. The
relationship is also known as the call relationship or
invocation relationship among modules.
 Interface among different modules. The interface among
different modules identifies the exact data items
exchanged among the modules.
 Data structures of the individual modules.
 Algorithms required to implement each individual
module.

11. 11
 Correctness: A good design should correctly implement
all the functionalities identified in the SRS document.
 Understandability (Simplicity): A good design is easily
understandable.
 Adaptability (Changeability): A good design is easily
adaptable.
 Efficiency: It should be efficient.
 Maintainability: It should be easily amenable to change.

12. 12
 In order to facilitate understandability, the design
should have the following features:
 It should use consistent and meaningful names for
various design components.
 The design should be modular. The term modularity
means that it should use a cleanly decomposed set of
modules.
 It should neatly arrange the modules in a hierarchy, e.g.
in a tree-like diagram.
 Informally, high complexity means many
relationships between different parts of the
design.

13. 13
System level
Sub-system
level

14. 14
 A design is adaptable if:
 Its components are loosely coupled.
 Each component is a self-contained entity (tightly
cohesive).
 To adapt a design, it must be possible to trace the links
between design components so that change
consequences can be analyzed.

15. 15
P O R
D
A
B
F
C
D Object interaction
level
Object decomposition
level

16. 16
 Problem understanding
 Look at the problem from different angles to discover the
design requirements.
 Identify one or more solutions
 Evaluate possible solutions and choose the most
appropriate depending on the designer's experience and
available resources.
 Describe solution abstractions
 Use graphical, formal or other descriptive notations to
describe the components of the design.
 Repeat process for each identified abstraction
until the design is expressed in primitive terms.

17. 17
 Architectural design: Identify sub-systems.
 Abstract specification: Specify sub-systems.
 Interface design: Describe sub-system interfaces.
 Component design: Decompose sub-systems
into components.
 Data structure design: Design data structures to hold
problem data.
 Algorithm design: Design algorithms for problem
functions.

18. 18
Architectural
design
Abstract
specificatio
n
Interface
design
Component
design
Data
structure
design
Algorithm
design
System
architecture
Software
specification
Interface
specification
Component
specification
Data
structure
specification
Algorithm
specification
Requirements
specification
Design activities
Design products
Design Products
Design Activities

19. 19

20. 20
 Techniques include:
 Top-down functional decomposition
 Bottom-up design
 Structured design
 Jackson/data structure design
 Database design
 Object-oriented design
 Aspect-oriented design
 Functional design
 Design for real-time systems
 Agile programming (eg. Extreme programming)
 Structured System

21. 21
 Top-down design
 First design the very high level structure of the system.
 Then gradually work down to detailed decisions about low-
level constructs.
 Finally arrive at detailed decisions such as:
• the format of particular data items;
• the individual algorithms that will be used.

22. 22
 Bottom-up design
 Make decisions about reusable low-level utilities.
 Then decide how these will be put together to create
high-level constructs.
 A mix of top-down and bottom-up approaches are
normally used:
 Top-down design is almost always needed to give the
system a good structure.
 Bottom-up design is normally useful so that reusable
components can be created.

23. 23
 Functional-oriented design
 Object-oriented design
 Mixed-strategy Design

24. 24
 A module having high cohesion and low coupling is said
to be functionally independent of other modules.
 Functional independence is a key to any good design due
to the following reasons:
 Error isolation: reduces error propagation.
 Scope of reuse: Reuse of a module becomes possible.
 Understandability: Complexity of the design is reduced,
because different modules can be understood in isolation
as modules are more or less independent of each other.

25. 25
 A measure of how well a component “fits
together”.
 A component should implement a single logical
entity or function.
 Cohesion is a desirable design component
attribute as when a change has to be made, it
is localized in a single cohesive component.
 Various levels of cohesion have been identified.

26. 26
 Coincidental cohesion (weak)
 Parts of a component are simply bundled together.
 Logical association (weak)
 Components which perform similar functions are grouped.
 Temporal cohesion (weak)
 Components which are activated at the same time are
grouped.

27. 27
 Communicational cohesion (medium)
 All the elements of a component operate on the same
input or produce the same output.
 Sequential cohesion (medium)
 The output for one part of a component is the input to
another part.
 Functional cohesion (strong)
 Each part of a component is necessary for the execution of
a single function.
 Object cohesion (strong)
 Each operation provides functionality which allows object
attributes to be modified or inspected.

28. 28
 A measure of the strength of the inter-connections
between system components.
 Loose coupling means component changes are unlikely
to affect other components.
 Shared variables or control information
exchange lead to tight coupling.
 Loose coupling can be achieved by state
decentralization (as in objects) and component
communication via parameters or message
passing.

29. 29
Module A Module B
Module C Module D
Shared data
area

30. 30
Module A
A’s data
Module B
B’s data
Module D
D’s data
Module C
C’s data

31. 31
 Content coupling:
 Content coupling exists between two modules, if they
share code.
 Common coupling:
 Two modules are common coupled, if they share data
through some global data items.
 Control coupling:
 Control coupling exists between two modules, if data
from one module is used to direct the order of
instructions execution in another.

32. 32
 Stamp coupling:
 Two modules are stamp coupled, if they
communicate using a composite data item such as a
record in PASCAL or a structure in C.
 Data coupling:
 Two modules are data coupled, if they communicate
through a parameter.

33. 33
‫ر‬َ‫ـد‬ْ‫ق‬‫ِـ‬‫ن‬،،،‫لما‬‫اننا‬ ‫نصدق‬ْْ‫ق‬ِ‫ن‬‫ر‬َ‫د‬

34. 34
 Overall goals of good design
 Increasing profit by reducing cost and increasing revenue
 Ensuring that we actually conform with the requirements
 Accelerating development
 Increasing qualities such as:
• Usability
• Efficiency
• Reliability
• Maintainability
• Reusability

35. 35
 Trying to deal with something big all at once is normally
much harder than dealing with a series of smaller things
 Separate people can work on each part.
 An individual software engineer can specialize.
 Each individual component is smaller, and therefore easier
to understand.
 Parts can be replaced or changed without having to
replace or extensively change other parts.

36. 36
 Ways of dividing a software system
 A distributed system is divided up into clients and servers
 A system is divided up into subsystems
 A subsystem can be divided up into one or more packages
 A package is divided up into classes
 A class is divided up into methods

37. 37
 A subsystem or module has high cohesion if it keeps
together things that are related to each other, and
keeps out other things
 This makes the system as a whole easier to understand and
change

38. 38
 Coupling occurs when there are interdependencies
between one module and another
 When interdependencies exist, changes in one place will
require changes somewhere else.
 A network of interdependencies makes it hard to see at a
glance how some component works.

39. 39
 Ensure that your designs allow you to hide or defer
consideration of details, thus reducing complexity
 A good abstraction is said to provide information hiding.
 Abstractions allow you to understand the essence of a
subsystem without having to know unnecessary details.

40. 40
 Classes are data abstractions that contain procedural
abstractions
 Abstraction is increased by defining all variables as
private.
 The fewer public methods in a class, the better the
abstraction
 Superclasses and interfaces increase the level of
abstraction
 Attributes and associations are also data abstractions.
 Methods are procedural abstractions
• Better abstractions are achieved by giving methods fewer
parameters

41. 41
 Design the various aspects of your system so that they
can be used again in other contexts
 Generalize your design as much as possible
 Follow the preceding three design principles
• Increase cohesion
• Reduce coupling
• abstraction as high as possible
 Design your system to contain hooks
 Simplify your design as much as possible

42. 42
 Design with reuse is complementary to design for
reusability
 Actively reusing designs or code allows you to take
advantage of the investment you or others have made in
reusable components
 Commercial-off-the-shelf (COTS) software.

43. 43
 Actively anticipate changes that a design may have to
undergo in the future, and prepare for them
 Reduce coupling and increase cohesion
 Create abstractions
 Do not hard-code anything
 leave all options open
• Do not restrict the options of people who have to
modify the system later
 Use reusable code and make code reusable

44. 44
 Plan for changes in the technology or environment, so
the software will continue to run or can be easily
changed
 Avoid using early releases of technology
 Avoid using software libraries that are specific to
particular environments
 Avoid using undocumented features or little-used features
of software libraries
 Avoid using software or special hardware from companies
that are less likely to provide long-term support
 Use standard languages and technologies that are
supported by multiple vendors

45. 45
 Have the software run on as many platforms as possible
 Avoid the use of facilities that are specific to one
particular environment
 E.g. a library only available in Microsoft Windows

46. 46
 Take steps to make testing easier
 Design a program to automatically test the software
• Discussed more in Testing Chapter
• Ensure that all the functionality of the code can by
driven by an external program, bypassing a graphical
user interface
 In Java, you can create a main() method in each class in
order to exercise the other methods

47. 47
 Never trust how others will try to use a component you
are designing
 Handle all cases where other code might attempt to use
your component inappropriately
 Check that all of the inputs to your component are valid:
the preconditions

48. 48
 A technique that allows you to design defensively in an
efficient and systematic way
 Key idea
• each method has an explicit contract with its callers
 The contract has a set of assertions that state:
• What preconditions the called method requires to be
true when it starts executing
• What postconditions the called method agrees to
ensure are true when it finishes executing
• What invariants the called method agrees will not
change as it executes

49. 49
 Using priorities and objectives to decide among
alternatives
 Step (1): List and describe the alternatives for the design
decision.
 Step (2): List the advantages and disadvantages of each
alternative with respect to your objectives and priorities.
 Step (3): Determine whether any of the alternatives
prevents you from meeting one or more of the objectives.
 Step (4): Choose the alternative that helps you to best
meet your objectives.
 Step (5): Adjust priorities for subsequent decision making.

50. 50
 Imagine a system has the following objectives, starting
with top priority:
 Security: Encryption must not be breakable within 100
hours of computing time on a Quad-3.4Ghz Intel processor,
using known cryptanalysis techniques.
 Maintainability. No specific objective.
 CPU efficiency. Must respond to the user within one
second when running on a i5-2.6Ghz Intel processor.
 Network bandwidth efficiency: Must not require
transmission of more than 8KB of data per transaction.
 Memory efficiency. Must not consume over 20MB of RAM.
 Portability. Must be able to run on Windows 8, NT 4 and XP
as well as Linux

51. 51
‘DNMO’ means Does Not Meet the Objective

52. 52
 Computer-aided software engineering (CASE) is the
scientific application of a set of tools and methods to
a software system which results in high-quality, defect-
free, and maintainable software products.
 CASE is a coherent set of tools that is designed to support
related software process activities such as analysis, design
or testing.
 Analysis and design workbenches support system modelling
during both requirements engineering and system design.
 These workbenches may support a specific design method
or may provide support for a creating several different
types of system model.

53. 53
 Diagram editors
 Model analysis and checking tools
 Repository and associated query language
 Data dictionary
 Report definition and generation tools
 Forms definition tools
 Import/export translators
 Code generation tools

54. 54
 Data dictionaries are lists of all of the names used in the
system models. Descriptions of the entities,
relationships and attributes are also included
 Advantages
 Support name management and avoid duplication
 Store of organizational knowledge linking analysis, design
and implementation
 Many CASE workbenches support data dictionaries

55. 55
‫ر‬َ‫ـد‬ْ‫ق‬‫ِـ‬‫ن‬،،،‫لما‬‫اننا‬ ‫نصدق‬ْْ‫ق‬ِ‫ن‬‫ر‬َ‫د‬

56. 56
 Design documents as an aid to making better designs
 They force you to be explicit and consider the important
issues before starting implementation.
 They allow a group of people to review the design and
therefore to improve it.
 Design documents as a means of communication:
• To those who will be implementing the design.
• To those who will need, in the future, to modify the design.
• To those who need to create systems or subsystems that
interface with the system being designed.

57. 57
A. Purpose:
 What system or part of the system this design document describes.
 Make reference to the requirements that are being implemented by
this design (traceability).
B. General priorities:
 Describe the priorities used to guide the design process.
C. Outline of the design:
 Give a high-level description of the design that allows the reader to
quickly get a general feeling for it.
D. Major design issues:
 Discuss the important issues that had to be resolved.
 Give the possible alternatives that were considered, the final
decision and the rationale for the decision.
E. Other details of the design:
 Give any other details the reader may want to know that have not
yet been mentioned.

58. 58
 Avoid documenting information that would be readily
obvious to a skilled programmer or designer.
 Avoid writing details in a design document that would be
better placed as comments in the code.
 Avoid writing details that can be extracted
automatically from the code, such as the list of public
methods.

59. 59