What is software architecture
Download
1 / 34

What is Software Architecture - PowerPoint PPT Presentation


  • 289 Views
  • Updated On :

What is Software Architecture? An Example Architecture??? Control Process (CP) Prop Loss Model (MODP) Reverb Model (MODR) Noise Model (MODN) Why Can the Previous Diagram Be Called an Architecture? It identifies components It indicates relationships among the components.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'What is Software Architecture' - paul2


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

An example architecture l.jpg
An Example Architecture???

Control

Process

(CP)

Prop Loss

Model

(MODP)

Reverb

Model

(MODR)

Noise

Model

(MODN)


Why can the previous diagram be called an architecture l.jpg
Why Can the Previous Diagram Be Called an Architecture?

  • It identifies components

  • It indicates relationships among the components.


What does this picture fail to show l.jpg
What Does this Picture Fail to Show?

  • The nature of the elements

    • What is the significance of their separation?

    • Do they run on separate processors?

    • Do they run at different times?

    • Do they represent ways in which the project labor will be divided?

    • Are they objects, tasks, functions, processes, programs, or something else?


What does this picture fail to show cont d l.jpg
What Does this Picture Fail to Show? (Cont’d)

  • The responsibilities of the elements

    • What do they do?

    • What is their function in the system?

  • The significance of the connections

    • Do the connections mean that the elements communicate with each other, control each other, send data to each other, use each other, invoke each other, synchronize with each other, share some information-hiding secret with each other, or some combination of these relations?


What does this picture fail to show cont d6 l.jpg
What Does this Picture Fail to Show? (Cont’d)

  • The significance of the layout

    • Why is CP on a separate level?

    • Does it call the other three elements, and are they not allowed to call it?

    • Does it contain the other three in an implementation unit sense?


Definition of a software architecture l.jpg
Definition of a Software Architecture

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.


Architectures affect the factors that influence them l.jpg
Architectures Affect the Factors that Influence Them

  • The architecture affects the structure of the developing organization.

  • The architecture can affect the goals of the developing organization.

  • The architecture can affect customer requirements for the next system.

  • The architecture will affect the architectures of future systems.

  • The architecture may affect the software engineering culture.


Software architecture specifics l.jpg
Software Architecture Specifics

  • Architecture defines software elements.

    • It embodies information about how the elements relate to each other.

    • It is an abstraction, i.e., it omits certain information about the elements that does not pertain to their interaction.

  • Architecture is a not a single structure, but a collection of structures

    • E.g., runtime vs. implementation


Software architecture specifics cont d l.jpg
Software Architecture Specifics (Cont’d)

  • All computing systems have architectures.

    • They may not be known to anyone.

    • The architecture of a system is different from its representation.

  • The behavior of each element is part of the architecture.

    • The behavior, and only the behavior, that influences how another element interacts with it or influences the system as a whole, is part of the software architecture.


Software architecture specifics cont d11 l.jpg
Software Architecture Specifics (Cont’d)

  • Architectures can be good or bad.

    • The careful design and evaluation of architectures is essential for producing good architectures.


Other definitions of software architecture l.jpg
Other Definitions of Software Architecture

  • Architecture is high level design.

  • Architecture is the overall structure of the system.

  • Architecture is the structure of the components of a program or system, their interrelationships, and the principles and guidelines governing their design and evaluation over time.

  • Architecture is components and connectors


Architectural patterns l.jpg
Architectural Patterns

  • An architectural pattern is a description of element and relation types together with a set of constraints on how they may be used.

  • Client-server is an example of an architectural pattern.

  • Picking a pattern is often the architects first major design choice.


Reference models l.jpg
Reference Models

  • A reference model is a division of functionality together with data flows between the pieces.

  • For example a database management system might have a reference model.

  • It is a standard division of a known problem into parts that cooperatively solve the problem.


Reference architecture l.jpg
Reference Architecture

  • A reference architecture is a reference model mapped onto software elements and the data flows between them.

  • The software elements cooperatively implement the functionality defined in the reference model.

  • That is,it maps the functionality of a reference model onto a system decomposition.


From models and patterns to architecture l.jpg
From Models and Patterns to Architecture

Reference

Model

Reference

Architecture

Software

Architecture

Architectural

Pattern


Why is software architecture important l.jpg
Why is Software Architecture Important?

  • Communication among stakeholders

  • Early design decisions

  • Transferable abstraction of a system


Stakeholder communication l.jpg
Stakeholder Communication

  • Different stakeholders are concerned with different system characteristics.

  • Architecture provides a common language in which different concerns can be expressed, negotiated and resolved.


Early design decisions l.jpg
Early Design Decisions

  • These are the most difficult to get correct.

  • They are the hardest to change later in the development process.

  • They have the most far-reaching effects.


Early design decisions20 l.jpg
Early Design Decisions

  • The architecture defines constraints on implementation.

  • The architecture dictates organizational structure.

  • The architecture inhibits or enables a system’s quality attributes.

  • Predicting system qualities by studying architecture.


Early design decisions cont d l.jpg
Early Design Decisions (Cont’d)

  • The architecture makes it easier to reason about and manage change.

  • The architecture helps in evolutionary prototyping.

  • The architecture enables more accurate cost and schedule estimates.


Transferability re usability l.jpg
Transferability/Re-usability

  • Software product lines share a common architecture.

  • Systems can be built using large, externally developed elements.

  • Less is more: it pays to restrict the vocabulary of design alternatives.

  • An architecture permits template-based development.

  • An architecture can be the basis for training.


Architectural views and structures l.jpg
Architectural Views and Structures

  • Architectural structures can be divided into three groups

    • Module structures – How is the system to be structured as a set of code units?

    • Component-and-connector structures – How is the system to be structured as a set of elements that have running behavior and interactions?

    • Allocation structures – How is the system to relate to nonsoftware structures in its environment?


Common software architecture structures l.jpg
Common Software Architecture Structures

Component-

And-Connector

Module

Allocation

Client-

Server

Shared

Data

Decomposition

Process

Class

Deployment

Uses

Concurrency

Implementation

Layered

Work

Assignment


Module based structures l.jpg
Module-Based Structures

  • Decomposition – the units are modules related by the “is a submodule of” relation.

  • Uses – the units are modules, procedures or resources on the interfaces of modules related by the “uses” relation.

  • Layered – when the uses relations are controlled in a particular way a system of layers emerges in which layer is a coherent set of related functionality.


Module based structures cont d l.jpg
Module-Based Structures (Cont’d)

  • Class or Generalization – the module units are classes and the relation is “inherits-from or “is-an-instance of”.


Component and connector structures l.jpg
Component-and-Connector Structures

  • Process or Communicating Processes– deals with the dynamic aspects of a running system and the relation is “attachment”. It shows how processes (the units) are connected by communication, synchronization, and/or exclusion operations.

  • Currency – the units are components and the connectors are “logical threads”. It allows determination of opportunities for parallelism and locations of resource contention.


Component and connector structures cont d l.jpg
Component-and-Connector Structures (Cont’d)

  • Shared Data or repository – comprises components and connectors that create store and access persistent data.

  • Client-Server – components are the clients and servers and the connectors are the protocols and messages they share.


Allocation structures l.jpg
Allocation Structures

  • Deployment – shows how software is assigned to hardware-processing and communication elements and the relations are “allocated to” and “migrate to”.

  • Implementation – shows how software elements (modules) are mapped to the file structure(s) in the system’s development, integration, or configuration control environments.


Allocation structures cont d l.jpg
Allocation Structures (Cont’d)

  • Work Assignment – assigns responsibility for implementing and integrating the modules to the appropriate development teams.


Relating structures to each other l.jpg
Relating Structures to Each Other

  • Each of these structures provides a different perspective and design handle on a system.

  • Each is valid and potentially useful in its own right

  • They are not independent but highly interrelated.

  • Often the module structure is dominant, but not always.


Relating structures to each other cont d l.jpg
Relating Structures to Each Other (Cont’d)

  • Not all systems warrant consideration of many architectural structures.

  • The larger the systems the more dramatic the differences between these structures tend to be.

  • Structures represent the primary engineering leverage point for satisfying quality attributes.

  • Multiple structures represent a powerful separation-of-concerns approach for creating the architecture.


Which structures to choose l.jpg
Which Structures to Choose?

  • Kruchten’s “four plus one” approach recommends four views (structures):

    • Logical – the elements are “key abstractions” (a module structure)

    • Process – addresses concurrency and distribution of functionality (a component-and-connector structure)

    • Development – organization of software modules, libraries, subsystems, and units of development (an allocation structure)


Which structures to choose cont d l.jpg
Which Structures to Choose? (Cont’d)

  • Kruchten’s approach (cont’d):

    • Physical – maps elements onto processing and communication nodes (a deployment view)

  • The “plus one” is a a set of key use cases that serve to validate that the structures are not in conflict with each other and together describe a system meeting its requirements.


ad