• software architecture is the set of structures of the system, which

comprise
✓ software elements
✓ the relationships among them
✓ the externally visible properties of those elements (assumptions that
other elements can make of an element)
• Software architecture is a result of
- technical
- business and
- social influences
• Architecture Business Cycle: cycle of influences from the environment to
the architecture and back to the environment
• Architectures are influenced by
o Stakeholders
o Development Organization
o Background & Experience of the Architects
o The Technical Environment
• What Do Architectures Influence?
- structure of the developing organization | Project context
- goals of developing organization | Business context
- customer requirements for the next system | Technical context
- architect’s experience with subsequent systems | Professional
context
- software engineering culture | technical environment)
• Software Architecture Activities
✓ Creating the business case for the system
✓ Understanding the requirements from stakeholders
✓ Creating or selecting the architecture via conceptual integrity
✓ Communicating the architecture to all stakeholders
✓ Analyzing or evaluating the qualities of the architecture
✓ Implementing the system based on the architecture faithfully
according to the structures and interaction protocols constrained
✓ Ensuring that the implementation conforms to the architecture
• What makes a Good Architecture? Rules of thumb/observations that
should be followed
1. Process recommendations
✓ single architect or small group of architects
✓ gather functional requirements and prioritized list of quality
attributes
✓ well documented, with at least one static view and one
dynamic view
✓ reviewed by the system’s stakeholders
2. Product recommendations
✓ well-defined modules based on information hiding and
separation of concerns
✓ Quality attributes should be achieved using well-known
architectural tactics
✓ architecture should be independent of particular versions of
commercial products or tools
✓ Modules that produce data should be separate from modules
that consume data
• box-and-arrow diagrams, system consists of four elements
o Prop Loss Model (MODP)
o Reverb Model (MODR)
o Noise Model (MODN)
o Control Process (CP)
• Three stages that capture characteristics of an architecture, on the way
from box-and-arrow to full software architectures
1. Architectural Patterns/ architectural styles
✓ description of element & relation types together with a set of
constraints on how they may be used
✓ exhibit known quality attributes, and are a reuse of experience
✓ it is architect’s first major design decision
✓ example: client-server
2. Reference Models
✓ division of functionality together with data flow between the
pieces
 ✓ arise from experience, and are thus a characteristic of mature
domains
✓ Example: Compilers (lexical analysis, code generation),
Networks (the OSI reference model)
3. Reference Architectures
✓ reference model mapped onto software elements and the data
flows between them
RM:
A reference model: defines a way of decomposing
functionalities
A reference architecture: defines a way of mapping a
functionalities on subsystems/architectural components
• Structures and Views
▪ View: a representation of a coherent set of architectural elements,
consisting of a set of elements and the relationships among them
▪ Structure: is the set of elements itself, as they exist in software or
hardware
• Why is Architecture Important? from a technical perspective
- Communication among stakeholders
- Early design decisions, earliest point decisions analyzed
- Transferable abstraction of a system/ transferable reusable model

• Groups/Three Types of Architectural Structures

➢ Module structures
✓ static structures, in that they focus on the way the system's
functionality is divided up and assigned to implementation
teams
➢ Component-and-connector structures
✓ runtime components (principal units of computation) and
connectors (communication vehicles among components)
➢ Allocation structures
 ✓ relationships between software elements & external
environments (system's organizational, developmental,
installation, and execution)
Useful module structures
➢ Decomposition structure
▪ Units: modules
▪ Relations: is a submodule of
▪ Affected attributes: modifiability
➢ Uses structure
▪ Units: modules
▪ Relations: uses, requires the correct presence of
▪ Affected attributes: subsetability, extensibility
➢ Layer structure
▪ Units: layers
▪ Relations: requires the correct presence of, uses the service of,
provides abstraction to
▪ Affected attributes: portability
➢ Class (or generalization) structure
▪ Units: classes, objects
▪ Relations: inherits from, is an instance of
▪ Affected attributes: modifiability, extensibility
➢ Data model
▪ Units: data entities
▪ Relations: {one, many} to {one, many}, generalizes, specializes
▪ Affected attributes: modifiability, performance
o Examining a system's module structures is an excellent way to reason about
a system's modifiability
Useful C&C structures
➢ Service structure
▪ Units: services, ESB, registry
▪ Relations: runs/ may concurrently with, excludes, precedes
▪ Affected attributes: interoperability, modifiability
➢ Concurrency structure
 ▪ Units: processes, threads
▪ Relations: can run in parallel
▪ Affected attributes: performance, availability
o Crucially important for reasoning about the system's runtime properties
such as performance, security, availability.
Useful allocation structures
➢ Deployment structure
▪ Units: software elements (usually process from a C&C view) and
hardware entities (processors)
▪ Relations: allocated-to, migrates-to
▪ Affected attributes: performance, data integrity, security, availability
➢ Implementation structure
▪ Units: software elements (usually modules), file structure
▪ Relations: stored in
▪ Affected attributes: development efficiency
➢ Work assignment structure
▪ Units: modules and organizational units
▪ Relations: assigned to
▪ Affected attributes: development efficiency

• Structures are not independent. Elements of one structure will be related

to elements of other structures

• Choosing Structures/ Kruchten’s Four + One Views

o Logical View - module view
✓ functionality that the system provides to end-users
✓ UML diagram: class diagrams, and state diagrams
o Process View - C&C view
✓ Dynamic/ runtime behavior of the system, explains the system
processes and how they communicate
✓ UML diagram: activity diagram
o Development/implementation view - allocation view
✓ Illustrates a system from a programmer's perspective and is
concerned with software management
 ✓ UML diagram: Component diagram, Package diagram
o Physical/deployment View
✓ depicts the system from a system engineer's point of view.
concerned with the topology of software components on the
physical layer
✓ UML diagram: deployment diagram
o Scenarios (One view)/ use case view
✓ describe sequences of interactions between objects
✓ serve as a starting point for tests of an architecture prototype