The POWER process

Overviewing the POWER process it consists of iterative sub-processes:

1. Translation of legislation and regulations in conceptual models, including completion of the models by expert knowledge elicitation (see Figure 7.2.1);

2. Re-factoring of conceptual models into coherent conceptual models;

3. Verification of conceptual models, including the detection of incompleteness and identification of missing legislation and regulations;

4. Generating knowledge based components for application frameworks, creating knowledge based systems that can be delivered for implementing law enforcement;

. . .

5 Legislation quality is defined as absence of anomalies, law enforceability, and effectiveness in obtaining intended effects.

Knowledge Management: The Role of Mental Models in Business Systems 5. Testing and validating knowledge components, including the

involvement of experts for certification of the knowledge components.

The order of the sub-processes may depend on the route chosen by specific legal drafting or law enforcement implementation projects.

Whatever the route chosen, eventually, the legislation, conceptual models and knowledge components will establish traceable refinement

relationships.

The modeling language used is a proper extension of the ICT industry standard Unified Modeling Language (UML), largely based on version 1.3, but including some proposed features of the upcoming version 2.0 that are particular to Catalysis services (D’Souza and Wills 1999). Part of UML 1.3 is the Object Constraint Language (OCL), which is used to express constraints that apply to the model.

However, the UML provides a very wide expression capability to

accommodate several systems development methods, e.g. Rational Unified Process (Kruchten 2000) and Catalysis (D’Souza and Wills 1999).

In order to obtain a well-defined translation process, we have to describe both the modeling conventions of the POWER method, which delimit a subset of the UML, and the extensions made to the UML, within the method and the translation process. In POWER, we use a translation process that is a somewhat adapted and more rigidly described form of Catalysis business modeling. The difference is due to:

• The deliberate absence of business process information in legislation, which is more often than not left for the law

enforcement agencies to set up as effectively as possible, albeit compliant to the legislation;

• The enhanced uniformity of conceptual models, delivered and required by the automated tool support of the POWER method;

• The particular features of the legislative domain, mainly the explicit references whereby a structure block in legislation (e.g. a chapter, article) refers to related structure blocks, combined with the need to create an independent model of each structure block for traceability purposes.

The structuring concept of UML is the package. Packages are the container concepts that delimit a part of a model. Packages have an hierarchical containment structure, and each nested package can reference the model items (such as other packages) contained by the nesting package. Other

model items can only be referenced if the containing package of the model item is imported in the package; the nesting package is implicitly imported.

In the translation step, each structure block of the legislation⁶ (e.g. law, chapter, section, article, sub, part, sentence) is translated into a package.

The hierarchical relationship of legislation structure blocks is reflected in the hierarchical nesting of packages, and an appropriate name is chosen for each package. In the translated conceptual models, we do not import any related packages to preserve traceability. Hence, each package has to be expressed with the model items of the package itself and of the nesting packages. This translation of structure provides a clean and traceable way to transit from a semi-formal legislation to a completely formal specification, while exploiting the specific features of the legislative domain, as compared to business modeling in general.

In order to preserve the non-import modeling, we extended the UML with the concept of a package reference. Package references model the explicit reference of one structure block to another structure block. Since we cannot import the package that corresponds to the referenced structure block, the reference is translated to a package reference model item. This allows us to include structural defects in legislation into a first conceptual model, e.g. if it cannot be determined which structure blocks are

referenced.

. . .

6 The names and kinds of structure blocks depend on legislative culture: it is related to the authoring legislative body or country in a certain time period. Since conceptual models and the translation process have to be applied regardless of legislative culture, both the conceptual model formalism and the translation process description have to remain culture-free.

Knowledge Management: The Role of Mental Models in Business Systems Figure 7.2.1. The POWER modeling process. Legal sources are translated into formal specifications (the conceptual model). Expert knowledge is used to extend, complete and validate those conceptual models. The models can be re-factored before being used in e.g. knowledge-based systems.

Taking a brief digression to the other processes, the verification process can automatically detect this type of defect for a large proportion of

references. In the re-factoring process, we will construct new packages that import both translated packages and other re-factored packages. The goal of re-factoring is to integrate a set of coherent specification packages into a set of complete, consistent specification packages that can be generated as a knowledge component. The package references contribute in calculating coherence heuristics.

Next, we use Catalysis business modeling to describe the domain

expressed in any given structure block. We select the structure blocks to be translated economically, based on expert judgment, and exploit the

package structure to maintain a record of the modeling status of each structure block. A versioning system can be integrated with the modeling tool to achieve this. Project status can be automatically tracked, as well as the version traceability between legislation and conceptual model. Version traceability allows us to translate the model as soon as a concept version of legislation becomes available, picking up changes as legislative drafting continues. This causes the modeling task to overlap the legislative drafting and approval task. The legislator can correct reported defects before the legislation is approved, and total project duration is reduced.

Catalysis models the business domain with types and attributes only, which is only a small subset of the UML. Doing this, the domain model will describe a minimal set of specifications, staying clear from design issues.

The specification allows us to identify exactly whether a given design conforms, without excluding a priori any potential alternative designs that may conform. In order to preserve minimal modeling, we can only specify the information required to conduct the legislative reasoning, using object types and attributes. Associations are considered inverse pairs of attributes that relate object types, and hence are a special case of attributes.

Types and attributes do not model stored data, but they model information that must be derived from collected data, i.e. any design⁷ of collected data must prove that this information can be calculated using the data. This proof is called refinement of the abstract information in the domain model into the concrete or realized data.

The translation is completed by capturing the legislative reasoning with static invariants, relating the types and attributes of the package with a first order predicate logic. Invariants are expressed using OCL. In order to work with the extensions to the UML, OCL is extended as well, with logical operators for package references. Static invariants are used to preserve the independence of the model from a task model. In practice, the task model and the conceptual domain model will be developed simultaneously. The task model will determine the set of structure blocks required in the model, but the conceptual domain models will also influence the tasks to be designed in executing the law in governmental agencies. Often, several tasks will be concerned with different aspects of the same conceptual domain model.

Modelers typically have no legal background. Hence, they must check often with legal experts, who are familiar with the legislative culture, to validate the formal interpretation of legal structure blocks in the model. During this in-translation validation, the modelers attempt to detect standard

interpretations in the legislative culture, identifiable by typical legal . . .

7 The definition of design is the creative process of coming up with a well-structured model that optimizes technological constraints, given a specification. An example can clarify this: legislation will often refer to a person’s (type) age (attribute) in its reasoning, while it makes more technological sense to collect birth date and

applicable date of the legislative reasoning. The age can be mapped to the difference of both, rounded down to whole years.

Knowledge Management: The Role of Mental Models in Business Systems

phrasing. These standard interpretations and typical legal phrasing, are then described with the corresponding formal models, and called translation patterns.

The in-translation validation with legal experts will also uncover semantic anomalies in the legislation (see also Kordelaar 1996). Semantic anomalies can occur if the rules used in the legislation or regulations lack clarity. In the POWER-translation processes detected anomalies are reported to legislators.

Traceability is an important feature in the POWER method because in legal domains we need to be able to point at the sources of our knowledge at execution time (to be able to motivate our decisions). If we preserve the refinement between the original legal sources (e.g. a specific article in a specific law or a part of case law) we are also able to make impact analyses when we have to make changes in existing legislation. We use the same references in the communication process with legislation drafters who are likely to understand legal texts better than formal representations (e.g. when validating models or reporting anomalies).

The conceptual model containing the formal specifications of a specific legal domain can be generated into a knowledge component for a modeled task, that is executable by computers. These knowledge components form the basis for a test against syntactic requirements, i.e. the verification process (see e.g. Den Haan 1996 and Kordelaar 1996) and the knowledge components can also be used to simulate the effects of legislation and regulations for a certain population (see e.g. Svensson, 1993).

Verification of the formal specifications will expose missing specifications and inconsistencies. Additional specifications may be translated from executive measures, and inconsistencies may be resolved through executive decisions of the authorized expert group. Re-factoring the specifications with these newly added specifications results in a more consistent and complete conceptual model. Eventually, the verification process demonstrates the consistency and completeness for the task at hand. The design of the enterprise’s software systems for enabling integration of the task into the executive business processes may be well underway by that time, in order to achieve the throughput time-to-execution required.

7.3. The application of POWER to a “simple” example from the