1

I do understand the SOLID Principles and LSP, but I want to be able to meausure how well a class diagram obeys to the LSP. Therefor I have found the "Value of LSP" metric, here is a guide how it should be used:

Metrics of Liskov Substitution Principles (LSP) The main key to this principle is the management of the inheritance hierarchy. The main metrics in this principle are NMI, NME and NMO. We specifies the NMI metric into NMIa the number of abstract methods inherited by the baseclass. NME metrics are the number of abstract methods defined by subclass, these definitions must be with the same method components (return type, name and parameter) like the baseclass property, whereas NMO metrics are the number of concrete methods overridden and overloading by subclass. This measurement is performed in a set of inheritance hierarchies, all of baseclass and subclasses pairs must be checked, to the lowest layer. The following is a technique for measuring class design conformity with LSP:

A)

A set of inheritance hierarchies, namely from (DIT = 0) ⋀ (NOC \> 0) ⋀ (abstract) to the largest DIT value at the lowest inheritance level. This set of hierarchies is called the Number of Hierarchies (NOH).

B)

This calculation is performed one by one between the baseclass inheritance pair and its subclasses in a set of inheritance hierarchies, namely by:

  1. Calculate the number of baseclass-children (NOC).

  2. Then calculate the value of ܰNMIa baseclass.

  3. Then calculate NME and NMO from each subclass.

  4. Match the value of NME and ܰNMIa for each pair of baseclass-subclass, make sure the values are the same. Then calculate NMO in the subclass, make sure that the NMO value is 0, if it is conform then it can be stated that the pair meets LSP, CLSP (Conform LSP).

  5. Calculate the NOC value of each subclass, if NOC > 0, then repeat the calculation of step 2 (B) to the children of the subclass.

C)

Calculations can stop immediately when encountered NMO > 0 the hierarchy NCLSP (Not Conform LSP).

D)

When NME is found to be smaller than ܰNMIa then check the subclass properties, if it is abstract, then continue the number 2 iteration (B) to their children, but if the concrete stops, the inheritance pair has subclasses that do not implement abstract methods, the hierarchy NCLSP.

E)

A set of inheritance hierarchies is stated to meet LSP when all inheritance pairs fulfill LSP requirements.

My question is if I start with an abstract Superclass (DIT=0) then the NMIa is going to be 0 such as NME and NMO, because you can't override or extend unimplemented functions, so in this case it's always Conform to LSP. Is my assumption correct? Could you give some examples when a violation of LSP would be registered by the metric and when a class diagram would be LSP conform?

The original paper can be found here: https://easychair.org/publications/preprint_download/pmpT

David
  • 21
  • 3
  • 1
    Presumably a violation of LSP is *always* registered by the metric. A class conforms to LSP when it adheres to all of the rules of LSP. – Robert Harvey Oct 14 '21 at 11:50
  • I have found it in a scholar paper on IEEE, so that's why it might look a little bit strange, but I couldn't find anything else which would make it measurable. My goal is to be able to "automatically" detect a LSP violation – David Oct 14 '21 at 11:54
  • For those of you who were wondering (as I was) what this is all about, the original paper from where this is derived can be found [here](https://easychair.org/publications/preprint_download/pmpT). – Robert Harvey Oct 14 '21 at 11:56
  • Thanks for adding the link to the paper. For the beginning I'd like to be able to do it by hand for my understanding and in the future it could be done by code – David Oct 14 '21 at 12:05
  • I don't think this can detect LSP violations, except for the trivial ones - might be useful in a large, out-of-control codebase, but if your goal is 'to be able to "automatically" detect a LSP violation', this is not going to do much. – Filip Milovanović Oct 14 '21 at 12:10
  • @FilipMilovanović Detecting trivial vioaltions would also be nice. Unfortunatly this is the only quantified approach I was able to find, but I am very open to alternatives, if you have any suggestions or know some algorithms – David Oct 14 '21 at 12:13
  • Does this answer your question? [How to verify the Liskov substitution principle in an inheritance hierarchy?](https://softwareengineering.stackexchange.com/questions/170189/how-to-verify-the-liskov-substitution-principle-in-an-inheritance-hierarchy) – gnat Oct 14 '21 at 12:36
  • 5
    The kinds of trivial violations that this can detect can also be detected by a compiler. Those aren't really that interesting. The problem is that a class diagram (static structure) is not enough information to determine LSP adherence, beyond just that the formal interface is implemented - tells you nothing about behavioral compatibility. – Filip Milovanović Oct 14 '21 at 12:37
  • Why do you think this approach is so bad? I mean it was somewhat proven in the paper, at least for class diagrams, which I am currently looking for. I am not sure what you mean by saying that a compiler could do the same. How does a Python compiler for example tell me about a LSP violation? I do understand what you mean by behavioral compatibility, but thatswhy it also involves methods of classes. I can't find any other metrical approach for this purpose, let me know if you know some. – David Oct 14 '21 at 13:09
  • @gnat Sorry, that's not what I am looking for, I need a quantitative solution – David Oct 14 '21 at 13:10
  • 1
    Do you really need metrics, or do you just need to know if an LSP violation has occurred? – Robert Harvey Oct 14 '21 at 13:23
  • 1
    @David, the answer in the link provided by gnat nicely illustrates the problem with automatically trying to find LSP violations. The algorithm you posted will classify that Rectangle/Square pair as Conform LSP, where in reality it is not. – Bart van Ingen Schenau Oct 14 '21 at 13:26
  • @BartvanIngenSchenau the problem is that I am looking for something for the step before the implementation, on design level. The rectangle square example should be a vioalotion accoirding to this, because NMO (Number of Overriden Merhods) > 0 or do I get the it wrong? – David Oct 14 '21 at 13:40
  • Main purpose of my question was to get some examples of using this method for a class diagram of your choice, so if there is a violation which this method won't detect or would detect, then please just show me the proccess of evaluating for my understanding – David Oct 14 '21 at 13:43
  • see [Why do 'some examples' and 'list of things' questions get closed?](https://softwareengineering.meta.stackexchange.com/a/7538/31260) – gnat Oct 14 '21 at 13:55
  • @gnat I don't need a list of things. The reason stated there, why asking for examples gets closed is because there are no right answer, but I need something more specific, "Could you give some examples when a violation of LSP would be registered by the metric and when a class diagram would be LSP conform?" In this case it's the same as asking a "how to" question, because the only way you could explain it to me is giving specific examples. You usually do the same if you answer to a question like "How to do x by using y" – David Oct 14 '21 at 14:05
  • 1
    Just to clarify: consider, for example, the [IComparable interface](https://docs.microsoft.com/en-us/dotnet/api/system.icomparable) where you have to implement a single method, CompareTo, that returns a value indicating the sort order. It's just a method that accepts an object and returns an int. It's abstract behavior *is not* entirely specified by the interface; you have to look at the documentation too. For example, if objA.CompareTo(objB) and objB.CompareTo(objA) both say that the parameter comes after the `this` instance (contradicting each other), then it's an LSP violation. 1/2 – Filip Milovanović Oct 17 '21 at 12:59
  • 1
    A compiler in a statically typed language can catch if you haven't implemented a method, and you can use reflection to see if a method is overridden. But overridden methods are fine - they don't automatically break LSP. And implementations of abstract methods still can. This is why I don't see much value in this approach - it has very little usefulness (besides, the paper looks shady and is poorly written). If you want useful metrics, implement TDD tests of *abstract behavior*, plug in an implementation, and produce a count of how many pass/fail. 2/2 – Filip Milovanović Oct 17 '21 at 12:59

0 Answers0