Relationship to Textbook

• This lecture is partially based on material in Chapter 4 of the Jalote textbook

Software Architecture

• Any complex system is composed of subsystems that interact with one another to provide its intended functionality
• Software architecture is an area of software engineering research aimed at providing tools and techniques for specifying a system's subsystems and their interrelationships
• The level of granularity for software architecture design is at the system level, not the package, module, or class level.
  • For many complex systems, each individual subsystem may itself be a large software system that has its own internal architecture (such as a relational database)
• Software architecture is a relatively recent research area (mid-90s) with an active research community
  • Architecture Description Languages
  • Architecture Modeling Tools
  • Architecture Analysis Tools
  • etc.
• The design of a system's architecture is one of the first places in which specific technologies for realizing/implementing the system are made
  • For instance, its difficult, if not impossible, to design a large system that will require, say, middleware technology or a large-scale relational database, and not specify these components ahead of time
    • As much as we would like to separate design and implementation issues, these types of technologies are expensive and if a company has invested in them, it may not be possible to choose an alternative technology
• The design of a system's architecture is also the earliest phase in which certain non-functional requirements such as security, performance, and reliability can be addressed.
  • For instance, if a system's subsystems must share information using encrypted communication links, this can be specified in the system's architecture model

An Aside

• I was involved in software architecture research as a graduate student
• At UCI, I helped to design and implement the C2 Architectural Style, a style that we created from our work in designing applications with graphical user interfaces.
• That work continued at UCI after I left and Eric Dashofy will be giving a colloquium at CU this week on the most recent results of software architecture research at UCI.
• Finally, Alex Wolf, a former professor here at CU played a key part in the creation of the software architecture research field, publishing (with Dewayne E. Perry) a foundational paper in the area in 1992.

Software Architecture: Two Definitions

• The principled study of software components, including their properties, relationships, and patterns of combination
• Also, a particular set of software components as combined in a particular software system

Intro. to Software Architecture

Intro. to Software Architecture

Intro. to Software Architecture

Intro. to Software Architecture

Intro. to Software Architecture

Intro. to Software Architecture

Intro. to Software Architecture

The Role of Architecture

The Role of Architecture

The Role of Architecture

The Role of Architecture

The Role of Architecture

The Role of Architecture

The Central Planning Phase

The Central Planning Phase

Good Architecture Lowers Cost

Architecture Descriptions

• A complex system can be partitioned in many different ways, each providing a useful view
  • Consider the plans for a building:
    • Blueprints showing overall spatial layout
    • Electrical Plans
    • Plumbing Plans
    • Heating and Cooling
    • 3D Mockups
    • etc.
  • Each view shows a different part of the system and is useful to different stakeholders in the process of creating the building
• The same is true for a software system; there is no unique structure for representing the system

Use of Architecture Descriptions

• Understanding and Communication: an architecture description allows a system's stakeholders to come to a shared understanding of the proposed system
• Reuse: architecture descriptions are useful for identifying components that might be reused across a variety of products within a product family
• Construction and Evolution: An architecture description can be useful for partitioning the work of subsequent design and implementation phases; it is also useful in understanding a system's current state such that modifications can be proposed in a logical fashion
• Analysis: properties can be associated with the components and connections of an architecture description; these properties can then be used to aid the analysis of an architecture to ensure that it is following the rules of its associated architectural style, that its connections are completely specified, etc.

Architecture Views

• A view of an architecture is composed out of a set of elements and the relationships between them
• Three common architectural views are
  • The Module View
  • The Components and Connectors View
  • The Allocation View
• The module view of architecture views a system's architecture as a collection of code units: packages, modules, etc. This view then documents relationships between the various modules and how these modules are combined to create an architecture's components. This view makes no attempt to specify an architecture's run-time characteristics.
• The component and connector view of architecture is the one that has received the most attention from the software architecture research community and is considered the primary way to represent software architectures. It is discussed next.
• The allocation view of architecture attempts to show how software components are allocated across resources, typically machines, but may also include file systems, sensors, people (roles), etc. We get more insight into the runtime characteristics of the proposed system, especially with respect to the system's ecosystem. The Unified Modeling Language (UML) has a notation, known as a deployment diagram, that is useful for depicting allocation views of a software architecture. An example deployment diagram is shown below.
  
  Note: This diagram is an example contained in a book by Scott Ambler known as The Object Primer. It is thus, Copyright © 2003-2006 by Scott Ambler.

Component and Connector View

• Components: Computational elements or data stores
• Connectors: Means of interaction between components
• Useful Metaphor: Consider Polo, Water Polo, and Soccer (aka football in the majority of the world): Similar in processors and data (components), but differ in connectors
• The C&C view describes a graph of components connected via connectors (often displayed as a boxes-and-arrows diagram). It is mainly a runtime view of a system's architecture: what components exist at runtime and how do these components communicate with one another

Components

• Units of computation or data stores
• Has a name, which represents its role, and provides its identity
• A component may have a type; different types are represented by different symbols in a C&C view
• Components use ports (or interfaces) to communicate with other components
• An architecture can use any symbol to represent components
  

Connectors

• Interaction between components happen through connectors
• A connector may be provided by a runtime environment, e.g. a procedure call
• But there may be complex mechanisms for interaction, e.g http, TCP/IP, ports,…; a lot of software may be needed to support a particular type of connection
• Important to identify connectors explicitly, such that later development phases can take them into consideration
• Having connectors defined in the architecture also allows non-functional characteristics that impact a system's communication patterns to be specified
  • For instance, certain connectors can be annotated to indicate that they will use secure protocols to achieve a certain level of security in the system
  • Or, a logging component might be attached to a connector to indicate that the messages that pass over the connector are going to be logged
  • etc.
• Connectors need not be binary, e.g. a broadcast bus
• Each connector has a name and a type
• Often connectors are represented as a communication protocol – i.e. components need to follow particular conventions when using the connector
• Best to use different notations for different types of connectors; connectors should not always be depicted as simple lines
  

Tool Support

• There is an excellent architecture description language and accompanying tool set for creating C&C architectural views, developed at the University of California, Irvine
• Architecture Description Language: xADL 2.0
• Tool Set: ArchStudio 4
• Key Feature: Extensibility. xADL can be extended to define concepts required by a third-parties architectural conventions. ArchStudio can then be extended to display these new concepts and allow them to be edited and analyzed
• These tools have been used in research (USC, UC Irvine, and others) and industry settings (Boeing, NASA JPL, and others)
• Both xADL and ArchStudio are available under open source software licenses. I encourage you to download them and check them out!

An Example

• Design a system for taking an on-line survey of students on campus
  • Multiple choice questions, students submit online
  • When a student submits, current result of the survey is shown
• One implementation choice: A Web-based application using a 3-tier architecture
  • Has a client, server, and database components
  • Connectors between them are also of different types

Initial Architecture

Extension 1

• This arch has no security – anyone can take the survey
• We would prefer that only registered students can take the survey (at most once)
  • To identify students and check for once-only submission, we need an authentication server
  • Need to use cookies, and server has to be built accordingly (the connector between the server and the authentication server will be http with cookies)

Extension 1 Architecture

Extension 2

• Assume that it is discovered that the connection to the database component is unreliable
• To improve reliability when the database is down, we would like to have a student's data cached and to return stale survey result data in response
• The survey data returned in this situation can be outdated by at most five survey submissions
• To handle this extension, we will add a cache component to the architecture, that stores the data of at least the last five survey submissions (and possible more if the database goes down for a significant amount of time)

Extension 2 Architecture

Discussion

• Each extension addressed a non-functional characteristic of the system
  • Architectural choices often have a big impact on a system's properties
• Note: that in this example we have not talked about explicit features of the system, the look and feel of the survey, how the data is stored, etc. Instead, we've looked at the overall structure of the system to evaluate feasibility and to enable a discussion of non-functional issues
  • The specific details of functionality and user interface are deferred to the high-level and low-level design phases of software development

Architectural Styles

• There are different ways (or rules) for how components and connectors of various types can be arranged. Each style offers certain benefits and limitations to an architect as long as its rules are followed.
• When developing a new system, its useful to consider various styles and evaluate which style best suits the needs of the proposed system
  • It is sometimes useful to consider combining certain styles for use within a single system
• Common Styles
  • Pipe and Filter
  • Layered Abstract Machine
  • Software Bus
  • Shared Repository

Pipe and Filter

• Well suited for systems that mainly do data transformations
• A system using this style uses a network of transformations to achieve a desired result
• Has one component type – filter
• Has one connector type – pipe
• A filter transforms the data it receives (in some way) and passes the modified data to another filter via its output pipe
  • Most famous use of pipe-and-filter?: Unix (!)
  • Unix: everything is a file
  • Unix: easy to link processes together such that the output of one is the input of another

Layered Abstract Machine

• Components are partitioned into layers; Lower-level layers provide foundational services that are used by components in higher-level layers
• Communication between components can take many forms, direct procedure call, remote procedure calls, events, etc.
• Typically communication is restricted: higher levels can invoke lower levels, but lower levels may not call up to a component in a higher level

Software Bus

• Components are independent entities that communicate with each other via a shared message bus
• Typically, messages are sent without an explicit destination specified
  • Instead, components register interest in certain classes of messages; when a message matches a component's interests, it gets delivered to the component by the bus
  • This is also known as the publish-subscribe style
• The software bus architecture is useful in situations in which every component needs to be connected to every other component

Shared Repository

• Two component types – data repository and data accessor
• Data repository – provides reliable permanent storage
• Data accessors – access data in repositories, perform computations, and may put the results back into the repository
• Communication between data accessors is only through the repository
• Two variations
  • Blackboard style: if data is posted in a repository, all accessors are informed; i.e. shared repository is an active agent
  • Repository style: passive repository
• Example
  

Other styles

• Client-Server Style
• Peer-to-Peer Style
• Mobile Agent Style
• etc.

Architecture and Design

• Both architecture and design partition a system into parts
• What is the relationship between design and architecture?
  • Architecture is a type of design; its focus is the solution domain (the machine), and not the problem domain
  • You can view architecture as a very high level design focusing on a system's main components
  • Design is about modules in these components that have to be developed
• Boundaries between architecture and design are not always clear
• It is up to the designer and architect to decide where architecture ends and design begins
• At the architecture level, issues like files, data structure, etc. are not considered, while they are important in design
• Architecture does impose constraints on a design, in that the design of a system must be consistent with its architecture

Coming Up Next

• Lecture 19: Function-Oriented Design
• Lecture 20: Object-Oriented Design