More on “The Huddersfield Method”

1. More on “The Huddersfield Method” A lightweight, pattern-driven method based on SSM, Domain Driven Design and Naked Objects

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

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

4. A work in progress... • Basis for a number of MSc Projects

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

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

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

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

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

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

11. Pattern related to M:M

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

13. Project • Help identify/document more patterns like this • Based on grounded theory?

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

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

16. Project • Apply and evaluate the method on real development projects • The university library • The research office • The placement unit • Something else.....