Creately offers forward thinking Text capabilities!

We break our usual slew of knowledge-based posts with a very exciting announcement today. With the latest Creately release, we’ve added on some really smart features that is sure to make your diagramming experience easier and rewarding. While we do have two awesome features to talk about, we’ll concentrate on just one in this post, with the next feature described in a subsequent post later on, during this week. So without further ado, discover Creately’s multiple text feature on lines! To help you understand the potential this gives you, scour through the benefits illustrated below.

    

1. Add multiple text to lines

To make the whole process of plugging in extra text has been made easier. So easy, in fact, all you need to do is double click on the relevant line to create text. Even cooler is that you can create any amount of text on the line by double clicking at any point. Plus, editing text is also an easy endeavor; all it requires is double-clicking on the text you want to edit. Observe this super-intuitive convenience in action below.

2. Easy drag functionality

So, now you can create any amount of multiple text on lines. But we’ve also taken pains to ensure that there is unhindered usability afforded with this feature as well. With most diagrams precision is key, which is why clicking and dragging text anywhere on the line to position and place your text makes the art of diagramming so much easier with Creately.

3. Experience multiplicity with UML associate connector type

While multiple text can be added onto any type of line in a variety of diagrams, we’ve also ensured that there is multiplicity with regard to associate connector type in UML Class Diagrams. So, now there is no need to plug in awkward and mismatched textboxes when all you need to do is plug in multiplicity with just a click or two. Simply change the type of connector when connecting two Class objects to “Associate” and the multiplicity options will be available.

There you have it. A simple feature that is packed with a level of potency that is sure to make diagramming faster, easier, more intuitive and versatile. Remember to spread the good news!

Posted via email from Creately | Comment »

Beyond the Basics of Sequence Diagrams: Part 3

We got the final part of this series right here. While we did spend some time discussing Gates and its use or relevance to Sequence Diagrams, we now concentrate on just two elements known as Combined fragments.

Combined fragments (break and parallel)

      If you do recall, back in the post called – The Basics & the Purpose of Sequence Diagrams ~ Part 2–  there was information on combined fragments known as “alternative,” “option,” and “loop.” While these combined fragments are what most people will utilize the most, there are other combined fragments, such as  break and parallel, which a large share of people will find useful.

Break

 

The break combined fragment is similar to the option combined fragment. There are two exceptions, though. First, a break’s frame has a name box stating “break” instead of “option.” Second, when a break combined fragment’s message is to be executed, the enclosing interaction’s remainder messages will not be executed because the sequence breaks out of the enclosing interaction.

Breaks are utilized to model exception handling. The figure below uses a break combination fragment since it treats the balance < amount condition as an exception instead of as an alternative flow. When the sequence gets to the return value “balance,” it checks to see if the balance is less than the amount. If the balance is not less than the amount, the next message sent is the addDebitTransaction message, and the sequence continues as normal. However, in cases where the balance is less than the amount, then the sequence enters the break combination fragment and its messages are sent. Once all the messages in the break combination have been sent, the sequence exits without sending any of the remaining messages (e.g., addDebitTransaction).

An important thing to note about breaks is that they only cause the exiting of an enclosing interaction’s sequence and not necessarily the complete sequence depicted in the diagram. Where there is a break combination, which is part of an alternative or a loop, then only the alternative or loop is exited.

Parallel

 

When the processing time needed to finish portions of a complex task takes longer than previously thought, some systems handle parts of the processing in tandem. The parallel combination fragment element should be used when creating a sequence diagram that shows parallel processing activities.

The parallel combination fragment is drawn using a frame, and you place the text “par” in the frame’s namebox. You then break up the frame’s content section into horizontal operands separated by a dashed line. Each operand in the frame represents a thread of execution done in parallel.

While the figure below may not illustrate the best computer system example of an object doing activities in parallel, it offers an easy-to-understand example of a sequence with parallel activities. The sequence goes like this: A hungryPerson sends the cookFood message to the oven object. When the oven object receives that message, it sends two messages to itself at the same time (nukeFood and rotateFood). After both of these messages are done, the hungryPerson object is returned yummyFood from the oven object.

All things considered, remember that the sequence diagram is a versatile diagram that can be used to document a system’s needs and to flush out a system’s design. The reason the sequence diagram is so useful is because it shows the interaction logic between the objects in the system in the time order that the interactions take place. We, of course, explained all this from the very first post we put out in the first series we did on these diagrams - The Basics & the Purpose of Sequence Diagrams ~ Part 1. We really do hope you found this series useful. Moreover, we would like to invite you to let us in on any new topics you would like us to tackle.

Posted via email from Creately | Comment »

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 »

Guidelines for UML Class Diagrams - Part 2

Today, we continue from where we left off on the topic Guidelines for UML class diagrams ~ part 1. We spoke about the relevant guidelines for General issues, Classes and Interfaces; in this post we will discuss the remaining 3.

4. Aggregation and Composition Guidelines

As it is known an object is made up of other objects. If you were to consider as examples where an airplane consists of wings, a fuselage, engines, flaps, landing gear and so on. A delivery shipment would contain one or more packages and a team consists of two or more employees. These are all examples of the concept of aggregation that illustrates “is part of” relationships. An engine is part of a plane, a package is part of a shipment, and an employee is part of a team. Aggregation is a specialization of association, highlighting an entire-part relationship that exists between two objects. Composition is a much potent form of aggregation where the whole and parts have coincident lifetimes, and it is very common for the whole to manage the lifecycle of its parts. If you were to consider a stylistic point of view, aggregation and composition are both specializations of association where the guidelines for associations do apply.

1. You should be interested in both the whole and the part

2. Depict the whole to the left of the part

3. Apply composition to aggregates of physical items

5. Inheritance Guidelines

Inheritance models “is a” and “is like” relationships, enabling you to rather conveniently reuse data and code that already exist. When “A” inherits from “B” we say that “A” is the subclass of “B” and that “B” is the superclass of “A.” In addition to this, we have “pure inheritance” when “A” inherits all of the attributes and methods of “B”. The UML modeling notation for inheritance is usually depicted as a line that has a closed arrowhead, which points from the subclass right down to the superclass.

1. Plus in the sentence rule for inheritance

2. Put subclasses below superclasses

3. Ensure that you are aware of data-based inheritance

4. A subclass must inherit everything

6. Relationship Guidelines

At this particular juncture, the term “relationships” will encompass all UML concepts such as aggregation, associations, dependencies, composition, realizations, and inheritance. In other words, if it’s a line on a UML class diagram, it can be considered as a relationship. The following guidelines could be considered as “best practices” and and effort should be made to adhere to them at all times. Figure A Figure B Figure C 1. Ensure that you model relationships horizontally 2. Collaboration means a need for a relationship 3. Model a dependency when a relationship is in transition 4. Depict similar relationships involving a common class as a tree.  In Figure A you see that both Delivery and Order have a dependency on OIDGenerator.  Note how the two dependencies are drawn in combination in “tree configuration”, instead of as two separate lines, to reduce clutter in the diagram. 5. As a rule it is best to always indicate the multiplicity 6. Avoid a multiplicity of “*” to avoid confusion 7. Replace relationships by indicating attribute types.  In Figure C you see that the customer has a shippingAddress attribute of type Address – part of the scaffolding code to maintain the association between customer objects and address objects. 8. Never model implied relationships 9. Never model every single dependency 10. Center names on associations 11. Write concise association names in active voice 12. Indicate directionality to clarify an association name 13. Name unidirectional associations in the same direction 14. Word association names left-to-right 15. Indicate role names when multiple associations between two classes exist 16. Indicate role names on recursive associations 17. Make associations bi-directional only when collaboration occurs in both directions. The lives atassociation of Figure B is uni-directional. 18. Redraw inherited associations only when something changes 19. Question multiplicities involving minimums and maximums So while we have made a dent in the interesting subject that is  UML design, you can surely expect more blog posts that are both interesting and compelling on the same subject. We do offer a great deal of information on UML design and would love to field in any questions or doubts that you may have.

 

Posted via email from Creately | Comment »

Guidelines for UML Class Diagrams - Part 1

A few months back, we gave you a heap of informative articles on UML design that started with this. If you have not read it, we do urge you to do so since it does offer a nice introduction to class diagrams, which is the focus of this post. When it comes to system construction, a class diagram is the most widely used diagram. A class diagram generally consists of interfaces, classes, associations and collaborations. Such a diagram would illustrate the object-oriented view of a system, which is static in nature. The object orientation of a system is indicated by a class diagram.

In this post we’ll discuss the numerous guidelines that are present when it comes to class diagrams. But before we dig into the details of the guidelines, it makes sense to begin by highlighting the points that are going to be covered:

  1. General issues
  2. Classes
  3. Interfaces
  4. Relationships
  5. Inheritance
  6. Aggregation and Composition

Due to the extensive nature of the subject, we thought it would be apt to break this down into two parts. In this specific post, we will indicate the guidelines that will relate to the areas of General Issues, Classes and Interfaces as has been mentioned above.

   

Since class diagrams are used for many different purposes, such as making stakeholders aware of requirements to highlighting your detailed design, you need to apply a different style in each circumstance.  This section describes style guidelines that are relevant to various types of class diagrams.

1. Show visibility only on design models

2. Assess responsibilities on domain class diagrams

3. Highlight language-dependent visibility with property strings

4. Highlight types only on design models

5. Highlight types on analysis models only when the type is an actual requirement

1. Design class diagrams should reflect language naming conventions. In the “Analysis and design version of a class” image you see that the design version of the Order class uses names that conform to common Java programming conventions such as placementDateand calculateTaxes().

1. Model association classes on analysis diagrams. The image that shows the “Modelling association classes” indicates the association classes that are depicted as class attached via a dashed line to an association – the association line, the class, and the dashed line are considered one symbol in the UML.

2. Do not name associations that have association classes.

3. Center the dashed line of an association class.

   

A class is basically a template from which objects are created.  Classes define attributes, information that are relevant to their instances, operations, and functionality that the objects support.  Some of the more important guidelines pertinent to classes are listed down below.

1. Put common terminology for names

2. Choose complete singular nouns over class names

3. Name operations with a strong verb

4. Name attributes with a domain-based noun

5. Do not model scaffolding code.  Scaffolding code refers to the attributes and operations required to use basic functionality within your classes, such as the code required to implement relationships with other classes.  The image above depicts the difference between the OrderItem class without scaffolding code

6. Never show classes with just two compartments

7. Label uncommon class compartments

8. Include an ellipsis ( … ) at the end of incomplete lists

9. List static operations/attributes before instance operations/attributes

10. List operations/attributes in decreasing visibility

11. For parameters that are objects, only list their type

12. Develop consistent method signatures

13. Avoid stereotypes implied by language naming conventions

14. Indicate exceptions in an operation’s property string. Exceptions can be indicated with a UML property string, an example of which is shown in the above image.

An interface can be defined as collection of operation signature and/or attribute definitions that ideally defines a cohesive set of behaviors.  Interfaces are implemented, “realized” in UML parlance, by classes and components. In order to realize an interface, a class or component should use the operations and attributes that are defined by the interface.  Any given class or component may use zero or more interfaces and one or more classes or components can use the same interface.

1. Interface definitions must reflect implementation language constraints.  In the above image, you see that a standard class box has been used to define the interface PersistentObject (note the use of the «interface» stereotype).

2. Name interfaces according to language naming conventions

3. Apply “Lollipop” notation to indicate that a class realizes an interface

4. Define interfaces separately from your classes

5. Do not model the operations and attributes of an interface in your classes. In the above image, you’ll notice that the shipment class does not include the attributes or operations defined by the two interfaces that it realizes

6. Consider an interface to be a contract

It’s true that UML design is a vast and complicated subject that needs quite a bit of respect. While this whole subject may seem rather complex in nature, we have tried out best to simplify it, so that both professional software engineers and those who are just getting into UML design will find this whole post useful. As always, we are more than happy to field in any questions or doubts you may have. Till our concluding post, which we will release this week, keep those UML diagrams coming!

Reference: http://www.agilemodeling.com/style/classDiagram.htm

Posted via email from Creately | Comment »

Now, it’s Creately for JIRA!

Well, this has been quite an exciting month for us! We had our Creately for Confluence go live last week, and today, we’re happy to announce the beta release of Creately for JIRA, a diagramming plugin for everyone’s favourite issue tracking and project management software, Atlassian JIRA.

Creately for JIRA helps your development team to improve the quality of detailing on their JIRA issues by easily creating and including Creately diagrams. Issues keep bouncing to and fro, and you cannot just replace a diagram with text when explaining a requirement. Now with Creately’s full integration into the JIRA interface, you can easily add flowcharts, use cases, mockups, mindmaps, UML or any other diagrams to your JIRA issues.

Creately for JIRA comes with the same user loved experience just like our Creately online, Creately for Confluence and all other Creately products -

  • Easy-to-use interface
  • User loved functionality
  • Contextual toolbar with the 1-click create and connect features
  • A vast library of smart objects
  • Access to images from Google and Iconfinder.com
  • In-line commenting

With Creately for JIRA, when you invite your team to edit the JIRA issue, they can edit the attached diagrams too. Working with Creately for JIRA is just absolute wonder, read our usage guide to see how to use Creately for JIRA.

Creately for JIRA plugin is now available for free downloads. This is only the beta release, so let us know if you have any suggestions on how we can improve.

Posted via email from Creately | Comment »

Creately for Confluence goes LIVE!

How cool is this? As posted a few days back, we announced Creately for Confluence in Beta. While that really was some cause for celebration, we have now officially gone LIVE! We’re sure you already checked out our brand spanking new page, but if you haven’t, check it out here. The best part about all this is that you can indulge in the same user loved experience that Creately has become so well known for.

With Creately for Confluence you can -

  • Attach diagrams to your Confluence wiki pages or blogs with one click.
  • Flowcharts, mockups, wireframes, UML diagrams, sitemaps or just about any other type of diagram is just so easy to draw.
  • Creately’s drag and drop functionality, 1-click connect feature makes diagramming just exciting and fun.
  • All your diagrams are seamlessly integrated and stored inside the Confluence server.

But the good news does not stop there. We’ve come up with an interesting pricing structure that is very reasonable. Just think, for a mere $99, 3 users can enjoy using Creately for Confluence. The cool thing about this is that regardless of how many users you have on Confluence, you can get started with 3 editors. To get more details on the pricing structure, visit us here. Also, as a hurray for our launch announcement we’ve made this plugin available to you at a 40% discount. So you can now use the code ‘c0nflu3nc3l4nuc‘ when you check-out to get 40% off your purchase. This launch offer is limited until the 15th of July!

We’d love to hear from all of you using Creately for Confluence how we can make Creately’s seamless integration work better for you. If you haven’t still got Creately for Confluence, install it now with a few simple steps. It comes with a 14-day free trial! And watch our video to explore how easy diagramming is with Creately inside your Confluence server.

Want to share your thoughts on Creately for Confluence and our plans? Go right ahead and connect with us here.

Posted via email from Creately | Comment »

Part 3 : The ABCs of UML diagramming

This is the final post in this series, which was first kicked off last week. Just to remind you where we left off in Part 1; we talked about various UML building blocks, such as Things and what it encompasses. Things are further subdivided into (a) Structural, (b) Behavioral, (c) Grouping and (d) Annotational. In Part 2, we carried on our discussion of Things while leaving the aspects of Relationships and Diagrams to be explained in this final post.

RELATIONSHIPS

One of the most important building blocks of UML is the Relationships that are depicted in a UML diagram. Relationships tell us what elements are associated to each other. This type of association describes the particular functionality of applications. The different types of relationships are listed below.

(a) Dependency

This is a relationship that exists between two things where a change in one element may affect the other one.

(b) Association

This is a set of links, which connects elements of a UML model. This type of relationship also illustrates how many instances of an object are involved in that relationship.

(c) Generalization

A Generalization is defined as a relationship that makes a connection between a specialized element and a generalized element. This describes an inheritance relationship within the world of objects whereby a specialised object will inherit the behaviours and properties of the generalized parent object.

(d) Realization

A Realization is somewhat different from the relationships mentioned above and depicts the relationship between an interface and an implementation of a class. A responsibility is described by one element while the other implements it.

UML DIAGRAMS

What we have discussed in Part 1  and Part 2 of this series is beneficial if you are about to draw UML diagrams; all the various elements and relationships that have been highlighted thus far are utilized to complete a UML diagram.

So now where do we go from here? The answer is back to another two-part series that was posted close to a month ago.  This series will offer you a detailed look into UML diagrams and its subcategories i.e. Structural Diagrams and Behavioural Diagrams. Ideally both these two series of articles will cover the length and breadth of UML diagrams. If you haven’t read it already, you can embark on that knowledge-infused journey, right here. :0)

Posted via email from Creately | Comment »

Part 2 : The ABCs of UML diagramming

As promised in the last post, we will be detailing the (b) Behavioral, (c) Grouping and (d) Annotational part of Things in this post.

(b) BEHAVIORAL

Behavioral things encapsulates the dynamic parts of all UML models. These behavioral things are shown below:

Interaction:


This is known as a behavior, which consists of messages that are exchanged among certain elements to finish a task that is specific.

State machine:



This is something that is useful when the state of an object in its life cycle is significant. This is concerned with the sequence of states an object goes through in reply to events, which are external factors that are responsible for state change.

(c) GROUPING

This is considered as a device where elements of a UML model can be grouped together. Consequently, there is only one thing under this section that is available.

Package:


A package is available for gathering behavioral and structural things.

(d) ANNOTATIONAL

This is defined as a way to capture remarks, descriptions, and comments of UML model elements. Like Grouping, there is only one thing available under this section.

Comment:


A comment is used to deliver things like notes and constraints of an element.

So here we have covered all aspects relating to (1) Things, which were started on the first post. The last post in this series, which we will publish later this week, will cover (2) Relationships and (3) Diagrams. All in all, we hope these posts have been useful to you when it comes to UML diagramming.

The real purpose behind these recent posts on UML 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, 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 »