What is Software Architecture

1
What is Software Architecture?
2
An Example Architecture???
Control Process (CP)
Reverb Model (MODR)
Prop Loss Model (MODP)
Noise Model (MODN)
3
Why Can the Previous Diagram Be Called an
Architecture?

• It identifies components
• It indicates relationships among the components.

4
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?

5
What Does this Picture Fail to Show? (Contd)

• 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?

6
What Does this Picture Fail to Show? (Contd)

• 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?

7
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.

8
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.

9
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

10
Software Architecture Specifics (Contd)

• 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.

11
Software Architecture Specifics (Contd)

• Architectures can be good or bad.
• The careful design and evaluation of
  architectures is essential for producing good
  architectures.

12
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

13
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.

14
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.

15
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.

16
From Models and Patterns to Architecture
Reference Model
Reference Architecture
Software Architecture
Architectural Pattern
17
Why is Software Important?

• Communication among stakeholders
• Early design decisions
• Transferable abstraction of a system

18
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.

19
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.

20
Early Design Decisions

• The architecture defines constraints on
  implementation.
• The architecture dictates organizational
  structure.
• The architecture inhibits on enables a systems
  quality attributes.
• Predicting system qualities by studying
  architecture.

21
Early Design Decisions (Contd)

• 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.

22
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.

23
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?

24
Common Software Architecture Structures
Component- And-Connector
Module
Allocation
Client- Server
Shared Data
Decomposition
Process
Class
Deployment
Uses
Concurrency
Implementation
Layered
Work Assignment
25
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.

26
Module-Based Structures (Contd)

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

27
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.

28
Component-and-Connector Structures (Contd)

• 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.

29
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 systems development, integration, or
  configuration control environments.

30
Allocation Structures (Contd)

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

31
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.

32
Relating Structures to Each Other (Contd)

• Not all systems warrant consideration of may
  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.

33
Which Structures to Choose?

• Kruchtens 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)

34
Which Structures to Choose? (Contd)

• Kruchtens approach (contd)
• 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.