Mastery 14 – OO and Agile

Agile is a philosophy for developing software that revolves around four values and twelve principles that can be found in the Agile Manifesto

Values:

1. Individuals and Interactions over processes and tools
2. Working Software over comprehensive documentation
3. Customer Collaboration over contract negotiation
4. Responding to Change over following a plan

Principles:

1. Customer satisfaction by early and continuous delivery of valuable software.
2. Welcome changing requirements, even in late development.
3. Deliver working software frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

These values and principles try to ensure a good relation between you, your team and the client, by building trust and delivering consistently.

Now, imagine using this philosophy and all the tips that the Head First Object Oriented Analysis and Design gave us. That would only translate to great object oriented software with the contemporary market trend: agile. If you want to find out more about HFOOAD’s tips, check out this other post which basically sums up the whole book: HFOOAD Chapter10 – “Putting It All Together”

 

HFOOAD Chapter10 – “Putting It All Together”

In this chapter, the authors explain everything that they have covered with an example. The only thing I will cover in this post, is the whole list of steps that are recommended to follow in order to develop great software.

1. Feature list

   Here you define everything that your software system needs to do in order to satisfy the client’s needs.

2. Use case diagrams

   These use case diagrams will help you and the client visualize how the system works and who is involved in the behavior of every process.

3. Break up the problem

   Break the system into modules and decide the order in which those modules are going to be developed. Here you will need to take into consideration the risk involved with every module.

4. Requirements

   Here is where the iterative part begins. This means that for every small part of the software system, you will work section 4 to section 7. In this section, you will figure out every need that the part you are working on needs to meet in order to satisfy the client.

5. Domain analysis

   In this section you will need to investigate the context of the software system you are developing. You will need to map the use cases that you made to objects in your system. Also it is very important that you and the client are on the same page.

6. Preliminary Design

   After defining the objects, you need to define the relationships between those objects, and apply design principles and patterns.

7. Implementation

   Develop the software system, actually code. Make sure you are testing everything to make sure that you won’t encounter any ugly surprises.

8. Delivery

   After you have finished, give the complete product to the client.

 

I really liked that the authors gave me a summary of the whole process. That will prove very useful in my future projects.

Mastery 13 – Test Driven Development

Test driven development is one that focuses, as its name suggests, on tests and test cases. In this approach of software development, test cases are made for each requirement and the goal is to develop until each test case is passed. This kind of development technique ensures that almost nothing the user does can harm his or her experience with the system.

This development style is cyclical and follows the following order:
1. Add a test
2. Run all tests and see if the new test fails
3. Write the code
4. Run tests
5. Refactor code
6. Repeat

Test driven development can be really good in the KISS (“keep it simple, stupid”) philosophy, because you code only what’s necessary in order for the software to work.

Mastery 12 – Testing in OO

The art of testing software is one that ensures that whatever you are developing is not going to cause any trouble to anyone that uses it. Whether that is your customer, or even yourself, are going to have the best experience when using the system you built.

Test driven development (as I mentioned it in HFOOAD Chapter 9 – “The Software is Still for the Customer”) is one where you plan the tests and develop software around them. At all times you want to test that new function, method, class or piece of code that you just made.

In OO things change a little bit, because this paradigm comes with a lot more capabilities and ways to develop the same thing. In OO test driven development you don’t only think about what can make your functions behave in a way that they are not intended to, you have to take into consideration some other things: how objects behave in the language you are coding, how inheritance could break your code, how polymorphism affects your system, and so on.

The general advice (and this applies to every software paradigm there is) is to test everything that that paradigm brings to the coding scene. If you are working with objects, test those objects, if you are developing in functional programming, test those functions, if you like modular programming, test those modules and how they interact with each other.

Software Verification and Validation

Validation is as simple as “are we meeting our requirements?”. In other words, we need to check if our project does everything it is supposed to be doing. This must be checked as we build the system, because if we wait until the very end of the coding part, we maybe find out that the have to change a lot of things.

Verification is checking that the product of every iteration in the development process is what was planned in the beginning of that iteration. That if the project is developed by iterations, if not, just make sure that in every step of the development process you developed what you agreed to in the beginning of the step.

Independent software verification and validation is a way to verify and validate your software by a team different from the one who coded, to ensure that the projects is going well. It usually consists of five phases:

• ISVV planning
• Requirements verification
• Design verification
• Code verification
• Validation

HFOOAD Chapter 9 – “The Software is Still for the Customer”

This chapter revolved around five ways to develop a software system. Most of the time, people tend to work on more than one way, so it is pretty common to mix and match with these ways to develop.

 

Use case driven development

When you develop a project scenario by scenario, use case by use case. In this approach, you develop each process at a time. It works well when the system has a lot of processes and scenarios, rather than individual pieces of functionality.

 

Feature driven development

In this approach you look at your list of features and start working one at a time. You don’t work on the next feature until the current one is done. This works well if your system has a lot of disconnected pieces of functionality.

 

Test driven development

In this approach, you always make tests of everything you are doing. You plan the tests even before you actually code, this way, when you are coding, you can make sure to make no mistake.

 

Programming by contract

When you program by contract, you give whoever uses your API a little freedom with errors and exceptions. In this approach, if one of your functions or methods can’t return something useful, you could return null. This way the developer handles the exception.

 

Defensive programming

When you program handling every single error or exception whoever uses your API may make. In this approach you could sacrifice a little bit of performance to ensure no one can crash their system by using you API.

 

In reality, as mentioned above, developers almost always mix and match these approaches in order to fit their needs and their customers’ needs.

HFOOAD Chapter 8 – “Originality is Overrated”

In this chapter we were introduced to design principles. These make your software more maintainable, flexible and extensible. These are the following:

1. Open-Closed Principle
2. Don’t Repeat Yourself Principle
3. Single Responsibility Principle
4. Liskov Subsitution Principle

Open-Close Principle

This principle tells us that classes should not be modified but extended. For example, if you worked on a class, your workmates should not modify your class, but make new classes that inherit from yours.

Don’t Repeat Yourself Principle

This design principle consists in identifying same behavior and abstracting it to just one place. That way if a change needs to be made, you don’t have to change several classes, just the one.

Single Responsibility Principle

This principle suggests that each class should only have one purpose. As it was mentioned in previous chapters, each class should only have one reason to change.

Liskov Substitution Principle

This principle tells us that subtypes should be interchangeable for their base type. For example, if you have the “Animal” class and the “Tiger” class inherits from it. You should be able to treat tiger objects as animal objects without having any problem. If you get a problem by this type of behavior, you are not using this principle the right way.

This chapter also talks about delegation, composition and aggregation.

Delegation is when you hand over a specific behavior from one class to another.

Composition is when a class has other classes as attributes and those other classes need the first class in order to exist. Composition is all about dependency.

Aggregation is just like composition but without the dependency, it’s when a class has other classes as attributes but any of those classes need another to exist.

This chapter focused on specific things, not like the big picture kind of stuff that was present inn previous chapters. I really liked that because it gave me some new tools for designing software projects.

References

McLaughlin B. , Pollice G., West D. (2006). Originality is Overrated. On Head First Object-Oriented Analysis and Design: A Brain Friendly Guide to OO&A (640). O’Reilly Media.

Mastery 09 – Classes to Code

This is really simple, because in your diagrams you already have the methods and attributes identified. To transfer a class from a class diagram to code, just create a class in the language of your choice and add the attributes and methods you have in your diagram. If the diagram was done well, it should tell you the data types your attributes, method parameters and those returned by your methods are. It should also tell you if your attributes and methods are protected, public or private. If you class diagram has any inheritance relationship between classes, you should also make sure you transfer that in the code. For example with the word “extends” in Java or JavaScript. And that should be it. I told you it was simple.

If you want more information on how to create class diagrams or what to do with them, be sure to check out my other posts:

• Mastery 06 – UML Part 1
• Mastery 08 – Classes to Tables

HFOOAD Chapter 7 – “Bringing Order to Chaos”

If you have a big project and you already have all the features, but don’t know what to do next, you are in the right place. This chapter talked about how to choose the order in which you are going to develop those features and it also talked about risk which is extremely important to consider in any project.

The previous blog post HFOOAD Chapter 6 – “My Name is Art Vandelay… I am an Architect” I talked about how to tackle a really big software problem, I recommend that if you haven’t read that already, please do, it will help you understand what I’ll talk about later on in this blog post.

So, let’s start. You have your features list and want to know where to start. The book recommends that you start with the most important features your project needs. To identify those called “key features” you need to ask yourself three questions for each feature:

1. Is this essential to the project?
   Can you imagine your project without this feature? If you can’t, it most likely means that it is a key feature.
2. What does it mean?
   If you are not sure about what that feature means, that feature is significant because you probably need to talk to the customer some more for him to explain the feature to you.
3. How do I do it?
   If you don’t know how to do it or think it will be difficult, you should focus on this early on to reduce risk.

As the book explains, the three questions above are the three Q’s that help you identify where you should put your attention early on in a project. After you have identified the key features, you must identify the order in which you will develop these features. To do that, you should think about the risk involved in not doing something first.

When you have done all of these, you are ready to start and keep developing feature after feature until your project is done.

References

McLaughlin B. , Pollice G., West D. (2006). Bringing Order to Chaos. On Head First Object-Oriented Analysis and Design: A Brain Friendly Guide to OO&A (640). O’Reilly Media.

SimSE

I played the Waterfall version because that’s the model that is the most familiar to me. I really enjoyed the game. It was a fun experience because you act as a project manager and have to know what to do with your employees in order to get the project finished in time. After my first 30/100 as a score I tried again and got 76 so, that’s nice.