1. Architectural Design
Establishing the overall structure of a software system
Objectives
To introduce architectural design and to discuss its importance
To explain why multiple models are required to document a software architecture
To describe types of architectural model that may be used

2. What is Architecture? A high-level model of a thing
Describes critical aspects of the thing
Understandable to many stakeholders
Allows evaluation of the thing’s properties before it is built
Provides well understood tools and techniques for constructing the thing from its blueprint
Which aspects of a software system are architecturally relevant?
How should they be represented most effectively to enable stakeholders to understand, reason, and communicate about a system before it is built?
What tools and techniques are useful for implementing an architecture in a manner that preserves its properties?

3. What is Software Architecture?
A software system’s blueprint
Its components
Their interactions
Their interconnections
Informal descriptions
Boxes and lines
Informal prose
A shared, semantically rich vocabulary
Remote procedure calls (RPCs)
Client-Server
Pipe and Filer
Layered
Distributed
Object-Oriented

4. From Requirements to Architecture
From problem definition to requirements specification
Determine exactly what the customer and user want
Specifies what the software product is to do
From requirements specification to architecture
Decompose software into modules with interfaces
Specify high-level behavior, interactions, and non-functional properties
Consider key tradeoffs
Schedule vs. Budget
Cost vs. Robustness
Fault Tolerance vs. Size
Security vs. Speed
Maintain a record of design decisions and traceability
Specifies how the software product is to do its tasks

5. Another View: The Twin Peaks Model

6. Focus of Software Architectures
Two primary foci
System Structure, Behavior, Interactions, Topology, Data, and key Properties
Correspondence between requirements and implementation
A framework for understanding system-level concerns
Global rates of flow
Communication patterns
Execution Control Structure
Scalability
Paths of System Evolution
Capacity
Throughput
Consistency
Component Compatibility

7. Why Software Architecture?
A key to reducing development costs
Component-based development philosophy
Explicit system structure
A natural evolution of design abstractions
Structure and interaction details overshadow the choice of algorithms and data structures in large/complex systems
Benefits of explicit architectures
A framework for satisfying requirements
Technical basis for design
Managerial basis for cost estimation & process management
Effective basis for reuse
Basis for consistency, dependency, and tradeoff analysis
Avoidance of architectural erosion

8. What is the Problem?
This is a simple
software system!

9. The Usual Tool: Design Abstraction
We have to do better!

10. Architectural Abstraction
Components
Connectors
Events

11. What is Software Architecture?
Definition:
A software system’s architecture is the set of principal design decisions about the system
Software architecture is the blueprint for a software system’s construction and evolution
Design decisions encompass every facet of the system under development
Structure
Behavior
Interaction
Non-functional properties

12. Other Definitions of Software Architecture
Perry and Wolf
Software Architecture = { Elements, Form, Rationale }
what how why
Shaw and Garlan
Software architecture [is a level of design that] involves
the description of elements from which systems are built,
interactions among those elements,
patterns that guide their composition, and
constraints on these patterns.
Kruchten
Software architecture deals with the design and implementation of the high-level structure of software.
Architecture deals with abstraction, decomposition, composition, style, and aesthetics.

13. Architectural design process
System structuring
The system is decomposed into several principal sub-systems
Communications between these sub-systems are identified
Control modelling
A model of the control relationships between the different parts of the system is established
Modular decomposition
The identified sub-systems are decomposed into modules

14. Key Architectural Concepts
Three canonical building blocks
components
connectors
configurations
A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems
A module is a system component that provides services to other components but would not normally be considered as a separate system

15. Components A component is a unit of computation or a data store
Components are loci of computation and state
clients
servers
databases
filters
layers
ADTs
A component may be simple or composite
composite components describe a (sub)system
an architecture consisting of composite components describes a system of systems

16. Components
Elements that encapsulate processing and data in a system’s architecture are referred to as software components
Definition
A software component is an architectural entity that
encapsulates a subset of the system’s functionality and/or data
restricts access to that subset via an explicitly defined interface
has explicitly defined dependencies on its required execution context
Components typically provide application-specific services

17. Software components
In most engineering disciplines, systems are designed by composing existing components that have been used in other systems
Software engineering has been more focused on original development
It is now recognized that to achieve
better software
more quickly
at lower cost
we need to adopt a design process that is based on systematic reuse

18. Components
Components provide a service without regard to where the component is executing or its programming language
A component is an independent executable entity that can be made up of one or more executable objects
The component interface is published and all interactions are through the published interface
Components can range in size from simple functions to entire application systems

19. A software component: Implements some functionality
Has explicit dependencies through provided and required interfaces
Communicates through its interfaces only
Has structure and behavior that conforms to a component model

20. LEGO analogy Set of building blocks in different shapes and colors
Can be combined in different ways
Composition through small stubs in one and corresponding holes in another building block
 LEGO blocks are generic and easily composable
LEGO can be combined with LEGO, not with e.g. MEGA Bloks

21. Component abstractions
Functional abstraction
The component implements a single function such as a mathematical function
Casual groupings
The component is a collection of loosely related entities that might be data declarations, functions, etc.
Data abstractions
The component represents a data abstraction or class in an OO language
Cluster abstractions
The component is a group of related classes that work together
System abstraction
The component is an entire self-contained system

22. Why CBSE?
CBSE increases quality, especially evolvability and maintainability
CBSE increases productivity
CBSE shortens development time

23. Hiding of component internals
Black box: only specification is known
Glass box: internals may be inspected, but not changed
Grey box: part of the internals may be inspected, limited modification is allowed
While box: component is open to inspection and modification

24. Development process in CBSE
Two separate development processes:
Development of components
Development of systems out of components
Separate process to assess components

25. CBSE system development process
Requirements: also considers availability of components (as in COTS)
Analysis and design: very similar to what we normally do
Implementation: less coding, focus on selection of components, provision of glue code
Integration: largely automated
Testing: verification of components is necessary
Release: as in classical approaches
Maintenance: replace components

26. Component assessment Find components Verify components
Store components in repository

27. Component development process
Components are intended for reuse 
Managing requirements is more difficult
More effort required to develop reusable components
More effort in documentation for consumers

28. Component development process
Requirements: combination of top-down (from system) and bottom-up (generality)
Analysis and design: generality is an issue, assumptions about system (use) must be made
Implementation: largely determined by component technology
Testing: extensive (no assumptions of usage!), and well-documented
Release: not only executables, also metadata

29. Software Connector Architectural element that models
Interactions among components
Rules that govern those interactions
Simple interactions
Procedure calls
Shared variable access
Complex & semantically rich interactions
Client-server protocols
Database access protocols
Asynchronous event multicast
Each connector provides
Interaction duct(s)
Transfer of control and/or data

30. Where are Connectors in Software Systems?
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

31. Benefits of First-Class Connectors
Separate computation from interaction
Minimize component interdependencies
Support software evolution
At component-, connector-, & system-level
Potential for supporting dynamism
Facilitate heterogeneity
Become points of distribution
Aid system analysis & testing

32. An Example of Explicit Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

33. An Example of Explicit Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

34. Software Connector Roles
Communication
Coordination
Conversion
Facilitation

35. Connector Types Procedure call Data access Event Stream Linkage
Distributor
Arbitrator
Adaptor

36. A Framework for Classifying Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

37. Procedure Call Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

38. Event Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

39. Data Access Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

40. Linkage Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

41. Stream Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

42. Arbitrator Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

43. Adaptor Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

44. Distributor Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

45. How Does One Select a Connector?
Determine a system’s interconnection and interaction needs
Software interconnection models can help
Determine roles to be fulfilled by the system’s connectors
Communication, coordination, conversion, facilitation
For each connector
Determine its appropriate type(s)
Determine its dimensions of interest
Select appropriate values for each dimension
For multi-type, i.e., composite connectors
Determine the atomic connector compatibilities

46. Configurations/Topologies
An architectural configuration or topology is a connected graph of components and connectors that describes architectural structure
proper connectivity
concurrent and distributed properties
adherence to design heuristics and style rules
Composite components are configurations

47. Scope of Software Architectures
Every system has an architecture.
Details of the architecture are a reflection of system requirements and trade-offs made to satisfy them
Possible decision factors
Performance
Compatibility with legacy software
Planning for reuse
Distribution profile
Current and Future
Safety, Security, Fault tolerance requirements
Evolvability Needs
Changes to processing algorithms
Changes to data representation
Modifications to the structure/functionality

48. Example Architecture – Compiler
Sequential
Parallel

49. CASE toolset architecture

50. Version management system

51. Packing robot control system

52. Film and picture library

53. Architecture in Action: Product Line
Motivating example
A consumer is interested in a 35-inch HDTV with a built-in DVD player for the North American market. Such a device might contain upwards of a million lines of embedded software. This particular television/DVD player will be very similar to a 35-inch HDTV without the DVD player, and also to a 35-inch HDTV with a built-in DVD player for the European market, where the TV must be able to handle PAL or SECAM encoded broadcasts, rather than North America’s NTSC format. These closely related televisions will similarly each have a million or more lines of code embedded within them.

54. Growing Sophistication of Consumer Devices

55. Families of Related Products

56. The Necessity and Benefit of PLs
Building each of these TVs from scratch would likely put Philips out of business
Reusing structure, behaviors, and component implementations is increasingly important to successful business practice
It simplifies the software development task
It reduces the development time and cost
it improves the overall system reliability
Recognizing and exploiting commonality and variability across products

57. Reuse as the Big Win Architecture: reuse of Product families: reuse of
Ideas
Knowledge
Patterns
engineering guidance
Well-worn experience
Product families: reuse of
Structure
Behaviors
Implementations
Test suites…

58. Added Benefit – Product Populations

59. The Centerpiece – Architecture

60. Analogies to Software Architecture
Hardware architecture
small number of design elements
scale by replication of (canonical) design elements
Network architecture
focus on topology
only a few topologies considered
e.g., star, ring, grid
Building architecture
multiple views
styles

61. Architectural models
Different architectural models may be produced during the design process
Each model presents different perspectives on the architecture
Static structural model that shows the major system components
Dynamic process model that shows the process structure of the system
Interface model that defines sub-system interfaces
Deployment model shows the relationship between system elements and hosts

62. An Example Static Model
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

63. An example Deployment Model
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

64. Key points
The software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition model
Large systems rarely conform to a single architectural model
Key architectural concepts are components, connectors, and configurations

65. Bibliography
The material of this class come from the Software Engineering class of Ian Sommerville, Nenad Medvidovic, and Han Van Vliet.