Usecase Realisations and thier significance.

As mentioned in earlier posts, the goal of the SDLC is to identify what the system will do and how the users a.k.a actors will interact with the system. The usecase is the first step to acheiving this objective. The belief is once the boundaries are defined and system behaviour is known then the system can be built and the built system can be tested.

But increasingly this kind of modelling of systems as a tool,is not a good model. The world is moving away from computer as a box to be used to a more akin to a information space in which we can interact. In this model, there is not a box on which information resides, rather the information resides in a space (across multiple computer systems). The users, other organisations and things are available in the information space. The users, organizations both customer and vendor and other automatons together create this new shared experience. it is not a one time system building activity, but an ongoing activity.

To move to such a environment, the system building activity has to move away from building a system to more like building a information space. To understand such a environment, we have to first understand how we build systems today and see what needs to be changed to create such an environment. All systems today are built on sequential computing theory, i.e all instructions have to be sequenced and pushed through the computing pipeline to be processed. in such a system the fundamental operation is to compute and store state. So if we imagine a system that is a information space, then it needs to be a communication machine. i.e. systems should be able to interact/communicate with one another, without being send through a sequential processor.

Comming back to use case realizations, the usecases now have to be sequenced (as we are still building systems on a sequential machine) and brought down to either a computation or a storing instruction. This is the job of the Usecase realizations. There are multiple artifacts which depict these simple instructions. These are Class diagram, Sequence diagram and State transition diagram. Each of these serve different functions.

The Class diagram explains and organizes functions around artifacts called classes. This way functions which are modular can be found easily by developers who come next to maintain this code. The sequence diagram, explains how the different algorithms are sequenced together.More on each of these artifacts will be explained later.

In the next few posts, i will explain each of these artifacts. It will be also be shown how these algorithms can be explained in terms of interactions, or rather in terms of input /output sequences. With further posts leading to a new way of approaching systems leading to a more agile, interactive and modular systems.