C.C Method

Get Adobe Flash player

Motivation

The C.C method leads you to achieve the following aims:
1) to discover existing processes and systems
2) to design new processes and systems
3) to define the IT software structures for those processes and systems that are to be supported by IT

A brief history and introduction to the C.C method

The C.C method has been in development for 25 years.

There is a strong mathematical background, and a strong managerial approach behind the C.C method and the Craft.CASE tool. Simulation functionality is based on the state-machine theory. The Craft.CASE tool guides the modeller to create consistent models through constraint and validity checks, while drawing and simulating diagrams. The possibility to interconnect data through various modelling stages makes Craft.CASE context-sensitive.

The C.C method is so called "object-oriented". In the terms of the method, this means that you take notice of two crucial concepts: elements of the real world (subjects) and their behaviour; further we refer these concepts as to "lanes". The basic idea is that each subject (like "invoice" or "accountant") has a certain, specific, behaviour. The presence of information in one lane suggests the presence of corresponding information in the other lane.

The 6 steps of C.C method:

 

Interview  

Interview is an informal, yet very important step. Its goal is to help organize your approach to the project. Here you should define the scope of the project, its effect, its result and structure and also find the main players (like "accountant", "invoice", etc.) and actions (like "processing invoices") that are crucial for your model. To capture this information, you create so called "sketch" diagrams. The tool supports you in checking if all interview items are covered during the other steps of the method.

Structure  

Based on the interview, you should discover or define all important subjects (later called "players" or "participants") and their core behaviour, so that you have a comprehensive view of the modelled problem. You should also discover or define all of the important pieces of each behaviour; these are called "scenarios". The main idea of doing this is to break the entire complex system into pieces of manageable size, so that all of them can be given the proper attention. If you think about the entire system as a theatre performance, you need to find the individual "scenes" of the play.

You can also work on a different structure, like having a goal (function), several objectives (scenarios), and ways of achieve them (states or activities).

Relationships  

So far, you have the model in a form of several objects bearing only structured text in your native language. No diagram (except for interview sketch diagrams) has yet been created. You can still easily change your mind and restructure your model at once, without having to care about whether your diagrams will look nice. So you now have a bunch of text-described scenarios and a few dozen players. Now we would like Craft.CASE to make sure we haven't made any major mistakes. Craft.CASE does not understand your written text, but you can approximate its meaning to Craft.CASE by defining "roles". The role describes a relationship between a participant and a scenario. This allows Craft.CASE to help you test the model at a high level, before drawing a single diagram.

Testing model  

To do as previously stated, Craft.CASE generates a set of cross-reference tables, which describe the lifecycle of each participant in each scenario and allows you to crosscheck. The C.C method tells you how to test the model in this way.

Diagram creation  

Only after you have tested your roles, are you ready to create diagrams. This is because Craft.CASE’s Business Diagram does not show individual processes, but instead a set of all possible processes that can take place for a given scenario. In comparison to old-fashioned  - and today rather obsolete - flowchart diagrams, Craft.CASE’s Business Diagram has a separate storyline for each participant. This fact fully represents reality – in reality, we have our daily "lifecycle" and our course of action is affected by the course of action taken by our "collaborators". Preceding testing of the roles in all scenarios assures that you follow reality precisely in this step.

A very useful and very important rule of this method is that each participant can change one state to another while executing an activity. This reflects life systems, where things and people are going through states of their lives, e.g activated, idle, sleeping, active, etc. An example of the Business Diagram is bellow:

Validation  

It is necessary to ensure our model is valid. Craft.CASE provides an embedded simulator that allows you to step through the Business Diagram and see what happens at each step. Our experience tells us that business customers - including management - natively understand and like simulation, and are therefore valid partners in testing the model.