Object-Oriented concepts, visual modeling with UML: UML Overview. In this unit, we will expeditiously glance the various types of diagrams provided by UML. Think of this as a survey. This is not a UML course, an in depth UML course by itself would be substantially larger than this entire course. What we will cover in a bit more depth after this survey will be the UML class diagram, because that is the one diagram most commonly used in learning quest courses. UML can be divided into two classes of diagrams. . Structural diagrams describe the static structure of parts of our system, hence the name structural diagrams. These include the class, object, component, and similar diagrams, they describe the structure of those elements and their relationships. Behavioral diagrams on the other hand describe dynamic or run-time aspects of our system. In other words, how does our system behave? These include Use Case, Activity and State Machine diagrams, as well as a whole suite of interaction diagrams. This is a classification hierarchy of diagrams, we will now do a fast survey of many of them. The class diagram shows the structure and content of classes including the class's name, it's data, and its methods. The diagram also shows inheritance and aggregation relationships. This is arguably the most to used diagram, and is the one diagram that we'll cover in any sort of detail, and that will be in our next lesson. But for now, this is what class diagrams look like. Object diagrams show relationships between instances, it can be used to model objects very early on in system development, basically acting as UML's version of CRC cards. Later on, we'd use class diagrams and interaction diagrams. Package diagrams help show relationships between groups of classes that have been organized into packages, they can be used to show dependency relationships at that high level. Deployment diagrams helps devOps and network architects understand the overall topology and deployment requirements. Component diagrams can be thought of as service diagrams given our modern notions are service oriented architectures. Each component or service, exposes its behavior over connectable interface, this diagram tells us what services we have and how they are interconnected. The composite structure diagram allows us to take the idea of interacting services to a higher level of composition. It could also be used with complex classes by allowing us to collapse complex portions, making it easier to see the overall concept, avoiding the "Can't see the forest for the trees" problem. Use Cases are a favorite of business analysts, and help us to understand the various sorts of interactions that a system needs to support. Here we see what sorts of Use Cases need to be supported by the online order system and the various actors involved. In this example, we have customer, shipping clerk, and online order system. Activity diagrams are like flowcharts, showing a sequences of decisions and activities required to perform a task, and the pass through them. Activity diagrams can be used in various places, they can document the detailed steps for Use Case scenario, they can document the activities of a workflow, although this is an area where they would overlap with a more powerful Business Process Model and Notation, BPMN, which is also maintained by the object management group. BPMN is the de facto standard for Business Process Modeling. We could use activity diagrams to document complex logic in a method or any other area where we want to model sequences of decisions and activities including support for concurrent operation. Activity diagrams use various symbols as shown here. Here's an example of an activity diagram. We start with receiving an order, then we start parallel paths. On one path, we fill in order and then make a decision as to how to ship it. Then we ship the order and wait for the other path to complete. Meanwhile, we send an invoice and wait to receive payment. When both paths are complete, we can close the order and terminate the activity. Some processes lend themselves best to modeling with a finite state machine. Finite state machines have a set of states and a set of transitions from one state to another. Transitions are triggered by some event, and there can be both guards and activities on each transition. UML state diagrams are rich enough to allow us to consolidate the constellation of states into a single composite or super-state. The purpose for that is to help manage visual complexity by reducing a group of states into a single visual component. UML also supports concurrent states, where more than one state can be active at a time. This is not something that you would use universally. But having been a computer science major, I am a fan of finite state automata in the right situations. Here's an example of a finite state machine diagram. It shows four possible states for a library book and transitions that can take place between them. For example, a book that is on hold could go to checked out, available or available hold. Contemplation of this semantics represented by this example diagram is left for another day. There are a number of behavioral diagrams known as interaction diagrams, including sequence, communication, interaction overview and timing diagram. Sequence diagrams are used to show a time ordered sequence of messages between objects. Objects are represented by boxes at the top of the diagram. Vertical lines drop down from those boxes representing those objects across time, and horizontal lines between those vertical lines represent messages between those objects at those relative points in time. This documents what objects are sending, which messages do alone in what order to accomplish a task? Here are the symbols used in sequence diagrams. Here is a sample sequence diagram. This student starts by sending a create schedule message to a registration form instance. The registration form sends a request course offerings message to a registration controller, which sends a get course offerings message to a course catalog. The length of the little vertical boxes that start with message we see on the timeline, are the relative amount of time taken for that operation before it returns to the sender. Little loops that you see with display course offerings and display blank schedule, are representing the fact that those are messages sent from registration form to itself. You can also see that this is a very concise way of communicating which objects are involved in a process and the sequence of methods that need to be invoked in order to accomplish that hass. Communication diagrams show the same information as sequence diagrams, but are rendered differently. They're generally used earlier in the development life cycle. As with sequence diagrams, they still show the relationships between the collaborating objects. But although the information is present in the form of numeric labels, they don't as readily visualize the sequencing of messages. Here is a communication diagram intended to match the earlier sequence diagram. The relationship between the objects should be clear. But the sequencing is not as apparent despite being present. It has to be teased out of the numeric labels. Interaction overview diagrams, try to show a high level consolidated view of information in both activity and interaction diagrams. The flowchart aspect illustrates the high level order of execution. But notice that the high level activities of view catalog register for course and pay bill all have references that one could follow to their details. Timing diagrams are used to show how a state or value might change over time. These are helpful for people working on embedded systems, especially hardware control. That is the end of our UML survey. In our next lesson, we'll come back and spend more time with the UML class diagram.
