The document outlines the concepts of architecture and software architecture, highlighting the importance of software design in creating a system's structure, components, and interactions. It distinguishes between architecture, which is focused on high-level concepts, and design, which applies concrete details for implementation. The document also emphasizes the significance of software architecture design in meeting system requirements and adapting to future changes while outlining the roles of software architects in the development process.

1. ARCHITECTURE WHAT?
WEEK#01
DR. Muhammad Ali Memon
Associate Professor, University of Sindh

2. Building Architectures

3. Build a Place

4. What is Architecture?
◦ the action or process of building; construction.
◦ a plan for organizing space
◦ a systematic arrangement of information or ideas.
◦ the manner in which the components of a computer or computer
system are organized and integrated.

5. The Architect

6. You need an architect first.

7. A software Architect

8. Structure in software

9. ARCHITECTURE DEFINITIONS

10. Definitions
◦ 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 interraction between
them
◦ Its an abstraction of the system
◦ Earliest artifact

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.
client,
users
architect developers
appearance,
behaviour
construction,
co-operation
architectural
design
visualises prescribes
requirem ents solutions
creates
assess assess

12. Some Examples

13. SE, Software Architecture, Hans van Vliet, ©2008 13

14. SE, Software Architecture, Hans van Vliet, ©2008 14

15. SE, Software Architecture, Hans van Vliet, ©2008 15

16. SE, Software Architecture, Hans van Vliet, ©2008 16

17. SE, Software Architecture, Hans van Vliet, ©2008 17

18. SOFTWARE DESIGN

19. 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.

20. Design vs. Architecture
◦ 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
◦ Architecture is concerned with the selection of architectural elements, their interaction,
and the constraints on those elements and their interactions
◦ Design is concerned with the modularization and detailed interfaces of the design
elements, their algorithms and procedures, and the data types needed to support the
architecture and to satisfy the requirements.
◦ Architecture…is specifically not about…details of implementations (e.g., algorithms and
data structures.)

21. Components & their Interactions
• Components are such things as clients and
servers, databases, layers, etc.
• Interactions among components can be
procedure calls, shared variable access, etc.

22. SOFTWARE ARCHITECTURE- Perry and Wolf
• Perry and Wolf distinguish between processing elements, data elements, and connecting
elements, and this taxonomy of architectural elements largely persists through most other
definitions and approaches.
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.”
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.

23. Where does architecture design come from?
• The architecture design representation is derived from the
system requirement specification and the analysis model.

24. Who is responsible for developing the architecture design?
• Software architects and designers are involved in this process
by translating (mapping) the software system requirements
into architecture design.

25. Why is software architecture design so important?
• A poor design may result in a deficient product that
– does not meet system requirements,
– is not adaptive to future requirement changes,
– is not reusable,
– exhibits unpredictable behavior, or
– performs badly.

26. When is software design conducted?
• Software design is an early phase of the Software Development
Life Cycle (SDLC).

27. What is the outcome of the software architecture design?
• Simply put, it is an overall representation of the software to be
built.
• A complete software architecture specification must describe not
only
– the elements and connectors between elements, but also the
– constraints and runtime behaviors
so that developers know what and how the design should be
implemented.

28. CODE
implementation
design
architecture

29. ARCHITECTURE BUSINESS CYCLE

30. Architectural influences
• Influences
– System Stakeholders
– Developing organization
– Architects’ background
and experience
– Technical environment
• Precautionary measures
– Know your constraints
– Early engagement of stakeholders

32. The Architecture Business Cycle

33. ABC Activities
Creating the business case for the system
– Why we need a new system, what will be its cost? Time to market,
integration with existing systems?
Understanding the Requirements
– Various approaches for requirements elicitation i.e., object-
oriented approach, prototyping etc.
– The desired qualities of a system shape the architectural decisions
– architecture defines the tradeoffs among requirements
Creating/selecting the architecture

34. ABC Activities …
Communicating the architecture
– Inform all stakeholders (i.e., developers, testers, managers, etc.)
– Architecture’s documentation should be unambiguous
Analysing or evaluating the architecture
– Evaluate candidate designs
– Architecture maps the stakeholders’ requirements/needs
Implementation based on architecture
Ensuring conformance to an architecture

35. ARCHITECT’S TASKS

36. AN ARCHITECT’S TASKS
• Perform static partition and decomposition of a system into
subsystems and communications among subsystems.
– A software element can be configured, delivered, developed, and
deployed, and is replaceable in the future.
– Each element's interface encapsulates details and provides loose
coupling with other elements or subsystems.

37. AN ARCHITECT’S TASKS
• Establish dynamic control relationships among different
subsystems in terms of data flow, control flow orchestration, or
message dispatching.
• Consider and evaluate alternative architecture styles that suit
the problem domain at hand.

38. AN ARCHITECT’S TASKS
• Perform tradeoff analysis on quality attributes and other
nonfunctional requirements during the selection of
architecture styles.
– For example, in order to increase a distributed system's extensibility,
portability, or maintainability, software components and Web
services may be the best choice of element types, and a loose
connection among these elements may be most appropriate.