When it comes to generating more traffic for your site there is no formula as such. If you design a site that is competent and consistent, your visitors will atleast stick around and may be tell others about your site. Using Creately, we’ve done a colorful mockup along with 10 mandatory points, which can be found after the mockup, of what a good site should have.
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.
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 GuidelinesAt 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.
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:
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.
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!
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
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.
Keeping in line with that proverbial cliche, “a picture is worth a thousand words”, we did a nifty infographic on five of the most well known diagramming tools out there. So find out what’s hot and what’s not below.
There is a lot of cool functionality in Creately Desktop, and some may be more accessible than you think. These cool tricks in Creately Desktop could save you time better spent in polishing your diagram. Learn these to save time and improve the look of your diagrams.
Short cut keys make life Easier
We’d bet using a short cut key could save you a good half a second! Especially for those of you who consider themselves as being keyboard aficionados, access to our list of short cut keys is as easy as clicking the Help menu.
KObjects get Smarter
Details! Details! Details! Web mockups can be tough to do, which is why Smart KObjects (we got loads!) like Creately’s Accordion Pane can and will make your mockups look complete. And there really is nothing like an almost-complete website to convince a client. Working on our KObjects are as easy as tapping a few keys. For example, consider the Accordion Pane below. The following Text will create 5 panes with the second one open while the rest remain collapsed.
Putting it in Context
Our Contextual toolbars rock! Flowcharts and mindmaps are useful just about everywhere, from the classroom to the boardroom. And although there are a ton of applications that you can use to create flowcharts, we believe Creately Desktop offers the best user experience for flow-charting on the web. With these new Shapes and the 1-Click connector you can now quickly develop mind maps on Creately. It’s really that easy and fast.
From your Desktop to the World in seconds
Visual Collaboration is more than just the diagrams you draw. Here at Creately, we make the whole process of visual collaboration and sharing easy. You’ll find our new Twitter button neatly tucked away in the Share panel on the right-hand side. Check the box to enable a URL for your diagram and click the “Share on Twitter” button to publish your diagram directly to Twitter.
Online or offline, collaboration is cool
We’ve ranted and raved on about Creately Desktop and its Diagrams Anywhere feature. But the secret to it all is synchronization. What this beautiful word means is that if you, for instance, add another rectangle onto your diagram that is housed in Creately.com, the same change will be reflected on the Creately Desktop and vice versa. This is just the cusp of it. You can change the color of an object, make a text change, comment to your heart’s content or rearrange your whole diagram and all those who collaborate will be able to see it.
Creately Desktop can now be found on Adobe Marketplace, which is a really great place to have an AIR application. It hosts the largest collection of apps that have been built using Adobe AIR and opens up a world of opportunity for new users. Check us out here. And while you are at it, please do give us some honest comments along with a generous vote. You know how much we do love feedback. We’re also gearing up to have Creately Desktop featured in other marketplaces so that enthusiastic diagrammers can enjoy the awesomeness of diagramming, so stay tuned to this space.