Design in Software Construction

What is Design?
• A scheme for turning a specification for computer software into operational
software

• Design is the activity that links requirements to coding and debugging

• Writing a class interface in pseudo-code before writing the details

• Drawing diagrams of a few class relationships before coding them

• Choose which design pattern seems like a better choice

Design in Software Construction

• Some people might argue that design isn’t really a construction activity

• On small, informal projects, a lot of design is done while the

programmer sits at the keyboard

• On larger projects, a formal architecture might address only the

system-level issues and much design work might intentionally be left
for construction.
Design in Software Construction

• Design Challenges

• Key Design Concepts

• Design Building Blocks

• Design Practices

• Popular Methodologies
Design challenges
Tradeoffs and Priorities
• Ideally, a system
• could run instantly

• consume zero storage space

• use zero network bandwidth

• never contain any errors

• cost nothing to build

Tradeoffs and Priorities

• In reality, a designer’s job is to weigh competing design characteristics

and strike a balance among those characteristics.
• If a fast response rate is more important than minimizing development time, a
designer will choose one design.

• If minimizing development time is more important, a good designer will craft a

different design.
Restrictions

• The constraints of limited resources for constructing buildings force

simplifications of the solution that ultimately improve the solution.

• The goal in software design is the same

Nondeterministic

• If you send three people away to design the same program, they can easily
return with three vastly different designs, each of which could be perfectly
acceptable

• There are usually dozens of ways to design a computer program

Heuristic Process

• Design techniques tend to be heuristics

• Heuristics—“rules of thumb” or “things to try that sometimes work”

• Design involves trial and error

• A design tool or technique that worked well on one job or on one aspect of a
job might not work as well on the next project.

• No tool is right for everything.

Emergent

• Designs don’t spring fully formed directly from someone’s brain

• Designs evolve and improve through design reviews, informal

discussions, experience writing the code itself, and experience revising
the code
Key Design Concepts
Key Design Concepts

• Desirable Characteristics of a Design

• Levels of Design
Desirable Characteristics of a Design
• Minimal complexity
• make “simple” and “easy-to-understand” designs
• If your design doesn’t let you safely ignore most other parts of the program when you’re immersed in one specific part, the design
isn’t doing its job.

• When software-project surveys report causes of project failure, they rarely identify technical reasons as the primary
causes of project failure.

• Projects fail most often because of poor requirements, poor planning, or poor management.

• But when projects do fail for reasons that are primarily technical, the reason is often uncontrolled complexity.

• The software is allowed to grow so complex that no one really knows what it does.

• When a project reaches the point at which no one completely understands the impact that code changes in one area
will have on other areas, progress tends to a stop on the project.
Desirable Characteristics of a Design
•Ease of maintenance
• Ease of maintenance means designing for the maintenance
programmer.
• Continually imagine the questions a maintenance programmer
would ask about the code you’re writing.
• Think of the maintenance programmer as your audience, and then
design the system to be self-explanatory.
Desirable Characteristics of a Design
• Loose coupling

• Loose coupling means designing so that you hold connections among

different parts of a program to a minimum.

• Use the principles of good abstractions in class interfaces, encapsulation,

and information hiding to design classes with as few interconnections as
possible.

• Minimal connectedness minimizes work during integration, testing, and

maintenance.
Desirable Characteristics of a Design

• Extensibility
• Extensibility means that you can enhance a system without causing violence to the
underlying structure.

• You can change a piece of a system without affecting other pieces.

• The most likely changes cause the system the least trauma.
Desirable Characteristics of a Design

• Reusability
• Designing the system so that you can reuse pieces of it in other systems

• Use concepts of modularity, low coupling and high cohesion.

• The ability to reuse makes it easy to build larger systems from smaller components
while being able to identify the commonalities of those parts.

• Maintaining modularity, high cohesion, loose coupling will help make your code more
flexible to adapt to different projects and be easily extended or modified which are all
essential for code reuse.
Desirable Characteristics of a Design

•High fan-in
• High fan-in refers to having a high number of classes that use a given
class.
• High fan-in implies that a system has been designed to make good use of
utility classes at the lower levels in the system.

[Utility Class, also known as Helper class, is a class, which contains just static methods, it is
stateless and cannot be instantiated. It contains a bunch of related methods, so they can be reused
across the application. For example, java. lang.]
Desirable Characteristics of a Design

• Low-to-medium fan-out
• a given class use a low-to-medium number of other classes

• High fan-out (more than about seven) indicates that a class uses a large number
of other classes and may therefore be overly complex.
Desirable Characteristics of a Design
• Portability
• designing the system so that you can easily move it to another environment

• Leanness
• designing the system so that it has no extra parts

• Standard techniques
• Try to give the whole system a familiar feeling by using standardized, common
approaches.
Key Design Concepts

• Desirable Characteristics of a Design

• Levels of Design
Levels of Design

• Design is needed at several different levels of detail in a software

system

• Some design techniques apply at all levels, and some apply at only one
or two
Levels of Design
Levels of Design

(1). The system is first organized into sub-systems

(2). The subsystems are further divided into classes

(3). The classes are divided into routines and data

(4). The inside of each routine is also designed

Level 1: Software System

• The first level is the entire system

• Some programmers jump right from the system level into designing classes, which
is not a good idea.
• It is beneficial to think through higher level combinations of classes, such as
subsystems or packages.
• Check the link [1] below to read more about subsystems of a management
information system.
[1] [Link]
Level 1: Software System
Level 2: Division into Subsystems or Packages
• The main product of design at this level is the identification of all major subsystems.

• The subsystems can be Database, user interface, business rules, report engine, and so on.

• The major design activity at this level is deciding how to partition the program into major subsystems
and defining how each subsystem is allowed to use each other subsystem.

• Division at this level is typically needed on any project that takes longer than a few weeks.

• Of particular importance at this level are the rules about how the various subsystems can communicate.

• If all subsystems can communicate with all other subsystems, you lose the benefit of separating them at
all. Make each subsystem meaningful by restricting communications.
Level 2: Division into Subsystems or Packages
Level 3: Division into Classes

• Identifying all classes in the system

• For example, a database-interface subsystem might be further

partitioned into data access classes and persistence framework classes
as well as database metadata.

• Details of the ways in which each class interacts with the rest of the
system are also specified as the classes are specified
Level 3: Division into Classes
Level 4: Division into Routines

• Dividing each class into routines

• This level of decomposition and design is often left up to the

individual programmer
Level 5: Internal Routine Design

• laying out the detailed functionality of the individual routines

• Internal routine design is typically left to the individual programmer

working on an individual routine

• The design consists of activities such as writing pseudo-code, looking

up algorithms in reference books, deciding how to organize the
paragraphs of code in a routine, and writing programming-language
code
Architectural Styles and Strategies
Design Styles

Pipes and filters

Object-oriented design
Implicit invocation
Layering
Repositories
Interpreters
Process control
Client-server
 Architectural Styles and Strategies
Pipes and Filters

In pipes and filter here are two types of components

• Component having Streams of data for input and output is called a pipe
• Filter is a component which is involved in transformation of the data
Architectural Styles and Strategies
Pipes and Filters (cont.)

In this type of system, the filters are independent, and each is not aware of the existence
or functions of the system’s other filters.
Example: we use a pipe and filter system, whenever we compile a program, filters in a
compiler are in a linear sequence: lexical analysis, parsing, semantic analysis. And code
generation.
Architectural Styles and Strategies
Pipes and Filters (continued)

There are Several important properties of P&F

• The designer can understand the entire system's effect on input and output as the composition
of the filters
• The filters can be reused easily on other systems
• System evolution is simple, because new filters can be added easily
• Allow concurrent execution of filters
Drawbacks
• Encourages batch processing (Batch processing is execution of a series of programs ("jobs")
on a computer without manual intervention )
• Not good for handling interactive application
Architectural Styles and Strategies
Object-Oriented Design

• Must have two characteristics

• the object must preserve the integrity of data representation
• the data representation must be hidden from other objects (encapsulation)
• It makes it easy to change the implementation without disturbing the rest of the system
• One object must know the identity of other objects in order to interact
Architectural Styles and Strategies
Implicit Invocation
• The design model for implicit invocation is event-driven, based on notation of
broadcasting

• Data exchange is through shared data in a repository

• Applications
• All modern operating systems

• packet-switch networks

• databases to ensure consistency

• user interfaces
Architectural Styles and Strategies
Layering
Layers are hierarchical
Each layer provides service to the one outside it and acts as a client to the layer inside it

The design includes protocols

Explain how each pair of layers will interact

Advantages
High levels of abstraction
Relatively easy to add and modify a layer

Disadvantages
Not always easy to structure system layers
System performance may suffer from the extra coordination among layers
Architectural Styles and Strategies
Example of Layering System
A system to provide file security
Architectural Styles and Strategies
Repositories
Two components
A central data store
A collection of components that operate on it to store, retrieve, and update
information
The challenge is deciding how the components will interact
In a traditional database, the transactions in the form of an input stream triggers
process execution
A blackboard: the central store controls the triggering process (example: pattern
recognition)
Many systems are recognized as repositories, for example large databases and search
engines.
Architectural Styles and Strategies
Repositories (cont.)
Major advantage: openness
Data representation is made available to various programmers (vendors) so they can build tools to
access the repository
But also, a disadvantage: the data format must be acceptable to all components

A typical blackboard
 Architectural Styles and Strategies
Client-Server
Distributed systems usually described in terms of the topology of their
configuration.
They can be organized as a ring or as a star as shown in the picture
Characteristics of Good Design
Coupling
Highly coupled when there is a great deal of dependencies
Loosely coupled components have some dependency, but the interconnections among
components are weak
Uncoupled components have no interconnections at all
Characteristics of Good Design
Coupling (cont.)
Coupling among components depends on
the references made from one component to another
the amount of data passed from one component to another
the amount of control one component has over the other
the degree of complexity in the interface between components
We can measure coupling along a range of dependence
Characteristics of Good Design
Cohesion
Cohesion refers to the internal glue with which a component is
constructed. The more cohesive the component, the more related are the
internal parts of the components to each other and to its overall purpose.
A component is cohesive if all elements of the component are directed
toward and essential for performing the same task