HFOOAD Chapter 7

--Originally published at Hackerman's house

This chapter is about how sometimes you don’t know where to start a project or how to approach it. This is something that made I felt identified to; it is usual that at the beginning of a project I spend more time looking at the screen and thinking without any idea of how to start, so I think it was useful to read this chapter.

The things in your application that are really important are architecturally significant, and you should focus on them FIRST.

One of the first advices I found useful was that before you start designing the relations between the parts of the systems you need to have these parts or at least the basics. Architecture isn’t just about the relationships; it’s is also about deciding which parts are more important to create them first. This is where the three Q’s of architecture get into the scene; they help you determine which modules are more important.
Q

Photo by Bill Dickinson

Is it part of the essence of the system?

The essence is the most basic idea of what a system does. The easiest way to determine if a part is essential to the system is imagining the system withouth that feature, if you can’t, the feature is most probably essential.

What the heck does it mean?

This idea was somewhat new to me, because I usually start with the part that I can understand easily. In this case the suggestion is start with the features we don’t completely understand. This allows you to avoid risks around this feature. Understanding it from the beginning can mean that you won’t have problems when you are designing the relation with other parts.

Confused

Photo by Thomas Hawk

How the heck do I do it?

This idea is really similar to the one Continue reading "HFOOAD Chapter 7"

Chapter 5 HFOOAD

--Originally published at Hackerman's house

This chapter talks about the importance of making software that is flexible that is prepared for change.

The abstract class defines behavior, and the subclasses implement that behavior

The first topic is the abstraction. We can use abstract classes as a mold for objects that share the same behavior, this is later implemented in the subclass following the precise requirements for that class, taking as a base the behavior of the abstract class. The subclass can implement or override what’s in the abstract class. The first step to create an abstract class is determining when objects share the same behavior.

By coding to an interface your code will work with all of the interface’s subclasses-even ones that haven’t been created yet

The interfaces have been a common topic since I began studying this career, the classes inherit common behavior from this interface, interfaces make software easier to extend, this is important as it adds flexibility to the software.

In this chapter I noticed that I usually see encapsulation just as a way to avoid repeated code but it is more than that, encapsulation can prevent unnecesary changes in the classes. A good practice is to separate behaviors of an app that can change a lot from those behaviors that won’t.

Finally one of the things that impacted me the most in this chapter was that you have to analyze your own code and recognize when you have made a mistake, design is iterative and you have to change your own design in case it’s needed.

Warmup

Photo by Mr. Nixter

Finally I want to talk a little about my project. We have decided our project and it’s main requirements but we need to define better what the reach of the project is going to be, the design until now is very Continue reading "Chapter 5 HFOOAD"

Chapter 4 HFOOAD

--Originally published at Hackerman's house

This chapter is really interesting, as it talks about how your project will not be in the perfect situation when you release it in the real world, so you have to take into consideration all the bad things that could happen and the external factors and situations that may arise in the environment where your software is. In the case that your system only works on the perfect scenario you will have a lot of problems with your customer, because the external factors may cause the software to become useless.

This chapter talks about two more things, first, in relation with the use cases we have been working on for a couple of chapters, it talks about how important is to detect the nouns and verbs in this use cases, this can be useful to determine which classes we are going to need to develop our system, it is important to notice that not all the nouns are going to become classes as some of these are external agents and the software doesn’t have the need to include them. The verbs help us define the methods that we’ll use.

Resultado de imagen para class diagram

Example of class diagram by TutorialsPoint

At last, this chapter introduces UML diagrams, to visually represent the system and how their parts relate to each other. This can be used after the analysis and can help us to have a nice transition between this stage and the development or code stage. This UML is used when you already have the vision of how the software should work.

Now I want to talk a little bit about the project, we have finally decided what we are going to do, the Robodoggo is a robot that will help the people take care of their dogs. I really like my team, I’ve known Max

Pug
Continue reading "Chapter 4 HFOOAD"

Chapter 3 HFOOAD

--Originally published at Hackerman's house

Chapter 3 of the book was shorter than the first two, and I think it didn’t cover as much information. It talks about change, this is something you can always count on when you are developing software. This sometimes happen in the middle of the project, when the requirements need to evolve to satisfy the customer, in other occasions the software is already complete, but the customer realizes that his product can improve or even change its goal.

Change is constant, and your system should always improve every time you work on it.

The system must evolve to handle the new requirements, the use cases must be redesigned to assure that the customer’s goal is accomplished. As we already learned in the chapter 2, the use cases help us code, if the initial code and the original use cases are well designed, the changes in the requirements can be easily handled. A good encapsulation, where the objects and their methods are correctly related may avoid duplicated code, thus facilitating the process of change.

CHANGE

Photo by Martin Deutsch.

In this chapter I realized how important is a good design, as this not only affects the way your customer will receive its product, but it affects the programmer when change is needed.

 

Chapter 2 HFOOAD

--Originally published at Hackerman's house

This chapter of the Head First Object-Oriented Analysis and Design talks about the importance of gathering the adequate requirements for the costumer, this process is all about making sure you satisfy your costumer by making sure you deliver them exactly what they need even though they may not know all they need.

This part of the design to talk with your client so you can understand what are their needs, this way you can define way better how to design your software, then you can verify if your software is fulfilling all the requirements that you set at the beginning of the project, this way you have a viable way to measure how well your project is being made, this can be used to show the customer or your boss the advances in the project.

Need

Most of the times, listen to the costumer won’t assure that your requirement list is complete, that’s why you got to see beyond what they told you, and imagine specific cases where external variables may affect the way the system works, in any case the system should be able to respond to these specific cases and take an alternate path to accomplish what it is made for.

In this book they use a requirement list to gather all the requirements for the system, a year ago I learned something called user stories these are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system, is an agile methodology which is really useful to define the requirements, and something I personally like to do when designing software.

Userstory

When you already have the list of requirements you may write Use cases to define how to accomplish the requirements previously stablished, this Continue reading "Chapter 2 HFOOAD"

Chapter 1 HFOOAD

--Originally published at Hackerman's house

hfooad

This is a new semester in my life, this means I will be using this blog to share insights about my Software Analisis class.

This time I will be sharing my thoughts and things I learned about the first chapter of the famous book Head First Object-Oriented Analysis and Design written by Brett D. McLaughlin, Gary Pollice and David West.

Reading this chapter I realized about the importance of planning when you are developing any project. It’s is important to consider not only the present of the project and its functionality but the future, how robust it is and many other factors that should be taken in account in the production of good software.

While you are developing software you have to have priorities, usually the most important thing is that it is useful for the customer, then you can try some other things to make your software flexible and reusable, both of them properties of good software.

I really liked this chapter, specially the way the authors try to explain the topics in such a didactic way, using examples of code as well as UML diagrams or simply using texts or characters to explain what is going on.