|
Having
thought through what a feature might look like, the next job was
to consider what the model of a UI might look like. In 1998, I felt
that this was probably based on a storyboard of the screens. A Navigation
diagram. At the time this was known as a "high level design".
I now consider this totally unsatisfactory. Navigation modeling
is a the process of mapping a storyboard for a UI in an engineering
notation. There is currently no standard for this but the leading
work in the area belongs to Dave Roberts of IBM's Ease of Use group,
OVID [Roberts98]. Constantine and Lockwood
have also done considerable work in the area of model driven interaction
and interface design. [Constantine99].
However, at this time tool support is sparse. When you are running
at web speed, you must reject any method which cannot be automated
in tools. I have therefore ignored the Navigation model (the high
level design) and focused on the Implementation model (the low level
design), for the model which will drive FDD for user interface.
Directly
following earlier work by Ian Horrocks [Horrocks
98], I am proposing that the implementation model for a user
interface design is delivered using David Harel's Statechart notation
which is already adopted into the UML. This provides ready availability
of modeling tools and the support of an open standard. FDD for UI
is therefore a Statechart model-driven method for presentation layer
project management.
Stage
1. Develop a Statechart Model
From
the user interface prototype, storyboard or navigation model, develop
a Statechart Model. This model should be wide. It should cover,
at least, the whole of a Subject Area from the business features
list.
Modeling
a UI with Statecharts has been explained in detail by Ian Horrocks
[Horrocks 98] and in the Web MVC articles
here at uidesign.net [Anderson 99]
Identify
the Views from the Navigation model, storyboard or prototype which
are associated with appropriate states.
Stage
2. Develop a Feature List
For
each State which has a View associated with it, list a feature in
the format,
<purpose
of screen> View
e.g. subscriber search dialog View
For
each Event coming from each View, list a feature in the format,
<action>
Event
e.g. search Event
The
<action> should be named from the button or control which
was affected in order to create the event e.g. a button labeled
"Search" would create a 'Search Event'.
Note
that several transitions from the same state can actually be using
the same event. Do not create a feature for each transition, only
1 for each event.
Transient
Business Features
There
is a third type of feature created from the UI. I am calling these
Transient Business Features. These are additional to the existing
features from the Business Layer which I am now proposing are known
as Persistent Business Features.
Transient
Business Features are created by the requirement in the UI to display
information which does not affect the persistent state of the business
objects. These features are often associated with transient collections.
For example,
List
the Subscribers for a given Search Criteria
This
feature is still being written in the agreed format for business
features, <action> <result> <for|to|of|from>
<object> but the object is a transient e.g. a search criteria
and the result is a transient e.g. a collection of Subscriber
objects. It would normally be implemented as a class method, or
directly onto the persistent data store.
This
first class of Transient Business Features usually manifest themselves
in the guard conditions or the actions on the transition arrows
on the Statechart.
There
is a second type of Transient Business Feature. These are generated
by implementation dependencies. For example, in a distributed environment
such as the J2EE platform, it may be necessary to build fine grained
data objects to facilitate "pass by value" from the business
layer implemented as EJBs in the application server, to the presentation
layer, implemeted as JSPs or Servlets, in the web server. Code needs
to be written for these "pass by value" structures. This
code is tightly coupled to the display object and is most definitely
transient.
An
example of a "pass by value" Transient Business Feature
might be
Get
the data for the account summary table
These
"pass by value" features are hard to spot because they
require detailed design. However, they will impact your planning.
If you decide not to list such features then be sure to size View
classes appropriately as to include time to develop any "pass
by value" code which might be necessary.
Stage
3. Develop a Detailed Plan
Number
each feature for tracking purposes. Insure that each feature is
traceable to a requirement, a use case, an element of your navigation
model or your storyboard, or all of these.
Group
features into sets using Strategy 1 from above. Each set should
contain a View, any sub-views, all the Events from the View, and
any Transient Business Features which resulted from the Event transitions
for the View.
Develop
subject areas of feature sets by identifying all the UI features
required to deliver the interface onto a subject area from the business
layer.
Now
weight and size each feature.
The
5 point scale
I
have developed a 5 point scale for this purpose. Following on from
lessons learned from Fred Brooks [Brooks 95],
the scale is non-linear. The scale is used later for tracking actual
against plan and adjusting estimates as project progress is reported.
|
Weight
|
Man
Days
|
| 1 |
1/2 |
| 2 |
1 |
| 3 |
2 |
| 4 |
4 |
| 5 |
8+ |
A
planning team which typical consists of the project manager / project
office staff, some of the modeling team or analysts, plus the chief
programmers will make the estimates. Each feature will be briefly
discussed and a weight assigned. For a project with 500 features,
this weighting can be performed in a typical afternoon planning
session. It is well worth the effort.
If
a 3 person feature team were given 3 features to design and build,
all of weight 3, then it ought to take them 2 working days to develop
the design material, review it amongst themselves, write the code,
perform some unit tests and and review the delivered code. Typical,
work bundles will be 5 to 10 features per chief programmer.
In
recent studies, where the emphasis was on web development of presentation
layer, the average complexity of features, modeled using the methods
described in this paper have delivered an average complexity weighting
of around 1.6.
In
other words a typical web page can be build as a JSP by a single
programmer in 1 day, and a typical event controller, can be build
by as a Servlet by a single programmer in half a day.
So
far this scale has proved reliable, needing only minor adjustment
during the development lifecycle. At the very least it provides
a good basis for evaluating plan vs actual performance.
Business
Features and the 5 point scale
I
have also used the same scale for business features. One rule of
thumb which I have adopted is to assign points on the scale against
the number of affected classes for the feature. During the planning,
we are only guessing at the complexity of the sequence diagramming
but a good guess is good enough. Normally, there are enough features
that guessing will average out over the whole project.
|
Weight
|
Classes
touched
|
| 1 |
1 |
| 2 |
2 |
| 3 |
3 |
| 4 |
4 |
| 5 |
5
or more |
This
scale worked well at ebeon.com, in 1999, where it was used to predict
the resources needed for the business layer development on a medium
sized project with 153 business features, to an accuracy of -10%.
In other words, development actually took 10% longer than predicted
but the bug count of only 5 reported errors against 153 features
meant that the slight time overrun was broadly acceptable, as the
time could be made up during system test. Feature Driven Development
run properly with design and code reviews leads to a high quality
of delivered code.
More
experiments and more data points are required to see whether the
5 point scale is of true value.
Stage
4. Design by Feature
At
this stage the deliverables become implementation specific. The
project office will assign features to a chief programmer who will
work with the feature team to design and build them. Developers
on the feature team will be assigned Views or Controllers to build.
They may also be assigned to work with the business layer developers
to provide the transient business features.
The
design output in a JFC/Swing project might include a class diagram
detailing the JFC components being used and how, as well as detail
of the Event classes being used, the Listener inner classes acting
as controllers, and the JFC classes acting as Views. A Sequence
Diagram showing the interaction amongst the presentation layer components
and how they interact with the business layer classes may also be
needed.
In
a web environment, a design detailing how the Controller or View
is being implemented together with a Sequence Diagram of interaction
with the business layer, may be needed. If an infrastructure similar
to that decsribed elsewhere at uidesign.net [Anderson
99] were being used then the developer would detail the logical
names of events, the parameters being passed and the transient or
persistent business methods being called to implement the guard
conditions and the actions.
The
feature team would review the design documentation against the requirements,
the Statechart model, the architecture and design guidelines for
the project, and the design review checklist.
Stage
5. Build by Feature
Each
developer builds their assigned classes or adds appropriate methods
to existing classes. Unit tests are run and results collated. Code
is brought back to the feature team for review. It is reviewed against
the design documentation from stage 4, together with coding guidelines
for the project and the code review checklist.
If
the chief programmer is satisfied that the work is complete to the
agreed standard then the feature is marked as complete and the code
is promoted to the system build for handover to the system testing
team.
Modeling
with Statecharts - a review
Modeling
the user interface with Statecharts has been discussed at uidesign.net
before. However, it would be appropriate to review how it is done
and how it helps to develop the UI Feature List and facilitate the
development of the presentation layer code.
Practical
experience using Statecharts for user interface design have shown
that it is not completely up to the task in its current form. There
are three key areas where Statechart notation is not currently sufficient
for the purpose of user interface modeling. The first is the notational
scoping of transactions or units of work. The second is the ability
to cope with processing exceptions where the normal flow of states
is interrupted. The third is derived out of the hierarchical nature
of user interface design problems. This leads to a large depth count
in the hierarchy of states which diagrammatically problematic. Drawing
user interface implementation models with current Statechart notation
is difficult. Suggestions to change the notation were made in the
TUPIS 2000 Position Paper [Anderson 00]
Finally
you should adopt a naming convention emerge for States within Statechart
diagrams, so that is possible to identify a given State on a diagram
and understand its position in relation to others in a hierarchy.
Make this naming convention part of your standards and guidelines
for your project. Encourage its use and discourage deviation from
the naming convention. Deviation will only slow you down later.
The
modeling tradeoff
Recently,
I have had very good feedback from developers on the use of modeling
with Statecharts. Comments like, "It has been really useful
to do this, it really makes you think carefully about how the application
should work." "Modeling with Statecharts has really helped
me to understand what we are doing". Overall I have noticed
a marked improvement in team confidence after completing the Statechart
modeling exercise. I believe wholeheartedly that the effort pays
back in improved team understanding, clarity of work to be carried
out, and improved quality of deliverables. The only cost is that
you must keep the Statechart model accurate during development.
As UI design changes arrive from the user experience team, you must
insure that the model as well as the code are kept in sync.
An
example of statechart modeling for a UI Feature list
In
Diagram 2, there are 4 Views called: First Page; Second Page; Good
Exit; and Bad Exit. There are 2 Events: Submit Name and Address;
Submit Credit Card Number. [Note these are not particularly good
names for the events]. There are only two Events because the transitions
coming from "Second Page" View have the same event. This
event would be processed through a Controller which is described
in the Mediator Pattern in the seminal text on the subject, Design
Patterns [Gamma 95].
There
is arguably one Transient Business Feature - "validate credit
card number". The transaction start and commit or rollback
requirements do not need to be considered as features, they are
merely design detail for the Event features.
[The
transaction boundary shown below is a manually added embellishment
and is not supported by any Statechart modeling tools at this time]
|