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)

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.

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.

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?

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

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

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

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

“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?

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

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

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)

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

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.

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

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.

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

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

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.

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)

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)