On almost all my previous blog posts related to Software Development I had mentioned a lot about something called Unified Modeling Language (UML) created by Rational Software, but I haven’t really covered the definition of it, and as you can guess, in this post we will cover the topic of Modeling Languages and as all the other definitions we had seen, by itself is quite abstract and covers a lot of alternatives.

If you search for Modeling Language, you will probably end up with results about UML because of it’s popularity, but according to Techopedia, the concept by itself means any graphical or textual computer language that provisions the design and constructions of structures and models following a systematic set of rules and frameworks.

As stated, you can basically create your own unique Modeling Language, called it as whatever you want and become famous (if you are lucky), but, you might have the question, why is UML so popular? In this post we will focus on answering that question. Keep in mind that there are a lot of modeling languages out there (this image pretty much sums a lot of them up).

Unified Modeling Language

One of first things you will probably see when you start exploring the software development environment is the word UML (I pretty much spam you with this word in my TC2004 blog posts). The creators of this modeling language are Ivan Jacobson, Grady Booch and James Rumbaugh (yes, they appear again!), there’s a lot of information UML, there’s even an official page (I recommend checking it out), but let’s try to put it in less complex words, we can summarize it as follows: it’s just a standard modeling language, which is a way to design and construct the system we are building.

I recommend reading the History of UML section by Visual Paradigm, in which they show a great timeline of how it has been evolving, but where are we now? Let’s look at an image that shows how a UML diagram looks like:

As you can see by the image, we define the actors, the actions it can do, and it’s interactions with the other parts of the systems, but there are multiple types of UML depending on the thing you are trying to represent, for example, you can also represent objects:

There are several types of UML representations, this post by Noel Ceta showcases and explains some of these types, I recommend you to check it out to learn a little bit more. Keep in mind, that if you go to other sources on the Internet or books, you might find a little differences in the way the information is presented, but they basically state the same thing, so don’t worry.

Creating UML Diagrams

Some of you might want to create UML diagrams because they are really useful to show dependencies in your code, and it’s really easy to do it since nowadays there are a lot of useful tools online that can help you with that, for example, if you code in Java, the names Eclipse and Intellij might sound familiar to you, the good thing about this IDE’s is that they provide a ton of functionalities, and one of them that is very usual in Java is the ability to generate the UML diagram of your project. For Eclipse you can use something like ObjectAid UML Explorer; in Intellij you can find it as a built in feature (you need the Ultimate Version, if you are student you can get it for free ;)).

But let’s say that you want to plan your UML diagram while designing (should be the appropriate approach to avoid spaghetti code), if you are a student with an adjusted budget, I really encourage you to use Draw IO, I have personally used it a lot for the past years in college, and it’s a saver.

Final Thoughts

Again, you probably have the feeling of: “What should I use?“, and of course, I cannot answer that questions, as every single thing in our path through software development, like methodologies, tools, techniques, etc., we have been seeing that there are an incredibly amount of alternatives to pick from, the same applies to Modeling Languages, we only talked about UML, but you are free to use whatever you want, but it’s important to at least know a little bit about everything to make sure that you can choose the right tools for the job you are making.

Continuing our journey to understand software development, we will stop to think about the important aspect of the product we are building, and by that I mean who is interacting with our system. Now, imagine that we combine the words that are in the title, what do we get? The answer is our next important topic: Use Cases.

Where are going to continue by defined the use cases based on the Unified Process paradigm we defined in the previous post Unifying Software Development Methodologies, where there are going to be many users that interact with it, and those interactions might be different depending the type of user they are (actors), and also might have different relationships with the objects that are part of the system or other users. For example, an online classroom (the most used example, but easiest to understand), where there are teachers, helpers and students. They have different views, permissions, and a different way to interact with the whole system, i.e., the system has different use cases depending on the user.

I know, i know, I might be over reusing the word “use cases”, I didn’t understood at first why they are important because they kinda seem obvious, so let me explain. Most of humans are really good at creating or building something if you have a set of instructions, sometimes these steps are really easy to follow and even sometimes are not necessary, for example, when you are preparing a bowl of cereal, you don’t really need instructions for that, but if you want to make a Lakeside Paella, you probably not even memorize the ingredients.

Use cases are really important to define the actors in the system, and at the same time, creating a blueprint of what to expect. This blog post by Tech Republic states that use cases are a great guidebook when you are developing and they give ten reasons why they are really important, in my options these three are key (the rest are important too, I recommend reading the post, it’s really useful):

• Reveal process alternatives, process exceptions, undefined terms, and outstanding issues: You will never cover all the things needed in a complex system, but you need to try to minimize these errors, and when you create use cases, you and your team can start brainstorming or realizing about things you haven’t consider before.
• Recognize patterns and contexts in functional requirements: Some uses between uses are related, and by defining them before hand, we can define similar functionality that both can share, to make a more simpler and cleaner design.
• Ensure the delivered software works properly: A key factor before delivery is testing, and if you have a blueprint of the expected behavior, you can use it to create test based on those assumptions and write good tests that others can read and help understand the functionality of the system.

There’s an important thing that you need to consider about use cases that Josh Spilker states on his blog post “What Is A Use Case?” (careful with the popups): Use cases explain behaviors, but not how to built or construct the system, they are quite simple.

Sometimes use cases are represented as diagrams, and in that case are part of UML and known as Use Cases Diagrams, they do not have to be always like that but are one of the common ways to define them.

Final Thoughts

If you read my previous post about Software Life-cycles, I talked about Agile, that approach has some term that might sound familiar to you if you read more about it, called User Stories, which I originally confused with use cases, they are somewhat similar, but they really serve different purposes, I recommend reading User Story vs Use Case by Visual Paradigm to understand the difference if you are struggling with the same problem.

I find quite amazing what people on the 80s-90s built from the necessities they started noticing when they were building software systems back in that time, and that the name Ivar Jacobson appeared again (this guy is everywhere in these blog posts). Use cases are a clear example of that, they are something that is really useful for early and future development because they define part of your requirements, an also you can come up with things you haven’t thought before.

On a previous post I talked about the Software Development Life Cycles, in this post we are going to continue looking through one specific process, called Unified Process (UP).

This well written scientific journal defines it as a system that goes though many iterations, with cyclic feedback and adaptation. Meaning that the whole system is development incrementally over time, and by each iteration the process makes changes based on the feedback received. There are four main phases: Inception, Elaboration, Construction and Transition.

We need to make clear a definition that can commonly lead to misunderstandings, the Rational Unified Process (RUP) it’s one the best known UP, and sometimes authors used this names interchangeably, but the Unified Process is referred as the general concept of the whole framework, since there are many examples of UP’s, the concept just include those elements that all the processes have in common.

Rational Unified Process (RUP)

This process was developed and published by Ivan Jacobson, Grady Booch and James Rumbaugh for IBM, were they combined their methodologies into a single framework based on UML. Probably these names are familiar to you, if not, I recommend you to read more about them, they have created and published a lot of tools and techniques that are used widely in software development, one example is Unified Modeling Language (will explain this topic in a future post).

IBM published a paper were they defined the Rational Unified Process as a disciplined approach to assigning tasks and responsibilities within a software development organization, and its goal is to ensure the production of high quality software, taking into account the needs of the end users, and it has the following characteristics:

• Is a process product.
• Enhances team productivity.
• It’s activities create and maintain models.
• Is a guide of how to effectively use the Unified Modeling Language.
• Is supported by tools, which automate large parts of the process.
• Is a configurable process.
• Captures many of the best practices in modern software development.

To explain each one of the main phases of the process, here’s a quick and great video that summarizes everything you need to know, it you don’t like to watch videos and prefer to read a more in-depth definition, here’s a great blog post that shares information about the process and it’s main phases.

Other Unified Process Examples

As I stated before, there are many more UP-like processes that developed over time and when needs on the industry change, these are inspired on the Rational Unified Process, and make it simpler or with little modifications since sometimes all the elements of RUP are not needed, but maintaining the core of it. We are going to see two quick examples: OpenUP and AUP.

Open Unified Process (OpenUP)

This is a method that is open license (as the name states), were only the fundamental and sufficient elements are included, it was used by the Eclipse Foundation, in other words, OpenUP is a lightweight alternative from RUP. There is a great article called OpenUP – The Best of Two Worlds that briefly explains why it’s useful to use this process. Here’s a diagram presented by the Eclipse Organization on a document that well explains the OpenUP process that I recommend reading:

Agile Unified Process (AUP)

Similar to OpenUP, AUP is a simpler version of RUP developed by Scott Ambler. He actually wrote an open document were the whole process it’s defined. The process uses Agile techniques and concepts such as Test-Driven Development and Agile Modeling, it life cycle phases are defined in the following figure :

It changes a little bit the phases work during the iterations having some other things in considerations, but as you can see, the core patterns are very similar to RUP.

Final Thoughts

The Rational Unified Process is a great software development that inspired a lot of processes used widely in many organizations, but it can be a killer in smaller projects, that’s why OpenUP and AUP exist, they get rid of the complexity and robustness that the original process has, making it more simpler and only doing the work that is enough, following other principles. It’s important to keep in mind that you use what you need in the environment you are in.

Software development can be a hard task, if you are thinking about creating some long term piece of software like Windows, or a short term software like your course final project, you want to be efficient and be able to deliver results, but, what steps do you have to follow?, Is there a concrete map of things you have to do?, in fact, there are many to choose from, they are called “life cycles of software development”, and we are going to talk about some of the two most popular approaches that I know quite well and differ quite a bit between each other: Waterfall and Agile models.

Waterfall Model

It was published for the first time by Dr. Winston W. Royce, being to this date one of the oldest models developed and inspired the creation of many more. It’s pretty straight forward, we have several stages to develop our software, but we have to work with one at the time before proceeding with the next one until everything is completely done. The steps done varies since there are different approaches, but the work that is done can be summarized as follows:

• Requirements: What does the user or client wants? A list of things that the software must have and consider.
• Design: Which approach or framework is going to be used to do the implementation?
• Implementation: Creating and following a strategy to work towards the goals and coding.
• Verification: Making sure everything makes works as expected and that the requirements are fulfilled and code testing.
• Maintenance: Fix bugs, security issues and do enhancements based on the feedback or data gathered.

Sadly, as you can tell, it’s very inflexible because of the limitation of not advancing to the next stage until the one before is finished, so if a mistake is done, it can result in a massive lose of time. On the other hand, because of it’s simplicity, it’s really easy to manage and it works on some projects were the solution has to be in the very first try, e.g. medical equipment, sending astronauts to the moon, etc.

You can find quick and good reads about the opinion of developers about the waterfall model, like this one by Jeff Atwood posted is his blog Coding Horror on why they are not being used so much anymore.

Agile Model

On the current environment of development, we have a ton of changes that happen nearly everyday, we know them as updates, people love and hate them, we are exited to have the newest features and bug fixes of software we have installed, but we do not like when you are on the middle of some online game match and out of nowhere Windows decides to update. We need to have some way to develop through many iterations, and that’s when Agile comes into play.

The way it works it’s by dividing the project into small chunks of work, making them more manageable, allowing for short deadlines and easier development since you don’t need months of preparation. Keep in mind, that the steps can change depending the Agile method you using, there are many, some examples are Extreme Programming and Scrum.

This model allows close interactions and communication with the customer to make changes from the continuous inputs they gave (like the ratings from your phone’s app store), providing a way to adapt to the wild environment of constant changing demands from clients, and it’s very flexible to make changes during each iteration compared to the Waterfall model.

If you want to learn more information about this methodology, there’s a lot you can read from the Agile Alliance webpage, my recommendation is to read their manifesto and 12 principles.

Final Thoughts

One of the things that I was struggling with when creating this post was: “which and how many life cycles do I write about?“. There are many popular, and it would be tired and boring to write about all of them, of course, a lot of them are useful, but from my perspective, it depends on the work you are doing, I just showcase two of them to get some starting point to a world of no correct answers. I cannot state what is the best of the two models I talked about or the other ones that exist, because it depends on the context and what you need at the time, likewise, if a perfect model existed, I don’t think people would still create articles like “this X model sucks!” (although is the Internet, who knows).

My recommendation to you is to choose whatever is best for you, read more about the other ones that are available, there a lot of articles that talk about other models that you can learn from, or you can read more about the other Agile methods, or just create your own cycle that works the best with the environment you work on. But remember, no matter what you plan, there are going to be obstacles and challenges that you need to face.

I really like the illustration above, it really shows how the real world works, and it can easily translate to software development. From my pasts experiences, I can tell you that no matter how well you prepare, there’s going to be something that fails because of internal or external reasons. There’s no secret formula to avoid these mistakes, the best thing you have to do is to prepare and act fast when this happens, and also don’t feel bad, I ensure you that it happens to the best people in every industry, just learn what you can from the mistakes 🙂

That was the blue static text visible on the opening crawl of the first movie of Star Wars, it marked the beginning of an adventure to become one of the biggest franchises of all time. Starting to blog for the first time doesn’t differ too much from an adventure, you don’t really know where to start or how to do it, there’s no exact guide other than some articles on the Internet that can give you some tips, and for someone that doesn’t use social media to share information, it’s something that seems like out of this world.

The reason behind I started this blog is because this semester my teacher asked to do this task (sorry for the call out), and to be honest, this seems kinda weird, I feel like talking to myself because probably nobody is watching this other than me and the teacher (hopefully my classmates too), but also in some way I feel excitement too.

The concept of registering the things you do and share it with others it’s an awesome experience were both reader and writer can learn from, and personally, it feels like an opportunity to grow other than computer nerdy technical skills. The following posts in this blog will show my progress through the course, I will share on these all the topics that cover the course of Analysis and Modeling of Software Systems, and I expect that you can learn something from the information I present.

Just for the record the things I have done lately are:

• Setup WordPress (duh).
• Setting up an account for Hypothes.is (seems cool).
• Understanding how to use Smalltalk (useful link that summarizes the language, more on this in upcoming posts).

I will be marking the course posts with the category of TC2004, if I have time, I will make other posts with other useful information outside of the scope of the course that can be useful for you, so feel free to poke around :).