On the purpose of Object Oriented Analysis Geri Magne Høydalsvik and Guttorm Sindre

The paper discusses the general purpose of analysis and desing and evaluates OOA with respect to this purpose, arguing that OOA often doesn’t deliver that it claims to do.

Outline Introduction The purposes of analysis and design OOA and the purpose of analysis OOA and the transition to design Consequences for the NSR project Positive trends in OOA Conclusion

1.Introduction The background of this work emerged in the NSR project. Within NSR project, the goal is to define a common methodology framework in which partner methods can serve as components. The role of the university is to evalute research results. The reason to evaluate OOA.

Introduction Cont. Two general claims of OOA –OOA fulfills the purposes of analysis –OOA has a smooth transition to design However, the authors found these claims to be false.

2 The purposes of analysis and design The exact boundary between analysis and design is hard to determine. But, still, a difference in purpose between analysis and design is recognized in most life-cycle models. Analysis concerns the description of the problem and the user requirements, whereas design concerns the construction of solution.

Cont. Discuss in more detail the purpose of analysis. –Knowledge to be captured. Analysis shoud concentrate on the requirement, not the solution –Activities to be undertaken. Major concern is Quality assurance, which includes verifacation and validation. –Requirements towards languages and methods. Languages and methods should be problem-oriented rather than target-oriented. (P244 Figure 1) Should be formal. –Transition to design The burden of translation from the problem domain to system domain should not be placed on the shoulders of users invloved in analysis but on the expereinced software engineers.

Problem-oriented vs target- oriented P244 Figure 1

3 OOA and the purpose of analysis 3.1 OOA and the software life-cycle. –For most OOA/OOD approaches, the difference between analysis and design is simply as the difference between what and how. –Instead, the real difference should be whether it addresses user requirements or solution.

3.2 Problem-orientation –Several objections can be made against the claime that object-oriented modelling is natural. –An OO representation might be good for some kind of knowledge, but less suitable for other kinds of knowledge. Business rules. Since business rules tend to be of a global nature, it is diffcult to attach them to any specific class. Dynamic, e.g. Processes. Most OO models are focus on static. Dynamics are scattered, since operations must belong to specific objects.

3.3 Verifaction and validation. –Most languages and methods for OOA are informal –Verification is poorly supported. –Useful validation technniques are not supported.

4. OOA and the transition to design 4.1 The OOPSLA conference registration problem 4.2 Describing the organization. –Static model –Dynamic model 4.3 Describing the software. –Static model with automation boundary. –Objects inside the automation boundary become information objects reflecting corresponding real world objects.

4.4 Comparing the models. Problems that may occur during the transition between analysis and design –The relative importance of classes may change. –Concurrency may change. –Behavior may change. –Services may change. –Attributes and relationships may change.

5 Consequence for the NSR Project. Works done in the context of NSR to achieving the goal of problem-oriented analysis. The role model by TASKON. METIS added a process model similar to DFD. Further implications on formality and validation.

6 Positive trends in OOA OOA has evolved into putting focus on system dynamics. Some methods have recognized the difference between analysis and design. OBA Formal approaches have started to appear. OSA

7 Conclusion The article has presented some general views on the purpose of analysis and design, and based on this it has been shown that OOA has several shortcomings, most importantly in being target-oriented rather than problem-oriented. Also the authors argue that a smooth transition to design is highly questionable.