1 / 29

Layered Style Examples

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.

williamsnyder
Télécharger la présentation

Layered Style Examples

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

  2. Unix Layered Architecture (c) Ian Davis

  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 (c) Ian Davis

  4. Pattern: Microkernel • Context • 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 (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) (c) Ian Davis

  6. (c) Ian Davis

  7. https://en.wikipedia.org/wiki/Microkernel (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

  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

  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 (c) Ian Davis

  11. Implicit Invocation Architecture (c) Ian Davis

  12. Implicit Invocation • Model/View/Controller • 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 (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 (c) Ian Davis

  14. Model View Controller (MVC) (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 (c) Ian Davis

  16. Model View Presenter • Problem • 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 (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 modelandupdating the view, reacting to user interactions updating the model. https://medium.com/@cervonefrancesco/model-view-presenter-android-guidelines-94970b430ddf (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 (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

  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

  21. Implicit Invocation Style (Cont’d) • An event announcement “implicitly” causes the invocation of procedures in other modules. (c) Ian Davis

  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

  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

  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

  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

  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

  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

  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

  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

More Related