Paper presented at IEE People In Control 2001 conference, Manchester
PRocurement Officer Management Information System
List of topics Decision support for specification of C3IS Automated documentation
G. Detsis, L. Dritsas, J. Kostaras Intracom – Defence Programs Defence Systems Development Markopoulo Ave., 190 02 Peania, Athens, Greece.
Key message With the organisation of global C3I knowledge in an appropriate model, formalisation of the specifications and the use of an information system, the procurement officer can be aided by an effective decision support and documentation generation tool.
SYNOPSIS The scope of the proposed paper is to present the research results of Euclid RTP 6.6 project, undertaken by the PROMIS consortium. The aim of the project is to develop an approach to supporting C3IS specification. Procurement officers have to produce a non-ambiguous, consistent and as complete as possible system specification before awarding to an industrial entity an implementation contract for the system. The procurement officers must consider the need for interoperability between the different national C2 systems, use COTS as much as possible and match commercial and military systems together. At the same time, the production of the specification must be available in the shortest time possible. The key to the approach is to consider a specification as a list of all possible interaction objects between the system and its stakeholders. These ‘User Objects’ define the external view of the system in a formal way; they are stored in a repository called ‘Reference Model’. However, unlike usual specifications, they are constrained to comply with C3IS system logic. The specification process is thus scoped down to a simple selection and overall consistency is ensured by a selection triggered automatic constraint propagation. Reference Model Information System (RMIS) is the name of the workshop designed to support this process. When the selection has been completed, the RMIS is able to generate a textual Segment System Specification (SSS), according to 2167 A American DoD standard, including Interface requirements, functional and non-functional requirements. The RMIS approach has been validated through a software demonstrator. This approach proved to be very fruitful because it can be extended to system design, e.g. to the SSDD at the expense of RM completion with C3IS architectural objects.
1 Introduction Whenever a Command and Control System (let us assume a C3IS) is to be acquired, a contractual baseline must be established between the procurement department and the industrial entity selected for system implementation. Producing this baseline is a difficult task. Let us take the most general view of the acquirement process. It typically includes the following phases:
Requirement Engineering Architectural Engineering Configuration Engineering Configuration Assessment
According to the US Department of Defence standard 2167, the process begins with a description of the military environment in which the C3IS (Communication, Command and Control Information System) is meant to work and ends with the production of:
SSS (System Segment Specification) for the requirements SSDD (System Segment Design Description) for Architectural and Configuration Engineering results Configuration Assessment results.
Intermediate assessments may give rise to requirement negotiations when some requirements appear too expensive and must be discarded. The negotiation back loop leads to a better-scoped set of raw requirements and to a new sequence of 4 steps. In this already cumbersome process, we should also understand the need for specifying a C3IS in a minimum amount of time and cost while considering commercial in addition to military standards that evolve rapidly.
Paper presented at IEE People In Control 2001 conference, Manchester
The PROMIS consortium worked together, in order to develop an approach for supporting C3IS specification, so that procurement officers can produce a non ambiguous, consistent and as complete as possible system specification before awarding to an industrial entity an implementation contract for the system.
2 Reference Model The first step towards this target was locating potential information sources of C3I expertise. A number of questionnaires were compiled and distributed to the MODs (Ministry of Defence) of the participating countries. The retrieved information was structured and stored as a Reference Model (RM) that could be used as a list of all possible interaction objects between the system and its stakeholders. Those interaction objects are conceived as the building blocks of any future C3I system specification. They are called ‘User Objects’ and they define the external view of the system in a formal way. But, unlike usual specifications, they are constrained to comply with C3IS system logic. Each user object of the RM is considered to have a maximum of 5 dimensions: Military Operational Functional Technical Security The specific attributes of each user object were studied both on each isolated dimension as well as with relation with the rest of the user objects. This yielded a set of rules enforcing the behaviour of a user object when participating in a C3IS specification that is being built based on the RM. The expert knowledge on C3I systems was formalized in order to produce the Reference Model. Because of prior experience and familiarity with UML this knowledge was described in UML class diagrams. Secondly, the description of the structure of the SSS document had to be formalized as well. The best candidate for that was XML (extended Mark-up Language), and, because a UML (Unified Modelling Language) diagram can also be described in XML, UML seemed as the ideal unique formalism to describe the input of the system (Reference Model) and the output (SSS).
Figure 1SSS Generation using XML The Reference Model must be able to describe the following types of relationships among entities: • Inheritance: B is-a A It allows describing the specialization of an object and the generalization of a sub-object. Whenever a Parent-Entity is selected, the User must be aware that a Specialization of this Parent-Entity is possible, in order to be more specific, if he/she is able to. Whenever a Child-Entity is selected, the User must be aware that it is a Specialization of a more general Entity and therefore other possible Specializations can exist for the same ParentEntity. • Aggregation: A is composed by B and C It allows describing the fact that an object is composed by several sub-objects. Whenever a Composite-Entity is selected, the User must be aware of which Sub-Entities are mandatory and which are optional. • Implication: D requires E It allows describing the fact that whenever D is needed, E is or should be needed too. First we have to construct a Reference Base compliant to a Reference Model, which follows the General Model:
Paper presented at IEE People In Control 2001 conference, Manchester
building blocks follow assembly rules powered by the constraints linking the user objects together. The set of selected building blocks is called the User Context. The rules the RMIS shall apply in order to correctly assembly and customise the building blocks are called Business Rules.
Figure 2 Reference Base By using the above techniques, the RM was conceptually structured as a set of five UML class diagrams, each one describing one of the five dimensions of all the user objects.
Once these building blocks are assembled and customised, a process is defined to automatically produce the corresponding SSS that will be a hypertext and multimedia document. The following diagram denotes the basic components comprising RMIS.
IBc
3 Reference Model Information System
MMIc
LVc
RAc (from MMIc)
The usefulness of the RM is shown with the use of a demonstrator that was especially built for this purpose. This demonstrator, named RMIS, supported a number of functionalities useful during the C3IS specification process. The RMIS supports the user or a stakeholder to produce a SSS document.
BREc
RMEc
(from MMIc)
Bc (from MMIc)
TMMc
URHc
UREc (from MMIc)
RDGc
SEc
Structured Report (SSS)
RMCc
Rc
RM Document
Figure 4 RMIS component diagram 1.
Figure 3 SSS Generation The user views the Reference Base as a set of building blocks out of which he can select from and customise in order to assemble a virtual C3IS. Those
2. 3. 4. 5. 6. 7. 8. 9.
MMIc, which in turn consists of 1. LVc (Log Viewer) 2. Bc (Browser) 3. UREc (User Requirement Editor) 4. RAc and IBc (Retrieval Agent and Information Base) TMMc (Target Model Manager) BREc (Business Rule Engine) Rc (Repository) RMCc (Reference Model Cruncher) RDGc (Requirements Document Generator) SEc (Search Engine) URHc (User Requirements Handler) RMEc (Reference Model Editor)
Paper presented at IEE People In Control 2001 conference, Manchester
RMIS was developed in Java and its repository was based on a light version of an ODBMS (Object Data Base Management System). The output specification documents are structured in XML.
3.1
MMIc
This package contains the overall MMI (Man Machine Interface) functionality. The MMI of RMISv2 has the following appearance:1
3.1.2 Bc (TMBc, URBc) The Browser component is a GUI for viewing the current status of a target model. In RMIS V1 a browser (Bc) was delivered to navigate in the target system model, to select/undo selection of entities and features, and to customise properties. In RMIS V2 a User Requirements Browser (URBc) is incorporated to browse user requirements and to navigate from user requirements to entities. Furthermore, in co-operation with the Bc, it will be able to navigate from entities to user requirements. The Browser component collects information from the Target Model Manager and the User Requirement Handler components and can also send information requests to those components. In short, the browser components are the user interfaces to the Target Model Manager and User Requirement Handler.
3.1.3 UREc
Figure 5 RMIS Man Machine Interface The top bar belongs to the general MMI providing menus by means of which the user can interact with the functionality of the various parts of the system. To the left is the user requirement editor/browser and to the right is the target model browser. The lower part belongs to the log viewer. These are described in more detail in the following paragraphs.
3.1.1 LVc The Log Viewer Component provides facilities to view the events that are performed by the system. The component is called by various other components. For instance, when the user selects an entity, a list of all selected and highlighted objects is proposed for consultation to the user, through the Log Viewer component. 1
The snapshot is from a “mock-up� version of the system available at the time of writing. The actual MMI in the running version of RMISv2 may appear slightly different.
The User Requirement editor provides the front end to perform the User Requirement Handler activities. It will be a dialog with different tabs in which the user fills the fields in order to create, modify or refine user requirements. Moreover, the dialog presents particular tabs to link documents from the local site and entities from the target model to the user requirements. In the MMI, the User Requirement Editor is the lower part and the User Requirement Browser is the upper part of the User Requirement Browser/Editor area.
3.1.4 RAc and IBc These two components are COTS tools, namely InfoSeek and Finder, respectively, and are not illustrated in the above MMI snapshot.
3.2
TMMc
The Target Model Manager provides storage/retrieval of all model objects associated with a target C3I system model. The TMM handles, for instance, the entities of the reference model in the repository. Its purpose is to provide access and control to objects, to the user, via the MMI (the browser components). TMM acts as a cache for the MMI, holding the branch of the data structure being manipulated. It handles both isolated
Paper presented at IEE People In Control 2001 conference, Manchester
objects (entity instances) from the reference model and entire Target Model Systems. It is placed between the Browser component and the Repository. It works on the Target System Model in parallel with the User Requirement Handler.
3.3
BREc
The Business Rules Engine Component maintains the implementation of Business Rules among Model Components in the system. When the user selects an entity, some others entities must be proposed for selection (‘highlighted’ is the right term chosen in RMIS). This proposal is based on ‘RULES’. For each Selection / Undo of selection of the user, a special rule engine must be called to present the list of implications; in other words: what are others entities (or Attributes, Methods or Properties) that are selected / de-selected / highlighted, using defined rules? This list is also directly sent to the Log Viewer Component. The Business Rules Engine is the module that implements all semantic rules (named ‘Business rules’). It is called by the Target Model Manager Component, and returns to it a response. The BRE may also receive a request to validate the current state of the model by the TMM component. The BRE has access to the Repository component and can interact with the Log Viewer component.
3.4
Rc
The Repository is a generic term for stored information. It does not reflect a dedicated component/application, but can be regarded as the collection of databases and persistent information in the system. The Repository contains an object version of the Reference Model, Target System Model (complete or incomplete) and the Target System Requirements (complete or incomplete). The central database holds an object structure version of the RM, the Target System Models and the Target System Requirements. The data is held as objects to facilitate manipulation of their state. The interpretation of the Reference Model is maintained intact, with links and components as they were generated. The Target System Model is a separate object structure that, while staying compliant with the
RM object structure, incorporates the selections made by the RMIS user.
3.5
RMCc
This component crunches an XML reference model into objects, which are stored in the Repository. The flat data structure in the XML document is interpreted by this application and converted to objects and associations, which can be stored in the repository. Storing the RM in an object form allows the system to manipulate the data more easily than the raw XML.
3.6
RDGc
This component provides a capability for automated generation of the Requirements document, and uses standards for SSS (System/Subsystem Specification) as template for the requirement documents generation. The RDG generates an SSS document in the XML formalism that reflects the state of the object structure in the repository (target system model). The output is expressed as paragraphs for the SSS. The component will use the service provided by Rc to retrieve information from the Target System (Entities/Features/Properties/User Requirements) The document can be browsed using an XML editor. A simple document generator was integrated in version 1, while a full-implemented document generator is implemented in version 2. The simple document generator for version 1 was developed only to demonstrate the component and RMIS functionality. The document generated was unstructured (TXT file) in which was indicated only the main chapters of the SSS, and the requirements were written without particular structure. Version 2 provides an improved and complete integration of the Requirement Document Generator allowing generation of an SSS in XML language following an SSS template.
3.7
SEc
This component aims at retrieving textual information in the user’s Target System.
Paper presented at IEE People In Control 2001 conference, Manchester
When the user describes a requirement, it is useful to retrieve information in the Target System that could be linked to the concerned requirement. The Search Engine is a facility for the user to retrieve an entity or a feature; if the user wants to link this Target System information to the requirement, he can do it using the Link Manager. The Search Engine cannot browse the whole Target System each time the user wants to retrieve any information, because this process is time-consuming. That is the reason why it is necessary to index the System Model offline. Using this index information, the Search Engine can easily retrieve Target System entities or features.
3.8
URHc
The URH component is concerned with User Requirement management, to be used for manipulation of the user requirements: creation, deletion, modification, and refinement. Furthermore the URH allows to save/ load user requirements in the repository using the repository services and to interact with "Search Engine" component in order to retrieve a set of entities from RM to cover a specific user Requirement.
4 Conclusions The PROMIS project proved the concept that it is possible to ease the C3IS specification process by means of a Reference Model and an information system utilising this model. Specific documents of STD-2197 were used but in principle any other standard may be used just as well. Furthermore the domain of C3IS can be broadened although this is a very sophisticated domain that is not easily matched.
5 Acknowledgements The PROMIS consortium consisted of 8 companies of 5 European nations: THALES Communications (France) MS&I (France) TERMA (Denmark) MRC (Turkey) DATAMAT (Italy) MARCONI (Italy) HAI (Greece) INTRACOM (Greece) They all worked together on a European research project named EUCLID (European Co-operation for the Long-Term in Defence) RTP 6.6 programme.
A User Requirement can have different levels of refinement depending on the user exigency, and the entire structure will be represented like a tree.
Many thanks also go to Intracom’s Defence Programs Department for kindly providing us with the valuable time to produce this paper.
The user starts writing a raw requirement. A raw requirement is by the system considered as the top node. The Raw requirement can be decomposed in various more refined user requirements. The user requirements can then be linked to one or more entities in the Target System Model in order to satisfy this user requirement.
6 References
When the entities in the target system model can not satisfy a user requirement, the user can insert directly the requirement in the SSS document linking the requirement to an SSS paragraph (bubble). In this case the user requirement must be well formulated and the user is responsible for that.
3.9
RMEc
This component is an integrated tool to the user that will allow manipulation of a reference model (in XML format).
I. II. III.
Sommerville, G. Kotonya, “Requirements Engineering: Processes and techniques”, Wiley & son 1998. US DOD STD-2167A (Defense System Software Development) MIL-STD-498 (Software Development and Documentation)