Aardvark and Bandicoot, Chapter 16
Mon 16 May 2016 by mskala Tags used: programming, math, philosophy, aardvark, bandicootStudies in Ontology, with a Hint of Romance
[first chapter] | [all in this series]
Aardvark: Friend Bandicoot, do you know what a formal ontology is?
Bandicoot: Yes, Friend Aardvark. I learned about them in library school.
A: I thought you had a software engineering degree?
B: Well, yes, but I went to library school for a couple of years before changing majors.
A: I guess we pay you better than what librarians get.
B: Well, NO, actually, but there was this boy bandicoot I liked and he was in all the software engineering classes, and--
A: Fine, fine. I don't need to hear your whole life story right now.
B: --turned out the joke was on me because he had a thing about girl bandicoots who wear those glasses with the cord--
A: But... surely you could wear such glasses anyway, without having a degree in library science?
B: No, you have to earn them. Just like the software engineering pants.
A: Trousers.
B: Right! So, was that what you wanted to discuss today?
A: No, I wanted to talk about the ontology of software engineering.
B: I thought we agreed ontologies were part of library science.
A: They're originally from philosophy, if we must, but that's not the point. See, when we talk about software we have a particular ontology in mind. Entities, relations, and so on.
B: Sure. That's what ontologies are made of.
A: There are software modules, like the one you're working on for evaluating expressions. That's one kind of entity.
B: Yes, and the fact I'm writing it is a relation between me (the developer, another kind of entity) and the module.
A: Sure. And another class of entity is the "feature." Modules are related to the features that they have, and they have a different kind of relation to the features they don't have yet, but should. Because for instance there's a relation from the spec to a feature saying it's a required feature.
B: Or an optional feature, as it may be.
A: Yes.
B: Like that weird extra double-double feature you keep talking about.
A: Well, that's the thing. Because there are other relevant entities, too. There are test cases. And being able to add 2+2 is not a feature, it's--
B: That's what I've been trying to tell you! We don't really need it at all.
A: We do need it! It's a test case that has become important. But test cases are not the same thing as features. They are a separate class of entity.
B: Look, these "test cases" are things the module is supposed to do, right?
A: Yes.
B: That makes them features.
A: No. Features are the real goals. They're in the spec. They're what the customer is paying us for.
B: So a "test case" is a secret required feature that's not in the spec but you expect me to read your mind, know that it's required, and implement it, even though it's not what the customer is paying us for and it's not any real goal of the project, because something that actually mattered would be a "feature" and would be in the spec. And the extra double-double thing is one of these secret features that isn't important and doesn't matter but you're making a big deal of it anyway for reasons I can't determine because I left the planchette for my Ouija board in the pocket of my other trousers. Am I understanding this right?
A: No! There's a one to many relation between features and test cases. Every feature has one or more test cases; every test case is in principle a test for one feature, even if in practice sometimes we combine more than one into a single case.
B: So for every feature in the spec you're going to hit me with multiple secret features that I have to learn about by psychic mind-reading. Even if in practice sometimes they'll also be confused into larger conglomerations.
A: Well, you can read the test suite code if you must, I guess. That'll at least be faster than the Ouija board. Especially for the non-ASCII Unicode characters--
B: My Ouija board has full Unicode support. It covers all sixteen astral planes.
A: Nice. But test cases really are not secret features. They're not any kind of features. Different ontological class. The test case is the thing by which we know the feature really works.
B: Oh! So the point is just to know that each feature in the spec really works.
A: Yes.
B: And we have a bunch of code that is not directly part of the module but exists to verify that all the features work, and that's what you're calling the "test suite."
A: Right.
B: Individual cases in that code are called "tests," and each of them is, at least in principle, associated with one "feature."
A: Right, exactly.
B: Okay, I think I get it now. And there are some natural consequences of this ontology.
A: Sure. For instance, you can't just drop a test case because you don't like it, if the feature it tests is an important required feature. Even if the test case is not called out by name in the spec, as it probably won't be because in general the spec lists features, not tests.
B: Well... but features, not test cases, are the really important things.
A: That's true.
B: So we don't need any specific test case after all. We just need, for every feature, enough test cases to know that it works. If the tests cover the feature set really well, we won't actually be depending on any one test case to test any feature anyway. Because that feature will also be tested redundantly by other test cases. This redundancy helps us to know that the test suite itself is correct; it's not so sensitive to individual cases.
A: I'm glad you have a clear understanding of this issue.
B: Well, I did go to software engineering school.
A: Yes.
B: But the boy bandicoot I liked never did approach me.
A: Did you approach him?
0 comments
