All kinds of UML Diagram Templates from Creately!

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 »

Why you should annotate Wireframes

As we all know, clarity is the main goal of any wireframe or UI mockup. What we seek to elucidate via this post is that when structuring a wireframe you need to ensure that you

  • focus on the client requirements
  • ensure that the design is clear and uncomplicated
  • and you concentrate on annotating the design.

Simple points but certainly potent points to ponder.

If you have experienced rejection at the hands of your clients, one too many times, you must remember that it may not actually be a fault of your design. Rather it could be all to do with the way you present your design to your client. While most designers are adept enough to get 1 and 2 sorted, then usually forget to do 3. And this is where it all goes horribly wrong.

Looking at a design from a client’s perspective, he/she would need to understand it before taking a decision on it. This is what annotating does. Consider this task as a step-by-step guide to the functionality of explaining what a wireframe design is all about. So at this stage, a client would be able to understand the whole concept and then, after much reflection, pass judgement on it.

Find below 4 best practices when it comes to annotating wireframes.

1. Short, simple and sweet

Think about it. How many clients do you know have oodles of time for meetings? You get the point. When annotating, make sure that you are clear and succinct in what you state. Be convincing, state the usefulness of whatever you annotate and keep it really short.

2. Annotate for the sake of usefulness

Your wireframe design is meant to solve a problem. Your client is only concerned about how useful your wireframe design is, so make sure that you annotate with “usefulness” being the main priority.

3. Order, please!

So your client has little or no time to spend meandering around a document figuring out how the wireframe design he is looking at is going to help him out. If you got the first two best practices sorted out, then all you need to do is to ensure that you arrange everything in numerical order. From the client’s perspective, this will lead to a natural flow whereby all information can be easily assimilated.

4. Get some space

You already probably know how the natural progression is to read from left to right. So it’s natural to have your design on the left while your annotations are on the right. An example using all these 4 best practices are shown right below.

 

If you do find this post useful, please do make a comment below. We’d be more than happy to field in any questions that you may have. If you got any suggestions for topics that you would like us to cover, you are more than welcome to let us know.

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 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 »

PART 1: What type of UML diagram should you be using? « Creately Blog

UML as a subject is extremely vast, which is why this particular post is divided into two different parts. While I won’t be getting into the very basic aspects of UML diagrams today, I thought it would be pertinent to elaborate on the different types of UML diagrams and what exactly they should be used for. As most diagrammers may be aware, UML diagrams are generally divided into two main categories, i.e. Structural Diagrams and Behavioural Diagrams. While this post will concentrate on the former, expect to read all about the latter tomorrow in Part 2 of this series. So if you’re a newbie when it comes to all things UML, this really is the perfect starting point for you.

All about Structural Diagrams

Basically, Structural Diagrams depict the structural elements composing a system or function. These diagrams reflect the static relationships of a structure. It is these static parts, which are represented by classes, components, objects, interfaces and also nodes. Structural diagrams are further sub-divided into four types of diagrams.

Class Diagram:

Class diagrams are what most diagrammers are used to, since they are the most common type when it comes to UML design. Class diagrams usually consist of interfaces, classes, associations and collaborations. These types of diagrams represent the object-oriented view of a system that is largely static in nature. Having said that, an active class is something that is used in a class diagram to illustrate the concurrency of a system. Generally, a class diagram highlights the object orientation of a system is the most widely used diagram when it comes to system construction.

Object Diagram:

Object diagrams are generally described as an instance of a class diagram. So object diagrams would be closer to real life scenarios when it comes to implementing a system. These diagrams consist of a set of objects and their relationships are like class diagrams and are representative of the static view of a system. The utilization of such object diagrams are similar to class diagrams, however, they are used to construct a model of a system from a perspective that is practical.

Component Diagram:

Component diagrams are representative of a set of components and their relationships. The components present in these types of diagrams consist of classes, interfaces or collaborations. So such diagrams offer the implementation view of the system. During the design phase, software artifacts of the system are placed in various groups based on their relationship to each other. These groups are called components and are basically used to visualize the implementation process.

Deployment Diagram:

Deployment diagrams would illustrate a set of nodes and their respective relationships. These nodes are described as being physical entities where the components are deployed. Deployment diagrams are used for visualizing the deployment view of a system.

So there you have it. As you can see, UML is a vast and detailed subject, which is why I’ve kept it deliberately short and simple. I hope you will tune into this space tomorrow as well for Part 2 of this series. We’ve got more exciting knowledge-based posts on diagramming coming your way next week. Please do reach out to us if you got any queries on UML or diagramming in general, the team at Creately will only be more than glad to help you out!

Posted via email from Creately | Comment »

Untitled

UML as a subject is extremely vast, which is why this particular post is divided into two different parts. While I won’t be getting into the very basic aspects of UML diagrams today, I thought it would be pertinent to elaborate on the different types of UML diagrams and what exactly they should be used for. As most diagrammers may be aware, UML diagrams are generally divided into two main categories, i.e. Structural Diagrams and Behavioural Diagrams. While this post will concentrate on the former, expect to read all about the latter tomorrow in Part 2 of this series. So if you’re a newbie when it comes to all things UML, this really is the perfect starting point for you.

All about Structural Diagrams

Basically, Structural Diagrams depict the structural elements composing a system or function. These diagrams reflect the static relationships of a structure. It is these static parts, which are represented by classes, components, objects, interfaces and also nodes. Structural diagrams are further sub-divided into four types of diagrams.

Class Diagram:

Class diagrams are what most diagrammers are used to, since they are the most common type when it comes to UML design. Class diagrams usually consist of interfaces, classes, associations and collaborations. These types of diagrams represent the object-oriented view of a system that is largely static in nature. Having said that, an active class is something that is used in a class diagram to illustrate the concurrency of a system. Generally, a class diagram highlights the object orientation of a system is the most widely used diagram when it comes to system construction.

Object Diagram:

Object diagrams are generally described as an instance of a class diagram. So object diagrams would be closer to real life scenarios when it comes to implementing a system. These diagrams consist of a set of objects and their relationships are like class diagrams and are representative of the static view of a system. The utilization of such object diagrams are similar to class diagrams, however, they are used to construct a model of a system from a perspective that is practical.

Component Diagram:

Component diagrams are representative of a set of components and their relationships. The components present in these types of diagrams consist of classes, interfaces or collaborations. So such diagrams offer the implementation view of the system. During the design phase, software artifacts of the system are placed in various groups based on their relationship to each other. These groups are called components and are basically used to visualize the implementation process.

Deployment Diagram:

Deployment diagrams would illustrate a set of nodes and their respective relationships. These nodes are described as being physical entities where the components are deployed. Deployment diagrams are used for visualizing the deployment view of a system.

So there you have it. As you can see, UML is a vast and detailed subject, which is why I’ve kept it deliberately short and simple. I hope you will tune into this space tomorrow as well for Part 2 of this series. We’ve got more exciting knowledge-based posts on diagramming coming your way next week. Please do reach out to us if you got any queries on UML or diagramming in general, the team at Creately will only be more than glad to help you out!

Posted via email from Creately | Comment »

Creately Defines Its Own ‘Web File’ With New API

Jeremy Glassenberg, September 27th, 2010

Comments(1)

Creately

Online diagramming service Creately opened its Creately API to the public this month, and with some surprisingly innovative features.  While providing obvious features to make its service available to outside developers, and several “above and beyond” features, such as easy embedding of diagrams, Creately has done something fairly unique: open up its own, web-based file format for other developers to use.

Creately is like an online version of Microsoft Visio, providing diagramming tools in a web-based interface.  Although it can accept Microsoft Visio files, Creately’s unique functionality required it to define its own file format – a format that it’s opening up to interact outside of its own service.

As summarized by Creately,

Creately is a visual collaboration platform used by project teams to communicate more effectively. With Creately’s easy to use interface and Shared Projects, everyone on your design, development and business teams can collaborate on software designs, wireframes, business & strategy diagrams easily.

Creately sample diagram

While intrigued by the new developer program, I found a significant gap in Creately’s workflow.  Although the concept of an open, web-based file format is quite intriguing, the file’s surprising lack of connectivity to the rest of the Creately platform limits its capabilities.  After reviewing the rest of the Creately API, I was surprised to find that there’s no way to interact with the Creately file format through any other aspect of this API.  For instance, a Creately file cannot be obtained from Creately through an API-connected program, nor can a Creately file be uploaded via API.  Currently file contents can only be obtained manually, through the website.  This may limit the Creately file type from being truly utilized for deep integrations.

I trust that Creately is just experiencing some jitters in the initial launch of its platform.  While the API appears well designed, it looks like Creately left some obvious items to be completed later.  This is noticeable in the documentation, which is a little rough on the edges, with a few documentation pages currently missing.  It seems that Creately is putting in a good effort to solidify the platform, so hopefully that will include a more solid basis to utilize the Creately file format and bring all pieces of this API together.

via blog.programmableweb.com

Posted via email from Creately | Comment »

Creately named Top 10 Apps in Asia

Creately named Top 10 Apps in Asia

FOR IMMEDIATE RELEASE

PRLog (Press Release)Sep 23, 2010 – Today, Creately was named one of Asia’s Top 10 Apps at the Singtel Accelerate 2010
conference held in Singapore. Creately was selected from a shortlist of applications nominated from all over Asia.

“We are very excited to have been selected and look forward to the new opportunities this will bring. The Singtel Accelerate event brings together some of the biggest telecommunications players in Asia, and its a fantastic opportunity for us to explore partnerships in Asia.” notes Chandika Jayasundara, CEO, Cinergix Pty Ltd, creators of Creately.

Creately also announces its Public API today at Accelerate. The Creately API allows Partners and Developers to build applications that integrate the Creately diagramming application directly into their platforms and web services. “The Creately API allows our partners to add a new dimension of visual collaboration to their current platforms. We have partnered with a number of SaaS and infrastructure platform providers, allowing Creately to grow our reach and customer base” added Chandika Jayasundara.

The Creately API is being already utilized by Tata Indicom to provide a white-labelled Creately service to their small business customers. “Besides our telco partners, we are working with a number of enterprise collaboration platforms to supplement their offerings. These will be announced within the quarter and we’re aggressively pursuing new partners especially in Asia, which has excellent growth potential for the near term” concluded Chandika Jayasundara.

More information about the Creately API can be found on the the Creately Developer Site - http://developer.creately.com/.


# # #

About Cinergix
Cinergix is an Australia based company that builds and sells Creately - a diagramming platform and its patent-pending KObject technology. Creately is a powerful web-based software with an interactive interface and collaborative capabilities that are changing the way teams communicate and collaborate online. This new paradigm of leveraging user-generated content for design work will enable Cinergix to support the long trail of design problems. Started in 2008 by a team from Sri Lanka, the UK, and Singapore, the company also runs a research and development centre in Colombo, Sri Lanka. For information, visit http://creately.com/about-us.

About Singtel Accelerate
Singtel Accelerate is a conference organized to curate the design and development of
applications and facilitate businesses to gain fast access into Asia. The Conference also
focuses on topics that span across Business, Technology and Design. For more information, visit http://accelerate.six.sg/about_accelerate.html


—- end —-


via prlog.org

Posted via email from Creately | Comment »