05.08.2014 Views

here - Stefan-Marr.de

here - Stefan-Marr.de

here - Stefan-Marr.de

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!