What is Software Architecture?

1
What is Software Architecture?
Chapter 2, Authors Len Bass, Paul, Rick Page
Numbers 19-45
2
System description of Acoustic Simulation
3
What Software Architecture Is and What It Isn't

• What is the nature of the elements?
• What is the significance of separation?
• Do they run on separate processors?
• Do they run at separate times?
• Do the elements consist of processes, programs or
  both?
• Are they objects, task, functions, processes,
  distributed programs,
• What are the responsibilities of the elements?
• What is it they do?
• What is their function in the system?
• What is 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, share some information hiding
  secret with each other,
• What information flows across the mechanism?
• What is the significance of the layout?
• Why is CP on a separate level?
• Does it call the other three?
• Are others not allowed to call?

4
Architecture Definition

• The Software Architecture is a structure or
  structures of the system, which comprise software
  elements, the externally visible properties of
  those elements, and the relationships between them

5
Architecture Definition

• externally visible properties -
• assumptions other elements can make of an
  element, such as its provided services,
  performance characteristics, fault handling,
  shared resources usage

6
Architecture Definition observation

• Architecture defines software elements
• The architecture represents information about
  how the elements relate to each other.
• An architecture is foremost an abstraction of a
  system that suppresses details of elements that
  do not affect how they use, are used by, relate
  to, or interact with other elements.

7
Architecture Definition observation

• Systems can and do comprise more than one
  structure
• All nontrivial projects are partitioned into
  implementation units these units are given
  specific responsibilities and are frequently the
  basis of work assignments for programming teams.

8
Architecture Definition observation

• Every computing system with software has a
  software architecture
• Every system can be shown to comprise elements
  and the relations among them.
• Unfortunately, an architecture can exist
  independently of its description or
  specification, which raises the importance of
  architecture documentation and architecture
  reconstruction

9
Architecture Definition observation

• the behavior of each element is part of the
  architecture
• behavior can be observed from the point of view
  of another element.

10
Architecture Definition observation

• the definition is indifferent as to whether
  the architecture for a system is a good one or a
  bad one
• meaning that it will allow or prevent the system
  from meeting its behavioral, performance, and
  life-cycle requirements.
• We do not accept trial and error as the best way
  to choose an architecture for a system

11
Other Points of View

• 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 evolution over time
• Architecture is components and connectors

12

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
• Set of constraints on an architecture
• Example-C/S architecture.

13
Reference Models

• A reference model is a division of functionality
  together with data flow between the pieces.
• It is standard decomposition of a known problem
  into parts that solves problem cooperatively
• Ex OSI reference model..

14
Reference Architectures

• A reference architecture is a reference model
  mapped onto software elements (that cooperatively
  implement the functionality defined in the
  reference model) and the data flows between them
• Reference model divides the functionality.
• A reference architecture is the mapping of that
  functionality on to a system decomposition.

15
Architecture useful concepts
Reference model
Reference architecture
Software architecture
Architectural pattern
16
Why is Software Architecture Important?

• Communication among stakeholders
• -SA represents a common abstraction of a system.
• -used as a basis for mutual understanding,
  negotiation, compromise, and communication by the
  stakeholders.

17
Why is Software Architecture Important?

• 2. Early design decisions
• Architecture represents earliest set of
  decisions about system, they are most difficult
  to get correct and the hardest to change.
• It is the earliest point at which design
  decisions can be analyzed.

18
Why is Software Architecture Important?

• 3. Transferable abstractions of a system
• Architecture is a relatively small model for how
  a system is structured and how its elements work
  together and this is transferable across systems.
• It can be applied to other systems exhibiting
  similar functional requirements.

19




ARCHITECTURE IS THE VEHICLE FOR STAKEHOLDER
COMMUNICATION

• Each stakeholder of a software system (customer,
  user, project, manager, coder, tester) is
  concerned with different system characteristics
  that are affected by the architecture.
• User is concerned that system is reliable
  available.
• Customer is concerned about schedule budget.
• Manager teams should work independently.
• Architect worried about strategies to achieve
  goals.

20

• Architecture provides a common language in which
  different concerns can be expressed, negotiated,
  and resolved at a level that is intellectually
  manageable even for large, complex systems

21
Architectural Structures and Views

• A structure is the set of elements.
• view It is a representation of set of
  architecture elements, as written by and read by
  system stakeholder.
• It consist of representation of a set of
  elements and the relations among them

22
Architectural Structures

• - module structures
• basic elements are modules.
• they are assigned areas of functional
  responsibility.
• Module allow us answer
• What is the primary responsibility of module?
• What other software does it use?

23

• - component-and-connector structures
• elements are run-time components (units of
  computation) and
• connectors (communication vehicles).
• What are the major components how do they
  interact?
• How does data progress through the system?
• - allocation structures
• shows the relationship between the software
  elements and the
• elements in external environment in which
  software is
• created and executed
• What is the assignment of S/W elements to
  development team

24
Architectural Structures Module
module
decomposition
uses
class
layered
25
Architectural Structures Component-and-Connector
component-and-connector
client-server
shared data
process
concurrency
26
Architectural Structures Allocation
allocation
Work assignment
implementation
deployment
27
Architectural Structures Module

• Decomposition
• Units are modules related to each other by is a
  sub module of relation.
• Shows how larger modules are decomposed into
  smaller modules recursively till the smaller
  modules are easily understood.
• Modules have associated products (code, test
  plans).
• Provides modifiability, by ensuring that changes
  to small modules.
• Used for project structuring also for integration
  test plans.
• Uses
• Structure are modules or procedures.
• Relation is uses.
• One unit uses another if the correctness of the
  first requires the presence of a correct version
  of second.

28

• Layered
• If the Uses relation is carefully controlled the
  a system of layer comes in picture.
• If there are n layers. Then the nth layer will
  use only service from layer n-1.
• Layers are often designed as abstractions hide
  implementation specifics below from the layers
  above.
• Class
• module units are called classes
• Relation is inherts- from
• Collection of similar behavior.
• This allows us to reason about reuse and
  additional functionality.

29
Architectural Structures Component-and-Connector

• Process or communicating processes
• Deals with dynamic aspects of a running system.
• Units here are processes or threads which
  communicate, synchronize with each other.
• The relation is attachment how components and
  connecters are linked together.
• Concurrency
• Allows the architects to determine the
  opportunities for parallelism.
• Units are components and connecters are logical
  threads
• Logical thread is a sequence of computation, that
  can be allocated to a separate physical thread in
  design process.

30

• Shared data or repository
• The structure comprises components and connecters
  that create, store and access data
• It shows how data is produced and consumed by run
  time software element.
• It is used for good performance and data
  integrity.
• Client and server
• Built as a group of cooperating clients and
  servers.
• Components are clients and servers Connecters
  are protocols and messages
• Used for load balancing( supporting run time
  performance) and physical distribution.

31
Architectural Structures Allocation

• Deployment
• Shows how software is assigned to hardware
  processing and communication elements.
• The elements are software, hardware, and
  communication pathways.
• Relations are allocated to (shows which
  physical units are assigns to software elements),
  and migrates to (if allocation is dynamic)
• Helps to understand the performance
  ,availability, security.
• Implementation
• shows how software elements are mapped to file
  structures in the systems development,
  integration.
• This is critical for management of development
  activities.

32

• Work assignment
• This structure assigns responsibility for
  implementing and integrating the modules to
  appropriate development teams.
• This structure which is the part of the
  architecture makes it clear about the decisions
  who does the work.
• The architect will know the expertise required on
  each team.

33
Architectural Structures Module
Software structure Relations Useful For Reason About
Decomposition is a sub module, shares secrets with resource allocation, project structuring and planning, information hiding, encapsulation, configuration control
Uses requires the correct presence of extension or extraction of functionality
layered requires the correct presence of, uses the rvices of, provides abstraction to incremental development, implementing systems on top of virtual machines
Class is an instance of, shares access methods of in OO producing rapid almost-alike implementations from a common template
34
Architectural Structures Component-Connector
Software structure Relations Useful For Reason About
client-server communicates with, depends on distributed operation, separation of concerns, performance, load balancing
process runs concurrently with, may run concurrently with, excludes, precedes scheduling, performance
concurrency runs on the same logical thread locations where resource contention exists, where threads may fork, join, be created or killed
shared data produces data, consumes data performance, data integrity, modifiability
35
Architectural Structures Allocation
Software structure Relations Useful For Reason About
deployment allocated to, migrated to performance, availability, security
implementation stored in configuration control, integration, test activities
work assignment assigned to project management, best use of expertise, management of commonality