SOFTWARE ARCHITECTURE Software Architecture 2 The software architecture

  • Slides: 17
Download presentation
SOFTWARE ARCHITECTURE

SOFTWARE ARCHITECTURE

Software Architecture 2 The software architecture of a program or computing system is the

Software Architecture 2 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.

Why Architecture 3 The architecture is not the operational software. Rather, it is a

Why Architecture 3 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 4 Representations of software architecture an enabler for communication between

Why is Architecture Important 4 Representations of software architecture 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” [BAS 03].

Architectural Styles 5 Each style describes a system category that encompasses: 1. a set

Architectural Styles 5 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.

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

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

Data-Centered Architecture

Data-Centered Architecture

 More intergrable Components can be added and removed easily

More intergrable Components can be added and removed easily

Data Flow Architecture

Data Flow Architecture

Call and Return Architecture

Call and Return Architecture

o o Fan-In How many modules directly control a given module Fan-Out How many

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

Sub styles of call and return architecture Main Program/Sub Program Main program is decomposed

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

Layered Architecture

Layered Architecture

Architectural Patterns Concurrency—applications must handle multiple tasks in a manner that simulates parallelism operating

Architectural Patterns Concurrency—applications must handle multiple tasks in a manner that simulates parallelism operating system process management pattern 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 application level persistence pattern that builds persistence features into the application architecture

Architectural Patterns Distribution— the manner in which systems or components within systems communicate with

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 A broker acts as a ‘middle-man’ between the client component and a server component.

Organization and refinement to assess and architecural style Control How is control managed? Distinct

Organization and refinement to 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

References Software Engineering: A Practitioner’s Approach, 6/e 10. 1, 10. 3 11. 2. 3,

References Software Engineering: A Practitioner’s Approach, 6/e 10. 1, 10. 3 11. 2. 3, 11. 2. 4