Material and some slide content from:

-Emerson Murphy-Hill
-Software Architecture: Foundations, Theory, and
Practice
-Essential Software Architecture and Design

Introduction to Software
Architecture, Architectural
Approaches and Design

1
REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Architecture
‣ Architecture is:
‣ All about communication.
‣ What ‘parts’ are there?
‣ How do the ‘parts’ fit together?
‣ Architecture is not:
‣ About development.
‣ About algorithms.
‣ About data structures.

2
REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

What is Software Architecture?

‣ The conceptual fabric that defines a system
‣ All architecture is design but not all design is
architecture.
‣ Architecture focuses on those aspects of a system
that would be difficult to change once the system is
built.
‣ Architectures capture three primary dimensions:
‣ Structure
‣ Communication
‣ Nonfunctional requirements
3
Logical Web Architecture
cs846.html

index.html

cs446.html

a1.html

a2.html

project.html

4
Physical Web
Architecture

5
REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Non-functional requirements
‣ Technical constraints: restrictions made for
technical reasons
‣ Business constraints: restrictions made for
business reasons
‣ Quality attributes: e.g.
‣ Scalability Security
‣ Performance
‣ Maintainability
‣ Evolvability
‣ Reliability/Dependability
‣ Deployability

6
REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

ANSI/IEEE 1471-
200
“Architecture is the fundamental
organization of a system,
embodied in its components, their
‣

relationships to each other and

the environment, and the
principles governing its design
and evolution”

7
REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Eoin
Woods
“Software architecture is the set
of design decisions which, if
made incorrectly, may cause
‣
you project to be cancelled.”

8
REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Philippe
Krutchen
“The life of a software architect
is long (and sometimes painful)
succession of sub-optimal
decisions made partly in the
dark.
‣

9
REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE
[TAILOR ET
AL.]

So what?
‣ What makes building systems so hard?
‣ New field.
‣ High user expectations.
‣ Software cannot execute independently.
‣ Incidental difficulties.
‣ Problems that can be overcome.
‣ Essential difficulties.
‣ Those problems that cannot be easily overcome.

10
REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE
[TAILOR ET
AL.]

Essential Difficulties
‣ Abstraction alone cannot help.
‣ Complexity
‣ Grows non-linearly with program size.
‣ Conformity
‣ System is dependent on its environment.
‣ Changeability
‣ Perception that software is easily modified.
‣ Intangibility
‣ Not constrained by physical laws. 11
REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE
[TAILOR ET
AL.]

Attacks on Complexity
‣ High-level languages.
‣ Development tools & environments.
‣ Component-based reuse.
‣ Development strategies.
‣ Incremental, evolutionary, spiral models.
‣ Emphasis on design.
‣ Design-centric approach taken from outset.

12
REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE
[TAILOR ET
AL.]

Architectural approaches
‣ Creative
‣ Engaging
‣ Potentially unnecessary
‣ Dangerous
‣ Methodical
‣ Efficient when domain is familiar
‣ Predictable outcome
‣ Not always successful

13
 Software Design
• How to implement the what.
• Requirements Document (RD) is starting point.
• Software design is a highly-creative activity.
• Good designers are worth their weight in gold!
– Highly sought after, head-hunted, well-paid.
• Experience alone is not enough:
– creativity, “vision”, all-around brilliance required.
Software Design (Cont’d)
• Some consider software design to be a
“black art”:
– difficult to prescribe how to do it
– hard to measure a good design objectively
– “I know a good design when I see it.”
REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE
[TAILOR ET
AL.]

Design process
1. Feasibility stage:
• Identify set of feasible concepts
2. Preliminary design stage:
• Select and develop best concept
3. Detailed design stage:
• Develop engineering descriptions of concept
• Planning stage:
1.Evaluate / alter concept to fit requirements, also
team allocation / budgeting
16
REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE
[TAILOR ET
AL.]

Abstraction
Definition:
‣

“A concept or idea not associated with a

‣

specific instance”
Top down
‣

Specify ‘down’ to details from concepts

‣

Bottom up
‣

Generalize ‘up’ to concepts from details

‣

Reification:
‣

“The conversion of a concept into a thing”

‣

17
Top-Down vs Bottom-Up Design
• Top-down Design:
– Start with a coarsely-grained view of system, and
repeatedly refine components until you have
concrete sub-components.
• Bottom-up Design:
– Start with existing components and “glue” them
together to get what you want.
Top-Down vs Bottom-Up Design
(Cont’d)
• Top-down is the “ideal” of most design
methods, but it’s rarely followed absolutely:
– some branches of development are expanded
before others are even started
– doesn’t adequately account for reuse of existing
components:
• libraries, previous versions of the same system.
REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE
[TAILOR ET
AL.]

Level of discourse
‣ Consider application as a whole
‣ e.g., stepwise refinement
‣ Start with sub-problems
‣ Combine solutions as they are ready
‣ Start with level above desired application
‣ e.g., consider simple input as general parsing

20
21
 Design Quality
• Software design “quality”, as with other
ideas on quality, is an elusive concept:
• It depends on priorities of your company
and the customers:
– fastest to implement
– easiest to implement
– easiest to maintain, “evolve”, port
– most efficient/reliable/robust end-product.
 Discussion
• What does “quality” mean to:
– IBM?
– Microsoft?
– Netscape?
– FAA?
– IRS?
– Intel?
– ...
Some Desirable Design
Attributes
• Hierarchical: A good design should be
organized into a well-designed hierarchy of
components.
• Modular: Separate distinct concerns (data
and processing) into distinct containers (i.e.,
subsystems, modules, and/or classes). Hide
implementation details and provide clean,
simple interfaces for each container.
Some Desirable Design
Attributes (Cont’d)
• Independent: Group similar things together;
limit the amount of “special knowledge” that
unrelated components may share. If you
change your mind about something, the
impact will be localized.
Some Desirable Design
Attributes (Cont’d)
• Simple Interfaces: Endless flexibility adds
complexity. Complex interfaces mean:
– hard to understand by users and developers (e.g.,
Unix man page syndrome)
– many possible variations of use
– inconvenient to change interface in order to
eliminate “bad options”.
• You can get away with “flexible interfaces”
in a low-level localized setting, but the larger
the scale, the simpler the interface should be.