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 Sample patterns 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: Problem 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 Problem 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 abstraction Manage 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 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: MKDE: Microkernel Databank Engine 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 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: Pointer? Or not SuperType 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.