In order to try and explain these diagrams, I will give their categorization and then an explanation of each diagram:
Structure diagrams emphasize what things must be in the system being modeled. This is a type of diagram that depicts the elements of a specification that are irrespective of time. This includes class, composite structure, component, deployment, object, and package diagrams.
* Class diagram: Shows a collection of static model elements such as classes and types, their contents, and their relationships. Class diagrams identify the class structure of a system, including the properties and methods of each class. Also depicted are the various relationships that can exist between classes, such as an inheritance relationship. The Class diagram is one of the most widely used diagrams from the UML specification.
* Component diagram: A component diagram depicts how a software system is split up into physical components and shows the dependencies among these components. Component diagrams describe the organization of physical software components, including source code, run-time (binary) code, and executables. Physical components could be, for example, files, headers, link libraries, modules, executables, or packages. Component diagrams can be used to model and document any system’s architecture.
* Composite structure diagram: Depicts the internal structure of a classifier (such as a class, component, or use case), including the interaction points of the classifier to other parts of the system. A composite structure diagram shows the internal structure of a class and the collaborations that this structure makes possible. This can include internal parts, ports through which the parts interact with each other or through which instances of the class interact with the parts and with the outside world, and connectors between parts or ports. A composite structure is a set of interconnected elements that collaborate at runtime to achieve some purpose. Each element has some defined role in the collaboration
* Deployment diagram: Shows the execution architecture of systems. This includes nodes, either hardware or software execution environments, as well as the middleware connecting them. Deployment diagrams are another model in the implementation diagram category. The Deployment diagram models the hardware used in implementing a system and the association between those hardware components. Components can also be shown on a Deployment diagram to show the location of their deployment. Deployment diagrams can also be used early on in the design phase to document the physical architecture of a system.
* Object diagram: Object diagrams model instances of classes. This type of diagram is used to describe the system at a particular point in time. Using this technique, you can validating the class diagram and it’s multiplicity rules with real-world data, and record test scenarios. From a notation standpoint, Object diagrams borrow elements from Class diagrams. Object diagrams describe the static structure of a system at a particular time. They can be used to test class diagrams for accuracy. An object diagram is a diagram that shows a complete or partial view of the structure of a modeled system at a specific time. This snapshot focuses on some particular set of object instances and attributes, and the links between the instances. A correlated set of object diagrams provides insight into how an arbitrary view of a system is expected to evolve over time. Object diagrams are more concrete than class diagrams, and are often used to provide examples, or act as test cases for the class diagrams. Only those aspects of a model that are of current interest need be shown on an object diagram.
* Package diagram: Package diagrams are a subset of class diagrams, but developers sometimes treat them as a separate technique. Package diagrams organize elements of a system into related groups to minimize dependencies between packages. The diagram shows how model elements are organized into packages as well as the dependencies between packages. A package diagram depicts how a system is split up into logical groupings by showing the dependencies among these groupings. As a package is typically thought of as a directory, package diagrams provide a logical hierarchical decomposition of a system. Packages are usually organized to maximize internal coherence within each package and to minimize external coupling among packages. With these guidelines in place, the packages are good management elements. Each package can be assigned to an individual or team, and the dependencies among them indicate the required development order.
Behavior diagrams emphasize what must happen in the system being modeled. This is a type of diagram that depicts behavioral features of a system or business process. This includes activity, state machine, and use case diagrams as well as the four interaction diagrams.
* Activity diagram: Activity diagrams illustrate the dynamic nature of a system by modeling the flow of control from activity to activity. An activity represents an operation on some class in the system that results in a change in the state of the system. Typically, activity diagrams are used to model workflow or business processes and internal operation. The Activity Diagram depicts high-level business processes, including data flow, or to model the logic of complex logic within a system. Activity diagrams are used to document workflows in a system, from the business level down to the operational level. When looking at an Activity diagram, you’ll notice elements from State diagrams. In fact, the Activity diagram is a variation of the state diagram where the “states” represent operations, and the transitions represent the activities that happen when the operation is complete. The general purpose of Activity diagrams is to focus on flows driven by internal processing vs. external events.
* State Machine diagram: The State Machine diagram describes the states an object or interaction may be in, as well as the transitions between states. Formerly referred to as a state diagram, state chart diagram, or a state-transition diagram. State diagrams are used to graphically represent finite state machines. State transition tables are another possible representation.
* Use case diagram: Use case diagrams model the functionality of system using actors and use cases. Shows use cases, actors, and their interrelationships. Use Case diagrams identify the functionality provided by the system (use cases), the users who interact with the system (actors), and the association between the users and the functionality. Use Cases are used in the Analysis phase of software development to articulate the high-level requirements of the system. A use case diagram is a type of behavioral diagram defined by the Unified Modeling Language (UML). Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals—represented as use cases—and any dependencies between those use cases.
Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled. This is a subset of behavior diagrams which emphasize object interactions. This includes communication, interaction overview, sequence, and timing diagrams.
* Communication diagram: A communication diagram shows instances of classes, their interrelationships, and the message flow between them. Communication diagrams typically focus on the structural organization of objects that send and receive messages. Formerly called a Collaboration Diagram. Like the other Behavioral diagrams, communication diagrams model the interactions between objects. This type of diagram is a cross between an object diagram and a sequence diagram. Unlike the Sequence diagram, which models the interaction in a column and row type format, the communication diagram uses the free-form arrangement of objects as found in an Object diagram. This makes it easier to see all interactions involving a particular object.
* Interaction overview diagram (UML 2.0): An interaction overview diagram is a variant of an activity diagram which overviews the control flow within a system or business process. Each node/activity within the diagram can represent another interaction diagram.
* Sequence diagram: Sequence diagrams describe interactions among classes in terms of an exchange of messages over time. Sequence diagrams Model the sequential logic, in effect the time ordering of messages between classifiers. Sequence diagrams document the interactions between classes to achieve a result, such as a use case. Because UML is designed for object-oriented programming, these communications between classes are known as messages. The Sequence diagram lists objects horizontally, and time vertically, and models these messages over time. A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner.
* UML Timing Diagram (UML 2.0): The UML timing diagram depicts the change in state or condition of a classifier instance or role over time. Typically used to show the change in state of an object over time in response to external events. Timing diagrams (UML 2.0) are a specific type of interaction diagram, where the focus is on timing constraints. Timing diagrams are used to explore the behaviors of objects throughout a given period of time. A timing diagram is a special form of a sequence diagram. The differences between timing diagram and sequence diagram are the axes are reversed so that the time is increased from left to right and the lifelines are shown in separate compartments arranged vertically.
Recent Comments