Software Architectural styles Introduction

Architectural styles Introduction

Recall: Architectural patterns vs. Architectural styles vs. Design patterns

Recall: Architectural patterns vs. Architectural styles vs. Design patterns

•     Architectural patterns define the implementation strategies of those components and connectors (‘how?’)

•     More domain specific

•     Architectural styles define the components and connectors (‘what?’)

•     Less domain specific

•     Good architecture makes use of design patterns (on a more fine-granular level)

•     We’ll see examples later on

•       Usually domain independent

Architectural Styles

An architectural style is a named collection of architectural design decisions that

−are applicable in a given development context

−constrain architectural design decisions that are specific to a particular system within that context

−elicit beneficial qualities in each resulting system

•Reflect less domain specificity than architectural patterns

•Useful in determining everything from subroutine structure to top-level application structure

•Many styles exist and we will discuss them in detail in the next lecture

Benefits of Using Styles

Reuse

Design: Well-understood solutions applied to new problems Code: Shared implementations of invariant aspects of a style

•Understandability of system organization

A phrase such as “client-server” conveys a lot of information

•Interoperability

Supported by style standardization

•Style-specificity

Analyses: enabled by the constrained design space Visualizations: depictions matching engineers’ mental models

Software Architecture:

Basic Properties of Styles

A vocabulary of design elements

•Component and connector types; data elements

−e.g., pipes, filters, objects, servers

Software

A vocabulary of design elements

•Component and connector types; data elements

−e.g., pipes, filters, objects, servers

•A set of configuration rules

Topological constraints that determine allowed compositions of elements

−e.g., a component may be connected to at most two other components

•A semantic interpretation

Compositions of design elements have well-defined meanings

•Possible analyses of systems built in a style

Some Common Styles

Traditional, language-influenced styles

•Main program and subroutines •Object-oriented

•Layered

•Virtual machines •Client-server

•Data-flow styles

•Batch sequential •Pipe and filter

•Shared memory

•Blackboard •Rule based

Interpreter

•Interpreter

•Mobile code

Implicit invocation

•Event-based

•Publish-subscribe

•Peer-to-peer

•“Derived” styles

•C2

•CORBA