1. Basic Concepts and Definitions
Software Architecture: a “set” of principal design decisions made about the system
Software Reference Architecture: a set of principal design decisions that are:
simultaneously applicable to multiple and related systems
typically within 1 application domain
with explicitly defined points of variations
( e.g. State-Tax package with different deduction rules)

2. What are these “Principal” Design Decisions?
System Structure:
Set of main components and how are they “related”
Functional Behavior:
What do the main components do and what do they “do-together”
Interactions:
How do the “main” components relate to each other in terms of control and data “passing” or “sharing” --- the “dynamic” aspect
Non-functional Characteristics:
How are properties such as security, scalability, performance, etc. addressed (different emphasis here may redefine “principal”)
Implementation:
How should the components be built, with what tool, and what platforms.
We are interested in delineating these categories of principal design decisions
so that they can be modeled, analyzed, implemented and tested.

3. Perry & Wolf definition of architecture
Software Architecture = { elements, form , rationale}
- where elements are the key components
that may be a processing, a data or a connecting
“element”
- form describes how the elements are
composed and organized
- rationale describes the designers intent,
assumptions, etc.

4. ANSI/IEEE Standard 1471 “Definition”
Architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, AND the principles governing its design and evolution.
What might these be?

5. Prescriptive & Descriptive Architecture
Prescriptive Architecture
Descriptive Architecture
“intentional”
Design Decisions
in limited
Artifacts:
- arch document
“realized
Decisions”
In Artifacts:
- Design documents
Implemented code
- Test Cases
Develop

6. Prescriptive versus Descriptive
Prescriptive or “intended”
Architecture
Descriptive or “realized”
Architecture
Prescriptive
architecture may be
changed
as it was “realized.”
A&B A B C D C D
Your text book has a different example see pages 62-63

7. Multiple “sets” of Principal Decisions
Can there be more than one set of Architecture?
Yes versions of architecture
Based on modifications as we change our minds
Based on modifications as we make corrections
Based on increase in depth as we know more
Based on expansion as we evolve and grow
etc.
We can have multiple sets of architecture at different times

8. Versions of Prescriptive & Descriptive Architecture
Version of
Prescriptive Architecture
Versions of
Descriptive Architecture
“intentional”
Design Decisions
“intentional”
Design Decisions
Artifacts:
- Design documents
Implemented code
- Test Cases
“intentional”
Design Decisions
Artifacts:
- Design documents
Implemented code
- Test Cases
Artifacts:
- Design documents
Implemented code
- Test Cases
Document &
Develop tn tn t0 t0

9. “Issues” with Architectural Differences
What issues do we need to worry about when prescriptive and descriptive architecture are different or when there are different versions of architectures?:
Which architecture is correct? (intent or realized?)
The versions of architecture still consistent among themselves ?
What criteria do we use to evaluate consistency? (# of components, component structure, etc.?)
What and how much information do we use in making decisions?

10. Architectural Degradation
Architectural degradation occurs when the prescriptive and the descriptive architecture differs.
There are 2 main types of architectural degradation.
Architectural Drift
Introducing principal design decisions into the descriptive architecture that are not in the prescriptive architecture, but does not violate the prescriptive architecture’s design decisions.
Architectural Erosion
Introducing principal design decisions into the descriptive architecture that violate the prescriptive architecture.
Remember Product Line and Product Family fertile ground for
Architectural Degradation

11. Architectural Perspectives
Different emphasis of design decisions provides a different view of the decisions made ---- emphasis difference may be due to a variety of reasons:
Delineating an important point
Emphasizing some area of concern
Clarifying a critical area
etc.
An architectural perspective is a non-empty set of types of architectural design decisions.
e.g.
“structural” perspective
“deployment” perspective
“relational” perspective

12. Some Terminologies and Definitions
We have loosely used some terms earlier; we will define and clarify the following terms:
Component
Connector
Configuration
Architectural Style
Architectural Pattern
Architectural model
Recovery Process
Stakeholders (architects, developers, testers, customers, etc)

13. Component
In looking at a software system, we considered what are the “key” elements (building blocks) of the system in terms of:
Processing (functionality or behavior)
States (data or information)
Interaction (communication, coordination, etc.)
The key elements that contain a) processing and b) states are the main components of the system
A software component is an architectural element that:
Encapsulates a subset of the functionalities and/or data,
Restricts access to the element through explicitly defined interface, and
Has explicitly defined dependencies on execution context

14. Some characteristics of a component:
Component (cont.)
Some characteristics of a component:
Architectural components often are derived directly from functional requirements (possibly in aggregated form)
It can be “seen” from outside only through its interface
Explicitly define its execution context:
Other required components
Resources such as data files and directories needed
Required system resources, programming language, etc.
Required hardware configuration
Components are often related to some application domain or are considered application specific.
Some are common utilities that may be utilized across different application domains.

15. Connectors
Connectors, like components, are key building blocks of a system. Where components handled a) functionality and b) data, connectors handle c) interactions.
A Software Connector is an architectural element responsible for regulating and effecting the interactions among components.
Connectors come in many different forms, some of the simple ones are:
Procedure call (synchronous or asynchronous and distributed)
Shared data access (database or a “global” variable)
Adaptor (connect pre-existing components)
Connectors, different from components, are mostly application independent

16. Configuration
Components and connectors are composed (related/associated) in some specific fashion to accomplish an objective. That composition represents the system’s configuration.
An architectural configuration is a set of specific associations among the components and connectors of a software system.
A configuration shows the “connectivity” and “path” but we also need to have compatible interfaces for the components and connectors to function together.

17. Architectural Styles
It has been found that certain sets of design decisions regularly result in solutions with desired specific properties. These design decisions are captured as architecture/design styles which may be reused.
An architectural style is a named collection of general architectural design decisions that:
Are applicable in a given development context
Constrain architectural design decisions that are specific to that particular system within the context
Elicit beneficial qualities in each resulting system

18. Example: Discussion on “Style” of Design
Separation of concern is a good design prescription , but the design should be brought to the same level of depth.
True
False
True
False
multiple statements
to perform
the “true” case
Call “true”
processing method
Call “false”
processing method
Call “false”
processing method
“prescribed” style of
“same level” design
“described” style of
“same level” design

19. Architectural Patterns
While architectural styles provide a set of general design decisions that need to be refined to more specific decisions in order to be applied to the software system, architectural patterns are more specific sets of design decisions.
An architectural pattern is a named collection of architectural design decisions that are:
applicable to recurring design problems,
parameterized to account for different software development context in which that problem appears.
Architectural Pattern and Style are very similar but differ in at least 3 ways:(p 74 of your text calls 3-tier architecture a pattern – some calls it a style)
Scope: style applies to development context while pattern addresses a specific, concrete problem
Abstraction: style helps in constraining the decisions but in an abstract way while patterns are parameterized, concrete design decisions
Relationship: a pattern may be parameterized and used in multiple styles and a style may use multiple patterns.

20. Models
We capture, specify, and analyze the architecture (principal design decisions) with a model.
An architectural model is an artifact (abstraction-my word) that captures some or all of the design decisions that comprise a systems architecture. Architectural modeling is the reification (specification–my word) and documentation of those design decisions
We use different modeling notations or languages to represent the model. (some formal and others are informal and graphical)

21. Architectural Recovery Process
Earlier we discussed architectural degradation where the prescriptive and descriptive architectures of the software system diverge after a period of time. Often times, we will need to retrace and reverse engineer the descriptive architecture from the implementation (code) before we can build a follow-on product release. (Still missing the more important prescriptive architecture)
Architectural recovery is the process of determining a software system’s architecture from its implementation. (Note that what we recover is the descriptive architecture --- we will need to ask or “guess” what the prescriptive architecture is)