Descriptions and methods of description, models and meta-models ​

The (role/private/aspect) description/view itself, according to the ISO 42010 standard, consists of a set of individual models that can be interpreted as formal or informal parts of the system description, reflecting even more specific important characteristics than the collective role description assembled from these models. For example, a full system description includes a financial description of the enterprise::creator, but in the financial description, one can identify different models needed to answer various questions of a finance-interested project role: balance sheet, profit and loss statement (P&L), and cash flow. If you only have a balance sheet, you won't be able to answer questions about the profitability of the enterprise, and if you have a profit and loss statement and even a balance sheet, you won't be able to discuss cash flow issues without documents on cash flow. One role description for one subject of interest, three different models for three subsubjects of interest (of course, subjects of interest/important characteristics are also subdivided into subsubjects/subcharacteristics!).

Each of the models should be created using one of the meta-models/model kinds (this is extensively discussed in the ontology transdiscipline), and each of the meta-models establishes certain languages, rules, and modeling techniques (agreements) used in model development. Just as individual models answering to some subinterest are combined into a more complete thematic/role description (view), meta-models (metamodels/model kinds) defining the language, rules, and modeling techniques used in role/thematic/specific descriptions are combined into role/thematic/specific methods of description (viewpoints) reflecting the subject of interest/frame. Description methods with their meta-models are often described in a "modeling agreement" document; for some data, the meta-model is often referred to as a "data model" (data = system model, data model = system metamodel).

For example, to create a financial description of a creating enterprise system, you need to first select one description method—RAS (Russian Accounting Standards) or IFRS (International Financial Reporting Standards). When preparing a balance sheet (one model of a financial description) and a profit and loss statement (another model of a financial description), meta-models (modeling agreements on how to make models) for these types of models from one description method—either RAS or IFRS—should be used.

And remember, there is also a meta-metamodel level (what RAS::viewpoint is exactly using our course material for assigning a type, we said that RAS is a description method, we used a meta-metamodel type of a fundamental discipline, a general type for all disciplines. And RAS is a metamodel, a description method for a subject/applied discipline).

It is simplest to consider a description method as library-based (library), which means that instead of revealing its contents, a simple reference to the literature on this method is provided. This is like giving a reference to a book or cartographic standard that lists symbolic labels and details on how to use these labels to depict relief details, flora, fauna, natural resources, population density, etc., instead of the full text and images of a map legend. But if there is no text with an established description method, you will have to describe a subject of interest in a way that has not been used before. In this case, instead of a reference to a library description method, you must attach a documentation of the description method prepared by you: descriptions cannot be made without specifying the description method. The description method is an alpha, so to witness the state of this alpha, an artifact/work product/document will be required. Description requires documentation, and the description method requires documentation.

The main point to remember is: any description is a description of a system, any system description is made using a description method (even if the describer is not aware of it), the description becomes accessible to people only after its documentation, the description method is a description of a description (hence questions about the description method of the description method are appropriate, as well as questions about documenting the description method of the description method!).

The description method (viewpoint) shapes (frames) the target characteristic (concern) of the project role. One consequence of the considered scheme: if a project role/stakeholder does not have a corresponding important characteristic/concern, then a description/view to satisfy interest in this characteristic is not made (and accordingly, this description is not documented, and the description method for it is also not needed): descriptions that do not address important characteristics for some roles are unnecessary, they are redundant. Even if some standard requires a certain description, but no one will read it (managers will just check it "for compliance with the standard"), such a description does not need to be created, it is a meaningless waste of project resources. And vice versa: if a project role has an important/target characteristic/concern, and its discussion begins, a description for such a characteristic is made and is mandatory documented. We are never talking about oral answers to questions. On paper, or in a database, or in files, but the description must be documented.

According to ISO 42010, descriptions (views) can be of two types: projective and synthetic.

Projective descriptions are similar to a theater spotlight where the lamp is white, but we create a colored beam by simply filtering out all colors except the one we like. In fact, this means that we have a large database in which all interconnected various models of different role descriptions are stored together in some format of documentation. But when we need data from one model, only what is needed is filtered out from this jointly stored single database document as a system description (requested role descriptions, or even requested individual models from these descriptions) and displayed in suitable document formats.

Synthetic descriptions, on the other hand, present the initial role descriptions in the form of separate model documents, where each model is documented not just as part of a single common database for all models (as in projective descriptions) but as an individual paper or electronic document. Correspondence rules are established between these autonomous models from separate documents (such as “this object of this model is that element of that model”), and the overall system description model is thus synthesized by combining separate autonomous specific models. Discussions about systems/full and role/specific system descriptions do not change based on how these descriptions are assembled from model documentation—immediately in a general document (projective approach to descriptions) or after creating separate model documents (synthetic approach).

Synthetic and projective descriptions turn out to be equivalent in terms of thinking about working with descriptions presented in ISO 42010; the set of concepts proposed works for both options. It just takes a lot of effort to coordinate independently prepared descriptions in synthetic descriptions, "lifecycle data integration." And in projective descriptions, a lot of effort is required before starting the modeling of a specific system to align description methods for documenting all role descriptions in one database. In general, of course, synthetic descriptions win because they do not imply preliminary huge work on integrating modeling tools. But the desire to have projective descriptions that are convenient to work with afterward is quite strong. Therefore, modern projects have several specific projective descriptions, together making up a synthetic one (since none of the specific projective descriptions reflects all project subjects of interest).