Types of UML models - Unified Modeling Language (UML) Tutorial

- [Instructor] UML notations are grouped under three different types of diagrams. The first is the set of those diagrams that model the structure of the system, and the second is the set that models the behavior of the system. Each of these two has several types of diagrams showing different aspects of the system. The third set comes under the behavior category and models the interaction within and outside the system. All these three types put together make 13 types of UML diagrams. The three categories of diagrams help us model different aspects of the system. Structural diagrams help us see the static view of the system in terms of its components. For example, class diagram is a structural diagram because it shows a static view of all the classes that will be created over the system. The behavioral diagrams show how the system and its components behave over time. For example, an activity diagram is a behavioral diagram that showcases the system's logical workflow. And interaction diagrams show interaction among the components of the systems identified in the structural diagram. For example, communication among the classes of a system. Interaction diagrams can also depict how the system as a whole interacts with its external entities. While there are so many types of diagrams, and their notations and complexity can get very intricate, it is important to consider a few tips. First, you should model selectively. Remember that you're modeling to analyze, communicate, test, and document. Modeling is just a means to an end and not the end in itself. So, you should selectively identify which types of diagrams you really need to create, and you do not and should not draw all 13 diagrams as it is just an overkill. Second, model collaboratively. Models are thinking and communication tools. Create them and share them with your team to have a common understanding and agreement. Third, model smartly. Models are knowledge assets and with the entire team invest its time and expertise. Keeping them handy and updated for future reference as your software design evolves is a great way to benefit from that investment. Having said that, it is easy to lose ourselves in the minutia of various diagrams. Do not spend too much time making them look perfect and pretty. Start on a white board or a piece of paper and keep it rough and fluid. Focus on what you are modeling and not the model itself. Once you have some basic semblance of the model, take a pick and go ahead with its implementation. As you will go through iterations of design and implementation, your design will begin to solidify and that rough sketch will begin to stabilize. That then will be a good time to use a tool to capture the final design for future reference. But which tool? Well, that is what we will discuss next.