1. Interactive/Adoptable systems

2. 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)

3. 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.

4. 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.

5. 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

6. 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

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

8. 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

9. Scenario 1: change propagation mechanism

10. Scenario 2: Initializing the MVC tiad

11. 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

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

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

14. 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

15. 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…

16. PAC Example

17. 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.

18. 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)

19. PAC Example

20. PAC Structure

21. 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…

22. 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

23. PAC Structure

24. PAC Scenario 1

25. PAC Secnario 2

26. 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

27. PAC flow for example

28. 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

29. 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…

30. 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…

31. 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.

32. 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

33. Microkernel-Example HYDRA

34. 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.

35. 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.

36. Microkernel Architecture

37. Microkernel structure

38. Microkernel OMT Diagram

39. Scenario 1

40. Scenario 2

41. 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

42. Microkernel variants
Microkernel system with indirect Client-Server connections. MK establish channel of communication between client and external servers.

43. 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..

44. 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

45. 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…

46. Microkernel Liabilities
Performance
Complexity of design and implementation.
Basic functionalities of the micro-kernel ??
Separation mechanism/policy => deep knowledge of domain.

47. 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.

48. Reflection example

49. 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

50. 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)

51. Structure

52. Reflection structure

53. Scenario 1
Primitive
Type…

54. Scenario 2:
Pointer? Or not
SuperType
Field…

55. 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

56. 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)…

57. 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

58. 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

59. 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.

60. 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.