interactive/adoptable systems

Interactive/Adoptable systems

Categories for today discussion From Mud to structure

Layered, Pipes and filters, Blackboard pattern Distributed systems

Broker Interactive systems

Presentation abstraction-control pattern (PAC) , Model view controller (MVC)

Adaptable systems Micro kernel

Note: it is desirable to explore several alternatives before deciding on specific architectural patterns

Example: Presentation abstraction-control pattern (PAC) VS Model view controller (MVC)

Interactive systems Needs of system

High degree of GUI interaction Keep functional core independent of UI Adoption of new UI if needed

Sample patterns MVC Presentation abstraction control (PAC) Note:MVC is most popular in interactive software

system development.

Model-View-Contoler (MVC) The model contains the core functionality

and data? Views display information to the user. Controllers handle user input. A change propagation mechanism ensure

consistency between user interface and the model.

MVC:Context/Problem Context:

Interactive application with a flexible human computer interface Problem

The same information is presented differently in different windows example (bar and Pie)

The display and behavior of the application must reflect data manipulations immediately

Change to UI must me easy and even possible at run time Supporting different ‘look and feel’ standards or porting the UI

should not affect code in the core of the application

MVC Solution Has 3 areas Processing, input and output The model component encapsulates core data

and functionalities. the model is independent of specific output representation or input behavior

View components display information to the user. A view obtains the data from the model. There can be multiple views of the model

Each view has an associated controller component

MVC structure:

Note: Every view will have one controller to help the view to show user based on there needs.

MVC Structure in C++ (OMT diagram Object modeling technique)

Note: Observer is not needed in small talk, in C++ view and controller has common parent

Scenario 1: change propagation mechanism

Scenario 2: Initializing the MVC tiad

MVC Implementation Separate human computer interaction from core functionality Implement he change propagation mechanism Design and implement the views Design and implement the controllers Design and implement the view and controller relationship Implement the setup of MVC Dynamic view creation Pluggable control Infrastructure for hierarchical views and controllers Future decoupling from system dependencies

MVC Known Uses Smalltalk MFC ET++: application Framework Java/Swing

MVC benefits Multiple views of the same model Synchronized views: change propagation Pluggable views and controllers Exchangeability of ‘look and feel’ Framework potential

MVC Liabilities Increased complexity Potential for excessive number of updates Intimate connection between view and

controller Close coupling of views and controllers to a

model Inefficiency of data access in view Inevitability of change to view and controller

when porting Difficulty of using MVC with modern user-

interface tools

Presentation abstraction control (PAC) PAC define a hierarchy of cooperating

agents. Each agent consists of three components:

presentation, abstraction, control. Separates human computer interaction

from its functional core and its communication with other agents…

PAC Example

PAC Context/Problem Context

Development of an interactive application with the help of agents

Problem Each agents maintain there own state and data/ there

needs a mechanism to exchanging data, messages and events

Interactive agents provide there own user interface. System evolve over time. Change in the individual

agents, should not affect the whole system.

Solution Structure the interactive applications as a tree like hierarchy of PAC

agent (each agent has separate PAC) The agents presentation component provides the visible behavior of

PAC agent The Top-level PAC agent provides the functional core of the system Bottom level PAC agents represent self constrained semantic

concepts on which users of the system can act (Like spread sheet, chart etc)

Intermediate level PAC agents represent either combinations of, or relationships between, lower-level agents. (example Floor plan, external view in CAD)

PAC Example

PAC Structure

Top Level PAC

Abstraction : Global Data model Presentation : Some Graphical elements Control:

Allow sub-agent to access abstractionManage hierarchy of PAC component Manage info about interaction (log, check

applicability of triggered application…

Note: the examples show only those functions that are relevant to control and co-ordinate the hierarchy, or which are accessible to other PAC agents

PAC Structure

PAC Scenario 1

PAC Secnario 2

Implementation Define a model of application (which service, which component,

what relation ship ..) Define a general strategy for organizing the PAC hierarchy Specify a top level PAC Agent Specify a bottom level PAC Agent Specify a bottom level PAC agent for system service Specify intermediate level PAC agents to compose lower level PAC

agents Specify intermediate level PAC agents to coordinate lower level

PAC agents Separate core functionality from human computer interaction Provide an external interface

PAC flow for example

PAC Known Uses

Network Trafic Management (TS93) Gathering traffic data Threshold checking and generation exceptions Logging and routing of network exception Vizualisation of traffic flow and network exceptions Displaying various user-configurable views of the whole

network Statistical evaluation of traffic data Access to historic traffic data System administration and configuration

PAC Benefits

Separation of concerns: Agent and inside an agent

Support for change and extension Support for multi-tasking: each PAC agent

can run its own thread on a different computer…

PAC Liabilities

Increased system complexity: Coordination of agents…

Complex control component: coordonate action inside agent and with other agents…

Efficiency : data are propagated throught the tree…

Applicability : Not a graphic editor where each object is a PAC agent…

Microkernel Applies to software systems that be able to

adapt to changing system requirements. It separates a minimal functional core from

extended functionality and customer specific parts.

The Microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration.

Example-HYDRA

Develop new OS Easy to accommodate future development Able to run application written for different

applications HYDRA will display all the applications

currently running with in its main window

Microkernel-Example HYDRA

Microkernal – Context/Problem Context

Development of several applications that use similar programming interfaces that build on the same core functionality.

Problem Application platform must cope with continuous

hardware and software evolution The application platform should be portable,

extendable and adaptable to allow easy integration of emerging technologies.

Microkernel -Solution

Encapsulate the fundamental services of your application platform in a microkernel component.

External servers implement their own view of the underlying micro kernel.

Client communicates with external servers by using the communication facilities provided by the microkernel.

Microkernel Architecture

Microkernel structure

Microkernel OMT Diagram

Scenario 1

Scenario 2

Implementation Analyze the application domain Analyze the external servers Categorize the service Partition the categories Find the consistent and complete set of operations and abstractions for every

category Determine strategies for request transmission and retrieval Structure the microkernel component To specify the programming interface of microkernel Ensure Microkernel is responsible for managing all system resources such a memory

blocks etc Design and implement the internal servers as separate processes or shared libraries Implement the external servers Implement the adopters Develop client application or use existing ones

Microkernel variants Microkernel system with indirect Client-

Server connections. MK establish channel of communication between client and external servers.

Microkernel known Uses Mach (92): Emulate other operating system

(NeXTSTEP) Amoeba (92):

– Kernel: process, threads system memory, communication, IO

– Services not in the kernel are internal servers..

Known uses Chorus WINDOWS NT:

– External servers: OS/2.1.X, posix server and win32 server

MKDE: Microkernel Databank Engine– External server : Data model of SQL database

Microkernel Benefits Portability : no need to port external

servers… Flexibility and extensibility Separation of policy and mechanism:

– Mechanism in kernel, policy in external servers Scalability Reliability: Distributed Microkernel… :-/ Transparency : Microkernel ~ broker…

Microkernel Liabilities Performance Complexity of design and implementation.

– Basic functionalities of the micro-kernel ??– Separation mechanism/policy => deep

knowledge of domain.

Reflection Provides a mechanism for changing

structure and behavior of software dynamically.

Support modification of fundamental aspects: type structures and function call mechanism

Meta-level makes the software self-aware Base-level includes application logic. Its

implementation builds on the meta-level.

Reflection example

Reflections context/Problem Context

Building systems that support their own modification a priori Problem

Change in software is tedious and error prone Adaptable software systems usually has complex inner structure More technique is more complex Change can be of any scale Even fundamental aspects of software system can change

Reflections solution Make software self aware Split software into to parts Meta level and base level Meta level provides self representation of software to

give its knowledge of its own structure and behavior Base level define application logic All communication happen though meta objects An interface is specified for manipulating the meta

objects called meta object protocol (MOP)

Structure

Reflection structure

Scenario 1

Primitive

Type…

Scenario 2:

SuperType

Pointer? Or not

Field…

Implementation: Define a model of the application Identify varying behavior Identify structural aspects of the system Identify system services that support both the

variation of application service identified in step2 and step3

Define meta objects Define meta objects protocol Define base level

Reflection known Uses CLOS : generic function and generic function

invocation MIP: run-time type information system for C+

+ Pgen: persistence component for C++ based

on MIP Ole2.0, CORBA (dynamic invocation)…

Reflection benefits No explicit modification of source code Changing a software is easy: no need for

visitors, factories and strategies patterns Support for many kind of change

Reflection Liabilities Modification at the meta-level can cause

damage. Increased number of component Lower efficiency Not all potential changes supported (only

those supported by the MOP) Not all language support reflection

Summary (C. Alexander) It is possible to make building by stringing

together patterns, in a rather loose way. A building made like this, is an assembly of patterns. It is not dense. It is not profound. But it is also possible to put patterns together in such way that many patterns overlap in the same physical space: the building is very dense; it has many meanings captured in a small space; and through this density, it becomes profound.

Drawbacks of Patterns Patterns do not lead to direct code reuse. Individual Patterns are deceptively simple. Composition of different patterns can be very

complex. Teams may suffer from pattern overload. Patterns are validated by experience and

discussion rather than by automated testing. Integrating patterns into a software

development process is a human intensive activity.