System Architecture Lecture 3 CSE 111 Spring 2010 6/22/20151Copyright William E. Howden.
-
date post
20-Dec-2015 -
Category
Documents
-
view
212 -
download
0
Transcript of System Architecture Lecture 3 CSE 111 Spring 2010 6/22/20151Copyright William E. Howden.
System Architecture
Lecture 3CSE 111 Spring 2010
04/18/23 1Copyright William E. Howden
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
04/18/23 Copyright William E. Howden 2
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
04/18/23 Copyright William E. Howden 3
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
04/18/23 Copyright William E. Howden 4
Peer to Peer
04/18/23 5Copyright William E. Howden
Central Server
04/18/23 6Copyright William E. Howden
Three-Tier
04/18/23 7Copyright William E. Howden
Three-Tier Architecture Nomenclature
• View (Presentation Tier)• DL (Business or Domain Logic, Logic Tier) • DB (Data base, Data Tier)
04/18/23 Copyright William E. Howden 8
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
04/18/23 9Copyright William E. Howden
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
04/18/23 10Copyright William E. Howden
Copyright W. Howden 11
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
Copyright W. Howden 12
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
Copyright W. Howden 13
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)
Copyright W. Howden 14
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()
Copyright W. Howden 15
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
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
04/18/23 Copyright William E. Howden 16
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
04/18/23 Copyright William E. Howden 17
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
Model View with Callback
Model View Controller with Callback
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
Copyright W. Howden 22
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
Copyright W. Howden 23
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
Copyright W. Howden 24
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
Copyright W. Howden 25
Implementing Subsystems/Components in Java
• Possible units of organization: – Files– Folders– Classes– Packages
Copyright W. Howden 26
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.
Copyright W. Howden 27
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
Copyright W. Howden 28
Folders and Subsystems
• Associate subsystems with folders• When class file is compiled, compiled class
files will go into the same folder
Copyright W. Howden 29
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
Copyright W. Howden 30
Packages and Subsystems
• We will use UML-Java packages for subsystems
• Assume package has interface classes for the subsystem
Copyright W. Howden 31
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
Copyright W. Howden 32
Dating System Architecture
«subsystem»Business Logic
«subsystem»GUI
«subsystem»DataBase
StartGobals Utilities
Dating System
Copyright W. Howden 33
Start Class Logic – creating the subsystems and linking them together
start : Start
dB : DataBase
dL : DomainLogic
gUI : GUI
cre
ate
(dB
)