Beyond the Basics of Sequence Diagrams - Part 2

We wrap up the week with where we left off with Sequence Diagrams and a look into more advanced elements. Today we will concentrate on the use of Gates in Sequence Diagrams.

Gates

The previous post illustrated how to reference another sequence diagram via sending across data through parameters and also return values. Yet, there’s another way to send across data between two sequence diagrams. Gates could be regarded as being a simple way to model the passing of data between a sequence diagram and its context. A gate is a message that is highlighted with one end connected to the sequence diagram’s frame’s edge and the other end connected to a lifeline. A reworking of Figure 1  (from Part 1 of this series) using gates can be seen in the following diagram.

 

Figure 2 (from Part 1 of this series) with the utilization of gates would look like what is shown below.

 

Figure 2 has an entry gate called getBalance that takes the parameter of accountNumber. The getBalance message is an entry gate, because it is the arrowed line that is linked to the diagram’s frame with the arrowhead linked to a lifeline. The sequence diagram has an exit gate, which returns the balance variable. The exit gate is known, because it’s a return message that is connected from a lifeline to the diagram’s frame with the arrowhead connected to the frame.

The real purpose behind these recent posts on Sequence Diagrams have been to offer anyone, irrespective of their experience in UML, with an effective  ”crash course” in understanding this area. We think this aim has been achieved. After this series is over (stay tuned for Part 3 next week!), we hope to bring more interesting insights into UML during the coming weeks and months. Till then, Happy Diagramming!

 

Posted via email from Creately | Comment »

Appropriate use of UML notations is very important for making a meaningful model

UML Diagram Objects   UML Diagram objects and their usage
Here is an overview of all the nine different kinds of Modeling diagram objects that are wrapped under the heading of the UML.

  • UML Class Diagrams
  • UML Use Case Diagrams
  • UML Object Diagrams
  • UML Sequence Diagrams
  • UML Collaboration Diagrams
  • UML Statechart Diagrams
  • UML Activity Diagrams
  • UML Component Diagrams
  • UML Deployment Diagrams

All these objects are available in Creately and you can try out a demo or take a look at some sample UML Diagrams for more context.

Simple Class

The core element of a UML Class Diagram is the class. This is a solid rectangle contains the class name.

Class Object

A class object in a UML Class Diagram represents an entity of a given system that provides an encapsulated implementation of certain functionality of a given entity. This is a rectangle divided into three compartments. The topmost compartment contains the class name. the middle compartment contains the attributes while the lowest compartment contains the list of operations.

Package

A package object in a UML Class and Use Case Diagram provides the ability to group together classes and/or interfaces that are either similar in nature or related. Grouping these design elements in a package element provides for better readability of UML diagrams, especially complex diagrams.

Interface

The Interface object found in a UML Class Diagram indicates a set of operations that would detail the responsibility of a class.

Actor

Actor in a UML Use Case Diagram is any entity (person, organization or external system) that performs a role in one given system. In a use case diagram, an actor interacts with a use case. For example, for modeling a reservation system, a passenger entity represents an actor in the application. Similarly, the ticket clerk who provides the service at the counter is also an actor.

Usecase

A use case in a UML Use Case Diagram gives a visual representation of a distinct business functionalities in a system. For example, for modeling a clinic system, the use cases will be “Make appointment” and “Perform medical tests”.

Simple Object

The simple object from the UML Object Diagram is a rectangle which displays the object name. This object name is usually underlined.

Object

The object element from the UML Object Diagram is a rectangle divided into two parts. The top part contains the name of the object, while the second part contains the attributes of the object. Note : This element should not be mistaken with the Class element which is divided into three parts.

System

A system in a UML Use Case Diagram is a rectangle spanning all the use cases in the system that defines the scope of your system. Anything within the box represents functionality that is in scope and anything outside is not. Note that the actors in the system are outside the system.

Lifeline Notation

The object notation of a UML Sequence Diagram is a rectangle with it’s lifeline (a dashed line) descending from the center of its bottom edge. This element represents the life span of the object during the scenario being modeled.

Object

The object element found in the UML Collaboration Diagram is a rectangle which displays the object name, preceding a colon. The object name is underlined. This shows the objects interacting with each other in the system.

Comment

Comment object in a UML Sequence Diagram and UML Activity Diagram is shown in a rectangle with a folded-over corner. To relate the comment to any object on the diagram, the comment has to be connected to the object with dashed lines.

Activation

Activation elements in the UML Sequence Diagram are boxes on the lifelines. These are also called the method-invocation boxes, and indicate that an object is responding to a message. It starts when the message is received and ends when the object is done handling the message.

Destroy Object

Destroy object in a UML Sequence Diagram is a X at the bottom of an Activation box. This is a UML convention to indicate an object has been removed from memory.

Message Arrow

Message Arrow in the UML Collaboration Diagram shows the interaction between the commencing object and the destination object.

Initial State

The Initial State from the UML Statechart Diagram is the state of an object before any transitions. For objects, this could be the state when instantiated. The Initial State from the UML Activity Diagrammarks the entry point and the initial Activity State. The notation for the Initial State is a small solid filled circle. There can only be one Initial State on a diagram.

End State

End state from the UML Statechart Diagram marks the destruction of the object who’s state we are modeling. The Activity End in aUML Activity Diagram shows the termination of the activity. The End notation is shown as a circle surrounding a small solid filled circle.

Activity

Activity state in a UML Statechart Diagram and UML Activity Diagram marks an action by an object. The notation for this is a rounded rectangle.

Junction

Junction state in a UML Statechart Diagram are vertices that are used to chain together multiple transitions. They are used to construct compound transition paths between states. A junction is represented by a small black circle.

Choice

Choice state in a UML Statechart Diagram evaluates the guards of the triggers of its outgoing transitions to select only one outgoing transition. The decision on which path to take may be a function of the results of prior actions performed in the same run-to-completion step. A choice pseudostate is shown as a diamond-shaped symbol.

Fork / Join

Fork vertices in the UML Statechart Diagram serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices. The segments outgoing from a fork vertex must not have guards or triggers. Join vertices serve to merge several transitions emanating from source vertices in different orthogonal regions. The transitions entering a join vertex cannot have guards or triggers.

A Fork notation in a UML Activity Diagram is a control node that splits a flow into multiple concurrent flows. This will have one incoming edge and multiple outgoing edges. A join node is a control node that synchronizes multiple flows.This will have multiple incoming edges and one outgoing edge.

Composite State

A composite state in a UML Statechart Diagram is a state that has substates (nested states).

Object

The Object notation in a UML Activity Diagram is an activity node that is used to define the object flow in an activity.

Decision

Decision notation in a UML Activity Diagram is a control node that accepts tokens on one or two incoming edges and selects one outgoing edge from one or more outgoing flows.

Flow End

Flow End node in a UML Activity Diagram 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. This is a small circle with a X inside.

Signal Receipt

Signal Receipt notation also called the Accept event action in a UML Activity Diagram is an action that waits for a specific event to occur. This is drawn as a concave pentagon.

Signal Sending

Signal Sending in UML Activity Diagram is an action that creates a signal instance from its inputs, and transmits it to the target object, where it may cause the firing of a state machine transition or the execution of an activity.

Activity Partition

Activity Partition in a UML Activity Diagram is either horizontal/vertical swimlane. The partitions are used to separate actions within an activity diagram.

Component

A Component UML Component Diagram represents a modular part of a system. A Component element in a UML Deployment Diagramrepresents a distributable piece of implementation of a system.

Provided Interface

A Provided Interface of a component in a UML Component Diagram describes the services that the component offers to its environment. This is modeled using the lollipop notation.

Required Interface

A Required Interface of a component in a UML Component Diagram declares the services that the component expects from its environment. This is modeled using the socket notation.

Provided Interface & Required Interface with Port

A Provided Interface with Port in a UML Component Diagramspecifies a distinct interaction point between the component and its environment. Ports are depicted as small squares on the sides of components.

Node

A Node element in a UML Deployment Diagram is anything that performs work in the system. This can be either a hardware like personal computers; or a software like the operating system, database server and so forth.

Device

A Device element in a UML Deployment Diagram is a type of node that represents a physical computational resource in a system, such as an application server.

Deployment Specification

A Deployment Specification element in a UML Deployment Diagramis a configuration file, such as an XML document or a text file that defines how an artifact is deployed on a node.

Posted via email from Creately | Comment »

All kinds of UML Diagram Templates from Creately!

PART 2: What type of UML diagram should you be using?

As promised here is Part 2 of our UML post. As mentioned previously, today I will be giving you a short and sweet run through of Behavioural Diagrams, which also forms a vast part of UML diagrams. To put it simply behavioral diagrams capture the dynamic aspect of the system. The word “dynamic” in this context can be described as being the changing parts of the system.

Unlike Structural Diagrams, Behavioural Diagrams can be subdivided into five types of diagrams.

Use Case Diagrams

Use case diagrams consist of a set of use cases, actors and their respective relationships. These diagrams seek to represent the use case view of a system. A diagram of this type illustrates the functionality of a system. So a use case diagram is utilized to represent the relationships that exist among the functionalities and their controllers (internal/external), which are known as actors.

Sequence Diagrams

A sequence diagram is also commonly known as an interaction diagram. A diagram of this type deals with certain sequences, which are messages that flow from a certain object to another. It is important to note that the interaction that is present between the components of a system is significant from an implementation and execution perspective. So a sequence diagram is utilized to visualize the sequence of calls in a system when it comes to performing a functionality that is specific.

Collaboration Diagram

Another form of an interaction diagram is known as a collaboration diagram. This type of a diagram illustrates the structural organization of the system and the messages that are sent or received. These structural organizations consists of various objects and links. The specific aim of a collaboration diagram is to visualize the organization of objects and their respective interaction.

State Chart Diagram

A state chart diagram is utilized to illustrate the event driven state change of a system. It basically describes the state change of a class and interface amongst other things. A state chart diagram is used to visually represent the reaction of a system through internal or external factors.

 

Activity Diagram

An activity diagram would illustrate the flow of control in the system. This means that such a diagram consists of both activities and links. The flow is usually sequential, concurrent or even branched. The activities are the functions within a system. Ideally, activity diagrams are usually used to illustrate the flow of controls in a given system. Such diagrams are excellent when it comes to have an idea of knowing how a system will work when it is executed.


So that pretty much concludes a basic assessment of the various types of UML diagrams. I hope both posts were useful in enhancing your knowledge when it comes to software design and communication. As always, I encourage you to get in touch with us with any issues you may have with diagramming (general or specific). While I think we have substantially covered UML as a subject in this space, expect to see some interesting and thought-provoking posts starting Monday fromIndu. Till then – Happy Diagramming!

Posted via email from Creately | Comment »

10 common mistakes to avoid in Sequence Diagrams

When talking about UML diagrams and, in fact, sequence diagrams you will realize that attention-to-detail is mandatory. We’ve tapped the knowledge present in house to identify 10 of the most common mistakes that designers make when it comes to constructing sequence diagrams. We hope this knowledge helps you when it comes to making quality sequence diagrams. Have a run through and let us know what you think.

1. Get rid of unnecessary detail

A typical mistake that software diagrammers usually make is adding too much detail when working with sequence diagrams. Say your code has quite a few branches in a particular method; this does not mean that you should include each one within the same diagram using block or scenario elements. The issue is that adding too much detail ends up with too much clutter thereby making the diagrams more difficult to read and comprehend. The same could be said when it comes to sequence diagrams at the system level. Main thing is to keep all  your diagrams clutter-free, as shown below.

2. Messages should (more often than not) run from left to right

When it comes to sequence diagrams, the message flow should start from the top left corner. Since it’s a practice in western culture to read from the left to the right, all classifiers such as actors, classes, objects and use cases, should follow this route. However, there are certain exceptions when it comes to this logical flow, for example, when objects pairs invoke operations on each other.

3. Sequence diagrams that are obsolete and out of date

Outdated sequence diagrams that are not relevant when compared to the interfaces, actual architecture or behavior of the system, become a pain since they stop offering any documentation value. This is another reason why high-level sequence diagrams work much better than low-level diagrams. The former tends to remain appropriate even as the application details are changed. They may even need only a few modifications over time in order to remain current.

4. Avoid sequence diagrams if you are dealing with simple logic

One of the most common mistakes that most of us do is waste precious time doing too many sequence diagrams for every single use case, one for the basic course of action and one for each alternate course.  It is best to design a sequence diagram only when you have complex logic that you have to deal with. If the logic is simple and easy to assimilate, having a sequence diagram would not really add any value.

5. Provide a visual trace between the use case text and the message arrows

Each sentence within the use case text ideally should have some blank space around it. Each sentence should also be in visual harmony with the message that is in agreement with the particular behavior. This will enable people reading the diagram to easily see how the system will accomplish what the use case showcases.

6. Keep your sequence diagrams abstract without the need for plumbing

When it comes to robustness diagrams, there really is no need to show plumbing, since these diagrams reflect a design view that is preliminary. Having said that it is pertinent to highlight the real design in detail since sequence diagrams are the last stop before coding.

7.  Consider behavior allocation, seriously

As most diagrammers are aware, the sequence diagram is the main vehicle when it comes to making behavior allocation decisions. You use them to assign operations to your classes as you go. Behavior allocation especially when it comes to deciding what operations belong to what classes is very important in the ICONIX approach.

8. Include the use case text on the sequence diagram

Writing the text for the use case in the margin of the sequence diagram provides a trace from the design back to your requirements. In short, the diagram should match the narrative flow of the associated use case.

9. Follow the basics when it comes to allocating behavior by using message arrows

An object ideally should only possess a single personality. What this means is that a class should ideally focus on a set of behaviors that are strongly related. In other words, state objects need to be cohesive and coupled loosely. Other aspects that you need to concentrate on include things like reusability. What this means is that when you have objects and classes that are general, you could resuse then for other projects. Also remember that methods are assigned to objects, make sure you make it a habit to ask whether there is a decent fit between the method and object.

10. Consider the origins of the message arrows carefully

This is a no brainer. You do have to see which object is in control at whatever time so that it is easy to see the flow of control. While the arrows are certainly important when it comes to robustness diagrams, they are more important when it comes to sequence diagrams. Remember that the messages that are present between objects determines the operations on the associated classes.

Posted via email from Creately | Comment »