PB007 Software Engineering I — Design Class Diagram1
Design Class Diagram
PB007 Software Engineering I
Lukáš Daubner
daubner@mail.muni.cz
PB007 Software Engineering I — Design Class Diagram2
Design Class Diagram
̶ Focus on implementation details
̶ It goes further than capturing domain
̶ Solutions to more technical problems
̶ Extends and enrich the analytical
class diagram
̶ ADVANCED: Patterns (Design Patterns)
PB007 Software Engineering I — Design Class Diagram3
How should it look like?
Design Class Diagram
̶ All that you need for implementation
̶ Except method body (we will get to that)
̶ Detailed specification of analytical class
̶ Technology-related class (Service, Controller, DBContext, etc.)
̶ Visibility and types are specified
̶ Attributes
̶ Method arguments
̶ Return values
̶ Constructor
̶ Properties (Getters, Setters)
̶ Methods needed for implementation
PB007 Software Engineering I — Design Class Diagram4
Analytical VS. Design class
Design Class Diagram
PB007 Software Engineering I — Design Class Diagram5
Design Class Diagram – Example
PB007 Software Engineering I — Design Class Diagram6
Interface
̶ Defines set of public services
̶ Methods
̶ Attributes
̶ Relationships
̶ Does not contain implementation
̶ Defines so called “Contact”
PB007 Software Engineering I — Design Class Diagram7
Specialized Associations
̶ Specification of aggregation and composition (see following slides)
̶ There is a lot of confusion regarding this topic.
See https://bellekens.com/2010/12/20/uml-composition-vs-aggregation-vs-association/
̶ Names, navigability, and multiplicities
̶ Afterall, it is an important part of the specification
̶ Decomposition of bidirectional associations
̶ Decomposition of M:N associations and association classes
PB007 Software Engineering I — Design Class Diagram8
Specialized Associations – Aggregation
̶ Whole-part relationship
̶ The whole may and may not exit without its parts
̶ Parts can exist independently from the whole
̶ The whole is in some sense incomplete if some parts are missing (but still valid)
̶ Parts can be shared by multiple wholes
̶ Transitive and asymmetrical (without cycles)
PB007 Software Engineering I — Design Class Diagram9
Specialized Associations – Composition
̶ “Stronger” form of aggregation
̶ The part belong to exactly one whole in the given time
̶ The part is not valid without the whole
̶ The whole is responsible for lifecycle of its parts
̶ When deleting, the whole must take care of its parts (delete or transfer them)
̶ Transitive and asymmetrical (without cycles)
PB007 Software Engineering I — Design Class Diagram10
Code comparison
Aggregation vs. Composition
public class Ship
{
private Engine _engine;
public Ship(Engine engine)
{
_engine = engine;
}
}
public class Ship
{
private Engine _engine;
public Ship()
{
_engine = new Engine();
}
}
PB007 Software Engineering I — Design Class Diagram11
Association Decomposition – M:N
̶ Analytical
̶ Design
̶ Decompose if there is
a need for additional attributes
̶ Someone must “own” it
PB007 Software Engineering I — Design Class Diagram12
Association Decomposition – Bidirectional
̶ Someone must “own” it
̶ To ensure consistency
PB007 Software Engineering I — Design Class Diagram13
You gotta do what you gotta do
Task for this week
̶ Process the feedback
̶ Copy and extend analytical class diagram to design class diagram
̶ Add all required methods, properties, constructors, etc.
̶ Specialize and decompose associations when suitable
̶ Type everything
̶ Add technology-related and service classes
̶ NB! Do not delete the original analytical class diagram
̶ Do your part in peer review