Use Case Modelling Importance in Object Oriented Systems Development Approach
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. Input output
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
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. Input output
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
References: Bennett, S., McRobb, S., & Farmer, R., (2010) “Object-Oriented Systems Analysis & Design using UML” 4th Ed McGrawHill, pp. 154-163. Jacobson, I., Christerson, M., Jonsson, P.M, Overgaard, G., (1992) Object Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, pp. 113–131.