1. Layered Style Examples
Layered Communication Protocols:
Each layer provides a substrate for communication at some level of abstraction.
Lower levels define lower levels of interaction, the lowest level being hardware connections (physical layer).
Operating Systems
Unix
(c) Ian Davis
Spring 2017

2. Unix Layered Architecture
(c) Ian Davis
Spring 2017

3. Overlaid Layered Architecture
Dynamically load code as needed
Can instantiate many different capabilities at run time
Free memory for reuse when no longer needed
COBOL (Initial, mainline, final)
COM/OLE
Reference counting
Garbage collection
Spring 2017
(c) Ian Davis

4. Pattern: Microkernel Context Problem Forces
Core functionality must deploy on different platforms
Problem
Connections to hardware / OS subject to change
Forces
Preserve abstraction rather than focus on detail
Encapsulate what may change so easier to change
Share abstraction across all applications
Memory protection within O/S as well as outside
Spring 2017
(c) Ian Davis

5. Characteristics Minimal capabilities in a much reduced Kernel
Process creation / deletion / scheduling
Foundational Inter-Process Communication
Secure Memory Management
Much implemented as application software
File System / Network Software / Drivers
Offers choice / variety / extension / change
Adaptable (O/S not set in stone)
Spring 2017
(c) Ian Davis

6. Spring 2017
(c) Ian Davis

7. https://en.wikipedia.org/wiki/Microkernel
Spring 2017
(c) Ian Davis

8. Layered Style Advantages
Design: based on increasing levels of abstraction.
Enhancement: since changes to the function of one layer affects at most two other layers.
Reuse: since different implementations (with identical interfaces) of the same layer can be used interchangeably.
(c) Ian Davis
Spring 2017

9. Layered Style Disadvantages
Not all systems are easily structured in a layered fashion.
Performance requirements may force the coupling of high-level functions to their lower-level implementations.
Adding layers increases the risk of error.
Eg. getchar() doesn’t work correctly on Linux if the code is interrupted, but read() does.
(c) Ian Davis
Spring 2017

10. Object-Oriented Style
Powerful metaphor
Dynamic creation and deletion of objects
Clearer encapsulation of functionality
More restrictions on legitimate usage
Inheritance
Polymorphism
Pure abstract interfaces
Spring 2017
(c) Ian Davis

11. Implicit Invocation Architecture
Spring 2017
(c) Ian Davis

12. Implicit Invocation Model/View/Controller Publish/Subscriber
Data forms the Model
Controller changes the model
Controller announces to requesting views change
Publish/Subscriber
Publishes to topics
Subscribers listen to topics
Observer design pattern
Underlying implementation
Spring 2017
(c) Ian Davis

13. Pattern: Model View Controller
Context
Systems retrieve and display data in many formats
User interface may need new or altered views
Problem
Don’t want core application to be concerned with supporting the User Interface behaviour
Forces at work
User interface expected to evolve
Parallel tasks can be handled in different ways
Partition how things appear from how they change
Spring 2017
(c) Ian Davis

14. Model View Controller (MVC)
Spring 2017
(c) Ian Davis

15. Model ↔ View ↔ Controller
Business logic does not sit between Display and State
Changes to model broadcast to listeners
View responsible for presentation of model
Different parts of dashboard all listen for change
Controller
Responsible for handling input
Maintains model consistency
Spring 2017
(c) Ian Davis

16. Model View Presenter Problem Solution
Hard to test/generate pseudo user interaction
Solution
Separate the logic for the visual display
View (software that writes to the screen)
Presenter (sees interactions that occur on screen)
Impose a strict interface between the two
Can now test presenter without having a screen
Simply invoke interface from test software
Spring 2017
(c) Ian Davis

17. MVC .v. MVP MVP can be a refinement of MVC
Android MVP looks a lot more like 3 tier
The presenter is the middle-man between model and view. All your business logic belongs to it. The presenter is responsible for querying the model and updating the view, reacting to user interactions updating the model.
Spring 2017
(c) Ian Davis

18. Why to avoid 3-tier In a dashboard can have many sub-views
New sub-views should be easy to develop
A sub-view may not be visible all the time
Putting all view management in the presenter makes the presenter ever fatter (and confused)
Risks breaking presenter if have to change it
Presenter doesn’t care about the views
subview listening software better encapsulated
subview can easily be deactivated/reactivated
Spring 2017
(c) Ian Davis

19. Implicit Invocation Style
Suitable for applications that involve loosely-coupled collection of components, each of which carries out some operation and may in the process enable other operations.
A generalization of event driven code in which relevant state is included with the event, and multiple processes can “see” events.
(c) Ian Davis
Spring 2017

20. Implicit Invocation Style (Cont’d)
Instead of invoking a procedure directly ...
A component can announce (or broadcast) one or more events.
Other components in the system can register an interest in an event by associating a procedure with the event.
When an event is announced, the broadcasting system (connector) itself invokes all of the procedures that have been registered for the event.
(c) Ian Davis
Spring 2017

21. Implicit Invocation Style (Cont’d)
11/30/2018
Implicit Invocation Style (Cont’d)
An event announcement “implicitly” causes the invocation of procedures in other modules.
(c) Ian Davis
Spring 2017

22. Implicit Invocation Invariants
Announcers of events do not know which components will be affected by those events.
Components cannot make assumptions about what processing will occur as a result of their events (perhaps no component will respond).
Components cannot make assumptions about the order of processing.
(c) Ian Davis
Spring 2017

23. Implicit Invocation Specializations
Often connectors in an implicit invocation system also include the traditional procedure call in addition to the bindings between event announcements and procedure calls.
(c) Ian Davis
Spring 2017

24. Implicit Invocation Examples
Used in programming environments to integrate tools:
Debugger stops at a breakpoint and makes that announcement.
Editor responds to the announcement by scrolling to the appropriate source line of the program and highlighting that line.
LSEdit
(c) Ian Davis
Spring 2017

25. Implicit Invocation Examples (Cont’d)
Used to enforce integrity constraints in database management systems (called triggers).
Used in user interfaces to separate the presentation of data (views) from the applications that manage that data.
Used in user interfaces to allow correct mapping of function keys etc. to logic.
Used in forms to allow generic logic.
(c) Ian Davis
Spring 2017

26. Implicit Invocation Advantages
Provides strong support for reuse since any component can be introduced into a system simply by registering it for the events of that system.
Eases system evolution since components may be replaced by other components without affecting the interfaces of other components in the system.
Easy to add new views, etc.
(c) Ian Davis
Spring 2017

27. Implicit Invocation Advantages
Eases system development since one has to only map the events which occur to the software that manages them, and these events are often predefined.
Case tools hide the complexities of managing the flow of events.
Asynchronous interface improves performance, response times etc.
Parallelism?
(c) Ian Davis
Spring 2017

28. Implicit Invocation Disadvantages
When a component announces an event:
it has no idea what other components will respond to it,
it cannot rely on the order in which the responses are invoked,
it cannot know when responses are finished.
Feedback involves generating additional events that are routed to callback routines.
(c) Ian Davis
Spring 2017

29. Implicit Invocation Disadvantages
There is no single defined flow of logic within such systems.
It can be hard to consider all possible events that may occur, and their interactions.
Such systems can be very hard to both maintain and debug.
There is the risk that you end up communicating with “Trojan horses”.
(c) Ian Davis
Spring 2017