Technical work in software engineering begins with the creation of the ANALYSIS MODEL. At this stage requirements are derived and a foundation for design is established. Therefore, technical metrics that provide insight into the quality of the analysis model are DESIRABLE — and rare, because there is little to count. FUNCTION-BASED METRICS — the function point, computed from the analysis model as in the cost modelling topic. It is the principal analysis-model metric, precisely because it can be computed from a specification rather than from code. METRICS FOR SPECIFICATION QUALITY (Davis et al.) — a way to measure a requirements document. Let: n_r = the number of requirements = n_f + n_nf (functional + non-functional) SPECIFICITY (lack of ambiguity): Q1 = n_ui / n_r where n_ui is the number of requirements for which ALL REVIEWERS HAD IDENTICAL INTERPRETATIONS. → the closer Q1 is to 1, the lower the ambiguity. This is a genuinely clever metric: rather than trying to define ambiguity, it MEASURES DISAGREEMENT among readers, which is what ambiguity actually is. COMPLETENESS of functional requirements: Q2 = n_u / (n_i × n_s) where n_u = the number of unique function requirements n_i = the number of inputs (stimuli) defined or implied n_s = the number of states specified → measures the percentage of necessary functions specified, by comparing what IS specified against the size of the input × state space that COULD be. DEGREE TO WHICH REQUIREMENTS HAVE BEEN VALIDATED: Q3 = n_c / (n_c + n_nv) where n_c = requirements validated as correct n_nv = requirements not yet validated WORKED — a requirements document under review: n_r = 88 requirements (61 functional, 27 non-functional) reviewers agreed on the reading of 71 Q1 = 71/88 = 0.807 → 17 requirements were read differently by different reviewers. Those 17 are the ones to rewrite, and Q1 gives you both a number to track and a specific list of work. n_u = 61 unique functions, n_i = 14 inputs, n_s = 9 states Q2 = 61 / (14 × 9) = 61/126 = 0.484 → about half the input × state combinations have a specified function. That is not necessarily wrong — many combinations are meaningless — but it is a prompt to check which of the other 65 are genuine gaps. Compare this to the "completeness includes invalid inputs" requirement from the SRS topic. n_c = 54 validated, n_nv = 34 not yet Q3 = 54/88 = 0.614 → the document is 61% validated, so any statement that "requirements are agreed" is premature.

ARCHITECTURAL DESIGN METRICS focus on characteristics of the program architecture with emphasis on structure and effectiveness of modules. They are BLACK BOX — they do not require knowledge of the inner workings of a module. Card and Glass define three measures: STRUCTURAL COMPLEXITY S(i) = f²_out(i) where f_out(i) is the fan-out of module i DATA COMPLEXITY D(i) = v(i) / (f_out(i) + 1) where v(i) is the number of input and output variables passed to and from module i SYSTEM COMPLEXITY C(i) = S(i) + D(i) As each increases, the overall architectural complexity increases, leading to greater integration and testing effort. MORPHOLOGY METRICS (Fenton), for a program structure with n nodes and a arcs: size = n + a depth = the longest path from root to leaf width = the maximum number of nodes at any one level arc-to-node ratio r = a / n — a measure of coupling DESIGN STRUCTURE QUALITY INDEX (DSQI) — computed from seven measured values: S1 total number of modules S2 number of modules whose correct function depends on the source of data input or that produce data used elsewhere S3 number of modules whose correct function depends on prior processing S4 number of database items S5 number of unique database items S6 number of database segments S7 number of modules with a single entry and exit Six intermediate values are then computed: D1 = 1 if the architecture was developed using a distinct method, else 0 (program structure) D2 = 1 − (S2/S1) module independence D3 = 1 − (S3/S1) modules not dependent on prior processing D4 = 1 − (S5/S4) database size D5 = 1 − (S6/S4) database compartmentalisation D6 = 1 − (S7/S1) module entrance/exit DSQI = Σ w_i D_i with Σ w_i = 1 DSQI ranges 0 to 1, higher being better, and its real value is COMPARISON: a DSQI significantly lower than a past project's signals that further design work and review are warranted. COMPONENT-LEVEL DESIGN METRICS — measure the internal characteristics of modules. WHITE BOX in nature. Three: COHESION METRICS (Bieman and Ott) define a collection of metrics providing an indication of the cohesiveness of a module — based on "data slices" and "glue tokens". Cohesion is normalised to 0..1, with 1 the most cohesive. COUPLING METRICS (Dhama) covering data and control flow coupling, global coupling and environmental coupling. Module coupling m_c = k / M, where the larger the value of m_c the lower the coupling — so the metric is constructed to make "high is good". COMPLEXITY METRICS cyclomatic complexity V(G) is the most widely used. Recall the risk bands: 1–10 simple, 11–20 moderate, 21–50 complex, above 50 untestable. INTERFACE DESIGN METRICS — LAYOUT APPROPRIATENESS (LA): LA = Σ (cost of making transitions in the proposed layout) relative to the optimal layout A value near 1 indicates the layout is near optimal. Used to assess whether related interface entities are placed near one another.

The CHIDAMBER AND KEMERER metric suite is the most widely used set of object-oriented design metrics, and the most likely to be examined. 1. WEIGHTED METHODS PER CLASS (WMC) WMC = Σ c_i, the sum of the complexities of the n methods of a class (complexity often taken as 1, giving a plain method count, or as cyclomatic complexity). · the larger the WMC, the more effort to develop and maintain the class · a large WMC limits reuse, because the class is more application-specific · high WMC suggests the class has too many responsibilities — a cohesion problem 2. DEPTH OF THE INHERITANCE TREE (DIT) The maximum length from a class to the root of the inheritance hierarchy. · as DIT grows, lower-level classes inherit many methods, making behaviour HARDER TO PREDICT · deeper trees imply greater design complexity · but deep trees also indicate greater potential REUSE of inherited methods — so DIT has an optimum, not a direction. Commonly quoted guidance is to keep DIT below about 5 or 6. 3. NUMBER OF CHILDREN (NOC) The number of immediate subclasses of a class. · high NOC means high reuse of the parent, which is good · but it also means the ABSTRACTION MAY BE DILUTED — some children may not truly be subtypes · and high NOC demands MORE TESTING of the parent's methods, because a change there affects many children 4. COUPLING BETWEEN OBJECT CLASSES (CBO) The number of collaborations a class has with others. · as CBO increases, reusability decreases · high CBO complicates modification and testing · CBO SHOULD BE KEPT AS LOW AS REASONABLE — this is the coupling principle from the design concepts topic, made countable 5. RESPONSE FOR A CLASS (RFC) The number of methods in the response set — all methods that can be invoked in response to a message to an object of the class, including methods called indirectly. · as RFC increases, testing effort increases because the test sequence grows · as RFC increases, the overall design complexity of the class increases 6. LACK OF COHESION IN METHODS (LCOM) The number of methods that access one or more of the same attributes, versus those that do not share attributes. · HIGH LCOM means LOW cohesion — the class is doing several unrelated things and should probably be split · LCOM = 0 is ideal WORKED — reading a CK report on four classes: class WMC DIT NOC CBO RFC LCOM ────────────────────────────────────────────── LicenceApplication 14 1 0 5 22 2 ApplicationManager 47 1 0 19 96 31 Officer 8 2 0 3 14 0 BaseEntity 3 0 4 1 5 0 DIAGNOSIS: ApplicationManager is the problem, on every metric at once. WMC 47 — far too many responsibilities CBO 19 — it collaborates with nearly everything, so almost any change touches it; it cannot be tested in isolation RFC 96 — 96 methods reachable from one message; the test sequences are enormous LCOM 31 — its methods barely share attributes, which is the mathematical signature of a class that is really several classes stuck together → this is the "God class" anti-pattern, and the metrics identify it before anyone has to read the code. The indicated action is to split it along the attribute clusters that LCOM is detecting. BaseEntity has NOC 4 and DIT 0 — a root with four children. That is healthy reuse, but it means a change to BaseEntity's methods requires re-testing four subclasses. NOC is therefore a TESTING-effort indicator, not just a reuse one. Officer with LCOM 0 and low everything is exactly what a well-formed design class looks like — compare the "complete and sufficient, primitive, high cohesion, low coupling" criteria from the design model topic. THE METRICS AND THE QUALITATIVE CRITERIA AGREE, which is the point of having them. OTHER OO METRIC SUITES worth naming: MOOD Method Hiding Factor, Attribute Hiding Factor, Method Inheritance Factor, Attribute Inheritance Factor, Polymorphism Factor, Coupling Factor LORENZ AND KIDD class size, number of operations overridden, number of operations added, specialisation index METRICS FOR OO TESTABILITY lack of cohesion in methods, percent public and protected, public access to data members, number of root classes, fan-in