Please enable JavaScript.

Coggle requires JavaScript to display documents.

UML 2.5 Diagram (Structure Diagram (Class Diagram (Class diagram shows a…

- - - - 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.
    - - Object name
        
        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.
      - Link
        
        Links tend to be instances associated with associations. You can draw a link while using the lines utilized in class diagrams.
  - - - 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 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
    - - Collaboration
        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.
      - Parts
        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.
      - Port
        A port defines the interaction point between a classifier instance and its environment or between the behavior of the classifier and its internal parts.
      - Interface
        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.
      - Connector
        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
        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
      - Interface
        
        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).
      - Subsystems
        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.
      - Port
        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.
      - Relationships
        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.
        
        Association
        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.
        
        Composition
        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.
        
        Aggregation
        A kind of association that has one of its end marked shared as kind of aggregation, meaning that it has a shared aggregation
        
        Constraint
        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.
        
        Dependency
        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.
        
        Links
        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.
  - - - 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.
  - - - Stereotypes
        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.
      - Constraints
        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.
- - - - 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 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.
  - - - 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.
  - - - 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.
        
        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.
        
        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).
      - 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.
        
        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.
        
        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.
        
        Element
        
        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.
        
        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.
        
        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.