The task of modeling a system using object orientation is complicated and needs a way to represent in various points of view what will be built. The Unified Modeling Language, UML, is the standard notation to use when modeling a object-oriented system. It can represent various aspects of the system using diagrams that make one or more characteristics more noticeable.There are 3 types of diagrams. The structural ones show the architecture of the system and how the system will be built. The behavioral diagrams show how the system should behave when used. The interactions diagram show how the parts of the system interact with themselves and with the user. In this article we’ll talk about the structural diagrams.As an example, I’ll show some diagrams that would represent a simple library system.Structural DiagramsClass DiagramThe class diagram is the most basic diagram in UML. It usually used to model the data handled by the system or to model the collaboration of classes to offer some cooperative service. It can also be used to show what is inside the scope of the system and what is outside it. Here’s the example for the library system.Each box represents a class, with its name in bold at the top, its attributes at the middle and its methods at the bottom.
The white arrow between two classes indicates a inheritance. That means a “is a” relationship. So, if A is in the end of the arrow with B, that means that A “is a” B and A has all the things B have plus its own. Also, A can be treated as B without problem.
The line between two classes indicates that these two classes are associated in some way, and the numbers on the links with the classes indicates the multiplicity of this association. Using the above as an example, the relationship between Shelf and Media says that one shelf can have various media associated with it, and that a Media should be in only one Shelf.
There are other types of associations and relationships between classes, but this is the most basic thing you need to know to read and write Class diagrams.
Object DiagramThis diagram is a realization of the Class Diagram in a given time. It is used as a test for the class diagram, as it can show inconsistencies in the other diagram.Packages DiagramThis diagram is a higher vision of the class diagram, as it specifies how packages (basically a group of classes that solve the same problem or work closely together) interact with themselves. It shows the system in a higher view. Our system could be divided in packages representing the user authentication system, the media renting system and the administrative part of the library (adding books, making orders for new books, etc). You can put the packages directly on the class diagram if you want, as this can make some relationships clearer.Components DiagramA component is a class or group of classes that exposes some interface to some services and that can be replaced by another with the same interface without loss of funcionality. In a simpler way, it’s some code that is pluggable in the system and can be replaced by another that looks like it (like Lego blocks). The components diagram shows the interaction between the the components to form more complex components and or to form the software system. In our library system, the authentication will be provided by a component (could be OpenID).Deployment DiagramThis diagram shows the physical resources needed to put the system in production and how this resources are combined. In this diagram every node is a computer that publishes or interacts with some service and the interaction between this nodes makes the system work. This diagram is only meaningful when your system has a complicated deployment. Simple cases like our library system are not a good example of a deployment diagram.