Use Cases are not inherently object-oriented. Why then is use case modelling so important in the Object-Oriented approach? Discuss. Most projects have failed due to the problem of clarity in requirements. Requirements serve as a key part of system development since it is an input to system development and “a system” is produced as the output. Therefore if the requirement stage is wrong, the whole system will be wrong. Hence, the project fails. Inputoutput Requirements System Fig. 1 Requirement as an input to system development to produce a system.
The requirement model as seen in the above diagram (captures the functional requirements of the proposed system) serves as the basis for the system development and it needs to be well represented in a way that all the stakeholders (Users, Analysts, and Developers) of the proposed system will be carried along and have a common functionality understanding of the system. In the last few years, Object-oriented approach has been adopted as a useful tool that can help in solving most of the problems experienced in building a system. This is possible because of the contents of the modelling system are being represented as related objects.
Instead of separating functionality and data as we have in Structured approach (Function/Data Approach), they are combined and regarded as integrated objects. As said by Jacobson et al. (1992), a model which is designed using object-oriented technology is often easy to understand, as it can be directly related to reality. And since object oriented technique deals with interactions between logically related objects, the suitable technique to use in capturing functional requirements of a system being developed using object-oriented approach should also deal with object interactions.
Use Case Modelling has been widely accepted to be suitable for modelling the behavioural views of a system. Use cases which are known as an integral part of the UML (Unified Modelling Language), and are used to describe the functionality of the system from the users` perspective (Bennett et al. 2010 p. 154). UML is a standard NOTATION with clearly defined semantics to model Object-Oriented systems development. Use Case Model which is part of Requirements Model (Jacobson et al. 1992) is used to model the functionality f the system from viewpoints of users by describing typical interactions between users and the system. Each use case represents the interactions and these communications of users with the system are shown using Use case diagrams. Use case Actor (Fig. 2 Example of a use case diagram) As seen in the diagram above the user is the actual person who uses the system, whereas an actor describes a role that a user can perform (Jacobson et al. 1992). When a user performs this task, he or she is performing a related set of transactions in a dialogue with the system. This special sequence is called Use Case.
Each use case signifies a specific way of using the system and every execution of the use case may be viewed as an instance of the use case and each of these instances is called a scenario. Use Case model forms the basis for every other model at different stages of object-oriented system development and also controls the large part of the system development. i. e. controlling the formation of all other models. The processes involved in system development are multifaceted and this can be handled by breaking down the whole process into five different models (Jacobson et al. 1992). They are; ?
This is made possible by the use of user stories which is used to flesh out systems requirements. The diagram below shows the relationship between user stories and use case. Figure 4 showing the relationship between user stories and use case Use case model makes traceability possible through all the models of object-oriented system development. System can be modified easily with new requirements. This is all about making changes to the Use Case based on what the users want to change in the system and the other changes will be made appropriately in other models.
Use case model makes changes to a system so easy. When a change needs to be made to the system behaviour, the appropriate actor and use case are just remodelled. This brings about a Use Case driven systems. i. e. a system driven by what the users wish to do with the system. Though Use Case modelling has been a vital tool for capturing functional system requirements in the object-oriented community but it does have its limitations when it comes to developing large and complex systems where the requirements are enormous and we have what we can call a Use case xplosion (having too many use cases in a model) and also the challenge of not suitable for capturing non-functional requirements of the system. However, critically studying Use Cases, the objects and classes that would be used in other UML diagrams like Class diagram etc. and in coding at construction stage of object-oriented systems development always emanate from Use Case Modelling.