How are Conceptual Models used in Industrial Software Development?

Harald Störrle
QAware GmbH
How are Conceptual Models used in
Industrial Software Development?
A Descriptive Survey
EASE, Karlskrona, 2017-06-15

Modeling in Industry (DMP-4)
Harald Störrle, 2017-06-15
BTH Karlskrona
2/21
Motivation
Who uses models, and what for?
▪ There are disjoint camps with diverging opinions on what models
are good for, who uses them, and how.
▪ Both of these are in contrast to my own practical experience and
research in industry.
▪ Existing studies seem to support either one or the other opinion,
depending on community.
The Model Driven Architect
Models are code
Not developing Software with
MBSD/MDA is poor practice
UML ought to be taught in 1st term
The Agile Adopter
The truth is in the code
Not developing software with
XP/SCRUM/… is poor practice
UML is not used at all in industry

BTH Karlskrona
3/21
Motivation
Goals, Questions, Expectations
▪ Goals
▪ Establish facts where opinions prevail so far.
▪ Highlight the importance of the viewpoint as a decisive factor.
▪ Establish this (differentiating factors) as a research topic in itself.
▪ Questions & expectations
▪ RQ1: Are conceptual modeling languages like UML or BPMN (widely) used in
the (software) industry at all? [yes]
▪ RQ 2: When, for what purposes, and by whom are models used in industrial
software development? [?]
▪ RQ 3: Are there distinct usage modes for models, and if so, how many can be
distinguished? [yes; Fowler’s trinity?]
▪ RQ 4: What is the relative frequency of the usage modes of models? [?]
▪ Descriptive Survey; large scale interview study in progress

BTH Karlskrona
4/21
Study Setup
Overview
▪ Grouping:
▪ Self assessment, min. 3 years of experience
▪ Question Items
▪ Intitial set of model usage modes based on interview study
▪ Participants were asked to offer other usages, resulting in one additional item (”test generation”)
▪ Recruiting
▪ Convenience sampling at first (fliers, advertising at presentations, ...)
▪ later more active triggering of people to cover North America

BTH Karlskrona
5/21
Study setup
Education, Occupation, Region
▪ We recruited well-educated senior IT professionals world wide.
▪ Participants mostly from Europe, Brazil, India, from industry, CS background
▪ Unlike students, academics, or junior professionals, their opinion should be
mostly shaped by experience and reality, not academic goodthink.
▪ High level of education, mix of industries and job descriptions.

BTH Karlskrona
6/21
Participants
Experience in industry/modeling

BTH Karlskrona
7/21
Participants
Organizations, Roles

BTH Karlskrona
8/21
Models
Usage context, modeling languages

BTH Karlskrona
9/21
Observations
Importance of modeling
▪ Everybody in the population uses models and is actively
modeling.
▪ "How can you not model?"
▪ There is more detail to observe, however.
▪ “There are no projects without modeling, but there are different kinds of
modeling.”
▪ Modeling is considered very important, a defining element of SE
professionalism.
▪ “Modelling will allow software development to evolve from craftsmanship to
an engineering discipline in the traditional way.”
▪ Clearly, the population sampled is pro-modeling, which limits the
generalizability.

BTH Karlskrona
10/21
Observations
Purpose of modeling
▪ Participants associate many different benefits with modeling.
▪ Communication, conception, and knowledge transfer are clearly and by far the most
frequent.
▪ Generating code (and other formal usages) are the least frequent, but they do occur to a
significant amount.

BTH Karlskrona
11/21
Finding
Modeling modalities
A
Informal models support thinking and communication,
utilizing rich information implicit in the situational context.
Capturing contextual information in the model is not just no
improvement, but effectively damaging the usefulness of the
model in these settings.
B
Partially formal models support design and documentation
activities. Here, more detail must be included and greater
precision must be exacted such that the model can stand for
itself, outside a given situational context.
C
Fully formal models are to be taken literal and binding, so as
to allow the analysis of system properties, simulation, and
generation of code and test cases. Fully formal models can also
be used like legal documents such as contracts, or other
formalized agreements.

BTH Karlskrona
12/21
Observations
Purpose of modeling by seniority
▪ When splitting answers by seniority (senior professionals vs. everybody else),
differences emerge in the ordering within groups.
▪ Very little change is seen between senior professionals and the whole population.
▪ However, the overall picture (grouping) remains unchanged.

BTH Karlskrona
13/21
Observations/Findings
Beneficiaries of modeling
▪ Software Architects are the main beneficiaries of models (98%).
▪ Everybody agrees on this, including software architects and all other roles.
▪ Other project roles benefit less (~70-90%).
▪ Development roles still benefit substantially (86-93%).
▪ Organizational roles (PM, client) benefit less (71-77%).
▪ End users benefit least, but still seem to benefit somewhat (39%).
▪ Other beneficiaries that are mentioned once or twice include Knowledge
engineers, enterprise modelers, regulatory bodies, UX/UI designers,
technical risk analyst, DB admins, students (problem comprehension/
presentation), Technical writers, product managers, contract managers.

BTH Karlskrona
14/21
Observations
Benefits of modeling
▪ Participants agree on the beneficial impact of models.
▪ 93% of the participants agree that modeling improves software quality.
▪ 86% think that modeling is helpful if and when it is being used.
▪ 72% believe that modeling saves effort.
▪ 66% report modeling decreases delivery time, and 61% report increased agility.
▪ Still, participants are divided about the ”MDA vision”.
▪ Comprehensive code generation from models is a contentious proposition even in a pro-
modeling population.

BTH Karlskrona
15/21
Observations
Experiences with modeling
▪ Participants disagree somewhat on the application conditions,
while they all outline particularly demanding situations.
▪ “Good modeling is time consuming and needs know-how. It should always be
done for products with a long lifecycle. I won't use modeling for small
experiments.”
▪ “Modeling for code generation can (only) be useful in certain domains, e.g.
smaller systems with safety critical applications."
▪ This implies that modeling takes up-front cost that has to be
justified or later recovered.
▪ Size of target system seems to be a shared concern
▪ “I miss an important question […]: what size of software/system are subject
of your modeling activities?”

BTH Karlskrona
16/21
Observations
Issues with modeling
▪ Participants highlight some issues with current modeling languages.
▪ “Modeling languages SHOULD be simple conceptually: easier for the user, easier
to write tools.”
▪ “Many modelling languages such as UML are under-specified which creates
confusion and allows for different interpretations of a model.”
▪ Most issues raised, however, pertain to modeling tools and methods
▪ “Moreover, the available tools, such as UMLet and Microsoft Visio, are often
frustrating since they either don't have the capability to create every model or are
annoying to use (erroneous resize, move, ...). Also most tools are not strict in their
use and allow syntactically wrong connections. They also do not perform
semantic checks, such as duplicate detection, inefficient pattern usage etc.”
▪ “There is no really good tooling available when it comes to modelling plus
requirements engineering plus development plus testing plus bug tracking plus
traceability. This is a big burden when you want to do modelling.”
▪ “Many ‘great modeling tools/methods’ are only applicable in case of small
systems, e.g. student projects or ‘hello world examples’.”

BTH Karlskrona
17/21
Observations
Meaning of "model“, kinds of modeling
▪ Some participants understood “model” in the sense of “mathematical model”
rather than SE model
▪ “Seems like I have a different understanding of the term modelling.”
▪ “[My] definition of “model” [is] very liberal […] any abstract description of a real artefact.”
▪ Participants distinguish between different modes or scenarios of modeling.
▪ “There are no projects without modeling. But there are different kinds of modeling.”
▪ “Not in every scenario, I will use a dedicated modeling tool to create something that is a model in
the strict sense of the word. For instance, to communicate with my colleagues, I will often draw
sketches that might incorporate some modeling notation.”
▪ The distinction is based on the purpose of modeling and, linked to it, the degree of
formality of the model.
▪ “Programming ought to be considered just a special case of modelling (although in my responses
to this survey I answered without that assumption). Textual modelling tools tend to be easier and
faster to use than graphical tools, although diagrams must be generated to view the model
(ideally 'as you type') and understand what you have typed. Most modelling tools are either
awkward to use, lack key features (such as good code generation) or are too expensive.”
▪ “ ‘Modeling’ is vague […] it can range from information sharing at a whiteboard to construction
of entire applications using modelling tools and code generation. My answers correlate MOSTLY
to the former meaning, a lot less to the latter (code generation).“
▪ “Modeling for communication between humans and modeling for generating code can not be
done using the same models - in case of large, real world applications. Models for code
generation are graphical programs, at the end - too detailed, too technical for easy
understanding. On the other hand, models for communication require “strong” abstractions
which make them inappropriate for code generation.”

BTH Karlskrona
18/21
Observations
Further topics suggested by participants
▪ 84 out of 96 participants (87%) did not answer at all or answered negative.
▪ 12 participants (13%) answered positive, suggesting to add questions about
▪ model quality, different types of models, distribution of model usage...
▪ if modelling is done with the help of a tool
▪ Difficulties and failures when applying models
▪ What are the prerequisites in a project to apply modelling?
▪ Modeling for specific application scenarios or concerns
▪ modeling with regard to safety standards as IEC 61508.
▪ to trace changes, generate tests, in software maintenance
▪ Usefulness, relevance, and usability of models, modeling, and modeling tools
▪ How much have you learned from models? (patterns, taxonomies, ...)
▪ what size of software/system are subject of your modeling activities?
▪ Questions proposed by participants.
▪ “Have you received formal training in any model?”
▪ “How about "Do you prefer graphical or textual modeling? Why?"

BTH Karlskrona
19/21
Conclusions
Threats and Limitations
▪ Is the population representative?
▪ No.
▪ Is the questionnaire valid?
▪ Are the question items biased by the researcher?
▪ Yes. However: the participants, while ready to offer their opinions, did not offer much in
this direction.
▪ Is there bias through the different numbers of items per group?
▪ No (see next slide)
▪ Additionally, this „bias“ could only have been avoided by starting with the hypothesis of the
three modes up front and using it for questionnaire design.
▪ Do I overstretch my data?
▪ I don‘t think so.

BTH Karlskrona
20/21
Conclusions
Threats and Limitations
▪ There are different numbers of items for the different modalities.
▪ Does this bias the outcome?
a) Larger number of items per mode might dilute the answers, biasing in favor
of A/B over C.
b) Conversely, presenting more items per mode may inflate the mentions of C
over A/B.
▪ Bias a) is unlikely:
▪ There are still differences between A/B with almost the same number of
items
▪ Both absolute and relative counts show the same picture.
Mode Items Never
(per item)
Rarely
(per item)
Sometimes
(per item)
Often
(per item)
Always
(per item)
A 4 18 (4.5) 23 (5.8) 76 (19.0) 161 (40.3) 76 (19.0)
B 5 44 (8.8) 69 (13.8) 111 (22.2) 155 (31.0) 63 (12.6)
C 8 195 (27.9) 109 (15.6) 130 (18.6) 99 (14.1) 45 (6.4)

BTH Karlskrona
21/21
Conclusions
Summary
▪ Models are widely used in the software industry.
▪ “Models” are also used in other domains, with different meanings.
▪ Modeling is considered a sign of professional progress.
▪ There are three modes of using models in Sw. Development.
▪ Informal models for communication and conception are very widely used.
▪ Semi-formal models for design and documentation are common.
▪ Code generation is a only niche application, but does happen.
▪ Software architects are considered to be the main beneficiaries of models and
modeling.
▪ Neither the “Model Driven Architect” nor the “Agile Adopter” are completely right,
or wrong.
▪ It is certainly wrong, tough, to claim modeling or any particular mode of modeling does not
happen in industrial software development.
▪ More research is needed to differentiate between environment factors promoting
or inhibiting the various usage types.
▪ Different industries might offer different setups (regulatory pressure, market pressure,
cultural/regional influences, …)
▪ We should differentiate better between modeling, using UML, and full-blown
MDE.

How are Conceptual Models used in Industrial Software Development?

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie How are Conceptual Models used in Industrial Software Development?

Ähnlich wie How are Conceptual Models used in Industrial Software Development? (20)

Mehr von QAware GmbH

Mehr von QAware GmbH (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

How are Conceptual Models used in Industrial Software Development?