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 »

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 »

Creately for Confluence in Beta!

Here at Cinergix we feel like we’re on Cloud 9 right now! Yes, after weeks of arduous hardwork, we’re extremely delighted to announce the Beta release of Creately for Confluence, a plugin for everyone’s favourite collaboration platform, Atlassian Confluence.

This is an online diagramming plugin which lets you create and edit diagrams directly inside Confluence with an easy-to-use in-browser editor. Now everyone on your technical team can communicate with total clarity by including flowcharts, wireframes, sitemaps, UML diagrams or just about any other diagram type to your Confluence wiki pages and blogs. Anyone working on the wiki pages can edit and and modify diagrams as the documentation is worked on. All of this is only one-click away!

Creately for Confluence comes with the same user loved experience just like our Creately online -

  • Smart and interactive interface
  • 1-click create and connect and styling features
  • An extensive library of smart objects
  • Search for images from Google and Iconfinder.com

With this diagramming plugin, you can now get everyone on the same page by adding great looking diagrams to your wiki pages. The ability to quickly add diagrams directly within Wiki pages will make documenting your software projects a lot less of a chore.

Creately for Confluence plugin is now available for free downloads. This is just the beginning, we have a long way to go, so let us know if you have any suggestions on how we can improve.

Watch this space for more updates, we will soon have a more thorough review and usage instructions when the general release is made.

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 »

Part 1 : the ABCs of UML diagramming

Consider this the prequel to Part 1 and Part 2 of what I posted earlier on UML diagrams. I do believe that these posts are perfect in the sense that they would give you the “big picture” of the UML universe. I understand what was posted earlier on may have been complex to a certain degree, which is why this particular post is intended for those who are just getting their hands wet with UML diagramming. So to make it easy to “digest”, I will break this post up into two or possibly three easy-to-understand parts as well.

While earlier we spoke about the types of UML diagrams, let’s concentrate on the building blocks of UML in this post. These building blocks can be defined as (1) Things, (2) Relationships and (3) Diagrams.

(1) Things: These are known to be the most important when it comes to the building blocks of UML. They can be further divided into (a) Structural, (b) Behavioral, (c) Grouping and (d) Annotational.

STRUCTURAL

The static parts of a model are defined as structural things. The latter can be defined as conceptual and physical elements.  These structural things are defined below.

Class:

This defines an object set that possess responsibilities that are similiar.

Interface:


This indicates a set of operations that would detail the responsibility of a class.


Use case:

This is representative of a set of actions, which are performed by a system that is goal specific.

Component:

The physical part of a system is defined as this.

Node:

A node is indicated as a physical element, which usually is present during run time.

I hope this post clears up any doubts you may have had regarding the basic tools of UML diagrams. Having finished off the Structural part of UML building blocks in this post, please do stay tuned to Part 2 of this post where I will be detailing parts (b) to (d) of Things.

Posted via email from Creately | Comment »