1
play

1 Design Pattern Description Design Pattern Observer Name - PDF document

Oct 04, 2023 •435 likes •483 views

OBJECT ARCHITECTURE What Is Architectural Design? DESIGN These slides continue with our example Choices Made In Architectural Design: application, based on the simplified OMT-based Components technique. High-Level Design Patterns

  1. OBJECT ARCHITECTURE What Is Architectural Design? DESIGN • These slides continue with our example Choices Made In Architectural Design: application, based on the simplified OMT-based • Components technique. • High-Level Design Patterns • I am not trying to cover all or not even most • Architectural Styles aspects here. • A Possible Framework Architecture • We will have other examples to show how things • Processes and Hardware can be done differently. • Processes and Communication • Other Architecture-Related Decisions ☺ • -> Some of these issues depend on each other strongly. 4.10.2004 Software Engineering 2004 1 4.10.2004 Software Engineering 2004 2 Jyrki Nummenmaa Jyrki Nummenmaa Input Information For Why Architectural Design? Architecture Design • Managing complexity • Analysis model of the application showing what the system is about and what it should do. – It is easier to manage complexity, if we divide the application into reasonable parts. • Hardware environment • Maintainability • Software environment – Usually a reasonable architecture makes it much easier to - possible database management system maintain the software. - communication technologies – This may actually be the biggest reason for architectural - programming language – if known design. - target operating system(s) – if known • Efficiency – A good architecture enables us to isolate the potential causes for inefficiency and makes it possible to scale up performance when load increases. 4.10.2004 Software Engineering 2004 3 4.10.2004 Software Engineering 2004 4 Jyrki Nummenmaa Jyrki Nummenmaa Architectural Design For Design Patterns Example Game Application • Clearly, it seems reasonable to separate the game • Our design could follow the principles of MVC (or logic from the user interface. MVC++) directly. • If done suitably, this will also enable multiple • Another possibility is to copy an existing design client applications with a view to the same game. idea and modify it to our needs. • This kind of an approach is actually quite usual. • The idea of copying designs like this is the basic idea behind design patterns . • In fact, so usual, that there is a well-known architectural solution for this kind of setting, called • It has been difficult to reuse code. The idea of Model-View-Controller architecture (MVC design patterns is to reuse ideas. architecture). • In a way, applying the MVC model is reusing the • We will study a variant of MVC from a separate set idea. However, there have been efforts to give a of slides by Ari Jaaksi, Nokia. fixed format for presenting design patterns. 4.10.2004 Software Engineering 2004 5 4.10.2004 Software Engineering 2004 6 Jyrki Nummenmaa Jyrki Nummenmaa 1

  2. Design Pattern Description Design Pattern ”Observer” • Name • Problem: We want to keep a number of objects (observers) aware of the state of an object • Problem (subject) • Solution • This is done by making the observers subscribe to – Static: E.g. Class Diagram the subject. – Dynamic: E.g. Sequence Diagram • Whenever the subjects state changes, it will • Strategy publish information about that to all subscribed – How to implement the pattern observers. • Consequences – Results and trade-offs 4.10.2004 Software Engineering 2004 7 4.10.2004 Software Engineering 2004 8 Jyrki Nummenmaa Jyrki Nummenmaa Class Diagram for Observer A Sequence Diagram For Design Pattern Observer Design Pattern :ConcreteSubject t1:ConcreteObserver t2:ConcereteObserver observes Object Subject attach(t1) {abstract} * {abstract} attach(t2) update() {abstract} attach(x:Observer) Changes State detach(x: Observer) notify() notify() for all g in observes { registers update() g.update() update() } ConcereteObserver ConcreteSubject update() 4.10.2004 Software Engineering 2004 9 4.10.2004 Software Engineering 2004 10 Jyrki Nummenmaa Jyrki Nummenmaa Applying The Observer Design Some observations Pattern • A subject and the respective observers need minimal information on each other. observes Object • In fact, they need to implement the required Subject {abstract} * {abstract} operations (attach, detach, notify, update), but update() {abstract} that’s about that. attach(x:Observer) detach(x: Observer) • This way, we get a high level of independence in notify() their implementations. for all g in observes { registers g.update() } GameGUI GameModel update() Controller? 4.10.2004 Software Engineering 2004 11 4.10.2004 Software Engineering 2004 12 Jyrki Nummenmaa Jyrki Nummenmaa 2

  3. Applying The Observer Pattern Components - What? • Apparently, we can use the Observer pattern for • Component technologies can be seen as packaging the user interface to observe the state of the technologies game. • Independent • Q: How is this different from using the MVC • Can be used as a building block to build larger model? systems – dynamic, ”plug & play” linking A: This model does not include the control part, ie. • Have a well-defined interface, which hides the it is more appropriate for situations, where implementation completely observing is enough. This way, MVC seems more • Can be treated as a product of its own appropriate for our game example. • Can be installed separately • -> Back to the drawing board. The MVC looked • Can be implemented with any language, as long as better. However, we will look at yet another it implements the necessary interfaces possibility: components. 4.10.2004 Software Engineering 2004 13 4.10.2004 Software Engineering 2004 14 Jyrki Nummenmaa Jyrki Nummenmaa Components - Why? Component Diagram • Object-oriented source-level re-use of code implements requires same source code language. uses • Object-oriented source-level re-use may require understanding of the implementation. • Building the system from source-level pieces Interface – this may also be ComponentZ represented with stereotype requires that these pieces compile happily with <<interface>> for a class. each other. InterfaceX • We want to avoid the above problems and build binary components with well-defined interfaces. ComponentY component 4.10.2004 Software Engineering 2004 15 4.10.2004 Software Engineering 2004 16 Jyrki Nummenmaa Jyrki Nummenmaa Component - Interfaces Component Technologies • An interfaces defines a set of services, which • Microsoft COM & DCOM (distributed COM) semantically belong together. • CORBA standard • An interface is a contract between the user and – several vendors the implementor. – heavyweight system • A componenent may implement many interfaces • Java Beans and an interface may be implemented by many components. • Once an interface is released, it does not change. • If changes are necessary, a new interface is released. • As a matter of fact, you should know all this. 4.10.2004 Software Engineering 2004 17 4.10.2004 Software Engineering 2004 18 Jyrki Nummenmaa Jyrki Nummenmaa 3

  4. Component Diagram For The Sequence Diagram for ”Take Game Application Card” at Component Level GameModel GameView GameController GameGUI User Choose to take card Take card Pay (1) Updated funds Show funds Show funds Game Controller Turn Card GameControllerInterface Card Value Show card value Show card value Add Funds (Value) GameModel Show funds Updated funds Show funds GameModelInterface 4.10.2004 Software Engineering 2004 19 4.10.2004 Software Engineering 2004 20 Jyrki Nummenmaa Jyrki Nummenmaa Deployment Diagram Processing resource (a device, not a device type) : GameClient : GameServer : GUI : GameModel <<TCP/IP>> : GameController Object – ok, this was a component Component instance in an earlier slide, this is just for example 4.10.2004 Software Engineering 2004 21 Jyrki Nummenmaa 4

Recommend

More recommend