CMPT 370: Information Systems Design

Instructor: Curtis Cartmill, Simon Fraser University – Summer 2003

Lecture Topic: Layered Architecture

Class Exercise: Modeling Views

22

ObjectivesObjectives

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

A typical system many have several more components• User Interface

• Database access

• Common services– Authentication, security, input/output, communications etc.Authentication, security, input/output, communications etc.

These components together what is called the logical architecture

33

Software ArchitectureSoftware Architecture

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

44

Performing architecturePerforming architecture

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

Architectural design• Is the resolution of architectural investigation

forces into the design of the software, hardware and networking operations and policies

55

Logical ArchitectureLogical Architecture 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

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

66

Common Layers in a Logical ArchitectureCommon Layers in a Logical Architecture

Presentation Layer

Application Layer

Domain Layer

Business Infrastructure Layer

Technical Services Layer

Technical Foundation Layer

Dependencies

Application

specific

Class focus so far

77

UML - Package DiagramUML - Package DiagramA 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

Technical Services

Domain

Application

Presentation

POS Application

Sales Inventory

Persistence Security

Web Interface Register Interface

88

PackagesPackages 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 What are the true subsystems

– How are they connectedHow 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 alreadyWe have looked at Observer already

99

Façade PatternFaçade Pattern 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.

Facade

+ calculatePrice ( ) : void+ calculateTax ( ) : void+ Facade ( )+ registerSubsystem ( [in] subsystem : java.lang.Object ) : void

SubsystemInterface

+ calculatePrice ( ) : void+ calculateTax ( ) : void+ SubsystemInterface ( )

- theSubsystemInterface1

1010

Mediator PatternMediator Pattern 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.

ConcreteMediator

+ ConcreteMediator ( )+ setConcreteColleague ( [in] colleague : ConcreteColleague ) : void

ConcreteColleague

+ ConcreteColleague ( [in] mediator : Mediator )

Colleague«JavaInterface»

Mediator

- theConcreteColleague

0..1

# mediator

0..1

1111

Model, View, ControllerModel, View, Controller 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

1212

MVC Pattern MVC Pattern 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.

1313

MVC ControllerMVC Controller 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.

1414

MVC ControllerMVC Controller 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.

1515

MVC Controller in ActionMVC Controller in Action 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.

1616

Multiple Client TypesMultiple Client Types Applications with a single client type can

implement a single controller. Additional controllers can support new client

types

1717

Templating ServiceTemplating Service 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.

1818

Separating Business Logic from PresentationSeparating Business Logic from Presentation 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.

1919

Business BenefitsBusiness Benefits Separating business logic from presentation has

several important benefits:• Provides client independence and code reuse

– Intermingling data presentation and business logic ties the Intermingling data presentation and business logic ties the business logic to a particular type of client. Business logic business logic to a particular type of client. Business logic that is available referentially as simple method calls on that is available referentially as simple method calls on business objects can be used by multiple client types.business objects can be used by multiple client types.

• Separates developer roles– Code that deals with data presentation, request processing, Code that deals with data presentation, request processing,

and business rules all at once is difficult to read, especially and business rules all at once is difficult to read, especially for a developer who may specialize in only one of these for a developer who may specialize in only one of these areas. Separating business logic and presentation allows areas. Separating business logic and presentation allows developers to concentrate on their area of expertise. developers to concentrate on their area of expertise.

2020

Business Benefits Business Benefits Separating business logic from presentation has

several important benefits:• Minimizes impact of change

– Business rules can be changed in their own layer, with little Business rules can be changed in their own layer, with little or no modification to the presentation layer. Application or no modification to the presentation layer. Application presentation or workflow can change without affecting code presentation or workflow can change without affecting code in the business layer. in the business layer.

• Increases maintainability– Most business logic occurs in more than one use case of a Most business logic occurs in more than one use case of a

particular application. Business logic copied and pasted particular application. Business logic copied and pasted between components expresses the same business rule in between components expresses the same business rule in two places in the application. Future changes to the rule two places in the application. Future changes to the rule require two edits instead of one. Business logic expressed in require two edits instead of one. Business logic expressed in a separate component and accessed referentially can be a separate component and accessed referentially can be modified in one place in the source code, producing behavior modified in one place in the source code, producing behavior changes everywhere the component is used. changes everywhere the component is used.

2121

View ModelingView Modeling 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.

2222

View ModelingView Modeling 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. 

2323

Modeling ViewsModeling Views Views can be modeled as objects themselves. 

• This allows the same systematic object definition, using the same techniques and notation. 

Modeling views as objects also matches the object-oriented 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. 

2424

Modeling ViewsModeling Views Use Case – View Courses

Class

- room- numberOfStudents- instructor

+ register ( )

Course

- name

Course Calendar

- startDate- endDate

+ scheduleClass ( )

Credit

Registration

+ calculateRemainingCreditsForGraduation ( )

Student

- studentID- name

Timetable

- startTime- endTime- startDate- endDate

*

*

*

1

*

*

*

1

1

2525

Modeling ViewsModeling Views

Class

- room- numberOfStudents- instructor

+ register ( )

Course

- name

Course Calendar

- startDate- endDate

+ scheduleClass ( )

Credit

Registration

+ calculateRemainingCreditsForGraduation ( )

Student

- studentID- name

Timetable

- startTime- endTime- startDate- endDate

*

*

*

1

*

*

*

1

1

CourseCalendarView

1

Use Case – View Courses

2626

CourseCalendarViewCourseCalendarViewThe view object is connected to the associations

between the viewed object and other objects.

CourseCalendarView

+ viewStartDate ( )+ viewEndDate ( )+ viewCourses ( )+ viewClasses ( )+ viewTimetable ( )

2727

Use Case – Register for ClassUse Case – Register for Class 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 Scenario1. Student searches for a course scheduled in upcoming semester2. System displays the course with a list of scheduled classes meeting search criteria3. Student selects a class that they wish to register for4. System checks student eligibility to register for the selected class (meets pre-requisites and co-requisites)5. System checks that selected class has availability (the class is not full) for student to register in6. System registers student in the class7. System displays confirmation of registration

2828

Class ExerciseClass Exercise Take the use case and update the class

diagram with views