Método Orientado A Objetos-Jaaksi

A Method for Your First Object-Oriented Project
Ari Jaaksi Nokia Telecommunications Network Management Systems Hatanpäänvaltatie 36 B, FIN-33100 Tampere, Finland ari.jaaksi@ntc.nokia.com

Jaaksi A., ‘A Method for Your Object-Oriented Project’ in JOOP, (Journal of Object-Oriented Programming), Vol 10, No 9, January 1998, pp 17 - 25.

1

Keywords: object-orientation, methodology, softwareprocess, notation

Abstract
This paper presents a pragmatic and simple approach to developing object-oriented applications. The approach is based on two fundamental principles of object-oriented software: objects and their cooperation. Process descriptions from collecting customer requirements to implementing code, as well as modelling notations are presented. Commercial object-oriented methodsare complicated and often hard to learn and use. The approach presented here is simple and easy to apply and develop further. The method includes only two notations and five clear steps. Still, it covers the software development process from requirements capture to testing. The approach can be used in the very first object-oriented projects of a company, and in domains and environments that areclear and simple enough. As regards more complex domains or environments the method scales up.

1. Introduction
Object-oriented literature is full of different methods and notations. There are plenty of books and publications explaining how to develop object-oriented software ‘in the right way’. Various companies are selling consultation and courses in object-orientation. Information about how todevelop software in an object-oriented way is available for those who are willing to study. In practice, companies cannot afford to study, take courses, and buy consultation for long periods of time. Especially small and middle sized companies would need an easy start, since they cannot hire expensive consultants to take care of object religion issues. Therefore, companies need a simple buteffective way to develop their first object-oriented systems. A methodology is more likely to be used when it is simple, clearly effective and small1. Still, I have noticed that most object-oriented software development methods are too big and complex to be used in real software projects. The problem is also discussed by Lilly2, and Henderson-Sellers and Edwards3, for example. Instead of detailed andcomplex modelling notations we need practical methods with clear notations and simple process description. These methods should be simple enough for an average software company to apply, and they should be easy to learn. The problem is that such methods may be too simple for us software scientists, because we all can find weaknesses in them. I argue that it does not really matter if the method doesnot cover full details. Instead, the method should first concentrate

2

on covering the most important aspects of software development. Only after that can the details be handled. Current object-oriented methods cannot be described as simple and easy to understand because they try to cover each and every aspect of software development. For example, the mere introduction of OMT4 and OOSE5requires about 500 pages of text. The complexity of these methods makes it sometimes hard to see what is really essential in them. The new Unified Modeling Language6 seems to even increase the complexity by introducing new notation details and concepts. Thus, a simplified version is needed, especially for beginners and for people working in small projects. A systematic approach is needed to guidesoftware development. A method, even a simple one, can assist an organisation in managing their own way of creating software. Process improvement activities, such as the ones presented in CMM7, for example, can be performed by modifying and developing the method. This can only be done if the method is followed in practice. Without a repeatable method in use the organisation cannot learn from...