Classical architectural styles l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 30

Classical Architectural Styles PowerPoint PPT Presentation


  • 360 Views
  • Updated On :
  • Presentation posted in: General

Classical Architectural Styles. Classical Architectural Styles. Common architectural idioms, taxonomies, and patterns Issues Detailed look at specific architectural styles Pure forms first, later heterogeneous systems Distinguishing characteristics and specialisation

Download Presentation

Classical Architectural Styles

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Classical architectural styles l.jpg

Classical Architectural Styles


Classical architectural styles2 l.jpg

Classical Architectural Styles

  • Common architectural idioms, taxonomies, and patterns

  • Issues

    • Detailed look at specific architectural styles

    • Pure forms first, later heterogeneous systems

    • Distinguishing characteristics and specialisation

    • Heuristics for choosing a style

    • Implementation techniques

    • Formal models and analysis

    • Case studies


Subtopics l.jpg

Subtopics

  • Dataflow systems

    • Batch sequential, pipe & filter

  • Procedure call systems

    • Information hiding, ADTs, objects

  • Event-based systems

    • Multicast organisation, implicit invocation


Subtopics con t l.jpg

Subtopics con’t

  • Repository-oriented systems

    • Blackboards, databases, client-servers

  • Processes

    • Communicating processes, message passing

  • Others

    • Interpreters and other virtual machines, process control, layers


Architecture in systems l.jpg

Architecture in Systems

  • Architecture:

    “the underlying structure of things”

    Not just “what”, but “why”

  • Good architecture (like much good design):

    • Result of a consistent set of principles and techniques, applied consistently through all phases of a project

    • Resilient in the face of (inevitable) changes

    • Source of guidance throughout the product lifetime


Elements of architectural descriptions l.jpg

Elements of Architectural Descriptions

  • The architectural definition of a system selects

    • Components: define the locus of computation

      • Examples: filters, databases, objects, ADTs

    • Connectors: mediate interactions of components

      • Examples: procedure calls, pipes, event broadcast

    • Properties: specify info for construction & analysis

      • Examples: signatures, pre/post conds, RT specs


Elements of architectural descriptions con t l.jpg

Elements of Architectural Descriptions con’t

  • An architectural style defines a family of architectures constrained by

    • Component/connector vocabulary

    • Topology rules

    • Semantic constraints


Common architectural idioms l.jpg

Common Architectural Idioms

  • Data flow systems

    Batch sequentialPipes and filters

  • Call-and-return systems

    Main program & subroutines

    Hierarchical layersOO systems

  • Virtual machines

    InterpretersRule-based systems

  • Independent components

    Communicating processesEvent systems

  • Data-centered systems (repositories)

    DatabasesBlackboards


Batch sequential systems l.jpg

Batch Sequential Systems

  • Processing steps are independent programs

  • Each step runs to completion before next step starts

  • Data transmitted as a whole between steps

  • Typical applications

    • Classical data processing

    • Program developments


Pipes and filters l.jpg

Pipes and Filters

  • Filter

    • Incrementally transform some amount of the data at inputs to data at outputs

      • Stream-to-stream transformations

    • Use little local context in processing stream

    • Preserve no state between instantiations


Pipes and filters con t l.jpg

Pipes and Filters con’t

  • Pipe

    • Move data from a filter output to a filter input

    • Pipes form data transmission graphs

  • Overall computation

    • Run pipes and filters (non-deterministically) until no more computations are possible


Main program and subroutines l.jpg

Main Program and Subroutines

  • Hierarchical decomposition

    • Based on definition-use relationship

  • Single thread of control

    • Supported directly by programming languages

  • Subsystem structure implicit

    • Subroutines typically aggregated to modules

  • Hierarchical reasoning

    • Correctness of a subroutine depends on the correctness of the subroutines it calls


Object architectures l.jpg

Object architectures

  • Encapsulation

    • Restrict access to certain information

  • Inheritance

    • Share one definition of shared functionality

  • Dynamic binding

    • Determine actual operation to call at runtime

  • Management of many objects

    • Provide structure on large set of definitions

  • Reuse and maintenance

    • Exploit encapsulation and locality


Layered patterns l.jpg

Layered Patterns

  • Each layer provides certain facilities

    • Hides part of lower layer

    • Provides well-defined interfaces

  • Serves various functions

    • Kernels: provide core capability, often set of procedures

    • Shells, virtual machines: support for portability

  • Various scoping regimes

    • Opaque versus translucent layers


Interpreters l.jpg

Interpreters

  • Execution engine simulated in software

  • Data

    • Representation of program being interpreted

    • Data (program state) of program being interpreted

    • Internal state of interpreter

  • Control resides in “execution cycle” of interpreter

    • But simulated control flow in interpreted program resides in internal interpreter state

  • Syntax-driven design


Communicating processes l.jpg

Communicating Processes

  • Components: independent processes

    • Typically implemented as separate tasks

  • Connectors: message passing

    • Point-to-point

    • Asynchronous and synchronous

    • RPC and other protocols can be layered on top


Event systems l.jpg

Event Systems

  • Components: objects or processes

    • Interface defines a set of incoming procedure calls

    • Interface also defines a set of outgoing events

  • Connectors: event-procedure bindings

    • Procedures are registered with events

    • Components communicate by announcing events at “appropriate” times

    • When an event is announce the associated procedures are (implicitly invoked)

    • Order of invocation is non-deterministic

    • In some treatments connectors are event-event bindings


Classical databases l.jpg

Classical Databases

  • Central data repository

    • Schemas designed specifically for application

  • Independent operators

    • Operations on database implemented independently, one per transaction type

    • Interact with database by queries and updates

  • Control

    • Transaction stream drives operation

    • Operations selected on basis of transaction type


The blackboard model l.jpg

The Blackboard Model

  • Knowledge sources

    • World and domain knowledge partitioned into separate, independent computations

    • Respond to changes in blackboard

  • Blackboard data structure

    • Entire state of problem solution

    • Hierarchical, nonhomogeneous

    • Only means by which knowledge sources interact to yield solutions

  • Control

    • In model, knowledge sources self-activating


Important ideas l.jpg

Important ideas

  • Common patterns for system structure

    • Pure type form, allowing variation

    • Identifiable types of subsystems and interaction

  • Decomposition and heterogeneity

    • Pattern also describe subsystem structure

    • Subsystem pattern o system pattern

  • Independence

    • System patterns and subsystem functions do not depend on application

  • Fit to problem

    • Problem characteristics guide choice of structure


Case studies 1 kwic l.jpg

Case studies: 1. KWIC

  • In his paper of 1972 Parnas proposed the following problem [Parnas72]

    The KWIC (Key Word in Context) index system accepts an ordered set of lines; each line is an ordered set of words, and each word is an ordered set of characters. Any line may be “circularly shifted” by repeatedly removing the first word and appending it at the end of the line. The KWIC index system outputs a listing of all circular shifts of all lines in alphabetical order.


Kwic con t l.jpg

KWIC con’t

  • Four solutions:

    • Shared data

    • ADT

    • Implicit invocation

    • Pipe-and-filter


Kwic con t23 l.jpg

KWIC con’t

  • Consider following changes:

    • Changes in the processing algorithm

    • Changes in the data representation

    • Enhancement to system function

    • Performance

    • Reuse


2 instrumentation software l.jpg

2. Instrumentation software

  • Develop a reusable system architecture for oscilloscopes

    • Rely on digital technology and

    • Have quite complex software

  • Reuse across different oscilloscope products

    • Tailor a general-purpose instrument to a specific set of users

  • Performance important

    • Rapid configuration of software within the instrument

  • => Domain specific software architecture


Instrumentation software con t l.jpg

Instrumentation software con’t

  • Object-oriented model of software domain

    • Clarified the data types used for oscilloscopes

      • Waveforms, signals, measurement, trigger modes, …

    • No overall model to explain how the types fit together

    • Confusion about partitioning of functionality

      • Should measurements be associated with types of data being measured or represented externally?

      • Which objects should the user interface interact with?


Instrumentation software con t26 l.jpg

Instrumentation software con’t

  • Layered model

    • Well-defined grouping of functions

    • Wrong model for the application domain

      • Layer boundaries conflicted with the needs of the interaction among functions

        • The model suggest user interaction only via Visualization, but in practice this interaction affects all layers (setting parameters, etc)


Instrumentation software con t27 l.jpg

Instrumentation software con’t

  • Pipe-and-filter model

    • Functions were viewed as incremental transformers of data

    • Corresponds well with the engineers’ view of signal processing as a dataflow problem

    • Main problem:

      • How should the user interact?


Instrumentation software con t28 l.jpg

Instrumentation software con’t

  • Modified pipe-and-filter model

    • Each filter was associated with a control interface

      • Provides a collection of settings to be modified dynamically by the user

      • Explains how the user can make incremental adjustments to the software

      • Decouples signal-processing from user interface

    • Signal-processing software and hardware can be changed without affecting the user interface as long as the control interface remains the same


Instrumentation software con t29 l.jpg

Instrumentation software con’t

  • Further specialisation

    • Pipe-and-filter lead to poor performance

      • Problems with internal storage and data exchange between filters

      • Filters may run at radically different speeds


Instrumentation software con t30 l.jpg

Instrumentation software con’t

  • Summary

    • Software must be typically adapted from pure forms to specialised styles (domain specific)

    • Here the result depended on properties of pipe-and-filter architecture adapted to satisfy the needs of the product family


  • Login