Software Design and Architecture

Chapter One
Software Design
Lec-1

December 29, 2020

1
 Topics to be discussed
 Software Process
 Software Process Phases
 Software Crisis
 Problems in software design
 Software Modeling
 UML-recap
 Software Design Goals
 Design Concepts
 Design Principles

December 29, 2020 2

 Software Process
 Software process is the term given to the organization and management of
software development activities
 Main phases of software design process:
 Requirements Analysis (answers “WHAT?”)
o Specifying what the application must do
 Design (answers “HOW?”)
o Specifying what the parts will be, and how they will fit together
 Implementation (a.k.a. “CODING”)
o Writing the code
 Testing
o Executing the application with test data for input
 Maintenance (REPAIR or ENHANCEMENT)
o Repairing defects and adding capability

December 29, 2020 3

 Software Process Phases: Banking application example

Requirements Analysis: Diagrams and text

• e.g., “ ... The application shall display the balance in the user‟s bank account.
...”
Design: Diagrams and text
• e.g., “ ... The design will consist of the classes CheckingAccount,
SavingsAccount, …”
Implementation: Source code
• e.g., ... class CheckingAccount { double balance; ... }
Testing: Test cases and test results
• e.g., “... With test case: deposit $44.92 / deposit $32.00 / withdraw $20.45 /
... the balance was $56.47, which is correct. ...”
Maintenance: Modified design, code, and text
• e.g., Defect repair: “Application crashes when balance is $0and attempt is
made to withdraw funds. ...”
• e.g., Enhancement: “Allow operation with Euro or other currencies.”
December 29, 2020 4
 Software’s Chronic Crisis
 Problems associated with software development are termed as crisis.
 Problems of software design
 Late deployment
Take too much time to build
 Budget overflows
Cost too much to build, require too much resources (time, space) to
run
 Unreliable and unsatisfactory systems
Do not provide the desired functionality
Can not evolve to meet changing needs
 Systems never delivered

December 29, 2020 5

 Software’s Chronic Crisis (contd.)

The fate of US defense

projects according to US
government
statistics.(Connel & Shafer
1989)

December 29, 2020 6

 Software Modeling
 Purposes
o Managing complexity
o Abstraction
o Communication: between stakeholders (programmers, designers, architects, clients, ...)
o Documentation: for maintenance and evolution
 Kinds of models
o Object models: classes, objects, messages, relations, ...
o Functional models: what the system „does‟, e.g., flow charts, State charts
o Physical models: which physical units the system constitute
o Task models: units of work, schedule, resources. E.g.: PERT ,Gantt,...
o Notations (Object Modeling Technique =OMT: Predecessor to UML)
o UML: Unified Modeling Language
 State charts
 Data flow diagrams

December 29, 2020 7

 Static vs. Dynamic Models
 Static models describe structural aspects:
 Class Diagrams
 Package Diagrams
 Type Diagrams
 Dynamic models describe behavioral aspects:
 Use Case Diagrams
 Sequence Diagrams
 Collaboration Diagrams
 State charts
 Data-Flow Diagrams

December 29, 2020 8

 UML -Recap

 An industry standard for software representation:

• A common vocabulary
• Accepted notation
• A visual abstraction
 Class Diagrams
 Data Flow Diagrams (DFD)
 Sequence Diagram
 Collaboration Diagram
 Activity Diagram

December 29, 2020 9

 Software Process Models

 Linear/Sequential

 Prototyping model

 Rapid application Development (RAD)

 Evolutionary model

 Incremental model

 Spiral model

December 29, 2020 10

 Software Design
 The purpose of design is to produce a solution to a problem:
 The problem: requirements specification.
 The solution: your description of how the requirements are to be
met.
 Design is the creative process of describing and transforming a problem
into a solution.
 Software design describe:
 The system well enough that coders can build it and deploy it
without serious problems.
 All the parts of the system and how they are to be assembled
 Each part in detail so that it can be coded.
 It consists of a set of documents (diagrams and text)

December 29, 2020 11

 Goals of Software Design

 Correctness
 Robustness
 Flexibility
 Reusability
 Efficiency
 Reliability
 Usability

December 29, 2020 12

 Cont.…
 Correctness

 Software design must satisfy the requirements for the

application

 The software designed must perform what it is intended to do

 Robustness

 A design or implementation is robust if it is able to handle

miscellaneous and unusual conditions such as bad data, user
error, programmer error, and environmental conditions.

December 29, 2020 13

 Cont....
 Flexibility
 Requirements of an application can change in many ways.
 Design should be flexible to accommodate these changes.
 Reusability
 The trend in software is to reuse parts among applications
 Example, Java API --- a large, extensive body of widely reused
classes
 Good designs are more easily modified and reused
 Efficiency
 It refers to the use of available machine cycles and memory

December 29, 2020 14

 Cont.…
 Reliability
 An application is reliable if it is relatively defect free

 Usability
 An application has high usability if users find it easy to use

December 29, 2020 15

 Example: Bank Account
 Requirements for bank account
 It begins by asking the user how many accounts he wants to
open. It then establishes the desired number, each with zero
balance.
 It asks the user which of these accounts he wants to deal with.
 When the user has selected an account, it allows the user to add
whole numbers of dollars to, or subtract them from the account
for as long as he requires.
 When the user is done with an account, he is permitted to quit, or
to pick another account to process.

December 29, 2020 16

 Problems with bank account
 How can we tell from the code that all required functionality has been
handled?
(correctness)
 If the user makes a mistake the system crashes or performs unpredictably
(robustness)
 Hard to modify, add or remove parts.
(flexibility)
 Executes fast enough?
(speed efficiency)
 Satisfies memory requirements?
(space efficiency)
 Class usable for other applications?
(reusability)
December 29, 2020 17
 Design Concepts

Abstraction

Refinement

Modularity

 Cohesion

 Coupling

 Separation of Concerns

December 29, 2020 18

 Abstraction
Abstraction is the selection of a set of concepts to represent a complex whole.

Abstraction is mostly formed by reducing information content of a concept or a

physical phenomenon typically to retain information that is relevant to a particular
purpose

Each step in the software design process is a refinement in the level of abstraction
of the software solution

Abstraction methods in Object Oriented Programming (OOP):

 Encapsulation

 Inheritance

 Polymorphism and dynamic binding

December 29, 2020 19

 Modularity
Partitioning a problem in to sub parts (Modules)
Quality attributes:
• Well-defined: Modules are clearly distinguished
• Separation of concerns: each module has one concern, with
minimal overlap between modules
• Loosely coupled
• Cohesive
 Cohesion is a measure of the relative functional strength of a
module.
 Coupling is a measure of the relative interdependence among
modules.

December 29, 2020 20

 Modularity (contd.)
 A good architecture:
• Minimizes coupling between modules:
• Goal: modules don‟t need to know much about one another to
interact
• Low coupling makes future change easier
• Maximizes the cohesion of each module
• Goal: the contents of each module are strongly inter-related
• High cohesion makes a module easier to understand

December 29, 2020 21

 Advantages of Modular design
 Comprehensibility
 Parallel development
 Quality: easier to—
 Test
 Verify and validate
 Measure reliability
 Maintainability: easier to—
o Locate faults and correct them
o Change
o Enhance
o Reusability

December 29, 2020 22

 Refinement
Refinement is a process of elaborating software design.

It begins with a statement of function (or description of

information) that is defined at a high level of abstraction.

Abstraction and refinement are complementary concepts.

 Abstraction enables a designer to specify procedure and data
and yet suppress low-level details.
 Refinement helps the designer to reveal low-level details as
design progresses.

 Both concepts aid the designer in creating a complete design

model as the design evolves.

December 29, 2020 23

 Design Principles
 The design process should not suffer from “tunnel vision.”
 A good designer should consider alternative approaches, judging each based
on the requirements of the problem, the resources available to do the job, and
design concepts
 The design should be traceable to the analysis model.
 Because a single element of the design model often traces to multiple
requirements,
 It is necessary to have a means for tracking how requirements have been
satisfied by the design model.
 The design should not reinvent the wheel.
 Systems are constructed using a set of design patterns, many of which have
likely been encountered before. These patterns should always be chosen as
an alternative to reinvention.
 Design time should be invested in representing truly new ideas and
integrating those patterns that already exist.

December 29, 2020 24

 Design Principles (contd.)
 Minimum intellectual gap between software and the problem
 The design should “minimize the intellectual distance” between the
software and the problem as it exists in the real world. That is, the
structure of the software design should (whenever possible) mimic the
structure of the problem domain.
 The design should exhibit uniformity and integration
 A design is uniform if it appears that one person developed the entire
thing.
 Rules of style and format should be defined for a design team before
design work begins.
 A design is integrated if care is taken in defining interfaces between
design components.

December 29, 2020 25

 Design Principles (contd.)
 The design should be structured to accommodate change.
 The design should be structured to degrade gently, even when
aberrant data, events, or operating conditions are encountered.
 Well- designed software should never “bomb.” It should be
designed to accommodate unusual circumstances, and if it must
terminate processing, do so in a graceful manner.

December 29, 2020 26

 Design Principles (contd.)
 Design is not coding, coding is not design.

 Even when detailed procedural designs are created for program components, the level
of abstraction of the design model is higher than source code. The only design
decisions made at the coding level address the small implementation details that enable
the procedural design to be coded.

 Quality assessment of the design during the development process

 A variety of design concepts and design measures are available to assist the designer in
assessing quality.

 The design should be reviewed to minimize conceptual (semantic) errors.

 A design team should ensure that major conceptual elements of the design (omissions,
ambiguity, inconsistency) have been addressed before worrying about the syntax of the
design model.

December 29, 2020 27

 Written Assignment
1. What is a Software Architecture?
2. What are the differences between Software Design and
Software Architecture?
3. List the common tasks of Software Architects
4. Identify the types of software architectural styles and the
characteristics of each type
5. What is the importance of Software Architecture?

December 29, 2020 28