UML Pt 2 – M #7

Have you ever wondered how time is relative and how a certain action can be done infinite amount of times? Something called State Diagrams are used for that.

State Diagrams are considered a behavioral diagram which helps to represent certain transitions of behavior. Throughout the readings we have learned that most of the time (if not all the time) software is never static but always dynamic, constantly changing in ways to help and improve our system that constantly changes a class.

In order to give a better approach to this whole diagram theme we will have to go deeper since there are two types of State Diagrams:

  1. Behavior Diagram:
  • Dynamic changes are always presented in software and this can be related to the commit done in over time. If we relate this with the commit done on Github are to reflect the modeling and of course the construction behind how the system works.

2. Structure Diagrams: 

  • It was mentioned before that most of the time software is dynamic and in very weird cases it is static; nevertheless, the way structure diagrams are used could be with an object diagram.

Whenever we are working with diagrams we can have up to two types of diagramas, the first one being component diagrams and the other one being package diagrams. Both may sound similar but they share its unique set of characteristics and are easy to differentiate.

Component

The Component diagram is normally used to execute a very stereotype function, this sounds like a cliché in software but it is the reality. Some examples would be the documents, files and of course the famous libraries that are 99% of the time executed. In order to have a good connection it is necessary to connect the components; nevertheless, in order to work “correctly” it must used the required interface of ones component plus another one. A great example would be your router connected and working properly. For instance, a service provider comes to your house and plugs in the cables (their cables), once installed the router is the receiver and from there it distributes to multiple signals therefore you the consumer and the provider can be translated to the component example.

Package

Requirements

  1. Must be middle or large project
  2. Must show the structure on the arrangement

It is mostly used to show the multiple perspectives that a system has.

MVC

Another term to have into consideration is the MVC, those letters stand for Model-View-Controller Pattern. Throughout our life, when we are either at school or at our house we have concerns. Those concerns can be used with the definition of the word, concerns in MVC are everything related to it and the “worried” actions therefore the important stuff is always done first.

Moreover, MVC is not only that; each word has its own meaning, here are the definitions.

Model – It is used to represent an object does not matter which one or the famous POJO in JAVA. Either way works but it must be considered that any changes on the drivers may affect the whole thing and its drivers.

View – It’s self explanatory, just like you use VIEW TABLE_NAME on Databases, we use it to visualize and analyze all the data that this unique model contains.

Last but not least, we have the Controller – Same like in databases certain commands allow us to visualize and modify at the same time and this is what Controller does, acts both view and model. It is in charge of controlling the data changing inside the certain object model and it lets us know what is changing with the View of it; nevertheless, both are separated from each other.

GRASP

G.R.A.S.P stands for General Responsibility Assignment Software Patterns.It is mainly use when deciding what to assign is an “issue”, it is in charge of assigning to the classes and objects in OOD.

Grasp can be divided into multiple categories:

  1. Creator
  2. [In]direction
  3. Polymorphism
  4. Controller
  5. Fabrication

Just to name a few but there are more. Moreover, those are all related to software therefore it is not intended to remove the traditions of trial and error or the famous “Intenta y venceras” that is commonly used in OOP. No… none of that, it is intended to be used as a guide to have a better documentation and avoid those “cliche” actions that are performed when using software related towards OOD.

Advertisement

Leave a Reply

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 )

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