By combing UML and code automation it is possible to boost your development productivity by 1000%! My current record is creating 100,000 lines of code in just four hours. I want to pass these skills on to you.
In this post I will firstly explain how to get started with UML. I will then cover five different UML elements and how, with these five elements, you can create very powerful models.
Turning UML into code is the best way to get a major productive boast! I will include tips on the best way to use UML to do this.
In other blog posts I will then explain how to turn these models into code in more detail.
Getting started with UML Class Diagrams
The UML Class Diagrams are the most versatile part of UML because they can be converted very easily into code, thus enabling you to automate the creation of your code. This Automation is the key to massive productivity increases!
What is a Class Diagram?
A Class Diagram allows you to design all the objects and relationships between each class, using graphical design software.
This is what a Class Diagram looks like.
As you can see a Class Diagram allows you to design software such as an Invoicing Microservice which I have shown in the above example. In the diagram above you can see all the objects with their attributes and the relationships between each class/ diagram.
Key elements of a Class Diagram
There are quite a few elements to a Class Diagram but to get started you only need to understand a few of them. I will now explain these
elements .
- Classes
- Attributes
- Operations
- Generalization
- Associations
One benefit is that these elements are simple to turn into code. Other elements of the UML Class Diagram e.g. Dependency’s do not translate as easily to code.
Classes
An UML Class is very similar to a class or object in most programming languages. It can contain both Attributes (variables) and Operations (procedures).
See below for what the class lnvoiceLine looks like in UML. There are three main parts to the class which have been numbered.
The first part of the Class is the header that contains the name of that class. The second part of the Class contains all the Attributes that belong to that Class. The third part contains any Operations that belong to that Class.
Attributes
All Attributes in a UML Class diagram are contained in either a “Class” or an “Interface”.
This is a picture of an Attribute with the three main parts.
The first part the plus “+” sign shows the Visibility. A plus “+” sign indicates that the attribute is public and can been seen by everything. A minus “-” sign indicates that the attribute is private and can only be used by that specific class. The two other types of visibility are Protected “#” and Package “~” which are not used very often.
The second part contains the name of the attribute.
The third part is the data type that the attribute stores.
It is also possible to show if the attribute is derived (e.g. the values is created via some code). A “/” will be added in front of the attribute name.
Also, the Multiplicity of the attribute can be displayed. The default Multiplicity of One is not displayed.
Operations
The first part the “+” sign shows the Visibility. A “+” sign indicates that the attribute is public and can been seen by everything. A “-“ sign indicates that the attribute is private and can only be used by the class. The two other types of visibility are Protected “#” and Package “~”.
The second part contains the name of the Operation.
The third part contains the Parameters of the Operation. You can have multiple Parameters in an Operation.
The forth part is the data type that the Operations returns.
Generalization
When you need to show inheritance in UML you use a Generalization. Generalizations are very useful as most programming languages support inheritance.
This diagram shows that the Class “Employee” inherits from the Class “Person”. A Generalization is shown as the line drawn between two different Classes (or Interfaces). A Generalization line ends with an arrow that is not filled in.
Note: UML supports multiple inheritance but not all programming languages do. So I would advise not using multiple inheritance as you could design a model that cannot be turned into code!
Associations
An Association is a relationship between two classes or interfaces. Association can be used to define 0..1 0..* (* means Many in UML e.g 1 or more) 1..* and *..* relationships.
An Association is a relationship between two classes or interfaces. Association can be used to define 0..1 0..* 1..* and *..* relationships.
The diagram below shows the association between a Company and its Employees.
The easiest Associations to convert into code are the 0..* and 1..* relationships. In the C# above 0..* Company association with Employees can written as follows
public class Company
{
public List<Employees> Employees {get; set;}
}
Best Practices for Associations and Attribute Relationships
UML is extremely flexible. This means it is possible to model a relationship in different ways, all shown by the model diagram.
For example: The relationship that an Invoice has multiple invoice Lines could be displayed as an Association with a 1..* relationship.
Another way of modelling this is an Attribute called InvoiceLines which could be added to the Invoice class, the Type would be set to “InvoiceLine” and the multiplicity would be set to 1..*
Since there are multiple ways to model relationships in UML I will now show you the best practices for modeling different relationships. Following these best practices will make your Class diagrams more understandable and consistent.
The Singular Relationship
In UML this is represented as 0..1 (Zero or One) or 1..1 (One)
These two relationships are best done by adding an attribute to a class and then setting the type. This also helps keep the Model looking “cleaner” as only associations with multiple elements are shown. It is easy to get a Model with so many association lines that you cannot easily see the relationships in the Model. By using attributes for the singular relationships, it helps to make the model more understandable when viewing. Also, it is easier to then convert the model into code.
The ‘Singular to Many’ Relationship
In UML this is represented as 0..* (Zero to Many) or 1..* (One to Many)
These relationships are best displayed with an association. Then it is easy when looking at the model to see exactly which relationships have multiple elements. Also, this help when converting the model into code.
The ‘Many to Many’ Relationship
In UML this is represented as *..* Many to Many
This relationship be created using an association. In general, I would avoid using this relationship as converting these models into code can be difficult. If this relationship is required one way around it would be to create an intermediately class and map the associations to it. The below diagram is example of this.
Standard Many to Many: Hard to convert directly to code
Alternative Many to Many: Easier to convert to code
Summary
I hope this has been helpful for you. Any questions please ask. ?
To learn more about turning your models into code please follow these links…
Download SilverModel. A Model First Design tool with Code Generation.
Introduction to using Model First Design: Creating an Invoice Microservice
