Unexpected Metonymy Linkages II


Before I even begin with one of my weird analogies have in mind that I’m assuming that you’ve already read my previous entry, so if I don’t have much of an introduction or there’s seems to be missing information, that’s the reason.

“Crayons” flickr photo by idreamlikecrazy https://flickr.com/photos/purple-lover/5979587149 shared under a Creative Commons (BY) license

One of the things I mentioned in the first part of UML is that diagrams are classified into categories depending on its primary symbols. This time I’ll cover three other types of diagrams:

First, if the diagram contains packages it’s classified as a package diagram. Package diagrams are a subcategory of structure diagrams, and sure they are. Packages are a way of grouping different elements into one, it works (and also looks) like a folder and their use in a package diagram is to simplify and provide a better structure of the system. Packages can interact with each other in order to form a logical structure that tells how different components work together. It’s almost like package diagrams are maps of the world, and each of the packages is the (more detailed) map of a country.

When the primary symbols of a diagram are behavioral states and transitions it belongs to the state machine diagram category. This kind of diagram is pretty intuitive and rather simple, it contains all possible states our system can be in, such as active, out of order and waiting. These diagrams include what actions have to be taken in certain states in order for the system to transition into another one. They’re very very similar to automats, but are not as complex.

Component diagrams are UML diagrams used for Component-Based Development, where components interact with each other. These components act as pieces that can be replaced, swapped or rearranged when necessary. The goal of using components is to be able to develop each one of them independently from each other. These components can be either logical or physical and often have associated interfaces or ports in order to interact with other components.

There are obviously a lot more categories for UML diagrams, but there are too many for me to cover them all. Instead, I recommend checking out this site to read about UML 2.5’s considered classifications and this one to see some examples of different UML diagrams. Those helped me understand many of the diagrams in this and in the previous post. UML-diagrams.org was my main source when doing research for this entries, they have detailed explanations of every single possible component in a UML diagram, so that can also be useful at some point.

Now, I’ve already talked about design patterns and many Object Oriented Programming related subjects in other blog posts, so the next concept should be easier to grasp (hehe). GRASP stands for General Responsibility Assignment Software Patterns, and is actually the name of a set of design patterns that aid Object Oriented Design. I think the name fits perfectly, since it already perfectly describes what these patterns’ objective is. But just in case it’s not completely clear: GRASP are patterns that receive certain responsibilities regarding objects and classes in the OOP paradigm.

GRASP makes use of the following patterns and principles:

Creator – Class responsible for creating objects. Similar to the Factory design pattern.

Indirection – Assigns responsibility of mediation to an intermediate object.

Information expert – Determines where to delegate responsibilities.

High cohesion – Keeps objects appropriately focused, manageable and understandable.

Low coupling – Dictates how to assign responsibilities to support multiple aspects.

Polymorphism – Defines variation of behaviors based on types.

Protected variations – Protects elements from the variations on other elements.

Pure fabrication – A class made for the sole purpose of achieving low coupling and high cohesion.

Controller – An object responsible for receiving and handling a system event.

I mentioned controller at the end of the list because it’s actually an important component in the next pattern I want to briefly explain: MVC. Model-View-Controller is yet another design pattern. This one divides the associated program into three interdependent systems. Each of them has a specific role in the whole thing, and the reason for doing this is so the representation of information is separated from the actual manipulation of it. I will be talking a little more about this particular pattern in my second partial reflection, since something funny regarding this happened last week.

All of these patterns and models may seem like advanced stuff that we may not get to use or even see at any point, but the more time I’ve spent studying and working on different projects I’ve realized that many of these are waaay more common that I’d first thought.

Note: I was told that I could have only written about even more UML diagram classifications. I could’ve done that, but I wouldn’t have had a chance to think of any new comparisons and that’d have been boring and not challenging at all. 

TL; DR: You’ll eventually find every pattern implemented in some way.

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website with WordPress.com
Get started
%d bloggers like this: