Review of “The Huddersfield Method” - Helios

More on “The Huddersfield
Method”

A lightweight, pattern
-
driven
method based on SSM, Domain
Driven Design and Naked Objects

Features

Emphasises an object oriented approach


Based on a core
subset of
UML

•
the most important 3 of the 14 diagrams


Assumes that requirements may be vague, ambiguous, incomplete, or

incorrect

•
hence recommended use of SSM in the early stages


Goes all
the way to
code

•
by emphasising application of the Naked Objects Pattern


T
raceable
from one step to the next
.


Emphasises an “agile” approach

•
short iterations,
small
increments

Plans

•
Specified in a pattern language

•
Patterns based on a grounded theory
approach

•
Interviews, marking assignments etc.

•
An attempt to specify a pattern language that
guides us away from common problems that
students have when learning about systems
development

A work in progress...

•
Basis for a number of MSc Projects

Putative Patterns

Use
a
modelling
tool that supports linkage and
traceability between


•

SSM Activities and use
cases.

–
Eg
. by
dragging and
dropping or colour coding.....


•
Use Cases and Sequence Diagrams

•
Sequence Diagrams and class diagrams

•
Class diagrams and code




Project

•
Develop SSM models of the systems
development process

•
A framework of conceptual models that can
be used as a starting point for designing a
CASE tool to support the Huddersfield Method

•
The CASE tool will be designed following the
Huddersfield Method!

Putative Patterns

Organise
your use cases with actors and use case diagrams
.


Initially concentrate on the “happy path” through the use case
identifying any alternatives or exceptions


Describe the happy path using
an event/response flow,
describing both sides of
the user/system
dialogue.


Use
GUI storyboards, prototypes, screen
mockups
, etc.


Reference
domain classes by name.


Reference
boundary classes (e.g., screens) by name.

Distinguish the domain model from the class diagram

•
Domain model represents the “real world” the class diagram is a
software design


Focus
on real
-
world (problem domain) objects.

•
Use association, generalization
(is
-
a) and aggregation (has
-
a)
relationships to show how the
objects relate
to each other
.

•
Consider breaking up any M:M relationships


Don’t put boundary objects (web pages, screens) on your domain
model.

•
Save them for the class diagram


Don’t expect your final class diagrams to precisely match your domain
model




Putative Patterns

Pattern Related to M:M

Problem:

•
How to model the relationship between two
classes
that have a
many
-
to
-
many
association with
each other
.


Forces

•
Many
-
to
-
many
relationships occur often in the real world.

•
It
can be difficult to implement many
-
to
-
many associations in some
object oriented programming
languages.

•
Many
-
to
-
many
relationships have no direct implementation in
relational database

•
systems in which they may have to be persisted.

•
A
many
-
to
-
many relationship is usually complicated enough to
warrant
the addition of an extra class.

Pattern Related to M:M

Solution

•
Transform the many
-
to
-
many association
between two classes into a trio of classes
by
creating
an intermediary class with two one
-
to
-
many
relationships. The name
of the
intermediary class should describe the type of
relationship being captured.

Pattern related to M:M

Pattern related to M:M

Discussion


•
This allows attributes and methods to be added to the
relationship, such as a date range
to the
Employment
class in the previous example. The multiplicity can be
tweaked on
either side
of the intermediary class to
more precisely define the exact nature of the
relationship
. For
example, the multiplicities on the left
side of the Employment class in the
example could
be
changed
to
reflect the fact that a person
may be
unemployed or have only a single job at a time.

Project

•
Help identify/document more patterns like
this

•
Based on grounded theory?


Putative Patterns

Create
a sequence diagram for
the happy path through each use
case,

•
Create additional diagrams for the exceptions and alternate
courses


Use
the sequence diagram to show how the
behaviour
of the use case
is
accomplished by the objects.


Make
sure your use case text maps to the messages being passed on
the
sequence diagram
.

•
Try
to line up the text and message arrows
.


Assign
operations to classes while drawing messages.

•
Some CASE tools support
this capability
.


Make
sure all your attributes are typed correctly, and that return values
and
parameter lists
on your operations are complete and correct
.


Generate
the code headers for your
classes


Putative Patterns

If you believe in Naked Objects:


Ensure that all

the business logic is encapsulated onto the domain objects. No
control objects!


•
This principle is not unique to naked objects: it is just a strong commitment
to encapsulation. Arguments both for and against this idea may be found
within the research literature for object
-
oriented programming and domain
-
driven design.


The user interface should be a direct representation of the domain objects, with
all user actions consisting, explicitly, of creating or retrieving domain objects
and/or invoking methods on those objects.


•
T
his principle is also not unique to naked objects: it is just a specific
interpretation of an object
-
oriented user interface (OOUI).


The user interface should be created 100% automatically from the definition of
the domain objects. This may be done using several different technologies,
including source code generation; implementations of the naked objects
pattern to date have favoured the technology of reflection.


Project

•
Apply and evaluate the method on real
development projects


•
The university library

•
The research office

•
The placement unit


•
Something else.....