Mumbai University > Computer Engineering > Sem 7 > Soft Computing

Marks: 10M

Year: Dec 2015

An architectural style is a named collection of architectural design decisions

• A primary way of characterizing lessons from experience in software system design
• 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 next week

Defination:

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.

Recurring organizational patterns & idioms

• Established, shared understanding of common design forms
• Mark of mature engineering field

Basic Properties of Styles

• 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

Benefits of Using Styles

• Design reuse

  • Well-understood solutions applied to new problems

• Code reuse

  • 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-specific analyses

  • Enabled by the constrained design space

• Visualizations

  • Style-specific depictions matching engineers’ mental models

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

Main program and subroutines:

• Displays greetings and instructions
• enters a loop in which it calls the three subroutines in turn.

Summary:

• Decomposition based upon separation of functional processing steps

Design elements

• Components: main program and subroutines
• Connectors: function/procedure calls
• Data: Values passed in/out subroutines

Topology

• Static organization is hierarchical
• Full structure: a directed graph

Advantages

Modularity: subroutines can be replaced as long as interface semantics are unaffected.

Disadvantages

Usually fails to scale

• Inadequate attention to data structures
• Effort to accommodate new requirements: unpredictable

Object-oriented

State strongly encapsulated. Internal representation is hidden from other objects

• Objects are responsible for their internal representation integrity

Design elements

• Components: objects (data and associated operations)
• Connectors: method invocations
• Data: arguments passed to methods

Topology

• Can vary arbitrarily: data and interfaces can be shared through inheritance.

Examples

• Complex, dynamic data structures
• Close correlation between physical world entities and entities in the program

Advantages

• Integrity: data is manipulated only by appropriate methods
• Abstraction: internals are hidden

Disadvantages

Not efficient enough for high performance computing (e.g., scientific computing, data science)

• Distributed applications require extensive middleware to provide access to remote objects
• In absence of additional structural principles unrestricted OO can lead to highly complex applications

Layered

Summary:

• An ordered sequence of layers, each layer offers services (interfaces) that can be used by programs (components) residing with the layer(s) above it

Design elements

• Components: layers, each layer usually several programs
• Connectors: typically procedure calls
• Data: parameters passed between layers

Topology

• Linear (strict layering), acyclic (non-strict layering)

Examples

Operating systems − 2INC0 “Operating systems” SfS:Y3Q1

Network and protocol stacks − 2IC60 “Computer networks and security” SfS, WbS:Y2Q4

Advantages

• Lower layers are independent from the upper layers
• Upper layers can evolve independently from the lower layers as long as the interface semantics is unchanged
• Strict layering: limits propagation of change

Disadvantages

• Not universally applicable
• Performance (mostly for strict layering and many layers)
• Client Server Style

Summary:

• Client initiates communication by sending server a request.
• Server performs the requested action and replies.

Design elements

• Components: client(s) and server
• Connectors: remote procedure call, network protocols
• Data: parameters and return values

Topology

• Two-level, multiple clients making requests to server
• No client-client communication

Examples

Centralization of data is required

Server: high-capacity machine (processing power)

Clients: simple UI tasks

Many business applications − 2IIC0 “Business Information Systems” SfS, WbS:Y3Q1

Dataflow styles focus on how data moves between processing elements

Batch-sequential

• “The Granddaddy of Styles”
• Separate programs are executed in order
• Aggregated data (on magnetic tape) transferred by the user from one program to another

Advantages

• Simplicity
• Severable executions

Disadvantages

• No concurrency
• No interaction between components

Pipe and Filter

Summary:

• Separate programs executed, potentially concurrently

Design elements

• Components: independent programs, a.k.a. filters
• Connectors: routers of data streams (pipes), provided by an operating system

Variations

• Pipelines — linear sequences of filters
• Bounded pipes — limited amount of data on a pipe − Typed pipes — data strongly typed

Topology

• Usually linear pipelines, sometimes T-joins are possible.

Blackboard Style

Two kinds of components

• Central data structure — blackboard
• Components operating on the blackboard • System control is entirely driven by the blackboard state

Summary:

• Separate programs communicate through the shared repository, known as the blackboard

Design elements

• Components: − shared blackboard − independent programs, a.k.a. knowledge sources
• Connectors: depending on the context − procedure calls, database queries, direct references…
• Data: stored on the blackboard
• Topology: star, the blackboard as the central node

Interpreter Style

Compilers translate the (source) code to the executable form at once

• Interpreters translate the (source) code instructions one by one and execute them
• To pass data from one instruction to the other we need to keep the Interpreter state

Mobile code style

Sometimes interpretation cannot be performed locally

• Code-on-demand
  • Client has resources and processing power
  • Server has code to be executed
  • Client requests the code, obtains it and runs it locally

Difference

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 finegranular level)