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
Traceable 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.
Putative Patterns
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
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 oneto-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 domaindriven 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.
•
This 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.....