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.

https://blog.codinghorror.com/unwanted-modeling-language/

For this week’s blog post, I chose a blog from Codding Horror where the writer, Jeff Atwood discusses his opinion on Universal Modeling Language (UML) and how he thinks that it is not an effective tool for organizing a program.

I picked this blog because we just went over the section on UML in class and why it is an effective tool to use. Since we’re learning it for our course, we are given mainly the positives about UML and how it can help us code. So I think it’s interesting that there is someone out there who has tried UML before and isn’t a fan of it.

Atwood states that his problem with UML is that it can be interpreted as subjective, which he feels doesn’t fit with programming since it is not subjective. Another point the writer brings up is that UML isn’t bidirectional and that if UML changes the code isn’t automatically changed and vice versa. Atwood also believes that UML does not have any advantage over other forms of documentation. However, these are all one person’s opinions. That does not make everything Atwood is saying about UML a fact, but it’s an interesting opinion to read about.

It’s interesting to get another perspective on UML after learning about it in class, and I think that Atwood is valid to feel this way because the same form of documentation is not going to work for everyone. People prefer different ways to document code and will work with what suits them best. Atwood doesn’t speak for everyone when it comes to using UML and his opinions on it aren’t the only opinion. There are many people out there who think that UML is an effective tool to organize.

This blog does not deter me away from using UML because I haven’t tried using it in depth yet so I can’t say if I will find UML effective or not, but from what I read about UML in class, it seems like a helpful modeling tool to make planning code more effective. I may love UML and use it for all of my programs in the future, or I could be like Atwood and prefer something else.

From the blog CS@Worcester – Decode My Life by decodemylifeblog and used with permission of the author. All other rights reserved by the author.

As the Fall semester kicks off and I begin to dive into the curriculum of Software QA and Testing I quickly realized how little I actually know and how in depth testing really needs to be. That being said I want to use my blog posts as an opportunity to learn about different types of testing. That lead me to go with the article “A Simple Guide to Interoperability Testing” written by the team over at ThinkSys. I really had no idea what Interoperability Testing was before I read this so I decided to learn. I also liked that it was written in 2017. I know a lot of software topics have remained the same for decades but there’s something refreshing about reading something that has been published more recently.

First off, interoperability testing is a type of non-functional testing. This means it is testing the way a system operates and the readiness of the system. In the most general sense interoperability is how well a system interacts with other systems and applications. A great example provided is a banking application system (seen below) where a user is transferring money. There is data/info exchange on both sides of the transfer without an interruption of functioning to finish the transaction.

The testing of the functionality that takes place to allow a fluent interaction between systems is what interoperability testing really is. It ensures end to end functionality between systems based on protocols and standards. The article covers 5 steps to perform this type of testing. They consist of:

1. Planning/Strategy: Understand each application that will be interacting in the network
2.  Mapping/Implementing: Each requirement should have appropriate test cases associated. All test plans and test cases are developed.
3. Execution: Running all test cases and logging and correcting defects. Also retesting and regression testing after patches have been applied.
4. Evaluate: Determine what the test results mean and ensure you have complete coverage of requirements.
5. Review: Document and review the testing approach, outline all test cases and practices so further testing can improve on what has been done.

Some of the challenges that can arise with interoperability testing include the wide range of interactions that can take place between systems, testing multiple system environments can be difficult, and root causes of defects can be harder to track with multiple systems involved.

After reading this article I can definitely see the complexity in interoperability testing. Taking an iterative approach seems like it would be the best method because you can use your results each iteration to create better test cases and more coverage. Trying to tackle all the test cases in one execution would be overwhelming and it would be difficult to have close to full coverage. It seems like interoperability testing would need to take place anytime an application is updated as well to make sure the systems that interact with it are still compatible. Now that I have a general understanding of interoperability testing I am certain it will play a role in future jobs and work I do. With today’s technology, it is rare to have a complete standalone application that doesn’t interact with additional systems.

In conclusion I enjoyed this article because it was simple, to the point, and I was able to retain the information.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

http://creately.com/blog/diagrams/class-diagram-relationships/
I thought class diagrams were complex when first introduced, but this blog post breaks it down into simple concepts that are easier to understand. This article has helped me a lot in learning the current course materials on class diagrams. It has helped me to determining and distinguishing the different components in class diagrams and their relationships, which are applicable in object-oriented modeling.
As stated in the article class diagrams are the main building blocks in object-oriented modeling. Their main function is to show the relationship between different objects in the system. This includes their attributes, operations, and relationships among them. Classes in a class diagram are represented as boxes partitioned in three. An example of a class is the loan account with three partitions. The first is the class name, which in this case is loan account. The middle is the class attributes which are the type, accountName, dateReleased, and loanAmount. The last is the method or possible operations associated with the class. The example shows all of the relevant data of a particular object in a systematic and clear way. A class diagram is simply a collection of classes.
Relationships between classes are interrelated through different types of logical connections. The following are the different types:
Association – encompasses just about any logical connection or relationships between classes.
Directed Association – shows directionality with an arrowhead, arrowhead depicts a container-contained directional flow
Reflexive Association – occurs when classes may have multiple functions or responsibilities.
Multiplicity – active logical connection when cardinality of class in relation to another is depicted.
Aggregation – formation of particular class as result of one class being aggregated or built as a connection, directionality is a diamond shape near the parent class to the child class.
Composition – similar to aggregation, difference being emphasizing dependence of contained class to life cycle of container class, directionality line is a diamond shape adjacent to the container class and directionality arrow to the contained class.
Inheritance/Generalization one associated class is a child of another by virtue of assuming same functionality, to show relation a solid single arrowhead is drawn from the child class to the parent class, with the arrowhead unfilled
Realization – shows implementation of functionality defined in one class by another class, relationship is indicated by broken lines.
This article was a overview of class diagrams. I chose it for its simplicity in explaining design concepts. It is worth reading for someone looking for a review and it has helped me a lot in understanding the course materials.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.