The first object-oriented analysis methods focused on the specification of the classes of a system and on the static relationships between them. Dynamic relationships between classes and the functional view of the system as a whole were neglected, and no models were offered for capturing system requirements. This changed with the publication of use case driven approaches such as OOSE (1992) and Fusion (1994). Modelling global behaviour by scenarios in both requirements analysis and design has since been adopted by many object-oriented methods. Scenarios are also called use cases, system operations or business processes, and they are modelled using different notations. Some of the analysis methods that use scenarios have common characteristics, namely i) the similarity of the relationship between the entities of a data model and the scenarios of a flat scenario model with a matrix, and ii) the assumption that the externally visible behaviour of the system can be subdivided into more or less independent scenario types. In the following, we will refer to these characteristics by the term matrix approach. While in many projects the matrix approach has been used successfully, several difficulties arise when more complex systems are modelled: relationships and similarities between different scenario types cannot be expressed, the dependencies between scenario types are not modelled, only one abstraction level can be represented, and the apparently seamless transition from the analysis to the design model may result in a low quality object model with a strong bias towards data modelling. These difficulties lead us to propose an enhanced scenario modelling technique (called SEAM) which overcomes some of the weaknesses of the matrix approach. This modelling technique includes composition, aggregation, specialisation and extension hierarchies of services, and is based on the paradigm of interacting objects (which can be atomic objects, subsystems or systems) offering services. Scenario types, showing the possible interaction sequences for a specific service, can be modelled on several abstraction levels, and can describe the services of any kind of object (and thus also the global behaviour of a whole system) from both an internal and external point of view. We describe the concepts and the notation of SEAM, and we show how it can be integrated into the Fusion method. The difficulties that may arise in projects using methods based on the matrix approach are not only due to the limitations of scenario modelling techniques. A major factor is the often contradictory definition of the analysis model goals, which leads to clashes of intent. Therefore we discuss the nature of such intent clashes and analyse how the different software development methods deal with them. Finally we give an overview of the various notations and basic concepts used by different scenario modelling techniques, and we provide summaries of current, mostly objectoriented, approaches to modelling global behaviour.
EPFL1997
