The state of affairs in computer-aided software design

Abstract

In this paper we examine the current state of affairs in Computer-Aided Software Engineering (CASE) (W) tools specifically aimed at software design. We look at individual tools as well as entire categories of tools with respect to applicability and effectiveness, and we notice their abject inadequacy.

This post is support material for michael.gr - Towards Authoritative Software Design.

(Useful pre-reading: About these papers)

The list

Through the decades, many tools and methodologies have been developed with the intent of aiding the software architecture and design process. A common pattern in them is that they try to make some aspect of development more visual rather than textual. Here is a long, but non-exhaustive list:

• Integrated Development Environments (IDEs) (W) - They are limited to fancy source code editors, (see below,) form builders, (see below,) and visualization tools. (see below.) As such, they are implementation tools, not design tools.
• Fancy Source Code Editors - No matter how fancy, they express implementations, not designs.
• Form Builders (a.k.a. graphical user interface (GUI) editors) - They only help define those small parts of a system that are visible by the user, and they can only specify their looks, not their functionality.
• Visualization Tools (e.g. class diagrams, dependency diagrams, call trees, etc.) - These are invariably restricted to the visualization of various aspects of existing systems, rather than the design of new systems, or the modification of existing systems. As such, they are reverse-engineering tools rather than design tools.
• Cloud Infrastructure Visualization Tools (e.g. Lucidscale, Cloudviz, Hyperglance, etc.) - They suffer from the same drawbacks as visualization tools, and they are also limited to specific realms, i.e. the cloud environments of particular vendors.
• Visual Programming Languages (W) (e.g Snap! (W), Scratch (W), EduBlocks (W), Blockly (W), etc.) - They are indeed visual, and they do in fact produce runnable software, but they are structurally equivalent to code, so they express implementations rather than designs. (See michael.gr - On Visual Programming Languages.)
• Microsoft "Visual" Programming Languages (e.g. Microsoft Visual C++) - There is nothing visual about them; their name is just a marketing ploy. (See michael.gr - On Microsoft "Visual" products.)
• Diagramming Software (W) (e.g. Microsoft Visio (W)) - They are good for making fancy diagrams, and they keep the arrows connected to the boxes as we drag the boxes around the canvas; however, they have no understanding of the actual meaning of those boxes and arrows, so they are restricted to modeling.
• Modelling Languages (W) and tools (e.g. Unified Modeling Language (UML) (W), the Context, Containers, Components, Code (C4) Model (W), ArchiMate (W), etc.) - They aim to constrain what can be added to a design, but these constraints exist only in theory, because they are not enforced by any technical means. The primary aim of UML in particular was to standardize the notation of diagrams, but it is very cumbersome to work with, so it is largely considered dead. (See michael.gr - On UML.)
• Specification languages (W) (e.g. Specification and Description Language (SDL) (W)) - They do see some use in certain niche domains such as process control and real-time systems; however, they describe implementations rather than designs.
• Web Services Description Language (WSDL) (W) - It exclusively focuses on the narrow domain of web services, and therefore cannot be used for software design at large.
• Business Process Modelling (BPM) tools (W) e.g. Business Process Execution Language (BPEL) (W). - They do see some use in describing business processes within software systems, but not the software systems themselves.
• Component-Based Software Engineering (CBSE) technologies (W), (e.g. Microsoft OLE (W)) - Existing implementations suffer from critical limitations such as:
• Assuming the exclusive use of a particular operating system or operating environment.
• Assuming the exclusive use of a particular programming language.
• Requiring components to include debilitating amounts of bureaucracy.
• Forcing components to be heavyweight, sometimes as heavyweight as a process.
• Requiring components to communicate exclusively via a specific mechanism, such as asynchronous message passing, data streams, etc.
• Complete absence of visual design tools, even though such tools could, in principle, be developed.

The shortcomings of these technologies are reflected in the limited extent of their adoption. Whatever meager adoption Microsoft OLE in particular enjoys can be attributed to coercion rather than merit: it is the only way to accomplish certain things under Microsoft Windows, so people use it because they have to, not because they want to. Nobody does OLE if they can avoid it.

• Rapid Application Development (RAD) tools (W) - They require the use of a particular programming language and a massive vendor-specific platform; they do not scale; they are aimed at easy creation of user-interface-centric applications rather than software design.
• No-Code Development Platforms (NCDPs) (W) and Low-Code Development Platforms (LCDPs) (W) - They require a massive vendor-specific platform; they impose limitations on what can be done; they are aimed at non-programmers, allowing easy creation of simple, small-scale, user-interface-centric applications to quickly meet specific narrow business needs without having to write code.
• Model-Driven Engineering (W) - Work in progress.
• Infrastructure definition tools (e.g. Terraform (W)) - Work in progress.
• SysML (W) - Work in progress.
• Structure101 (->) - Work in progress.
• The Open Group Architecture Framework (TOGAF) (W) - Work in progres
• Lattix (->) - Work in progress.
• IBM Rational Rose (W) - This was a suite of UML tools. It has been discontinued.
• Rational Software Architect Designer (->) - Work in progress.
• Architecture Description Languages (W) - Work in progress. (Modelling languages without the modesty of admitting that they are limited to nothing but modelling?) 
• Flow-based Programming (W) (E.g. NoFlo (->))  - Work in progress. 

Of all the technologies listed above, only diagramming tools (e.g. Visio) and modelling languages (e.g. UML) can legitimately be said to be of any potential usefulness in the software design process at large; however, these tools are restricted to modelling, and as such they are nothing more than fancy whiteboards.

For what is wrong with whiteboards, please see michael.gr - The perils of whiteboards.

For what we should be doing instead, please see michael.gr - Towards Authoritative Software Design.

 

---

 

Cover image: Created via ChatGPT with the prompt "please give me a photographic quality image of a 40-year-old programmer in a home-office environment looking at a computer screen with disappointment and resignation" and "please give me the same picture but his frown a bit less exaggerated".