Object-Oriented Design

Unlike some object-oriented design methods, Catalysis does not always begin by assigning responsibility for actions to specific objects. We believe in not taking decisions all at once. We first state what happens then we state which object is responsible for doing it and which one is responsible for initiating it and finally we state how it is done.1 

Not only do objects participate in actions, but they are also used to describe the actions effects on the participants.2 3 Actions are characterized primarily by what they achieve and only secondarily by how they achieve it there might be many different ways. For example, we might say 

The stars indicate that every Student can have any number of accomplishments, and every Skill can be the accomplishment of any number of Students. The stick figure and the box represent types of objects the use of the stick figure instead of a box is optional and highlights the expectation that Student may be one of many roles played by any one object. 

Defining actions is covered in Chapter 4 and specifying actions in Chapter 3 and Chapter 4. 

The associations may represent real-world relationships if we asked Jo some deep question about lettuce curling, she should now know the answer. Or associations can represent software there is now a row in a database table saying that Jo has completed the lettuce-curling course, or Jo s name is in a record somewhere. The useful aspect of associations is that we don t have to say exactly how they are realized, but we can still make meaningful statements about how actions affect them. 

---

Fig. 3. NAMD 1 employs a modular, object-oriented design in which patches communicate via an encapsulated communication subsystem. Every patch owns an integrator and a complete set of force objects for bonded (BondForce), nonbonded (ElectForce), and full electrostatic (DPMTA) calculations.

For object-oriented design Clear, use case driven techniques for transforming from a business model to 00 code, with an interface-centric approach and high quality assurance. 

More-detailed discussion of object-oriented design can be found in Chapter 16. Classes and types in OO languages are discussed in Section 3.13. 

If you ve done any database design, you ll be familiar with the idea that every entity must have a unique key, which it is up to you to assign. The key is an explicit combination of the entity s attributes, and any two entities with the same attribute values are actually the same one. But in object-oriented design, we always assume an imphcit unique key. If you implement in an OO language or on an OO database, it provides the key for you otherwise, you make it explicit when you get to coding. 

The big difference between object-oriented design (OOD) and the procedural style is that with OOD your program must not only work as a sequence of statements but must also be well decoupled so that it can easily be pulled apart, reconfigured, and maintained. You... 

There are three big questions in object-oriented design. 

The ( ) suffixes distinguish the implementation. The first thing a reviewer might notice is that the classes I have written don t seem to correspond directly to the classes mentioned in the specification. Their attributes are different, and so on. We are doing object-oriented design, says the reviewer. Your code should mirror the spec. It says so in 50 different textbooks. ... 

We ve seen how a model can be very different from the code and still represent the same information. Now, as we ve said before, the Golden Rule of object-oriented design is to... 

In object-oriented design and programming, the concept of a framework has proven to be a useful way to reuse large-grained units of design and code while permitting customiza-... 

An object-oriented design according to these principles can be fully traceable from business requirements through to code, whether or not the correspondence is direct. 

The idea is to gain the benefits of 00, but without throwing away old code. You want to be able to make systems that remain flexible as your organization and its structure and working methods change. You want to build many applications from a set of basic components. These are features of object-oriented designs. 

This activity is similar to the problem of object-oriented design, and the same notation and techniques can be applied. (Indeed, an effective help in deciding the distribution of responsibilities among software objects is to pretend that they are people, departments, and so on, although the analogy can be carried too far ) This similarity should not surprise us, because the big idea of 00 programming is that the software simulates the business. 

Build from well-decoupled components this is a particular strength of object-oriented design. 

Object-oriented design is about decoupling the major aspects of the way a component functions and connects to its neighbors can be separated into different subcomponents. 

Many books have been written about good object-oriented design and implementation. Component-based development and assembly have only very recently become hot topics. Component and connector technology, effective pluggable design, and a coherent architecture together enable implementation by assembly. 

Booch91] Booch, G 1991. Object-Oriented Design with Applications. Menlo Park, CA Addison-Wesley. 

Johnson91] Johnson, R., and V Russo. 1991. Reusing Object-Oriented Designs. University of Illinois, TRUMCDCS 91-1696. 

Reil96] Reil, A. J. 1996. Object-Oriented Design Heuristics. Reading, Mass. Addison Wesley Longman. 

Meyer, B., Reusability The case for object-oriented design. IEEE Software, March, pp. 50-64 (1987). 

Chidamber, S.R., Kemerer, C.F. A metrics suite for object oriented design. IEEE Transactions on Software Engineering 20(6), 476-493 (1994)... 

Alabiso, B. (1988), Transformation of Data Row Diagram Analysis Models to Object-Oriented Design, in OOPSLA 88 Object-Oriented Programming Systems, Languages and Applications Conference Proceedings (San Diego, CA, September 25-30, 1988), N. Meyrowitz, Ed., Association for Computing Machinery, New York, pp. 335-353. 

---