Information systems modelling UML and service description languages

Transcription

1 Internet Engineering Tomasz Babczyński, Zofia Kruczkiewicz Tomasz Kubik Information systems modelling UML and service description languages

2 Overview of design patterns for supporting information systems modelling Gamma E., Helm R., Johnson R., Vlissides J., Design PATTERNS: Elements of reusable object-oriented software. 1. Introduction 2. Identification of design patterns 3. Review of design patterns 3.1. Creational patterns 3.2. Structural patterns 3.3. Behavioral patterns

3 Overview of design patterns for supporting information systems modelling Gamma E., Helm R., Johnson R., Vlissides J., Design PATTERNS: Elements of 1. Introduction reusable object-oriented software.

4 Introduction (1.1) - Assumption The information system is needed for: a large number of users, huge size of executing data and vast amounts of execututed services.

5 Introduction (1.2) - Solution Multitier information system + each tier built of design ` patterns Scalab ility Performance Complexity; 1. completeness of abstraction 2. reusability 3. testability 4. understandability 5. maintainability Quality of software

6 Introduction (1.3) Each tier of software is specialized in the implementation of sub-services used to implement the full functionality of the system. Scalability is a property of a system, which indicates its ability either to handle growing amounts of work or to become enlarged - it can add resources such as buffers with data and instances of services. Program performance is defined by a number of units of input data (data size), which in due time, the program manages to transform into units of output (data).

7 Introduction (2.1) Generally, the use of design patterns supports the creation of high-quality software in an efficient manner. A pattern must be always programmed into each application that uses it. A pattern must be always programmed into each application that uses it. It is not a step backward from the software reuse - because of transformation and implementation of design patterns into the functionaloriented reusable components.

8 Introduction (2.2) Design patterns can be improved by making refactoring based on transforming some micro-architectures onto functionality equivalent ones. Therefore they prevent of reducing the scalability, performance or quality of software. This way of the software development is better than based on designs without taking into account the context of using of them. The use of design patterns improves the management of software development.

9 Introduction (2.3) Developers should have the knowledge of techniques based on design patterns which are used in object-oriented analysis, design and programming for building object oriented multi-tiers software based on design patterns of Client, Web, Business and Enterprise information system tiers. This follows from the fact that design patterns are composed of several sections: on the one side, there is the classification based on the Structure, Creational, and Behavioural sections on the other side there is classification supporting design and implementation of the multi-tier software such as Presentation, Business and Integration Patterns.

10 Overview of design patterns for supporting information systems modelling Gamma E., Helm R., Johnson R., Vlissides J., Design PATTERNS: Elements of 1. Introduction reusable object-oriented software. 2. Identification of design patterns

11 Identification of design patterns (1) A well-built object system is full of object-oriented patterns A pattern is usually adopted to solve a typical problem in the given context A structure of a design pattern is represented in the form of a class diagram The pattern behaviour is shown by means of a sequence diagram A design pattern represents the relationship between a problem and its solutions (according to G. Booch, J. Rumbaugh, I. Jacobson, UML User's Guide)

12 Identification of design patterns (2) Each pattern consists of three parts, which express the relationship between a particular context, problem and solution (based on Christopher Alexander) Each design pattern is a three-part rule that expresses the relationship between a particular context, a recurrent distribution of forces in this context, and software configuration, allowing for the mutual balancing of these forces in order to solve the task (based by Richar Gabriel) A design pattern is an idea that proved to be useful in a real context and will probably be useful in another (Martin Fowler)

13 Identification of design patterns (3) As one kind of classification there are three types of design patterns: creational, structural and behavioural. They are based on concepts of: aggregation, inheritance, encapsulation, interface polymorphism paradigms of object- oriented methodology in structure and behaviour of software.

14 Identification of design patterns (4) Each pattern is described by using the following template: A solved problem, A solution of problem with description of components of pattern, A client of pattern, A result.

15 Overview of design patterns for supporting information systems modelling Gamma E., Helm R., Johnson R., Vlissides J., Design PATTERNS: Elements of 1. Introduction reusable object-oriented software. 2. Identification of design patterns 3. Review of design patterns

16 Review of design patterns 1. Creational patterns 2. Structural patterns 3. Behavioral patterns

17 Overview of design patterns for supporting information systems modelling Gamma E., Helm R., Johnson R., Vlissides J., Design PATTERNS: Elements of reusable object-oriented software. 1. Introduction 2. Identification of design patterns 3. Review of design patterns 3.1. Creational patterns

18 Creational patterns A main goal: Isolation of the rules for creating objects from the rules that determine how the use of these objects (separation of the code for creating objects from the code that uses them) A list of creational patterns: Design pattern 1)Abstract Factory 2)Builder 3)Factory Method 4)Prototype 5)Singleton The aspect, which can change The family of objects The way of creating the complex object The subclass of the created object The class of the created object Only one copy of the class

19 Creational patterns Related patterns Design pattern Creational Patterns Structural Patterns 1)Abstract Factory 2)Builder Factory Method, Singleton Abstract Factory, Prototype Composite, Behavioral Patterns 3)Factory Method Abstract Factory Template Method 4)Prototype Abstract Factory, Composite, Decorator 5)Singleton Abstract Factory, Builder, Prototype

20 Abstract Factory (1) Problem: Creating the appropriate families of related or dependent objects in the following cases: different operating systems, different requirements for effectiveness, efficiency, etc. various versions different types of co-applications (such as different types of databases) different functionality for different users different groups of elements depending on the settings related to the location (e.g. data format)

21 Abstract Factory (2)

22 Abstract Factory (3)

23 Abstract Factory (4) Solution: A Client object uses the AbstractFactory interface and AbstractProduct interface. ConcreteProduct and ConcreteFactory are classes that implement these interfaces. Each ConcreteFactory object can create one of the families of ConcreteProduct objects. Main client: The Client object manages creation of objects by the factory, but it is independent of the rules on creation of these objects Result: Isolation of the rules for creating objects from the rules that determine how the use of objects Definitions of rules to create objects that can best achieve the main goals of the application Configuring applications using associated objects The system uses created objects, knowing their base classes

24 Builder (1) Problem: Creating complex custom objects represented in different ways Solution: A Director object has a request to a ConcreteBuilder object that implements a Builder interface for creating the Product object Client: A Client instructs the Director object to create the Product object by using the supplied ConcreteBuilder object.

25 Builder (2) This does not affect the client code, because of converting abilities of ConcreteBuilder objects. the ASCII format document represented by the Products objects ASCII converter from the documents of the RTF or the XML formats

26 Builder (3)

27 Result: Builder (4) Director objects receive the Builder abstract interface, that allows you to freely construct Product objects. Separating the code used to construct Product objects from the code for using these objects. The algorithm to build a Product object is created independently of its components that may be of any type. Better control of the construction of the Product object by using operations, implemented through an Builder interface by the ConcreteBuilder object and controlled by the Director object.

28 Overview of design patterns for supporting information systems modelling Gamma E., Helm R., Johnson R., Vlissides J., Design PATTERNS: Elements of reusable object-oriented software. 1. Introduction 2. Identification of design patterns 3. Review of design patterns 3.1. Creational patterns 3.2. Structural patterns

29 Structural patterns The main goal: Grouping classes and objects into larger structures Class design pattern: use of inheritance and polymorphism to make structures of interfaces and their implementations Object design pattern: describe a way how to combine objects in order to obtain a new functionality, even during program execution. List of the structural patterns The aspect, which can change 1)Adapter - class and object design pattern 2)Bridge - object design pattern 3)Composite - object design pattern The interface of an object The implementation of the object The structure and the scheme of the object 4) Decorator - object design pattern The obligation of the object without defining its subclass 5) Facade - object design pattern The interface of a subsystem 6) Flyweight - object design pattern The cost of storing objects 7)Proxy -- object design pattern The way of an access to the object; its location

30 Structural patterns Related patterns List of the structural patterns Other structural patterns Behavioral patterns Creational pattens 1)Adapter - class and object design pattern Bridge, Decorator, Proxy 2)Bridge - object design pattern Adapter Abstract Factory, 3)Composite - object design pattern Decorator, Flyweight Chain of Responsibility, Iterator, Visitor 4) Decorator - object design pattern 5) Facade - object design pattern 6) Flyweight - object design pattern 7)Proxy - object design pattern Adapter, Composite, Strategy Abstract Factory Mediator Singleton Composite Adapter, Decorator, State, Strategy

31 Bridge (1) Problem: You should separate the abstract from the implementation, so that they can change independently of one another Solution: The RedefineAbstraction objects have methods that use the methods of the Implementor abstract class (or an interface), which are implemented by specific ConcreteImplementor classes, cooperating with various classes (with different interfaces) from a variety of platforms and libraries. Client: The client uniformly treats each RedefineAbstraction object without committing to a specific platform or a library.

32 Bridge (2)

33 Example

34 Bridge (5)

35 Bridge (2) Result: The separation of abstraction from implementation, eliminating dependencies while compiling a program or activity, Introduction of multitiered architecture Extensibility of class hierarchies of the Abstraction and Implementor Easy addition of new objects Hiding implementation details of the implementation

36 Composite (1) Problem: It combines objects in object-oriented data structures (tree) as a part-whole. Solution: The Component abstract class (or an interface) declares the basic operations for graphical objects. The Composite object contains the two sets of objects: the other Composite objects and the Leaf objects, which do not contain any object. The Leaf objects they implement the Component class. Client: Client object uniformly treats each element of the object structure - as objects of Component type

37 Composite (2)

38 Composite (3)

39 Composite (3) Object diagram of Composite (1)

40 Client Composite (4) Composite Object diagram of Composite (2) Leaf

41 Composite (6) Result: Recursive grouping on primary (Leaf-type) and complex objects (Composite) A simple construction of a client who does not need to distinguish between primary and complex objects One can easily add new facilities The difficulty in maintaining restrictions on the construction of complex objects Implementation: a new class of "Boundry" such as Swing package classes The JComponent class represents the Component class, The JButton class represents the Leaf class and the The JPanel class represents the Composite class.

42 Decorator (1) Problem: Dynamic functionality development of the facility as an alternative to creating a hierarchy of classes. Solution: A Component is an abstract class (or an interface) for visual objects. Its interface defines the operations of drawing and event handling implemented by the class ConcreteComponent. The Decorator abstract class (or an interface) inherits operations from the Component class (or an interface) and defines additional operations performed by the ConcreteDecorator object. Client: The object executes along with objects inherited from the Component class, with decorators and without decorators.

43 Decorator (2)

44 public void draw() { document = new Document(); Footnote footnote = new Footnote(document); PageNumbering page_numbering = new PageNumbering(footnote); page_numbering.draw(); } run: Document Footnote Page Numbering BUILD SUCCESSFUL (total time: 0 seconds)

45 Decorator (4)

46 Decorator (5)

47 Decorator (6) Result: the dynamic and transparent solution to add additional components to the basic components Easy removal of an additional functionality. Replacement of class hierarchy containing the equivalent functionality on a permanent basis, by dynamically adding the decorators with different functionalities Implementation: a new class of "Boundry" such as Swing Package class, a library classes of Java Server Faces components

48 Facade (1) Problem: grant access only to selected functions of the system tier Solution: It is an interface or interfaces of the system tier - facades provide the several methods for selected groups of subsystems Client: only receives the necessary methods Result: Release of important methods only, for example, a tier of the system use cases and hides classes of the system tier. The facade may prevent access to all methods of the encapsulated class.

49 Facade (2) Client 1 Class_A Class_1 Client 1 facade A Class_A Class_1 Client 2 Class_B Class_2 Client 2 Class_B Class_2 Client 3 Class_C Class_3 Client 3 facade B Class_C Class_3 Layer 1 Layer 2 Layer 1 Layer 2

50 Flyweight (1) Problem: A repeated use of the same object - to share objects Solution: The Flyweight interface declares the methods which are implemented by ConcreteFlyweight objects (shared use) and UnsharedConcreteFlyweight object (used once) used by client applications. Flyweight objects are created and managed by the FlyweightFactory object. Client: Clients keep references to flyweight objects

51 Flyweight (2) 1..* 1..*

52 Facade Client Flyweight Client Flyweight

53 Flyweight (4), Facade (4)

54 Flyweight (5)

55 Flyweight (6) Result: Memory savings by sharing facilities, namely the flyweight objects Implementation: a new class of "Boundry" or "Entity", e.g. reference the same object from a family of TProduct1 objects (flyweight) may be stored in many objects such as the TItem (client); Object references of the TPromotion object (flyweight) may be kept by the one of the objects from the family of TProduct1 objects (client)

56 Proxy (1) Problem: The representation of one object to control access to the other one. Solution: A Proxy object stores a reference to the actual object of the RealObject object and may replace the RealObject object The Proxy object may be a remote object, referring to the RealObject object, or provides the virtual access to the object by buffering the RealObject object, or prevents the access to the RealObject object by unauthenticated objects. Client: Any object of any tier of the multitiered systems.

57 Proxy (2)

58 Example Proxy (2)

59 Proxy (4)

60 Result: Proxy (5) The remote Proxy object can hide RealObject objects in any address space Virtual Proxy object improves performance by caching data of the RealObject object and limits unnecessary operations on the RealObject object such as modifications of file records The Proxy object provides the security, because it can authorize or prohibit access to RealObject objects

61 Overview of design patterns for supporting information systems modelling Gamma E., Helm R., Johnson R., Vlissides J., Design PATTERNS: Elements of reusable object-oriented software. 1. Introduction 2. Identification of design patterns 3. Review of design patterns 3.1. Creational patterns 3.2. Structural patterns 3.3. Behavioral patterns

62 Behavioral patterns The main goal: Allocating algorithms and obligations to objects, covering the patterns of objects and classes, and communication between objects The list of behavioral patterns 1)Chain of Responsibility 2)Command 3)Interpreter 4)Iterator 5)Mediator 6)Memento 7)Observer 8)State 9)Strategy 10)Visitor 11)Template Method The aspect, which can change The object, which can achieve a request The condition and the way of realization of a request The grammar and the interpretation of a language The way of the access and walking through elements of an aggregate Why and which objects influence one another? Which and when private informations are stored outside the object The number of objects, which are dependent on other objects and how dependent objects keep the actual state The state of objects The algorithm Operations, which can be applied to objects without changing their classes Steps of the algorithm

63 Behavioral patterns Related patterns The list of behavioral patterns Structural paterns Creational patterns Other behavioral patterns 1)Chain of Responsibility Composite 2)Command Composite, Prototype Memento 3)Interpreter Composite, Flyweight Iterator, Visitor 4)Iterator Composite Factory Method Memento 5)Mediator Facade Observer 6)Memento 7)Observer Singleton Mediator 8)State Flyweight Singleton 9)Strategy Flyweight Command, Iterator 10)Visitor Composite Interpreter 11)Template Method Factory Method Strategy

64 Chain of Responsibility (1) Problem: The pattern creates a chain of receiving objects and passes the request along a chain of objects, until any of objects can handle it. Solution: Handler interface declares a service of demands and possibly the reference to the successor. The ConcreteHandler object responsible for requests, which are detected and supported. Client: generates and directs requests to the list of ConcreteHandler objects Result: The object to be handled and the ConcreteHandler objects haven't explicit knowledge about themself and do not necessarily know the structure of the chain. A chain of commitments increases flexibility in allocating service requests by changing the subclasses of objects and structures of objects chain - but no guarantee of receiving a request. Implementation: Use for the event handlers

65 Chain of Responsibility (2)

66 Chain of Responsibility (2) alt alt

67 Interpreter (1) Problem: A definition of a representation for the grammar of the given language and an interpreter of sentences written in a language-defined by the grammar Solution: The Context object contains global information for the interpreter. The Client object gets the built AbstractSyntax tree representing sentences of the language and calls its interpret method - a tree made up of the TerminalExpression and NonterminalExpression objects, which implement the AbstractExpression interface.

68 Interpreter (2)

69

70 Interpreter (4) Example: TerminalExpression = {-6, -2, 1, 5, x, y}, NonterminalExpression = {S, A, AN, B, N}, and rules of BNF notation: <S> ::= <AN><AN> <AN> ::= <A><N> <B><N> <N> ::= x y <A> ::= 1-2 <B> ::= 5-6 A AN S N B AN N Expression: ((1+x)+(-6+y)) 1 x -6 y

71 Interpreter (5) Client: The Client object builds or gets a syntax tree, and starts the process of interpretation of the sentence represented by a tree Result: Easy modification of the grammar Easy to implement different grammar Difficulties to handle a complex grammar - each class represents at least one production rule Adding new ways of the interpreting the expression by the modifications of the classes.

72 Mediator (1) Problem: The pattern allows you to limit the links between objects that interact in complex ways and allows you to change the way they communicate. Solution: The Mediator declares an interface in the agreement of the Colleague interface, so every ConcreteColleague object knows the operations of the ConcreteMediator object - each ConcreteColleague object need not communicate with another ConcreteColleaque object, but with an ConcreteMediator object; the ConcreteMediator object coordinates cooperation of many ConcreteColleague objects. The ConcreteColleague objects send requests to the ConcreteMediator object, then the ConcreteMediator object sends these requests to the appropriate ConcreteColleague objects.

73 Mediator (2)

74 Mediator (3)

75 Mediator (4) Result: The ConcreteMediator object focuses behaviour that would otherwise be placed in many ConcreteColleague objects You can combine different type of property of objects such the ConcreteClleague and ConcreteMediator Simplification of protocols to communicate through one-to-many associations between the objects such the ConcreteMediator and ConcreteColleague, replacing many of the objects derived from many ConcreteColleague objects. The generalization of the cooperation between objects, which implement the Colleague interface by the Mediator interface The functionality of the objects, which implement the Mediator interface, can lead to very complex implementations, which will be difficult to maintain

76 Observer (1) Problem: Define the one-to-many relationship between objects - when one object changes state, all dependent objects are automatically notified and updated Solution: The ConcreteSubject objects know its observers and hold the state which is interesting for ConcreteObserver objects - when they change their status, notify the observers (Observer interface) by the update method. The ConcreteObserver object has a reference to the ConcreteSubject object and holds the state, which must be consistent with the state of the observed ConcreteSubject object Result: Abstract relationship between objects such as the ConcreteSubject and ConcreteObserver objects Support for sending messages - the ConcreteSubject objects send the notification without knowing the recipient Unexpected upgrade - due to the fact that observers do not know about the existence of other observers

77 Observer (2)

78 Observer (3)

79 State (1) Problem: You can change the behaviour of an object when you change the inner state of this object by forming its derivative object. Solution: The Context object defines an interface for clients and maintains the ConcreteState object. The State interface declares the interface associated with the state of the Context object. The ConcreteState objects represent the complete behaviour associated with the state of the Context object. Client: The object, which configures the ConcreteState objects by using the Context object Result: The location in one object, which implements the State interface, all functionality, and diversification of behaviour which depends on the change of the state in the derived classes. These classses acquire all the functionality. Each derivative object implements a new standalone functionality, which improves the visibility of transitions between states Sharing objects such ConcreteState objects, because their states are represented by their types.

80 State (2) State TCP TCP Connection TCP Accept TCP Close

81 State (3)

82 Strategy (1) Problem: A selection of different business rules or algorithms for different versions depending on the context Solution: It selects a version of the algorithm which separates from its implementation Result: Definition of a family of algorithms Definition of a Strategy interface which contains a method providing algorithms and methods in a Context class which uses these algorithms Elimination of manual selection or a conditional choices of algorithm of the strategy by introducing a mechanism of polymorphism Client: The decision to implement strategies and context of the objects is taken by the owner of these objects

83 Strategy (2)

84 Strategy (2)