5. Mutual communication
• Software architecture represents a
common high-level abstraction of the
system that most, if not all, of the
system's stakeholders can use
as a basis for creating mutual
understanding, forming consensus, and
communicating with each other
6. Mutual Communication
• 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. Architecture
provides a common language in which different
concerns can be expressed, negotiated, and
resolved at a level that is
7. Continued…
• intellectually manageable, even for large,
complex systems.Without such language,
it is difficult to understand large systems
sufficiently to make the early decisions
that influence both quality and usefulness
8. Early design decisions.
• Software architecture embodies a relatively
small, intellectually graspable model for how the
system is structured and how its
• components work together; this model is
transferable across systems;
• particular, it can be applied to other systems
exhibiting similar requirements, and can promote
large scale reuse..
9. Early design decisions.
• The architecture is in fact the sum of the
early design decisions. System architects
choose an architecture
• Capture the emergent behavior of the
system, that is they relate to system as a
whole or a family of closely related
architectures.
11. Limitations
• Resource allocation decisions also
constraint on implementation level
• The architects need not be experts in all
aspects of designing but he knows the all
architectural trade-offs.
• the work breakdown structure of a system
12. Limitations.
• The work breakdown structure, in turn,
dictates units of planning, scheduling, and
budget, as well as inter-team
communications channels, configuration
control and file system organization
• Integrations of all subsystems is not so
easy task
13. Reusability of a system
• Software architecture embodies a relatively
small, intellectually graspable model for how the
system is structured and how its components
work together; this model is transferable across
systems; in particular, it can be applied to other
systems exhibiting similar requirements, and
can promote large scale reuse.
14. Reusability of a system
• reusing a family-wide design reduces the
risk that a derived system might have an
inappropriate architecture. Using a
standard design reduces both risk and
development costs, at the risk of non-
optimality
15. Architectural Attributes
• Performance can be enhanced by localising
operations to minimize sub-system
communication. That is, try to have self-
contained modules as much as possible so that
inter-module communication is minimized.
• Security can be improved by using a layered
architecture with critical assets put in inner
layers.
• Safety Safety-critical components should be
isolated
16. Architectural Attributes
• Availability can be ensured by building
redundancy in the system and having
redundant components in the architecture.
• Maintainability is directly related with
simplicity.Therefore,maintainability can be
increased by using fine-grain, self-
contained components
17. Architectural Design
Process
• System structuring is concerned with
decomposing the system into interacting
sub-systems. The system is decomposed
into several principal sub-systems
and communications between these sub-
systems are identified.
20. References
• ‘Requirements Engineering: Processes and
Techniques’ by G. Kotonya and I. Sommerville,
John Wiley & Sons, 1998
• Software Requirements: Objects, Functions, and
States by A. Davis, PH, 1993
• Software Engineering 6th Edition, by I.
Sommerville, 2000
• Software Engineering 5th Edition, by R. Pressman
