Don’t… please don’t think that we will talk about this kind of models, deal with it! Well at least for now…

Modeling Languages, these are some other kind of models, maybe not that attractive at this point, but lemme change your mind.

First, as always, we need to define our topic, what are those called «Modeling Languages»? According to Techopedia a «Modeling language is any graphical or textual computer language that provisions the design and construction of structures and models following a systematic set of rules and frameworks».

But in reality and common words, what are those? Well, Modeling Languages are the words or images used to describe what is happening in a program or system, as we see everyday in different models of reality, like maps, we can use them to understand every little part of their behavior.

Also, you know these guys have their own web page? Check it out!

Now that we know what a Modeling Language is, we can talk about some tools we have to use them.

First and foremost: UML, Unified Modeling Language, this particular language uses some kind of visual resources to explain the different parts of a program and the interconnection between those, we can see an example in the next video:

So, what tools can we use UML with to explain our system? We have a lot of options:

• Lucidchart.
• GenMyModel.
• Gliffy.
• Draw.io.
• Creately.
• Cacoo.
• UMLetino.
• Diagramo.

Most of them are free, but in my personal opinion the best one is Lucidchart, because it has a great amount of resources for us to use, let’s see how to get started:

See? Now a really complicated program turns into words and little images that can be understood by anyone, Modeling Languages and their tools aren’t that bad after all, huh?

Let’s keep learning in next posts, thanks for keeping up with me.

-RC

As complicated as it sounds, the answer is YES!! We need to learn how to use and implement some requests from our clients, so we need to know what they will need, those, in a nutshell, are our use cases, let’s get down to business and start learning.

Last time we talked about USP, we now know that getting our requirements well defined and organized is crucial for us to get good results, so use cases will help us.

Use Cases -according to TechTarget– «is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal».

A use case has these characteristics:

• Organizes functional requirements.
• Models the goals of system/user interactions.
• Describes one main flow of events, and possibly other ones, called exceptional flows of events.
• Is multi-level, so that one use case can use the functionality of another one.

As we saw in the last definition, we need use cases in order to satisfy our client and get things done properly, now let’s see how we can draw a use case.

As seen in Visual Paradigm tutorial, we need these steps:

1. Identify the Actors (role of users) of the system.
2. For each category of users, identify all roles played by the users relevant to the system.
3. Identify what are the users required the system to be performed to achieve these goals.
4. Create use cases for every goal.
5. Structure the use cases.
6. Prioritize, review, estimate and validate the users.

So now you know what is a use case, why it is important and some crucial characteristics of them, if you want to know more, you can see this quick guide on how to draw them:

-RC

Unified Software Process (USP). What? Okay, let’s start, imagine you have a project and start creating content for it, yet you do not have the amount of people you want knowing your project, what do you do? You start by hiring people to create a tool for you to approach your potential clients, but… do you just want to see the finished product, or want to see some phases?

If you opt to see phases, you would be going by the basis of the USP, last mentioned is -as mentioned in study.com– «an iterative, incremental, architecture-centric, and use-case driven approach to software development».

We have different approaches for different types of projects, let’s see some:

Use Case Driven Approach: This approach takes into account what the client wants, first we get the requirements and questions asked, then they start working.

Architecture Centric Approach: In this case people start by thinking what technologies we may use, you begin to structure the company who wants the service.

Iterative and Incremental Approach: Here we divide each project into smaller ones and each one of those into iterations, so every time we finish a small part of the project, we have an iteration that can be presented to the clients so they can approve and let us know we’re in the right direction.

In this process we have 4 phases, let’s get to know each one:

Inception: The primary goal of the Inception phase is to establish the case for the viability of the proposed system. We have some activities here:

• Defining the scope of the system (that is, what’s in and what’s out)
• Outlining a candidate architecture.
• Identifying critical risks and determining when and how the project will address them.
• Starting to make the business case that the project is worth doing.

Elaboration: The primary goal of the Elaboration phase is to establish the ability to build the new system given the different constraints. The key activities are:

• Capturing the majority of the functional requirements.
• Expanding an internal release of the system focused on describing the architecture.
• Addressing significant risks on an ongoing basis.
• Finalizing the business case for the project and preparing a project plan that contains sufficient detail to guide the next phase of the project.

Construction: The primary goal of the Construction phase is to build a system capable of operating successfully in beta customer environments. In this phase we do all the tasks regarding to the actual creation of the system.

Transition: The primary goal of the Transition phase is to roll out the fully functional system to customers. Here we just open and update our programs to all the clients.

One example of USP usage is Rational Unified Process, this is an agile software development methodology. The phases previously defined are used by this kind of method.

The main goal of RUP is to create high quality software with a predictable budget and time frame. Each of the life cycle phases can be repeated, if needed, until the main objectives are met. Once the transition stage is completed successfully, the project is finished.

We also have Agile Scrum, which is also a common unified software process which originates from the waterfall model cycle, here, each stage should be finished before we start another one.

At the end we can say that USP is a way of distributing work for better results and easier ways of obtaining what we want our project to be, so… would you like to see just the finished product, or some phases?

-RC