Complexity Reduction in Software Engineering (CRuiSE)
CRuiSE is the research group of Dr. Timothy C. Lethbridge, in the
School of Electrical Engineering and Computer Science at the University of
Ottawa.
The acronym has "Complexity Reduction" and "Software Engineering" as
keywords. But the "ui" in the centre is critical: Reducing complexity
means, to a large extent, keeping the the "user interface" central.
However, we are not just talking about the interface for the end-user of
software, we are also talking about the interface for software engineers;
in particular the programming languages, modelling languages and other
software engineering tools they use.
Overview of the research
One of the biggest challenges to software engineering is complexity.
Software systems are naturally complex due to the tendancy to develop
large numbers of features (and hence vast volumes of code) to satisfy the
perceived and real requirements. However, there is a great deal we can do
to reduce the complexity, and this research group investigates a
variety of these.
Part of our research is to study what software engineers find complex,
and why many of them are resistant to techniques such as modelling and
using software engineering tools that are supposed to simplify
development. We are studying how to unify the notions of programming amd
modelling, so software engineers can develop and maintain systems quickly
and at a high level of abstraction.
One of our ongoing subprojects is to develop a language called
Umple
which is designed to inccorporate modelling concepts such as
associations, attributes, states and actions into a programming language.
The developer/programmer would be able to work using any text editor, any
IDE (such as VS Code or Zed) as well as in a web browser. Se or he would be able to specify the above
high-level constructs as well as lower-level algorithmic code all in a
textual form. However, the graphical form would not be lost, as visual
representations (like UML), would still appear.
Current and former thesis students working on the project are listed on Dr. Lethbridge's grad students
page. Many project students have worked on the project, at both the 4th year and Masters level.
All Umple contributors are listed in the license.
Some of our hypotheses
- There need be no distinction between programming and modelling.
- Software engineers are resistant to modelling for some of the
following reasons:
- Graphical modelling tools are not as fast to use as programming
tools, largely due to the need to use the mouse to build diagrams. This
could be potentially overcome if models could be created and edited with
a text editor, in the same manner as a program is edited.
- Modelling languages do not allow software engineers to express all
the ideas they want, or do not make it easy to express ideas as
programming languages.
- In general, software engineers are not well trained in modelling
languages such as UML, so do not know how to take good advantage of
them.
- The most powerful tools for modelling tend to be expensive, causing
resistance to their use, especially among those in smaller companies and
those developing open-source software on their own. On the other hand,
the less powerful tools tend to merely allow drawing diagrams, as
opposed to creating executable systems.
- The majority of software engineers using UML just draw pictures
(primarily class and state diagrams), and do not generate code from these
diagrams. Reasons for this include complexity, expense and inflexibility
of tools.
- Those programming in Object-Oriented languages tend to use many
idioms and patterns that require boilerplate code. Examples include the
code necessary for manipulating links of associations, the code to
implement state machines, and the code for patterns such as Singleton. It
would be better to build primitives for these into programming
languages.
Some of our research questions
- With the advent of AI and LLMs for coding assistance, how well can modeling
languages be generated by AI, and would be the benefit of using AI to generate
model code like Umple (that can then generate final systems)
rather than using AI to directly generate the final systems,
- What proportion of software engineers use modelling languages and
what for?
- What are software engineers' reasons for using modelling languages,
or not?
- What features should we provide in a programming technology like
Umple?
- If Umple was available to software engineeers, would they use it?
- To what extent would textual-based modelling benefit software
engineers?
- Beyond plain modeling, what other features could be added to a language like
Umple, such as capabilities to manage product lines
|
