P-Modeling Framework

Last updated April 28, 2020

P-Modeling Framework is a package of guidelines, methods, tools and templates for the development process improvement. P-Modeling framework can be integrated into any other SDLC in use, e.g., MSF Agile, MSF CMMI, RUP, etc.

History

The origins of P-Modeling Framework come from "The Babel Experiment" designed by Vladimir L. Pavlov in 2001 as a training program for software engineering students that was aimed at making students go through a “condensed” version of communication problems typical for software development and gain the experience of applying UML to overcome these problems.

This experiment was done in the following manner. A team of students was assigned the task of designing a software system with the following restriction factor: UML had to be the only language allowed for communication while working on the project. The premise was intended to make students go through a “condensed” version of communication problems typical for software development and gain the experience of applying UML to overcome these problems. As the result of this experiment, students developed quite clear and concise models.

A little later, during a design session, there were two independent teams working on the same task. The communication means of the first team was restricted to UML as described above, while the other team was allowed to communicate verbally using a natural language. It turned out that the first, more restricted team, performed the task more efficiently than the other one. The UML diagrams created by the first team were more sound, detailed, readable, and elaborated.

Subsequently, Vladimir L. Pavlov conducted a number of additional experiments intended to reveal whether the “silent” modeling sessions are more productive than the traditional ones. In these experiments, silent teams appeared to be at least as efficient as the others, and in some cases the silent teams outperformed the traditional ones.

Some of the interpretations of these results are the following:

The restriction on using a natural language may stimulate creativity of the designers as well as force them to stay focused on their job;
Work in speechless mode may force designers to explicitly uncover all underlying assumptions at the very early stages of the design process;
UML is not treated as a superfluous burden irrelevant to real-life needs (as a “write-only” language) — instead, the designers may begin to demonstrate greater concern about the quality and readability of their models.

Afterwards, ideas were constructed for conducting additional new experiments with the intention of finding a method to compare UML to natural languages. The premise in these experiments was to set up forward (from a natural language to UML) and backward (from UML to the natural language) "translation" tasks for two teams of professional software designers. This would be done with one team performing the forward translation and the other one performing the backward translation. The intention was to observe how closely the outcome of the backward translation resembled the original text, thus providing verification of correctness of UML model.

The experiments showed that, for information describing software systems, UML has sufficient power of expression required to maintain the model's content. Texts obtained after the backward translation from UML were semantically equivalent to the original.

The experiments suggested the model of the entire software development cycle existed as a series of translations. In subsequent experiments backward translation verification has been demonstrated as a method to help guarantee deliverables of each development step do not lose, or have misinterpreted, anything that was produced at the previous step. This method has been named "Reverse Semantic Traceability." It has proven to be a solid second part completion to the P-Modeling Framework.

Basic principles

Reverse Semantic Traceability

Reverse Semantic Traceability is a quality control method that allows testing outputs of every translation step. Before proceeding to the next phase, the current artifacts are “reverse engineered”, and the restored text is compared to the original. If there is a difference between these two texts – the tested artifacts are corrected to eliminate the problem (or initial text is corrected.) Consequently, every step is confirmed by stepping back and making sure that development stays on the correct track. In this way, issues may be discovered and fixed without delays, so they do not accumulate, and do not cascade to subsequent phases of the development cycle.
The key word in the name of this method is “Semantic.” It is based on the fact the original and restored versions of a text are to be compared semantically, with a focus on the “meaning” of the text, not on particular “words” used in it.

The highest usage scenarios reported by early adopters of Reverse Semantic Traceability method are:

Validating UML models: quality engineers restore a textual description of a domain, original and restored descriptions are compared.
Validating model changes for a new requirement: given an original and changed versions of a model, quality engineers restore the textual description of the requirement, original and restored descriptions are compared.
Validating a bug fix: given an original and modified source code, quality engineers restore a textual description of the bug that was fixed, original and restored descriptions are compared.
Integrating new software engineer into a team: a new team member gets an assignment to do Reverse Semantic Traceability for the key artifacts from the current projects.

Speechless modeling

Being originally invented as an advanced training to teach Object-Oriented Analysis and Design with UML to students, the Speechless Modeling, in essence, is a restriction on using communication means directly or indirectly involving a natural language. In this way, a team of designers is forced to use the modeling language as the only language available for communication during a design session.

Incorporating P-Modeling Framework into Software Development Life Cycle (SDLC)

Regardless of what type of development process is used in an organization; waterfall, spiral, various iterative-incremental or some others, there are certain processes, such as software design, quality control, human resources management, risk management, communication management, etc. to which can P-Modeling Framework principles can be applied, especially in the earlier stages of a project when quality control activities are either minor or (virtually) absent.

Requirements and limitations

All the P-Modeling Session members should speak some graphical modeling language fluently.
Minimum of 8 qualified people required for full-blown P-Modeling Session.
Minimum of 3 qualified people required for an efficient RST Session.
P-modeling Framework doesn’t provide the possibility to detect ambiguous, contradicting, and incomplete aspects in requirements or client requests.
Speechless Modeling Session requires large amount of energy and efforts from participants.

Criticism

P-Modeling Framework obviously has some room for further improvement. For example:

P-Modeling Sessions require additional resources without knowledge of the original artifact and add extra workload for programmers.
While doing RST, texts should be compared manually which means that the framework lacks automation.
One of the possible outcomes in RST is the situation when people "design for RST" — they create artifacts in a way they can be easily reconstructed, without adding new value.
There’s no reliable statistical evidence of the P-Modeling Framework effectiveness.
The “silent design sessions” have quite a narrow applicability: only to systems and organizations that can and need document the system in graphical modeling language. This is not the case when:
- Company doesn’t have enough developers “speaking any graphical modeling language” fluently and knowing when and how to apply it, which means very highly qualified.
- Company doesn’t use any graphical modeling language extensively.
P-Modeling Sessions can’t help to differentiate between good design and bad design.

Related Research Articles

A data model is an abstract model that organizes elements of data and standardizes how they relate to one another and to the properties of real-world entities. For instance, a data model may specify that the data element representing a car be composed of a number of other elements which, in turn, represent the color and size of the car and define its owner.

Software design is the process by which an agent creates a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints. Software design may refer to either "all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems" or "the activity following requirements specification and before programming, as ... [in] a stylized software engineering process."

The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure.

Model-driven architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and supports model-driven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.

IDEF, initially an abbreviation of ICAM Definition and renamed in 1999 as Integration Definition, is a family of modeling languages in the field of systems and software engineering. They cover a wide range of uses from functional modeling to data, simulation, object-oriented analysis and design, and knowledge acquisition. These definition languages were developed under funding from U.S. Air Force and, although still most commonly used by them and other military and United States Department of Defense (DoD) agencies, are in the public domain.

Object-role modeling (ORM) is used to model the semantics of a universe of discourse. ORM is often used for data modeling and software engineering.

Process modeling a description of a process at the type level

The term process model is used in various contexts. For example, in business process modeling the enterprise process model is often referred to as the business process model.

Architecture description languages (ADLs) are used in several disciplines: system engineering, software engineering, and enterprise modelling and engineering.

An information model in software engineering is a representation of concepts and the relationships, constraints, rules, and operations to specify data semantics for a chosen domain of discourse. Typically it specifies relations between kinds of things, but may also include relations with individual things. It can provide sharable, stable, and organized structure of information requirements or knowledge for the domain context.

A UML tool is a software application that supports some or all of the notation and semantics associated with the Unified Modeling Language (UML), which is the industry standard general-purpose modeling language for software engineering.

Domain-specific modeling (DSM) is a software engineering methodology for designing and developing systems, such as computer software. It involves systematic use of a domain-specific language to represent the various facets of a system.

The Shlaer–Mellor method, also known as Object-Oriented Systems Analysis (OOSA) or Object-Oriented Analysis (OOA) is an object-oriented software development methodology introduced by Sally Shlaer and Stephen Mellor in 1988. The method makes the documented analysis so precise that it is possible to implement the analysis model directly by translation to the target architecture, rather than by elaborating model changes through a series of more platform-specific models. In the new millennium the Shlaer–Mellor method has migrated to the UML notation, becoming Executable UML.

Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

RST may refer to:

Model-driven engineering (MDE) is a software development methodology that focuses on creating and exploiting domain models, which are conceptual models of all the topics related to a specific problem. Hence, it highlights and aims at abstract representations of the knowledge and activities that govern a particular application domain, rather than the computing concepts.

Executable UML is both a software development method and a highly abstract software language. It was described for the first time in 2002 in the book "Executable UML: A Foundation for Model-Driven Architecture". The language "combines a subset of the UML graphical notation with executable semantics and timing rules." The Executable UML method is the successor to the Shlaer–Mellor method.

Reverse semantic traceability (RST) is a quality control method for verification improvement that helps to insure high quality of artifacts by backward translation at each stage of the software development process.

Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model.

In software engineering, a software development process is the process of dividing software development work into distinct phases to improve design, product management, and project management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

References

Vladimir Pavlov, Anton Yatsenko. Using Pantomime in Teaching OOA&OOD with UML. 18th IEEE Conference on Software Engineering Education and Training (CSEE&T), Ottawa, Canada.
Vladimir Pavlov, Anton Yatsenko. The Babel Experiment: An Advanced Pantomime-based Training in OOA&OOD with UML. 36th ACM Technical Symposium on Computer Science Education (SIG CSE 2005), St Louis, Missouri, USA.

External links

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.