UML 2.5 Diagram (Structure Diagram (Class Diagram (Class diagram shows a…
UML 2.5 Diagram
Structure Diagram
Class diagram shows a collection of classes, interfaces, associations, collaborations, and constraints. It is also known as a structural diagram.
Shows structure of the designed system, subsystem or component as related classes and interfaces, with their features, constraints and relationships - associations, generalizations, dependencies, etc.
Class diagram is a static diagram. It represents the static view of an application. Class diagram is not only used for visualizing, describing, and documenting different aspects of a system but also for constructing executable code of the software application.
class, interface, feature, constraint, association, generalization, dependency
Object Diagram
An object diagram shows relation between the instantiated classes and the defined class, and the relation between these objects in the system. They are be useful to explain smaller portions of your system, when your system class diagram is very complex, and also sometimes modeling recursive relationship in diagram.
During the analysis phase of a project, you might create a class diagram to describe the structure of a system and then create a set of object diagrams as test cases to verify the accuracy and completeness of the class diagram
Before you create a class diagram, you might create an object diagram to discover facts about specific model elements and their links, or to illustrate specific examples of the classifiers that are required.
Every object is actually symbolized like a rectangle, that offers the name from the object and its class underlined as well as divided with a colon.
Object Attribute
Similar to classes, you are able to list object attributes inside a separate compartment. However, unlike classes, object attributes should have values assigned for them.
Links tend to be instances associated with associations. You can draw a link while using the lines utilized in class diagrams.
Package Diagram
Package diagram, a kind of structural diagram, shows the arrangement and organization of model elements in middle to large scale project. Package diagram can show both structure and dependencies between sub-systems or modules, showing different views of a system, for example, as multi-layered (aka multi-tiered) application - multi-layered application model.
Package diagrams are used to structure high level system elements. Packages are used for organizing large system which contains diagrams, documents and other key deliverables.
Packages can be represented by the notations with some examples shown below:
Dependency notations
<<import>> - one package imports the functionality of other package
<<access>> - one package requires help from functions of other package
Composite Structure Diagram
A composite structure diagram is a UML structural diagram that contains classes, interfaces, packages, and their relationships, and that provides a logical view of all, or part of a software system. It shows the internal structure (including parts and connectors) of a structured classifier or collaboration.
Composite Structure Diagrams allow the users to "Peek Inside" an object to see exactly what it is composed of.
The internal actions of a class, including the relationships of nested classes, can be detailed.
Objects are shown to be defined as a composition of other classified objects
A collaboration describes a structure of collaborating parts (roles). A collaboration is attached to an operation or a classifier through a Collaboration Use. You use a collaboration when you want to define only the roles and connections that are required to accomplish a specific goal of the collaboration.
A port defines the interaction point between a classifier instance and its environment or between the behavior of the classifier and its internal parts.
Composite Structure diagram supports the ball-and-socket notation for the provided and required interfaces. Interfaces can be shown or hidden in the diagram as needed.
A line that represents a relationship in a model. When you model the internal structure of a classifier, you can use a connector to indicate a link between two or more instances of a part or a port. The connector defines the relationship between the objects or instances that are bound to roles in the same structured classifier and it identifies the communication between those roles. The product automatically specifies the kind of connector to create.
Component Diagram
Component diagrams are used in modeling the physical aspects of object-oriented systems that are used for visualizing, specifying, and documenting component-based systems and also for constructing executable systems through forward and reverse engineering. Component diagrams are essentially class diagrams that focus on a system's components that often used to model the static implementation view of a system.
This type of diagrams is used for Component-Based Development (CBD), to describe systems with Service-Oriented Architecture (SOA).
A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. In UML 2, a component is drawn as a rectangle with optional compartments stacked vertically
Provided interface symbols with a complete circle at their end represent an interface that the component provides - this "lollipop" symbol is shorthand for a realization relationship of an interface classifier
Required Interface symbols with only a half circle at their end (a.k.a. sockets) represent an interface that the component requires (in both cases, the interface's name is placed near the interface symbol itself).
The subsystem classifier is a specialized version of a component classifier. Because of this, the subsystem notation element inherits all the same rules as the component notation element. The only difference is that a subsystem notation element has the keyword of subsystem instead of component.
Ports are represented using a square along the edge of the system or a component. A port is often used to help expose required and provided interfaces of a component.
Graphically, a component diagram is a collection of vertices and arcs and commonly contain components, interfaces and dependency, aggregation, constraint, generalization, association, and realization relationships. It may also contain notes and constraints.
An association specifies a semantic relationship that can occur between typed instances.It has at least two ends represented by properties, each of which is connected to the type of the end. More than one end of the association may have the same type.
Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time.If a composite is deleted, all of its parts are normally deleted with it.
A kind of association that has one of its end marked shared as kind of aggregation, meaning that it has a shared aggregation
A condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element.
A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation.
A generalization is a taxonomic relationship between a more general classifier and a more specific classifier.Each instance of the specific classifier is also an indirect instance of the general classifier.
Deployment Diagram
A UML deployment diagram is a diagram that shows the configuration of run time processing nodes and the components that live on them. Deployment diagrams is a kind of structure diagram used in modeling the physical aspects of an object-oriented system. They are often be used to model the static deployment view of a system (topology of the hardware).
When to use
What existing systems will the newly added system need to interact or integrate with?
How robust does system need to be (e.g., redundant hardware in case of a system failure)?
What and who will connect to or interact with system, and how will they do it
What middleware, including the operating system and communications approaches and protocols, will system use?
What hardware and software will users directly interact with (PCs, network computers, browsers, etc.)?
How will you monitor the system once deployed?
How secure does the system needs to be (needs a firewall, physically secure hardware, etc.)?
They show the structure of the run-time system
They can be used to plan the architecture of a system.
They model physical hardware elements and the communication paths between them
They are also useful for Document the deployment of software components or nodes
They capture the hardware that will be used to implement the system and the links between different items of hardware.
Profile Diagram
Profile diagram, a kind of structural diagram in the Unified Modeling Language (UML), provides a generic extension mechanism for customizing UML models for particular domains and platforms. Extension mechanisms allow refining standard semantics in strictly additive manner, preventing them from contradicting standard semantics.
Auxiliary UML diagram which allows to define custom stereotypes, tagged values, and constraints as a lightweight extension mechanism to the UML standard. Profiles allow to adapt the UML metamodel for different platforms (such as J2EE or .NET), or domains (such as real-time or business process modeling).
Stereotypes allow you to increase vocabulary of UML. You can add, create new model elements, derived from existing ones but that have specific properties that are suitable to your problem domain. Stereotypes are used to introduce new building blocks that speak the language of your domain and look primitive. It allows you to introduce new graphical symbols.
Tagged Values
Tagged values are used to extend the properties of UML so that you can add additional information in the specification of a model element. It allows you to specify keyword value pairs of a model where keywords are the attributes. Tagged values are graphically rendered as string enclose in brackets.
They are the properties for specifying semantics or conditions that must be held true at all the time. It allows you to extend the semantics of UML building block by adding new protocols. Graphically a constraint is rendered as string enclose in brackets placed near associated element.
Behavior Diagram
Use Case Diagram
A use case diagram is a graphic depiction of the interactions among the elements of a system.
Purpose: Describes a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors) to provide some observable and valuable results to the actors or other stakeholders of the systems.
Use cases allow to capture requirements of systems under design or consideration, describe functionality provided by those systems, and determine the requirements the systems pose on their environment
An actor is behaviored classifier which specifies a role played by an external entity that interacts with the subject (e.g., by exchanging signals and data), a human user of the designed system, some other system or hardware using services of the subject.
A subject of a use case defines and represents boundaries of a business, software system, physical system or device, subsystem, component or even single class in relation to the requirements gathering and analysis.
Extend is a directed relationship that specifies how and when the behavior defined in usually supplementary (optional) extending use case can be inserted into the behavior defined in the extended use case.
Use case include is a directed relationship between two use cases which is used to show that behavior of the included use case (the addition) is inserted into the behavior of the including (the base) use case.
Association Between Use Cases
Activity diagram
Activity diagram is another important diagram in UML to describe the dynamic aspects of the system. Activity diagram is basically a flowchart to represent the flow from one activity to another activity. The activity can be described as an operation of the system.
Purpose: Shows sequence and conditions for coordinating lower-level behaviors, rather than which classifiers own those behaviors. These are commonly called control flow and object flow models.
Where to use:
Modeling work flow by using activities.
Modeling business requirements.
High level understanding of the system's functionalities.
Investigating business requirements at a later stage.
Activity is a parameterized behavior represented as coordinated flow of actions.
Activity contains activity nodes which could be:Action, Object Control.
Activities may contain actions of various kinds:
Occurrences of primitive functions, such as arithmetic functions.
Invocations of behavior, such as activities.
Communication actions, such as sending of signals.
Manipulations of objects, such as reading or writing attributes or associations.
An activity partition is activity group for actions that have some common characteristic.
Partitions often correspond to organizational units or business actors in a business model.
Partitions provide a constrained view on the behaviors invoked in activities. Constraints could be selected according to the type of the element that the partition represents. The following constraints are normative (standard) in UML 2.4: classifier, instance, part, attribute and value
Action is a named element which represents a single atomic step within activity, i.e. that is not further decomposed within the activity. Activity represents a behavior that is composed of individual elements that are actions.
An object node is an abstract activity node that is used to define object flows in an activity. Object nodes include pin, central buffer, parameter, expansion nodes.
Control node is an activity node used to coordinate the flows between other nodes. It includes: initial node, flow final node, activity final node ,decision node ,merge node ,fork node ,join node.
Activity Edge is an abstract class for the directed connections along which tokens or data objects flow between activity nodes. It includes control edges and object flow edges. The source and target of an edge must be in the same activity as the edge.
State machine diagram
State machine diagram is a behavior diagram which shows discrete behavior of a part of designed system through finite state transitions. State machine diagrams can also be used to express the usage protocol of part of a system
Purpose: Used for modeling discrete behavior through finite state transitions. In addition to expressing the behavior of a part of the system, state machines can also be used to express the usage protocol of part of a system. These two kinds of state machines are referred to as behavioral state machines and protocol state machines**.
Behavioral state machines: Shows discrete behavior of a part of designed system through finite state transitions.
Protocol state machines : Shows usage protocol or a lifecycle of some classifier, e.g. which operations of the classifier may be called in each state of the classifier, under which specific conditions, and satisfying some optional postconditions after the classifier transitions to a target state.
Interraction diagram
Purpose: Interaction diagrams include several different types of diagrams:
Sequence diagram
Purpose: Most common kind of interaction diagrams which focuses on the message interchange between lifelines (objects).
Element:
Lifeline is a named element which represents an individual participant in the interaction. While parts and structural features may have multiplicity greater than 1, lifelines represent only one interacting entity.
Execution (full name - execution specification, informally called activation) is interaction fragment which represents a period in the participant's lifetime when it is executing a unit of behavior or action within the lifeline, sending a signal to another participant, waiting for a reply message from another participant.
Message is a named element that defines one specific kind of communication between lifelines of an interaction. The message specifies not only the kind of communication, but also the sender and the receiver. Sender and receiver are normally two occurrence specifications (points at the ends of messages).
Combined fragment is an interaction fragment which defines a combination (expression) of interaction fragments. A combined fragment is defined by an interaction operator and corresponding interaction operands. Through the use of combined fragments the user will be able to describe a number of traces in a compact and concise manner.
Interaction use is an interaction fragment which allows to use (or call) another interaction. Large and complex sequence diagrams could be simplified with interaction uses. It is also common to reuse some interaction between several other interactions.
A state invariant is an interaction fragment which represents a runtime constraint on the participants of the interaction. It may be used to specify different kinds of constraints, such as values of attributes or variables, internal or external states, etc.
Destruction occurrence is a message occurrence which represents the destruction of the instance described by the lifeline. It may result in the subsequent destruction of other objects that this object owns by composition. No other occurrence may appear below the destruction event on a given lifeline.
Communication diagram
Purpose: Focuses on the interaction between lifelines where the architecture of the internal structure and how this corresponds with the message passing is central. The sequencing of messages is given through a sequence numbering scheme.
Timing diagram
Purpose: Shows interactions when a primary purpose of the diagram is to reason about time. Timing diagrams focus on conditions changing within and among lifelines along a linear time axis.
State or Condition Timeline
Timing diagram could show states of the participating classifier or attribute, or some testable conditions, such as a discrete or enumerable value of an attribute.
UML also allows the state/condition dimension be continuous. It could be used in scenarios where entities undergo continuous state changes, such as temperature or density.
Destruction occurrence is a message occurrence which represents the destruction of the instance described by the lifeline. It may result in the subsequent destruction of other objects that this object owns by composition. No other occurrence may appear after the destruction event on a given lifeline.
Duration constraint is an interval constraint that refers to a duration interval. The duration interval is duration used to determine whether the constraint is satisfied.
Time constraint is an interval constraint that refers to a time interval. The time interval is time expression used to determine whether the constraint is satisfied.
Interaction overview diagram
Purpose: Defines interactions through a variant of activity diagrams in a way that promotes overview of the control flow. Interaction overview diagrams focus on the overview of the flow of control where the nodes are interactions or interaction uses. The lifelines and the messages do not appear at this overview level.
Initial node is a control node at which flow starts when the activity is invoked.
Flow final node is a control final node that terminates a flow. It destroys all tokens that arrive at it but has no effect on other flows in the activity. Flow final was introduced in UML 2.0.
Activity final node is a control final node that stops all flows in an activity. Activity final was introduced in UML 2.0.
Decision node is a control node that accepts tokens on one or two incoming edges and selects one outgoing edge from one or more outgoing flows. Decision nodes were introduced in UML to support conditionals in activities.
Merge node is a control node that brings together multiple incoming alternate flows to accept single outgoing flow. There is no joining of tokens. Merge should not be used to synchronize concurrent flows.
Fork node is a control node that has one incoming edge and multiple outgoing edges and is used to split incoming flow into multiple concurrent flows. Fork nodes are introduced to support parallelism in activities. As compared to UML 1.5, UML 2.0 activity forks model unrestricted parallelism.
Join node is a control node that has multiple incoming edges and one outgoing edge and is used to synchronize incoming concurrent flows. Join nodes are introduced to support parallelism in activities.
An interaction diagram of any kind may appear inline as an invocation action. The inline interaction diagrams may be either anonymous or named.
An interaction use may appear as an invocation action.
To capture the dynamic behaviour of a system.
To describe the message flow in the system.
To describe the structural organization of the objects.
To describe the interaction among objects.