A use case is a description that lays out the interaction between the user and the piece of software in question. A use case details the a specific task that your program should do. Use cases describe the What of your application. A good practice is to write a use case for every software requirement that your software must comply with.
What must a use case have?
First of all, according to the book. A use case must add value to your application. It should define something that is integral to your program. Second of all, the use case should have an external trigger. Something should jump start each use case. Lastly, the use case should have a clear start and an ending. A use case usually comes as a series of sequential steps.
Why are they important?
A use case can reveal holes in your software requirements. Because a use case requires you to be specific and list all the steps needed to accomplish a task; it helps you to notice certain missing requirements. It can also make you found out about things that your customer forgot to tell you.
Scenarios
A complete path through a use case from the first step to the last is called a scenario. A scenario might have multiple paths. However, they all end in the same user goal.
This is a topic that we’ve seen in our introductory course on Software. It is a really big and important concept that all sofware engineers need do know. In projects that I’ve had the requirements are probably one of the hardest things to get right. Most of the time we come back and make some adjustments.
The customer doesn’t really know what he wants
This is something that makes laying out the requirements very difficult. How can the developer define the requirements when even the customer doesn’t know them either. Maybe that’s why most of the time Apple doesn’t listen to its customers altogether.
The use cases
This is also a topic we saw in an earlier class. Although the book covers three things that a use case must have that I didn’t know about. Basically the use case must add value to the product. Have a clear starting and stoping point and finally the initiator must be an outside trigger.
Another thing that captured my attention was that the use cases actually help to find things that the customer didn’t tell you. That is very useful. Writing use cases can also find holes in your requirements. In conclusion use cases are very important for the product to fulfill the customer’s needs.
The Unified Software Development Process is a very popular standard software development proccess based in UML. It is a use-case and risk driven proccess. It is iterative and incremental. In each iteration various processes are made.
The Iterations
Every single iteration is like a mini-project. It contains different steps. These steps are the lyfe cycles that we covered in the Mastery 01. Planning, Design, , implementation, Test and deploy. The final result is reached through a sequence of iterations.
Every iteration may contain all of those steps, in each iteration the emphasis of each step varies.
When an iteration ends, the result of said iteration is called an increment. An increment is the difference between the result of the previous iteration, with the next iteration.
Phases
USDP consist of 4 phases. The number of iterations within each phase varies and is dependant of the size of the project. The 4 phases are the following: Inception, Elaboration, Construction and Transition.
Workflow
As we’ve discussed, in each phase the emphasis of work varies. In the following graph we can see this.
On the right we have the steps of the life cycle of software development that we’ve already talked about. At the top there are the phases of the Unified Software Process. The line represent the amount of work that is put on each phase. As we can see, in the inception phase, the requirements and the analysis is the most important aspect. These steps become more important in the Elaboration phase. At the end of this phase the importance of design peaks. In the construction phase the implementation is the focus of the work. At the end of this phase testing peaks. In the transition phase, testing is the most important thing.
Inception
In this phase the feasibility of the project is established. The key requirements are laid out. In this phase the critical risks of the project are defined.
Elaboration
In this stage the risks are heavily scrutinized. The quality attributes are defined. The use-cases are written. A very detailed plan for the construction phase is worked on. Another important goal of this phase is the formulation of the resources, time, staff and cost.
Construction
This is probable one of the most time consuming phases. In this phase the use-cases should be completed. Here, most of the time is spent on the implementation.
Transition
As we’ve mentioned erlier. This stage is all about refinement and getting ready for deployment. Bugs are fixed. Defects are corrected. Another imporant thing is the user manuals and the documentation.
The Life cycle, also known as life cycle of software development (LCSD) is the procces that a piece of sofware goes through. In this section I’ll talk about the different stages of the LCSD.
1. Planning
This is the first stage. On this stage the requirements are layed out. The software requirements are very important, since the sofware is going to be based on this list of requirements. These are what the application needs to be able to do. They are usually expressed as a user case. For example; the user should be able to make an account. The user should be able to log in. The user should be able to log out.
2. Design
This stage takes the requirements listed in the previous stage and begins to plan the product. Things like the layout are planne. The color sheme is also agreed upon on this stage. This part may be overlooked as uninportant. But the color sheme can say a lot about the company and the product. In this stage the programming languages are also defined. The frameworks are also a big part of this stage. One big question could be what type of data base to use. Relational or Non-relational. And if one choses a non-relational database we still have options on what databes management system to use. MongoDB and Cassandra are good options with different advantages and disadvantages.
3. Implementation
This is probably the one that most of us jump straight into and find the most fun. The programmers will start to write code. The designers start to plan the user interface. In this stage one may realise that something in the earlier stages of the cycle was not planned correctly and go back and change things accordingly.
4. Testing
This is a very important stage. Problems and bugs are searched in this stage. It’s important to rigorously test because some flaws can cost the company a lot of money. On this stage the requirements are checked to see if they were met.
5. Deploy
On this stage the servers will be ready to be installed. This stage includes setting up the links and the data bases. In this stage the application goes live to the users.
6. Maintenance
On this stage we need to maintain the servers. We need to see that the users are not loading the servers and bringing down the system. Maybe we need to make larger servers or larger databases. There’s a lot of things that go in this stage but it’s basicaly about keeping the product functional
This chapter was quite interesting as it detailed some of the most important and basic principles of OODA. I think it is certainly useful to have this concept in mind when working on software. I am excited about what the knowledge this book is going to give me.
The basic principles of OODA
The first think that was maybe obvious but certainly helps to keep in mind is the question what makes great software. It’s easy to see that a good software is one that does what the customer wants. Altough there certainly are disagreements with this premise. Steve Jobs is a textbook example.
Encapsulation
Another principle of OODA that was talked about is the encapsulation principle. I can see why it is usefull, although I think that in the chapter this principle wasn’t very well explained. I undersood what this principles means but the implementation that the book made I think wasn’t the best.
Thinks I didn’t like
The most talked about thing of the chapter was of course the search() method. It was the most complicated and the most important in Rick’s application. The main think I didn’t like about the implementation was the matches() method in the GuitatSpec Class. I think it shouldn’t return a Boolean. A match like this is not a white or black thing. It should return an int in my opinion. This int would be the metric to measure the match.
This blog is called Cellar Door Blog. Throughout the course I’ll post summaries of the course’s book – Head first; Object Oriented Design and Analysis. Likewise, this blog will also have “Mastery Topics”. These are various topics that I’ll try to master and explain.
This blog will now contain entries for my Software Quality and Testing course
Cellar Door
You may be curious about the meaning of the blog’s name. I wanted to have a pretty name for my blog. In one of my favourite films Donnie Darko (2001) there’s a scene where the phrase Cellar Door is introduced to the viewer. This is a famous phrase on Phonaesthetics, the study of the beauty of words and phrases purely on the way that it sounds. According to the New York Times (2010) numerous writers and poets have regarded this phrase as one of the most beautiful on the English language (para. 2).
Cellar Door Blog 