Complexity Reduction in Software Engineering (CRuiSE)
CRuiSE is the research group of Dr. Timothy C. Lethbridge, in the
School of Information Technology and Engineering 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 a text editor, most
likely in an IDE like Eclipse, and 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.
Below you can read about the students currently working on the
project, as well as some of the ideas and research questions we are
investigating.
Note that since this is ongoing research, anything and everything
may change here!
Current students
The following are the students currently working as members of this
team:
Andrew Forward, PhD student. Andrew is researching how to
bridge
the gap between graphical modeling, textual modeling and programming.
Part of his research involves conducting a survey about why people model
(or why not). Dusan Brestovansky, MSc student. Dusan is creating the
first version
of the Umple Language compiler.
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
- 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 language like
Umple?
- If Umple was available to software engineeers, would they use it?
- To what extent would textual-based modelling benefit software
engineers?
- Would users of different modelling languages such as BPEL and UML
all benefit from a textual alternative?
|
