The new blog is up and running!  This one may be updated occasionally but here is where the action is.

Follow me on Twitter here

When I teach I try to interject as much real life experiences into my lecture. Sometimes these border on somewhat cynical, but none the less realistic (especially my project management lectures). But, these are classic and and if you stick with it, Joel has a serious good lesson in there. The best lessons learned in college are not the ones intended to be learned and learn to communicate well.

Here is part 1, part2 and part 3 of his talk.

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

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

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

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.

I am looking around my place and as I get ready to move I see a lot of the boxes are books.  Now I don’t just read technical books, but I am always in the middle of one or the other and have a couple on standby, ready to be read.

In my normal daily blog scanning I read Top Ten Must Read Books  for the Java Developer and since he referenced this article with the same theme and I had read that one before I decided to throw in my two cents.

There is no disagreement with any books listed. For Java programmers, as long as you have Effective Java and Thinking in Java in your library, you are on the right track.  However, let’s add a couple.

1) Test Driven Development, A Practical Guide – Author David Astel’s superb introduction to the concepts of TDD with some really good examples.  This compliments, I am told, Kent Beck’s TDD book well.

2) Refactoring Databases – Scott Ambler and Pramodkumar J. Sadalage cover an important topic of refining and improving our application’s data.  I read the first few chapters as an overview to the subject and have and will continue to use the rest as a reference.

3) Pragmatic Programmer – Should be required reading for any developer.

4) Definitive Guide To Grails -  I believe you need to understand the growing market for languages such as Groovy and Ruby.  I chose this one as Groovy is based on Java technology and Grails uses some very familiar technology such as Spring and Hibernate underneath the covers.  Read as an options for testing your Java applications if nothing else.

Finally, anything by Steve McConnell….

If you read the two lists linked to at the beginning, take into consideration their recommendations and add in my minor contribution you have a pretty good start on some great reading.  Enjoy.

This is part two in a series called Introduction to UML. In this section we will look at some basics of Analysis and Design and methodologies. Part one looked at a history of UML and some of the drivers behind the need for a standard modeling language.

Modeling is the design of systems and specifically in our area of interest software applications. The model can be compared to a plan when building a ship or a floor plan when building a house. They are used to assure themselves that business functionality is complete and correct, needs are met and the design supports the system requirements (i.e. scalability).

We all have read the statistics on success of software projects and the probability of success. Therefore, modeling should be a key player in increasing the odds for a successful completion of a project.

UML is used to specify, visualize and document models of software systems. It is not a methodology, it is the notation or common language used to specify a system. How you use it is not specified, or specifically the methodology. Go to

http://www.cetus-links.org/oo_ooa_ood_methods.html for a very (almost exhausting) description of methodologies.

Analysis and Design

At this point it may be beneficial to make the distinction between analysis and design. Analysis is the specification of a system’s requirements as an object model. Basically analysis determines the technical and business drivers, specifications and boundaries to gain a thorough understanding of a system. This is highly important as the main determiner of a successful software development project is user satisfaction (or the covering user requirements). If you fail to analyze a system or existing process properly it will be very difficult to build software that users are satisfied to use.

Analysis overview: http://www.sei.cmu.edu/str/descriptions/ooanalysis.html

Design on the other hand is concerned with the development of an OO model of a system that will satisfy the requirements. Two main goals beyond the obvious implementation of the requirements is maintainability and reusability. Maintainability is accomplished through simplified designs due to a deeper understanding of the problem domain. Reusability is attainable through the same understanding and mapping to the features of a particular object-oriented programming language.

Design overview: http://www.sei.cmu.edu/str/descriptions/oodesign.html

Software Development Process

Earlier it was mentioned we would not cover the process for OOD&A or methodology. There are hundreds of books and many well-known methodologies to choose from. However, irregardless of the process, the following steps must be performed.

  1. Requirements Capture – this is where the requirements of the system are understood. It is important to be able to do this in a language the users can understand or as it is called in the “problem domain”.
  2. Analysis – this is where the requirements are taken and one starts to mold into a possible solution or in the “solution domain”. An abstract manner is used, in other words it is kept at a high level.
  3. Design – the specification from the analysis phase is taken and a concrete solution is defined. This is done in full detail.
  4. Build Phase – the design is used as a base to actually program in the chosen programming language. This is just not programming, it is also testing to ensure requirements are met, testing that it solves the customer problem and documenting the system.

There are two basic ways to develop software, one traditional and one modern (I believe all software development methodologies are derived as a basis from these two foundations).

Waterfall Method

This is where each phase of the software development process is completed before the next phase is started. One downfall of this method is that it is often impossible to understand the requirements completely at the start of the project. Second, code does not become available until late in the project.

As you see, like in a series of waterfalls, once you move down to the next level it is extremely hard to get back to an earlier step.

Another negative point is that each consecutive step in the process requires more effort and this is increased if a phase needs to be revisited. This is depicted below. A basic premise is modifications in a software development project are cheaper the earlier they can be made.

Iterative Method

The iterative method has as its main idea getting some code produced as soon as possible and then highlight any problems early in the development.

One way to visualize this is by looking at the development process as a series of small waterfalls. The analysis, design and build phases are first performed for the most important requirements and then after user feedback they are repeated and more of the requirements are covered. This continues until all requirements have been satisfied.

One advantage is the work is done in manageable pieces of work and project managers can retain an overview of progress.

Agile methods, such as Extreme Programming, Crystal or Scrum, have gained a lot of attention lately. This again heavily involves users in the entire development process and has some unique characteristics such as turning the requirements into test cases, pair programming among others.

Agile methods usually follow these general principles.

· Individual and interactions OVER processes and tools

· Working software OVER comprehensive upfront documentation

· Customer collaboration OVER contract negotiation

· Responding to change OVER following a plan

For more information on Extreme Programming go to http://www.extremeprogramming.org/.

 

This is a multi-part posting discussing the Unified Modeling Language (UML).   The first part will look at the history and drivers that were the catalyst in creating UML.

How did we get to where we are at today?  Understanding the drivers and history behind a subject can help one to get a get a complete understanding of a principle or concept.  This is certainly true in this case.

Why was UML even invented?  It was mainly the wisdom and intuition of a few people in understanding that a standard and organized way for people to communicate when designing systems can only be beneficial.

In the 1980’s and early 90’s there were a myriad of design methodologies.  These came about because of the sudden popularity of object-oriented programming languages (C++. ADA, Smalltalk, etc.).  Naturally there were design methods before this time, even object-oriented ones but the popularity of C++ created the need for a new approach.  Most design methodologies before this were data driven and/or functional in nature.  When programming in an object-oriented language they were found to be not adequate.

Some of the methodologies that became popular were Rumbaugh OMT, Booch, Coad-Yourdan, OOSE from Jacobsen and Shlaer-Mellon to name a few.  All were quite good in certain areas, but seem to not cover the whole design process.  In other words, one had as a strongpoint the requirements gathering where another concentrated on the sequence of events in a system.   Also, each methodology had its own type of notation, often similar but different enough to make it hard for someone knowledgeable in one methodology to have trouble understanding another designer’s work and the associated notation.

At this time developers adapted their favorite method and even adapted these into their own hybrid design methodology, splintering the industry even more.  We then had the so-called “Method Wars” where people argued endlessly the pros and cons of their adapted methodology.  If anyone has ever heard a developer discuss his pet programming language, you will know this group can be quite religious about their beliefs.   On top of this, consultants had bookshelves of books and needed to learn different methodologies dependent on their client’s needs and preferred method of design. 

Finally, around 1994-1995 three design creators, Jim Rumbaugh, Grady Booch and Ivar Jacobson joined forces at a company specializing in design tools called Rational (the distributor of the Rational toolset and now part of IBM).  They became known as the famous “three amigos”.   They declared the “Method Wars” over and soon came out with a first release of the Unified Modeling Language.  While there was still some disagreement, this was overcome when the standards body, Object Management Group (OMG), decided to adapt UML as a standard design modeling language.  Note, the OMG is the same group that came out with many other standards, including CORBA.

Within a short period this became the standard for Object Oriented Design and Analysis (OOD&A) and almost all major players in the industry proclaimed their support for UML.  This has probably single-handedly brought the software development industry further than any other single accomplishment.  Currently the UML standard is version 2.1.1.

- UML introduction and further information can be found here.

- UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition by Martin Fowler.

This hilarious look at acronyms for development methodologies has been mentioned a few times in the blogosphere but if you haven’t read it yet, do!   And how many of these types of people or situations have you experienced?

Follow

Get every new post delivered to your Inbox.