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) tools specifically aimed at Software Architecture and Software Design. We examine individual tools as well as entire categories of tools with respect to applicability and effectiveness. We notice the abject inadequacy of existing solutions.

(Useful pre-reading: About these papers)

Through the years, many tools have been developed with the intent of aiding the software architecture and design process, or at least making the software engineering process more visual rather than textual. Here is a long, but non-exhaustive list of individual tools and/or categories of tools:

• Integrated Development Environments (IDEs) (W). These are restricted to fancy text editors for source code, form builders for user interfaces, and perhaps a few ways of graphically illustrating, but not defining, various aspects of a software system under development, such as class diagrams, dependency diagrams, call trees, etc. As such, they are software development tools, but not software design tools.
• 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.)
• Visual programming languages (W) e.g Snap!, Scratch, EduBlocks, Blockly, etc. They do in fact produce runnable software, but they are structurally equivalent to program code, so they express implementations rather than designs.(See michael.gr - On Visual Programming Languages.)
• Diagramming software (W) e.g. Visio. They are good for making fancy diagrams, and they do in fact keep the arrows connected to the boxes as we drag the boxes around, but they have no inherent understanding of the meaning of the arrows and the boxes: they are not informed by the actual available software components, nor of valid ways of interconnecting them, and they cannot automatically convert diagrams into working software systems.
• Modelling Languages (W) e.g. UML (W), the C4 Model (W), etc. As the name implies, they are used for modelling, but not for actually building software systems. Some tools support automatic scaffolding code generation, but this is based on the all-design-up-front fallacy: once scaffolding code has been automatically generated, and hand-written code has been added, changing the design and re-generating the scaffolding code is bound to produce a big mess, since the hand-written code does not match the scaffolding code anymore.
  UML in particular aims to standardize at least the notation of diagrams, but it is very cumbersome to work with, so a large percentage of programmers have developed an acute aversion to it. It is largely considered dead. (See michael.gr - On UML.)
• Architecture Description Languages (W) hese tend to be modelling languages without the modesty of admitting that they are limited to nothing but modelling.
• Specification Languages (W), such as Specification and Description Language (SDL) (W). These do see some use in niche applications such as process control and real-time applications, but they are suitable for describing implementations rather than designs.
• Business Process Modelling (BPM)(W) tools, e.g. Business Process Modeling Notation (BPMN) (W). They see some use in describing business processes within software systems, but not the software systems themselves.
• Visualization tools, e.g. Lucidscale. These are invariably restricted to the visualization, exploration, and documentation of existing systems, rather than the design and deployment of new systems, or even the modification of existing systems. As such, they are reverse-engineering tools rather than design tools. Furthermore, they tend to be limited to specific realms, such as the cloud environments of particular vendors.
• Component-Based Software Engineering (CBSE) (W) tools, e.g. Microsoft OLE, *nix command shell pipes, etc. These technologies tend to suffer from critical limitations such as:
• Assuming the exclusive use of a particular programming language.
• Assuming the exclusive use of a particular operating system.
• Requiring debilitating amounts of bureaucracy to accomplish simple things.
• Forcing software components to be heavyweight (sometimes as heavyweight as a process.)
• Requiring communication between components to be done via a particular mechanism such as asynchronous message passing, command shell pipes, 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, and whatever meager adoption some of them do enjoy can usually be attributed to coercion rather than merit. For example, Microsoft's Object Linking and Embedding (OLE) is the only way to accomplish certain things under Windows, so people use it because they have to, not because they want to. Nobody does OLE if they can avoid it.

• C4 Model (W) -- Work in progress.
• Model-Driven Engineering (W) -- Work in progress.
• Low Code Development Platforms (W) -- Work in progress.
• Various infrastructure definition tools like Terraform (W) -- Work in progress.
• ArchiMate (W) -- Work in progress.
• TOGAF (W) -- Work in progress.
• SysML (W) -- Work in progress.
• Rapid Application Development (RAD) tools (W) -- Work in progress.
• Structure101 (->) -- Work in progress.
• Lattix (->) -- Work in progress.
• Structurizr DSL (->) -- Work in progress.
• Rational Software Architect Designer (->) -- Work in progress.

 

---

 

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"