Idf Implementation
Idf ImplementationOne of the first implementation of The TgpMethodology was a unique simulation project in the early 90's. In many ways, the simulation project resembles strategic war games, such as Red Alert or Civilization, however it was in a real army - the IDF (Israeli Defense Force).
The major problem the TgpMethodology tackled in that project was the ineffectiveness of the military strategists, combat analysts and operation researchers (the "business" analysts of this system). These people have a unique knowledge and ideas about weapon capabilities and organizational structure. They wanted to try and develop these ideas using the simulation infrastructure.
Before the methodology was implemented, they just coded their ideas in our simulation framework using C++. It took them a very long time to code and debug, and they were mainly frustrated because their passion was in the business domain rather than technology.
It was clear to all that we had to develop a kind of declarative simulation language for them. But we could not define a static one. The declarative language needed to be dynamic!
Hence, instead of providing a specific simulation language we focused on a collaboration methodology to make the analysts effective. The methodology should allow them to architect the simulation abstractions (the grammar of the simulation language), ask for features (words), and be the users of the dynamically created declarative language (talk the language). This was the first TGP shared model (TgpArchitecture).
From the business analysts point of view, the architecture of the simulation language - the shared model, is defined by the Types, the business domain abstractions. In their case, it was weapon, unit, firing capability, hiding capability, etc. Types are mapped into interfaces in the software.
Types are abstract, and generate the grammar rules in which features can be assembled to define specific functionality.
The simulation language features are defined as ProfileTemplates (PTs), which are templates used to build profiles. For example, A Canon is a PT with the following open parameters: effective distance, size of bullets, etc.
Profiles are concretizations of PTs. Profiles are used to define concrete business terminology. For example, Canon M145 is a Canon with a specific effective distance, and specific size of bullets. Profiles serve as classes rather than instances. They can also be regarded as declarative Meta objects or knowledge objects.
The role of the developers was to:
Discussion
Don't forget that SoldatenSindMörder -> don't work for them! -- KurtTucholsky?
TgpMethodology TgpArchitecture TgpProcess ImplementingTgp
EditText of this page
(last edited January 29, 2007)
or FindPage with title or text search