Domain Analysis

and Models
Object-oriented
Programming Project
Niklas Broberg, 2024
PSA: Pitch Sessions
• Confirmed “issue” with GU students on Canvas and
“Appointment Groups”. Future bookings will be handled
via Slack.
• The GU-only teams will be contacted for a special invite
regarding these first sessions.

• Piero: User Feedback, Agile methodology

• Sessions next week.

• Wincent: Technical tools

• Probably early week 4.
PSA: Upcoming lectures and sessions
• W3:
• Wednesday lecture: Roleplay on Team Dynamics and Conflicts
• Wednesday workshop: AI copilots
• Thursday lecture: Design and Architecture
• Friday seminar: early presentations (see next slide)
• W4 Wednesday lecture: Natasha Mangan on ECS architectures
• W5 Wednesday lecture: Putting the pieces together, iteratively
• W6-7: Possibly more guest lectures, presentation techniques,
• iterative and incremental (agile!) decisions on lecture content
PSA: Seminars
• Early feedback from me, the supervisors, and other
teams.

• Compulsory to be present in person.

• If you have pressing(!) needs to participate remotely,
contact me in advance.

• Each team participates in one of three seminar

sessions
• 2h per session, 10-11 groups per session.
• 10 minutes per group, including questions and
feedback.
• Bookable slots through Slack, same principle as for
pitch sessions. Stay tuned!
PSA: Survey
• Research project on team dynamics and representation.
• Me, Eva Ranehill (LU), Kajsa Hansson (LU), Anna Sandberg Trolle-Lindgren (SU)

• Analysis of submitted material – statistics, not individual data.

• Two short surveys: First one will go out tomorrow.

• Second one in January.

• You may opt out – information in the Survey.

PSA: Course evaluation process
• Midterm meeting early w4 (TBD).

• Please lift any issues you may have: to me, to your supervisors,
and/or to your student representatives:
• GU: Yousef Noufal, Tim Persson, Daniell Cole
• Chalmers: Chloe Dusén, Thomas Mathiassen, Shifaa Mahmoud

• We are very committed to do our best to make the journey of every

team and every student as awesome as possible.
Where you at?
• At this point in the project you should have…
• Nailed down an idea for a product to develop.

• A team contract that you actively work by, and with.

• Discussed inclusivity – what that means for your team, and
how you need to work to ensure it.

• Started working with user stories.

• Started discussing system architecture.
• Plans for second iteration of user feedback elicitation.
Refresher: Iterative process
We use an
• iterative (i.e. cyclic, repeating)
• incremental (i.e. in many small steps)
process for development, so that our team can
• meet changing expectations and context demands
• easily adapt based on end-user feedback
• deliver early testable prototypes that improve quality of
feedback

In other words, we strive for teams to be agile.

Analysis – Design – Implementation
• Analysis – What software should we actually develop? Do The Right Thing
• User stories: Cards, Conversation, Confirmation
• INVEST criteria for stories, SMART criteria for tasks Non-Technical
• Domain model: Ubiquitous Language, Bounded Contexts, Entities and Values, … Conversation within the
• Paradigm-independent (e.g. OO), free from technical aspects, common language team and with external
with non-technical domain experts. stakeholders

• Design – How do we structure the software in the best way? Do The Thing Right
• Architecture (MVC), components , modules
• SOLID, design patterns Technical Conversation
• Independent of programming language, frameworks, etc. within the team, or
between development
teams
• Implementation – How do we realize our design in practice?
• Programming language, frameworks/libraries/APIs, … Make The Thing Work
• Concrete algorithms, data structures, method implementations, …
Smaller groups
User Feedback
• What do you test? Active choice!
• W1: UI mockups, project ideas
• After that, you choose. Priorities?
Single features (vertical slices)?
User experience?

• How do you test? Active choice!

• Focus interviews? Usability testing? Specify to the user what is being tested, and
steer the feedback accordingly.

• How often do you test? Active choice!

• Our minimum requirement is feedback from two users each week. You can do more,
and more often!
Refresher: User Stories
• A modern incarnation of ”requirements”
• Answering the question ”what should the system do”
• Adding the ”why” – or rather, ”what value” – to requirements.
• Centered around living Conversation.

• The three Cees:

• The Card – physical reminder of the ongoing Conversation
• The Conversation – ongoing communication between stakeholders
• The Confirmation – how we can all agree when something is fulfilled

• Best practices and tools:

• ”As an [persona] I want [feature/activity] because [value]”
• INVEST metrics.
Communicating with external stakeholders
• “Pidgin language” – a language that allows two parties with different
“lingo” to communicate with each other.

• How to best form such a pidgin language?

• Teach the non-developer stakeholders about developer lingo?
• Teach the developers about domain lingo?
• Some hybrid of the two?
UML design diagrams - wrong abstraction!
Signal
- status : SignalStatus SignalObserver
- speed : Speed
- view : SignalObserver <<interface>>
+ run() : void + actOnSignalChange(SignalStatus) : void
+ speedUp() : void
- slowDown() : void
- notifyStatusChange() : void

SignalLogger SignalView
SignalApp + actOnSignalChange(SignalStatus) : void + actOnSignalChange(SignalStatus) : void

+ main(String[]) : void
Ubiquitous Language
• Ubiquitous (en): “överallt närvarande, genomsyrande,
förekommande”

• Build the pidgin language from the lingo that already exists in the
domain.
• Teaching domain experts about developer lingo is very very hard.
• However, some technical lingo is useful to introduce.
• Teaching developers about domain lingo is not trivial – but:
• Much easier than other way around.
• Added benefit of making developers analyse and understand the domain better.
RAD: Requirements Analysis Document
• Communicating “Domain Design” to domain experts, to facilitate
continuous Conversation.

• Includes
• Introduction – in plain text, what are the overarching goals and vision?

• “Requirements”:
• GUI sketch/mockups
• User Stories
• (Stages,) DoD: Definition of Done

• Domain model
Running example: Monopoly
• “The project aims to create a computer based generic version of the well known board
game Monopoly by Parker brothers. Generic in the sense that it's should be possible to
adapt the game to different locations and more.” – Introduction in RAD

• General characteristics:
• The application will be turn based.
• The actual player must explicitly end his or her turn.
• The next player is chosen by the application from a preset ordering.
• The ordering is generated randomly by the application at start of the
game.
• There are no time constraints for a round.
• The application will end according to the rules or possibly be cancelled.
• If the game is cancelled the player with most resources will be the winner.
• The application will handle all of the bank's responsibilities.
• …
 UI
sketches/mockups
Epics As as: user
I want to: set up the game
so that: the game can commence

As a: user Acceptance:
I want to: play the Monopoly game - User can set the options
so that: I can have fun - After all options have been defined
(number of players etc.), the game is
Acceptance: ready to start
- User can play game according to Monopoly
rules
As as: player
I want to: take a turn
so that: I can try to win

Acceptance:
- User can roll dices
- User can make a move
- The state of the game is updated
according to Monopoly rules
- ...
 User Stories As as: player
I want to: roll the dice
so that: I can make a move

Acceptance:
- Player can start the roll of the dices
As as: user - Only the active player can roll the dices
I want to: choose the number of players - After rolling the player can make a move
so that: I configure the game - The player can only roll the dices one time
- ...
Acceptance:
- Application can read input from user
- User can fill in number of players
- The game configuration is updated according to user input
- The game cannot start before the number players is configured
- The number of players can not be changed after the game has
started
- ....
 Task breakdown
• Show the board
• Show the players on the board
As as: player
I want to: roll the dice • Highlight the active player
so that: I can make a move
• Allow the active player to roll the dice
Acceptance: • Show the resulting dice values
- Player can start the roll of the dices
- Only the active player can roll the dices • Make the dice values available to
- After rolling the player can make a move
- The player can only roll the dices one time other actions (next move)
- ...
• Change active player
Domain-Driven Design (DDD)
• Design methodology closely connected to “Agile”
development processes (XP)
• Built around the interplay between Domain Model and
User Stories
• Central aspect (Domain Pattern): Ubiquitous Language

• Continuous Conversation with domain experts.

• Elicit User Stories and Ubiquitous Language.
• Let these guide the construction of a Domain Model
• Abstract model of the domain, independent of technical
design
Domain Model
• Abstract model of the domain
• Core entities, values, services, and
their relationships.
• Associations – who knows who?
• Multiplicity – how many of each are
part of a relationship?

• Higher abstraction level than e.g. class diagrams; less formal.

• Should be comprehensible to non-developer stakeholders, e.g.
• Domain experts, end users, product owners, …
• Intended to promote and facilitate Conversation (internally and with stakeholders) centered around “doing the
right thing” – ensuring that we’re working towards the correct end goal.

• Concretized (internally by developer team) through a design model, including class and object
diagrams, …
Monopoly: Domain model

First iteration!
Domain model vs Class diagram

A Class Diagram is a tool primarily

The Domain Model is part of the
for Conversation around
material for internal and external
development – internally or with
discussion.
other developer teams.
• Ubiquitous Language, no “techno • Should be technically oriented
babble”. and suitably detailed.
• Abstract concepts, not • How can we translate and
implementation details. concretize a domain as an object-
• “If this were a physical product…” oriented design model?
Domain design patterns
Entities – core concepts with identity.

Value Objects – core data types without identity.

Services/Service Objects – core operations not (yet) tied to

specific entities.
Factories and Repositories – create or fetch entities or value
objects (partial techno babble!).
Entities
• Entities are “things” with their own identity.
• Important to be able to distinguish one from the other.

• Can only appear once in the (design) model and implementation.

• No cloning, defensive copying, …
• .equals should be the same as ==, i.e. referential equality.

• Can often be “looked up” through a repository based on identity.

Monopoly: Domain model First iteration!
Only entities so far
(and we haven’t
covered all)

Weird multiplicities,
missing relationships, …
Aggregates
• Entities can often be composed of many aspects (components).
• Both on the domain level, and in the design model.

• All aggregates have a Root Object.

• External entities can only talk to the Root, which represent the whole of the
aggregate.
• Law of Demeter
• State and statefulness is concentrated to the Root Object, or as a separate
Component, or outside the Aggregate.
• Consider what works best for each case.
Monopoly: Entities
• Player: Figure, Position, Money, Streets owned

• Street: Cost, Houses/Hotel, Tile placement

• Tile: Street or Event, Board placement

• Board (singleton): Tiles ordering, Players

and positions
Value Objects
• Complex “things” that aren’t simply what Java calls values (e.g. int, String, …), but
behave as values in this domain,
• We don’t care about identity.
• E.g. a date, a position in a system of coordinates, …
• Example: A business card that is composed of different information items – but we don’t care
which specific copy of the card we have in our hand, only the information on it.

• Monopoly: Chance cards

• There can be several different cards that say the same thing, e.g. “Go directly to jail”. We don’t care
which of these identical cards we draw, only what’s written on it.

• Implementation: Should preferably be clonable (.clone, copy constructor) and compare based
on values (.equals instead of ==, since referential equality is meaningless)
Second iteration – entities – draft work-in-progress
Monopoly Board
Player
Represents the game and Knows the order of
Represented by a piece different spaces
its rules
Has money
Owns streets
Piece is no longer
an entity

Dice Space
Can be rolled by player Represents one space a
Result between 1 and 6 player can land on

Suite Street EventSpace Card

Several streets together Can have houses or hotels Spaces that are not Some events
Player monopoly causes streets cause drawing of
higher rates cards

Value Object,
not entity
Third iteration – relationships – draft still!
Monopoly Board
Player
Represents the game and Knows the order of
Represented by a piece different spaces
its rules
Has money
Owns streets

Dice Space Card

Can be rolled by player Represents one space a Value object that
Result between 1 and 6 player can land on causes event
Belongs to deck

Suite Street EventSpace Deck

Several streets together Can have houses or hotels Spaces that are not Deck of “Chance” cards
Player monopoly causes streets
higher rates
Service Objects
• Abstraction for operations (services) not specifically tied to any one
entity.
• Monopoly: GoToJailHandler, PassGoHandler, PurchaseHouseHandler…

• Common operations often affecting several different entities.

• GoToJailHandler is called from a Chance Card, and moves a given Player to a
specific Tile.
• PassGoHandler is called from Board, and pays out money to the Player.
Factories and repositories
• Control how different entities can get access to other entities or value objects.
• Special forms of Services.

• Factory: Abstraction for the creation of entities and value objects.

• Repository: Abstraction for the retrieval (lookup) of existing entities/value
objects.
• that already exist in the program; or
• that are fetched from secondary storage, e.g. a database or file system

• NB! Present at domain level and design level.

• Which entities should have access to creation or retrieval of other entities?
• Factory and Repository are “techno babble” – does the Ubiquitous Language have other
terms already, such as a “Document storage”, …?
Monopoly: Factories and repositories
• How do we find a Player? A Tile?

• How are houses and hotels created?

• How is a Player initialized? The Board?

Analysis – Design – Implementation
• Analysis – What software should we actually develop? Do The Right Thing
• User stories: Cards, Conversation, Confirmation
• INVEST criteria for stories, SMART criteria for tasks Non-Technical
• Domain model: Ubiquitous Language, Bounded Contexts, Entities and Values, … Conversation within the
• Paradigm-independent (e.g. OO), free from technical aspects, common language team and with external
with non-technical domain experts. stakeholders

• Design – How do we structure the software in the best way? Do The Thing Right
• Architecture (MVC), components , modules
• SOLID, design patterns Technical Conversation
• Independent of programming language, frameworks, etc. within the team, or
between development
teams
• Implementation – How do we realize our design in practice?
• Programming language, frameworks/libraries/APIs, … Make The Thing Work
• Concrete algorithms, data structures, method implementations, …
Smaller groups
Seminar: requirements
• We want you to present:
• A (early draft of) domain model
• Some examples of user stories.
• GUI mockups, screenshots, …
• If you have a demo, fabulous!

• … but make it quick, it’s only 10 minutes!

Three takeaways
• Use domain language – Ubiquitous Language – in user
stories and domain model.
• Ensure you are Doing the Right Thing through continuous
conversation involving non-developer stakeholders.

• Mapp domain concepts to design through the use of

established domain patterns.
• Entity, Aggregate, Root Object, Value Object,
Service Object, Repository, Factory
• Again: Do The Thing Right.

• Utilize resources in the best way possible!

• Pitch Session, seminars, supervision meetings, lectures, …