Eigenschappen
| Context | Expertise Management Methodology |
|---|---|
| prefLabel | |
| altLabel | |
| hiddenLabel | |
| inScheme | |
| subject | |
| broader | EMontPatronen |
| narrower | |
| partOf | |
| association | |
| related | |
| creator |
De View-Navigation (VN) pagina's.
Er zijn geen VN pagina's gelinkt.
Description
The PQR formula has already been discussed in great detail in another part of the wiki, however, the pattern and how it's visualised is hardly discussed. This page about the PQR pattern aims to inform of the way PQR is visually structured within the EMont. PQR is an extremely important part of the Expertise Management Ontology, as mentioned before: It’s considered to be the working horse of the EMont. The PQR pattern is widely used in the EMont and it can be used in multiple different situations due to the way it has been set up.
Using the PQR method will generate numerous different approaches to reach a certain result. In some contexts it’s better to choose one of those actions, but other times it might be better to execute all the actions sequentially. This is where the major distinction in PQR visualisations comes in; the freedom of getting to choose which action is the most appropriate is labeled as the ‘Degree of freedom’, whilst executing the activities one after another is called ‘Sequencing of activities’. This means that when a high degree of freedom is present, there will also be lots of actions to choose from, depending on the situation; this might or might not be ideal. When sequencing activities, there is not much room for freedom, the relevant activities will be done in a certain order, no questions asked.
The result of a PQR implementation is a ‘use case map’, which is essentially a timeline which denotes the activities that need to take place to reach a certain goal. Metaphorically speaking, the timeline can be seen as a railroad, at every halt, the train comes to a stop and performs certain activities, which allows the train to move its merry way. Different halts require different activities to take place, therefore there are multiple types of activities that are used in a use case map, the different types are:
A sequential execution of activities means that all activities are done one after another. The next activity can't be started until the previous activity has been completed. In the context of flood protection, it could be the case that a dike has to be strengthened, after that has been done, a test can be ran; but the test can't be performed until the dike has been strenghtened.
A conditional execution means that a certain condition has to be met before an activity can start. For example it could be that an activity is to construct a dike, but before that can happen, money needs to be raised. The condition in the case is: Half a million euros are required. The activity 'build a dike' can't start until this condition has been met.
Parallel activities are executed alongside each other; this means that both of the activities will be executed at the same time, running parallel. For example; while building a dike, it's also possible to finish certain paperwork, it wouldn't make sense to wait until everything is done to finish this, so they are executed simultaneously. This does not necessarily mean that both activities have to work towards the same goal.
Last but not least, there's the wait activity. A wait activity is an activity that relies on the output of other activities to continue. The activity can already start before relying on the output, but after a while the activity will come to a halt; requiring certain facilitation. This facilitation will come from another activity, for example: A dike is being built, but certain permits have not yet been granted, bringing a temporal halt to the construction. Once the permit has been granted, the building can start again. Thus, the activity is waiting for external input.
<<image to be added>>
Alternative visualisation(s)
While the current visualisation does a good job at displaying the pattern, a couple of alternatives will still be presented. Luckily, there are already a few frameworks to visualise this kind of information, one of which being the UML; the Unified Modeling Language. Within the UML there are a few available options that would be a good combination with the PQR, namely the Activity diagram and the Sequence diagram. The sequence diagram is typically used to show interaction between objects, in this case however, it will be used to display the interaction between activities. This extremely structured approach can (when slightly modified to show activities instead of objects) provide a good means to capture the PQR cases. UML natively supports conditions, parallel execution, sequential execution and also wait activities(triggers). However, there's a downside: UML diagrams, especially sequence diagrams are not as easy to comprehend compared to the current visualisation, let alone creating one, especially considering all the seemingly similar symbols that mean entirely different things. Therefore the visualisation of the PQR formula with UML has to be done with caution and with the average user in mind. After all, it's the user that has to interpet the visualisation, too much room for interpretation may cause confusion. A small example of a a sequence diagram is:
An activity diagram is a lot simpler, which makes it easier to understand, but limits the available options. An activity diagram is a great way to show the course of activities, including which decisions are made, which path has been taken, etc. An activity diagram looks quite similar to the current visualisation, however, it's a lot more structured in its approach, allowing for bigger structures while maintaining acceptable levels of readability. An activity diagram example is found below.
http://www.holub.com/goodies/uml/images/activity.3.gif
Problems might arise when trying to combine this visualisation with other Expertise Management Method Patterns, such as the Big Picture, but for now that will be disregarded.
