CS 290C: Formal Models for Web Software Lecture 9: MVC Architecture and Navigation Analysis Based on the MVC Architecture Instructor: Tevfik Bultan.

Slides:



Advertisements
Similar presentations
Design Patterns.
Advertisements

A component- and message-based architectural style for GUI software
 Recent researches show that predicative programming can be used to specify OO concepts including classes, objects, interfaces, methods, single and multiple.
Observer Method 1. References Gamma Erich, Helm Richard, “Design Patterns: Elements of Reusable Object- Oriented Software” 2.
Chapter 7 – Object-Oriented Design
Design Patterns in Web Programming Nathan Wallace March 2000 Introduction About Me Why listen to me? What am I talking about? Disclaimer Design Patterns.
CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.1 Software Engineering: Analysis and Design - CSE3308 Patterns CSE3308/CSC3080/DMS/2000/12.
OOP Design Patterns Chapters Design Patterns The main idea behind design patterns is to extract the high level interactions between objects and.
2 Object-Oriented Analysis and Design with the Unified Process Objectives  Explain how statecharts can be used to describe system behaviors  Use statecharts.
Introduction To System Analysis and Design
CSE Software Engineering: Analysis and Design, 2005Lecture 8A.1 Software Engineering: Analysis and Design - CSE3308 Design and Analysis Patterns.
Observer Pattern Fall 2005 OOPD John Anthony. What is a Pattern? “Each pattern describes a problem which occurs over and over again in our environment,
CS 290C: Formal Models for Web Software Lecture 10: Language Based Modeling and Analysis of Navigation Errors Instructor: Tevfik Bultan.
CSE Software Engineering: Analysis and Design, 2002Lecture 7B.1 Software Engineering: Analysis and Design - CSE3308 Patterns CSE3308/DMS/2002/15.
BehavioralCmpE196G1 Behavioral Patterns Chain of Responsibility (requests through a chain of candidates) Command (encapsulates a request) Interpreter (grammar.
James Tam Introduction To Design Patterns You will learn about design techniques that have been successfully applied to different scenarios.
Copyright © Active Frameworks Inc. - All Rights Reserved.More On Behavioral Patterns - Page L9-1 PS95&96-MEF-L16-1 Dr. M.E. Fayad Creationa l.
Satzinger, Jackson, and Burd Object-Orieneted Analysis & Design
CS 290C: Formal Models for Web Software Lecture 1: Introduction Instructor: Tevfik Bultan.
Software Engineering I Object-Oriented Design Software Design Refinement Using Design Patterns Instructor: Dr. Hany H. Ammar Dept. of Computer Science.
CS 290C: Formal Models for Web Software Lecture 6: Model Driven Development for Web Software with WebML Instructor: Tevfik Bultan.
ECE 355 Design Patterns Tutorial Part 2 (based on slides by Ali Razavi) Presented by Igor Ivković
PRESENTED BY SANGEETA MEHTA EECS810 UNIVERSITY OF KANSAS OCTOBER 2008 Design Patterns.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
The chapter will address the following questions:
UNIT-V The MVC architecture and Struts Framework.
Design Patterns Discussion of pages: xi-11 Sections: Preface, Forward, Chapter
Behavioral Patterns  Behavioral patterns are patterns whose purpose is to facilitate the work of algorithmic calculations and communication between classes.
MVC pattern and implementation in java
Design Patterns.
MVC and MVP. References enter.html enter.html
Software Design Refinement Using Design Patterns Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
Introduction To System Analysis and Design
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 27. Review UML dynamic view – State Diagrams.
Observer Behavioral Pattern. Intent Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified.
James Tam Introduction To Design Patterns You will learn about design techniques that have been successfully applied to different scenarios.
SE: CHAPTER 7 Writing The Program
Design Principle & Patterns by A.Surasit Samaisut Copyrights : All Rights Reserved.
ECE450S – Software Engineering II
Proxy, Observer, Symbolic Links Rebecca Chernoff.
Behavioural Design Patterns Quote du jour: ECE450S – Software Engineering II I have not failed. I've just found 10,000 ways that won't work. - Thomas Edison.
Copyright © Active Frameworks Inc. - All Rights Reserved - V2.0Design Pattern Catalog - Page L3-1 PS95&96-MEF-L10-1 Dr. M.E. Fayad Creationa.
Design Pattern. Definition: A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
12 Chapter 12: Advanced Topics in Object-Oriented Design Systems Analysis and Design in a Changing World, 3 rd Edition.
Manali Joshi1 The Observer Design Pattern Presented By: Manali Joshi.
Behavioral Patterns1 Nour El Kadri SEG 3202 Software Design and Architecture Notes based on U of T Design Patterns class.
Concordia University Department of Computer Science and Software Engineering Click to edit Master title style ADVANCED PROGRAMMING PRACTICES Model View.
1 CSE 331 Model/View Separation and Observer Pattern slides created by Marty Stepp based on materials by M. Ernst, S. Reges, D. Notkin, R. Mercer, Wikipedia.
The Observer Pattern (Behavioral) ©SoftMoore ConsultingSlide 1.
1 Good Object-Oriented Design Dr. Radu Marinescu Lecture 4 Introduction to Design Patterns.
The Observer Design Pattern Author :Erich Gamma, et al. Source :Elements of Reusable Object-Oriented Software Speaker : Chiao-Ping Chang Advisor : Ku-Yaw.
High degree of user interaction Interactive Systems: Model View Controller Presentation-abstraction-control.
February 23, 2009Observer Pattern, OOA&D, Rubal Gupta, CSPP, Winter ‘09 Observer Pattern Defines a “one-to-many” dependency between objects so that when.
Presented by Alexey Vedishchev Developing Web-applications with Grails framework American University of Nigeria, 2016 Intro To MVC Architecture.
Design Patterns CSCE 315 – Programming Studio Spring 2013.
Design Patterns: MORE Examples
Software Design Refinement Using Design Patterns
Observer Design Pattern
Instructor: Dr. Hany H. Ammar
Presented by Igor Ivković
Design Patterns - A few examples
Web Programming Language
Patterns.
Observer Pattern 1.
Advanced ProgramMING Practices
Advanced ProgramMING Practices
Presented by Igor Ivković
Presentation transcript:

CS 290C: Formal Models for Web Software Lecture 9: MVC Architecture and Navigation Analysis Based on the MVC Architecture Instructor: Tevfik Bultan

Model-View-Controller (MVC) Architecture MVC is a design structure for separating representation from presentation using a subscribe/notify protocol The basic idea is to separate –where and how data (or more generally some state) is stored, i.e., the model – from how it is presented, i.e., the views Follows basic software engineering principles: –Separation of concerns –Abstraction

Model-View-Controller (MVC) Architecture MVC consists of three kinds of objects –Model is the application object –View is its screen presentation –Controller defines the way the user interface reacts to user input a=50% b=30% c=20% model views

Model-View-Controller (MVC) Architecture MVC decouples views and models by establishing a subscribe/notify protocol between them –whenever model changes it notifies the views that depend on it –in response each view gets an opportunity to update itself This architecture allows you to attach multiple views to a model –it is possible to create new views for a model without rewriting it

Model-View-Controller (MVC) Architecture Taken at face value this may be seen as an architecture for user interface design –It is actually addresses a more general problem: decoupling objects so that changes to one can affect any number of others without requiring the changed object to know the details of the others –This is called Observer pattern in the design patterns catalog Observer pattern is a design pattern that is used as part of the Model-View-Controller (MVC) architecture to handle notification of multiple views that depend on a single model

A Brief Overview of Design Patterns Think about the common data structures you learned –Trees, Stacks, Queues, etc. These data structures provide a set of tools on how to organize data Probably you implement them slightly differently in different projects

A Brief Overview of Design Patterns Main concepts about these data structures, such as –how to store them –manipulation algorithms are well understood You can easily communicate these data structures to another software developer by just stating their name Knowing them helps you when you are dealing with data organization in your software projects –Better than re-inventing the wheel

A Brief Overview of Design Patterns This is the question: –Are there common ideas in architectural design of software that we can learn (and give a name to) so that We can communicate them to other software developers We can use them in architectural design in a lot of different contexts (rather than re-inventing the wheel) The answer is yes according to E. Gamma, R. Helm, R. Johnson, J. Vlissides –They developed a catalog of design patterns that are common in object oriented software design

A Brief Overview of Design Patterns Design patterns provide a mechanism for expressing common design structures Design patterns identify, name and abstract common themes in software design Design patterns can be considered micro architectures that contribute to overall system architecture Design patterns are helpful –In developing a design –In communicating the design –In understanding a design

A Brief Overview of Design Patterns The origins of design patterns are in architecture (not in software architecture) Christopher Alexander, a professor of architecture at UC Berkeley, developed a pattern language for expressing common architectural patterns Work of Christopher Alexander inspired the work of Gamma et al. In explaining the patterns for architecture, Christopher Alexander says: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” These comments also apply to software design patterns

Resources for Design Patterns Original paper: –“Design Patterns: Abstraction and Reuse of Object- Oriented Design” by E. Gamma, R. Helm, R. Johnson, J. Vlissides Later, same authors published a book which contains an extensive catalog of design patterns: –“Design Patterns: Elements of Reusable Object-Oriented Software”, by E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley, ISBN

Cataloging Design Patterns Gamma et al. present: –A way to describe design patterns –A way to organize design patterns by giving a classification system More importantly, in their book on design patterns, the authors give a catalog of design patterns –As a typical developer you can use patterns from this catalog –If you are a good developer you can contribute to the catalog by discovering and reporting new patterns The template for describing design patterns used by Gamma et al. is given in the next slide

Design Pattern Template DESIGN PATTERN NAMEJurisdiction Characterization the name should convey pattern’s essence succinctly used for categorization Intent What particular design issue or problem does the design pattern address? Motivation A scenario in which the pattern is applicable. This will make it easier to understand the more abstract description that follows. Applicability What are the situations the design pattern can be applied? Participants Describe the classes and/or objects participating in the design pattern and their responsibilities. Collaborations Describe how the participants collaborate to carry out their responsibilities. Diagram A class diagram representation of the pattern (extended with pseudo-code). Consequences What are the trade-offs and results of using the pattern? Implementation What pitfalls, hints, or techniques should one be aware of when implementing the pattern? Examples Examples of applications of the pattern in real systems. See Also What are the related patterns and what are their differences?

Observer Pattern Observer pattern is a design pattern based on Model-View- Controller (MVC) architecture In the next slides, I will give the design pattern catalog entry for the Observer pattern.

ObserverBehavioral Intent The Observer pattern defines an one-to-many dependency between a subject object and any number of observer objects so that when the subject object changes state, all its observer objects are notified and updated automatically. Motivation The Observer design pattern has two parts and they are subject and observer. The relationship between subject and observer is one-to-many. In order to reuse subject and observer independently, their relationship has to be decoupled. An example of using the observer pattern is the graphical interface toolkit which separates the presentational aspect with application data. The presentation aspect is the observer part and the application data aspect is the subject part. For example, in a spreadsheet program, the Observer pattern can be applied to separate the spreadsheet data from its different views. In one view spreadsheet data can be presented as a bar graph and in another view it can be represented as a pie chart. The spread sheet data object notifies the observers whenever a there is a data change that can make its state inconsistent with its observers.

Class Diagram for the Observer Pattern Subject Attach(Observer) Detach(Observer) Notify() ConcreteSubject GetState() SetState() subjectState Observer Update() ConcreteObserver Update() observerState for all o in observers { o->Update(); } observers return subjectState; observerState = subject->GetState();

a:ConcreteObserver:ConreteSubject SetState() Notify() b:ConcreteObserver GetState() Update() GetState() Update()

Applicability Use the observer pattern in any of the following situations: When the abstraction has two aspects with one dependent on the other. Encapsulating these aspects in separate objects will increase the chance to reuse them independently. When the subject object doesn't know exactly how many observer objects it has. When the subject object should be able to notify it's observer objects without knowing who these objects are. Participants Subject Knows it observers Has any number of observer Provides an interface to attach and detaching observer object at run time ConcreteSubject Store subject state interested by observer Send notification to it's observer Observer Provides an update interface to receive signal from subject ConcreteObserver Maintain reference to a ConcreteSubject object Maintain observer state Implement update operation

Consequences Further benefit and drawback of Observe pattern include: Abstract coupling between subject and observer, each can be extended and reused individually. Dynamic relationship between subject and observer, such relationship can be established at run time. This gives a lot more programming flexibility. Support for broadcast communication. The notification is broadcast automatically to all interested objects that subscribed to it. Unexpected updates. Observes have no knowledge of each other and blind to the cost of changing in subject. With the dynamic relationship between subject and observers, the update dependency can be hard to track down. Known Uses Smalltalk Model/View/Controller (MVC). User interface framework while Model is subject and View is observer.

Back to MVC How do the MVC architecture and the Observer pattern relate to Web applications? The reason we are discussing the MVC architecture is that many Web applications nowadays are built based on the MVC architecture The reason we are discussing the Observer pattern is that the MVC-based Web applications doe not properly use the Observer pattern, causing problems

MVC Architecture in Web Applications Many web frameworks support web application development based on the MVC architecture –Ruby on Rails, Zend Framework for PHP, CakePHP, Spring Framework for Java, Struts Framework for Java, Django for Python, … MVC architecture has become the standard way to structure web applications

MVC Framework for Web Applications Use of MVC architecture in Web applications –Model: This is the data model which is an abstract representation of the data stored in the backend database. Typically uses an object-relational mapping to map the class structure for the data model to the tables in the back-send database –Views: These are responsible for rendering of the web pages, i.e., how is the data presented in user’s browser –Controllers: Controllers are basically event handlers that process incoming user requests. Based on a user request, they can update the data model, and create a new view to be presented to the user

MVC Framework for Web Applications Note that use of MVC in web applications does not fit the Observer pattern –typically it is not possible to refresh a browser window directly when the data model changes (i.e., it is not possible to actively notify the observers when the state of the subject has changed) This can create navigation problems –when there are multiple windows open, they may represent stale views –this was the problem in the orbitz example we discussed earlier

Abstraction in MVC Frameworks MVC framework provides separation of concerns and abstraction, which can be exploited for analysis –For example, we can use a tool like Alloy to analyze the data model –We can analyze the controllers to eliminate navigation errors

Achieving Navigation Correctness in MVC I will discuss some work we have done recently on analyzing navigation behavior in web applications developed using MVC frameworks The idea is –to exploit the abstraction provided by the MVC architecture by enforcing navigation constraints at the controller –use model driven development to provide a navigation model and analyze it statically –enforce the navigation model synamically at runtime to prevent navigation errors

Request processing in a Web application

A formal model We can formally model an MVC application as M: is a set of data model states, where the data model can include any stateful representation of application data, such as a database, V: is a set of session variables, i.e., data stored on the server on a per-client basis, I: is a set of sessions used by the server to associate clients with session variables, A: is a set of controller actions, i.e., the program segments that are invoked based on the HTTP requests sent by the user, P: is a set of request parameters, i.e., input data from the user received as part of the HTTP requests via GET or POST.

A formal model A web application is a tuple A = (Q, B, T) where: –Q is the set of states, which is the Cartesian product of the model states and the domains of the session variables for each session –B is the set of initial states –T is the transition relation mapping a state, an action, a set of request parameters and a session to a next state The transition relation must guarantee that each session can only modify its own session variables The model can change even when there is no action executed (i.e., the backend database contents can change without a request from a user)

Session traces Given the formal model, we can define global execution traces of a web application –Each trace starts from an initial state –Each element in the trace is a tuple: (state, action, request parameters, session index) –Any two consecutive tuples in the trace must be consistent with the transition relation of the application We can project each global trace to a session i (by deleting the tuples which do not contain i) and obtain a session trace

Navigation state machines (NSMs) A navigation state machine (NSM) is a state machine –that specifies acceptable sequences of actions and request parameters that can appear in a session trace Given a navigation state machine, and a session trace, –the session trace conforms to the navigation state machine if the sequence of actions and request parameters for that session trace is accepted by the navigation state machine

Navigation state machines The states of a navigation state machine is defined by –the values of the session variables, –the last action executed by the application –And the request parameters that were sent with the last action We assume that this information is enough to figure out what are the next actions that can be executed by the application

Navigation state machines We developed a simple language to specify navigation state machines It is a state machine that shows the allowable sequences of controller action executions in a web application MVC frameworks typically use a hierarchical structure where actions are combined in the controllers and controllers are grouped into modules –We exploit this hierarch to specify the navigation state machines as hierarchical state machines (statecharts)

Navigation state machines In addition to identifying which action can be executed after which other action, –navigation state machines also identify constraints among the request parameters between two consecutive requests –This can be used to make sure that the values stored in cookies are not changes for example

Navigation state machine example A portion of the navigation state machine for the Digitalus system (an open source content management system)

What can we do with NSMs If we can check that the web application conforms to the NSM, –then we can verify navigation properties on the NSM and conclude that the navigation properties hold for the application –We can use model checking to check properties of NSMs –This way we can eliminate the navigation errors Big problem: How do we ensure that the application conforms to the NSM?

Runtime Enforcement Statically verifying that a web application conforms to a navigation state machine is a very difficult problem (in general undecidable) So, instead, we use runtime enforcement –We have a plugin that can be easily added to an MVC web application that takes a NSM as input and makes sure that every incoming request conforms to the NSM –If the incoming request does not obey the NSM, then the plugin either ignores the request and refreshes the previous page or generates an appropriate error message –This way non-compliant user requests can be handled uniformly without generating strange error messages

Model checking NSMs We translate NSM models to SMV We write navigation constraints in ACTL: AG (login => A(!login U logout)) We check the properties using the SMV model checker

Model checking and Runtime Enforcement Our approach combines the following ideas: –Using model driven development for specification of navigation constraints –Using model checking to verify properties of formal navigation models –Using runtime enforcement to ensure that the navigation behavior at runtime obeys the navigation model We show that when all these are combined, navigation errors can be eliminated