Sequence Diagram, its Significance and limitation.

A Sequence Diagram by definition depicts, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner. I.e it tells how the different participants (or in UML terms actors), participate to make the overall functionality.

In OO Terms, the class diagram already depicts the different methods that achieve the overall functionality. The sequence diagrams gives how these methods participate to achieve the overall functionality i.e in the diagram, the overall restaurant experience. As you would have noticed, the diagram is called sequence diagram, as all computers work sequentially and all behavior has to be sequenced like this to achieve a computer functionality.

The line in the diagram (for e.g Order food, etc) is the method call to the object Bob the waiter. All these objects (in this case, Fred, Bob, Hank,) are sequenced by message or method calls.

i.e. The overall functionality, which could be a real world with parallel activities, have to be sequenced, so that this can be modelled in a sequential computer. This modeling constraint of sequentiality is the reason why the whole SDLC is very expensive. As the world which is parallel needs to be sequenced and modeled so that it can be executed by a sequential computer.

As you can see in this model, say tomorrow, Bob the waiter gets capability to also become the cook. But this model now have to reflect this, as you can see this change of roles for Bob is very difficult to acheive in this seuquential model. As the whole sequential algorithm has to be re-sequenced to give the right model. Simply a very expensive and laborious process .This is the problem that is faced by all enterprises. As when their business model changes. the computer model is not able to keep up with the business change, due to the sequential modeling employed.

Can we break from this paradigm of sequentiality? If this paradigm is shifted from sequential to parallel, this would help us model systems better. I.e. we might be able to express parallel systems directly, significantly improving productivity and agility of our IT systems.

In further posts, i will depict how these modelling can be changed so that we can model businesses directly.

Class Diagram and its significance.

The next step of the SDLC process is to realize this usecase with some of the infrastructure that is available in the market place. As all technology realizations that is available in the marketplace have algorithms as it fundamental. So all the use cases have to be realized on these infrastructure fundamentals. Towards this functions have to built around objects which will finally realize these product use cases. When function and it manipulations are built, it involves structuring these code around different objects and these objects have to organized to give a level of modularity to the whole system. This static technology realization is depicted in the class diagram.

Besides the above function of organizing methods, it also has the function of organizing state. I.e how will each class manage the state.

To make it more formal, by definition, a class diagram is a diagram showing a collection of classes and interfaces, along with the collaborations and relationships among classes and interfaces. A class diagram is the pictorial representation of the static relationship of all classes. As mentioned earlier, the use cases depict what needs to be built, and the class diagram defines how these functionality that needs to be built is realized. The use case functionality, which is broad is broken down into smaller atomic functionalities and assigned to classes.

A class diagram consists of a) Class Diagram, b)Interface and c) Package. The class diagram depicts,
an entity of a given system that provides an encapsulated implementation of certain functionality of a given entity. These are exposed by the class to other classes as methods. These methods take inputs and either respond back with a response or it communicates nothing back. So in a way we can say that a methods job is to communicate values, i.e accept values and respond back with values. The class is an collection of these communications or request/response sequences. These collection of communications can also be called as interfaces. These interfaces represent a behaviour.. The class can be used to organize and categorize behaviour, so that behaviour can be chunked into groups.

The behaviour is a collection of request/response communications. These request/response a.k.a behaviour is the capability of this class to enter into relationships with other classes. So these methods in a way also depict the different collaborations, this class can enter into with other classes if they are sequenced. This behaviour and its capability to enter into collaborations is the business functionality.

Apart from business functionality, a class also has properties that reflect unique features of a class. The properties of a class are called attributes. These attributes are represented as primitives and methods a.k.a communication primitives are attached to this primitives;which give semantic markup.For e.g. the date by itself does not make any sense, this is just a primitive number, it is when it is able to communicate what this date represents then it makes sense. A birth date in association with a date primitive makes a lot of usefullness. This semantic markup, in this case the birth date, can also be viewed as a way to reach this date through a communication primitive, the communication primitive could be a method called birthdate, which when collaborated with is ready to give the date.

So in a nutshell, the class diagram gives how the different request responses (Algorithms / Transformations) that needs to realize the overall functionality (as depicted in the usecase), are organized and it also decides how state will be maintained.

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.