Design Class Diagrams

Why make Design Class Diagrams?

• allow us to create and show the specification for the software classes
that we’ll build

• principally they show:

• classes and their associations

• attributes with their types and visibilities

• methods with their parameters, return types and visibilities

• and also:

• interfaces with their operations

• dependencies

• DCDs can be created in parallel with sequence diagrams

 Example

Three section box Navigability

Register Sale

Date
isComplete : Boolean
Captures time
addLineItem(…)
… 1 1 makeLineItem()

methods; parameters not specified Type information

from Ch 19 Applying UML & Patterns (Larman)

 Domain versus Design

Register Sale
Domain Model
1 Captures * Date
isComplete : Boolean
time

Register Sale
Design Model Date
1 Captures 1 isComplete : Boolean
addLineItem(…) time
… makeLineItem()

from Ch 19 Applying UML & Patterns (Larman)

 How to Create a DCD
• draw for the whole system or for a subsystem

• identify which classes participate

• from sequence diagrams

• add attributes

• look to the domain model for inspiration

• but note that not all classes and attributes from the
domain model will be used

• likewise, new classes and attributes will be needed which

aren’t in the domain model
Example: identify classes & attributes

Register ProductCatalog ProductSpecification Payment

quantity description amount
price
itemID

Store Sale SalesLineItem

address quantity
date
name isComplete
time

from Ch 19 Applying UML & Patterns (Larman)

 ...How to Create a DCD...
• add methods

• again from sequence diagrams

• aim for a 1-to-1 match (revise docs in parallel to achieve this)

• expect to identify more methods as you progress (and maybe lose some)

• some points:

• replace create() with actual constructor detail

• leave out simple getters and setters

• e.g leave out getHeight() for the attribute height

• but do include important, derived getters

• e.g. getTotal() for Sale class

• add types
Example: add methods & types

from Ch 19 Applying UML & Patterns (Larman)

 ...How to Create a DCD...
• add associations and navigability

• rather like the domain model

• derive from the sequence diagrams

• show when:

• A sends a message to B

• A creates an instance of B

• A needs to maintain a connection to B

• direction of arrow:

• usually the source class has an instance of the target class as an

attribute
Example: add associations

from Ch 19 Applying UML & Patterns (Larman)

...Example expanded

from Ch 19 Applying UML & Patterns (Larman)

 ...How to Create a DCD...
• avoid needless effort!

• add visibilities?

• by convention attributes are private and methods public, so we usually don’t need to
represent these

• so just use:

• + for public

• - for private

• when an attribute or method breaks convention

• model user interface classes?

• for sheer practicality do not waste time modelling the huge number of attributes and
methods contained within a user interface

• just show it’s a <<user interface>> below its name, and show its association to other
classes
 ...How to Create a DCD...
• avoid clutter

• if you try to model every class, complete with

attributes and methods in a single diagram it will
look like a circuit board

• impressive but impractical

• so it’s better to provide separate diagrams for each

class specification, then just show the class names
and key attributes in an overall DCD

• so it will look a lot like the domain model

 Mapping Designs to Code
• an iterative process

• very difficult to design completely on paper before building

• far quicker and easier to get started with the coding and feed
back ideas and observations

• context helps:

• as you sit down and code you’ll think of things which need to
change with the design

• attributes, methods, classes to add or remove

• types (representations) to change

• associations (and hence attributes) to add

Example: design to code
public class SalesLineItem {

private int quantity;

public SalesLineItem(ProductSpecification spec, int, qty) {...}

public Money getSubtotal() {…}
…
}

ProductSpecification
SalesLineItem
* Described-by 1 description : Text
quantity : Integer price : Money
itemID : ItemID
getSubtotal():Money

from Ch 20 Applying UML & Patterns (Larman)

Example: adding reference attributes

from Ch 20 Applying UML & Patterns (Larman)

Example: using role names

from Ch 20 Applying UML & Patterns (Larman)

 Order of Implementation
• essentially, code the classes with fewest dependencies first

• i.e. least coupled to most coupled

from Ch 20 Applying UML & Patterns (Larman)

 Error Handling
• error handling can be modelled in sequence diagrams

• using asynchronous messages and alternative flow

• but for now we’ll skip that

• however, do aim to write code which captures and handles the

exceptions listed in the use case descriptions

• expect to find many other possible errors to handle

• a good idea is to build a robust UI which prevents problems

before they arise

• for example, if you require the user to enter a 3 digit number,

then prevent other symbols and string lengths from being entered
 To conclude
• we can generate class diagrams alongside sequence diagrams

• we can use them to specify in great detail the classes, methods and attributes
which will form the design solution

• but we shouldn’t wait too long to get coding

• some coding now will speed up the analysis and design processes

• when coding:

• build the easiest, least coupled classes first

• a little time spent now forcing user actions to be legal will save a lot of
time debugging and error handling later

• avoid clutter:

• as with other diagrams, split these up if need be

References & Further Reading
• base structure and figures taken from:

• Applying UML & Patterns (Larman), Chapters 19, 20

• for good coding principles:

• Program Development in Java (Liskov & Guttag)