CMPT 370 Information Systems Design Lecture Topic Layered

CMPT 370: Information Systems Design Lecture Topic: Layered Architecture Class Exercise: Modeling Views Instructor: Curtis Cartmill, Simon Fraser University – Summer 2003 (c) Addison Wesley Chapter 1

Objectives n To date we have been focused on the modeling of business aspects of a software application. • A focus on domain objects and classes • A focus on gaining core design skills n A typical system many have several more components • User Interface • Database access • Common services – Authentication, security, input/output, communications etc. n These components together what is called the logical architecture 2

Software Architecture n An architecture is a set of significant decisions about the organization of a software system: • The selection of the structural elements and their interfaces by which the system is composed, together with their behaviour as specified in the collaborations among those elements, • The composition of these structural and behavioural elements into progressively larger subsystems and the architectural style that guides this organization (these elements, their interfaces, their collaboration and their composition 3

Performing architecture n Architectural investigation • Involves identifying those functional and (especially) non-functional requirements that have a significant impact on system design, such as market trends, performance, cost, maintenance, and points of evolution n Architectural design • Is the resolution of architectural investigation forces into the design of the software, hardware and networking operations and policies 4

Logical Architecture n The best known practices around architecture are to organize the structure of a system into discrete layers of distinct related responsibilities • A desire to have a clean cohesive separation of concerns such that the lower layers of the architecture are low level and general and the higher layers more application specific n A layered architecture defines a n-tiered model. It avoids the problems of • • Source code changes rippling through the system Application logic intertwined with user interface General services intertwined with application specific logic Difficulty in evolving functionality, scaling up the solution or update with new technologies due to high coupling 5

Common Layers in a Logical Architecture Class focus so far Dependencies Presentation Layer Application Layer Domain Layer Application specific Business Infrastructure Layer Technical Services Layer Technical Foundation Layer 6

UML - Package Diagram A package diagram shows the packages comprising the logical architecture and the dependencies between them note that the dependencies are all pointing to a package in the same or lower layer 7

Packages n Packages or layers are not just conceptual groups of things but true subsystems with behaviours and interfaces: • Two things to decide at an architectural level are – What are the true subsystems – How are they connected • We can use Design Patterns such as Façade, Mediator and Observer to design connections between layers and packages – We have looked at Observer already 8

Façade Pattern n Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. • Clients communicate with the subsystem by sending requests to Facade, which forwards them to the appropriate subsystem(s) objects. Although the subsystem objects perform actual work, the facade may have to do work of its own to translate its interface to subsystem interfaces. Clients that use the facade don't have to access its subsystem objects directly. 9

Mediator Pattern n Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. 10

Model, View, Controller n We can combine the Façade pattern and the Mediator pattern to form an architectural pattern called Model, View, Controller (MVC) • Model is our model as we have designed over the past several weeks, the application layer • View is the presentation layer for our model (think of the façade pattern) • Controller is the communication between the two layers (think of the mediator pattern 11

MVC Pattern n The MVC pattern provides a host of architectural design benefits. • MVC separates design concerns (data persistence and behavior, presentation, and control), decreasing code duplication, centralizing control, and making the application more easily modifiable. • MVC also helps developers with different skill sets to focus on their core skills and collaborate through clearly defined interfaces. 12

MVC Controller n At the highest level, the controller does four basic things in a specific order: • interprets client requests, • dispatches those requests to business logic, • selects the next view for display, and • generates and delivers the next view. 13

MVC Controller n A controller must be maintainable and extensible. • Its tasks include mapping requests to application model operations, selecting and assembling views, and managing screen flow. • Views do not refer to each other directly • The controller controls screen flow by selecting the next view a user sees. • Application model operations have no knowledge of presentation • Good structure can minimize code complexity. 14

MVC Controller in Action n The controller in the application uses two components to select and generate views: a (screen) flow manager, which selects the next view to display; and a templating service, which actually generates the view content. The controller uses the flow manager to select a view, and forwards the request to the templating service, which assembles and delivers a view to the client. Both the screen flow manager and the templating service are generic components that are usable in any application. The component-based design reduces component coupling, promoting code reuse and simplifying the controller design. 15

Multiple Client Types n n Applications with a single client type can implement a single controller. Additional controllers can support new client types 16

Templating Service n n One typical application requirement is that application views have a common layout. A template is a presentation component that composes separate subviews into a page with a specific layout. Each subview is a separate component. Views that share a template have the same layout, because the template controls the layout. The example shows the layout of a single page created by a template. Across the top of the page is a banner, on the left is a navigation menu, a footer appears at the bottom, and the body content occupies the remaining space. 17

Separating Business Logic from Presentation n Placing business logic and presentation code in separate software layers is good design practice. The business layer provides only application functionality, with no reference to presentation. The presentation layer presents the data and input prompts to the user (or to another system), delegating application functionality to the business layer. 18

Business Benefits n Separating business logic from presentation has several important benefits: • Provides client independence and code reuse – Intermingling data presentation and business logic ties the business logic to a particular type of client. Business logic that is available referentially as simple method calls on business objects can be used by multiple client types. • Separates developer roles – Code that deals with data presentation, request processing, and business rules all at once is difficult to read, especially for a developer who may specialize in only one of these areas. Separating business logic and presentation allows developers to concentrate on their area of expertise. 19

Business Benefits n Separating business logic from presentation has several important benefits: • Minimizes impact of change – Business rules can be changed in their own layer, with little or no modification to the presentation layer. Application presentation or workflow can change without affecting code in the business layer. • Increases maintainability – Most business logic occurs in more than one use case of a particular application. Business logic copied and pasted between components expresses the same business rule in two places in the application. Future changes to the rule require two edits instead of one. Business logic expressed in a separate component and accessed referentially can be modified in one place in the source code, producing behavior changes everywhere the component is used. 20

View Modeling n n Once objects have been identified, the next step is to determine what views are necessary for each object. A view can be considered a representation of an object in the user interface. In order for the user to employ an object in a use case they must be able to see it in one or more views. So, once an initial set of objects has been extracted from the use cases the attention switches to the views of those objects. 21

View Modeling n n Starting with the most frequent task, a view is created for each object used in that task. Each view is represented as an object on the object diagram. • The view object is connected to the associations between the viewed object and other objects. 22

Modeling Views n Views can be modeled as objects themselves. • This allows the same systematic object definition, using the same techniques and notation. n Modeling views as objects also matches the objectoriented programming implementation. • By modeling views through class relationship and state diagrams, this part of the design methodology may be, for the time being, isolated from any specific visual or graphic design concerns. • This helps ensure the accuracy and completeness of the view definition, and also helps clarify the requirements for visual design. 23

Modeling Views n Use Case – View Courses 24

Modeling Views Use Case – View Courses 25

Course. Calendar. View The view object is connected to the associations between the viewed object and other objects. 26

Use Case – Register for Class n n n 1. 2. 3. 4. 5. 6. 7. Register for Class Description: This Use Case allows a student to register for a class Actor: Student Pre-Condition: Student is known Post-Condition: Student is registered for selected Class Main Scenario Student searches for a course scheduled in upcoming semester System displays the course with a list of scheduled classes meeting search criteria Student selects a class that they wish to register for System checks student eligibility to register for the selected class (meets pre-requisites and co-requisites) System checks that selected class has availability (the class is not full) for student to register in System registers student in the class System displays confirmation of registration 27

Class Exercise n Take the use case and update the class diagram with views 28