Download presentation
Presentation is loading. Please wait.
1
System Architecture Lecture 3 CSE 111 Spring 2010 6/22/20151Copyright William E. Howden
2
System Architecture Identifies the basic parts of the system and their relationships – called: components, modules, subsystems Component interactions – called: send a message to, use Relationships – corresponds to: message being sent, data flow 6/22/2015Copyright William E. Howden2
3
Component Interfaces When a component is used a method is called in its interface class(es) Interface class may be a facade in the sense that it contains no or little logic Interface class(es) use other classes in the component to perform required action. Those classes may call on methods in the interfaces of other components 6/22/2015Copyright William E. Howden3
4
System Architecture Patterns/Metaphors General patterns that have found to be useful Sample architectures – Peer to peer – Central Server – Three-tier, based on model view separation and layers – Model View Controller 6/22/2015Copyright William E. Howden4
5
Peer to Peer 6/22/20155Copyright William E. Howden
6
Central Server 6/22/20156Copyright William E. Howden
7
Three-Tier 6/22/20157Copyright William E. Howden
8
Three-Tier Architecture Nomenclature View (Presentation Tier) DL (Business or Domain Logic, Logic Tier) DB (Data base, Data Tier) 6/22/2015Copyright William E. Howden8
9
General Design Patterns Used as Part of the Three-Tier Pattern Model-View Separation – View: GUI/Interface – Model: Business Logic/Domain Logic – Separation GUI classes in a separate component from Model GUI event handlers (Java Listeners) – are called when an event such as a button push occurs – they call methods in the Model to perform actions such as get date » may retreive information from model or change its state – shut down and open new screens/dialogs Why? – Management of intellectual complexity – Facilitates testing and changes. Can swap in a new GUI without changing model 6/22/20159Copyright William E. Howden
10
Three-Tier Design Patterns (cont) Layers design Each layer – is a kind of abstract machine defined using the layers below it – a layer can call on the layers below it but not the ones above it – originated in the THE operating system (Dijkstra) Why? – Facilitate management of intellectual complexity – Facilitates changes 6/22/201510Copyright William E. Howden
11
Copyright W. Howden11 Three-Tier Design Patterns (cont.) Callbacks – View call on model to get information to display – How does lower level Model component alert View that something needs displaying? – View calls a model method with an identifier for a method to be called when the condition of interest happens. Passed method is called a call back function. View is registering itself for the occurrence of a certain event. – Similar object oriented approaches using call back objects
12
Copyright W. Howden12 Callbacks in Java – Observer/Observable -1 Observer-observable is a callback pattern Java Classes with same names can be used to implement it Observers – register with observable, assumed to have an update() method Observable – when instructed, will call the observers’ update() method
13
Copyright W. Howden13 Observer/Observable -2 Observer is an interface – Class who wants to be called back by a lower layer class should implement it – requires an update(Observable obs, Object arg) Observable is a class – Class that will cause the call back to occur should subclass it – Includes methods and data structures used for implementing call backs addObserver(Observer obs) notifyObservers(Object arg)
14
Copyright W. Howden14 Sample Callback for DatingSystem Requirement: want domain/business logic layer of system to flash a warning on the screen if logged on member is a frequent dater, and then continue normally with logic for logging on Suppose we had a simple GUI interface class and a simple BL (business logic) Model class Use of observer/observable – GUI implements Observer => must implement an update() method. Have this method flash the warning when it is called – BL extends Observable, giving it an addObserver(Observer obs) and notifyObserverMethod()
15
Copyright W. Howden15 Use of the Callback Assume at start up the constructor for GUI is passed a reference to an instance of the BL GUI constructor calls BL.addObserver(this) to register itself as an observer of BL In the logOn logic in BL: if the special condition is recognized, notifyObservers() is called which causes the registered observers update() methods to be called, which causes the warning to flash
16
Caveat DS call back example here is contrived - created to illustrate a point Assume when logon occurs in GUI it calls a logon(m) method BL interface (class) logon() could be written to return warning value if member m is a frequent dater. GUI method that called logon() in the BL can display the warning directly, without the need for callbacks 6/22/2015Copyright William E. Howden16
17
Passive and Active Models and Callbacks A passive Model is updated by the actions of the by the View (or the Controller in MVC (see below)) – The View may call the model to acquire information – No need for callbacks to allow Model to initiate changes to state of View An active Model can be updated by external events not originating from the View (or the Controller in MVC) – View may need to be updated: this is where callbacks are really necessary 6/22/2015Copyright William E. Howden17
18
Model View Controller View similar to MV – Controller: handles all input events from user sends messages to Model that View would have sent in the MV updates View logic/state, when the update does not depend on Model state changes (e.g. causes next screen to be displayed) – View can still be registered with Model (for callbacks) Controller could also be registered
19
Model View with Callback
20
Model View Controller with Callback
21
Arguments for and against MVC (as opposed to simple MV) For – Controller delinks the view from the model separates the view logic from the view separates the model management from the view – Argument is that you could reuse the view with another model but would still have to change the controller Against Controller is an anachronism from the days when controllers had to perform complex view construction tasks, before complex graphical windowing was included in the OS
22
Copyright W. Howden22 UML and Components Components – Pieces of the system architecture – Layers, modules, logical tiers – May be nested subcomponents UML packages – Collections of classes and packages, using a special notation (example given later) – May be used for modeling components
23
Copyright W. Howden23 Subsystems Sometimes used synonymously with module or component, but sometimes more formally as: – “Package plus one or more interfaces that define the services supported by the subsystem” Subsystem interface class is not the same thing as Java Interface. Is simply the class through which the capabilities of the subsystem are used Name of a subsystem interface class may be the same as the name of the subsystem because it “stands for it”. E.g. in DS we have the DL (domain logic = business logic) interface class for the DL middle level component of the three-tier design
24
Copyright W. Howden24 Subsystems, Facades and Proxies Façade defintion – an interface object that is the single point of entry for the services of a subsystem - a common unified interface for a disparate set of implementations or interfaces Subsystem interface can be a façade which calls methods in an implemented subsystem Could also be a proxy which simulates a subsystem or which communicates with a remote implementation These patterns (façade and proxy) will be discussed later
25
Copyright W. Howden25 Implementing Subsystems/Components in Java Possible units of organization: – Files – Folders – Classes – Packages
26
Copyright W. Howden26 Files and Subsystems Files: units of compilation Compilation produces class files for each class in a file Too small a unit for organizing subsystems Class in one file has limited visibility (i.e ability to create an instance of) to classes in other files.
27
Copyright W. Howden27 Inner Classes and Subsystems Inner Class – Defined inside another class – Has access to variables of enclosing class Subsystems consist of a principal class (e.g. subsystem interface), and its inner classes Problems e.g. – Cannot have static members in inner classes – Cannot access inner classes from the outside
28
Copyright W. Howden28 Folders and Subsystems Associate subsystems with folders When class file is compiled, compiled class files will go into the same folder
29
Copyright W. Howden29 Packages Java Package is a collection of classes Package is associated with a folder Can use import statement in a file to identify a source of classes used in file Use package statement to identify a file as belonging to a package Use import to identify sources of referenced classes
30
Copyright W. Howden30 Packages and Subsystems We will use UML-Java packages for subsystems Assume package has interface classes for the subsystem
31
Copyright W. Howden31 Additional Packages In addition to our GUI, DL and DB subsystem packages, there are several other packages in the DS design – Globals E.g. MemberData in DS – Utility routines E.g. Classes used for tracing and debugging Will also have a special Start class
32
Copyright W. Howden32 Dating System Architecture
33
Copyright W. Howden33 Start Class Logic – creating the subsystems and linking them together
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.