arquitectura de sistemas de software -...

FEUP, Ademar Aguiar

Arquitectura de Sistemas de Software, 2008/09

FEUP ● Nuno Flores ● Ademar Aguiar ● Arquitectura de Sistemas de Software, 2010/11 1

Arquitectura de Sistemas de Software Mestrado Integrado em Engenharia Informática e Computação

Nuno Flores nuno.flores at fe.up.pt


Estilos de arquitectura

adaptado de http://www.ugrad.cs.ubc.ca/~cs410/lectures/slides/cs410-ArchitecturalStyle1.ppt e http://www.ugrad.cs.ubc.ca/~cs410/lectures/slides/cs410-ArchitecturalStyle2.ppt

FEUP, Ademar Aguiar



Architectural styles

  Early Gothic Architecture, Notre Dame, Paris

  Gothic characteristics • Ogival archs, great expanses of glass, ribbed vaults, clustered

columns, sharply pointed spires, flying buttresses and inventive sculptural detail such as gargoyles. [http://en.wikipedia.org/wiki/Gothic_architecture]


Styles and patterns

  Identifying styles and patterns can help codify and share knowledge/expertise

  Architectural Styles • [Shaw and Garlan, Software Architecture, Prentice Hall 96]

  Design Patterns • [Gamma, Helm, Johnson, Vlissides, Design Patterns, Addison Wesley

95] • [Buschmann et. Al, Pattern-oriented Software Architecture: A System

of Patterns, John Wiley & Sons 96]

  Code Patterns • [Coplien, Advanced C++ Programming Styles and Idioms, Addison-

Wesley 91]

FEUP, Ademar Aguiar



Architectural styles

  A style consists of: •  a set of component types (e.g., process, procedure) that perform some

function at runtime •  a topological layout of the components showing their runtime relationships •  a set of semantic constraints •  a set of connectors (e.g., data streams, sockets) that mediate

communication among components

  Styles provide guidance for architectural design based on the problem domain and the context of use •  Recurring (and proven) architectural design •  Definition of common vocabulary

  Each style has: •  components, connectors, key characteristics, strengths and

weaknesses, variants and specializations. From Chapter 5, Software Architecture in Practice, p. 94


A catalog of architectural styles

Call and Return

Main Prog.and Sub.

Object-oriented

Layered

Data Flow

BatchSequential

Pipes andFilters

Data-Centered

Repository Blackboard

Virtual Machine

Interpreter Rule-basedSystem

Independent Components

CommunicatingProcesses

Event Systems

ImplicitInvocation

ExplicitInvocation

From Chapter 5, SoftwareArchitecture in Practice, p. 95

FEUP, Ademar Aguiar



Call and Return


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

FEUP, Ademar Aguiar




Object-oriented (ADT) substyle

  Objects help achieve modifiability by encapsulating internal secrets from environment

  Access to objects is only through methods (constrained forms of procedure calls)

  Object-oriented paradigm is distinguished from ADT by inheritance and polymorphism

FEUP, Ademar Aguiar




Example: cruise control system

  A cruise-control system exists to maintain the speed of a car, even over varying terrain, when turned on by the driver.

  When the brake is applied, the system must relinquish speed control until told to resume.

  The system must also steadily increase or decrease speed to reach a new maintenance speed when directed to do so by the driver. Throttle

System on/off

Engine on/off

Pulses from Wheel

Accelerator

BrakeIncrease/Decrease

Speed

Resume Speed

Clock From Model Problems in Architecture, Shaw

FEUP, Ademar Aguiar



Layered substyle

  Goals: modifiability and portability

  Optimally, each layer communicates only with its neighbors

  Sometimes, must layer bridge for performance: decreases benefits of style

Core

Basic Utility

Subsystem

Subsystem

User Interface


FEUP, Ademar Aguiar



Layered substyle: Example

  Outline of a design used on a mobile robot

  Level 1 is robot control

  Levels 2-3 deal with input from real world

  Level 4 manages robot’s view of world

  Level 5 manages robot navigation

  Levels 6-7 schedule and plan robot’s activities

  Top-level is UI and supervisory

Supervisor

Global Planning

Control

Navigation

Real-world Modelling

Sensor Integration

Sensor Interpretation

Robot Control

Environment


Data-Flow

FEUP, Ademar Aguiar



Data-Flow style

  Goals: achieve reuse and modifiability

  Components are independent programs • each step runs to completion before the next starts • each batch of data is transmitted as a whole between steps

  Classic data-processing approach

Data-flow

Batch Sequential

Pipes and Filters

• 


FEUP, Ademar Aguiar



Pipe-and-Filter substyle

  Incremental transformation of data by successive components •  Filters transform data using little contextual information and retain

no state between instantiations •  Pipes are stateless and are used to move streams of data between

filters

  A pipe’s source end connects to a filter’s output port; sink end connects to filter’s input port

  Pipes and filters run non-deterministically until no more computations or transmissions are possible +  Simple to reason about, eases maintenance, enhances reuse, can

easily enhance performance by parallelizing or distributing -  Interactive apps are difficult, filters can’t cooperate to solve a

problem, performance is often bad


FEUP, Ademar Aguiar



Data-Centered


Data-Centered styles

  Two-substyles: Repository and Blackboard

  When a system can be described as a centralized data store that communicates with a number of clients

  In a (passive) repository, data might be stored in a file.

  In an active repository, such as a blackboard, the blackboard notifies clients when data of interest changes (so there would be control from data to clients)

Shared Data Client

Client Client

FEUP, Ademar Aguiar




FEUP, Ademar Aguiar



Blackboard: Example

  Captain is the overall supervisor

  Map navigator is a high-level path planner

  Pilot is a low-level path planner and motor controller

  Perception subsystem takes data from sensors and integrates it

Perception Subsystem

Blackboard

lookout

captain

map navigator

pilot


Just to keep track…

Call and Return

Main Prog.and Sub.

Object-oriented

Layered

Data Flow

BatchSequential

Pipes andFilters

Data-Centered


Virtual Machine




Event Systems

ImplicitInvocation

ExplicitInvocation


FEUP, Ademar Aguiar



Independent components


Independent components style

  We’ll look at the implicit invocation (event) substyle

  Goals: achieve modifiability by decoupling various parts of the computation

  Approach: have independent processes or objects communicate through messages

FEUP, Ademar Aguiar




Event systems

  Individual components announce data they wish to share (publish) with others

  Other components may register an interest in the kind of data (subscribe). They are invoked when the data appears

  How does this achieve modifiability?

FEUP, Ademar Aguiar



Implementing event systems

  Several different ways to achieve an event system: •  Callbacks •  Event Handling in Java Swing •  Observer design pattern •  Event notification pattern •  Message Manager •  (this is not a complete list)


FEUP, Ademar Aguiar




Event handling in Java Swing

  Some examples: User closes a window WindowListener Table selection changes ListSelectionListener User clicks a button ActionListener

Event Source

Event Listener

Event Listener

Event Listener Event Object

FEUP, Ademar Aguiar



Java Swing…

  public class MyClass implements ActionListener { public void actionPerformed( ActionEvent e ) { … } }

  someComponent.addActionListener( instanceOfMyclass );


Observer design pattern

FEUP, Ademar Aguiar



Limitations of observer

  the basic implementation described in the pattern has some limitations

• can’t tell why an object is being told to update (except by digging through code)

• one size fits all: an observer might not be interested in all changes in the subject

• an observer has only one routine that dispatches updates


Event notification pattern

  Dirk Riehle created the Event Notification Pattern to address some of these problems (http://www.riehle.org/papers/1996/tapos-1996-event.html)

  An event represents an abstract state change of an object (a subject). The event notification mechanism notifies dependent objects (observers) when a change has occurred; the dependent objects can then update themselves (sometimes through explicit invocation)

FEUP, Ademar Aguiar



Event notification pattern: How-To

  Make abstract state changes for an object (a subject) visible by providing state change objects as part of its interface

  A dependent object ( an observer) uses event stub objects to represent its dependencies as first-class objects

  Event stubs are linked to state change objects via event link objects

  Event link objects propagate change


Event notification pattern: Basic design

Observer

OpForEv1(..) OpForEv2(..)

Subject

StateChg1(..) StateChg2(..)

EventStub operation observer

Forward(..)

observer->operation(..)

StateChange Announce(..) Register(..)

Unregister(..)

For all registered stubs: stub->Forward(..)

1..n

1..n 1..n

Overall implicit invocation

Indirect invocation

FEUP, Ademar Aguiar



Event notification pattern: Refined design

Observer

OpForEv1(..) OpForEv2(..)

Subject

StateChg1(..) StateChg2(..)

EventStub operation observer

Forward(..)

StateChange Announce(..) Register(..)

Unregister(..)

For all registered stubs: stub->Forward(..)

1..n

1..n 1..n

Overall implicit invocation

Indirect invocation

EventLink

Forward(..)

inherits


Using the event notification pattern

  We will break into groups and try out the event notification pattern in class

FEUP, Ademar Aguiar



Message manager

  Sometimes you want even more flexibility

  For instance, if building a programming environment, perhaps you want to be able to add tools on the fly and have them respond to events

  A message manager can help •  Receive messages and route them to registered parties


Just to keep track…

Call and Return

Main Prog.and Sub.

Object-oriented

Layered

Data Flow

BatchSequential

Pipes andFilters

Data-Centered


Virtual Machine




Event Systems

ImplicitInvocation

ExplicitInvocation


FEUP, Ademar Aguiar



Virtual Machines


FEUP, Ademar Aguiar




Mixing styles

FEUP, Ademar Aguiar



Heterogeneous use

  Systems are generally built from multiple styles

  Three kinds of heterogeneity: •  Locationally heterogeneous: run-time structures reveal different styles in

different areas •  Hierarchically heterogeneous: a component of one style, when decomposed

is structured according to another style •  Simultaneously heterogeneous: different styles depending on point of view


FEUP, Ademar Aguiar



Characterizing and comparing styles

  The following categories are useful in comparing and characterizing styles: •  What kinds of components and connectors are used in the style? •  What are the control structures? •  How is data communicated? •  How do data and control interact? •  What kind of reasoning does the style support?


Components & Connectors

  “A component is a unit of software that performs some function at runtime.” [p.105]

  “A connector is a mechanism that mediates communication, coordination, or cooperation among components” [p. 105]

FEUP, Ademar Aguiar



Control Issues

  How does control pass among components?

  Topology: •  What is the topology of a batch-sequential data-flow style? •  What is the topology of a main-program-and-subroutine style?

Other topologies include star, arbitrary… Topology may change at runtime.


Control Issues...

  Synchronicity: How interdependent are the component’s actions upon each other’s control states? •  E.g., lockstep - state of one component implies state of all others •  E.g., synchronous - components synchronize regularly; other state

relationships are unpredictable

FEUP, Ademar Aguiar



Control Issues...

  Binding Time: When is the partner in a communication established? •  Program-write time? •  Compile-time? •  Invocation-time?


Issues...

  Data Issues: •  Topology •  Continuity: Continuous vs. sporadic; volume •  Mode: Passed, shared, copy-out-copy-in, etc. •  Binding Time: Same as control issue

  Control/Data Interaction Issues: •  Shape of control and data topologies •  Directionality: does data flow in direction of control?

  Type of Reasoning

arquitectura de sistemas de software -...

Documents