I blogged a bit last week about the functionality and purpose of Unified Modeling Language (UML). Since we’re still discussing the topic in class, I figured this would be a good opportunity to give a more in-depth account on the subject. I just finished reading an informative article from SmartDraw that offered me some additional insight regarding UML; it’s appropriately entitled “Everything You Need to Know about UML Diagrams.”

Some of the main topics discussed in SmartDraw’s article are: what a UML Diagram is, why we use UML, and types of UML diagrams.

SmartDraw’s article begins by explaining that the UML gives us the capability of visualizing programs through a series of diagrams. Originally developed for the purpose of Object Oriented Design, UML has worked its way into being implemented in many other forms of Software Development as well. We use UML diagrams to provide clear and ubiquitous visual explanations to our projects. The goal of UML is to help increase efficiency and team productivity.

SmartDraw indicates that UML diagrams can generally be divided into two main categories: Structural and Behavioral. Structural diagrams tend to focus on the physical attributes of a program or system, whereas behavioral diagrams are more interested in the consequences and responses from the actions within our structure.

Both groups include several other subcategories which, with the help of SmartDraw’s article, I will attempt to summarize some of which I have found particularly interesting.

Structural:

• Class Diagram: the “backbone” of almost every object-oriented method, it shows how certain classes, objects, attributes, and operations are related to each other.
• Object Diagram: describe the static structure of a system at a given time; can test class diagrams to ensure accuracy.
• Component Diagram: describe the organization of physical software, including source code, run-time (binary) code, and executables. It describes the organization and wiring of physical components within a system.

Behavioral:

• Activity Diagram: illustrate the flow of control from one activity to the next. Typically used to model the internal operation of workflow.
• Sequence Diagram: also called an event diagram, describe interactions among classes by means of periodic message exchanges.  It provides good visualization and validation among a variety of runtime situations.
• Use Case Diagram: models functionality using “actors” and provides descriptions of results for every possible action by these actors.

SmartDraw’s article went into great detail about UML, providing explanations of its purpose and why we use it. It also elaborated on several different subcategories of Structural and Behavioral UML diagrams. This article made me think of how important these diagrams seem to be in Software Development in general; they’re our blueprints for developing software. A contractor likely wouldn’t even think about building a house without a blueprint, so it seems to me that a Software Developer should adhere to that same advice.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

We’re approaching week four in the semester and getting into the processes of testing code. Prior to taking this course, I’ve tested code typically with random input, ad-hoc style. But I am now learning new testing methods as well, which are more systematic and cover larger ranges of potential case failures. That being said, I would like to talk about unit testing in general, and why it is so important.

We do unit testing because we want to ensure that our code works. Sometimes it can be frustrating when we can’t get our code to do what we want it to do. We need to do thorough testing to weed out these problems. For instance, perhaps our code works sometimes, but not always, and we have no idea why.

It can be disheartening when spending hours trying to fix something in your code which seems to magically work for some inputs, but then crashes on others. It seems that simply entering a finite and/or random number of test cases, or simply not running tests frequent enough, we may not ever find out why our code only works sometimes, but not always.

Now that I’ve discussed a few reasons why I feel that unit testing is important, I would like to share a blog that I found on the topic as well.

The Green Machine (TGM): 5 Reasons Why Unit Testing is fun–and Important

As the title suggests, TGM provides additional clarification as to why testing code is an essential part of programming. He also emphasizes that unit testing is fun as well, for a variety of reasons.

For instance, TGM states that unit testing can be rewarding in the sense that “we can execute our code right away and know that it works.” Since one of the most enjoyable aspects of programming is seeing the result of our work, having the capability to test our code at any given point is beneficial. And if for some reason it doesn’t work, we can likely figure out where it went wrong faster if we’re testing in a frequent and consistent manner.

Unit testing can also lead to an overall better understanding of how our code works. As TGM indicates, unit testing helps us figure out how our code will behave under a large range of circumstances. By running frequent tests, we can gather a better understanding of exactly what our code is doing, regardless if the tests pass or fail.

TGM’s blog was an interesting read for me, especially in regard to his insights of how unit testing can be rewarding. I’ve always known that testing code was important for functionality reasons, and now I feel that frequent testing can help make me a better programmer in general. This is due to what TGM indicated about how we can learn more about our code through its behavior during pass/fail tests.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

We’ve been discussing this in class for the past couple of weeks so I thought this would be a good topic to reflect upon. Unified Modeling Language, or UML, can be described as the graphical representation of a program’s structure. This is useful for documenting relationships of, for instance, objects and classes in a given structure. Furthermore, UML diagrams can provide general descriptions of the intended behavior and purpose of these classes and objects.

I felt it would be useful to learn more about how to make the “ideal” UML diagram, and Bellekens has a good blog in regards to this topic.

GeertBellekens: UML Best Practice: 5 Rules for Better UML Diagrams

The blog is a good read on the subject because it emphasizes the importance of consistency as well as simplicity when designing UML diagrams. Five general “rules” were discussed in Bellekens’ blog. I will summarize these below while simultaneously providing my personal takeaways from each of them.

Less is more.

When designing UML diagrams, it is important to provide the user with information that is clean, easy to follow, and straight to the point. If a diagram has too much going on, it is bound to confuse and overwhelm the user with excessive information.

No crossings.

Bellekens explains that when designing a UML diagram, there is no need for lines to cross when pointing to the various objects within the structure. Instead, enough space should be allocated to prevent this line crossing from happening. If one is unable to find the space to prevent crossing, this is often a good indication that there’s too much going on in the diagram in the first place.

Orthogonality.

While it is possible to make diagonal lines when pointing from one object to another, I feel it does not nearly look as clean as straight lines and right angles. Other than a few minor exceptions, such as pointing to notes, Bellekens suggests to avoid making diagonal lines in UML diagram at all costs.

Parents Up.

In regards to inheritance and other hierarchies, “parents/superclasses” should always be above their “child/subclass” counterparts. This makes sense to me because whenever I think of something such as a UML diagram, I think of a family tree; oldest on top, youngest on bottom.

Tidy Up.

A great closing argument to Bellekens’ five rules of UML diagrams. Maintaining the validity of UML diagrams and keeping them up to date is just as important as designing a solid graphical representation of our programs in the first place. A UML diagram that is outdated and cluttered with unnecessary information can be frustrating to say the least. Furthermore, keeping objects aligned in an orderly way makes UML diagrams easier to follow and pleasing to the eye.

I look forward to learning more about Unified Modeling Language Design in the upcoming weeks – I am sure I will use Bellekens’ tips on creating solid UML diagrams in the near future!

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

We’ve been discussing this in class for the past couple of weeks so I thought this would be a good topic to reflect upon. Unified Modeling Language, or UML, can be described as the graphical representation of a program’s structure. This is useful for documenting relationships of, for instance, objects and classes in a given structure. Furthermore, UML diagrams can provide general descriptions of the intended behavior and purpose of these classes and objects.

I felt it would be useful to learn more about how to make the “ideal” UML diagram, and Bellekens has a good blog in regards to this topic.

GeertBellekens: UML Best Practice: 5 Rules for Better UML Diagrams

The blog is a good read on the subject because it emphasizes the importance of consistency as well as simplicity when designing UML diagrams. Five general “rules” were discussed in Bellekens’ blog. I will summarize these below while simultaneously providing my personal takeaways from each of them.

Less is more.

When designing UML diagrams, it is important to provide the user with information that is clean, easy to follow, and straight to the point. If a diagram has too much going on, it is bound to confuse and overwhelm the user with excessive information.

No crossings.

Bellekens explains that when designing a UML diagram, there is no need for lines to cross when pointing to the various objects within the structure. Instead, enough space should be allocated to prevent this line crossing from happening. If one is unable to find the space to prevent crossing, this is often a good indication that there’s too much going on in the diagram in the first place.

Orthogonality.

While it is possible to make diagonal lines when pointing from one object to another, I feel it does not nearly look as clean as straight lines and right angles. Other than a few minor exceptions, such as pointing to notes, Bellekens suggests to avoid making diagonal lines in UML diagram at all costs.

Parents Up.

In regards to inheritance and other hierarchies, “parents/superclasses” should always be above their “child/subclass” counterparts. This makes sense to me because whenever I think of something such as a UML diagram, I think of a family tree; oldest on top, youngest on bottom.

Tidy Up.

A great closing argument to Bellekens’ five rules of UML diagrams. Maintaining the validity of UML diagrams and keeping them up to date is just as important as designing a solid graphical representation of our programs in the first place. A UML diagram that is outdated and cluttered with unnecessary information can be frustrating to say the least. Furthermore, keeping objects aligned in an orderly way makes UML diagrams easier to follow and pleasing to the eye.

I look forward to learning more about Unified Modeling Language Design in the upcoming weeks – I am sure I will use Bellekens’ tips on creating solid UML diagrams in the near future!

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

This is my first blog for CS-443, Software Quality Assurance and Testing. I am looking forward to becoming more familiar with this course, and blogging in general.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

I am new to blogging, and looking forward to becoming familiar with this course.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.