Software Design Principles Questions and Answers

Answer: C

The units are software units.

The formula is the coupling metric proposed by Fenton and Melton for a pair of modules x and y. i is the worst (highest) type of coupling relationship found between the two, on an ordinal scale running from no coupling up to content coupling, and n is the number of interconnections between them. The units being measured are therefore software modules in general, whatever language or paradigm they come from.

The metric is not restricted to classes, objects or methods; those are particular kinds of unit in object-oriented design, and the measure applies to any pair of software units.

Answer: B

The statement that is not a design principle is (ii) only.

The Interface Segregation Principle, one of the class-based component design principles Pressman lists, says the opposite of (ii): many client-specific interfaces are better than one general-purpose interface, so that clients do not depend on operations they do not use.

Statement (i) is the Open-Closed Principle, that a module should be open for extension but closed for modification. Statement (iii) is the Common Closure Principle, that classes that change together belong together in a package. Both are genuine principles, so options including them are wrong.

Answer: A

Cohesion is intra-module and coupling is inter-module.

Cohesion measures how closely the elements within a single module belong together, how focused the module is on one task. Coupling measures the degree of interdependence between modules. Good design aims for high cohesion and low coupling.

Option B reverses the two, and options C and D put both concepts on the same side, which would make them the same measure.

Answer: B

MDD stands for model-driven development.

Model-driven development (also called model-driven engineering) makes models, rather than code, the main outputs of development. Higher-level models of the system are transformed, often automatically, into lower-level models and finally into executable code; the OMG's Model Driven Architecture is one form of it.

The other expansions are not standard terms; none of them is what the abbreviation means in software engineering.