Software Architecture CS3300 Fall 2015

Beware the Fuzzy Front End We are already almost 1/3 of the way done Need to negotiate deliverable schedule: SDP SRS In-Class Design Presentation/Review Test Plan (Behavioral and Unit tests under CM) Project Demo and Presentation (Monday Dead Week) Project Post-Mortem (Wednesday Dead Week)

Definition The term software architecture intuitively denotes the high level structures of a software system. It can be defined as the set of structures needed to reason about the software system, which comprise the software elements, the relations between them, and the properties of both elements and relations (Wikpedia)structuressoftware system Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives. (Garlan and Shaw)

Definition Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns. (MSDN)

Definition The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system's lifetime; and, in the end, architecture boils down to whatever the important stuff is. (Martin Fowler) 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. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural (Bass and Clements)

Garlan and Shaw Styles Pipe and Filter ADT Blackboard Master-Controller Event Driven – Implicit Invocation

Architectural Views Looking at different aspects of the architecture. See the model paper. Logical -- Package groupings of classes Process – Threads and Processes Module – Code packages/namespaces/file organization Physical – Devices hosting software components Scenarios – Use cases that illustrate relationships

Physical view - Deployment Or also called a Technical Architecture From Scott Ambler, Elements of UML Style

Deployment Diagram UML

Keys to Success (Booch) Focusing on simplification, minimization, and clarification. Adapting the architecture to future customer needs, technology, competition, and business goals. Establishing a consistent and pervasive architectural rhythm—regular architecture and product releases that help coordinate the actions and expectations of all parties. Partnering and broadening relations with stakeholders. Maintaining a clear architecture vision across the enterprise. Proactively managing risks and opportunities.

Representing Architectures Architectural Description Languages (There are many!!!!) Architecture Analysis and Design Language (AADL paper) Figure 4.2 is graphical notation ACME – an architectural interchange language

Evaluating Architectures Architectures can only be evaluated against quality constraints Steps: Present the ATAM Present Business Drivers (Goals of System) Present Architecture (How does it satisfy goals) Identify Architecture Approaches (styles, subsystems) Generate Quality Attribute Utility Tree Analyze Architecture Approaches Prioritize Scenarios Analyze Architecture Approaches Present Results

Quality Attribute External Stimuli – Events that cause the architecture to respond or change. Architectural Decisions – Components/Connectors/Properties that have direct impact on achieving responses Responses – Observable/Measureable/Concrete

Scenarios Use Case: uses of the system The user wants to examine budgetary and actual data under different fiscal years without re-entering project data. (usability) Growth : anticipated changes to the system Migrate to a new operating system, or a new release of the existing operating system in less than a person-year of work. Exploratory : extreme changes that stress the system Tenfold increase in the number of bids processed hourly while keeping worst-case response time below 10 seconds.

Utility Tree See Figure 3, page 17 of ATAM document Ranked with Importance to System Success, Risk to achieve H,H (High importance, High Risk) L, H (Low importance, High Risk)

Product Line Architectures Establishing Commonality across products when you can. See case study, avionics product line See article: Applying Software Product Line Architectures Product Lines are not: fortuitous, small-grained reuse single-system development with reuse just component-based or service-based development just a reconfigurable architecture releases and versions of single products just a set of technical standards