interactive/adoptable systems
DESCRIPTION
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)TRANSCRIPT
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.