Introduction to UML, Use Cases – Part III

OK, we are now ready to start exploring UML. The one point worth repeating is UML is not a method or process (such as RUP). It is a modeling language and defines a set of notations and associated rules for designing systems.

Note, UML is most often used for designing software but it is not tied to this industry. UML can be used for modeling any system, such as an airplane or car.

UML defined twelve types of diagrams. These are divided into three categories which are structure, behavior and model management.

Ø Structural Diagrams – class diagrams, object diagrams, component diagrams and deployment diagrams

Ø Behavior Diagrams – use case diagrams, sequence diagrams, activity diagrams, collaboration diagrams and state chart diagrams.

Ø Model Management Diagrams – packages, subsystems and models

Diagrams in the Development Process

Where are the diagrams used in the development process? This is often one question asked by people learning UML.

Ø Requirements Gathering – use case diagrams. Often a “Vision Document” is also created to document business drivers, influences and overall goals of the system. As was mentioned before, use cases are done in the language of the problem domain, which is the language of the users. For instance, terminology is used that accountants understand in describing a book keeping system.

Ø Analysis – high-level class, sequence and state chart diagrams. Use cases are revised from the language of the problem domain to the language of the solution domain.

Ø Design – package diagram to describe the structure of the system. Class, sequence and state chart diagrams are revised. Component diagrams are used to describe system architecture and how pieces of the system will work together. Collaboration, object, sequence and activity diagrams may be used. Finally, deployment diagrams are used to show how the system will look when installed.

Ø Build – actually none of the diagrams are specifically used in this phase, though use case diagrams should have considerable input to testing.

A lot of designers champion the idea of not drawing a diagram for the sake of saying it has been used. As a minimum use cases are usually done to understand the requirements and class diagrams for design of the system.

So, with this introduction behind us, we will start looking at the different diagram types.

Use Cases

Working through a process is not new in software development. This is what we call scenarios and the benefit of this was realized very soon by software developers. However, they were not often documented or at a minimum and in a manner that was difficult for users to understand.

When working with use cases in the initial stages, Requirement Gathering, the language should be the language of the users and one should attempt not to think of solutions. This is important for gaining an understanding of the current system without outside influences (This is easier said than done).

The roots of Use Cases came from Ivar Jacobsen and his Objectory method. He was the one who started calling them use cases instead of scenarios. When he joined Rational they became a core element of UML.

 

A Use Case is used to describe an interaction within a system. This may be a user or another computer system. Uses cases have the following properties:

Ø Captures some user visible function

Ø May be small or large. There is no specified size.

Ø It achieves a discrete goal for the user

 

Use cases are described by talking to different users and discussing (in their language) the various ways they may want to use the system. This is of course built on their experience with the current system or manual processes.

 

Often the best way is to give this a name and write up a paragraph on each interaction. These should be reviewed by you to see similarities and to make sure you are using a common language and naming conventions (that are the same used by the users).

Also, the granularity (the size or detail), of a use case is not specified. Again, this depends on the person gathering requirements and the type of system being studied. Some experts suggest that a project should not contain more than 30 use cases. If there are more, it possibly should be broken into sub-projects.

Two main components make up a use case. They are Actors and Use Cases. Below a very simple use case is shown.

Simple Use Case

This shows 4 actors and 3 use cases. Notice how actors have interaction with multiple use cases and that an actor does not have to be a person (though shown as a stick person).

Actors

Actor is a role that a person or system plays with respect to the system. An actor is not a person, a physical person may play multiple roles with a system and multiple people may carry out a role.

One hint often given when doing use case diagrams is not to start with use cases but instead start with a list of actors. Then it is easier to determine the use cases, which is the ultimate goal. Actors are important to see who uses which part of the system and determine conflicts as well as configuring the system for different users.

Use Case

A use case is a name of a process, interaction or scenario (take your pick!) in a system. In our example above we had three, Maintain ATM, Use ATM and Audit. The use cases are interactions with the system and you know that the resulting system will need to implement this requirement. How many use cases are specified is one point of argument. It is usually specified as many as are needed to understand the system to the level you want. The beauty of iterative development is that you don’t dig into the details until you need to. Also, as in the case above if you can take a use case such as Audit and understand this function and which actors are involved, you don’t need to do go any further (for the moment).

Association

An actor will have an association with a use case. This is shown with a straight line. Normally they are simple straight lines, though arrows may be used. When an arrow points to a use case this means the actor is active. Active means they initiate the interaction. When the arrow points to the actor, the actor is passive. This means the system initiates the interaction with the actor (often external systems).

 

Extend

Also, use cases may have an extend link between themselves. This is generally the used when there is two use cases that are similar and one does a bit more than the other. This is done not to “clutter” and existing use case. This is shown with a link between two use cases and the arrow pointing to the general use case and away from the more specific.

Extension of a Use Case

Include

An include link is used to decompose a use case into smaller interactions. This is done when an initial use case was at such a high level it became difficult to describe it or as you learn more it became bigger than at first sight. This is done as shown below. Notice the dashed arrows with the arrows pointing to the sub tasks. These in turn will probably become use cases in their own right.

Use Case Includes

To learn more about the Use Case technique and an excellent book on object oriented design in general see Object-Oriented Software Engineering, A Use Case Driven Approach by Ivar Jacobson et. Al.

 

Google Docs

I am in the middle of transferring everything I ABSOLUTELY need to Google Docs if my hard drive should crash. I knew Google Docs existed for ages, but this is the first time I have used it. It is amazing! I love the bulk add via email, the ability to save in different formats (e.g. doc to pdf), add tags and as you see below the ability to post to a blog.

Note for application designers/developers; it is the little things that matter once you get the application is working.  Details are everything. They don’t overload it with features, but the ones there are useful and they work.

Although the formatting is not great, I published my CV from Google Docs to this blog, as you see in the “post” below. Love it.  Here is a link to it Brian’s CV.  This link was also created within Google Docs.

 

Some Tips..

What do you think of these tips?   They come from a code peer review we did and their origin is from various sources.

 1) Then anyone handling it does not need to handle null values, can just use the normal iterator for the array or collection.  Although people argue performance is a reason to return nulls, this is not worth worrying about.    If you are worried about it, create a constant zero length array in your program (so it is only created once) and always return this. 2) Only one return per method?3) Only one catch block per method (can be multiple exceptions chained) and not two different areas in a block.4) Declare variable where they are first used in a method? Not all at the top, though they will be used at the end.

5) Keep method names from being too long, but descriptive.

6) Be wary of deep class hierarchies.   This usually means something is wrong with the design. 

7) Declare constants in an interface.

I am not saying I agree with all of this 100%, but arguments can be made…. 

 

No Silver Bullet

In a recent interview I was conducting with others I asked one of the questions I love to ask. What were the last two books related to SW development you read and in a sentence or two your opinion of it? After some hesitation and mumbling the candidate brought up Frederick P. Brooks, Mythical Man Month. OK, not a bad answer. Taking him on his word he had just read that. I didn’t test him, he gave a decent enought reason. His other answer was “a lot of BEA documentation”. Not very good….
However, this made me think of another piece from Brooks although I had read it a long time ago, No Silver Bullet: Essence and Accidents of Software Engineering. If you haven’t read this I would encourage you to do so. Joel Spolsky in his Joel On Software blog commented on it here.

By the way, looking for a job. If you have had enough B.S. from people calling from the normal job sites take a look here. It is the Job Site from his Website Joel On Software.

 

Lightweight Project Management – Part III

This is Part III in my lightweight overview of free project management tools. Part I covered some basic topics and Part II took a closer look at Basecamp, the first of the two tools I am covering. The third “installment” will look at a tool called Zoho Projects

First to the company, Zoho. In part two I spent less time talking about the makers of Basecamp 37Signals because most blog readers have heard of them either from their tools or as the creators of Ruby On Rails. Well, Zoho is quite an impressive company and although I had not heard of them until I ran across Zoho Projects, maybe some of the readers have. If you want an overview check out their website and read their blogs. They have an amazing set of tools available. Zoho Show which is an online presentation application, Zoho Writer (word processor), Zoho Sheet (spreadsheet), Zoho Virtual Office (collaboration tool), Zoho CRM, etc. I have looked at a few, seenonline presentation from Zoho Show and they are all incredible tools with free versions usually with limited users. All I can say is go to the site and have a look. It is amazing what is available.

OK, now to Zoho Project the actual subject for this blog. (As I mentioned in Part I this is a Beta version as of now, but you would never know).

Zoho Projects provides many of the features such as Time tracking for team members that are in paid versions of Basecamp. Zoho allows a more traditional view of your project with tasks having date assignments, due dates and able to track percentage of completion.

The reports in Zoho allow a task calendar view as well as a milestone delivery date. Zoho, being very Web 2.0 provides visual feedback at the mouse cursor almost every where you go. Putting the mouse over the calendar on the right side where a mile stone will cause a small bubble window to appear with Milestone information. Also, in the Calendar view you can simply put the mouse over a particular date and three icons appear for create a task, milestone or meeting.

When you go to the website you sign up by providing a email address which is for th administrator, base name for the URL like in Basecamp and password. Your project URL will then be <basename>.zohoprojects.com. When you name your project, you are ready to start defining it. Currently one project is allowed per admin email address.

You can add users that will either be employees, managers or contractors. Below is an empty dashboard view of the project.

Some really cool features are the Latest Activity section in the Dashboard so you can see what exactly was done to the Project Plan you are making, including deletions.

As in Basecamp you can enter tasks but as I mentioned there is more information that can be entered. I think the biggest difference (didn’t I say I would not compare them, oh well) is Basecamp is the minimalistic view (this is actual a theme of the company 37Signals, only do what is needed and nothing more) and Zoho gives you more choice to add more information. I like this approach too, you don’t have to do it, but if you want the opportunity is there.
Here is a view of the tasks and milestone page with a couple of tasks and milestones defined.

Milestones are similar to tasks only have the same start and end date. When milestones are created you can also add tasks under them that need to be completed for the milestone to be completed. This is shown below:

Another nifty feature is the ability to track time working on a task. If you enter the Timesheet Calendar view you can select a date and log time for that day to specific tasks. This is also a feature in Basecamp, but again in the paid versions.

I hope this quick overview of Zoho Projects may have wet your appetite for trying out the extensive feature set. Zoho is really impressive and I am sure it will be getting a lot of press in the coming weeks/months.

I am looking forward to presenting Zoho as well as Basecamp to my students as I believe they both provide an excellent method to manage your projects.

 

Lightweight Project Management – Part II

In part I of this series I explained the background of what I am writing about, reasoning for looking at project management planning software over MS Project and introduced the two products, Basecamp and Zoho Projects that I am going to cover. In part II we will look at Basecamp.

Many of you will have heard of Basecamp and even maybe have used it. Basecamp, according to its website has over 500,000 users and you can read loads of accolades. It is no doubt a great product and I am not going to crritique, just run through a highlight of its features.

Basecamp comes in different pricing models, I have only used the free version. You get a lot of functionality in the free version but there are limitations such as you can only manage one project at a time and advanced features such as Chat and Time Tracking are not present. Note the chat is provided by integration of one of their other products called Campfire, which you can also sign up for separately for free. The drawback is it is not integrated with your project.

Here is an overview of the different pricing models and their features (as of 16 Sept, 2006).

Basecamp Pricing

As you can see, you can get a version with all the features and the ability to manage 35 projects for $49/Month.

What you will notice when you work with Basecamp is its incredible user interface and broad spectrum of possibilities when working with the product. It is really amazing for a web application what they make possible.

When you sign up for a Basecamp account you need to enter some basic information, including a base url for your project. This becomes part of the URL to your project. Once this is done you can upload a logo for your company, change the coloring scheme and grant access to other team members (users). Finally, you select the link to Create your first project. After giving this a name such as “Project Management Class” you will be ready to start defining the different components of your project.

Messages are the first component we look at. These are where you provide basic project information for your project for other team members, important links to web pages and documents. You have formatting possibilities such as bold and italics easily built in with formatting characters. You can also select from a list of provided categories or create your own, attach a file to the message and finally select project members to send an email to. This is your basic communication method in Basecamp. Below is a simple example of a message:

To Do Lists provide organization of tasks. They work by allowing you to organize, prioritize and assign items in the to do list to team members. Note that to do lists do not have dates assigned to them. Tasks with assigned completion dates are milestones, which we will look at later. I like this idea, the general idea is we need to get these done at some point, but no exact date. Also, along the lines of the project management pronciple of more than one person can work on an item but only one is responsible you can either assign to Anyone or to a single team member.

Milestones are assigned items with a specific due date. You name the milestone and provide a date. Users of MS Project will recognize this concept with a task of 0 days length and a diamond in the Gantt Chart.

You can also assign the milestone to the team or a specific team member. Also nice is that in the Dashboard view you can see a calendar view with easy overview of when milestones are coming due. Milestones can be view milestones in Apple iCal and Mozilla Calendar. By checking a milestone you mark it as complete. Below is a view of milestones, notice the reminder of an overdue reminder.

Also available in the free version are whiteboards and chat sessions through 37Signal’s other products.

Does this seem simplistic? It does and that is the beauty in the approach. Once you spend a day setting up a project in Basecamp you will come to appreciate the simple and effective way it allows communication, tracking tasks and deadlines. You can share documents, work on versions and even chat with other members. Email reminders simple screens make sure confusion and updating is an easy task.

In summary, Basecamp insures you spend your time working on what is important and provides non-obtrusive support for your project planning needs.

 

Lightweight Project Management – Part I

When teaching Project Management, I often have the feeling I am struggling to make the class interesting and relevant.   Since my audience consists of senior undergraduate level students and it is a required course I face two hurdles:  1) Many would not choose this course if they did not have to take it; 2) Most (99%) have no experience in Project Management, even as someone who had worked under a project manager.   I do have an occasional adult student who has some experience.   So enough whining, what is my point anyway…

I do stick pretty close to the book with my lectures, the very good book from Kathy Schwalbe, I am always giving a lot of thought to what I can do as a value-add and make the course more interesting.   Most of these students have not started their careers yet, not even sure where they want to go with their careers and certainly are not looking for a PMP certification.  One thing I do is assign a group exercise where they are required to research and present an assigned topic such as eXtreme Programming, RUP, Scrum, MSF (Microsoft Solutions Framework, etc.   This gives them an insight into the software developmnent lifecycle and differing methodologies.

Since the book mainly uses MS Project as a software project planning software example, I have decided this semester to show some other examples.   I am not knocking MS Project, I also decided to go over some lightweight methods of organizing projects verse the heavier method MS Project provides.

So, I have chosen two examples.   These are:

1) Basecamp – a blurb taken from their website states: Basecamp turns project management and collaboration on its head. Instead of Gantt charts, fancy graphs, and stats-heavy spreadsheets, Basecamp offers message boards, to-do lists, simple scheduling, collaborative writing, live chat, and file sharing.

2) Zoho Projects – again from thee product website a short description of their goal.  Zoho Projects help teams organize their work & track progress. Most of the project management software takes longer time to setup & it becomes a overhead in a project. Zoho Projects is designed to make sure Planning & Management takes lesser time than the actual work.
Basecamp is from the same company that brought the world the Ruby On Rails phenomenon.  They have several other collaboration products available such as Campfire, Backpack, Writeboard and Ta-Da List.

A couple of notes/disclaimer.  First, you may ask what problems these are products trying to solve?   Microsoft Project works fine, it has all the functionality I need from a project planning software tool.  Again I repeat, I am not slamming MS Project it is a great tool for many projects.  This is only a different perspective.  You are right, that is the point.  It can have too much functionality.   These products are trying to be effective by being simple.   A software planning tool should assist the development team in delivering software, not become a project in themselves.  Often maintaining the project plan becomes a horrendous task taking up way too much time.  I have experienced this myself, all the charts, reports and task lists (Work Breakdown Structure) become tedious to maintain.  These products are providing a lightweight manner to maintain tasks, resource assignments and the communication.  These products would work great with a development methodology such as Scrum which is meant to be lightweight.
The disclaimer is that I have used the free versions of 37Signals products for my own use and am a big fan of them.  Basecamp is a very capable product that has been available for some time, Zoho Projects is in beta.  I am not going to compare the two (though will be inevitable it may happen) but attempt to explain my view of how each works.

In installment two I will start looking deeper into these two lightweight project management products.

 

Interfaces

When I am teaching Java to my students or mentoring a junior person on the job they often ask for some tips to become productive in Java.  I have always believed that a solid foundation in generic object oriented concepts and techniques and an understanding of how these relate to programming in Java.

Going Public

In object oriented systems objects define their behavior through their exposed behavior.  In Java this is through their public methods.   Often people will call the methods that an object exposes its interface.   The most common example I have seen is your television set and the remote control (who uses the buttons on the front of their TV still?).   The remote control defines how you interact with your television.

As a side note, interfaces in Java are often portrayed as a way to circumvent the lack of multiple inheritance in Java that is present in other languages like C++.  While you can implement a form of multiple inheritance and it does solve what C++ critics like to call the diamond problem, this is not where I see interfaces being useful.  I spent a lot of years writing C++ code and do not remember consciously using multiple inheritance anyway.

Contract & Polymorphism

For me interfaces provide an elegant way to implement polymorphism as well as making sure my public interface (this is the interface that means the exposed methods) conform to what is expected.

First to polymorphism.  If you need a refresher here try this.   If you need more help there are thousands of definitions, tutorials and articles on the web.   Interfaces allow me to work with the interface type in Java and not worry about which object I am currently referencing with my interface.   A good example of this is found in this article.  I think in this context interfaces are a nice, simple and lightweight solution verse using base classes etc.   Think of the standard example with an interface  type Shape and implementation classes such as Square, Circle and Triangle.  The interface declares a method Draw and each implementing class must know how to draw itself.   I like this, it makes sense and it is elegant. 

OK, what about forcing a public interface.   This is called Design By Contract.  You can do this by documenting that anybody who wants to implement a class within this hierarchy HAS to implement a method or a set of methods with the signature as specified.  But, who is going to make them.   For a good example of this, think to when you do Swing programming.   You want the system to call an event handler after you have registered a component with the event handling subsystem using the addActionListener(this); method call.    The event handling subsystem will then call a method called actionPerformed(ActionEvent event) when an event occurs.   But how can you be sure this method is implemented, with the write name, in correct case and the right parameters.   By implementing the interface ActionListener.   By declaring your class with the words implements ActionListener all of this will be guaranteed and enforced by the compiler.  So this is a formal way to make sure you deliver what you promise.

So interfaces aren’t about multiple inheritance and were not included to make up for the lack of this being present in Java.  They are for: 1) Elegant way to implement polymorphism;  2) Insure your classes deliver the public interface you promise.

powered by performancing firefox

 

A Great Technique, Take A Break…

I am just coming into day two of teaching the Programming I course. This course should be a real challenge, there are 21 students!!!  That is by 6 the most I have ever had in this course.  My project management course had 28, but that requires less one on one interaction.

By the way, one of the things I love about teaching the University of Phoenix online courses is that I have students who live in places ranging from the northwest, CA, across the USA, the east cost and even Guam (actually 2 of them who found out they know each other and live there but didn't know they were attending the U of Phx!).

Anyway, in the first few days the main gaol is to get everyone to the same level. This involves getting everyone with the same JDK installed,downloading a text editor and getting their first app running. For a text editor I recommend JGrasp but don't enforce it.  The next step they need to create a program that prints their name or the proverbial "Hello World" just to show they have everything installed.  The students, though generally very experienced in their careers, quite possibly have not had a lot of experience programming.  Most have done one other programming course in C at this point.  Therefore some get frustrated when they cannot get their programs working.  This is 99% of the time 1 of 2 problems. 

1) They did not name their public class the same as their Java file.

2) They had something in lower case or at least the wrong case.  For instance system.out.println instead of System.out.println. 

You can imagine this becomes very frustrating when you first start out.  Therefore I have always recommended when you reach the boiling point to walk away and do something else for awhile or at least go away and write it down on paper.  This always worked for me and seems to be a great method to see the "forest through the trees".

Therefore I was really happy to see this entry on the Hacknot.info website.  Especially the portion with the text Take A Break as this was almost word for word what I tell my students.   

What other useful hints do people have that I could pass on to my students?