TRADEMARKS OlivaNova is a trademark of CARE Technologies S.A. Windows is a trademark of Microsoft Corp. Java is a trademark of Sun Corp. While the information in this publication is believed to be accurate, CARE Technologies makes no warranty of any kind to this material including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. CARE Technologies shall not be liable for errors contained herein, or for incidental or consequential damages in connection with the furnishing, performance or use of this material. COPYRIGHT NOTICE No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, photocopying, recording or otherwise, without prior written consent of CARE Technologies. No third-party intellectual property right liability is assumed with respect to the use of the information contained herein. CARE Technologies assumes no responsibility for errors or omissions contained in this white paper. This publication and features described herein are subject to change without notice. All products or services mentioned in this white paper are covered by the trademarks, service marks, or product names as designated by the companies that market those products. Current and future (conventional) notations used in Conceptual Modeling techniques should have a precise (formal) semantics to provide a well-defined software development process, with the purpose of going from specification to implementation in an automated way. To achieve this objective, the OO-Method approach to Information Systems Modeling introduced here tries to overcome the conventional (informal) / formal dichotomy by picking the best ideas from both approaches. In the OO-Method a clear distinction is being made between the problem space (centered on what the system is) and the solution space (centered on how it is implemented as a software product). It provides a precise, conventional graphical notation to obtain a system description at the problem space level, but this notation is strictly based on a formal OO specification language that determines the conceptual modeling patterns needed to have the system specification. An abstract execution model determines how to obtain the software representations corresponding to these conceptual modeling patterns. In this way, the final software product can be obtained in an automated way.
[1]
David W. Embley,et al.
An Active, Object-Oriented, Model-Equivalent Programming Language
,
1995,
Advances in Object-Oriented Data Modeling.
[2]
David W. Embley,et al.
Turnable formalism in object-oriented systems analysis: meeting the needs of both theoreticians and practitioners
,
1992,
OOPSLA.
[3]
Gunter Saake,et al.
Gaining a Uniform View of Different Integration Aspects in a Prototyping Environment
,
1995,
DEXA.
[4]
Chris Dollin,et al.
Object-oriented development: the fusion method
,
1994
.
[5]
David W. Embley,et al.
Automated Support for the Development of Formal Object-Oriented Requirements Specifications
,
1994,
CAiSE.
[6]
Rebecca Wirfs-Brock,et al.
Designing object-oriented software
,
1990
.
[7]
William E. Lorensen,et al.
Object-Oriented Modeling and Design
,
1991,
TOOLS.
[8]
Shaoying Liu.
SOFL: a formal engineering methodology for industrial applications
,
1997,
Proceedings of ISRE '97: 3rd IEEE International Symposium on Requirements Engineering.