The purpose of structural design modeling is exactly what the name implies—to model the design of the structural aspects of your system. Structural design focuses on the identification of entities, classes or data structures, and the relationships among those entities. For modern systems there are two basic styles of structure that you need to be concerned about at the detailed design level. The first is the design of your object schema, something that is typically modeled with a class diagram. The second is the design of your database, something that is done with a physical data model (PDM).

This chapter addresses the following topics:

• UML class diagrams;

• Applying design patterns effectively; and

• Physical data modeling with the UML.

UML CLASS DIAGRAMS

The purpose of design is to model how the software will be built; as you would expect, the purpose of design class modeling is to model the static structure of how your software will be built. The techniques of analysis class modeling that you learned in Chapter 8 still apply. The only difference is your focus is on the solution domain instead of on the problem domain. In fact your analysis class model often evolves into your design class model—you simply introduce changes to your class model based on implementation technologies. Although modeling purists may insist that you keep your analysis and design models separate, the reality is that you will often work through requirements to analysis to design in a matter of minutes, sometimes even seconds.

Architecture provides the foundation from which systems are built, and models are one way to define the vision on which your architecture is based. The scope of architecture can be that of a single application, of a family of applications, for an entire organization, or for an international infrastructure such as the Internet. The focus of this chapter is on architectural modeling for a single system, although much of the advice is pertinent to larger efforts. Regardless of the scope, my experience is that you can take an agile approach to the modeling, development, and evolution of architectures. Table 10.1 overviews the artifacts described in this chapter for architectural modeling.

For our purposes the architecture for a system is simply its high-level design. Good architectures are based on requirements—developers taking on the role of architect will often analyze the pertinent requirements as part of the architectural modeling process. One way to look at architecture is that it, along with analysis, is the bridge between requirements and design. Architects will also consider high-level design decisions such as “What will we build this system from?”, “How will the parts of this system fit together?”, and “How can we ensure this system will work under less-than-perfect (or real-world) conditions?”

The only constant in the information technology (IT) industry is change. To remain employable, let alone effective, software developers must continually take the time to identify and then understand the latest development approaches. The goal of this chapter is to introduce you to leading-edge technologies and techniques that enable you to succeed at developing modern business systems. I will try to steer you through the marketing hype surrounding these approaches, and in one case try to dissuade you from adopting it—just because something is new and well hyped does not mean that it has much of a future. In short, this chapter provides you with a foundation for reading the rest of this book.

This chapter discusses

• Modern development technologies;

• Modern development techniques;

• How this book is organized; and

• The case studies.

MODERN DEVELOPMENT TECHNOLOGIES

Effective developers understand the fundamentals of the technologies that they have available to them. The good news is that we have many technologies available to us; the bad news is that we have many technologies available to us.

Figure 1.1, which depicts a high-level architecture detailing how these technologies are used together, shows how some applications may be n-tiered—an approach where application logic is implemented on several (n) categories of computing devices (tiers)—whereas others fall into the “fat client” approach where most business logic is implemented on the client. Object technology is used to implement all types of logic, including both business and system logic.

You need to understand object-oriented (OO) concepts before you can successfully apply them to systems development. Because OO techniques grew, in part, out of the disciplines of software engineering, artificial intelligence, and information modeling, many of them will seem familiar to you. Do not let this make you complacent—you also need to understand several new concepts.

This chapter explores the following:

• A brief overview of OO concepts;

• OO concepts from a structured point of view;

• The diagrams of the unified modeling language (UML 2);

• Objects and classes;

• Attributes and operations;

• Abstraction, encapsulation, and information hiding;

• Inheritance;

• Persistence;

• Relationships;

• Collaboration;

• Polymorphism;

• Interfaces;

• Components; and

• Patterns.

A BRIEF OVERVIEW OF OO CONCEPTS

This chapter discusses the concepts that make up the foundation of OO development techniques. People experienced with structured technologies such as COBOL and FORTRAN will have seen some of these concepts before, and some will be new to you. For example, many concepts that go to the heart of OO—encapsulation, coupling, and cohesion—come from software engineering. These concepts are important because they underpin good design regardless of the technology you are working with. The main point to be made here is you do not want to deceive yourself: just because you have seen some of these concepts before, it does not mean you were doing OO; it just means you were doing good design. While good design is a big part of object orientation, there is a lot more to it than that.

OO concepts appear deceptively simple. Do not be fooled.

The purpose of object-oriented programming is to build your actual system, to develop the code that fulfills your system's design. Your design artifacts, such as unified modeling language (UML) class and state machine diagrams, drive the development of your source code. Design and programming are highly interrelated and iterative and you will often move back and forth between them. Your programming efforts will quickly reveal weaknesses in your design that need to be addressed, and your design efforts will reveal potential strategies to code the system effectively.

Developers will typically focus on two types of source code: object-oriented code, such as Java or C#, and database-oriented code, such as data definition language (DDL), data manipulation language (DML), stored procedures, and triggers. Section 13.4 describes how to implement common object-oriented concepts in Java and Chapter 14 describes database coding. The end goal of your programming efforts is to produce a component, subsystem, or even a full-fledged application that can undergo testing in the large (described in Chapter 3).

This chapter discusses these topics:

• Philosophies for effective programming;

• Programming tips and techniques for writing high-quality code;

• Test-driven development (TDD);

• From object design to Java code; and

• What you have learned.

PHILOSOPHIES FOR EFFECTIVE PROGRAMMING

Over the years I have found that the following philosophies have helped improve my effectiveness as a programmer:

1. Always write high-quality, clean code. Quality work is one of the practices of extreme programming (XP) (Beck 2000), and my experiences confirm the importance of writing high-quality code at all times. High-quality code is easier to write, easier to understand, and easier to enhance. Sloppy code will only slow you down.

2. […]

Your skills, and how you apply them, are significant determinants of your success as a software professional. By reading this book, you have gained the fundamental knowledge required to begin learning object technology and agile techniques. The bottom line is that software development is hard; it takes skilled people to be successful at it. By making it to the end of this book you have learned the basics of modern software development; you have learned some useful concepts and techniques; you have started to get a handle on how they fit together; and you have applied them by working through the review questions and case studies. You are now in a good position to continue your learning process, a process that will last throughout your entire career. This chapter provides insight into where the software profession currently is, where it is going, what skills will be needed over the next few years, and how you can obtain those skills.

BECOME A GENERALIZING SPECIALIST

I believe that one of the biggest problems the IT industry faces is over specialization of skills. Many organizations have IT departments filled with Java specialists, database specialists, business analyst specialists, project management specialists, and so on. This approach is based on an organizational behavior paradigm called Taylorism, named after Frederick Taylor, who in his 1911 paper The Principles of Scientific Management set the stage for large-scale manufacturing.

Modeling and documentation are critical aspects of any software project. Modeling is the act of creating an abstraction of a concept, and documentation is a permanent record of information. In traditional software processes, such as the IEEE 12207 (http://www.ieee.org), modeling is included as one or more serial phases. Modern prescriptive processes, such as the rational unified process (RUP) (Kruchten 2000) or the enterprise unified process (EUP) (http://www.enterpriseunifiedprocess.info), which describe in specific detail the activities required to develop software, include modeling disciplines that you work through in an evolutionary manner. Agile software processes, such as feature-driven development (FDD) (Palmer and Felsing 2002) and extreme programming (XP) (Beck 2000), also include evolutionary modeling efforts, although in FDD, modeling is an explicit activity, whereas in XP it is implicit. The point is that modeling and documentation are important parts of software development, so it makes sense to want to be as effective and efficient at it as possible.

This chapter describes agile model–driven design (AMDD), an approach to software development where your implementation efforts are guided by agile models that are just barely good enough. This chapter addresses the following topics:

• Modeling philosophies;

• Project stakeholders;

• What is agile modeling (AM)?;

• The values of AM;

• The principles of AM;

• The practices of AM;

• Easing into agile modeling;

• Agile model–driven development (AMDD);

• Fundamental information gathering skills;

• Agile documentation;

• Making whiteboards work for software development;

• AMDD and other agile methodologies; and

• AMDD and test-driven development (TDD).

The Object Primer is a straightforward, easy-to-understand introduction to agile software development (ASD) using object-oriented (OO) and relational database technologies. It covers the fundamental concepts of ASD and OO and describes how to take an agile approach to requirements, analysis, and design techniques applying the techniques of the unified modeling language (UML) 2 as well as other leading-edge techniques, including agile model–driven development (AMDD) and test-driven development (TDD) approaches. During the 1990s OO superceded the structured paradigm as the primary technology paradigm for software development. Now during the 2000s ASD is superceding traditional, prescriptive approaches to software development. While OO and ASD are often used to develop complex systems, learning them does not need to be complicated. This book is different from many other introductory books about these topics—it is written from the point of view of a real-world developer, someone who has lived through the difficulty of learning these concepts.

WHO SHOULD READ The Object Primer?

This book is aimed at two primary audiences—existing developers and university/college students who want to gain the fundamental skills required to succeed on modern software development projects. Throughout this book I use the term “developer” broadly: a developer is anyone involved in the development of a software application. This includes programmers, analysts, designers, business stakeholders, database administrators, support engineers, and so on.