ABSTRACT:
This paper deals with this use case modelinq as the basis of event identification. Over the last three years, use cases have become we!I established as one of the fundamental techniques ·of object-oriented analysis. Although initially introduced by Ivar Jacobson to the object community at the 1987 OOPSLA conference, it was the publication of his book Object-Oriented Software Engineer.ing: A use case Driven Approach in 1992 that marked the true beginning of use cases meteoric rise in popularity. Possibly in reaction to the previous structured methods, early. object-oriented development methods overemphasized static architecture and partially ignored dynamic behaviour issues during requirements analysis, especially above the individual class level where state modeling provides as important technique for dynamic behaviour specification. Use cases provide a great many benefits in addition to correcting this overemphasis, and most major object-oriented development methods (including my own) have jumped on the bandwagon and added use cases during the last few years. In the resulting hoopla and hype, however, there has been little discussion of the limitations and potential pitfalls associated with use cases. This paper is an attempt to provide a more balanced behaviour issues and to caution against the uncritical acceptance of use cases as the latest patent medicine for all software ailments.
Cite this article:
Ojha (2004). Event Identification Using -Use Cases. Journal of Ravishankar University (Part-B: Science), 17(1), pp.1-9.