Transcript The COMPACT web design approach

The COMPACT web design
approach
Neil Axtell – Web Development Manager,
Landmark Information Group.
Introducing … Neil Axtell
Web Development Mgr – Landmark Information Group
(www.landmarkinfo.co.uk)
Graduated from Thames Poly in 1986
Started working with real-time control systems:
– Microlight Instrument Panel
– High-accuracy milling machine
– Bulk Solid weighing systems
•
•
•
•
Asphalt Loadout systems – 2 Tonnes/sec flow rates
Cold Feed systems
Weigh Feeders
Belt Weighers
Introducing … Neil Axtell
Real-time control systems cont:
– Critical Care medical monitors
• Measure Oxygen saturation in blood both inside the body and outside
• Network printing
• Portable Monitor UI design
– Private Mobile Radio (PMR) systems
• Large systems used by 7 largest Water Authorities
– Tools for GSM S/W development
Internet Technologies:
– First online Car Insurance app in Europe
– Customer Service Data Visualisation application
– Web-based learning/training
Introducing … Neil Axtell
Internet Technologies cont:
–
–
–
–
–
–
Analysis of 3G protocol exchanges
Visual 3G Test Builder web-app
Free Environmental Risk data site www.homecheck.co.uk
Ordering sites for Landmark resellers www.landmarklegalreports.co.uk
Brochure-ware sites www.sitecheck.co.uk
Mapping Components for integration into other sites
What is COMPACT?
Composite Object Modelling Process for Architectural
Communication in Teams
Developed by Neil Axtell and Greenwich University (Liz bacon,
Gill Windall) for modelling the design of web applications.
Has been developed and refined over the last three years by
Landmark.
Has been used by one of the development teams within
Landmark during the design and implementation of Java web
applications using the Struts MVC framework.
What is COMPACT?
Aims to produce a high-level, architectural model of all the web
pages within a web application.
Shows how they are connected together.
Shows the details of any server-side processing needed to
support the transitions between web pages.
Shows the points within the application where major external
systems are accessed.
What is COMPACT?
Once the “network” has been completed, details regarding the
information that is passed between the major components within
the application are added.
Why COMPACT?
Web development teams are typically made up of individuals
with differing skill sets.
These are split between front-end skills (HTML, JavaScript, JSP,
tag libraries) and middle to back-end skills (e.g. Server-side
Java, Database Stored Procedures).
There is need for a simple yet comprehensive model that all
developers can understand.
Why COMPACT?
People reviewing the design of a web app also need some sort
of “context”.
UML diagrams give too much low-level detail but no real
“context” into which this can be placed.
People new to a project need some sort of “map” to find their
way around.
When starting the design of a web application you need some
sort of context diagram around which to base your discussions.
High Level Description
The model needs to support the early design discussions
between the different developers in a web team each with
different skill-sets as well as ensure a definitive record of the
decisions is made. Specifically it needs to:
High Level Description
– Show all the pages in the website/web application.
– Show how the individual web pages are linked together.
– Show what transitions cause the user to move from one page
to another.
– Identify the major external systems (e.g. Database, external
data feed etc.) that the web application interacts with.
– Show what server-side components are used in processing a
user request .
– Give some indication as to what data is sent between the
web pages and the server-side components.
High Level Description
COMPACT is a model to help developers navigate their way
around the application.
It does not record the minute detail of how every Java
class/server-side component is built but is designed to help the
project team:
High Level Description
– Work out where they are and where they need to go.
– Stimulate debate about the best way of getting from “A” to “B”.
– Introduce new developers to the project quickly by giving them access to
a context within which to understand the detail they will rapidly encounter.
– Allow the development work to be easily split between developers.
– Make it clear which developers will be responsible for which parts of the
system being developed.
– Leave behind a piece of high-level documentation that describes the web
application as it was delivered (which may not be the same as how it was
initially designed).
What’s in it for me?
Allows you to show your overall design.
Gives a “coat hanger” on which to hang your more detailed
documentation (e.g. UML).
Allows you to prove that you’ve thought of things up-front and not
just hacked it together.
Makes marking/evaluation much easier.
Provides a great forum for debate!
Enough Theory!
Lets look at an example you should recognise!
– Case Study “A”
The Main COMPACT shapes
Web Page (JSP/HTML/ASP)
JSP page name
Form Page
JSP page name
Server-side Processing
(Servlet)
Servlet Classname
(Package name optional)
The Main COMPACT shapes
Label each web page with it’s real filename.
Label each server-side component with its Classname.
Only add the Package name if you need to avoid Classname
clashes (even better use names that do not clash).
You do not need to show the URLs as this is from a Developers
point of view.
The Main COMPACT shapes
The connections between the
components on the diagram:
[Add] Clicked
A general Java Class:
Class Name
A JSP Tag Library:
<Tag Name>
(Tag name within angled brackets)
Tag Library Name
The Main COMPACT shapes
External Systems
(e.g. Databases)
External
System
Don’t just give them generic labels – give them a meaningful
name e.g. “Museum Artefacts Oracle DB”
The Main COMPACT shapes
Label transitions coming from a web page with the user action
that has started the transition.
If a Form page only has one [Submit] button then you can simply
label the transition “Submit()”.
If a Form page only has more than one [Submit] button then add
the button name (as seen by the user) to the “Submit()” tag
within the brackets.
The Main COMPACT shapes
The starting page within the application:
The point where the user leaves the
application:
Start
Exit
How to draw a COMPACT model
Identify all the web pages in the app.
Identify and label all the transitions between pages.
Identify those pages that submit HTTP Form data.
Add any server-side processing that is involved.
Add any significant general Classes/Tag Libraries used.
Add any external systems that are used.
Add the data that is passed around.
Review for clarity!
Modelling Data
HTTP Data
Java Objects
External System Data
Collections
(Can be Java or HTTP)
HTTP Data
Java Object/Bean
Ext. Sys. Data
A Data Collection
Modelling Data
Give each item of data a meaningful name that describes what it is.
Place the data shapes next to the transition down which they
“travel”.
Place the data shapes close to the model component that creates
them – their “source”.
If anything needs more explanation simply add an annotation/callout to the model.
If there are a lot of individual data items being passed around don’t
be afraid to create a Collection and use that on the diagram.
Modelling Data
How do I show the Context/Scope within which data is stored
within my web app?
Simple – by adding Scope suffixes to the data item name as
follows:
– Request Scope: The default case so no suffix required.
– Session Scope: Add “[S]” to the data item name.
– Application Scope: Add “[A]” to the data item name.
Modelling a DAO
If your app uses a DAO to access
a Database then simply model this
as a General Class sitting
between the application and the
DB:
Event Names
Sport Names
Venue Names
OlympicDAO _ver1
Ol ym pi c
Database
Package Names
A COMPACT model is supposed to bring an overview and clarity.
Don’t be tempted to add too much text.
Only add Package names where you need to avoid a Classname
clash.
If you use a Package naming scheme (e.g. all Servlets in one
Package) then add a Legend as the first page in your COMPACT
diagram.
How do I?
Show a Class that I call directly from my JSP page?
– Use a “General Class” shape an connect it to the JSP page.
Show that I use a Tag Library?
– There is a special shape for a Tag Library. Simply connect it
to the JSP page with the arrow going to the Tag Library.
Which direction do I show the arrows on the
connectors?
– In the direction in which the information flows.
– For a DB read show the data coming from the DB, for a write
show it going to the DB.
How do I?
Show an HTML page that is generated by a Servlet?
– Draw this as a simple HTML page with a name describing its
contents.
– Add “<Generated HTML page>” after the page “name”.
– Draw a transition between the Servlet and this page shape.
– Leave the transition label blank.
What if my Servlet generates a Form page?
– Just use a Form page shape instead.
How do I?
My JSP pages uses Tiles – how do I model that?
– Just show the main “container” JSP page in the COMPACT
model with an annotation indicating the Tiles included (if you
wish).
What about EJBs?
– There are dedicated COMPACT shapes for EJBs with and
without JNDI names.
How do I?
Where do I label the Transitions?
– Either directly inline with the Transition or as separate text
above/below the Transition.
What if I’m using a Model-View-Controller (MVC)
approach to my web app?
– Leave out the Controller as it “hides” the logical transitions
between pages.
– Just show the Views and the Model
– If you are using Struts then there are special symbols
available for you to use.
Package Names
COMPACT web design approach
Package Names
Top-level package:
Servlet package:
Java Beans package:
Struts Actions package:
Business Delegate package:
uk.org.compact-web
Any Questions?
If you want to practise drawing a COMPACT model then
come to the Tutorial.
Remember, a COMPACT model is about giving an
overview and making things clear.
– Resist the temptation to add too much on a single page.
– Don’t put too much detail, you can decompose this down to
other diagrams/documentation.