Abstract Factory. Consequences section. UML structure. Applicability section Requirement Elaboration of requirement Achieved through

Transcription

1 Abstract Factory a system should be independent of how its products are created, composed, and represented. a family of related product objects is designed to be used together, and you need to enforce this constraint. a system should be configured with one of multiple families of products. you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations. Decouple product modules from clients. Represent product family. Runtime binding of variant module families. Reveal module interface and hide implementation. It isolates concrete classes. Decouple product modules from clients. It makes exchanging product families easy. Runtime binding of variant product families. It promotes consistency among product Common interface of variant families, an application use objects from product families. only one family at a time. Compose whole from parts Union of services Compose whole from parts ConcreteFactory, ProductA, ProductB ConcreteFactory 1..* ProductA, ProductB ConcreteFactory.createProductA() ConcreteFactory.createProductB() AbstractFactory, ConcreteFactory1, ConcreteFactory2 AbstractFactory ConcreteFactory1 AbstractFactory ConcreteFactory2 Client, ConcreteFactory, ProductA, ProductB Client ConcreteFactory ProductA Client ConcreteFactory ProductB

2 Builder the algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled. the construction process must allow different representations for the object that's constructed. It lets you vary a product's internal representation. It isolates code for construction and representation. It gives you finer control over the construction process. Compose whole from parts Aggregation of services Generic implementation of assembling algorithm. Generic implementation of assembling algorithm. Variant parts need to be exchangeable at runtime. Generic implementation of assembling algorithm. Step-by-step assembling of complex object. Director, ConcreteBuilder Director 1..* ConcreteBuilder // Director.construct() method for all parts { part.buildpart() Builder, ConcreteBuilder Builder ConcreteBuilder Interface Parameterization Director.construct(Builder[] parts) { Interface Parameterization Interface Parameterization Interface Parameterization Aggregation of services

3 Factory method a class can't anticipate the class of objects it Late/runtime binding of services. must create. a class wants its subclasses to specify the Implement variations of the objects it creates. classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate. Provides hooks for subclasses. Generalize service commonality service. Abstraction based on variation points. Implement variations of common interface. Creator ConcreteCreator // Creator.anOperation() method.. product = factorymethod().. Generalize service commonality

4 Prototype the classes to instantiate are specified at Variant prototype modules need to run-time, for example, by dynamic loading. to avoid building a class hierarchy of factories that parallels the class hierarchy of products. when instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state. Specifying new objects by varying values. Highly dynamic systems let you define new behavior through object composition by specifying values for an object's variables. Reduced subclassing. Avoid factory modules for object creation and initialization. Configuring an application with classes dynamically. be exchangeable at runtime. Allow self object creation and initialization. Avoid manually object creation and initialization when a class can have one of only a few different combinations of state. Generic implementation of assembling algorithm. Allow self object creation and initialization. Variant prototype modules need to be exchangeable at runtime. Prototype.clone() Prototype ConcretePrototype Object cloning Interface Parameterization Client.operation(Prototype p) { cloneobj = p.clone() Object cloning Object cloning Interface Parameterization Object cloning

5 Singleton there must be exactly one instance of a class. Joint use of object data Object sharing Sole instance must be accessible to clients -- Static access type from a well-known access point. when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code. The sole instance is created at runtime but not at compile time so that polymorphism is unaffected. Null value based object creation Controlled access to sole instance. Hide constructor method. Permits refinement of operations and representation. The sole instance is created at runtime but not at compile time so that polymorphism is unaffected. Null value based object creation Permits a variable number of instances. Hide constructor method. More flexible than class operations. The sole instance is created at runtime but not at compile time so Null value based object creation that polymorphism is unaffected. // Singleton.getInstance() method if(uniqueinstance == null) Null value based object creation uniqueinstance = new Singleton(); else return uniqueinstance; Static access type static getinstance(); Preprocessing module Singleton.getInstance() { if(uniqueinstance == null) uniqueinstance = new Singleton(); Client Singleton.getInstance() Singleton.Singleton()

6 Adapter you want to use an existing class, and its Overcome mismatch in interface Interface mapping interface does not match the one you need. you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces. (object adapter only) you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class. Enables clients to call operations on Adaptee object. signature. Overcome mismatch in interface signature. Access the services of provider module without subclassing. Redirected access between Client and Adaptee objects. Interface mapping Adapter.request() { Adaptee.specificRequest() Class adapter: Subclass delegation Target Adapter Adaptee Adapter AND Adapter.request() { specificrequest() Interface mapping Preprocessing module Object adapter: Preprocessing module Class Adapter: Adapter Adaptee AND Adapter.request() { Adaptee.specificRequest() Client Adpter Adaptee Object Adapter:

7 you want to avoid a permanent binding between an abstraction and its implementation. Bridge Generic implementation of Interface Parameterization abstraction. when the implementation must be selected or switched at run-time. both the abstractions and their implementations should be extensible by subclassing. In this case, the Bridge pattern lets you combine the different abstractions and implementations and extend them independently. you want to share an implementation among multiple objects (perhaps using reference counting), and this fact should be hidden from the client. The implementation of an abstraction can be configured at run-time. Improved extensibility. You can extend the Abstraction and Implementor hierarchies independently. Hiding implementation details from clients. You can shield clients from implementation details, like the sharing of implementor objects and the accompanying reference count mechanism (if any). Variant implementor modules need to be exchangeable at runtime. Extend both abstraction and implementation without affecting existing code. Decoupling of client and implementor modules. Variant implementor modules need to be exchangeable at runtime. Extend both abstraction and implementation without affecting existing code. Decoupling of client and implementor modules. Subclass delegation communication paths Subclass delegation communication paths Abstraction.operation() Implementor.operationImp() Implementor ConcreteImplementor Preprocessing module Interface Parameterization Abstraction.operation(Implementor imp) { imp.operationimp()

8 Subclass Delegation Abstraction RefinedAbstraction AND RefinedAbstraction.refinedOperation() { operation() Client Abstraction ConcreteImplementor Composite you want to represent part-whole Encapsulate part-whole hierarchies Compose whole from hierarchies of objects. you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly. defines class hierarchies consisting of primitive objects and composite objects. makes the client simple. Clients can treat composite structures and individual objects uniformly. makes it easier to add new kinds of components. Newly defined Composite or Leaf subclasses work automatically with existing structures and client code. Compose whole from parts Container interface of objects. Composite and primitive modules provide uniform interface. Encapsulate part-whole hierarchies of objects. Composite and individual modules provide uniform interface. Composite and Leaf modules provide uniform interface. Composite, Component Composite 1..* Component Component.add(Component) Component.remove(Component) Component.getChild(int) parts Compose whole from parts

9 // Composite.operation() method Aggregation of services for all parts { part.operation() Interface Parameterization Composite.operation(Component[] parts) { Component, Composite, Leaf Component Composite Component Leaf Decorator to add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects. Add responsibilities to individual objects transparently, that is, without affecting other objects. Add responsibilities to individual objects dynamically. for responsibilities that can be withdrawn. Add responsibilities to individual objects transparently. when extension by subclassing is An alternative to subclassing to impractical. add an extension. Decorator pattern provides a way to add An alternative to subclassing to responsibilities to objects than can be had add an extension. with static (multiple) inheritance. Decorator offers a pay-as-you-go approach to adding responsibilities. Add responsibilities to individual objects dynamically. Preprocessing module Decorator.operation() { addedbehavior() component.operation() Preprocessing module Interface Parameterization Preprocessing module Preprocessing module Preprocessing module Interface Parameterization

10 Interface Parameterization Decorator.operation(Component comp) { Component ConcreteComponent Facade you want to provide a simple interface to a -- Union of services complex subsystem. there are many dependencies between clients and the implementation classes of an abstraction. Decouple subsystem components from clients. you want to layer your subsystems. Represent subsystem layer. Compose whole from Parts It shields clients from subsystem components. It promotes weak coupling between the subsystem and its clients. It doesn't prevent applications from using subsystem classes if they need to. Compose whole from parts Union of services Decouple subsystem components from clients. Decouple subsystem components from clients. Provide a simple interface to a complex subsystem. Facade 1..* Component Facade.component1Operation() Façade.component2Operation() Client Façade Component Union of services

11 Flyweight An application uses a large number of Reduce data duplication. Object sharing objects. Storage costs are high because of the sheer Reduce data duplication. Object sharing quantity of objects. Most object state can be made extrinsic. Object state can be managed by Object sharing Many groups of objects may be replaced by relatively few shared objects. the reduction in the total number of instances. memory manager. Reduce data duplication. Reduce data duplication. Object sharing Object sharing // FlyweightFactory.getFlyweight() if(flyweightobj exists) { return existing flyweight Object pool search based creation else { create new flyweight add it to the pool of flyweights return the new flyweight Preprocessing module FlyweightFactory Flyweight Client FlyweightFactory Flyweight Interface Parameterization FlyweightFactory.getFlyweight(Flyweight flyweightobj) { Flyweight ConcreteFlyweight

12 Proxy whenever there is a need for a more versatile or sophisticated reference to an object than a simple pointer. Additional actions when an object is accessed. Smart reference A protection proxy controls access to the original object. Authenticated access to the object. Credentials based access A reference count proxy manages the reference count of the object. -- Count number of references introduces a level of indirection when accessing an object. Decouple server object from clients. Preprocessing module Proxy.request() { realsubject.request() Client Proxy RealSubject Proxy pattern Protection proxy

13 Reference count proxy Chain of Responsibility more than one object may handle a request, and the handler isn't known a priori. The handler should be ascertained automatically. you want to issue a request to one of several objects without specifying the receiver explicitly. the set of objects that can handle a request should be specified dynamically. Reduced coupling. Added flexibility in distributing responsibilities among objects. Integrate independent modules to support request propagation. Integrate independent modules to support request propagation. Integrate independent modules to support request propagation. Decouple handler module from clients. Integrate independent modules to support request propagation. // ConreteHandler.handleRequest() if can handle { handle request Chaining else { successor.handlerequest() Interface Parameterization handlerequest(handler successor) { Chaining Chaining Chaining Chaining

14 Handler ConreteHandler Client aconretehandler succesorhandler Command parameterize objects by an action to perform. Generic implementation of the action. Interface parameterization support undo, queue, logging operations. Support for commonly used Library operation structure a system around high-level operations built on primitive operations. primitives. Reuse primitive operations to build high-level operations. Client specifies the receiver of the command. Receiver of the command is specified at runtime. Composite command is assembled from Reuse primitive operations to primitive commands. build high-level operations. Library operation Command.execute() Apply polymorphism Receiver ConcreteReceiver Interface parameterization Command.execute (Receiver receiver) { receiver.action() Library operation Interface parameterization Library operation

15 Interpreter Use the Interpreter pattern when there is a language to interpret. Because the pattern uses classes to represent grammar rules, you can use inheritance to change or extend the grammar. The Interpreter pattern makes it easier to evaluate an expression. Grammar Compose whole from parts Aggregation of services Represent statements in the language Using classes to represent the nonterminals of the grammar. Interpret individual parts of the sentence separately. Grammar Compose whole from parts Aggregation of services TerminalExpression, NonterminalExpression NonterminalExpression 1..* TerminalExpression // NonterminalExpression.interpret() for all parts { part.interpret() AbstractExpression TerminalExpression AbstractExpression NonterminalExpression Interface parameterization NonterminalExpression.interpret(AbstractExpression[] parts) {

16 Iterator to access an aggregate object's contents without exposing its internal representation. to provide a uniform interface for traversing different aggregate structures (that is, to support polymorphic iteration). It supports variations in the traversal of an aggregate. Complex aggregates may be traversed in many ways like preorder, postorder. Iterators simplify the Aggregate interface. Provide a simple way to access the elements of an aggregate object sequentially. Variant aggregate modules need to be exchangeable at runtime. Provide uniform interface for different traversal algorithms. Provide a simple way to access the elements of an aggregate object sequentially. Traversal module Traversal module Traversal module ConcreteIterator.first() Traversal module ConcreteIterator.next() ConcreteIterator.isDone() ConcreteIterator.currentItem() Iterator ConcreteIterator Interface parameterization ConcreteAggregate.createIterator(Iterator iteratorobj) { Mediator a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand. Additional functionality to handle message passing. Remote messaging

17 reusing an object is difficult because it refers to and communicates with many other objects. a behavior that's distributed between several classes should be referred without a lot of subclassing. Additional functionality to handle message passing. Objects use message passing as an alternative to subclassing. Remote messaging Remote messaging It limits subclassing. Objects use message passing as an Remote messaging alternative to subclassing. It decouples colleagues. Hide server location from clients. It simplifies object protocols. Additional functionality to handle message passing. Remote messaging Making mediation an independent concept and encapsulating it in an object lets you focus on how objects interact apart from their individual behavior. Separate object communication functionality from individual behavior. Preprocessing module Remote messaging Mediator.sendMsg() { receiver.receivemsg() Interface Parameterization Mediator.sendMsg(Colleague receiver) { Colleague ConcreteColleague Preprocessing module Mediator ConcreteColleague ConcreteColleague1 Mediator ConcreteColleague2 Memento a snapshot of an object's state must be saved so that it can be restored to that state later. Save a snapshot of object s state. Restore the object state later. Checkpoint Rollback

18 a direct interface to obtaining the state would expose implementation details and break the object's encapsulation. Preserving encapsulation boundaries. It simplifies Originator. Checkpoint Rollback Credentials based access Preprocessing module Authenticated access to the persistence object. Authenticated access to the persistence object. Separate checkpoint and rollback functionality from individual behavior. Originator.createMemento() Originator.setMemento() Memento.setState() Memento.getState() Originator Memento Originator Memento Caretaker Credentials based access Credentials based access Preprocessing module Observer When a change to one object requires changing others. State change in one object requires state change in other objects. Notify modification You don't know how many objects need to be Dependents of an object are known Register at runtime changed. When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don't want these objects tightly coupled. at runtime. Variant modules need to be exchangeable at runtime. Abstract coupling between Subject and Abstract interface of variant Observer. modules is used for coupling. Support for broadcast communication. Variant modules need to be exchangeable at runtime. Apply Polymorphism Interface Parameterization Apply Polymorphism

19 Notify modification Subject.notify() Register at runtime Subject.attach() Subject.detach() Interface Parameterization Subject.notify(Observer[] observers) { for all o in observers o.update(); Subject ConcreteSubject Observer ConcreteObserver State An object's behavior depends on its state, and it must change its behavior at run-time depending on that state. Operations have large, multipart conditional statements that depend on the object's state. State pattern puts each branch of the conditional in a separate class. Object s behavior change at runtime. Encapsulation of multipart conditional branches. It localizes state-specific behavior and Encapsulation of state specific partitions behavior for different states. behavior. It makes state transitions explicit. Variant state modules need to be exchangeable at runtime. State specialized modules ConcreteStateA module ConcreteStateB module State ConcreteStateA State specialized modules State specialized modules

20 State ConcreteStateB Interface Parameterization Context.request(State state) { state.handle() Strategy provide a way to configure a class with one Variant algorithms need to be of many behaviors. exchangeable at runtime. you need different variants of an algorithm. Implement variations of common an algorithm uses data that clients shouldn't know about. Avoid exposing complex, algorithm-specific data structures. a class defines many behaviors, and these appear as multiple conditional statements in its operations. Family of related algorithms. A choice of implementations. interface. Encapsulation of algorithm specific behavior. Variant algorithms need to be exchangeable at runtime. Encapsulation of algorithm specific behavior. Variant algorithms need to be exchangeable at runtime. Algorithm specialized modules ConcreteStrategyA module ConcreteStrategyB module Strategy ConcreteStrategyA Strategy ConcreteStrategyB Interface Parameterization Context.request(Algorithm algorithm) { Algorithm specialized modules Algorithm specialized modules

21 Template Method to implement the invariant parts of an algorithm once and leave it up to subclasses to implement the behavior that can vary. when common behavior among subclasses should be factored and localized in a common class to avoid code duplication. template method calls "hook" operations at specific points, thereby permitting extensions only at those points. Template methods are a fundamental technique for code reuse, they are the means for factoring out common behavior in library classes. Generalize service commonality implement the invariant parts of an algorithm once. leave it up to subclasses to implement the behavior that can vary. Generic implementation of common behavior. Implement variations of common interface. Generic implementation of common behavior. AbstractClass.templateMethod() AbstractClass ConcreteClass Generalize service commonality Generalize service commonality Generalize service commonality

22 Visitor an object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes. many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid polluting their classes with these operations. the classes defining the object structure rarely change, but you often want to define new operations over the structure. Changing the object structure classes is potentially costly. Variations of the operation on different concrete classes need to be represented. Adding new operations does not affect existing object structure. Adding new operations does not affect existing object structure. Visitor makes adding new operations easy. Adding new operations does not affect existing object structure. Related behavior is gathered and localized in a visitor. Add an individual module Enumerate variations Variations of the operation on different concrete classes need to be represented. ConcreteVisitor1, ConcreteVisitor2 ConcreteVisitor.visitConcreteElementA() ConcreteVisitor.visitConcreteElementB() Visitor ConcreteVisitor Interface Parameterization ConcreteElement.accept(Visitor v) Enumerate variations Add an individual module Add an individual module Add an individual module Enumerate variations Layers Designing a system whose dominant characteristic is a mix of low- and high-level issues, where high-level operations rely on the lower-level ones. High-level decomposition of the system whose dominant characteristic is a mix of low- and high-level issues. Multiple Abstraction levels

23 A typical pattern of communication flow consists of requests moving from high to low level, and answers to requests, incoming data or notification about events traveling in the opposite direction. Portability to other platforms is desired. Several external boundaries of the system are specified a priori, such as a functional interface to which your system must adhere. Late source code changes should not ripple through the system. Interfaces should be stable, and may even be prescribed by a standards body. Parts of the system should be exchangeable. It may be necessary to build other systems at a later date with the same low-level issues as the system you are currently designing. Similar responsibilities should be grouped to help understandability and maintainability. Reuse of layers. If an individual layer embodies a well-defined abstraction, the layer can be reused in multiple contexts. Support for standardization. Dependencies are kept local. Exchangeability. Individual layer implementations can be replaced by semantically-equivalent implementations. High-level decomposition of the system whose dominant characteristic is a mix of lowand high-level issues. Decouple lower abstraction modules from higher abstraction modules. Implement variations of common interface. Decouple lower abstraction modules from higher abstraction modules. Implement variations of common interface. Variant modules need to be exchangeable at runtime. High-level decomposition of the system whose dominant characteristic is a mix of lowand high-level issues. High-level decomposition of the system whose dominant characteristic is a mix of lowand high-level issues. High-level decomposition of the system whose dominant characteristic is a mix of lowand high-level issues. Implement variations of common interface. Decouple lower abstraction modules from higher abstraction modules. Variant modules need to be exchangeable at runtime. Multiple Abstraction levels Layer 1, Layer 2,, Layer N Layer J+1 Layer J Layer J-1 AbstractLayer Layer Multiple Abstraction levels Multiple Abstraction levels Multiple Abstraction levels Multiple Abstraction levels

24 Pipes-and-Filters building a system that process or transform a stream of input data. Future system enhancements should be possible by exchanging processing steps or by recombination of steps. Small processing steps are easier to reuse in different contexts than large components. Non-adjacent processing steps do not share information. Different sources of input data exist, such as a network connection or a hardware sensor. It should be possible to present or store final results in various ways. Explicit storage of intermediate results for further processing in files is errorprone. No intermediate files necessary. Flexibility by filter exchange. Flexibility by recombination. Reuse of filter components. Multiple Processing stages High-level decomposition of the system whose characteristic is multi-stage data transformation. Variant filter modules need to be exchangeable. Decoupling of non-adjacent processing steps. Processing stages for input and output transformation of the system. Files are not used to share intermediate results between adjacent processing stages. Files are not used to share intermediate results between adjacent processing stages. Variant filter modules need to be exchangeable. Abstract coupling between filter modules. High-level decomposition of the system whose characteristic is multi-stage data transformation. Multiple Processing stages -- Multiple Processing stages Filter 1, Filter 2,, Filter N Multiple Processing stages Request propagation Chaining Interface Parameterization Multiple Processing stages

25 Chaining Filter.execAction() { process request successorfilter.execaction() Interface Parameterization Filter.execAction(AbstractFilter successorfilter) { AbstractFilter Filter Filter J-1 Filter J Filter J+1 Blackboard The system processing spans several fields of expertise. problems that do not have a feasible deterministic solution for the transformation of raw data into high-level data structures. In many cases no predetermined strategy exists for how the partial problem solvers should combine their knowledge. A complete search of the solution space is not feasible in a reasonable time. Since the domain is immature, you may need to experiment with different algorithms for the same subtask. For this reason, individual modules should be easily exchangeable. There are different algorithms that solve partial problems. For example, the detection of phonetic segments in the waveform is unrelated to the generation of phrases based on words and word sequences. Input, as well as intermediate and final results, have different representations, and the algorithms are implemented according to different paradigms. High-level decomposition of the system whose processing spans several fields of expertise. Data-directed dynamic problem solving process. Data-directed dynamic problem solving process. Data-directed dynamic problem solving process. Variant solver modules need to be exchangeable. High-level decomposition of the system whose processing spans several fields of expertise. Implement variations of common interface. Multiple Partial problem solvers Heuristics based chaining Heuristics based chaining Heuristics based chaining Multiple Partial problem solvers

26 Experimentation. A complete search of the Data-directed dynamic problem solution space is not feasible. solving process. Support for changeability and Decoupling of solution steps. maintainability. The individual knowledge sources, and control algorithm are strictly separated. However, all modules can communicate via the blackboard. Reusable knowledge sources. Knowledge High-level decomposition of the sources are independent specialists for system whose processing spans certain tasks. several fields of expertise. Heuristics based chaining Multiple Partial problem solvers Multiple Partial problem solvers KnowledgeSource 1, KnowledgeSource 2,, KnowledgeSource N KnowledgeSource J Blackboard KnowledgeSource J+1 Heuristics based chaining KnowledgeSource.execAction() successor = Controller.nextSource() successor.execaction() Interface Parameterization nextsource(abstractknowledgesource successor) { AbstractKnowledgeSource KnowledgeSource Broker Your environment is a distributed and possibly heterogeneous system with cooperating components. By partitioning functionality into independent components the system becomes potentially distributable and scalable. If components handle communication themselves, the resulting system faces several dependencies and limitations. Services for adding, removing, exchanging, activating and locating components are also needed. High-level decomposition of distributed systems. High-level decomposition of distributed systems. High-level decomposition of distributed systems. Implement variations of standard communication services. Separate communication mechanisms Separate communication mechanisms Separate communication mechanisms Apply polymorphism

27 From a developer's viewpoint, there should essentially be no difference between developing software for centralized systems and developing for distributed ones. An application that uses an object should only see the interface offered by the object. It should not need to know anything about the implementation details of an object, or about its physical location. Components should be able to access services provided by others through remote, location-transparent service invocations. The architecture should hide system- and implementation-specific details from the users of components and services. Location Transparency. Clients do not need to know where servers are located. Similarly, servers do not care about the location of calling clients. Changeability and extensibility of components. If servers change but their interfaces remain the same, it has no functional impact on clients. Reusability. When building new client applications, you can often base the functionality of your application on existing services. Separate communication mechanisms Apply polymorphism Application level components interact only using provider s interface. Application level components interact only using provider s interface. Hide server location from clients. High-level decomposition of distributed systems. Hide server location from clients. Application level components interact only using provider s interface. High-level decomposition of distributed systems. Separate communication mechanisms Separate communication mechanisms Separate communication mechanisms Separate communication mechanisms Separate communication mechanisms Application layer Client, Server Proxy layer Client-side proxy, Server-side proxy Communication layer Broker, Bridge AbstractBroker Broker Client Broker Server

28 Model-view-controller requirements on the user interface. The same information is presented differently in different windows, for example, in a bar or pie chart. Supporting different 'look and feel' standards or porting the user interface should not affect code in the core of the application. The display and behavior of the application must reflect data manipulations immediately. Changes to the user interface should be easy, and even possible at run-time. Different users place conflicting Handle multiplicity in user- Multiple views interface requirements. Handle multiplicity in userinterface requirements. Individual components are designed to be high cohesive modules. State change in model component requires state change in user interface components. State change in model component requires state change in user interface components. Different user interface for the same model. Handle multiplicity in userinterface requirements. Synchronized views. State change in model component requires state change in user interface components. Pluggable views and controllers. Exchangeability of look and feel. Framework potential. A framework based on MVC implements reusable view and controller components. View components attach and detach to model component at runtime. Variant view modules need to exchangeable. Individual components are designed to be high cohesive modules. Multiple views View 1, View 2,, View N Specialized modules Model, Controllers, Views Notify modification Model.notify() Register at runtime Model.attach() Model.detach() Interface Parameterization Model.notify(AbstractView[] views) { AbstractView View View Controller Model Multiple views Specialized modules Notify modification Notify modification Multiple views Notify modification Register at runtime Specialized modules

29 Presentation-Abstraction-Control Complex information need to support for -- Hierarchy of views multiple levels of Human-Computer interaction. Multiple collaborating agents are organized System provides different levels Multiple Abstraction as tree-hierarchy. Tree-hierarchy reflects transitive dependencies among agents. of information processing. Decouple lower abstraction agents from higher abstraction agents. Support for various stakeholder concerns. Separation of concerns. The application is structured as hierarchy of collaborating agents. Support for change. Source code changes to one agent do not ripple through the system. Hierarchy of views Multiple Abstraction levels Complex information need to support for multiple levels of Human-Computer interaction. System provides different levels of information processing. Decouple lower abstraction agents from higher abstraction agents. levels communication paths Hierarchy of views Multiple Abstraction levels communication paths CRUD level interface Spreadsheet level interface Statistical graph level interface Bottom level agents Intermediary level agents Top level agents Top level agent Intermediary level agent Bottom level agent

30 Microkernel The application platform must cope with software evolution. High-level decomposition of evolvable systems. Separation of functional core The application platform must allow easy integration of emerging technologies. Decouple functional core modules to support emulation. The application platform should be High-level decomposition of Separation of extensible. The applications in your domain need to support different, but similar, application platforms. The applications may be categorized into groups that use the same functional core in different ways, requiring the underlying application platform to emulate existing standards. Portability. A Microkernel system offers a high degree of portability. In order to migrate a system to a new hardware platform, it is sufficient to migrate the functional core of the system. Extensibility. If you need to implement an additional functionality, all you need to do is add a new external server. Separation of policy and mechanism. The microkernel component provides all the mechanisms necessary to enable external servers to implement their policies. Separation of functional core extensible systems. Implement variations of common interface. Decouple functional core modules to support emulation. Migration of system through functional core. Support extensibility through extension layer of the system. Decompose the system into kernel and extension subsystems. External server subsystem Emulator subsystem Microkernel subsystem External server Emulator Microkernel PlatformInterface Microkernel functional core Separation of functional core Separation of functional core Separation of functional core

31 Reflection Changing software is tedious, error prone, and often expensive. Software which actively supports and controls its own modification can be changed more effectively and more safely. Adaptable software systems usually have a complex inner structure. To keep change behavior of such systems, we prefer to hide this complexity from maintainers of the system. A uniform mechanism that applies to all kinds of changes is easier to use and understand. Adapting an application framework for a specific customer. Even fundamental aspects of software systems can change, for example the communication mechanisms between components. Support modification of the behavior without changing the code. Provide a simple control panel for behavior modification. Provide a simple control panel for behavior modification. Support modification of the behavior without changing the code. Implement variations of common interface to be exchangeable. No explicit modification of source code. Changing a software system is easy. Support for many kinds of change. Metaobjects can encapsulate every aspect of system behavior, state and structure. Support modification of the behavior without changing the code. Provide a simple control panel for behavior modification. Provide a simple control panel for behavior modification. Parameter based behavior selection Parameter based behavior selection Parameter based behavior selection Parameter based behavior selection Parameter based behavior selection Parameter based behavior selection Parameter based behavior selection

32 Parameter based behavior selection Multiple Abstraction levels Meta objects Base level Meta level Behavior selection level Client Behavior selection level Meta level Client Behavior selection level Base level AbstractMechanism Mechanism Whole-part A complex object should either be decomposed into smaller objects, or composed of existing objects, to support reusability, and changeability of structure. Clients should see the aggregate object as an atomic object that does not allow any direct access to its constituent parts. Changeability of Parts. The Whole encapsulates the Parts and thus conceals them from its clients. This makes it possible to modify the internal structure of the Whole without any impact on clients. Separation of concerns. A Whole-Part structure supports the separation of concerns. Each concern is implemented by a separate Part. Reusability. Parts of a Whole can be reused in other aggregate objects. Compose whole from parts Design complex object from smaller parts. Decouple constituent parts from clients. Decouple constituent parts from clients. Design complex object from smaller parts. Design complex object from smaller parts. Whole 1..* Part Compose whole from parts Compose whole from parts Compose whole from parts

33 Aggregation of services Whole.service1() { Whole.serviceA1() Whole.serviceB1() Whole.serviceN1() Client Whole Part Master-slave A Computationally intensive task uses -- Work partitioning Divide-and-conquer principle. Clients should not be aware that the calculation is based on the 'divide and conquer' principle. Neither clients nor the processing of subtasks should depend on the algorithms for partitioning work. It can be helpful to use different but semantically-identical implementations for processing sub-tasks. Supports parallel computation. Exchangeability. By providing an abstract slave class, it is possible to exchange existing slave implementations. Separation of concerns. The introduction of the master separates slave and client code from the code for partitioning work. Eficiency. The Master-Slave pattern for parallel computation enables you to speed up the performance. Hide task processing details from clients. Separate work partitioning module from subtask modules. Variant processing subtasks provide common interface to be exchangeable. A Computationally intensive task uses Divide-and-conquer principle. Variant slave classes provide common interface to be exchangeable. Separate work partitioning module from subtask modules. A Computationally intensive task uses Divide-and-conquer principle. Compose whole from parts Work partitioning Compose whole from parts Work partitioning

34 Work partitioning Master.splitWork() Compose whole from parts Master 1..* Slave Aggregation of services // Master.splitWork () method for all slaves { slave.subservice() Client Master Slave Interface Parameterization Master.splitWork(AbstractSlave[] slaves) { AbstractSlave Slave Command processor You often need to implement services that go beyond the core functionality of the system for the execution of user requests. Examples are request queueing, scheduling and suspension. Different users like to work with an application in different ways. Additional services such as scheduling should be implemented consistently for all requests. Flexibility in the way requests are activated. Different user interface elements for requesting a function can generate the same kind of command object Flexibility in the number and functionality of requests. The controller and command processor are implemented independently of the functionality of individual commands. Support for commonly used execution primitives. Different user commands implements variation of common interface. Generic implementation of execution management services. Different user commands implements variation of common interface. Generic implementation of execution management services. Execution management library Interface Parameterization Interface Parameterization

35 Programming execution-related services. The central command processor easily allows the addition of services related to command execution. Concurrency. Command processor also implements services related to concurrent execution commands such as synchronization. Support for commonly used execution primitives. Support for commonly used execution primitives. Execution management library Execution management library Execution management library CommandProcessor.queue() CommandProcessor.schedule() CommandProcessor.suspend() Interface Parameterization CommandProcessor.schedule(AbstractCommand command) { AbstractCommand Command View handler Software systems supporting multiple views often need additional functionality for managing them. open, manipulate, dispose, and coordination of views. Implementation of view management does not depend individual views implementations. View implementations can vary, types of views may vary. Uniform handling of views. Exchangeability of views. Support for commonly used view management primitives. Generic implementation of view management services. Different view modules implements variation of common interface. Generic implementation of view management services. Different view modules implements variation of common interface. View management library Interface Parameterization Interface Parameterization

36 View management library ViewHandler.open() ViewHandler.close() ViewHandler.update() ViewHandler.clone() Interface Parameterization ViewHandler.update(AbstractView[] views) { AbstractView View Forwarder-Receiver The system should allow the exchangeability Exchangeability of of the communication mechanisms. The cooperation of components follows a peer-to-peer model, in which a sender only needs to know the names of its receivers. Efficient inter-process communication. The separation of IPC functionality from peers introduces an additional level of indirection. Compared to the time consumption of the actual IPC, however, this overhead should be negligible in most cases. Encapsulation of IPC facilities. All dependencies on concrete IPC facilities are encapsulated within the forwarders and receivers. communication components. Additional functionality to handle message passing. Hide location of a remote peer from other peers. Integrate multiple modules to support request propagation. Remote messaging Receiver.receiveRequest() { Forwarder.sendRequest() Remote messaging Chaining

37 Forwarder.sendRequest() { Reeceiver.receiveRequest() Chaining Peer 1 Receiver1 Forwarder1 Receiver2 Peer 2 Peer 1 Forwarder 1 Forwarder N Peer 2 AbstractForwarder Forwarder AbstractReceiver Receiver Interface Parameterization Forwarder.sendRequest(AbstractReceiver receiver) { Client-Dispatcher-Server A component should be able to use a service independent of the location of the service provider. The code implementing the functional core of a service consumer should be separate from the code used to establish a connection with service providers. Exchangeability of servers. Location and migration transparency. Additional functionality to handle message passing. Separate object communication functionality from individual service providers. Variant server classes provide common interface to be exchangeable. Decouple server modules from clients. Remote messaging Remote messaging Dispatcher.sendRequest() { server.receiverequest() Interface Parameterization Dispatcher.sendRequest(AbstractServer server) { Preprocessing module

38 Preprocessing module AbstractServer Server Dispatcher Server Clinet Dispatcher Server Publisher-Subscriber One or more components must be notified about state changes in a particular component. The number and identities of dependent components is not known a priori, or may even change over time. The publisher and its dependents should not be tightly coupled when introducing a change-propagation mechanism. Registry. The publisher maintains a registry of currently-subscribed components. Synchronization. Whenever the publisher changes state, notify method of publisher sends a notification to all its subscribers. Notify modification Register at runtime State change in one object requires state change in other objects Dependants of an object are known at runtime Abstract coupling between publisher and subscriber modules Dependants of an object are known at runtime State change in one object requires state change in other objects PublisherSubscriber.notify() PublisherSubscriber.registerSubject() PublisherSubscriber.unregisterSubject() PublisherSubscriber.registerObserver() PublisherSubscriber.unregisterObserver() Notify modification Register at runtime Interface Parameterization Register at runtime Notify modification Add an individual module PublisherSubscriber module Interface Parameterization PublisherSubscriber.notify(Observer[] observers) { Observer ConcreteObserver Subject PublisherSubscriber ConcreteObserver

39