Topic Title 6: Other Software Architecture Examples: Design Patterns
ICT373: Software Architectures
• Distributed systems over a network and communicate through Sockets.
Copyright By PowCoder代写 加微信 powcoder
• Client-Server applications on the Web.
Outline • Patterns
• Examples of Architectures as Patterns:
• layered, pipe-filter, client-server, singletons, observers, blackboards,
interpreter
1. Deitel & Deitel, Java How to Program, 11th edition: Appendix N – Design Patterns (On author’s website)
2. Java Design
Patterns Resource Centre:
http://www.deitel.com/ResourceCenters/Programming/JavaDesignPatterns/ta bid/1103/Default.aspx
Objectives
• Explain what is meant by a design pattern.
• Describe the characteristics of patterns.
• Give some examples of patterns.
• Explain the use of the Singleton pattern and how it might be implemented in Java.
• Explain the use of the Observer pattern and how it might be implemented in Java.
• Explain how different patterns and/or architectures could be involved in the same system.
• Describe the blackboard architecture.
• Explain the use of a virtual machine.
• A good designer will reuse designs:
• it is very hard work to instead develop and perfect a brand new design.
• In order to reuse and share good designs ( = good ways of solving general problems) and good architectures (i.e. high-level design decisions), software designers have started classifying and formalizing good workable approaches to design solutions for general types of problems.
• These are often called patterns or design patterns.
• The concept of a pattern as used in software architecture is borrowed from the field of architecture (buildings, spaces), in particular from the writings of architect .
• Design patterns are proven architectures for developing object oriented software. They promote design re-use and help reduce the complexity of design process.
• A pattern will present (in a more or less standard way) a description of the various components, connectors and control structures that will be needed to implement the solution.
• The pattern idea is most often associated with O-O designers who will talk of the various classes and objects needed and show example implementations in languages such as Smalltalk, C++ or Java.
• However, patterns are also mentioned in connection with more general software architectures. Then the components can be machines, compilation units, modules etc.
Design patterns: Definition
• Design patterns are recurring solutions to design problems you see over and over [The Design Patterns Smalltalk Companion].
• Design patterns constitute a set of rules describing how to accomplish certain tasks in the realm of software development [Pree, 1994].
• A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate. [Buschmann et al, 1996]
• Patterns identify and specify abstractions that are above the level of single classes and instances, or of components [Gamma et al, 1995].
Characteristics of Patterns
• Patterns have the following characteristics in general [Buschmann]:
• A pattern describes a solution to a recurring problem that arises in specific design situations.
• Patterns are not invented; they are distilled from practical experience.
• Patterns describe a group of components (e.g., classes or objects), how the components interact, and the responsibilities of each component, i.e., they are higher level abstractions than classes or objects.
• Patterns provide a common vocabulary for communication among designers. The choice of a name for a pattern is very important.
• Patterns help document the architectural vision of a design. If the vision is clearly understood, it will less likely be violated when the system is modified.
Characteristics of Patterns
• Patterns provide a conceptual skeleton for a solution to a design problem and, hence, encourage the construction of software with well- defined properties
• Patterns are building blocks for the construction of more complex designs.
• Patterns help designers manage the complexity of the software. When a recurring pattern is identified, the corresponding general solution can be implemented productively to provide a reliable software system.
How to use patterns
• The hope is that large books of patterns can be published. These will be systematically organized to allow ease of use.
• There will be detailed descriptions of when to apply each pattern, i.e. in what general situations is it useful, what conditions should be met, and how to look at the problem in the right way.
• There will be detailed descriptions of the solution, i.e. how to choose and arrange the components to solve the problem, example implementations in a variety of languages or suggestions as to which specific languages might be best used.
• There will be descriptions of the consequences of using the design, i.e. what are the pros and cons, eg, the pattern might be inflexible in some ways but very fast, or it might be slightly slower but allow maximum scope for future extensions in a certain way.
How to use patterns
• At the moment such catalogues do exist in preliminary forms. Eg, Design Patterns, Elements of Reusable Object-Oriented Software by Gamma et al (Addison-Wesley, 1995) contains details of 23 very useful design patterns.
• It may save a software development team months of time and effort to just be aware of the brief descriptions of these patterns. The catalogue includes real-world examples of use.
How to use patterns
Design patterns can be divided into 3 categories:
• Creational Patterns: Creational patterns create objects for you, rather than you having to instantiate objects directly. Your program gains more flexibility in deciding which objects need to be created for a given case.
• Structural Patterns: Structural patterns help you compose groups of classes and objects into larger structure, eg complex user interface and accounting data. They describe common ways to organise classes and objects.
• Behavioural patterns: These patterns assign responsibilities to classes and objects. They help you define the communication and collaboration between objects in your system and how the flow is controlled in a complex system.
How to use patterns
• Gamma et al (in their book) described 23 design patterns, which are listed below:
• 5 Creational design patterns: Abstract Factory, Factory Method, Builder, Prototype, Singleton.
• 7 Structural patterns: Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy
• 11 Behavioural patterns: Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor.
(http://www.oodesign.com/)
A Brief Overview: Example Patterns
• Adapter: converts the interface of a class into another interface clients expect.
• Command: encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and supports undoable operations.
• Decorator: attaches additional responsibilities to an object dynamically.
• Iterator: provides a way to access the elements of an aggregate object
sequentially without exposing its underlying representation.
• Prototype: specifies the kinds of objects to create using a prototypical instance, and creates new objects by copying this prototype.
• Proxy: provides a surrogate or placeholder for another object to control access to it.
• Strategy: defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
converts the interface of a class into another interface clients expect.
https://www.geeksforgeeks.org/adapter-pattern/
encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and supports undoable operations
https://sourcemaking.com/design_patterns/command
attaches additional responsibilities to an object dynamically
https://www.journaldev.com/1540/decorator-design-pattern-in- java-example
• By dynamic loading or To avoid building a class hierarchy of factories that parallels the class hierarchy of products or
• 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.
https://www.geeksforgeeks.org/prototype-design-pattern/
provides a surrogate or placeholder for another object to control access to it.
https://sourcemaking.com/design_patterns/proxy
Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
https://sourcemaking.com/design_patterns/strategy
The Singleton Pattern
• Used to ensure that a class has one and only one instance object, and provide a global point of access to it.
• Uses: various types of managers (of security, GUIs, interaction with databases and other programs, data structures, etc). Also used in the Java libraries.
• One implementation approach is to let the class have a static object but make constructors private and disallow cloning so that no other objects can be made.
• Eg, an implementation from Eckel. Since this class isn’t inherited from a Cloneable base class and cloneability isn’t added, making it final prevents cloneability from being added in any derived classes:
Singleton: uses
• The abstract factory, builder, and prototype patterns can use singletons in their implementation.
• Facade objects are often singletons because only one facade object is required.
• State objects are often singletons.
• Singletons are often preferred to global variables because:
• They do not pollute the global namespace (or, in languages with namespaces, their containing namespace) with unnecessary variables.
• They permit lazy allocation and initialization, whereas global variables in many languages will always consume resources.
Composite Design Pattern
“Compose objects into tree structure to represent part-whole hierarchies. Composite lets client treat individual objects and compositions of objects uniformly”.
When to use it:
• you want to represent part-whole hierarchies of objects.
• you want client to be able to ignore difference between
compositions of objects and individual objects.
• Clients will treat all objects in the composite structure uniformly.
Composite Design Pattern
• Component • Leaf
• Composite
• WorkFlow • Recursion
Composite design pattern
Case study: In a small organization, there are 5 employees. At top position, there is 1 general manager. Under general manager, there are two employees, one is manager and other is developer and further manager has two developers working under him. We want to print name and salary of all employees from top to bottom.
UML Diagram
The Observer Pattern
• Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
• This solves a very common problem. Often an application presents multiple views of the same underlying object/data. Eg, word processors (printing layout vs HTML), data presentation (pie charts, histograms, data lists), CAD (overhead view and elevation) etc. When the user changes the underlying object then all views must be updated.
The Observer Pattern
In fact, the observer pattern is so generally useful that it is supported directly in the java.util library.
The library supplies a class Observable which keeps a record of who needs notifying and notifies them (by calling their update method) when the Observable object gets notifyObservers() method called.
To be notified, an object needs to implement the Observer interface which just contains the update method.
An argument can be passed to notifyObservers( Object a) and this will be passed on to the update calls.
Observer pattern: Example
Some Patterns for Software Architectures
• There are classifications of some common architectures as design patterns. Most of what can be said about O-O design patterns applies to architectural patterns as well.
• Eg, we want a classification which describes problems addressed (and context) and the solution.
• It is important to realise that several architectural patterns can be applied to one piece of software.
• It is possible to view the same design as an example of two different patterns. Each pattern may be a valid and useful way of looking at the design. It might also be even more useful to have both views of the design.
• Eg, we view a client-server system as an O-O design by implementing it, maybe using RMI, to encapsulate all processing in client objects and a server object.
Patterns for Software Architectures
• It is also possible that one complicated architecture might involve various other architectures at a more detailed level. Eg, a filter in a pipe-filter system may be itself implemented via an O-O design.
• Here we look at some of the common architectural patterns from a paper by and .
• Problem: applications which require a defined series of independent computations to be performed on ordered data. This architectural pattern is particularly useful when computations can be performed incrementally.
• Solution: Data flow (via streams) between filter components (computational, local processing, asynchronous).
• Variants: batch processing, but be careful with loops as they might cause starvation problems.
Layered Architectures
• Problem: applications involving distinct classes of services that can be arranged hierarchically. Often there are layers for basic system-level services, utilities appropriate to many applications and specific application tasks.
• Context: Assign each class of service to a specific layer. Use different patterns to refine each layer’s design.
• Solution: A hierarchy of opaque layers. Components (layers) are composed of procedures. Connections between layers are via procedure calls or a client-server design. There is a single thread of control.
• Variants: 1) layers may be transparent or opaque (i.e. only the interface defined by a given layer may be used by the next layer up).
• 2) layered systems are often organized as chains of virtual machines or interpreters.
Repository (= blackboard) Architecture
• Problem: applications in which the central issue is establishing, augmenting and maintaining a complex central body of information. Typically the information must be manipulated in a wide variety of ways. Often long-term persistence may also be required.
• Different variants support radically different control strategies.
• Context: Repositories often require considerable support, either from an augmented runtime system (such as a database) or a framework or generator that processes the data definitions.
• Solution: System model: Centralized data, usually richly structured. Components: one memory, many computational processes. Connectors: direct access or procedure calls. Control structure: varies.
• Variants: databases, compilers, AI blackboard systems.
How to Implement a Blackboard
• This depends exactly on what sort of blackboard is needed. But generally as follows:
• You need one blackboard object and multithreading for the various computational processes. There needs to be synchronization on access to the blackboard.
• For big problems you may need to hide a database (connected using JDBC) under the blackboard interface. Otherwise an internal data structure will do. The exact type of structure and interface depends on the problem.
• Eg 1, the blackboard might just be a set of objects. Processes will be able to add and remove objects and check whether a given object is there. So there are three public blackboard methods.
• Eg 2, the blackboard might contain the draft design of a complex building (or large sheep farm or banana plantation). The processes might contain network connections to various distributed building architects. There may be many complex methods available for interaction with the blackboard.
Interpreter Pattern
Problem: applications in which the most appropriate language or machine for executing the solution is not directly available. It is also suitable for applications in which the core problem is to define a notation for expressing solutions (for example, as scripts). Interpreters are sometimes used in chains, translating from the desired language or machine to an available one in a series of stages.
Interpreter Pattern
Context: the interpreter is most often designed to bridge the gap between the desired machine or language and some (possibly virtual) machine or language already supported by the execution environment.
Solution: Virtual machine consisting of a state machine (the execution engine) and three memories (state of execution, program being interpreted and current state of program). Control by state-transition.
Variants: Expert systems.
Subtitle if required
• This topic introduced the concept of design patterns and looked at a number of design patterns available to software designers.
• Such patterns
• promote design re-use in future systems
• help to identify common mistakes and pitfalls that occur when building systems
• shorten the design phase in a software development process.
• A number of examples of software architectures are grouped in this topic.
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com