Practical Software Analysis vs. Design Modelling

Writers often refer to software modelling in general terms, not distinguishing between analysis and design models. This may be ok for some purposes, since the two have a lot in common. However, there are also significant differences that need to be taken into account when studying collaboration, language engineering or tool design in software modelling.

Domain Specific Language

The language of analytical modelling is inherently domain specific.  Analysis means close communication with business domain stakeholders. Thus, the primary objective of a modelling language is to foster this collaboration, and so things like obeying standards becomes secondary. ‘This is UML conformant’ is not an argument in this context.

However, it is not necessary to reinvent the wheel in every software project. Basic language elements are almost always the same, like processes with steps and flow control, entities with relationships like whole-part or generalization, states with events and transitions or systems with components and interfaces. It is hard to say, therefore, whether stereotyping is sufficient or a DSL (based on foundational elements) is required.

Moreover, the business domain unfolds during the analysis process and so does the language. Thus, an analytical modelling language is not firstly defined and then secondly used. Rather, it develops step by step as the understanding of the business domain matures.

Formality and Fuzziness

A model is at the core of each analysis in software development. One has not really understood the subject until he/she is not able to build a model of the essential process, entity structures, system parts, etc.

However, although a model itself is a quite well-structured thing, the path of getting there is usually not. It involves taking notes of ideas or approaches in an unstructured way or the (temporary) use of other models that are outside the scope of the actual analysis. Modelling in software analysis can go all the way from napkin scribble to formal model. Where it starts is strongly dependent on the business domain, its maturity, its knowledge sources, etc.

Moreover, analysis models are about understanding. They are made for humans, and since human understanding is not a straightforward thing it might be highly beneficial to enrich the model with some non-formal or narrative elements, in order to be more concrete, to refer back to common terms, for a more presentable appearance, to guide the reader or to bypass shortcomings of the modelling language. Therefore, an analysis model, although clear and precise at the core, might become fuzzier towards the paring.

Heterogeneous User Group

The stakeholders in analysis comprise a broad circle, from very different departments, workplaces, responsibilities or levels of involvement in the project. This brings up the more technical issue of providing access to the model. The stakeholders read, verify, comment, edit and navigate the model via some modelling tool they have installed in their workplace, some lightweight or browser-based utility, some common intranet, or via documents extracted from the model and sent to them by email. Of course, all this needs to be done in a way that keeps the model consistent and modifiable, which is always a considerable challenge.

Views, Views, Views

Analysis in software development is basically about understanding, and the main key to understanding is seeing things from appropriate perspectives, i.e., creating views on the model. Views are more than just reductions of the model, views are reductions that make sense – in other words, abstractions. For example, simply picking some entities with their relations from an ER-model without giving further reasoning for the choice and drawing a diagram from it is just reduction (and contributes little to nothing to understanding). As opposed to providing a rule (query) that defines the choice of the diagram and thus conveys understanding.

analysis design modelMoreover, a view contains more than just a subset of the objects of a model.  It can affect its relations as well. For example, a model containing a class vessel with an attribute volume and a subclass bucket (by generalization relation), may appear in a diagram as just the bucket class with the attribute volume in it. Notice that here, the view refers to the semantics of the modelling language.

Last but not least, views create redundancy, which affects modifiability. However, handling this kind of redundancy by separating object from presentation is the core capability of modelling tools. So, this can easily be solved by tools, as long as they are capable of handling the other aspects (‘sense’, semantics) of views.

All of the above properties – domain dependence of language, structured/ unstructured mix, broad audience, and the importance of views – are surely beneficial in software design models, too, but surely do not have such a prominent role there as they have in analysis.

So long,

Dear language and tool designers – do you think you’re fit for software analysis modelling?


Posted in Requirements, Software_Engineering | Tagged , , , , , , , , , , , , , | Leave a comment

The Killer Application of Software Modelling

So, you have built a gorgeous model of your software requirements or architecture? Now what to do with it? Many people look for benefits by automating certain aspects of modelling, like checking or transformation. Although this is an intriguing area with huge potential, IMHO the real killer application of modelling lies in a completely different aspect. From my own experience as a business analyst (BA) in quite a number of IT projects I would say: the killer application of a model in software development is talking about it.

Now, “talking about it” sounds simple at first. However, have you ever tried to discuss your ideas with somebody who has a completely different underlying model of how to think of the situation? Quite often it goes like this: I say “” and two hours later, after an exhausting debate, we find out that “” are actually the same, just seen from a different angle. Sounds familiar? And even if our opinions really are contradictory, we still need a common ground if we are to compare them and argue about them. This is what a common underlying model can provide.

Nowadays, software projects are quite heterogeneously staffed, since, for example, there may be a need to scale up the number of people within a short period, special skills may be temporarily required or the project may be affected by a general reorganization. Thus, professionals with different roles, experiences and schools (of thinking) must find a common ground from which to discuss issues such as the business domain, applications of the technology and how to collaborate. This common ground can range talking modelsfrom attaching accepted and meaningful names to objects and relations in the business domain so that they can easily be referred to, through defining appropriate abstraction layers for discussing and deciding on technical architecture, to agreeing on basic notions, such as what is a requirement at all, where does the biz domain model end and the technical architecture start and what are the consequences for project roles and responsibilities. And it doesn’t matter what some book or standard says. In the end, the project itself should decide which concepts or approaches to adopt or to define.

Despite the fact that models of requirements, architectures or the software development process itself can be of great use, the way these models are actually used in software projects varies largely. It ranges from horror scenarios, like posterior documentation or ending up in some abandoned folder, to highly beneficial usages forming a basis for common understanding, debate and decisions, where people really “speak model”.

So, there’s a lot to find out, like:
1. One size doesn’t fit all: classifications of model users
2. Thinking about “talking about it”: classification of communication/ collaboration scenarios involving models
3. How can we tell good models from bad models (for communication purposes)?
4. How fit are current modelling languages for the above scenarios, and how could they be improved?
5. How can we make software development people really adopt a model-based collaboration?

So long,

Posted in Requirements, Software_Engineering | Tagged , , , , , , , , , , , , , | Leave a comment

A simple relational Model

Let’s recapture some modelling basics:

Some Dia

What does a diagram like (Some Dia) say, in terms of logic?

Relations a b c dLets call the “->” relation R, obviously there are two elements where one is R-related to the other, we express this with two variables x and y, as shown in figure (a), by
(1) x R y

Next, we want to assume that the diagram shows all R-relationships of its contained elements, and thus we must exclude cases like (b) by
(2) ¬yRx ∧ ¬xRx ∧ ¬yRy

Moreover, we want to express that we have at least two elements by
(3) x ≠ y

Finally we assume the diagram to cover the whole model, i.e. there are no other elements, by
(4) z x=z ∨ y=z

Thus, all together we get
(5) x, y (1) ∧ (2) ∧ (3) ∧ (4)

(5) describes (some Dia) structurally, i.e. up to isomorphism. Additionally, we could give the elements a material meaning, say a certain Person (x) drives (R) a certain Car (y). (see Unambiguous Models)

So long

Describing single structures is usually not enough in modelling. What we want is to model sets of structures like every Person drives at least one car.

Posted in Foundations (rigour), Software_Engineering | Tagged , , , , , , , , , , , , , , | Leave a comment

Categories of semantic Models by Stachowiak

In addition to former excerpts of Herbert Stachowiak’s 1973 book “Allgemeine Modelltheorie” (General Model Theory) here are some brief examples from the part on semiological (semological) classification of semantic models (chapter

Semantic vs non-semantic Models

Prior to the subsequent ordering, Stachowiak distinguishes semantic from graphical/technical models. Semantic models are models of perception and thinking expressed by combinations of conventionalized signs. Examples of graphical/ technical models are viewable and graspable models like photographs, diagrams, function graphs; globes, crash test dummies, lab rats etc.

Moreover, following the linguistic separation of expressions of emotions (emotional semantic models) and thoughts (cognitive semantic models) by A. Noreen, Stachowiak deals only with the latter considering the former not to be part of the theory at all.

Kinds of semantic Models

These cognitive semantic models can now be separated into the following categories, here represented by examples:

  • allocative e.g. “Hello, you!”
  • optative e.g. “Have a nice trip!”, “Wouldn’t it be nice …”
  • imperative (order) e.g. “Move over!”
  • interrogative (question) e.g. “What’s you name?”
  • narrative (statement)
    • pre-scientific declarative e.g. “You can get it if you really want”
    • poetical e.g. “The nightingale, the organ of delight”, “Ready to drink wine, with a cherry blossom”
    • metaphysical as biomorphic (e.g. creation of the earth as egg of a prehistoric bird), technomorphic (e.g. canopy (sky), “pushing up the daisies”) or sociomorphic (e.g. willpower as police of the soul)
    • scientific
      • formal (formal science): e.g. expressions in language of first order logic and mathematical structures satisfying them. [see any textbook on mathematical logic]
      • empirical-theoretical (empirical science): structure of real world objects satisfying formal axioms [basically, extraction of formulas from (probably very very difficult) word problems]
      • operative and prospective: empirical models with objects changing (esp. over time) [see any imperative programming language]

Notice that Stachowiak has described these categories in much greater detail, and this is just a first brief overview. The examples are translated very liberally.

So long

The category of empirical-theoretical models, elementary to all kinds of engineering, is covered in more detail in Stachowiak on semantic Requirements Modelling

More on Stachowiak: Herbert Stachowiak postings

Posted in Epistemology, Herbert Stachowiak, Requirements | Tagged , , , , , , , , , , , , , , , , | Leave a comment

Modeling & Abstraction at the very heart of Business Requirements Analysis

In between Business Engineers and IT Architects, how does a Business Analyst (BA) for requirements fit in? From industrial practice we know a BA definitely makes a lot of sense. So, now we try to conceptualise this extra benefit. As we’ll see, it’s mainly based on abstraction (and thus modeling).

Business and Technology perspectives

Say, your company performs the business tasks described in figure (BizTasks):

Biz Tasks. CEO vs Janitor.

If you asked the CEO what her company is doing here, she would say sth like “We send greetings and invoices”, where ‘send’ means write and ship it, since a CEO doesn’t care if it is performed in 1, 2, or more steps, she solely has the business perspective.

If you asked the janitor, or whoever may be responsible for the tasks’ infrastructure, he would say sth like “We write ‘stuff’ and ship it”. The essential difference for him is, that he has to provide the writers with, say, a typewriter and a pen, and the mail office with, say, envelopes, stamps and a mail box nearby, in other words he has the technology perspective.

So, now that we have the biz and tech views, what is the requirements analyst’s view on this? And, moreover, is an analyst just a bit biz and a bit IT person, or does an analyst’s view makes sense on its own?

How Abstraction makes the Business Analyst

Although the janitor’s view is determined by technology, it doesn’t contain any technology itself, i.e. it consists of biz concepts (completely understandable to the CEO) only. Such a view is pretty exactly that of a BA in software requirements analysis: providing the implementors with relevant information about the business, in a technology free way.
Thus, does the BA have to be a technology specialist, in order to state relevant requirements?

Not if the BA can use an abstraction that hides the technology details. Notice, that abstraction is more than just reduction. It also has a ‘practical aspect’ (Stachowiak), in plain words, the abstraction has to make some ‘sense’ in it self. This is why a BA is not just a half-and-half biz and IT semi-specialist. The abstracting nature of the BA’s perspective makes software requirements analysis a self-contained discipline.

Information System as the Abstraction of Choice

As practice shows the concept of Information System (IS) is a ‘quite good’ abstraction for software requirements. For our purposes, by an IS we mean a system of information flows among participants. Moreover we assume an IS to be analytic, not designed, i.e. extracted from the world (by abstraction), not constructed into it. There are various definitions of IS* that are more or less all come down to data, functions, and interfaces.

In other words, analysis of software requirements means describing the world in terms of data, functions, and interfaces. No need of technology knowledge – in theory, of course. In practice some tech and biz knowledge is required as well, however the core competency – in which the BA differs – is the capability of abstracting (and thus modelling) the IS from the business. Also notice, that this is far more than just the ability to ‘think analytically’ often found in BA job ads.

So, remember: If you do not abstract, it is not analysis.

So long

* textbook e.g.: Antoni Olive (2007) Conceptual Modeling of Information Systems.

For now, of course the open issue left, is a closer look on how an IS fits the above purpose.

Posted in Requirements, Software_Engineering | Tagged , , , , , , , , , , , | 1 Comment

Software Requirements Analysis: From the Art of Tidying Up to the Art of Abstraction

Requirements analysis is more than just tidying up, it’s about understanding the complexity of structures. An explanation inspired by the art of Ursus Wehrli:

Is Requirements Analysis just a kind of Tidying Up?

Recently I discussed with some project responsibles, the option to use an issue management system (namely JIRA) for gathering software requirements. The people obviously thought of requirements as a big set of snippets, that have to be collected and ordered, very much like a stamp collection. This seems to be a common misunderstanding of the nature of requirements, which can be elucidated nicely by the art of Ursus Wehli.

Ursus Wehrli is a Swiss comedian and artist, who makes books in which he “tidies up” works of art, for example, sorts the elements of a Kandinsky painting by colour and size, or orders the letters of an alphabet soup alphabetically. (more here: NYT)

Why Tidying Up is not enough

Let’s picture this little Wehrli-forgery here, a unjumbled version of a public transport map:

wehrli zürich tidyIt has lines (heavy for city trains, double for long distance), station names and station nodes. So, what is missing? What exactly makes the difference to a complete map? Obviously, it’s the relationships among the map elements that are missing here.

However, since the elements can still be classified and ordered, there must be some relationships left, determined by the elements’ properties. In this kind of representation they are made explicit, such that it becomes easy to ‘query’ e.g. if there is a station named ‘Opfikon’, or what line is the longest. Thus, simplification by ‘tidying up’ also has certain benefits.

Why Managing Relationships is not enough

wehrli zürich relationSo, why not simply add the relationships to the list, as in (Public Transport related)? It defines the relations name to station node, and station node to line, with station nodes identified by numbers 1 to 11.

So, technically all information would be available. However, for humans it’s still too hard to deal with. The relationships are now manageable by the system, but they are not yet expressed in a human-oriented notation. This is why an issue management system (IMS) is not enough to deal with requirements, even if it’s capable of managing relationships. An IMS’ focus is on sorting and grouping things, for example to make a todo-list of requirements, or to support the management of the analysis process.

And why even Visualisation is not enough

wehrli zürich transport mapFor the typical use of a public transport map, a diagram as (Public Transport) is certainly appropriate, i.e. the human understandability can be accomplished simply by choosing an appropriate notation. And even if the lines and stations become just more, we simply can increase the size of the map. However, if the structure gets more complex, i.e. the elements are ‘closer’ related, diagrams quickly become hard to understand. Visualisation scales well concerning size, but not concerning complexity.

Visualisation of relationships is usually what modelling tools are good at. However, as we have seen the tidy perspective has its advantages, too. Thus, beyond visualising the modelling results (i.e. diagrams), modelling tools should provide ‘tidy’ perspectives (like an IMS), in order support the modelling process. In other words, working out models is more than just documenting them.

Abstraction for Analysis

wehrli zürich airportIf things get more complex – just think of a map with a more complex system of stations and lines (trams, etc) – it might become beneficial to create views on the model, e.g. all available lines from the airport, as in figure (Airport Transport), with connecting lines indicated at each station. Similarly, think of a requirements model of a whole software application, decomposed into data, use-case, state, etc. views/ diagrams. This goes beyond visualisation, this is about abstraction. Thus, as compared to the ‘art of tidying up’, choosing appropriate views on a model, in order to understand its complexity, constitutes the ‘art of abstraction’ (so to say).

By the way, this is also what distinguishes modelling from simple drawing tools. (Just in case, the next project wants to do requirements analysis with VISIO)

So long

Notice that additionally to the relations in (Public Transport related) the diagram (Public Transport) contains the coordinates of the stations. Although, they are only schematic, they provide an approximate geographical location information.
Ursus Wehrli

Posted in Requirements, Software_Engineering | Tagged , , , , , , , , , , , , , , , | Leave a comment

Modelling with Classes: Square and Rectangle revisited

Classic problem in class-modelling: how to express that a square is a special kind of rectangle?  Practically the best approach is in general to refrain from subclassing and add a boolean method isSquare() to the rectangle class instead.

In order to deepen understanding, let us scrutinize the situation a bit closer here, using logical/ structural foundations of modelling:  Undoubtedly, Square is a subclass of Rectangle, since all squares constitute a proper subset of all rectangles. This could be simply describes as:

(R1) Rectangle: real a, real b, {a>0}, {b>0}
(S1) Square: real a, {a>0}
A method area() would look like: a * b in Rectangle and a² in Square.

However, additionally we have the challenge of inheritance, that is, we want to obtain the description of Square by just extending the description of Rectangle. This is not satisfied by the solution above, since Square drops the b. Notice, that we talk about just the description of the classes here. Their extensions (rectangles and squares) remain unaffected. Of course, one could specify it like this:

(S2) Square: real a, real b, {a>0}, {a=b}
But here b is redundant and e.g. area() could be a * b or a² arbitrarily.

Thus, for a subclass Square we can choose to drop inheritance or accept redundancy. Now, inheritance is a very desirable feature.  For example, it allows the area() method of (S2) to remain unchanged in the Square class.  Just imagine, how confusing developing would become, when subclasses exhibit methods of superclasses differently structured or named.

This is why it’s recommendable to accept redundancy for the benefits of inheritance here. To implement this either by a subclass Square, as in (S2), or inside the Rectangle class, as with an isSquare() method, is left to practical considerations.

So long

Posted in Software_Engineering | Tagged , , , , , , , , , , , , , , , | Leave a comment

Reflections on Abstractions: Roaming the Subsumption Continuum

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by basic concepts of graph theory.

In the recent post we defined 4 cases of subsumption. In order to get from these basic cases to real world situations, we see the 4 cases as the corners of a ‘continuum’ A, B, C, D, and thus we get figure (subsumption continuum).

continuum of subsumption

Here the following areas – well known from graph theory – can be identified:

CC Connected Component

A connected component is a subgraph in which any two vertices are connected to each other by paths, and which is connected to no additional vertices in the supergraph.* This is what we get when we reduce the density of A, i.e. components become less obvious to abstract/model just by their internal composition alone.

CY Connectivity

The connectivity asks for the minimum number of elements (nodes or edges) which need to be removed to disconnect the remaining nodes from each other. A higher degree of connectivity is what we get when we increase the strength of A, i.e. components become less obvious to abstract/model just by their external relationships alone.

MO Module

In a module all members have the same set of neighbors among nodes not in the module. This is what we get when we add edges to C, i.e. the abstraction/model of the class structure becomes a multi-level tree.

CL Concept Lattice

All formal concepts of a bi-partite graph constitute a lattice. This is what we get when we reduce edges from C, i.e. the abstraction/model of the class structure becomes a multi-level lattice.

EX Expander

An expander is a sparse graph that has strong connectivity properties. It is ‘quite’ hard to decompose by subsumption into classes or components. For this reason expanders are used to design robust IT networks etc.

Finally, we get E by reducing the edges in A and C and then joining them to a ‘cube’ that can not reasonably be structured by classes or components.

Thus …

we can take parts of graph theory for describing typical problem situations of abstraction. However, most of these parts of graph theory* do not address the issues of the actual abstracting mapping from original to model, as required for ‘modelling for the purpose of understanding’. This is what a theory of modelling should be about.

So long

* apart from formal concept analysis

Posted in Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , | Leave a comment

Craftsman or Engineer?

A brief word on a practical software engineering issue:

A lot has been written on the differences between Craftsman and Engineer.  Recently I came across a simple example by Hofstadter & Sander, that nicely shows the basic difference in thinking. We start with a little exercise:

“Draw a square, a rectangle, a rhombus, and a parallelogram.”

Some people draw a solution as in (a), some draw solution (b).  Both are perfectly acceptable in their way:
shapes abstraction

  • With (a) you show your detail knowledge, of how the shapes are defined, s.t. you are able to give a typical example for each class.
  • With (b) you show your ability to abstract, of how the shapes are related to each other, s.t. you are able to give a special case valid for all conditions.

shapes concept lattice and context

The latter is an abstraction by constructing formal concepts, i.e. by deriving the concept (lattice) from the (context). Imho, being able to ‘navigate’ the concept lattice – that of course looks much more complex for real world subject areas – is what separates the thinking of Engineer and Craftsman.

So long

For example, from my personal experience in business analysis I may say, that typically there are lots of people on the expert side with type (a) knowledge, so what they need an analyst (on engineer-level) for, is help them to create type (b) understanding from it.

Posted in Abstract Thinking, Software_Engineering | Tagged , , , , , , , , , , , , , , , , , , | 4 Comments

Reflections on Abstractions: Subsumption I

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by the means of basic relational mathematics.

We’re going to look at a subsuming mapping from lhs original to rhs model. When we assume subsumption, i.e. non-lhs-uniqueness, a single rhs node in model ‘contains’ , i.e. is mapped from, 1..n nodes of original.

Two model nodes with no edge

subsumption 2 nodes 0 edgeNext, as in figure (no edge), we look at two rhs nodes a and b with no (rhs) edge amongst them. From no edge on the rhs we can derive that not all lhs nodes in node a have a (lhs) edge with all lhs nodes in b, else we would need a negation in the mapping rule to map from all-to-all edges on lhs to no edge on rhs. Among the remaining mapping options, the rule ‘no lhs edge iff no rhs edge’ is the strictest (the ‘opposite’ of all-to-all, so to say).

Moreover, in this case no edge among the lhs nodes of a and b would make no sense, since the abstraction could not be justified by the structure of the graph. Thus, the nodes of a and b must be connected amongst themselves. Again, we take the strictest case of all-to-all connection as in figure (no edge).

Two model nodes with one edge

subsumption 2 nodes 1 edgeNext, as in figure (one edge), we look at two rhs nodes a and b with one (rhs) edge amongst them. From one edge on the rhs we can derive that one lhs nodes in node a has a (lhs) edge with one lhs node in b, else we would need a negation in the mapping rule to map from no edges at all on lhs to one edge on rhs. Among the remaining mapping options, the rule ‘all-to-all lhs edges iff one rhs edge’ is the strictest  (the ‘opposite’ of no edge at all, so to say) .

Moreover, in this case all-to-all edges among the lhs nodes of a and b would make no sense, since the abstraction could not be justified by the structure of the graph. Thus, the nodes of a and b must not be connected completely amongst themselves. Again, we take the strictest case of no edge at all connection as in figure (one edge).


abstraction subsumption

… we get four cases of subsumption as in figure (strictest cases), which next can be developed into a continuum with the four cases as corner points.

So long

Or in terms of adjacency matrices:

4 cases abstraction by subsumption adjacency

Posted in Reflections on Abstractions | Tagged , , , , , , , , , , , , | 1 Comment

Reflections on Abstractions: Subsumptions and Omissions

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently we provide a simple visualisation of some basic concepts.

In addition to the recent posting Abstractive and Functional Mappings we provide a simple visualisation.  There we defined abstraction by subsumption as a not lhs*-unique mapping, and abstraction by omission as a not lhs-total mapping. This, and the combination of both to an ‘omsumption’ (excuse the word), is illustrated below.

abstraction subsumption omission

So long

* lhs = left hand side

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , | 1 Comment

Reflections on Abstractions: The Use Case trade-off

Loosely collecting examples of abstractions on finite relational structures:

Relational World

relational abstractionIn the posting Adjacent Rooms we had an abstraction as in figure (abstraction by ‘is related’), a mapping with the structural unsatisfactory property to be non-unique on the model-side, e.g. the ‘2’ in the original is mapped to 2 different nodes in the model. However, we also saw an example where this sort of abstraction fits quite well, and thus speaks in favour of the relevance of this kind of abstractional mapping.

Real World

request processinguse cases request processingAnother such example is the abstraction of functionality by Use Cases. Figure (Request Processing) shows a simple process for handling customer requests, that can be of various kinds, like placing an order, a request for product information, or a change of the billing address. Think of the activities as nodes of a graph as above.

Now, the basic idea of a Use Case is to lump together activities such that they form an emergent behaviour (easy to comprehend). In figure (Use Cases) we have three of these. Obviously the Use Cases are overlapping, since e.g. the ‘Dispatch request’ activity is contained in all Use Cases, as well as ‘Send reply’ appears in ‘Update Static data’ as well as in ‘Request Information’ (indicated by the edges among the Use Cases). Thus we get better understandable (emergent) units of functionality, however usually for the price of a non-unique mapping.

Based on the elementary terms of relational structures, this shows the basic trade-off of Use Cases: emergence vs redundancy.


  1. The ‘extend’ or ‘include’ relationship in UML are typical elements to address this redundancy issue.
  2. Compare the kind of knowledge gained out of such a formal analysis as above to that you get from common text books on Use Cases. Moreover, seems that some very popular books, don’t address this trade-off at all (!?)

So long

Posted in Mathematics, Reflections on Abstractions, Requirements, Software_Engineering | Tagged , , , , , , , , , , , , , , , | 1 Comment

Reflections on Abstractions: Adjacent Rooms

Loosely collecting examples of abstractions on finite relational structures:

Relational World

Relational abstractionFigure (abstraction by ‘is related’) shows an abstraction by subsuming directly connected nodes in the original into a single node in the model. An edge in the model indicates a common element of its nodes in the original. For example, the nodes 1, 2 become a single node (1, 2) that is related to e.g. node (2, 3) since they have the element 2 in common.

Real World

rooms wallsA practical case of such an abstraction is a structure of walls that is abstracted to rooms with the neighborhood relation, where neighborhood is defined by having a wall in common, as in figure (wall in common). For example, the bath (Ba) has walls in common with the bed room (BR) and the foyer (F).


  1. The abstraction takes into account only the relationships of the nodes. No further properties are considered.
  2. The abstraction is total on the original-side and not unique on the model-side.
  3. The model has more nodes than the original. Is this a contradiction to the reduction property of abstraction? I Don’t think so, since a reduction exists from two connected nodes to a single node. Other opinions?

So long

for an informal definition of reduction in the context of models, see Stachowiak

Posted in Abstract Thinking, Reflections on Abstractions | Tagged , , , , , , , , , , , | 6 Comments

Examples of Preterition and Abundance in Modelling

In addition to the earlier posting Stachowiak on Preterition and Abundance in Modelling here are some examples of Preterition and Abundance (also see here for all postings on Stachowiak):

Stachowiak Abundance Preterition Black WhiteIs this a black and white picture? Is this a colour image of a black/ white arrangement or a black/ white image of a coloured arrangement?  In the latter case, even if you want not to express the colour of the Original at all, you have to choose some colour for the image (here, the scale from black to white).

Stachowiak Abduction Use CaseWho triggers the Use Case? In UML the association between actor and use case is not allowed to have a direction. Thus, in order to express that an actor triggers the use case it are sometimes notated on the left hand side. So, the diagram could say that the customer triggers the use case or not. We cannot say, without any further information.

Stachowiak Maza LabyrinthWhat does the graph tell about the maze? The graph inside the maze preserves coordinates and path length. Also in the graph on the right nodes have coordinates and edges have lengths. However, they are not meaningful anymore. They were ‘sacrificed’ for the sake of a certain view.*

Notice that a lot of further questions apply in the graph on the right: does the top element represent the starting point? Is 1-2-4-6-8 a kind of primary path (typical issue in process models)? Is it better to have all edges of equal length, to indicate the abundance?

So far, just a few examples that came to my mind.

*Stachowiak gives a similar example in his book “Allgemeine Modelltheorie”. The book at Google books.

Posted in Epistemology, Herbert Stachowiak, Software_Engineering | Tagged , , , , , , , , , , , , , , , , , , | 5 Comments

Reflections on Abstractions in Relational Structures. The very basic Setting.

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by the means of basic Graph Theory and Formal Concept Analysis.

A single unary relation R(x), can simply classify e.g. Naturals in evens and odds. This doesn’t take us very far.  So, they should be enhanced by either adding more unary relations or making the relation 2-ary, 3-ary etc.  Moreover, both can be combined to multiple n-ary relations. However, here we stick with the basic two cases, and adjourn the combined case until ‘later’.

fca-lattice-even-oddMultiple unary relations R(x), S(x), …, can describe complex property structures.  In the theory of Formal Concept Analysis, this is said to be a Context.  Now in order to handle the complexity of such structures by Abstraction, the concept of a Formal Concept proves very helpful.  All Formal Concepts of a structure provide a lattice, which helps us ‘understanding’ the structure.  Thus, in abstractional terms, Classification (by Formal Concepts) implies Generalisation (Concept Lattice). in detail…

graph-mod-cmpA single n-ary relation R(x, y, …), shows how the elements are related to each other.  Graph Theory provides two basic concepts here that describe Abstraction:  A Module (corresponding to the abstractional concept of Classification) lumps together all the nodes, that have the same edges to other nodes, i.e. appear the same to the outside, so to say.  A Component (corresponding to the abstractional concept of Aggregation) groups the nodes, closely connected to each other and loosely connected to the outside, roughly speaking.
Moreover, both, Modules and Components, can be sorted hierarchically, in order to simplify the ‘understanding’ of the structure.  Intuitively, I would call this Generalisation in the case of Modules.  However, for Components, the term ‘composition’ sounds more natural to me. in detail…

It is hoped, that this can provide a very basic setting for a deeper analysis of the nature of Abstraction.  Some questions arise immediately, like ‘how do formal concepts and modules fit together?’ (i.o.w. how can they be generalised?) or ‘what makes modules and components the outstanding concepts for abstraction?’ (i.o.w. what properties define the formal concept of ‘module and component’ in the context of abstraction?) etc.

So long

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , , , | 2 Comments

Reflections on Abstractions: Correctness and Completeness

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently, in strive for rigour, an earlier post on quality properties of models is compared to basic concepts of mathematical logic.

1. Correct and Complete, simply put

cc-custsysThe former post, gave a brief explanation what correct, complete, etc. means for models, as in the figure.  Where correct meant, no requirement in the model is wrong and thus every solution accepted by the customer (in C) is in accord with the model (in M) and complete is, no requirement in the model is missing and thus every solution according to the model (in M) is also accepted by the customer (in C).

2. The concept of a Formal System

In mathematical logic a formal system (FS) is a triple of a language syntax, a set of axioms and a resolution mechanism, for example, the syntax of first order logic, the axioms of the theory of equivalence relations, and the |- resolution operator, such that theorems can be derived from the axioms.

A structure that obeys such a FS is said to be a model. For example, for my red and white socks, being of equal colour defines an equivalence-relation.

A FS has at least one model if, and only if, it is consistent, i.e. the axioms are not self-contradicting, and thus can be fulfilled.

So, consistency assumed, the axioms define a set of models A, as well as any theorem defines a set of models T, and thus proving a theorem (by the resolution operator) comes down to show that the models of the axioms A are a subset of the models of the theorem T.

3. Correct and Complete, formally put

Now the above situation in a FS seems quite similar to that of a ‘customer system’: instead of written down axioms in some language, we have requirements, ‘hidden inside the head’ of the customer, that we have to explore by stating requirements (theorems). Instead of a resolution mechanism we have the customer itself, as a kind of oracle that answers our questions.

Thus, when a requirement is accepted by the customer it defines a superset of the accepted solutions (models), and hence is said to be correct. Correspondingly, if the requirements altogether define a subset of the accepted solutions (models), they are said to be complete. Thus, correct and complete, ensures that the stated and the accepted solutions are congruent (consistency assumed).

So long

Concerning ambiguity: if there is at most one model for the axioms in the FS, then together with consistency (at least one model), the model is said to be unique up to isomporphy (because maths is a structural science).

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , , , , , , , , | Leave a comment

Reflections on Abstractions: Cases vs Models

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by the means of basic Finite Model Theory.

All finite relational structures can uniquely be described in First Order Logic (FO) up to isomorphy. This is quite pleasant, since FO is a relatively nice and simple language (for expressing queries, doing proofs, etc). For example, a structure consisting of a 2-elementary alphabet and a binary relation R (see figure) can be characterised by conjunction of the following sentences:
(1) there are exactly 2 elements
(2) for x≠y: R(x,x), R(y,y) holds, R(x,y), R(y,x) doesn’t
where both sentences can be expressed in FO (see here for formalism).

However, another way to characterise R is:
(1) as above
(2′) R is reflexive and empty else ( x=y ⇔ R(x,y) )
what is also expressible in FO.

Between the two axiom systems (I) and (II) there is an essential difference: While (I) lists all existing cases in (2), (II) uses the property of reflexivity (2′) to characterise the structure. The latter has certain advantages: it, can be expanded easily for structures of more than 2 elements, and it states a principle that can be understood by humans.

This describes by simple means of basic Finite Model Theory a very important principle in software engineering: modelling properties is more expressive than just collecting cases. This is the reason why test cases can be derived from specifications but not vice versa. Another example is Intentional Programming, addressing that the big picture ‘gets lost’ on the source code level.

Like most things in life, expressing properties by models also comes with a downside: While cases as in (I) can always be expressed in FO, properties in general cannot. For example, for expressing that the alphabet of a structure is always of even size, FO is not expressive enough.

Thus, altogether cases vs models is always a trade-off.

So long

PS for the ‘light’ version, see previous post

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , , | Leave a comment

Reflections on Abstractions: Generalisation and Aggregation

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by the means of basic Graph Theory.

reflections on abstractionsA Component in Graph Theory is a connected subgraph ‘disconnected’ to the outside. For example, directed graph (1) consists of 3 components. This concept is basic but not very useful, since it does not allow connections among the components. For this reason, we are going to allow such connections and thus also need to generalise the notion of component, what can be done in (at least) two ways:

  • Generalisation: lump together all nodes that have the same edges to the outside, as in (2) (called “Module” in graph theory).
  • Aggregation: lump the nodes closely related, and losely related to the outside as in (3) (based on graph theoretical “Connectivity“).

By very simple means this provides the notion of two different kinds of abstraction: generalisational and aggregational. Whereat in aggregations all elements together make the interface (edges to/from the outside), in contrast to generalisation where one could pick any of the inside nodes to represent the interface.

Notice, as the above shows, aggregational abstraction is >not< a specialisation of generalisational abstraction, thus the existence of aggregational abstraction contradics the widespread understanding of abstraction as equivalent to generalisation.

So long

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , | 5 Comments

General Model Theory by Stachowiak

In his 1973 book “Allgemeine Modelltheorie” (General Model Theory) Herbert Stachowiak describes the fundamental properties that make a Model.  Unfortunately this is still only available in german language, so I thought why not try a translation of the essential bits:

Fundamental Model Properties

  1. Mapping: Models are always models of something, i.e. mappings from, representations of natural or artificial originals, that can be models themselves.
  2. Reduction: Models in general capture not all attributes of the original represented by them, but rather only those seeming relevant to their model creators and/ or model users.
  3. Pragmatism: Models are not uniquely assigned to their originals per se. They fulfill their replacement function a) for particular – cognitive and/ or acting, model using subjects, b) within particular time intervals and c) restricted to particular mental or actual operations.


  1. Mapping: Such originals can evolve in a natural way, be produced technically or can be given somehow else. They can belong to the areas of symbols, the world of ideas and terms, or the physical world. […] Actually, every entity, that can be experienced (more general: ‘built’) by a natural or mechanical cognitive subject, can in this sense be considered an original of one or many models. Originals and models are interpreted here solely as attribute classes [representable by predicate classes], that often achieve the shape of attributive systems [interrelated attributes that constitute a uniform orderly whole]. The concept of mapping coincides with the concept of assigning model attributes to original attributes in the sense of a mathematical (set theoretical, algebraic) mapping.
  2. Reduction: To know once that not all attributes of the original are covered by the corresponding model, as well as which attributes of the original are covered by the model, requires the knowledge of all attributes of the original as well as of the model. This knowledge is present especially in those who created the original as well as the model , i.e. produced it mentally, graphically, technically, linguistically, etc in a reproducible way. Only then an attribute class is determined the way intended by the creator/ user of the original and the model. Here, an attribute class is an aggregation of attributes of the original as well as of the model side, out of the overall unique attribute repertoire. Thus, the original-model comparison is uniquely realisable. […]
  3. Pragmatism: Beyond mapping and reduction the general notion of model needs to be relativised in three ways. Models are not only models of something. They are also models for someone, a human or an artificial model user. At this, they fulfil their function over time, within a time interval. Finally, they are models for a certain purpose. Alternatively this could be expressed as: a pragmatic complete determination of the notion of model has not only to consider the question ‘what of‘ something is a model, but also ‘whom for‘, when, and ‘what for‘ it is a model, wrt. its specific function. […]
  • Stachowiak, Herbert (1973) (in german (DE)). Allgemeine Modelltheorie [General Model Theory]. Springer. ISBN 3-211-81106-0.

Have fun

Part II: Stachowiak’s K-System of Modelling

Posted in Epistemology, Herbert Stachowiak | Tagged , , , , , , , , , , , , , , | 22 Comments

Lecture Notes on Model Thinking I

Some lecture notes/ scribble on Model Thinking by Scott E. Page. Lecture Intro, Part 2: “Intelligent Citizens of the World”:

“George Box: ‘essentially all models are wrong, but some are useful'”

|=: Agree! Just a little everyday-obervation: it’s funny how often people use right/ wrong in the context of abstraction (i.e. models), not realising, without being ‘wrong’ (i.e. loosing details) it would not be a model. Such discussions usually start sth like this:
2 Rects
A:‘These are two rectangles!’ B:‘No, no, these are two essentially different things!’ … (sounds familiar?)

Have fun

Are you a hedgehog or a fox?: Try the quiz on Overcoming Bias
and this is Philip E. Tetlock: Wikipedia

Posted in Abstract Thinking, Model Thinking | Tagged , , , , , , , , , , , , | 17 Comments

Human centric Modelling

Some thoughts on Vincent Hanniet’s Agile & Modeling new way of life! :

If you ask people what concepts come to their mind when they think of modelling in software engineering, you usually hear things like “UML”, “Model Driven …”, “Autosar”, etc. Now these are big comprehensive topics, that one cannot handle without having spent some time getting into them.

In contrast, to me, modelling is a way of thinking, based on abstraction, a quite natural skill, and thus is also a quite natural thing to do for every human being, like when you’re abstracting the shape of the screen you’re just looking at as rectangular or using the word “screen” as a concept.

I do not say that seeing modelling one way is better than the other. Both are good to have. I see it like this: There is a modelling at the low-end, that all humans use every day a million times, and there is modelling at the high-end with comprehensive concepts like UML, MDD etc. Perhaps approaching the modelling topic from the low-end would make it easier accessible for most software practitioners.

Have fun

Compared to what has been published on UML, MDD etc, we still know very little about practical abstractional thinking in models, don’t we?

Posted in Model Thinking | Tagged , , , , , , , , , , , , , | 5 Comments

Are your Requirements complete?

No Analyst will ever can tell if the requirements are complete, however at least completeness can be approached by systematic analysis. The idea goes roughly like this:

Say you should tell all the Integers between 0 and 11, how would you approach that?
Bad way: “6, 3, 2, 1, 8, 6, 5 – so, that’s it or did I miss one?”
Good way: “1, 2, 3, 4, 5, 6, 7, 8, 9, 10 – bingo!” – for example.

Obviously the point is, to obtain an understanding the structure of the domain. Else it is just collecting facts. Finding appropriate systematics, I’d see mainly in the responsibility of the analyst.
Bad way: “Tell me all the integers between 0 and 11.”
Good way: “What’s the next integer after 0?” etc – for example.

To me this is already a basic application of modeling and its benefits.

Posted in Epistemology, Software_Engineering | Tagged , , , , , , , , , , , | 3 Comments

Why finiteness counts

Becoming aware of Finite Model Theory. Part 1 of n.

You arrive at a hotel, looking for a room. Unfortunately all rooms are occupied. Fortunately the hotel has countably infinite many rooms. So they move the guest of room 1 to room 2, guest of room 2 to room 3 etc so you can check in to room 1. (better don´t unpack your suitcase, in case the next guest arrives)

So compared to the real world the hotel doesn’t have to manage the occupation of its rooms, therefore it has to handle infinity, i.e. if one wants to deal with the above on a scientific level, one must be able to capture the concept of infinity formally.

Finite hotels (as well as ‘finite scientists’) don’t have to care about infinity; therefore they have to deal with the complexity of managing occupation. This can be done by keeping track of the number of empty rooms or by looking up all rooms for an empty one each time a guest arrives. The first approach is space consuming (since they have to write down the number empty rooms somewhere (i.e. space can be a piece of paper)). Instead the second approach requires time to go and check the rooms.

Thus there are two mutually exclusive things that can make occupation management interesting: infinity with all its ‘strange’ effects and the complexity (effort) of keeping track of ‘what’s going on’.

Or how Neil Immerman puts it: “In the history of mathematical logic most interest has concentrated on infinite structures….Yet, the objects computers have and hold are always finite. To study computation we need a theory of finite structures.”

Posted in Mathematics | Tagged , , , , , , , , , , , , , , , | 11 Comments

Software for Managing Chaos

The Cynefin framework enables us to talk about the complexity of knowledge and decision-making contexts in general. These are a few thoughts on applying Cynefin to software development, here in the so-called ‘Chaos’ context.

Managing ‘Chaos’

David Snowden and Mary Boone give the following example of managing chaos:

In January 1993, a gunman murdered seven people in a fast-food restaurant in Palatine, a suburb of Chicago. In his dual roles as an administrative executive and spokesperson for the police department, Deputy Chief Walter Gasior suddenly had to cope with several different situations at once. He had to deal with the grieving families and a frightened community, help direct the operations of an extremely busy police department, and take questions from the media, which inundated the town with reporters and fi lm crews. “There would literally be four people coming at me with logistics and media issues all at once,” he recalls. “And in the midst of all this, we still had a department that had to keep running on a routine basis.”

– D. J.Snowden, M. E. Boone, ‘A Leader’s Framework for Decision Making’, (Harvard Business Review, 2007) –

How could Deputy Chief Walter Gasior be supported? Perhaps, for example, by a press conference training? However, in general it is not very likely that a Deputy Chief of a Chicago suburb has to give important press conferences. So, a training beforehand would very likely never pay-off, and a just-in-time training would be unrealistic in this context.

Nevertheless, other things could prove useful in general as well as in particular. For example, a solid communication infrastructure, a spacious room for general purposes, that can be used for large press conferences in particular, etc.

Software for Managing ‘Chaos’

In terms of software this means that in situations like the above, general purpose software like e-mail, a decent word processor or spreadsheet are more appropriate than e.g., software that most efficiently supports a certain business process. But, how relevant are situations like the above to business software development? Isn’t it mainly about implementing well-structured business processes?

Example: BPM and ACM

For example, business process management (BPM) software consists primarily of elements to describe process activities, branch or join the flow, etc. This is very often sufficient for supporting 90% of the daily work of say, a back-office customer relationship process, where workers deal with customer requests, orders, static data, etc. Beyond these tasks, the remaining 10% of the daily work is more similar to Chief Gasior’s situation, where specific software support would be inefficient. This is where Adaptive Case Management (ACM) comes in. ACM is the complementary approach to BPM, i.e., it is NOT the more and more specific implementation of less and less often occurring processes. In contrast, it provides generic infrastructure for handling the remaining 10%, like communication and self management utilities.


In more general terms, when implementing information systems we go from functionality that is highly efficient to implement (large value, small effort), downwards till we reach a certain barrier of inefficiency. What we can do about the remaining functionality is to provide some general purpose functionality that supports generic user activities, like communication, or self-management. Notice, that this approach is significantly different from trying to implement the remaining specific functionality in a cheaper way.

So long

More on Cynefin here

Posted in Software_Engineering | Tagged , , , , , , , , , , , , , , , , , , | Leave a comment

1 + x = 3 as a Query

Just a brief recap of some software engineering fundamentals:

FOL Query

What is

(1) 1 + x = 3, with x ∈ N

from a software engineering perspective? Can it be considered a requirement? No, because it’s not a sentence and thus cannot be evaluated to true/ false.
Can it be considered a query? Yes, since it defines a result set on N, that is {(2)}.
This result set contains a single 1-ary tuple. Other cases are:
1 + x <= 3, {(1), (2)}
3 + x = 1, {}
1 + 2 = 3, {()}
3 + 2 = 1, {}

Here "()" is said to be a tuple with arity 0. For example, a 2-tuple (1, 2) can be defined by a set {{1}, {1, 2}}. Thus a 1-tuple (1) is {{1}}, and a 0-tuple () is {}. Thus, {()} and {} correspond to truth values true and false.

SQL Query

An SQL version would go like this: we define a table “+” (cols y, x, z) that contains all possible results (y+x=z) (what would make it actually infinite, but nerver mind), that we can query by

(2) select x from + where y = 1 and z = 3;

or alternatively for a table N of all naturals (col n) and a query language containing a + operator:

(3) select n from N where 1 + n = 3;

Boolean Query

Back to First Order Logic. Also the following equation can be considered a query of 0-ary tuples, a so called boolean query:

(4) ∃x 1 + x = 3

Notice, this could also be seen as a requirement, since it evaluates to true/ false. So could “1+2=3”. However, requirements are usually about sets not about single instances, i.e. Boy loves Girl, not Willy loves Kate. So, “1+2=3” would correspond more to a test case.

So long

Posted in Epistemology | Tagged , , , , , , , , , , , , , , , | Leave a comment

Unambiguous Requirements Models

We’ll see that the concept of ambiguity of (requirements in software engineering) models comprises structural as well as material aspects, on all model levels (top to bottom).

Unambiguous is a core quality characteristic of software requirements specs (SRS). For example, IEEE 830 defines:

“An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation.”

Apart from linguistic confusions, like the escalator sign “Dogs must be carried” etc, even in a clearly stated requirement there can be numerous ways of interpretation.

Unambiguous in Higher Level Models

For example, in “Every Employee works for at least one Company” the unary predicate Employee(x) can be interpreted in various ways, and thus needs to be defined. Picturing this as part of an entity-level model (e.g. ER model) such a definition can be given by an informal (material) description in natural language, as for example: “A person that works part-time or full-time under a contract of employment.”. Since this kind of definition is the best one can do on the entity level, the model (pictured only on this level) can be practically considered unambiguous.

Unambiguous in Bottom Level Models

Subsequently, during the process of specification the predicate will usually be specified on a deeper level. In the above case attributes can be attached to the entity Employee, like “First name”, “Last name”, “Social security number” (SSN), etc, with a formally defined data type each, like char(7) for SSN, perhaps even with some further restrictions in a formal language like “^[A-Z]{3}[0-9]{4}$” (3 letters and 4 digits). Thus, by rigid typing on the bottom level the attribute be can structurally (up to isomorphism) defined.


Does that mean one can do away with all material descriptions of SSN like “A SSN is …”, the descriptive name “Social security number” itself (and replace it by “X”), and consequently with the entity-level description (“A person that …”) as well? In other words, would one consider a solely structural definition of SSN as unambiguous? Certainly not! Thus, unambiguity consists of a structural and material part. This connects it with, but also sets it apart from correctness, completeness, and consistency.

So long

The structural unambiguous specification on the bottom level is one important aspect that distinguishes software engineering from physical engineering disciplines.

Posted in Requirements, Software_Engineering | Tagged , , , , , , , , , , | 1 Comment

Stachowiak on semantic Requirements Modelling

In addition to former excerpts of Herbert Stachowiak’s 1973 book “Allgemeine Modelltheorie” (General Model Theory) here is a part on empirical-theoretical models wrt. empirical science (chapter part 1 (formal semantic approach)).

Although I’m a software requirements analyst and not an empirical scientist, this describes pretty close the very basics of my kind of modelling.

First he recapitulates the formal (scientific) models (iow: basic maths) from an earlier chapter:

Starting point of the subsequently following considerations is the concept of the formal-scientific evaluation model in the closer sense, as introduced in the last chapter. It was said to be a (concrete or abstract) relational structure (M, a), that satisfies a given (sound) axiom system Σ. Latter consists of conditions in formal language, equipped with variables (argument places). The relational structure was a (n + 1)-tuple (M; Ru …, Rn), defined on a domain set M and n relations defined on M, satisfying the condition system Σ. With Σ also the theory induced by Σ (in addition of deduction rules) holds, since the satisfying Σ-evaluation entails a satisfying T(Σ) evaluation.

Such formal models can be applied to turn data (more or less well) into understanding of the world by abstraction:

These characterisations and in particular the differentiation between a theory and its possible satisfying evaluations are transferable to certain empirical scientific subject areas. Therefore, such a subject area has to be either available in a completely axiomatised way or its axiomatisation has to be progressed so far that linguistic description models and their associated allocation models can be sensibly distinguished. In other words, the conceptual apparatus of mathematical structural theory and the logical-semantic model theory can be applied to empirical scientific modelling in such cases. Here, the formal linguistic axiomatic constraint system Σ is abstracted from empirical data (with actually a broad subjective variety in the theory construction process) or it is at least constructed wrt. empirical data. This is due to the systematic summarising, explaining and prediction-enabling description of parts of the empirically accessible world it provides, especially the space-timewise-energetic entity and event world.

And here is how to do it, namely by interpreting the formal domain and relations by empirical entities and relationships:

The axiom system of an axiomatised empirical scientific theory is at best a system of logically fully formalised predicative statements, employing mathematical means of representation and descriptive, i.e. non-logical and non-mathematical, base terms. Let such an axiom system be interpreted by an empirical relational construct satisfying the axiom system of the associated empirical scientific theory T(Σ). Then this construct is said to be an evaluation model (in the closer sense) of Σ, or an (empirical) realisation of the axiom system Σ. The domain M of the construct consists of individuals of a part of the empirically accessible world of entities and events. Relations on M are empirically deducible respectively empirically verifiable properties of these entities as well as empirically deducible respectively empirically verifiable relationships amongst these entities.

For example, consider the axioms of classical particle mechanics:

(A1) P is a finite nonempty set.
(A2) T is an interval of real numbers.
(A3) Let p ∈ P and t ∈ T. Then s(p, t) is a twice t-differentiable vector-valued function.

Above, the set symbols P and T as well as the relation symbols s, m, and f are interpreted descriptive base terms, only implicitly defined by the formal axiomatic conditions. Their empirical interpretation takes place by the evaluation by terms of the used observation resp. measurement language. Let it be characterized on the level of the observation language as follows:
On (A1) P is a set of physical objects, e.g. the set of planet objects of the solar system, or more abstract, the set of centers of masses of the physical objects. The finiteness condition shell ensure the definability of the masses and the kinetic energy of the whole particle system.
On (A2) The elements of T represent periods of time. Concerning time measurement only, rational numbers had been sufficient. Reals are required to allow differentiation and integration wrt T.
On (A3) s = s (p, t) is a 2-ary location function, that describes the spacial changes of the physical objects (planets) p over time t. (A3) requires the existence of the 2nd derivative of s(p, t) wrt. t, s.t. (A7) can be satisfied.

In order to leap back to requirements modelling, as mentioned above, we take a look at the famous example by Jackson/ Zave 1995 of the requirements of a turnstile. They call an empirical realisation a designation set:

Each designation of the set gives a careful informal description by which certain phenomena may be recognised in the environment; it also gives a term by which the phenomena may be denoted in requirement and specification descriptions:
a) in event e a visitor pushes the barrier to its intermediate position ≈ Push(e)
b) in event e a visitor pushes the barrier fully home and so gains entry to the zoo ≈ Enter(e)
c) in event e a valid coin is inserted into the coin slot ≈ Coin(e)

In terms of Stachowiak: The unary relations Push(e), Enter(e), Coin(e) that are part of the formal requirements modelling language are defined by an empirical realisation in an informal observation language.

Thus, the theory of empirical-theoretical models by Stachowiak, provides a perfectly suitable foundation of semantic requirements modelling.

So long

1. Please excuse my rough and incomplete translation. Professional improvements welcome.
2. Ref: Michael Jackson, Pamela Zave (1995) Deriving specifications from Requirements: An Example
3. See also: Wilfrid Hodges (2009) Functional Modelling and mathematical Models: A semantic Analysis
4. More by Herbert Stachowiak: Fundamental Model Properties, Preterition and Abundance, …

Posted in Epistemology, Herbert Stachowiak, Requirements | Tagged , , , , , , , , , , , , , , , , | 1 Comment

Modeling for Understanding and/xor/etc Execution

Inspired by the discussion on “Executable models are models or programs? (and does it matter?)” on Modeling Languages.

Say, we have a list of a few thousand requirements, each nicely and precisely formulated e.g. like this*:
(1) p∈Personc∈Car drives(p, c)

From a purely logical perspective, we would be fine, since such sentences can be processed by e.g. a model checker in order to check its logical qualities etc. However, from a human point of view, such a list of requirements is impossible to understand, e.g. to discuss with the requirements provider. Therefore, describing the requirements in a restricted, easy to visualize language, i.e. modeling, is very helpful. For example, think of the above sentence as part of an ER-diagram. Thus, modeling solely for the purpose of understanding can have a value.

An even larger value could be achieved if the same models were used for understanding and generating (other models or code) or even direct execution. This is the big promise of various tool vendors and language standards. Due to the nature of their interests (perhaps) they appear quite reluctant towards certain practical difficulties that come with such an approach.

ER Tree and Org ChartThe following example is inspired by a software project situation I recently encountered. Say, we develop a database application that holds the organization structures of companies. They are all assumed as hierarchical, i.e. tree-like. So, firstly, we model a general tree structure as an ER model, as in (er-tree). For example, every r must have leafs l in L or forks f in F. Every such f must have further forks or leafs, until all leafs are reached (the 1:… cardinality guarantees that it’s acyclic). Secondly, we enrich this solely structural model with some business specific properties, as in (er-org). For example, the team entity type inherits the structural (tree) properties from the board, but not its business properties, so we have to put the latter into a subclass of R, Board.

Now, say, you are the requirements provider from the business side, how would you think of an org chart? Certainly, not like this. In general, it is definitely no bad idea to establish a common language of discourse between analyst and requirements provider, even if it is new to the latter. This is always a trade-off between effort of getting used to it and benefit for communication and thinking. However, models like the above clearly push it too far.

Thus, we have two concerns in the application domain, precision of processing towards execution, as well as ease of understanding towards the requirements provider. In simple development approaches, we can perhaps use a simplified model for the customer, and maintain the actual model manually ‘behind the scenes’. However, a sophisticated approach – as executable modeling – should be able to handle a consistent mapping between the two, as it does between business and architectural concerns – at least if it wants to go the whole (ambitious) way, from biz to exe.

So long

* If you don’t like the first order logic, you may think of it in natural language.


Posted in Requirements, Software_Engineering | Tagged , , , , , , , , , , , , , , | Leave a comment

Splitting the Requirements Atom

Requirements should exhibit, besides their logical properties (correct, complete, consistent, unambiguous), further important qualities. Atomicity is one of them. When is a requirement said to be atomic? For example, can (1) a = 21 be an atomic requirement? Well, it could be split into (2) a ≥ 21 and a ≤ 21 or even worse into (3) a is odd, a is not a prime, a > 15 ∧ a < 25 Does that mean (1) not atomic? In requirements literature there are lots of statements like: “A requirement is not atomic, if it can be split into more than one requirement.”, but nothing rigorous (as it seems). Alternatively, can the atomicity concept from logic take us further? Logically, a requirement is a sentence, i.e. they evaluate to either true or false. In particular, an atomic sentence is a formula that doesn’t contain any logical symbols (and, or, not, quantifiers) and thus no variables. However, with requirements we want to express properties on the class level (Boy loves Girl), usually not for single instances (Abelard loves Heloise). So, the atomicity concept from logic is not sufficient for requirements. Perhaps it can be expanded in a reasonable way? Worth to think about. Fortunately, the above example contains only a constant a, such that the atomicity concept of logic applies without modification. This leaves us with 2 kinds of atomicity: 1. the logical one, s.t. a=21 can be called atomic. 2. the ‘atom splitting’ one that divides = into le, ge, s.t. a = 21 could not be called atomic. How do these 2 interpretations relate to each other? Are they contradictory? Atomicity in 1 and 2 is compatible if = seen as an abstraction of ≥ and ≤. This means, they are statements on different abstraction levels, and since it makes lot of sense to picture requirements on different levels of abstraction separately it is perfectly reasonable to call a = 21 atomic. For example, Use Case Diagrams are a perfectly reasonable way to describe functional requirements, although they do not contain all details. Notice, that in addition, higher abstraction levels often use reduced language, that makes it impossible to express the details anyway, as in the = and Use Case Diagram example. Thus, a = 21 can be called atomic, with respect to a certain abstraction level, and can also be split into details, like a ≥ 21 and a ≤ 21. Such details on rock bottom level are sometimes called atoms, too (e.g. by Robertson & Robertson). So long |= PS Open Issue: can the logical atomicity be broadened to a useful concept in requirements?

Posted in Requirements | Tagged , , , , , , , , , , , | Leave a comment