The main goal of this book is to present a set of good practices that allows software developers to comprehend and use object-oriented principles in an effective and efficient way. This chapter presents the motivation for this book and a quick introduction to UML (Unified Modeling Language) and UP (Unified Process). The goal of this book is not to be another reference manual to such technologies, but to help people who are working with them to accomplish their jobs better.

Keywords

UML; Unified Process; object-oriented analysis; object-oriented design; object-oriented development; design patterns

• Object-Oriented Systems Development

• Unified Modeling Language (UML)

• Unified Process (UP)

1.1 This book

There is a vast literature that aims at syntactically presenting UML1 diagrams, such as for instance, Miles and Hamilton (2006). There are also a significant number of books about development processes and management activities, such as Satzinger, Jackson and Burd (2011). However, there are relatively few books that go really deep into the presentation of best practices that allow the effective application of object-oriented techniques in software development in the real world. This means that despite the vast literature in this area, many questions faced by developers are still left unanswered.

This book presents more details on many object-oriented concepts and activities, especially those presented by Larman (2004), which is based on the Unified Process, commonly known as UP (Jacobson, Booch, & Rumbaugh, 1999; Scott, 2001).

The reason this book is based on Larman’s concepts is because he presents a concise and efficient approach to systems analysis and design using an object-oriented paradigm. In his approach, each artifact (document or diagram) has a very clear and practical reason to exist and the connections between artifacts are very precise.

In our approach, agile principles adopted by Extreme Programming (XP) (Beck & Andres, 2004) are largely accepted. However, we propose that programming must be undertaken first using a modeling language before directly programming code. The use of UML diagrams as high-level programming tools instead of just documentation tools is recommended. With that approach, the artifacts used should contribute directly to the understanding of the problem (analysis) or to the design of a solution. In order to improve the process of designing a solution, we consider model transformation and automatic code generation fundamental.

Furthermore, in contrast to Larman’s work, this book presents some original concepts and other details on topics as follows:

The aforementioned features are useful for producing high-quality software that is well organized, based on a multitiered architecture, and able to change or accommodate new requirements.

1.2 Object-oriented systems development

What is object-oriented systems development? By observing the way object-oriented analysis and design is taught and practiced in some places, it can be concluded that many professionals simply adopt an object-oriented programming language, or use fragments of an object-oriented based development process. However, very often, they are not as effective as one would expect.

It is not sufficient to organize the system architecture in tiers and modules if the code implemented inside of it is disorganized. Some programmers organize the system adequately in classes and packages, but they still write spaghetti code inside the methods of these classes and packages. In addition, other developers still use top-down functional decomposition inside methods, which is not appropriate when using object-oriented programming (top-down decomposition is adequate if structured programming is used instead).

In order to build code that is really object-oriented, developers should learn the techniques of delegation and responsibility assignment, which can lead to reusable code and low coupling. Those techniques are explained in this book.

It is useless to invest heavily in object-oriented CASE (computer-aided software engineering) tools without learning the way to think in terms of object-oriented programming. The use of diagrams will not necessarily improve the quality of the software, although it may help.

1.3 Unified Modeling Language (UML)

Some developers believe that UML is a methodology, maybe because of the “M” in the acronym. However, that is not true: UML means Unified Modeling Language, and it is therefore a language that can be used to describe things.

Knowing a language does not necessarily imply the ability to produce useful artifacts. For example, English is a language, but someone who knows how to speak English does not necessarily know how to write good poetry or how to make good speeches. Besides the language syntax, there are knowledge and techniques of best practices that greatly help poets and speakers to place the elements of the language in an order and structure that is adequate to produce the expected results.

The UML language has been under development since James Rumbaugh and Grady Booch joined forces at Rational Software and started to unify their already well-known diagrammatic notations and processes. Later, Ivar Jacobson joined the group and added his use cases and other notations to the unified language that was under development.

UML is constantly being revised and currently has the following three families of diagrams:

Not every diagram must be used during the development of a system. Only those that represent useful information for the project are recommended. This book emphasizes the use of the activity, machine state, use case, sequence, communication, and class diagrams for modeling information systems. However, other diagrams can be useful depending on the features of the system being modeled. For more information on the different UML diagrams, the book by Miles and Hamilton (2006) may be consulted.

1.4 Unified Process (UP)

The techniques presented in this book are compatible with the Unified Process, which is heavily based (although not necessarily) on UML.

UP was also proposed by the three amigos, Grady Booch, James Rumbaugh, and Ivar Jacobson (Jacobson, Booch, and Rumbaugh, 1999), as the result of their extensive experience.

This process is based in the following principles: