Say hello to our versatile 3D objects!

As promised in our last post, where we unveiled Creately’s forward thinking Text capabilities, we are now thrilled to offer a fresh new perspective, in this post, on our intuitive KObjects, namely 3D versions of the CubeCylinder and Cone. So why is this such BIG news? We’ve listed ‘em out for you below.

1. Cool Features

   

What we actually did was to create 3D objects that have a list of features associated with it. As you can see below, you can change the Position & Size of these objects along with the 3D Angle andCube Depth as well.

    

2. Such versatile Fun!

Click and drag either one of the 3D objects onto the editor and you are sure to have oodles of fun, creating and designing diagrams, like a rocket blasting off into space, a pencil and even the Tower of Hanoi below.

We’ve already established that creating complex diagrams, such as UML diagramswireframes andmockups are easy. But Creately has also quite a bit of a fun side to it, as seen by the screen shots above.

 

3. Better usability = Simple but Beautiful Diagrams

What better way to highlight this sentiment than to draw a system architecture diagram. Having a 3D look and feel to the whole diagram is certainly something that makes it look better, more interesting and beautiful.


That wraps up this post, in the meanwhile, do spread the word to your friends and peers and other aficionados of diagramming. For more interesting announcements and tips and trends on diagramming, stay tuned to this space.

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 »

Tech Talks - The Importance of Reliability

I was the 2nd presenter in line to have a go on the Tech Talk session series atCinergix. I decided to make the focus of the presentation to center on a QA Quality Factor which is known as “Reliability”. Generally, if something or someone is described as being “reliable” it gives an idea of being trustworthy and dependable. Reliability which is a time-bound component implies successful operation over a certain period of time.

Reliability in software can be defined as “the probability of a computer program performing its intended functions, without any failures for a specified time under a specified environment”. For web applications such as Creately, reliability is an important Quality Factor that needs to be considered. Achieving reliability will give you benefits in the areas of:

Customer Satisfaction – unreliable product will negatively affect customer satisfaction severely. Thus high reliability is a mandatory requirement for customer satisfaction.

Repeat Business – Customers will return to a website that is reliable & has a positive impact on future business

Reputation – When a product is reliable the company will have a favorable reputation

Competitive Advantage – Companies can publish their predicted reliability numbers to help gain an advantage over their competition who either does not publish their numbers or has lower numbers

Warranty Costs – Reliable products will fail less frequently during the warranty period. This will lower the repair & replacements costs & refunds

Cost Analysis – Reliability data can be used for cost analysis. Reliable products will show that although the initial cost of their product might be higher, the overall lifetime cost is lower than a competitor’s because their product requires fewer repairs or less maintenance

To achieve reliability in software, activities can be followed in the areas of:

1. Error prevention

2. Fault detection and removal

3. Measurements to maximize reliability, specifically measures that support the first two activities

1. Error prevention activities

When it comes to error prevention activities, there are many things that need to be undertaken in order for you to achieve reliability. While it would be impossible to delve into the whole spectrum of these activities in this post alone, I will mention a few so that you get the gist of what  these activities entail. Ideally, you need to have requirements that should clearly & accurately specify the functionality of the final product. Moreover, you have to follow proper coding standards, perform regular code reviews for correctness & safety and perform unit testing to independently test the modules. Other activities that need to be considered would be load testing to determine the system’s behavior under both normal and anticipated peak load conditions and to also perform regression testing after additions or modifications are done to ensure that the existing functionality remains the same.

2. Fault detection and removal activities

There are two aspects that need to be considered here - Software Testing & Software Inspection.

3. Measurements

Reliability metrics are units of measure for system reliability. System reliability is measured by counting the number of operational failures and relating these to demands made on the system at the time of failure. As far as this topic is concerned you need to take into consideration Static Code Metrics (which gives information at the code level) and Dynamic Metrics (which provides information on the actual runtime). Examples for Static Code Metrics would be Source Lines of Code (SLOC) of the program, Number of Modules & Go To Statements & Number of Classes & Weighted Methods per Class (WMC). One of the Dynamic Metric examples would be Failure Rate Data such as:

- Probability of Failure on Demand (POFOD)

POFOD = 0.001 (For one in every 1000 requests the service fails per time unit)

- Rate of Fault Occurrence (ROCOF)

ROCOF = 0.02 (Two failures for each 100 operational time units of operation)

- Mean Time to Failure (MTTF)

Average time between observed failures

Problem Reports

When talking about problem reports, it is imperative that you use error logs & access logs to determine the following:

- Date of occurrence, nature of failures, consequences

- Type of faults, fault location

So there you have it. I hope this rather techy blog post acts as a good focal point when it comes to assessing your site or app with regard to reliability. I cannot but drive home the fact that this is certainly an aspect that can be regarded as being one of the best cornerstones when it comes to building a great site or app. Got any queries, comments or complaints, please do go ahead and let us know.

References: Software Metrics and Reliability by Linda Rosenberg, Ted Hammer, and Jack Shaw.  IEEE International Symposium on Software Reliability Engineering. 1998., http://swreflections.blogspot.com/2009/08/lessons-in-software-reliability.htm…

Posted via email from Creately | Comment »

Why are Wireframes so important?

While some of our recent posts walked you through the art of wireframing and its benefits, have you ever wondered why we’re going on and on about wireframes? Well the reason is rather simple. Wireframing is a valuable stage of any web design project, and now let’s take a step forward to understand why it is so important.

Wireframes are blue prints that illustrate the elements of a web site. Creating a wireframe gives the client, the developer and the designer an opportunity to take a critical look at the structure of the website and allows them to make revisions easily. Most teams discuss the requirements with their clients, and maybe sketch a few quick ideas on paper, and then jump right into Photoshop to design the layout or into Dreamweaver to do the coding. This is not always the best approach as this can result in hours of productive time being wasted on revisions. It’s always best to design wireframes as an initial step in the designing process to save loads of time in the long run. By doing this, you can address problems early and not wait to resolve the issues during the full color phase. Let’s take a look at why wireframes are so important for you and your clients.

Just simple and clear

Having an unpolished framework minus the aesthetic details eliminates the distraction of an element’s visual treatment. When reviewing a web page layout for the first time in color, it’s very easy for the client’s opinion to be influenced by the graphical design. For example – Imagine having the Call-to-Action (CTA) button in yellow and your client happens to hate the colour. Your client will likely be influenced by the CTA button’s appearance, which will probably make it harder for him/her to focus on the layout of the page. Feedback may be, “I think this needs to be re-done”, even though the layout works well. Thus, a simple wireframe without any colour distraction will let you get important feedback on sizing, layout and placement without your client making life harder for you.

Get a close-up view of the web site design

Project requirements might seem like excellent viable ideas during project initiation, but unfortunately projects are rarely simple. Anyone with experience will know the number of unforeseen problems that you’re likely to face when you start drawing the design ideas on paper. Wireframes take considerably less time to design than Photoshop layouts, so you can spend time early on using wireframes to map out the functionality of the pages. This will help you get a thorough understanding of the user experience at the early stage and therefore identify potential usability problems with the design. It’s better to make adjustments early rather than spending time on full revisions.

Know your client better

Working on wireframes will let you understand your client’s ideas better. The feedback you get from your client and your interaction with them will give you a better understanding of what to expect during future stages of the project. For example – when you initially lay out quick line drawings of the page, the client might comment on a particular element on the layout. As you’re working through the process of wireframing you may notice that the client is consistently commenting on certain elements. This will help you track the feedback patterns and learn about what your client wants to see and what they don’t like. Having this knowledge and applying it to the future phases of your project you will save considerable amounts of time.

Save time and effort

It takes a lot more time, effort and expertise to create a full colour layout on Photoshop than a wireframe. The first time your client will see the finished design is after you have spent all the effort creating it. But design changes are inevitable and more time and effort will be spent making the revisions. However, when we review wireframes, both internally and with clients, design changes can be reworked in a matter of minutes. If you don’t like the size of the button, make it smaller. If it is too small, then tweak it a bit to the perfect size. Wireframing makes it quick and inexpensive to make revisions in any day.

Wireframing Resources

Traditionally, quick and easy ways to communicate a design layout to others was hand drawn sketches, which was later replaced by full colour mockups done on Photoshop. However, in recent years, there has been a handful of drawing tools that allow designers to create interactive wireframes and user interface mockups that you can share with your client and team members on the project.

Here’s a simple wireframe built using Creately. This uses simple wireframe objects to represent the content and navigation on a web page to understand its real functionality.

Wireframe_example

I’m sure people have different approaches to wireframing. But, it is best to opt for an option which saves times, assists in collaboration and ultimately improves your productivity. Let us know if you’ve got any questions.

Posted via email from Creately | Comment »