The Object Oriented Way

When analyzing a problem from an Object Oriented point of view, the first things that are usually identified are actors and use cases. An actor is an external (from the system point of view) entity that communicates with the system through a use case. A use case is a generic scenario that illustrates the different services that the system should provide. Use cases are useful in a very preliminary analysis stage but are also interesting to document the system behavior, once the design phase has finished.

Once the basic behavior of the system has been exposed, we are ready to accomplish the most important and maybe difficult task in an Object Oriented process: identify classes. This identification may be performed following one of the following approaches: (1) the application domain is analyzed and classes are identified as ``important'' entities that belong to the system (as opposed to actors); (2) instead of identifying classes, we concentrate on identifying objects and the way they communicate, classes are later extracted from grouping objects that have an identical behavior.I would recommend a mixed approach. First identify most important entities in the system and relations in between them. This step does not need to get into much detail so attributes and operations do not need to be completely identified. Then, scenarios should be illustrated, analyzing objects and messages in between them. This step will surely bring to light new classes that had not been previously identified. Class operations will also be obtained by analyzing messages between objects. So, afterwards we can iterate on the first step (class identification) and repeat the iteration as many times as needed.

When identifying classes we are partitioning both the problem domain and the resulting system. An abstract and probably complex problem is methodologically converted into a number of classes. Each class should have a strong internal cohesion and low coupling should exist between the different classes (see [Larman, 2002]). Following this process a new model of the ``complex'' system is obtained by partitioning the problem into smaller problems that can be treated more easily.

A well defined object oriented model of a system has a more or less direct mapping into the final program code using an OO programming language. Most Computer Assisted Software Engineering (CASE) tools are thus capable of generating code from a well-formed class diagram plus some information about the dynamic behavior of objects (i.e. some sequence, collaboration, state or activity UML diagrams).The Unified Modeling Language (UML) is the standard used for depicting all the different steps in the OO lifecycle. UML is a language, not just a notation. As such, it includes vocabulary (i.e. definition of basic concepts), notation (the graphical way to represent model elements), and rules (guidelines on how to use notation).

Figure 1.1: Sample UML Class Diagram

The Object-Oriented paradigm and related processes define a different way of doing things. This has led to the upcoming of different methodologies that, although not strictly restricted to, are especially fit for the object-oriented paradigm and represent a step forward from the traditional waterfall model. One of the most important object-oriented methodology is the Rational Unified Process (RUP) [Kruchten, 2000] developed by the same main authors than UML as a combination of different already existing methodologies such as Booch or Objectory.

But probably the most important methodological change due to object-orientation is the one introduced by Agile Methodologies [Cockburn, 2002] in general and eXtreme Programming[Beck, 1999] in particular. These methodologies defend a lightweight developing lifecycle in which human values such as communication or courage are favored and formal documentation is avoided. Agile methodologies represent a step further from Incremental methodologies, the planning is performed in small iteration phases and continuously revised. Therefore the line between analysis and design phases is completely blurred. eXtreme Programming in particular puts a high emphasis on the code and promotes the use of practices such as Test-driven Development or Pair Programming.