1

Software Architecture and Design

Design Principles and Laws

Instructor Name: Riaz Ahmad

23.03.2024 Department of Computer Science, COMSATS University Islamabad, Wah Campus, Pakistan
Outline
2

 What are software Design Principles?

 Static and Dynamic Quality Attributes
 Role of the Architect
 4+1 Views Model
 Summery of the lecture
 What next……..

23.03.2024
 Motivational Quotation of Today?

1.Your attitude will mean what you get in life.’

2.‘The most selfish people in the world are those who
merely consume what other people have created in the
past and don’t contribute anything.’
3.‘Every single human being is a completely unique
creation.’

3 23.03.2024
 The Process of Design
4

Definition:
•

• 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 non-functional
requirements...
- Such as performance, maintainability, security, persistence, cost,
reliability, portability, etc…..(long list)
- including also the budget, technologies, environment, legal issues,
deadlines, ...
—and while adhering to general principles of good quality
23.03.2024
 Object-Oriented Design
5
•Emphasizes a conceptual solution that fulfills the requirements.
•Need to define software objects and how they collaborate to fulfill the

requirements.
•For example, in the Library Information System, a Book software object may
have a title attribute and a getChapter method.
•Designs are implemented in a programming language.

•In the example, we will have a Book class in Java.

•These we refer to as ‘software classes’ or POJC (Plain Old Java Class)

23.03.2024
 From Design to Implementation
6

Analysis
Design Construction
investigation
logical solution code
of the problem

Book public class Book {

Book
public void print();
(concept) title
print()
private String title;
}
Domain concept Representation in Representation in an
analysis of concepts
object-oriented
programming language.
23.03.2024
 Process of Design
7
•Design is all about decisions.
•Approaches:

• Top down – start with the architecture

• Bottom up – start with utilities

•There are always TRADEOFFS! There is no free lunch!!!--

• Will look at several of the tradeoffs

• Will look at (and you will develop) a software

 architecture to support your high-level design

23.03.2024
 Design as a Series of Decisions
8

A designer is faced with a series of design issues

•

• These are sub-problems of the overall design problem.

• Are always several alternative solutions: design options.
• Designer makes design decisions to resolve each issue.
—This process involves choosing the best option from among the
alternatives.
• Recognize that there may be a number of solutions – in fact, there may be

a number of good solutions for the problem to be solved.

• We would like the ‘best’ one.

23.03.2024
 Making decisions
9

• To make each design decision, the software engineer uses:

• Knowledge of
• the requirements (use cases, UI prototype, supplementary specification
document, class diagrams, interaction diagrams …)
• the design as created ‘so far’
• Available technologies (RMI, RPC, xml, jsp, servlets, html, jdbc, etc. etc.) given
a development environment
• software design principles and ‘best practices’
• what has worked well in the past
• Sometimes there is no single, best solution.
• Sometimes they conflict – each presenting pros and cons
23.03.2024
 ‘Design space’ – example Consider choice of thin client vs fat client options:
10

The space of possible designs that could be achieved by choosing different sets of
•

alternatives is often called the design space

(more efficient use of CPU and of network resources)
• For example: Why???
fat-client
separate
user interface
layer for programmmed in Java
client-server client

programmed in .Net
thin-client

no programmed in C++; C#?

separate
monolithic (simpler user interface
layer for client
software)
Advantages of fat client: bandwidth, networking services, reduced need for powerful server…
Advantages of thin client: simpler client devices; maintaining services; central bus logic…
Disadvantages? Know! Cost, reliability, maintenance, security, bandwidth, network
traffic; Never a single answer for all cases! è Design!
23.03.2024
 Different aspects of Design – Very important!!
11

• Allkinds of ‘design’ This is where the decisions are made!!!!

• Architecture design:
—The division into subsystems and components,
- How these will be connected.
- How they will interact.
- Their interfaces.
• Class design:
—The various features of classes.
• User interface design
• Algorithm design:
—The design of computational mechanisms.
• Protocol design:
—The design of communications protocol.

For a while, now, we will emphasize Architectural Design – after we discuss

• class design.
23.03.2024
 Design Principle 1: Divide and Conquer
12
•Trying to deal with something big all at once is normally much more difficult than dealing
with a series of smaller, manageable, understandable things
•(hence the iterative approach to software development)

• A software engineer/software developer can specialize.

— Specialize in network, distribution, database, algorithms, searching / sorting

techniques…
• Individual components smaller, easier to understand.

• Parts can be replaced or changed without having to replace or extensively change other

parts.

23.03.2024
 Ways of dividing a software system
13

• 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

23.03.2024
 Design Principle 2:
Keep level of Abstraction as high as possible
14

•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
• Allows us to grasp the essential!

—Defer the less important grunt-level items until later

• Allows us to deal with complexity!

• You will be doing this when you create your subsystems and when they are contained in

layers, etc.

23.03.2024
 Architectural Design Decisions
15

 Is there a generic application architecture that can be used?

 How will the system be distributed?
 What architectural styles are appropriate?
 What approach will be used to structure the system?
 How will the system be decomposed into modules?
 What control strategy should be used?
 How will the architectural design be evaluated?
 How should the architecture be documented?

23.03.2024
 Architectural Views
16

 What views or perspectives are useful when designing and documenting a system’s
architecture?
 What notations should be used for describing architectural models?
 Each architectural model only shows one view or perspective of the system.
It might show how a system is decomposed into modules, how the run-time
processes interact or the different ways in which system components are distributed
across a network. For both design and documentation, you usually need to present
multiple views of the software architecture.

23.03.2024
 4 + 1 view model of software architecture
17

 A logical view, which shows the key abstractions in the system as objects or object
classes.
 A process view, which shows how, at run-time, the system is composed of interacting
processes.
 A development view, which shows how the software is decomposed for development.
 A physical view, which shows the system hardware and how software components are
distributed across the processors in the system.
 Related using use cases or scenarios (+1)

23.03.2024
 Quality Attributes

18

Quality is a measure of excellence or the state of being free from deficiencies or defects. Quality attributes are system
properties that are separate from the functionality of the system. Implementing quality attributes makes it is easier to
differentiate a good system from a bad one. Attributes are overall factors that affect runtime behavior, system design, and
user experience. They can be classified as follows:

Static Quality Attributes

Reflect the structure of system and organization, directly related to architecture, design, source code. They are invisible to
end-user, but affect the development and maintenance cost, e.g.: modularity, testability, maintainability, etc.

Dynamic Quality Attributes

Reflect the behavior of the system during its execution. They are directly related to system’s architecture, design, source
code and also the configuration, deployment parameters, environment, and platform. They are visible to the end-user and
exist at runtime, e.g.: throughput, robustness, scalability, etc.

23.03.2024
 Quality Scenarios
19

Quality scenarios specify how to prevent a fault from becoming a failure. They can be
divided into six parts based on their attribute specifications:
 Source An internal or external entity such as people, hardware, software, or physical
infrastructure that generates the stimulus.
 Stimulus A condition that needs to be considered when it arrives on a system.
Environment The stimulus occurs within certain conditions.
 Artifact A whole system or some part of it such as processors, communication channel,
persistent storage, processes etc.
 Response An activity undertaken after the arrival of stimulus such as detect faults, recover
from fault, disable event source etc.

23.03.2024
 Role of Software Architect
20

A Software Architect provides a solution that the technical team can create and design for the entire application.
A software architect should have expertise in the following areas:
Design Expertise
 Expert in software design, including diverse methods and approaches such as object-oriented design, event-
driven design, etc.
 Lead the development team and coordinate the development efforts for the integrity of the design.
 Should be able to review design proposals and tradeoffs among them.
Domain Expertise
 Expert on the system being developed and plan for software evolution.
 Assist in the requirement investigation process assuring completeness and
consistency.
 Coordinate the definition of domain model for the system being developed.

23.03.2024
 Role of Software Architect
21

Technology Expertise
 Expert on available technologies that helps in the implementation of the system.
 Coordinate the selection of programming language, framework, platforms,
databases, etc.
Methodological Expertise
 Expert on software development methodologies that may be adopted during SDLC
(Software Development Life Cycle).
 Choose the appropriate approaches for development that helps the entire team.
Hidden Role of Software Architect
 Facilitates the technical work among team members and reinforcing the trust
relationship in the team.
 Information specialist who shares knowledge and has vast experience.
 Protect the team members from external forces that would distract them and bring
less value to the project.
Deliverables of the Architect
• A clear, complete, consistent, and achievable set of functional goals
• A functional description of the system, with at least two layers of decomposition
• A concept for the system
• A design in the form of the system, with at least two layers of decomposition
• A notion of the timing, operator attributes, and the implementation and operation
plans
• A document or process which ensures functional decomposition is followed, and the
form of interfaces is controlled 23.03.2024
 A View is a complete description (an abstraction) of a system from a particular
view-
point or perspective – covering particular concerns and omitting others not
relevant to this perspective.
Different ‘views’ from different ‘stakeholders; different concerns.
A Model is a complete representation.
22 23.03.2024
23 23.03.2024
24 23.03.2024
25

THANK YOU

23.03.2024