Stanislaw Niepostyn

Stanislaw Niepostyn
Warsaw University of Technology · Institute of Computer Science

Doctor of Philosophy

About

20
Publications
5,223
Reads
How we measure 'reads'
A 'read' is counted each time someone views a publication summary (such as the title, abstract, and list of authors), clicks on a figure, or views or downloads the full-text. Learn more
40
Citations

Publications

Publications (20)
Conference Paper
This paper presents a survey of consistency rules identified between UML diagrams. It bases on a representative collection of publications and author’s experience of developing original method of software architecture construction (e-CMDA). A new notation for consistency rules is introduced. It uses regular expressions combined with symbols of UML...
Article
This paper presents a survey of consistency rules identified between UML diagrams. It bases on a representative collection of publications and author’s experience of developing original method of software architecture construction (e-CMDA). A new notation for consistency rules is introduced. It uses regular expressions combined with symbols of UML...
Article
Since the birth of software architecture IT architects have combined various diagrams applying similar names for their elements. These constructions, now called consistency rules, introduce a vastly improved quality of software development and at the same time bring more information content to the software architecture of the system itself. It was...
Conference Paper
Full-text available
An improved method of complex computer systems design could be implemented in the environment of the object-oriented software, in particular in the BPM environment (Business Process Management) and using the Enhanced CMDA concept (shortly named e-CMDA, where CMDA denotes the Consistent Model Driven Architecture). Thus, it enables automating the des...
Conference Paper
Full-text available
A description of software architecture is a plan of the IT system construction, therefore any architecture gaps are affect the overall success of an entire project. The definitions mostly describe software architecture as a set of views which are mutually unrelated, hence potentially inconsistent. Software architecture completeness is also often de...
Conference Paper
Full-text available
The goal of the MDA is to produce software systems from abstract models in a way where human interaction is restricted to a minimum. These abstract models are based on the UML language. However, the semantics of UML models is defined in a natural language. Subsequently the verification of consistency of these diagrams is needed in order to identify...
Article
Full-text available
UML activity diagrams are primarily used to visualise scenarios. The verification of activity diagrams consistency is subsequently needed to identify errors in requirements at the early stage of the development process. The consistency verification is difficult due to a semi-formal nature of activity diagrams. We propose to extend the activity diag...
Conference Paper
Full-text available
It would be unreasonable to capture everything we want in a single comprehensive diagram. Such diagram would be too big and complex, and primarily too confusing to display all architectural concerns. Key software architecture aspects should be therefore captured in several diagrams or even models, while the architectural details are grouped in adeq...
Conference Paper
Full-text available
BPMN diagrams are more and more often used to visualise scenarios in use case driven IT projects. The verification of consistency of BPMN diagrams is subsequently needed to identify errors in requirements at the early stage of the development process. The consistency verification is challenging due to a semi-formal nature of BPMN diagrams. We exami...
Chapter
Full-text available
In most projects UML models are systematically modified and refined in the software development process. Existing software development methodologies are not explicitly describing transitions between different views, models, and appropriate elements of models. The three dimensional Document Circulation Diagram (3D DCD) enables to design the function...
Conference Paper
Full-text available
Currently, no single UML diagram provides the satisfactory completeness and consistency of the system description. There is also no BPMN diagram to satisfy such requirements. The satisfactory completeness means that the model enables to describe fully a function, a structure, and a behaviour of the IT system. With BPMN diagram one cannot provide a...
Conference Paper
Full-text available
A new approach to mapping from BPMN diagrams into XPDL standard and the implementation of these mappings made in Dodocum modeller environment is presented. The business processes are modelled in the BPMN notation. In result refined BPMN diagrams and automatically generated DCD diagrams become round trip transformable, thus aligning services with bu...
Article
Full-text available
W niniejszym artykule przedstawiono narzędzie do kontroli spójności trzech podstawowych diagramów UML za pomocą modelu przestrzennego DOD (Diagram Obiegu Dokumentów) zrealizowane w środowisku TOPCASED. Model przestrzenny DOD umożliwia zaprojektowanie struktury aplikacji jej zachowania i funkcjonalności. Taki sposób modelowania docelowego systemu um...
Chapter
Full-text available
W niniejszym rozdziale przedstawiono diagramy obiegu dokumentów (DOD) służące do opisu systemów obiegu dokumentów. Zaproponowano prostą metodę porównywa-nia metod modelowania procesów biznesowych opartą na szacowaniu widoczności ta-kich cech jak przepływ sterowania i danych, wykonywane czynności, wizualizacja obiektów, systemów, aktorów. Metodę tę...

Questions

Questions (5)
Question
In my UNCR (UNIVERSAL NOTATION FOR CONSISTENCY RULES) notation, these four consistency rules from Table III would take the form: 1. CcAi; 2. ApCc; 3. AvCch; 4. AvCch. All these rules have already been proposed by Chanda, J., Kanjilal, A., Sengupta, S., Bhattacharya, S. in the publication "Traceability of Requirements and Consistency Verification of UML UseCase, Activity and Class diagram: A Formal Approach" from 2009. The third and fourth have already been proposed by Sapna, P., G., Mohanty, H. in the publication Ensuring Consistency in Relational Repository of UML Models from 2007. The second, third and fourth were proposed by Xianhong, L. in the publication "Identification and Check of Inconsistencies between UML Diagrams" from 2013. These are so-called consistency rules very popular in the literature. And in the design of software architecture, the most used rule is BuAv, and more specifically: Bu«scenarios»An«start»(v+|i+)+n«stop». It is simply a visualization of the business use case in the form of a scenario model in the activity diagram.
Question
What is the consistency rule?
If we consider the nature of consistency [Spanaudakis, Zisman 2001], then we imagine that the consistency rule is a relationship between
two elements of different diagrams.
Let's just consider these consistency rules, which are relations between elements of different diagrams.
If we're using the uppercase letter UML diagram type, and the lowercase UML element of this diagram, then we would get the following table for UML diagrams and the next table for UML elements.
Table 1. UML diagrams
A - Business Use Case Realization Diagram (ACT)
B - Business Use Case Diagram (UC)
C - Business Class Diagram (CLASS)
Q - Internal Use Case Realization Diagram (SD)
S - Business State Machine Diagram (STM)
U - System Use Case Diagram (UC)
Z - System Use Case Realization Diagram (ACT)
Table 2. UML elements
a - Actor (UC)
c - Class (CLASS)
h - Operation (CLASS)
i - Instance (ACT)
l - Lifeline (SD)
m - Message (SD)
p - Partition (ACT)
s - State (STM)
u - UseCase (UC)
v - Activity (ACT)
More markings for diagrams and elements can be found at
Using these designations as regular expressions, we can get some common consistency rules and, by the way, identify duplicates of the proposed consistency rules:
1. BuA - mapping between business use cases and activities [Hausmann 2002, Ibrahim 2011]
2. BaQl - mapping between business actors and sequence lifelines [Sapna 2007]
3. UaQl - mapping between system actors and sequence lifelines [Shinkawa 2006, Ibrahim 2012] - similar as 2.
4. JchQm - mapping between class operations and sequence messages [Sapna 2007, Vasilecas 2009, Khai 2011, Ibrahim 2012, Kalibatiene 2013, Xianhong 2013]
5. JcQl - mapping between classes and sequence lifelines [Sapna 2007, Khai 2011, Ibrahim 2012, Kalibatiene 2013, Xianhong 2013]
6. AvCch - mapping between activities and class operations [Sapna 2007, Chanda 2009, Xianhong 2013]
7. AiCc - mapping between activity instances and classes [Chanda 2009].
What consistency rules do you use when constructing your software architectures? I use 87 such consistency rules.
Question
I have just published on this portal my next article, in which there is a mathematical proof that adding similar names to elements from various UML diagrams, increases the information content of software architecture (https://www.researchgate.net/publication/332963902_Proof_of_the_Decrease_in_Entropy_when_Applying_Consistency_Rules_in_Software_Architecture_of_IT_Systems?isFromSharing). Thus, the use of so-called consistency rules in UML diagrams increases the readability and ordering in software architecture. But does it cause more consistency of software architecture? And it has to be added that in most tools for creating software architecture, there is no automatic option of marking these consistency rules. Hence it is so difficult to define what are the consistency rules. But their use is extremely helpful in software development. Therefore, more or less conscious behavior in the construction of software architecture makes the most sense, because it reduces the entropy of software architecture, and thus increases its readability and organization. But at the same time, questions arise in connection with the application of consistency rules: 1) What is the consistency of software architecture, and 2) When is the architecture of the software consistent ? I believe that if the software architecture consists of consistent perspectives, it is consistent. If the perspective consists of consistency layers, it is consistent. And if the layer consists of consistency models (diagrams) it is consistent.
Question
What dimension describes a Use Case ?
Behavior ? A UseCase is a specification of behavior (18.1.1) - semantic rules
Functionality ? Each UseCase specifies a unit of useful functionality (18.1.3.1)
Behavior ? A UseCase inherites from the BehavioredClassifier (Fig. 18.1) - syntactic rules
Supplemental ? Use Cases belong to Supplemental Modeling (Figure 6.1) - semantic rules
What dimension describes a Port ?
Functionality ? Port is used to provide the published functionality (11.3.3.1) - semantic rules
Structural ? A Port inherites from the Property (Fig. 11.10) - syntactic rules - &
A Property inherites from the StructuralFeature (Fig. 9.10) - syntactic rules
Structural ? Common Structure belongs to Structural Modeling (Figure 6.1) - semantic rules
What dimension describes a Component ?
Functionality ? Component that offers equivalent functionality ... (11.6.3.1) - semantic rules
Structural ? A Component inherites from the Class (Fig. 11.38) - syntactic rules
Behavior ? A Class inherites from the BehavioredClassifier (Fig. 11.15) - syntactic rules
Structural ? An EncapsulatedClassifier inherites from the StructuredClassifier (Fig. 11.10) - syntactic rules
Structural ? Common Structure belongs to Structural Modeling (Figure 6.1) - semantic rules
What dimension describes an Interface ?
Functionality ? The Interfaces ... offer its full set of provided functionality (11.8.6.5) - semantic rules
Structural ? An Interface inherites from the Classifier (Fig. 10.7) - syntactic rules
Behavior ? A BehavioredClassifier is composed of InterfaceRealizations (Figure 10.7) - syntactic rules
Structural ? Common Structure belongs to Structural Modeling (Figure 6.1) - semantic rules
Question
Software architecture is a plan for software development. Agile methods perceive software architecture as something from the past, equating it with big design up-front (BDUF)—a bad thing—leading to massive documentation and implementation of YAGNI (you ain’t gonna need it) features. Does such software architecture exist, which would be useful in agile methods?

Projects

Projects (2)
Project
A description of software architecture is a plan of the IT system construction, therefore any architecture gaps are affect the overall success of an entire project. I propose the method of fast constructing of the series of UML diagrams originating from abstract models implemented with consistency rules. The proposed method enables IT architects to decide whether the modelling process is complete and consistent. The overall benefit of such an approach is that it facilitates the preparation of complete and consistent software architecture more effectively as well as it enables assessing and monitoring of the ongoing modelling development status. I applied this method in a few industry of IT system designs
Project
An improved method of complex computer systems design could be implemented in the environment of the object-oriented software and using the Enhanced CMDA concept (e-CMDA). It thus enables to automate design of the underlying software architecture while applying consistency rules of UML diagram series which are based on the calculation of entropy of UML diagrams using the FBS software architecture metric. IT systems produced along the e-CMDA are built up quicker, more productively, and less erroneous, what makes such architectures particularly useful for agile development methods. Comparability is an additional feature of e-CMDA methodology as it directly outcomes from the implementability assessments of different software architectures by means of objective calculation of consistency, completeness and transformability of diagrams.