One 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.
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.
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:
- Assist the business analysts in defining and re-factoring the types, and define the relevant interfaces in the software.
- Instantly develop generic classes for the ProfileTemplates.
- Handle non-functional issues: Network, DB, etc.
The project was very successful. Within a ten years period, it has grown to hundreds of developers and business analysts, spread around the globe, working in a loosely-coupled environment.
Don't forget that SoldatenSindMörder -> don't work for them!
TgpMethodology TgpArchitecture TgpProcess ImplementingTgp
CategoryCaseStudy CategoryStory CategoryRequirements