System Architecture Lecture 3 CSE 111 Spring 2010

System Architecture Lecture 3 CSE 111 Spring 2010 10/3/2020 Copyright William E. Howden 1

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 10/3/2020 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 10/3/2020 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 10/3/2020 Copyright William E. Howden 4

Peer to Peer 10/3/2020 Copyright William E. Howden 5

Central Server 10/3/2020 Copyright William E. Howden 6

Three-Tier 10/3/2020 Copyright William E. Howden 7

Three-Tier Architecture Nomenclature • View (Presentation Tier) • DL (Business or Domain Logic, Logic Tier) • DB (Data base, Data Tier) 10/3/2020 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 10/3/2020 Copyright William E. Howden 9

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 10/3/2020 Copyright William E. Howden 10

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 11

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 12

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 • add. Observer(Observer obs) • notify. Observers(Object arg) Copyright W. Howden 13

Sample Callback for Dating. System • 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 add. Observer(Observer obs) and notify. Observer. Method() Copyright W. Howden 14

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. add. Observer(this) to register itself as an observer of BL • In the log. On logic in BL: if the special condition is recognized, notify. Observers() is called which causes the registered observers update() methods to be called, which causes the warning to flash Copyright W. Howden 15

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 10/3/2020 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 10/3/2020 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

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 22

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 23

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 24

Implementing Subsystems/Components in Java • Possible units of organization: – Files – Folders – Classes – Packages Copyright W. Howden 25

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 26

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 27

Folders and Subsystems • Associate subsystems with folders • When class file is compiled, compiled class files will go into the same folder Copyright W. Howden 28

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 29

Packages and Subsystems • We will use UML-Java packages for subsystems • Assume package has interface classes for the subsystem Copyright W. Howden 30

Additional Packages • In addition to our GUI, DL and DB subsystem packages, there are several other packages in the DS design – Globals • E. g. Member. Data in DS – Utility routines • E. g. Classes used for tracing and debugging • Will also have a special Start class Copyright W. Howden 31

Dating System Architecture Copyright W. Howden 32

Start Class Logic – creating the subsystems and linking them together Copyright W. Howden 33