3 Drafting the Andromeda application

We'll start working on the SCADA-like system mentioned earlier. Let’s call it “Andromeda Control Software.” This project aims to develop a spaceship control and simulation software that the engineers from Space Z Corporation can use in their work. It has many parts and components, all with its own requirements and desired properties. Describing the domain is an unavoidable step that I can’t skip in my narrative. This is what section 3.1 “Goals, requirements, and plans” is about. Section 3.2 will tell about designing the architecture of the application. It contains different diagrams to illustrate the process of reasoning. It’s almost the same as we could do it near a whiteboard when meeting our colleagues. Yet, if you want to code, section 3.3 “Naive implementations the Hardware subsystem” opens a door into the development world. It’s mostly Haskell, but many concepts will be useful to other languages such as F# and Scala.

3.1 Goals, requirements, and plans

We’re going to build an application. Where to start? What goals to pursue in the first place?

Let’s try to guess what parts Andromeda Control Software should contain. Database, networking, GUI, application, spaceship blueprints external DSL, multithreading, some low-level libraries to connect with hardware.

3.1.1 Minimum viable product

3.1.2 Andromeda software requirements

3.1.3 The Hardware subsystem

3.1.4 Logic control scripts

3.2 Designing the architecture

3.2.1 Defining architecture components

3.2.2 Defining modules, subsystems, and relations

3.2.3 Defining the application architecture

3.2.4 Modules organization

3.3 Naive implementations of the Hardware subsystem

3.3.1 The structure of the Hardware subsystem

3.3.2 Algebraic definition of HDL

3.3.3 Functional interface to the Hardware subsystem

3.4 Summary