Home

Elevator Case Study Wiki

So, what does an unambiguous, executable, and platform agnostic statement of a system's required behavior look like?

That's the objective of this case study.

The example system's purpose is to provide safe, comfortable, and efficient vertical transportation of people and cargo in 40+ story buildings.

This particular case is chosen so that any related instructional material can put the focus on the analysis and modeling without having to spend a lot of time explaining the system itself. Most of us interact with elevators in everyday life.

From concept to models

This case study begins with a natural language statement of system behavioral requirements.

On real projects, natural language requirements range from fuzzy concepts in the minds of stakeholders to massive databases of detailed, indexed, and cross-referenced statements.

But in all cases, even carefully regulated medical systems, such requirements are riddled with ambiguity, self-contradiction, incompleteness, inconsistent levels of detail, intrusive over-specification of the implementation, and so forth.

It doesn't take much modeling of the type I describe to expose these faults.

That said, writing down the requirements is an essential step, but as we'll see with our elevator requirements, we can be more relaxed with the natural language knowing that the models will nail down a solid unambiguous statement of the system.

The elevator models are executable

You can run the models and see how they behave without writing any programming language code. You can build, populate, debug, and run the models just like code but at a level of abstraction suited to the real world system, not any specific implementation. And here we will walk through an open source tool chain to execute the case study models.

The elevator models are platform independent

There are no assumptions about the computing hardware, operating system, programming language, programming paradigm, data architecture or anything specific to an implementation.

For example, a synchronization requirement like The doors may not open while the cabin is in motion is a behavioral requirement that must be implemented regardless of platform or design. Our models both specify this rule and can drive conformance tests across platforms and platform versions.

The modeling language

To pull off these two feats, we need a modeling language expressly designed for this purpose. Not a tool, not a graphical notation, or a standard (though these are important!) but a language.

We're using Shlaer-Mellor in our case study because it achieves our stated goals regardless of what tooling, notation, or standards you wrap around it.

The models are AI ready

All of the modeled content is defined as human readable text. We build our models using a simple text editor. From there we can use open source tools to generate a diagrams in a variety of notations. While indispensable for human evaluation, AI doesn't care about your diagrams.

Enough reading, see the wiki sidebar for the models!