Chapter 1: Introduction to

Software Design &Architecture

Lecture 1
Introduction
• Software architecture has emerged as an important subdiscipline of
software engineering.
• Architecture is roughly the prudent partitioning of a whole into parts,
with specific relations among the parts.
• This partitioning is what allows groups of people—often separated by
organizational, geographical, and even time-zone boundaries—to
work cooperatively and productively together to solve a much larger
problem than any of them could solve individually.
Introduction
• From that interaction emerges the functionality and quality
attributes—security, modifiability, performance, and so forth—that
the system’s stakeholders demand.
• The larger and more complex the system, the more critical is this
partitioning—and hence, architecture.
• Architecture is what makes the sets of parts work together as a
coherent and successful whole.
• Architecture documentation help architects make the right decisions;
it tells developers how to carry them out; and it records those
decisions to give a system’s future caretakers insight into the
architect’s solution.
Software Design
• Software design refers to the process of creating a specification of
software artifact which will help to developers to implement the
software.
• It is about designing individual modules/components means it defines
what is module is performing, the classes, functions and their usages,
etc.
• It is considered one of the initial phase of SDLC Software design
process establishes a best possible design plan to implement the
system.
• It mainly focuses more on internal components of the system and
their interaction with each other.
Software Architecture
• Software architecture refers to fundamental structure or the process
of creating high level structure of a software system.
• Initially software architecture is created and when it is agreed then
that software design is carried out.
• In software architecture the solution is structured in such a way so
that it meets technical and operational requirements and during
structuring application quality, maintenance, performance and overall
success all these things are kept in mind as ultimately software
architecture impact all these things at last.
What’s The Software Architecture?
What’s The Software Architecture?
• No universal definition of software architecture exists.
• The Software Engineering Institute’s Web site collects definitions from the
literature and from practitioners around the world; so far, more than 150
definitions have been collected.
• An architecture is the set of significant decisions about the organization of
a software system, the selection of the structural elements and their
interfaces by which the system is composed, together with their behavior
as specified in the collaborations among those elements, the composition
of these structural and behavioral elements into progressively larger
subsystems, and the architecture style that guides this organization—these
elements and their interfaces, their collaborations, and their composition.
(Booch, Rumbaugh, and Jacobson 1999, p. 31)
•
What’s The Software Architecture?
• The software architecture of a computing system is the set of
structures needed to reason about the system, which comprise
software elements, relations among them, and properties of both.

• The fundamental organization of a system embodied in its

components, their relations to each other, and to the environment,
and the principles guiding its design and evolution. (IEEE 1471 2000,
p. 9)
• This definition stands in contrast to other definitions that talk about
the system’s “early” or “major” design decisions.
The Software Architecture Elements
The Software Architecture Elements
• a software architecture can be defined in terms of the following elements:

Software Architecture = {Components, Relationships, Constraints}

• Components. Components are the computational elements which collectively

constitute an architecture. A software architecture is typically decomposed into
subsystems, which in turn may be decomposed into modules. Further
decomposition is also possible.
• (For example in an object-oriented design, modules may be decomposed into
classes.)
• Examples of components include clients, services, and persistent stores.

• ·
The Software Architecture Elements
• Relationships. Relationships are the logical connections between
architectural components.
• Examples of concrete component relationships include client-server
protocols and database protocols.

• Constraints. Constraints provide conditions and restrictions for component

relationships. They connect the architecture to system requirements.
• Examples of constraints include restrictions on parameters types for
communication protocols and high availability requirements for fault
tolerance.
The architecture components and their interrelationships define the
architectural structure.
The Importance of Software Architecture
1. Architecture and Quality Attributes
• Quality attributes such as performance, reliability, security, and modifiability are
every bit as important as making sure that the software computes the correct
answer.
• A software system’s ability to produce correct results isn’t helpful if it
• takes too long doing it, or
• the system doesn’t stay up long enough to deliver it

• Architecture is where these concerns are addressed. For example:

• If you require high performance, you need to :
– Exploit potential parallelism by decomposing the work into cooperating or synchronizing
processes.
– Manage the inter-process and network communication volume and data access frequencies.
– Be able to estimate expected latencies and throughputs.
– Identify potential performance bottlenecks.
1. Architecture and Quality Attributes
• If security is important, you need to
– Legislate usage relationships and communication restrictions among the parts.
– Identify parts of the system where an unauthorized intrusion will do the most
damage.
– Possibly introduce special elements that have earned a high degree of trust.
• If you need to support modifiability and portability, you must carefully
separate concerns among the parts of the system, so that when a change
affects one element, that change does not ripple across the system.
• If you want to deploy the system incrementally, by releasing successively
larger subsets, you have to keep the dependency relationships among the
pieces untangled, to avoid the “nothing works until everything works”
syndrome.
1. Architecture and Quality Attributes
• But an architecture alone cannot guarantee the functionality or
quality required of a system.
• Poor downstream design or implementation decisions can always
under- mine an adequate architectural design.
• Decisions at all stages of the life cycle—from architectural design to
coding and implementation—affect system quality.
• Therefore, quality is not completely a function of an architectural
design.
1. Architecture and Quality Attributes
• The solutions to these concerns are purely architectural in nature.
• It is up to architects to find those solutions and communicate them
effectively to those who will carry them out.
• Architecture documentation has three obligations related to quality
attributes.
• First, it should indicate which quality attribute requirements drove the design.
• Second, it should capture the solutions chosen to satisfy the quality attribute
requirements.
• Finally, it should capture a convincing argument why the solutions provide the necessary
quality attributes. The goal is to capture enough information so that the architecture can
be analyzed to see if, in fact, the system(s) derived from it will possess the necessary
quality attributes.
2. Enhancing communication among Stakeholders

• Each stakeholder of a software system—customer, user, project manager,

coder, tester, and so on—is concerned with different characteristics of the
system that are affected by its architecture. For example:
• The user is concerned that the system is fast, reliable, and available when
needed.
• The customer is concerned that the architecture can be implemented on
schedule and according to budget.
• The manager is worried (in addition to concerns about cost and schedule)
that the architecture will allow teams to work largely independently,
interacting in disciplined and controlled ways.
• The architect is worried about strategies to achieve all of those goals.
2. Enhancing communication among
Stakeholders
• Architecture provides a common language in which different concerns
can be expressed, negotiated, and resolved at a level that is
intellectually manageable even for large, complex systems.
• Without such a language, it is difficult to under- stand large systems
sufficiently to make the early decisions that influence both quality
and usefulness.
3. carrying Early design decisions
• An architecture design can also be viewed as a set of decisions.
• The early design decisions constrain the decisions that follow, and
changing these decisions has enormous ramifications.
• Changing these early decisions will cause a ripple effect, in terms of
the additional decisions that must now be changed.
3. carrying Early design decisions
What are these early design decisions embodied by software architecture?
Consider:
• Will the system run on one processor or be distributed across multiple
processors?
• Will the software be layered? If so, how many layers will there be? What will each
one do?
• Will components communicate synchronously or asynchronously? Will they
interact by transferring control or data or both?
• Will the system depend on specific features of the operating system or hardware?
• Will the information that flows through the system be encrypted or not?
• What operating system will we use?
• What communication protocol will we choose?
3. defining constraints on an Implementation
• An implementation exhibits an architecture if it conforms to the
design decisions prescribed by the architecture.
• This means that the implementation must be implemented as the set
of prescribed elements, these elements must interact with each other
in the prescribed fashion, and each element must fulfill its
responsibility to the other elements as dictated by the architecture.
Each of these prescriptions is a constraint on the implementer.
•
3. defining constraints on an Implementation
• Element builders must be fluent in the specifications of their
individual elements, but they may not be aware of the architectural
tradeoffs—the architecture (or architect) simply constrains them in
such a way as to meet the tradeoffs.
• A classic example of this phenomenon is when an architect assigns
performance budget to the pieces of software involved in some larger
piece of functionality.
• If each software unit stays within its budget, the overall transaction
will meet its performance requirement. Implementers of each of the
constituent pieces may not know the overall budget, only their own.
4. Improving cost and Schedule Estimates

• Cost and schedule estimates are important tools for the project
manager both to acquire the necessary resources and to monitor
progress on the project, to know if and when a project is in trouble.
• One of the duties of an architect is to help the project manager create
cost and schedule estimates early in the project life cycle.
5. reasoning about and Managing change
• Modifiability—the ease with which changes can be made to a
system—is a quality attribute
• Many programmers and software designers never get to work on new
development; they work under the constraints of the existing
architecture and the existing body of code.
• Virtually all software systems change over their lifetime, to
accommodate new features, to adapt to new environments, to fix
bugs, and so forth. But these changes are often fraught with difficulty.
5. reasoning about and Managing change
• Every architecture partitions possible changes into three categories: local,
nonlocal, and architectural.
• A local change can be accomplished by modifying a single element. For
example, adding a new business rule to a module.
• A nonlocal change requires multiple element modifications but leaves
the underlying architectural approach intact. For example, adding a new
business rule to a module, then adding new fields to the database that this
new business rule requires, and then revealing the results of the rule in the
user interface.
• An architectural change affects the fundamental ways in which the
elements interact with each other and will probably require changes all
over the system. For example, changing a system from client-server to
peer-to-peer.
Thanks