Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: (1) analyze the effectiveness of the design in meeting its stated requirements, (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and (3) reduce the risks associated with the construction of the software. Why is Architecture Important? = Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system. = The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity. = Architecture “constitutes a relatively small, intellectually graspable mode of how the system is structured and how its components work together” [BAS03].Architectural Descriptions = The IEEE Computer Society has proposed IEEE-Std- 1471-2000, Recommended Practice for Architectural Description of Software-Intensive System, [IEE00] = to establish a conceptual framework and vocabulary for use during the design of software architecture, = to provide detailed guidelines for representing an architectural description, and = to encourage sound architectural design practices. = The IEEE Standard defines an architectural description (AD) as a “a collection of products to document an architecture.” = The description itself is represented using multiple views, where each view is “a representation of a whole system from the perspective of a related set of [stakeholder] concerns.” Architectural Genres = Genre implies a specific category within the overall software domain. = Within each category, you encounter a number of subcategories. = For example, within the genre of buildings, you would encounter the following general styles: houses, condos, apartment buildings, office buildings, industrial building, warehouses, and so on. = Within each general style, more specific styles might apply. Each style would have a structure that can be described using a set of predictable patterns.Architectural Styles Each style describes a system category that encompasses: (1) a set of components (e.g., a database, computational modules) that perform a function required by a system, (2) a set of connectors that enable “communication, coordination and cooperation” among components, (3) constraints that define how components can be integrated to form the system, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts. Data-centered architectures = Data flow architectures = Call and return architectures = Object-oriented architectures = Layered architectures Data-Centered Architecture oilent cient sofware sotwere cient sofware colent A= lent software Daw stre lropcei ery or sch board client softvare cient ient shew sofware:Data Flow Architecture (@) jipes and fiters te tier | pet iter | pel fier >| fer > (©) ath sequentialCall and Return Architecture fan-out a | b c on = Hoe AN ‘|(o) fh 2) (el (el a fan-in LJ G width Layered ArchitectureArchitectural Patterns = Concurrency—applications must handle multiple tasks in a manner that simulates parallelism = operating system process managementpattern = task scheduler pattern = Persistence—Data persists if it survives past the execution of the process that created it. Two patterns are common: = a database management system pattern that applies the storage and retrieval capability of a DBMS to the application architecture = an appiication level persisience pattern that builds persistence features into the application architecture = Distribution— the manner in which systems or components within systems communicate with one another in a distributed environment = A broker acts as a ‘middle-man’ between the client component and a server component. Architectural Design = The software must be placed into context = the design should define the external entities (other systems, devices, people) that the software interacts with and the nature of the interaction = Aset of architectural archetypes should be identified = An archetype is an abstraction (similar to a class) that represents one element of system behavior = The designer specifies the structure of the system by defining and refining software components that implement each archetypeArchitectural Context Satehome Internet-based Product system pane! target system: suneillance | function SecuttyFunction homeownerArchetypesComponent StructureRefined Component StructureArchitectural Considerations = Economy — The best software is uncluttered and relies on abstraction to reduce unnecessary detail. = Visibility — Architectural decisions and the reasons for them should be obvious to software engineers who examine the model at a later time. = Spacing — Separation of concerns in a design without introducing hidden dependencies. = Symmetry — Architectural symmetry implies that a system is consistent and balanced in its attributes. = Emergence — Emergent, self-organized behavior and control