Software Architecture

1. Software Architecture

2. Software Architecture • The software architecture of a program or computing system is the structure or structures of the system, which comprise the software components, the externally visible properties of those components, and the relationships among them. — Bass. et al.

3. Why Architecture • The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: • analyze the effectiveness of the design in meeting its stated requirements, • consider architectural alternatives at a stage when making design changes is still relatively easy, and • reduce the risks associated with the construction of the software

4. 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 model of how the system is structured and how its components work together” [BAS03].

5. Architectural Styles • Each style describes a system category that encompasses: • a set of components (e.g., a database, computational modules) that perform a function required by a system, • a set of connectors that enable “communication, coordination and cooperation” among components, • constraints that define how components can be integrated to form the system, and • semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

6. Architectural Styles • Data-centered architectures • Data flow architectures • Call and return architectures • Object-oriented architectures • Layered architectures

7. Data-Centered Architecture

8. More intergrable • Components can be added and removed easily

9. Data Flow Architecture

10. Call and Return Architecture

11. Fan-In How many modules directly control a given module • Fan-Out How many modules are directly controlled by another module

12. Sub styles of call and return architecture • Main Program/Sub Program • Main program is decomposed into sub programs • Remote procedure Call • Components of main/sub program are distributed over network

13. Layered Architecture

14. Architectural Patterns • Concurrency—applications must handle multiple tasks in a manner that simulates parallelism • operating system process management pattern • task schedulerpattern • Persistence—Data persists if it survives past the execution of the process that created it. Two patterns are common: • a database management systempattern that applies the storage and retrieval capability of a DBMS to the application architecture • an application levelpersistencepattern that builds persistence features into the application architecture

15. Architectural Patterns • Distribution— the manner in which systems or components within systems communicate with one another in a distributed environment • The way entities connect to each other • The way of communication • Abroker acts as a ‘middle-man’ between the client component and a server component.

16. Organization and refinementto assess and architecural style • Control • How is control managed? • Distinct control hierarchy? • Components transfer control • Is control synchronized or asynchronous • Data • How do data is communicated • Is flow of data continuous or sporadic • Is their a central repository

17. References • Software Engineering: A Practitioner’s Approach, 6/e • 10.1,10.3 • 11.2.3,11.2.4