Tools for Automated Verification of Concurrent Software

bracechumpInternet and Web Development

Feb 5, 2013 (4 years and 5 months ago)

143 views

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 0
-
201
-
63361
-
2

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 NAME



Jurisdiction 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.

Observer





Behavioral


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