UML Diagrams

mywbut.com UML Diagrams Overview UML was designed to be the distillation of best practices in software development. To accomplish this ambitious goal, UML provides an extensive set of diagramming tools. Because UML is such a big subject and the diagramming tools are so diverse I thought it would be helpful to give you an overview of the diagrams themselves. This chapter presents some samples of each diagram with a brief introduction describing the purpose and benefits of each diagram. As a kind of roadmap I'll use the UML groupings that divide the diagrams into packages based on their roles in the Model Management, Structural, and Behavioral aspects of system design. Model Management diagrams include Packages, which are used to represent Subsystems, Models, and more. Structural diagrams include the Class diagram, Object diagram, Composite Structure diagram, Component diagram, Deployment diagram, and the Combined Component and Deployment diagram. Behavioral diagrams include the Use Case diagram, Activity diagram, Interaction diagrams, State Machine diagram, and Protocol State Machine diagram. UML Diagrams and Work Products Each diagram reveals a unique yet overlapping view of a system. That sounds a bit strange. How can a diagram be unique yet overlap other diagrams? The uniqueness comes from the different perspective taken by each diagram. The overlap comes from the fact that all of the diagrams are looking at the same problem. The big question that usually crops up about now is, "Why do I have to use all these diagrams? Joe and Susan have always just drawn Class diagrams." This question is valid. For small, simple projects you may not need to create all these diagrams. But I suspect that one reason you're reading this book is that you don't work on small projects, and the projects you do work on get pretty complicated. When the projects become large and complicated, you often move from one piece of the project to another in rapid succession. Coming back to something you worked on a few days ago often means hours of getting your head back into a pile of notes and/or mountains of code, much of it not your own. It also means that there is no realistic way to know how right you are until you build enough code to run tests. By then you have used up a large part of the project schedule, and if you find problems it is difficult to justify the extra time to do a lot of rewriting. If only we got paid by the hour…. 1 mywbut.com So how does a diverse set of diagrams help? Consider a common example from everyday life. Suppose you're in a car accident at an intersection. Someone runs a red light and broadsides your car. A police officer shows up, walks over to a witness, and takes her story. She says that you ran the red light, not the other person. Then the officer leaves assuming he has the truth. How do you feel? Outraged, I imagine. But the officer talked to a "client" and captured the facts just like we typically gather requirements from our clients. So what's the problem? The problem is that the officer did nothing to verify his facts. He should have asked the other witnesses for their perspectives. After he got information from a variety of sources he would have a set of accounts looking at the same set of facts but from different perspectives. If he compared the stories, he would discover two things. First, some of the information from different testimonies will agree. He could reasonably assume that those portions of the accounts are true. Second, the portions that didn't line up could not be trusted until he could find corroborating evidence. Dealing with many different views of a software or business problem works the same. Each diagram describes the problem in a different way, just like different witnesses describe an incident. The diagrams will overlap because they describe the same body of facts. If they agree where they overlap, you can relax knowing you've probably got it right. If they don't agree, then you have some homework to do to reconcile the differences. Now here are the two really-great benefits: . When the viewpoints disagree, you've pinpointed where you need to invest your effort. When all the viewpoints agree, you know you're done. How many times have you sat in a status meeting trying to come up with a way to describe how much progress you've made and what remains to be done? Often we get stuck "guesstimating" a percentage of completion. The question is, "a percentage of what?" Instead, wouldn't it be nice to be able to say something like, "We have 28 business requirements so far. Seventeen have been completely reviewed and approved with clients. The clients tell us that we've identified all of the critical business requirements but there are maybe five more low-priority requirements that we need to document. Of the 17, we have fully modeled 12. Based on the time we have invested so far, we estimate another week to finish the remaining five, and three weeks to finish the other eleven." Even better, the more practice you get and the more metrics you keep on each modeling effort, the more reliable your estimates become. Structural Diagrams Structural diagrams illustrate the static features of a model. Static features include classes and association, objects and links, and collaborations. These static features provide the framework in which the dynamic elements of the model execute. For example, a Class defines the behaviors that types of objects can provide. An association defines the type of relationship that objects can participate in. A 2 mywbut.com Deployment diagram models pieces of hardware (and people) that can perform work. Components define pieces of software and procedures that need to be deployed to processors. The structural diagrams function much like a blueprint for building a house or a piece of equipment. They show the parts and how they can be assembled, but they cannot show how the finished product will behave. Class diagram The Class diagram is at the heart of the object modeling process. It models the definitions of resources essential to the proper operation of the system. All of the other modeling diagrams discover information about these resources (such as attribute values, state, and constraints on behavior) that ultimately must make its way onto the Class diagram. The Class diagram is the source for code generation (converting a model to code) and the target for reverse engineering (converting code to a model). The Class diagram models the resources used to build and operate the system. Resources represent people, materials, information, and behaviors. Class diagrams model each resource in terms of its structure, relationships, and behaviors. The notation is surprisingly simple. Figure below models a class with the three predefined compartments found in nearly every class: name, attribute, and operations. Figure: A class with the three predefined compartments. But I said that the Class diagram models resources and relationships between resources. Next figure models two classes and the relationship between them. In the theater system a venue manager authorizes agents to sell tickets. Over time an agent may be authorized by any number of different venue managers. The model defines how many objects may participate in the relationship and may even set rules defining which objects can participate. 3 mywbut.com Figure: A Class diagram with a relationship called "authorizes." You will likely have a number of Class diagrams on a project. Each will focus on the resources for a specific subject area. This is one example of where Package diagrams come into play. A Class diagram for the resources required to manage a venue can be placed in one package. A Class diagram for the resources to manage agents can be in another package. Because all the diagram elements for a project are stored in the same repository, regardless of package, you can reference any of these resources on any diagram merely by using the proper naming convention using the import concept . Class diagrams are valuable because they . Define the essential resources of a system. Define relationships between resources. Generate code. Model code (reverse engineering). Provide a focus for all the other diagrams. Object diagram While the Class diagram models the definitions of resources, the Object diagram models facts or examples. Above figure shows a Class diagram that defines venue managers, agents, and their relationship. Figure given below presents an Object diagram that models one specific agent, Mike, and two specific venue managers, Susan and Bill, and the relationships between the three people. In most modeling tools you draw an Object diagram in the same facility/canvas as the Class diagram. 4 mywbut.com Figure: Object diagram. An Object diagram is most useful in the early phases of a project for modeling examples. Examples often can uncover the rules that need to be part of the definitions of the resources and their relationships. Later in the project the Object diagram is useful for modeling test cases to see whether the Class diagram is correct and complete. Object diagrams are valuable because they . Support the investigation of requirements by modeling examples from the problem domain (that may later be used as test cases). Model test cases to validate the Class diagram. Composite Structure diagram The Composite Structure diagram is new in UML 2.0. It represents the functionality formerly described using Composite Context diagrams and collaborations (not the same as Collaboration diagrams). The concept of the Composite Structure diagram is to visually represent the parts of a class, component, or collaboration, including the interaction points (called ports) used to access features of the structure.

Load more