Conceprocity goes beyond G-MOT in recognising the notions of event and logical connector. An event is a named change of state, typically represented in English using a past participle such as arrived or departed. Again typically, events are the result of one procedure and trigger another; this is the case for P1 in the diagram which follows.
Figure Basic sequence of events and procedures
In Conceprocity, events should normally be preceded and followed by either a procedure or a logical connector. The logical connectors available in Conceprocity are Not, eXclusive-Or, Inclusive-Or and And.
Figure AND logical connector
Figure Inclusive OR logical connector
Figure An example of combining events, procedures and logical connectors
The example in Figure shows labels Yes and No. Such labelling is optional and often unnecessary, since the events adequately label the alternative outcomes.
10.5Lists and properties
Lucidchart allows tables and these can be used to list, for example, properties. However we suggest that Conceprocity models should not be over-encumbered with lists and other textual items, which are often best left in the dictionary associated with a model.
10.6A summary of Conceprocity grammar rules
(Rosemann and Green, 2002) discuss how Wand and Weber have developed a series of models based on the ontological theory of Mario Bunge; they named these models the Bunge-Wand-Weber BWW models. The BWW models have as their intent the formalisation of modelling techniques. Rosemann and Green identify two particular criticisms of the models, one being the understandability of the constructs within those models and the second being the difficulty in applying the models to specific modelling techniques. They propose a meta-model of the BWW constructs using a meta-language that is in effect an extended entity relationship model (Chen, 1976). Their justification for that choice is that the entity relationship model is already very familiar to many Information Systems professionals. Furthermore the extended entity relationship model is the meta-language by which (Scheer, 2000) has modelled and formalised his ARIS event process chain model. We have yet to attempt any such formal meta-modelling for Conceprocity. Instead, and for the time being, we have followed (Paquette, 2010) and G-MOT in setting out certain grammar rules which together constrain and add meaning to concept process models. Conceprocity follows very much the same rules.
Figure Summary of Grammar Rules, based on (Paquette 2010).
10.7Some simple rules to follow Events must have one arrow in or one arrow out or (one arrow in and one out). Logical connectors should EITHER have one arrow in and more than one out (split) OR have multiple arrows in and one out (join). All other notions should have at most one arrow in and one arrow out. 10.8Structuring Conceprocity maps 10.8.1The need for multi-level models
Conceprocity allows a knowledge model to be developed at several levels. The principal (top level) model gives a general overview of the domain. The subordinate models add a new level of detail, more and more specific to the representation of the domain: an expansion. Each level of representation should be simplified so as to retain only the knowledge essential at that level. By this means the benefits of encapsulation – low coupling and high internal cohesion – can be realised in the context of knowledge representation. In Conceprocity, the existence of an expansion of Concepts and Procedures is signalled by a highlighted border. The notion is then linked to another page in the same model or to another model.
Figure Concepts and procedures which are expanded elsewhere - signified by highlighted border
10.8.2Structuring a model
A Level 1 diagram is potentially supported by several Level 2 diagrams. Each Level 2 diagram might be supported by several Level 3 diagrams. There is but one Main Model and a series of nested models stemming from the Main Model.
10.9Conceprocity Usage Profiles
A Usage Profile is a named usage of Conceprocity. These various usage profiles require few or no extensions to the Conceprocity basic notation which is richly expressive. It is possible and desirable to start with a beginners’ profile “Simple concept mapping for beginners”, in which the only available relationship is association and no use is made of principles, and only then to move on to typed relationships and principles. In particular in this profile, we place strong emphasis on the use of sketches, icons and images as complementary to the more formal Conceprocity notions. The simple usage profile is sometimes referred to as a CIAOPEA model.
10.10Learning to use Conceprocity: moving on from the beginner’s profile
Conceprocity is cloud-based and essentially multi-user. It also provides implicit support for the notion of usage profiles. A Usage Profile is a named usage of Conceprocity.
The various usage profiles require few or no extensions to the Conceprocity basic notation which is richly expressive.
Table Conceprocity Usage Profiles
-
Conceprocity Usage Profile
|
Simple concept mapping for beginners: CIAOPEA
Makes use of a deliberately restricted range of Conceprocity notions. In particular, the only relationship type supported is association. In order to give more expressiveness, this profile permits association relationships to be named and encourages it.
|
Knowledge mapping: TROPICPEA
Very general with the full range of Conceprocity objects. Relationships should not normally be named. Instead, the nature of the two notions linked by a typed relationship should normally provide full context sufficient to make the meaning of the relationship clear. Where this is not the case, Conceprocity permits commentary/notes.
Typical uses include: self-observation, research design, representing knowledge as-is and as-ought, demonstrating understanding, documenting a body of knowledge, design and delivery of teaching (e.g. to act as the “advance organiser” or signposting originally suggested by (Ausubel, 2000)), learning and evaluation, requirements modelling and the representation of algorithms and of heuristics.
|
Usage diagrams
Usage models are slightly-extended use case diagrams. Use case diagrams were first proposed by Jacobson and are documented in (Booch, Rumbaugh and Jacobson, 2005). We suggest that no distinction needs or ought to be made between a use case and a procedure. Therefore the symbol used to represent a procedure is also used to represent a use case. However in Conceprocity we address what we perceive to be a weakness in use case analysis as presented by (Booch, Rumbaugh and Jacobson, 2005). That weakness is that interactions – which occur at the interface between an actor and a use case – should be explicitly represented. We have therefore introduced a specific symbol for interaction. In cases where a use case diagram represents a computer-based system which is or will be implemented, this interaction will take concrete form as a web page, perhaps as a web form; or as some other element, such as a form, report, query or view in a desktop database.
|
Event-driven process chains
We suggest that no distinction needs or ought to be made between a function in the usual event-process chain described by (Scheer, Thomas and Adam, 2005), implemented for example in ARIS; and a procedure in Conceprocity. Therefore the symbol used to represent a procedure is also used to represent a function in an event-process chain. Conceprocity already has a specific symbol for an event. The symbols for inclusive OR, exclusive XOR and AND are deliberately not the same as those used in common event-process chain modelling tools such as ARIS.
|
Data (entity-relationship) models
|
System architecture and components
|
Taxonomy creation and maintenance
Conceprocity is not currently intended for the representation of full ontologies; it can however be used effectively to represent taxonomies.
|
Causal loop diagrams (Eden, 2004)
|
Share with your friends: |