3

How can I observe ripple effect using coupling attributes alone?

I first find the common coupling metrics for a set of deprecated classes in a project, like CBO(Coupling Between Objects), RFC(Response For Classes), Import/Export coupling, Afferent coupling(Total no. of incoming edges to a deprecated package), Efferent coupling(Total no. of outgoing edges from a deprecated package ), etc.

How can all this be interlinked to Ripple Effect?

Can Abstractness and Instability of a class be a result of Ripple effect associated with it?

Background: This is for a Reengineering project that we are doing by trying to go through the coupling that exists across all deprecated classes/APIs in around 20 projects. Instability (I) metric measures the instability of packages, where stability is measured by calculating the effort to change a deprecated package without impacting other packages within the application. Metric measures the ratio between CE(Efferent Coupling) and CE+CA(Afferent Coupling). Instability I = Ce / (Ca + Ce)
Abstractness (A) is the linear unit metric that measures how abstract a package is, in that it will calculate the ratio between the number of abstract classes or interfaces and the total number of classes inside a package. One can measure the abstractness of a package (A) using the following formula: A = Na / Nc Where: Na is the number of abstract classes and interfaces in the package
Nc is the number of concrete classes and interfaces in the package

Deprecated API remains in the software, its use may raise warning messages recommending alternative practices; deprecated status may also indicate the feature will be removed in the future. Features are deprecated rather than immediately removed, to provide backward compatibility, and to give programmers time to bring affected code into compliance with the new standard.

neyrah
  • 39
  • 2
  • You might want to put a little more background into your question. Don't assume we all know what you're talking about. And no, "I'll just wait for someone who knows all of my domain-specific vocabulary to answer" is not a valid reason to refrain from providing such background. – Robert Harvey Mar 20 '18 at 02:46
  • @RobertHarvey, modified the question. Thanks for the suggestion – neyrah Mar 20 '18 at 02:57
  • Seems like your entire project is based on the premise that interfaces or abstract classes reduce coupling, which is false, except for constructors. – Frank Hileman Mar 21 '18 at 19:04
  • 1
    Coupling can only be measured by the symbol references between "packages". Abstractness, as defined, is useless and can be artificially inflated. Decoupling means you remove references to data types or their members; this is the only type of decoupling that reduces work in the future. – Frank Hileman Mar 21 '18 at 19:27
  • @FrankHileman, thanks but I am not trying to reduce coupling. I just want to study how this coupling exists between packages in case of Deprecated API. For which I am using the aforementioned metrics to measure the number of dependencies. I just want to know how all this is linked to ripple effect – neyrah Mar 23 '18 at 14:15
  • 1
    "Ripple effect" is an vernacular phrase in English. If you are using some formal definition, you should explain it. The more dependencies you have, the bigger the changes required. "ripple" implies other things change as well (besides the direct API usages); that is probably impossible to determine before hand using these metrics. – Frank Hileman Mar 24 '18 at 21:36
  • 1
    On the other hand, a static analysis tool could determine this information, as it can trace dependencies across packages. – Frank Hileman Mar 26 '18 at 16:47
  • Yes, that's true. I use Understand tool for extracting the coupling related metrics. I found lots of interesting results. – neyrah Mar 28 '18 at 03:24

0 Answers0