design class diagrams

Design Class Diagrams

Monday, 22 October 12

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

1

Captures

Sale

DateisComplete : Booleantime

addLineItem(…)…

Register

1 makeLineItem()

Three section box Navigability

methods; parameters not specified Type information

from Ch 19 Applying UML & Patterns (Larman 2004)


Domain versus Design


1Captures

SaleDateisComplete : BooleantimeaddLineItem(…)

…

Register

1

makeLineItem()

Captures

Sale

DateisComplete : Booleantime

Register

1Domain Model

Design Model

*


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

Store

ProductCatalog

SalesLineItem

quantity

Sale

Payment

addressname date

isCompletetime

amountquantity

ProductSpecificationdescriptionpriceitemID


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




• 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



...Example expanded




• 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



• 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


1

ProductSpecification

description : Textprice : MoneyitemID : ItemID

SalesLineItem

quantity : Integer

getSubtotal():Money

* Described-by

public class SalesLineItem {

private int quantity;

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

}


Example: adding reference attributes



Example: using role names



Order of Implementation


• essentially, code the classes with fewest dependencies first

• i.e. least coupled to most coupled


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 2004), Chapters 19, 20

• for good coding principles:

• Program Development in Java (Liskov & Guttag)


design class diagrams

Documents

uml patterns larman

visibilities methods

methods typesfrom ch

classes attributesfrom

convention attributes

associations attributes

methods public

new classes