Software Architecture Foundations Theory and Practice Basic Concepts

Software Architecture Foundations, Theory, and Practice What is Software Architecture? l l l Definition: u A software system’s architecture is the set of principal design decisions about the system Software architecture is the blueprint for a software system’s construction and evolution Design decisions encompass every facet of the system under development u u Structure i. e The architectural elements should be organized and composed like this… Behavior i. e Date processing, storage, and visualization will be performed in strict sequence Interaction i. e communication among all system elements will occur only using notifications Non-functional properties i. e The system’s dependability will be ensured by replicated processing modules 2

Software Architecture Foundations, Theory, and Practice What is “Principal”? l l “Principal” implies a degree of importance that grants a design decision “architectural status” u It implies that not all design decisions are architectural u That is, they do not necessarily impact a system’s architecture How one defines “principal” will depend on what the stakeholders define as the system goals 3

Software Architecture Foundations, Theory, and Practice Other Definitions of Software Architecture l Perry and Wolf u Software Architecture = { Elements, Form, Rationale } what l l how why Shaw and Garlan u Software architecture [is a level of design that] involves l the description of elements from which systems are built, l interactions among those elements, l patterns that guide their composition, and l constraints on these patterns. Kruchten u Software architecture deals with the design and implementation of the high-level structure of software. u Architecture deals with abstraction, decomposition, style, and aesthetics. 4

Software Architecture Foundations, Theory, and Practice Temporal Aspect l l l Design decisions are and unmade over a system’s lifetime Architecture has a temporal aspect At any given point in time the system has only one architecture A system’s architecture will change over time 5

Software Architecture Foundations, Theory, and Practice Prescriptive vs. Descriptive Architecture l l A system’s prescriptive architecture captures the design decisions made prior to the system’s construction u It is the as-conceived or as-intended architecture A system’s descriptive architecture describes how the system has been built u It is the as-implemented or as-realized architecture 6

Software Architecture Foundations, Theory, and Practice Two Architectures Side-by-Side § § Which architecture is “correct”? Are the two architectures consistent with one another? What criteria are used to establish the consistency between the two architectures? On what information is the answer to the preceding questions based? Prescriptive Architecture Descriptive Architecture

Software Architecture Foundations, Theory, and Practice Architectural Evolution l l l When a system evolves, ideally its prescriptive architecture is modified first In practice, the system – and thus its descriptive architecture – is often directly modified This happens because of u Developer sloppiness u Perception of short deadlines which prevent thinking through and documenting u Lack of documented prescriptive architecture u Need or desire for code optimizations u Inadequate techniques or tool support 8

Software Architecture Foundations, Theory, and Practice Architectural Degradation l l l Two related concepts u Architectural drift u Architectural erosion Architectural drift is introduction of principal design decisions into a system’s descriptive architecture that u are not included in, encompassed by, or implied by the prescriptive architecture u but which do not violate any of the prescriptive architecture’s design decisions Architectural erosion is the introduction of architectural design decisions into a system’s descriptive architecture that violate its prescriptive architecture 9

Software Architecture Foundations, Theory, and Practice Architectural Recovery l l l If architectural degradation is allowed to occur, one will be forced to recover the system’s architecture sooner or later Architectural recovery is the process of determining a software system’s architecture from its implementationlevel artifacts Implementation-level artifacts can be u Source code u Executable files u Java. class files 10

Software Architecture Foundations, Theory, and Practice Implementation-Level View of an Application 11 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture Foundations, Theory, and Practice Implementation-Level View of an Application Complex and virtually incomprehensible! 12 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture Foundations, Theory, and Practice What about “Real” Examples? Linux – Prescriptive Architecture Linux – Descriptive Architecture

Software Architecture Foundations, Theory, and Practice Top-Level Architecture – Another View 14

Software Architecture Foundations, Theory, and Practice Memory Manager Subsystem 15

Software Architecture Foundations, Theory, and Practice Another Example i. RODS – Prescriptive Architecture i. RODS – Descriptive Architecture

Software Architecture Foundations, Theory, and Practice And Another Hadoop Distributed File System – Prescriptive Architecture 17 HDFS – Descriptive Architecture

Software Architecture Foundations, Theory, and Practice Hadoop – HDFS + Map. Reduce

Software Architecture Foundations, Theory, and Practice Hadoop – Complete Architecture

Software Architecture Foundations, Theory, and Practice Hadoop – Complete Architecture Another View

Software Architecture Foundations, Theory, and Practice Another Example – bash Top-Level Architecture

Software Architecture Foundations, Theory, and Practice bash – Job Control Component

Software Architecture Foundations, Theory, and Practice bash – Commands Component

Software Architecture Foundations, Theory, and Practice Deployment l A software system cannot fulfill its purpose until it is deployed Executable modules are physically placed on the hardware devices on which they are supposed to run The deployment view of an architecture can be critical in assessing whether the system will be able to satisfy its requirements Possible assessment dimensions u Available memory u Power consumption u Required network bandwidth u l l 24

Software Architecture Foundations, Theory, and Practice A System’s Deployment Architectural Perspective 25 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture Foundations, Theory, and Practice Software Architecture’s Elements l l A software system’s architecture typically is not (and should not be) a uniform monolith A software system’s architecture should be a composition and interplay of different elements u Processing u Data, also referred as information or state u Interaction 26

Software Architecture Foundations, Theory, and Practice Components l Elements that encapsulate processing and data in a system’s architecture are referred to as software components l l Definition u A software component is an architectural entity that l encapsulates a subset of the system’s functionality and/or data l restricts access to that subset via an explicitly defined interface l has explicitly defined dependencies on its required execution context Components typically provide application-specific services 27

Software Architecture Foundations, Theory, and Practice Components The extent of the context captured by a component can include : l The component’s required interface, that is , the interface to services provided by other components in a system on which this component depends. l The availability of specific resources, such as data files or directories, on which the component relies. l The required system software, such as programming language run time environments, middleware platforms, operating systems, network protocols, device drivers, and so on. l The hardware configurations needed to execute the component. 28

Software Architecture Foundations, Theory, and Practice Connectors l l In complex systems interaction may become more important and challenging than the functionality of the individual components Definition u A software connector is an architectural building block tasked with effecting and regulating interactions among components In many software systems connectors are usually simple procedure calls or shared data accesses u Much more sophisticated and complex connectors are possible! Connectors typically provide application-independent interaction facilities 29

Software Architecture Foundations, Theory, and Practice Examples of Connectors l l l Procedure call connectors Shared memory connectors Message passing connectors Streaming connectors Distribution connectors Wrapper/adaptor connectors 30

Software Architecture Foundations, Theory, and Practice Configurations l l Components and connectors are composed in a specific way in a given system’s architecture to accomplish that system’s objective Definition u An architectural configuration, or topology, is a set of specific associations between the components and connectors of a software system’s architecture 31

Software Architecture Foundations, Theory, and Practice An Example Configuration 32 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture Foundations, Theory, and Practice Architectural Styles l l Certain design choices regularly result in solutions with superior properties u Compared to other possible alternatives, solutions such as this are more elegant, effective, efficient, dependable, evolvable, scalable, and so on Definition u An architectural style is a named collection of architectural design decisions that l are applicable in a given development context l constrain architectural design decisions that are specific to a particular system within that context l elicit beneficial qualities in each resulting system 33

Software Architecture Foundations, Theory, and Practice Architectural Patterns l Definition u An architectural pattern is a set of architectural design decisions that are applicable to a recurring design problem and parameterized to account for different software development contexts in which that problem appears 34

Software Architecture Foundations, Theory, and Practice Architectural Patterns In general style and patterns differ in at least three important ways: l. Scope : -An architectural style applies to a development context (for example, “highly distributed systems” or “GUIintensive”) -While an architectural pattern applies to a specific design problem (for example, “The system’s business logic must be separated from data management”). -Architectural styles are strategic while patterns are tactical design tools. 35

Software Architecture Foundations, Theory, and Practice Architectural Patterns l Abstraction: - A styles helps to constrain the architectural design decisions one makes about a system. - However, styles require human interpretation - Patterns are parameterized architectural fragments that can be thought of as concrete pieces of a design. l Relationship : - A single pattern could be applied to systems designed according to the guidelines of multiple styles. - A system designed according to the rules of a single style may involve the use of multiple patterns. 36

Software Architecture l Foundations, Theory, and Practice A widely used pattern in modern distributed systems is the three-tiered system pattern u Science u Banking u E-commerce u Reservation systems 37

Software Architecture Foundations, Theory, and Practice Three-Tiered Pattern l Front Tier u l Middle Tier u l Contains the user interface functionality to access the system’s services Contains the application’s major functionality Back Tier u Contains the application’s data access and storage functionality 38 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture Foundations, Theory, and Practice Architectural Models, Views, and Visualizations l l l Architecture Model u An artifact documenting some or all of the architectural design decisions about a system Architecture Visualization u A way of depicting some or all of the architectural design decisions about a system to a stakeholder Architecture View u A subset of related architectural design decisions 39

Software Architecture Foundations, Theory, and Practice Architectural Processes l l l l Architectural design (Chapter 4) Architecture modeling and visualization (Chapter 6 -7) Architecture-driven system analysis (Chapter 8) Architecture-driven system implementation (Chapter 9) Architecture-driven system deployment, runtime redeployment, and mobility (Chapter 10) Architecture-based design for non-functional properties, including security and trust (Chapter 12 -13) Architectural adaptation (Chapter 14) 40

Software Architecture Foundations, Theory, and Practice Stakeholders in a System’s Architecture l l l l Architects Developers Testers Managers Customers Users Vendors 41