Preface

This book presents, in a deep and didactic way, elements of object-oriented analysis and design for developing information systems.

The area of software development for information systems has evolved during the last two decades around the Unified Modeling Language (UML) and the Unified Process (UP), adopted as international standards by the Object Management Group (OMG). Even agile developing methods nowadays use object-oriented development as the leading paradigm.

In contrast to some other books in this area, which are organized around the presentation of UML diagrams and their many possible uses, this book concentrates on the daily analyst’s and designer’s activities, and it explains how the different diagrams may help them in developing better systems and developing systems better.

Although the object-oriented culture has more than 40 years of existence, there are still companies that find it hard to produce good quality software, especially due to the lack of maintainability and flexibility on the systems they produce. This book presents information and techniques to minimize that deficiency.

The techniques described here were applied with success by the author in many software development companies, as well as in research projects at the university level.

This book is intended for computing professionals (analysts, designers, and programmers), and computer science students, both in undergraduate or graduate studies with at least a basic knowledge of object-oriented development or modeling. Beginners and experienced people will find the guidance presented in this book useful in improving the quality of their projects. This book was written to help them achieve the best design possible.

In contrast to what occurs with the waterfall model (Royce, 1970), where analysis and design activities happen sequentially, iterative models like UP propose that those activities (also called disciplines) may happen with higher or lower emphasis at any phase.

This book gives more emphasis to the activities that are typically performed by analysts and designers, including business modeling, requirements engineering, analysis, and design. Other disciplines such as project management, implementation, and testing are also referenced. For more information on other disciplines, books on software engineering such as Pressman (2010) may be consulted, or books more specific to the Unified Process such as Kruchten (2003).

The goal of the UP Inception phase is to build a general view of the system and its context, and plan further development. The two main modeling tools for this phase are conceptual modeling (Chapters 6 and 7) and high-level use cases (Chapter 3). Business modeling (Chapter 2) may be necessary with more or less emphasis, depending on the project that is going to be developed.

At the end of the Inception phase, high-level use cases may be used as a basis for planning the rest of the project (Chapter 4). Usually, that planning involves rating use cases as small, medium, or large (the t-shirt scale) with regard to their complexity, and deciding on their priority. When the complexity of each use case is known, it is possible to estimate the average time necessary to develop them (Karner, 1993), and thus, the iterations may be planned as a set of activities that can be realistically performed with the time available.

The Elaboration phase of UP is performed as a sequence of iterations. Each iteration has a set of use cases assigned for development.¹ Developing an individual use case usually starts with its expansion into flows (Chapter 5). Optionally, the use case flows may be represented as system sequence diagrams, in order to help discover system queries and commands that have to be implemented.

During the Elaboration phase, when the architecture is evolving, the conceptual model (Chapters 6 and 7) is refined and completed.

System queries and commands may be implemented with a programming language. But the designer may choose rather to specify contracts for system queries and commands (Chapter 8), which besides being a higher-level definition for the expected behavior of each procedure, may be very useful in helping to define test cases (Chapter 11). These contracts correspond to the functional model of the system, because they define the functionality of each query and command in terms of the input they receive and the results they produce.

At this point, again, the system may be implemented, or its code may be automatically generated if tools are available. However, if elegant code is desired, it may be helpful to produce a new set of diagrams (sequence or communication diagrams) for each of the system operations (Chapter 9). Those diagrams indicate how the different objects will exchange messages in order to distribute responsibilities and attain the desired postconditions specified by the contracts. With this procedure, design patterns are easier to apply to the code. These diagrams also help to specify which methods (besides getters and setters) must be implemented in each class, and how they must be implemented.

During Elaboration, the design of the interface can be completed (Chapter 12). This book presents the IFML notation² as an option for modeling that aspect of a system. IFML is a brand-new standard modeling language for information flow that is being adopted as one of the OMG standards from March 2013.

Although it is more emphatic during the construction phase, the elaboration phase may also require the generation of a database structure (Chapter 13) and running code (Chapter 10). Data persistence may be generated automatically if the appropriate tools are available. However, it is worth at least knowing how the persistence mechanism works, even if it is automated. Code generation is also presented as a set of rules that can be automated.

In order to save space for a deep presentation of the topics, most of the exercises can be accessed on the Internet.