1. Identifying Objects CSE301 University of Sunderland Harry R. Erwin, PhD

2. The Problem and a Solution Software engineering has been unable to deal effectively with the problems of scale (Boehm, various papers). Large systems usually exceed the span of control and understanding of a single software architect. Delegation of responsibility to subordinates is rarely effective due to the complexity of top-level interfaces. Object-oriented design and design methodologies allow the construction of large systems that exceed the capacity of a traditional hierarchical organization. –Assign subsystems to peer members of an architectural team for definition, –The manager concerns herself with facilitating their work. I have seen this approach work!

3. Object Identification Object identification is the process of determining the set of peer subsystems/objects whose behavioral interactions will solve the problem posed by the system requirements. Since it is known that many real systems cannot be accurately modeled computationally (Rosen, 1985, Life Itself), it is clear that there may be no ‘right’ set of objects that works perfectly. We will address various approaches to choosing a solution to this design problem. You should also read the discussion of this topic in the text for the authors’ perspective. If you’re using refactoring, you can change the objects if you get them wrong initially.

4. Approaches There are basically three approaches to initial object identification: 1.Model the system requirements—define the system requirements in terms of objects and object interactions and use those in the design. 2.Transform the system requirements—define the system requirements in terms of objects and object interactions and transform those to reflect architectural and design constraints. 3.Use a pattern language—define the design in terms of ‘patterns’ known to solve system requirements previously defined in some traditional fashion.

5. Modeling the System Requirements This approach is common, since most systems automate some existing process. The objects in the requirements are directly modeled using the features of the language, and the design may be automatically generated from the requirements. Pros: –Easy to envision and hence manage –Minimizes design effort –Usually easy to test Cons: –The system requirements may not lend themselves to object-orientation –The resulting design may not solve the real problem because it fails to consider implementation constraints –Testing may be infeasible You will probably have to refactor your initial object identification.

6. Transforming the System Requirements This approach is also standard. There are two ways to do it: 1.Ignore implementation issues in defining the system requirements. The design is corrected incrementally by refactoring in response to problems while directly implementing the requirements. 2.Write the system requirements with implementation in mind. In this case, the transformation begins early, and is continued as the requirements are implemented. (Historically, this has worked better.) Pros: –Addresses the problems inherent in modeling the system requirements. –Potentially less refactoring. Cons: –Incremental correction may not converge on a working system. –Requires expertise in both system requirements and solutions during system requirements definition (i.e., early). This can be risky, particularly if the solution space is not understood. –May not address user requirements and so fails user evaluation.

7. Using a Pattern Language Invented by Christopher Alexander, a noted architect. In his dissertation research, he investigated formal techniques for identifying a design from the relationships between requirements and design constraints. This failed for reasons already familiar, so he began to investigate pattern languages—ways of describing a design directly in terms of patterns: –problems, –general solutions to those problems, and –the underlying trade-offs. This has been extended to software. It works well enough that we will discuss many patterns during this module.

8. Pattern Language Pros and Cons Pros: –The resulting system actually solves a problem. –Expert system architects seem to think that way. Cons: –Pattern-based designs tend to be rigid. –Non-experts tend to produce rambling architectures without unifying themes. That makes refactoring and maintenance very difficult. General Assessment: –We will follow a hybrid transformational and pattern approach to O-O architecture. –This is particularly effective in an apprentice relationship, so get as much ‘face time’ with your tutors and lecturers as you can.

9. Starting the Process Traditionally, you would use a functional decomposition to design a system. That takes a function-oriented hierarchical perspective on the system, ignoring the data for the most part. Don’t do that—it doesn’t work for most large systems (Parnas). Instead, start with the data. In an object-oriented design, objects contain data and exchange messages concerning those data. Consider the data and data flows in the system, and define the data transformations (behavior) to satisfy the system requirements. Finally, group the data and transformations into tightly bound and loosely coupled objects. Remember two things in this: –You’re not designing a database. Objects have identity and behavior. Don’t end up with a mass of passive objects organized into tables. –Subsystems (and objects) should have peer relationships. Unless they do, you don’t have an object-oriented solution.

10. Identifying the Objects Look at the system as a whole, and ask what data indicates the state of the system. Those data items are the natural objects of the system. (They might not be the objects of your final design. They may actually be subsystems or even virtual objects created by the interaction of a number of real objects.) Avoid complex interdependencies. Instead, encapsulate. Avoid giving too much responsibility to an object—delegate! Try not to have a large number of top-level objects or subsystems. A list of objects you can paper your office with is too long. Instead, increase the level of abstraction. Try not to have too few top-level objects as well. Aim for 5 to 9, with a minimum of 3 and maximum of 15.

11. Identifying the Behavior Consider the behavior that users of each object (subsystem, virtual object) need access to. Consider how that behavior can be organized into interfaces. Many narrow interfaces are better than a few broad ones. Your design will implement these interfaces.

12. Refining the Objects Look at common behavior. If a number of distinct objects (subsystems, virtual objects) seem to support the same behavior, they should probably implement the same interface. If a number of distinct objects possess common attributes or data, perhaps they can be composed of objects from classes with responsibility for managing those attributes/data. Limit the responsibility of an object. Instead, delegate.

13. Bringing it Together Make the system function—consider how it is created, how it is organized, how it shuts down, and how it needs to respond to various scenarios. UML provides tools to diagram these, and there are a series of standard patterns to follow. Do not design a single main method in some class that runs everything. That is functionally oriented, not object-oriented! Your main method should set things up, start the system running, and get out of the way.

14. Finding the Structure “If there isn’t a main function to tell everything else what to do and on what data, how do you structure an OO system?” The answer is: with addresses for messages. That is, when the system is starting (or is changing mode), objects need to be given links to use for their messages. There are standard patterns for this. A simple one is for the start-up program to hand objects the address data they need at creation. You can also use the Singleton pattern to automate this.

15. Proving it Works You need to test your system to prove it works. This involves writing one or more test drivers and providing data recording interfaces within your system. Test drivers provide messages that cause the system under test to behave appropriately. They may be passive (injecting messages and recording the responses) or active (also interacting with the system). They also handle initializing the test data. Data recording interfaces allow a tester to examine the state of data within the system. Objects implementing those interfaces should be provided by the system to the test driver at test initialization.

16. Summary The tasks of the system architect include: –Knowing the need (understanding the system requirements) –Defining the data –Identifying the objects –Identifying the behavior –Putting the subsystems together –Proving it works