type expressed in the implementation language. New classes must be introduced to store intermediate results during program execution. Emphasis shifts from the application domain to implementation and computer concepts such as user interfaces or view layer and access layer (see Figures ). During the analysis, we look at the physical entities or business objects in the system; that is, who the players are and how 'they cooperate to do the work of the application. These objects represent tangible elements of the business. As we saw in Chapter 7, these objects could be individuals, rganizations, machines, or whatever else makes sense in the context of the real-world system. During the design phase, we elevate the model into logical entities, some of which might relate more to the computer domain (such as user interfaces or the access layer) than the realworld or the physical domain (such as people or employees). This is where we begin thinking about how to actually implement the problem in a program. The goal here is to design the classes that we need to implement the system.
166 Fortunately, the design model does not look terribly different from the analysis model. The difference is that, at this level, we focus on the view and access classes, such as how to maintain information or the best way to interact with a user or present information. It also is useful, at this stage, to have a good understanding of the classes in a development environment that we are using to enforce reusability. In software development, it is tempting not to be concerned with design. After all, you (the designer) are so involved with the system that it might be difficult to stop and think about the consequences of each design choice. However, the time spent on design has a great impact on the overall success of the software development project. A large payoff is associated with creating a good design "up front," before writing a single line of code. While this is true of all programming, classes and objects underscore the approach even more. Good design usually simplifies the implementation and maintenance of a project. In this chapter, we look at the object-oriented design process and axioms. The basic goal of the axiomatic approach is to formalize the design process and assist in establishing a scientific foundation for the object-oriented design process, to provide a fundamental basis for the creation of systems. Without scientific principles, the design field never will be systematized and so will remain a subject difficult to comprehend, codify, teach, and practice . 16.2 OBJECT-ORIENTED DESIGN AXIOMS By definition, an axiom is a fundamental truth that always is observed to be valid and for which there is no counterexample or exception. Such explains that axioms may be hypothesized from a large number of observations by noting the common phenomena shared by all cases; they cannot be proven or derived, but they can be invalidated by counterexamples or exceptions. A theorem is a proposition that may not be self-evident but can be proven from accepted axioms. It, therefore, is equivalent to a law or principle.