Architectural Styles

1
Architectural Styles

• Hovhannes Avoyan

2
What is Architectural Style?

• The style determines a coherent vocabulary of
  system design elements and rules for their
  composition.
• By structuring the design space for a family of
  related systems a style can
• Drastically simplify the process of building a
  system,
• Reduce costs of implementation through reusable
  infrastructure, and
• Improve system integrity through style-specific
  analyses and checks.

3
Styles typically provide four things

• A Vocabulary of design elements component and
  connector types such as pipes, filters, clients,
  servers, parsers, databases, etc.
• Design rules or constraints that determine
  the permitted compositions of those elements. For
  example, the rules might prohibit cycles in a
  particular pipe-filter style, specify that a
  client-server organization must be an n-to-one
  relationship.
• Semantic interpretation, whereby compositions of
  design elements, suitably constrained by the
  design rules, have well-defined meanings.
• Analyses that can be performed on systems built
  in that style 

4
Architectural styles classification

• Data flow styles Styles dominated by motion of
  data through the system, with no upstream
  content control from recipient
• Call-and-return styles Styles dominated by order
  of computation, usually with single thread of
  control
• Interacting process styles Styles dominated by
  communication patterns among independent, usually
  concurrent processes.
• Data-centered repository styles Styles dominated
  by a complex central data store, manipulated by
  independent computations
• Data-sharing styles Styles dominated by direct
  sharing of data among components
• Hierarchical styles Styles dominated by reduced
  coupling, with resulting partition of the system
  into subsystems with limited interaction

5
Styles Classification
6
Styles Taxonomy
7
Connectors Taxonomy
8
Data-centered architectures

• Complex central data store manipulated by
  independent computations
• Transactional Database Repositories
• Blackboards
• Modern compilers

9
Data-centered architectures

• System is described as central data store that
  communicates with number of clients
• Repository use passive data storage when data
  consumer is responsible for retrieving data.
• Blackboard is a active repository which notifies
  (triggers) users when data of interest changes.
• Components shared-data stores and data
  accessors. In Blackboard style data accessors
  called knowledge source, and the data store is
  called the blackboard.
• Useful properties to document
• restrictions on number of accessors
• possibilities to add accessors at runtime
• access control policies and who is responsible
  for control
• data persistence
• concurrent access and synchronization mechanism.
• Analysis should focus on performance, security,
  privacy, reliability, compatibility with other
  repositories.

10
Dataflow styles

• Motion of data through the system, with no
  upstream content control
• Batch sequential Pipes Filters

11
Pipe and Filter Style

• Uniform data format results in the highest
  flexibility because it makes recombination of
  filters easy.
• Separate pipes from filters. Allow
  reconfiguration of filters without changing
  filters. Dont use direct calls between filters.
• Smaller filters provides better reuse and
  flexibility but more overhead.
• Design error handling. Filter may for example
  ignore error input.
• Explicit external definition of pipelines
  provides more flexibility.
• Useful Properties to document
• Buffers
• End-of-data
• Blocking behavior with buffers
• Reading when empty
• Single or multi-threaded
• Stream transformations
• Analysis focused on performance for the aggregate
  transformation provided by the graph of filters
  input/output stream latency, buffer requirements,
  and schedulable.

12
Call-and-return styles

• Dominated by order of computation, usually with
  single thread of control Main program and
  subroutine Information Hiding Systems
• Classical Objects
• Naïve client/server (message passing w/o
  maintaining contextof state of current actions)

13
Call and return Style

• Goal achieve modifiability and scalability
• Substyles
• Main-program-and-subroutine
• Decompose program hierarchically. Each component
  gets control and data from its parent.
• Remote procedure call
• Components are distributed across a network.
  Remote call is between two computers, but
  otherwise looks like a procedure call.
• Object-oriented or abstract data type
• Layered Style

•  

14
Hierarchical styles

• Dominated by reduced coupling, with resulting
  partition of the system into subsystems with
  limited interaction
• Layered
• OS
• TCP/IP
• N-Tiered
• Interpreter

15
Layered Style

• Keep number of layers in a good balance too many
  layers impose overhead, too few layers can result
  in a poor structure
• The higher layer provides services for the client
  while lower levels are helpers for the layers one
  level above them.
• Layers separation. Arguments, return or error
  types provided by certain Layer must be primitive
  types or types defined in this particular Layer.
  Some relaxation to these strict typing principles
  can be achieved by allowing usage of types taken
  from a shared data definition module.
• Inverted pyramid of reuse. Keep the base layers
  slim while higher layers can expand a broader
  spectrum of applicability
• Apply black box approach whenever possible.
  Layer should provide flat interface to upper
  layer without giving access to particular
  components within the layer.
• One-way coupling. In well-designed architectures
  an upper layer is aware of the next lower layer,
  but lower layer is unaware of the identity of its
  users. Although certain decupling of upper level
  is also possible if use interface and run-time
  instantiation mechanism.
• Communication between layers. Upper level sends
  requests to lower level, while lover layer sends
  notifications. Best practice is restricting
  sending requests to a layer just bellow to the
  senders level.

16
Problem with Layers reuse

• The higher the layer, the less the reuse because
  the more domain specific it is.
• The higher the layer, the less the reuse because
  the more assumptions made about lower layers.
• Many things (upper layers) develop dependencies
  on a few (lower layers). This inhibits lower
  layer evolution, flexibility and reusability.
  This is similar to the Fragile Base Class
  Problem.

17
Inverted Layer

• In Inverted Layers style lower layer parts are
  fairly ignorant of the upper layers, which are
  more free to vary, allowing greater reuse of the
  upper layers.
• Because so much is done for them by upper layers
  (lifecycle management, initialization, hookup,
  etc), application parts can be mostly small,
  simple, and dumb, making them wildly easy to
  design, program and compose with.
• Upper layers, such as a framework "core", can
  vary more independently of parts, allowing
  fantastic evolution where it matters most
  frameworks.
• Inversion completely changes the architecture.
  Application parts must now communicate with other
  layers using events (such as Messages) whereas
  before they used calls.

18
Circuit Based Style
Parts publish all their discrete input and
output, and the framework takes care of the input
and output hookups among parts. This creates
"circuits" just like the wires connecting
electronic devices on a circuit board. All part
input and output travels along circuits. The
input is normal methods. The output is usually
handled as an event. Parts have no idea who they
are collaborating with.
19
(No Transcript)
20
CB Vocabulary

• Part is a software component, which consumes,
  produces or transforms data.
• Part handles inputs and outputs via pins (inpins
  and outpins).
• Parts are composed into Devices which could serve
  as Parts for more complex Devices. Devices are
  configurations of Parts, Wires and Terminals.
• Terminals. Terminals are Device input and output
  ports.
• Wires are connectors. They connect pins by
  matching outpin and inpin parameters
• Diagrams are graphical views of configurations
• CB builds applications by connecting Parts.

21
CB Principles

• Anonymous collaboration. Two or more parts using
  each other without knowing about the other. For
  example, if PartA wants PartB to do something,
  PartA can send a Message to a MessageRouter,
  which sends it to PartB.. Anonymous Collaboration
  greatly reduces part dependencies, and is one of
  the principles
• Hierarchical composition - The organization of a
  system's elements into a strict tree of
  containers (devices) and leafs (parts), with a
  single root container (application). Advantages
• Large systems can be understood, navigated and
  managed better.
• Any properly encapsulated container can be reused
  in another system.
• Tools can handle hierarchical systems more easily
  that a web of elements.