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 Eclipse or VS Code) 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.

• The UmpleOnline web interface is at try.umple.org

• The user manual is at manual.umple.org

• The Umple home page is at www.umple.org

• Umple download page: umple.org/dl

Current and former students working on the project are listed on Dr. Lethbridge's grad students page.

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:
  1. 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.

  2. 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.

  3. 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.

  4. 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?