Review of “The Huddersfield Method” - Helios

wakecabbagepatchSoftware and s/w Development

Nov 18, 2013 (3 years and 11 months ago)

110 views

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