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 »

Creately Blog - How to decide on using a 3rd party component

posted26/07/10

How to decide on using a 3rd party component

decision, Development, flowchart, lesson, partners, tips

When you are building a software solution to solve a particular problem, you would be very focused on solving the problem and solving it well. However, from time to time you need supporting components in your solution that are not directly related to the problem you are solving. These are components that are required to complete your solution.

Maybe its a payment system for your online greeting card service, or a spell checker component for your realtime note editor, you would rather look for something that’s already built and working well rather than building it yourself from scratch. This way you can focus on your “core competency”.

This is generally how everyone thinks. So did we. Here at Creately, we chose to use a third party solution to complete a product that we were working on. In the rush and excitement of getting the product out we signed up with the 3rd party service not considering some important factors that we should have. Even though the intention was to avoid reinventing the wheel and save time and effort, the out come was us spending double the time and effort to get the solution to work. Lesson learnt the hard way.

So I thought I would put together a simple flowchart to help us evaluate such situations in the future when such a need arises again. This flow chart explains the basic thinking, and the factors involved in making the decision can be found below.


How to decide on choosing a 3rd party solution.

Picking the most suitable solution
  • How well is my requirement met? Does the solution meet all the feature and functionality requirements I have? Does the solution meet the integration requirements I have?
  • Is the component build for me? Even if the solution meets all my functionality and feature requirements, one thing I have to watch out for is, if it does more than what I need. Will it complicate my product? or my users experience? or my integration process?
  • Is the integration and setup process straight forward? Time and effort required to setup and integrate?
  • What is the financial commitment?
  • Considering all factors above, compare the time, effort and cost involved in building the ideal solution against using the selected solution.
Assessing if the solution can be used to solve the problem
  • Can I use the existing features in the solution to make it do what I want it to do?
  • Can the solution be customized to fit my requirements?
  • What is the time and effort involved in customizing the solution for my need?
  • What is the financial cost involved in customizing the solution for my need?
  • Considering all factors above in A and B, compare the time, effort and cost involved in building the ideal solution against using the selected solution.

@Hiraash

Try Creately Now

via creately.com

Posted via email from Creately | Comment »