Diseña un sitio como este con WordPress.com

Let’s Model!

Picture of that shooting
Dany. Photo by me.

As a photographer, I can tell you that working with models is way easier than shooting with normal people. Once, I had a shooting with two girls for some social media advertisement. The shoot was amazing, we were on an awesome location and the production team was just good vibes. However, one of those girls was indeed a model, and the other one not. Shooting the model was easy, we got a lot of pics in a very short amount of time; shooting with the other girl who was unfamiliar to this, was a little bit more difficult. We got the job done, but it was easier and quicker working with the model. Well, the same goes to the software: «Working with models is going to make your life easier and your productivity will increase».

The Tower of Babel. Image from Wikimedia Commons

The software engineers were aware of this, but there was a little problem: with the born of the object oriented paradigm, a rush of new modeling languages came in, just like there were several network protocols. The world of computers needed a standardization so the developers could integrate with different teams and get a common language to communicate their ideas.

Resultado de imagen para old chinese manuscript
1500 years old Chinese manuscript, photo by Wikipedia . Since Chinese was simplified (Unifying all the different most used dialects into one language), the people who can read Chinese is able to read documents which are even 2000 years old!

James Rumbaugh, Grady Booch and Ivar Jacobson decided to merge various existing modeling languages into one common standard; this way, UML was born. The Unified Modeling Language is a graphic language that is intended to represent this:

  • Individual objects (basic elements)
  • Classes (Combining elements with the same properties)
  • Object Relationships (Hierarchy and behaviors, communication between objects)
  • Activity (Complex combination of actions / behavior modules)
  • Interactions between objects and interfaces (even human interaction)

UML is a multimodeling Language, meaning that you can make different models from the same thing, it depends on which level of abstraction you want to represent something.

UML has 13 different types of diagrams. We are going to categorize them by their functions.

Structural diagrams: This type of diagram, makes emphasis on the elements that may exist into the modeled system.

  • Class diagram
  • Component diagram
  • Object diagram
  • Composite Structure diagram
  • Deployment diagram
  • Package diagram
Behavioural diagrams: Describes what has to happen into the modeled system.
  • Activity diagram
  • Use Cases diagram
  • State diagram

Interaction diagram: This are a subtype derived from the behavioural diagrams, centered into the control and data flow into the system.

  • Sequence diagram
  • Communication diagram
  • Timing diagram

I bet you are into this right now so, let me explain some diagrams.

State Diagrams

This one is used to model the dynamic behavior of a class in response to time and changing external stimuli. We can say that each and every class has a state but we don’t model every class using State diagrams.


Initial state – Use a black filled circle represent the initial state of a System or a class

State Symbol

State – Use a rounded rectangle to represent a state. A state represents the conditions or circumstances of an object of a class at an instant of time.


Transition – Use a solid arrow to represent the transition or change of control from one state to another. The arrow is labelled with the event which causes the change in state.


Fork – Use a rounded solid rectangular bar to represent a Fork notation with incoming arrow from the parent state and outgoing arrows towards the newly created states. The fork notation is used to represent a state splitting into two or more concurrent states.


Join – Use a rounded solid rectangular bar to represent a Join notation with incoming arrows from the joining states and outgoing arrow towards the common goal state. use thise join notation when two or more states concurrently converge into one on the occurrence of an event or events.


Composite state – Use a rounded rectangle to represent a composite state. A composite state is a state which has an internal structure consisting of a set of states, transitions and other components.

Final State

Final state – Use a filled circle within a circle notation to represent the final state in a state machine diagram.

Self transition

Self transition – Use a solid arrow pointing back to the state itself to represent a self transition. There might be scenarios when the state of the object does not change upon the occurrence of an event. Use self transitions to represent such cases.

Steps to draw a state diagram

  1. Identify the initial state and the final terminating states.
  2. Identify the possible states in which the object can exist (boundary values corresponding to different attributes guide us in identifying different states).
  3. Label the events which trigger these transitions.

Package Diagram

Package diagrams are used to simplify complex class diagrams, you can group classes into packages. A package is a collection of logically related UML elements.

Package diagram follows hierarchal structure of nested packages. Atomic module for nested package are usually class diagrams. There are few constraints while using package diagrams, they are as follows.

  • Package name should not be the same for a system, however classes inside different packages could have the same name.
  • Packages can include whole diagrams, name of components alone or no components at all.

Check the syntax


Different notations

We need a way to represent code dependencies, this is what we have to do.

There are two sub-types involved in dependency. They are <<import>> & <<access>>. Though there are two stereotypes users can use their own stereotype to represent the type of dependency between two packages.

<<import>> – one package imports the functionality of other package

<<access>> – one package requires help from functions of other package.

Now that you know how this works, check this example:

This is a little overview on how UML is used to model the systems. This is a powerful tool for project development and of course, if you want to be a good software engineer, you must have to have understanding on this diagrams. If you want to learn more, there are always books and wonderful websites with tons of knowledge waiting to be read.

The pattern in chaos

Beautiful pattern in the ceiling of a building at the Forbidden City- Beijing, China. Photo by me.

Have you ever wondered why is always the menu located in an upper corner from the most of apps ? well, if you did, you are at the right spot; but, if you didn’t, i recommend you to stay, because we are about to dig into some gold.

Humans, despite having the capability to adapt, can feel uncomfortable when ran into an unfamiliar situation or environment. The designers realized about this, and they started to create patterns to make our lives easier and a much pleasant experience. This concept, known as Design Patterns, is almost everywhere, from buildings to a web page, and it is one of the most useful guides in the development of any project.

Design patterns were not only intended for UX, in fact, the concept born in the building world, based on this idea:

«Each pattern describes a problem which occurs a lot of times in our environment, including the solution to it; so, this solution can be used forward without having to think it again.»

Cristopher Alexander

Kent Beck and Ward Cunningham realized how this concepts could be applied in the new OO paradigm, so they published an article entitled Using Pattern Languages for OO Programs. A couple years later, the gang of four wrote the book Design Patterns, which you can read if you want to learn more.

So, basically, design patterns are a set of reusable elements in the design of software systems that try to avoid the search of solutions to problems which are already solved. Somehow, dp create standards for the vocabulary of the designers and also, standardize the way in which things are created (a better UX). However, design patterns does not impose some alternatives to another, its just a guide; and, of course, this is not an attempt to eliminate creativity in the design process.

Languages can model too

Photo by Quino Al on Unsplash

Have you ever heard about the concept «Modeling language»? If you have not, congratulations! You are at the right place. As I said on my previous post, we need to represent our projects in a way that can be understood by every involved person. Thus, we are going to use modeling languages; a modeling language provisions the design and construction of structures and models following a systematic set of rules and frameworks.

Modeling languages are mainly used in the field of computer science and engineering, intended for designing models of new software, systems, devices and equipment. This languages are primarily textual and graphical, but based on the requirements and specific domain in use, modeling languages fall into four categories:

  • System modeling language
  • Object modeling language
  • Virtual reality modeling language
  • Data modeling language

Let’s focus on system modeling languages. This languages will let us specify and design what we want to achieve on a software product. I am going to use a couple of them, but it will be just a sneak peak, in the future i’ll be blogging in deep about those.


Class diagram By Donald Bell

It was developed by Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software. It is a pretty complete language because it has ways to represent the most important parts of a project, such as structure, behavior and interaction diagrams.


This family covers a wide range of uses, from functional modeling to data, simulation, object-oriented analysis/design and knowledge acquisition. This family were developed under funding from U.S. Air Force and although still most commonly used by them, as well as other military and United States Department of Defense (DoD) agencies; however, this are public domain.

The main goal of this modeling languages is to make the developers life easier and to create a software blueprint that will enhance productivity and clearness in the project.

Use cases not only to store things

The most difficult part of any software project is to get what the client wants. Every mind is a whole different world, and this could cause miscommunication problems or giving something by understood without having in mind the discrepancies between the developer and client ideas. Thus, the engineers had to manage to find some way in which the client requirements could be completely understood by the developer; mostly, to represent the software-human interaction, we use the «Use case» technique.

Photo by Chris Lawton on Unsplash. Nature interactions!

So, What are the use cases?

The use case is a paradigm which describes how a user uses a system to accomplish a particular goal. The goal is to create a model of the system based on the user interactions, in order to define the features to be implemented.  You can find the use cases as plain text or a diagram, but the most common one is the diagram so let’s go deep into it.

Use case diagram

The use case diagram is composed by 3 or 4 elements: Actor, use case, system and package (this one is optional).



Any entity that performs a role in one given system. This could be a person, organization or an external system and is usually drawn like this.

Use case

Use case

Represents a function or an action within the system. It’s drawn as an oval and named with the function.



The system is used to define the scope of the use case and drawn as a rectangle.



The package is another optional element that is extremely useful in complex diagrams. Similar to class diagrams, packages are used to group together use cases.

Now that you know how to interprete the diagram, check out this example, is so simple that it needs no explanation.

Use case restaurant model by Wikimedia commons.

Unifying Anything

Unified Zebras by me

At the beginning, when God brought software to the world, the IT crowd started to create big and complicated systems. But there was a problem; due to the lack of uniformity, the project in development could be compared to a tangled spaghetti because of every aspect but the code.

Thus, Some crazy computer people started to design a framework that allowed us as developers, to get productivity, an enhanced project structure and better results for the clients in the process. This people came out with the Unified Process. So, What is the unified process? Let’s talk about it.

First things first, the unified process is not a a software development process, it’s an extensible framework. This means that it should be customized for every project or organization, always having in mind the main characteristics of the UP, which i’m about to explain.

The  Unified Process is a framework for an iterative and incremental software development process.
Main bass loop of Chameleon, a masterpiece by Herbie Hancock. Image by Ethan Hein

Iterative and incremental

The Unified Process is like an endless loop, until the project is finished; let’s go deep about it. The Elaboration, Construction and Transition phases are divided into a series of timed iterations. Each iteration results in an increment, which is a new release of the system that contains added or improved functionality.


Architecture sits at the heart of the project team’s efforts to shape the system.

Risk Focused

The Unified Process requires the project team to focus on addressing the most critical risks early in the project life cycle.


  • Inception
  • Elaboration (milestone)
  • Construction (release)
  • Transition (final production release)


Inception is the smallest phase in the project, and ideally it should be quite short. You should develop an approximate vision of the system, make the business case, define the scope, and produce rough estimate for cost and schedule.


At this time, the project team is expected to capture the system requirements. However, the main goals of Elaboration are addressing known risk factors and to establish and validate the system architecture.

Construction phase

Construction is the largest phase of the project. In this phase, the remainder of the system is built on the foundation laid in Elaboration. System features are implemented in a series of short, time-boxed iterations. Each iteration results in an executable release of the software.

Transition phase

The final project phase is Transition. In this phase the system is deployed to the target users. Feedback received from an initial release may result in further refinements to be incorporated over the course of several Transition phase iterations. The transition phase also includes system conversions and user training.

Everything is born to die.

After this nihilist title, i'm about to tell you something that you may be not conscious about.
maiden voyage
Maiden voyagae by Yumikrum. Check out its amazing work.

As a software student, i have been involved in many projects. Most of them are for educative purposes, but in some cases, i enrolled in some commercial solutions. Thanks to previous experiences, I can assure you that following a good scheme in how you develop your product will save you a lot of time, so, let’s talk about life cycles.

In the software business, a life cycle is not more than the software development process. Now, i bet you are thinking: «Come on, man, just code what the client wants and you are done». Yeah, that works most of the time, but only when you are working alone. First, you need to think that there will be a lot of engineers involved in a big project, and last, once the software is deployed, there will be the need of making enhancements, add features and fix bugs. because of that, we are in the need of implementing a software development process.

Let’s say that any software product that you are developing is like your son, and its life cycle is how you are going to raise it. If you choose the right methodology, the project will flow better. For instance, if you are working in a website for a client, you should use any agile methodology so you can show functionalities to the client once they are ready, adding it to the project and making changes faster than in a once finished deploy. If you are developing an embedded system for some health equipment, you should use like a spiral method, where you are always conscious of risks and in every stage you will reduce them. My point is that choosing the right life cycle for your software will make your life and work better. Basically, the life cycle of any software project will tell you how it will be born, how is going to be maintained and how is going to die. This post is about the concepts of life cycles, but if you want to learn more about methodologies, you should stay tune!

Yoda says: Always pass on what you have learned

#Mastery00 – An introduction to the course.

This is the first post on my new blog. I’m just getting started, so I’d like to introduce me.

My name is Oscar; i’m studying a BS in Computer science. I’m in love with music and the life! and I think that if you put enough effort on something, you always will get what you want. Also, I love photography, thats one of the things that I think makes this life better, because it gives me the opportunity to share with others how I can see the world, and sometimes, you can share emotions too. I have a meme page with over 70k followers, and yes, I do memes, but also i take it from other pages, the watermark is always there, so our followers can know where is the meme coming from. I have a little dog, his name is Pirata; he’s always making my days better and its more effective than a home alarm! For me, mathematics are present in everything, and if something has todo with numbers or patterns, i’m gonna be as focused as possible.

I took this picture when the wildfires were going on along Jalisco . Thats one of my favorite pictures because the message it carries.

But let’s get back to the topic

I think that this kind of courses (the ones that use modern educative methods) are the greatest because education has evolved based on its reasons. This «connected courses» thing will let us learn in a different way by reading what our classmates have concluded, and by interchanging opinions and perspectives, making our criteria and concepts better. I’m Trying to connect my own website with this blog, but I think that will have to wait until the next week, because i have a lot of projects going on. I’m hoping to give the best of me in this course and to get the most knowledge that I can.