here - Stefan-Marr.de
here - Stefan-Marr.de
here - Stefan-Marr.de
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
6. Evaluation: The OMOP as a Unifying Substrate<br />
Implementation size is often assumed to be an indication for implementation<br />
complexity, however, this assessment has an in<strong>here</strong>ntly social and subjective<br />
component. T<strong>here</strong>fore, the evaluation <strong>here</strong> consi<strong>de</strong>rs only directly measurable<br />
aspects. It uses implementation size in terms of lines of co<strong>de</strong> (LOC)<br />
as a surrogate measure for implementation complexity. As pointed out by a<br />
number of studies, size seems to correlate with other metrics to such a <strong>de</strong>gree<br />
that it is not clear whether t<strong>here</strong> is value in these additional metrics<br />
to assess complexity. Jay et al. [2009] found a strong correlation between cyclomatic<br />
complexity [McCabe, 1976] and lines of co<strong>de</strong>. For their experiments,<br />
they go so far as to conclu<strong>de</strong> that cyclomatic complexity has no explanatory<br />
power on its own. van <strong>de</strong>r Meulen and Revilla [2007] found that Halstead Volume<br />
[Halstead, 1977] and cyclomatic complexity correlate directly with LOC<br />
on small programs. Emam et al. [2001] studied object oriented metrics and<br />
their relation to class size, i. e., LOC. They find that previous evaluations of<br />
metrics did not account for class size and that the effects predicted by these<br />
metrics can be explained based on size alone. They conclu<strong>de</strong> that the value of<br />
these metrics needs to be reevaluated.<br />
Since these indications cast doubt on the value of metrics other than size<br />
for assessing complexity, this evaluation uses only size-based metrics as a<br />
surrogate for measuring complexity to compare the ad hoc and OMOP-based<br />
implementations.<br />
The second aspect of applicability is the ability to vary language guarantees.<br />
Sec. 6.5.1 discusses how the OMOP can be used to vary the semantics of<br />
concurrent programming concepts. The goal is to argue that it enables a wi<strong>de</strong><br />
range of variations covering a significant part of the <strong>de</strong>sign space spanned by<br />
the supported concurrent programming concepts. Based on the agents case<br />
study, the section argues that the additional semantic guarantees provi<strong>de</strong>d<br />
over Clojure agents are the kind of variations that are <strong>de</strong>sirable and a good<br />
indication for the variability of the OMOP. The range of supported concepts<br />
is an other indication that supports the conclusion that the OMOP provi<strong>de</strong>s<br />
sufficient flexibility for the <strong>de</strong>finition of language semantics for concurrent<br />
programming.<br />
Relevance of supported Concepts To evaluate the relevance, Sec. 6.5.1 argues<br />
that the supported concepts are used today. It gives for each of the<br />
supported concepts an example of either recent research in the corresponding<br />
area, or a programming language that is respected and used in industry.<br />
Based on these indications for actual use, it argues that each of the supported<br />
140