software design and architecture

1. Memoona Sami
Memoona.sami@faculty.muet.edu.pk
SOFTWARE DESIGN AND ARCHITECTURE
LECTURE 1-3
Disclaimer: The contents of this
presentation have been taken from
multiple sources, i.e. Books, Research
articles, Thesis publications, and websites.

2. The material used in this presentation i.e., pictures/graphs/text, etc. is solely
intended for educational/teaching purpose, offered free of cost to the students for
use under special circumstances of Online Education due to COVID-19 Lockdown
situation and may include copyrighted material - the use of which may not have
been specifically authorised by Copyright Owners. It’s application constitutes Fair
Use of any such copyrighted material as provided in globally accepted law of many
countries. The contents of presentations are intended only for the attendees of the
class being conducted by the presenter.
Fair Use Notice

3. OUTLINES
❖Introduction
❖Architecture Business Cycle
❖Architectures Business Cycle and Software Processes
❖Good and bad architectures

4. INTRODUCTION
❖A software architecture is developed as the first step toward designing a system that has a
collection of desired properties.
❖The software architecture of a program or computing system is the structure or structures of
the system, which comprise software elements, the externally visible properties of those
elements, and the relationships among them.
❖Architecture serves as an important communication, reasoning, analysis, and growth tool for
systems.
❖In a nutshell, if you know the requirements for a system, you can build the architecture for it.

5. INTRODUCTION
❖Where Do Architectures Come From?
❖An architecture is the result of a set of business and technical decisions.
❖There are many influences at work in its design, and the realization of these influences will
change depending on the environment in which the architecture is required to perform.
❖Even with the same requirements, hardware, support software, and human resources available, an architect
designing a system today is likely to design a different system than might have been designed five years ago.

6. A SOFTWARE ARCHITECT?
Software Architecture Design
Team
Software
Architecture
Architecture
Realization
Application

7. STRUCTURE MATTERS
Dijkstra 1968:
◦ “…Correct arrangement of the structure of the software systems before programming…”
◦ Layered structure for easier development.
Parnas 1972:
◦ “… selected criteria for the decomposition of the system impact the structure of the programs and
several design principles must be followed to provide a good structure…”
◦ Examples: separation of concerns, hierarchical structures, program families (reuse).

8. EVOLUTION OF SOFTWARE SYSTEMS
❖Software problems have changed in nature(algorithmic to general purpose applications)
❖increased complexity to millions lines of code
❖It has now become hard/impossible to develop system without architecture

9. Software Architecture Definitions

10. DEFINITIONS FROM THE CLASS…
❖Basic artifact shown to the customers and made from the requirements.
❖Breaking down of the system into components
❖And describing the interrelations between the components
❖A prototype of the system
❖Identify the components of the system along with the interaction between them
❖Its an abstraction of the system

11. SOFTWARE ARCHITECTURE- Booch
1991
“The logical and physical structure of a system, forged by all the strategic and tactical decisions
applied during development.”
Architecture is the high level structure of a system.

12. SOFTWARE ARCHITECTURE- IEEE
“Software architecture is the fundamental organization of a system, embodied in its
components, their relationships to each other and their environment, and the principles
governing its design and evolution.”

13. SOFTWARE ARCHITECTURE – BASS,
CLEMENTS, KAZMAN
The software architecture of a program or computing system is the structure or structures of
the system, which comprise software elements, the externally visible properties of those
elements and the relationships among them.

14. WHAT IS SOFTWARE DESIGN
❖Software design is the process by which we create a specification of a software artifact, using
a set of primitive components and subject to constraints.
❖The process of defining the architecture, components, interfaces, and other characteristics of a
system or component.

15. DIFFERENCE
❖Software architecture deals with high level concepts without regard to any implementation
details. Software design on the other hand takes high level concepts and applies concrete
details so that software can be implemented.
❖Every architectural work is a kind of design, but the reverse is not true

16. It's about addressing those architecturally significant requirements (the "what") that will
drive (and constrain) the "how" (the design).

17. What does SA address?
❖Complexity of software systems increased
❖ Developing software: hundreds/ thousands person-years
❖ Many software systems: complex as skyscrapers
❖ Designing software
❖ Beyond algorithms/ data structures of the computation
❖ New kind of problem: overall system structure
❖An important criteria for building complex software is: does it have a good SA, understood by
stakeholders and developers?

18. SA
❖Provides a design plan of a system
❖ Blueprint
❖ Implies purpose
❖ Is an abstraction that helps in managing the complexity of a system
❖ Software architects are limited by
❖ Lack of standardized ways to represent architecture
❖ Lack of analysis methods to predict whether an architecture will result in an implementation that
meets the requirements

19. SA goal
❖One should strive for a good architecture
❖ When system is implemented according to the architecture, it meets its requirements and resource
budget
❖ It is possible to implement system according to architecture
❖ Not good enough when
❖ Not explicit or not comprehensive or not consistent or not understandable

20. TERMINOLOGY
1. Architectural style/pattern:
❖Defines element types and how they interact together with a set of constraints
❖Sometimes defines a mapping of functionality to architectural elements
❖An architectural style determines the vocabulary of components and connectors that can be used in
instances of that style, together with a set of constraints on how they can be combined. These can
include topological constraints on architectural descriptions (e.g., no cycles). Other constraints—say,
having to do with execution semantics—might also be part of the style definition
❖E.g. Client Server Architectural Pattern.

21. The following table lists the major areas of focus and the corresponding architectural styles.

22. 2. Reference/domain specific architecture:
❖Defines element types and how they interact
❖They apply to a particular domain
❖They define how the domain functionality is mapped to architectural(software) elements.
TERMINOLOGY

23. 3. Product line architecture:
❖A software product line is a set of software-intensive systems that share a common, managed set of
features satisfying the specific needs of a particular market segment or mission and that are developed
from a common set of core assets in a prescribed way.
❖Applies to a set of products within a company
❖Defines element types, how they interact, how the product functionality is mapped to them
❖May also define some of the instances of the architectural Elements. E.g., error-reporting components
would be common to many products of the product line
TERMINOLOGY

24. 4. Software Architecture:
❖Applies to one system
❖Describes element types, how they interact, how the product functionality is mapped to them
❖Describes the instances that exist in the system
❖Level of specificity needed to design a system
TERMINOLOGY

26. QUESTION
❖What do you think would happen if same requirements were given to two different architects
of different organizations?

27. Architecture Business Cycle
❖Software architecture is a result of technical, business, and social influences. Its existence in
turn affects the technical, business, and social environments that subsequently influence future
architectures. We call this cycle of influences, from the environment to the architecture and
back to the environment, the ABC.
❖Organizational goals-> requirements->SA-> systems-> future new organizational goals-> …
❖ We begin building the ABC by identifying the influences to and from architectures.
❖Architectures are influenced by:
◦ System Stakeholders
◦ Developing Organization
◦ Experience of Architects
◦ Technical Environment

28. Architecture Business Cycle

29. Architecture Business Cycle
❖Architecture affects following factors
◦ Structure of the developing organization
◦ Goals of the developing organization
◦ Customer requirements for the next system
◦ Architect’s experience for subsequent systems
◦ Technical Environment

30. Architectures Business Cycle and
Software Processes
❖Software process is the term given to the organization and management of software development
activities.
❖What activities are involved in creating a software architecture, using that architecture to realize a design,
and then implementing or managing the evolution of a target system or application? These activities
include the following:
❖Creating the business case for the system
❖Understanding the requirements
❖Creating or selecting the architecture
❖Documenting and communicating the architecture
❖Analyzing or evaluating the architecture
❖Implementing the system based on the architecture
❖Ensuring that the implementation conforms to the architecture
❖As indicated in the structure of the ABC, architecture activities have comprehensive feedback
relationships with each other.

31. Good and Bad Architectures
❖What Makes a "Good" Architecture?
❖If it is true that, given the same technical requirements for a system, two different architects in different organizations
will produce different architectures, how can we determine if either one of them is the right one?
❖There is no such thing as an inherently good or bad architecture. Architectures are either more or less fit for some
stated purpose.
❖A distributed three-tier client-server architecture may be just the ticket for a large enterprise's financial management system but
completely wrong for an avionics application.
❖An architecture carefully crafted to achieve high modifiability does not make sense for a throw-away prototype.
❖We divide our observations into two clusters:
❖process recommendations and
❖product (or structural) recommendations.

32. Good and Bad Architectures
❖Process Recommendations
❖The architecture should be the product of a single architect or a small group of architects with an identified leader.
❖The architect (or architecture team) should have the functional requirements for the system and an articulated,
prioritized list of quality attributes (such as security or modifiability) that the architecture is expected to satisfy.
❖The architecture should be well documented, with at least one static view and one dynamic view, using an agreed-on
notation that all stakeholders can understand with a minimum of effort.
❖The architecture should be circulated to the system's stakeholders, who should be actively involved in its review.
❖The architecture should be analyzed for applicable quantitative measures (such as maximum throughput) and
formally evaluated for quality attributes before it is too late to make changes to it.

33. Good and Bad Architectures
❖Process Recommendations
❖The architecture should lend itself to incremental implementation via the creation of a "skeletal"
system in which the communication paths are exercised but which at first has minimal functionality.
This skeletal system can then be used to "grow" the system incrementally, easing the integration and
testing efforts.
❖The architecture should result in a specific (and small) set of resource contention areas, the resolution
of which is clearly specified, circulated, and maintained.

34. Good and Bad Architectures
❖Product Recommendations
❖The architecture should feature well-defined modules whose functional responsibilities are allocated
on the principles of information hiding and separation of concerns.
❖Each module should have a well-defined interface that encapsulates or "hides" changeable aspects
(such as implementation strategies and data structure choices) from other software that uses its
facilities. These interfaces should allow their respective development teams to work largely
independently of each other.
❖Quality attributes should be achieved using well-known architectural tactics specific to each attribute.
❖The architecture should never depend on a particular version of a commercial product or tool. If it
depends upon a particular commercial product, it should be structured such that changing to a
different product is straightforward and inexpensive.

35. Good and Bad Architectures
❖Product Recommendations
❖Modules that produce data should be separate from modules that consume data. This tends to increase modifiability
because changes are often confined to either the production or the consumption side of data. If new data is added,
both sides will have to change, but the separation allows for a staged (incremental) upgrade.
❖For parallel-processing systems, the architecture should feature well-defined processes or tasks that do not
necessarily mirror the module decomposition structure.
❖Every task or process should be written so that its assignment to a specific processor can be easily changed, perhaps
even at runtime.
❖The architecture should feature a small number of simple interaction patterns. That is, the system should do the
same things in the same way throughout. This will aid in understandability, reduce development time, increase
reliability, and enhance modifiability. It will also show conceptual integrity in the architecture, which, while not
measurable, leads to smooth development.

36. Why is Software Architecture
important?
▪Architecture is the vehicle for stakeholder communication
▪Architecture manifests the earliest set of design decisions
▪ Constraints on implementation
▪ Dictates organizational structure
▪ Inhibits or enable quality attributes
▪Architecture is a transferable abstraction of a system
▪ Product lines share a common architecture
▪ Basis for training