Tgp Architecture

The TGP Architecture

The TgpMethodology provides an architecture of collaboration with BusinessProfessionals (called also Technical Business Analysts TBAs). The architecture is based on ObjectOrientedFramework principles. The TGP VisualSharedModel aims to respond to dynamic changes in some areas of the software - creating flexible zones that are easy to adjust. Furthermore, the adjustments should be executed by businessprofessional who are not programmers; hence, the collaboration using the TGP VisualSharedModel takes place in the declarative area of the software. The businessprofessionals operates in the declarative area which is a confined and protected environment. The way TGP architecture separates the modular declarative part from the imperative part of the software is presented in the following figure:

The TgpProcess describes how to start and keep the IncrementalDevelopment process going. In order to adapt the software gently to the dynamics of the business domain, the flexible zones need to be built in a modular way. The TGP VisualSharedModel has three layers; the basic layer is the "Types". Types are the definitions of the abstractions and interfaces, the other two layers are generic classes/ProfileTemplates and Profiles. The basic layers of the TGP shared model and the different responsibilities of BusinessProfessionals and developers are presented in the following figure:

TGP Layers

Types are categories for the business professional and extension interfaces for the developer. Types generate the flexibility dimensions; they constitute a plug-in environment that makes extensions inexpensive. Types are determined by the BusinessProfessionals' interaction with developers. New perspectives may lead to an expensive modification of the Types. Example from interior design software for types can be: table, chair, certain, carpet

Generic Classes are ProfileTemplates (PTs) for the professional experts. The PTs serves as forms for generating new features and new functionalities. PTs concretize the existing types and use other types as parameters. PTs are determined by the BusinessProfessionals' interaction with developers as well. Example from interior design software for a PT of table can be: dining table, desk, coffee table Each of these PTs has the following properties: basic functionality (as indicated in their names) and rough size (large medium small).

Profiles are sets of concrete configuration for the business professionals. The profiles have an actual meaning in the business domain. In a good model most of the requirements are mapped by the BusinessProfessionals into profiles. Profiles are used to define both set of values and relationships to other profiles that together define the desired functionality. For the developers profiles serve as concrete classes, however, in most cases they are transparent to them. An example from interior design software for a profile will be furniture defined in the catalog, such as CT356-G. CT356-G is a coffee table with specific properties determined in the profile: rectangle shape, 120cm length, 70cm width, 80cm height, made of wood and with green color. Yet, profiles are classes rather than instances in the database. Instances may have other properties set by the end user, in this case, the position the table, its price, relate it to other furniture, etc. Profile may resemble knowledge objects, or configuration objects in other implementations.

In a sense, a TGP model is a map of the anticipated and actual flexible areas of the software. The basic structure of a TGP shared model is presented in the following figure:

-- ShaiBenYehuda and OriInbar

Discussion

In my experience, end-users often have a hard time with normalization/factoring. They may identify attributes, but are not practiced in consolidation of related concepts and keeping to OnceAndOnlyOnce. They will let duplication live and breed if left alone. For complex situations, an experienced analyst is needed to keep things clean. -- top

That is why the BusinessProfessionals are not alone in the process of shaping the software. They cooperate with the developers and architects that stress these aspects of "clean" design. The visual interface of the TGP shared model determines the borders of the possible functions of most businessprofessionals creating Profiles. In the high level activities of shaping the shared model, the BusinessProfessionals are not independent, in fact technically, only the developers can create ProfileTemplates and Types.

In a multi team projects we suggest another role "Business Strategists", who are familiar with the business domain like BusinessProfessionals, however, they have modeling skills. The Business Strategists (see ImplementingTgp). -- OriInbar

(moved here from FlexibilityZonesArchitecture)

Various questions arise immediately. For example -

What are categories and types, and, in particular, what are "exiting types"?
How is "developer" different from "programmer"?
Why is maintaining a profile called "adjusting" it, and why put the word "new" after "create" (surely "create" implies "new")?
What are "transparent for developers" when they "concretize" generic classes?
How can interfaces define behavior?

Answers:

Categories and Types are implemented as interfaces. The BusinessProfessionals don't need any understanding about the methods defined in the interface. However, they understand types as grammar rules, place-holders for profiles of this type. Since types have actual meaning in the business domain, the BusinessProfessionals use them to define structures of profiles. See TgpBackground for examples. The "exiting types" are simply the ones that are already functioning in the software as oppose to the ones need to be defined in the IncrementalDevelopment TgpProcess.
The "developer" is a "programmer". In the TGP development process there are basically 2 roles developer and BusinessProfessionals, however in large projects the TGP promotes another 2 roles architects and business strategists, see ImplementingTgp. Maybe we should use the word programmer instead of developer, because one can claim that BusinessProfessionals are developers!
The profiles holds the configuration of the software. Maintaining a profile called "adjusting" it since we see them as a kind of a switchboard that need to be adjusted-calibrated. Concerning: why put the word "new" after "create" (surely "create" implies "new")? - of course you are right.
Basically, the profiles are "transparent for developers" since the BusinessProfessionals are the one writing them using their tools. The data and structure stored in the profiles (likely to be in XML format) is loaded as a structure of instances of the generic classes with read-only properties defined in the profiles.
The Types-Categories do not define behavior by themselves. There is a simple top-level process known to all that determine the behavior. The signatures of the interfaces are designed according to this process (and other non-functional considerations known only to the programmers). The imperative part of the software is the implementation of the methods in the generic classes along with some core controller logic. In general, TGP tries to hide behavior issues from the BusinessProfessionals by letting them work on the declarative model and define input and outputs as TestCases.

-- OriInbar and ShaiBenYehuda

OK, this, and pretty much all the other TGP pages, feel to me like they're full of marketing hype and b******t and very, very light on actual content. What are you selling?

You are right that the pages describing the methodology are written in some marketing attitude. We will be delighted to refactor together with the community to make the methodology better. However, at the moment we are not selling anything. Moreover, the TGP is more of a strategy than a set of tactics. The content is not concrete in the sense that in each implantation the tactics may vary. -- OriInbar

''ArtwareSoft is a consulting company. We help existing projects to refactor, and help start-ups to design. The Tgp WalledGarden started as a direct copy of our white papers, and this is the reason it looks like white papers. I don't like it personally, but I guess it was the easiest way to put things up, and worry about removing all the buzzwords later.

The reason we put the Tgp papers here at all was to discuss it with the smartest people in the business. Methodologies and ideas are free, and like free software, they improve when they are shared. We want opinions and criticism; to know if other people use similar concepts; to clarify what it is actually good for and where it should be applied; to find good definitions of the concepts. We don't sell it, and I don't believe we ever will be able to.

There is some (very simple) technology involved, and it was implemented for each of the projects that implemented it separately, but along similar lines. ArtwareSoft doesn't own any of these implementations, but we intend to write one as an open source project, or maybe two (one in Java and one in C++).

We use the Tgp methodology since we believe it is the best for our clients, probably because we are still very excited about it - we invented it, it solves many problems, and everyone who ever used it loves it. -- Moddy Te'eni ''

TgpMethodology AgileProcesses AgileSoftwareDevelopment CategoryAgileMethodology OrganicTesting TgpProcess