1 / 15

Decoding Specifications: MSC and Their Meaning

Delve into the intricacies of specifications using MSCs to understand the relationships between specification, design, and implementation. Discover the nuances of underspecification, overspecification, correctness, and design in software development.

arce
Download Presentation

Decoding Specifications: MSC and Their Meaning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Meaning of a Specification’s Meaning Case Example: MSC Clive Jervis

  2. What is a Specification? • We readily use terms such as: • specification, • design, • implementation. • We invent formal languages to express these. • We may even ascribe them formal semantics. • We use sub-categories such as: • underspecification • overspecification • refined specification • But what do they mean? • What are their relationships?

  3. Specification • A simple definition: • A specification represents a set of implementations • A specification that represents more than one implementation we call underspecification - an implementer is free to choose which one to build. • A specification that represents just one implementation is complete and the implementer has no freedom of choice. • Notice, the ‘type’ of specifications is different to the ‘type’ of implementations: type Spec = set of(set of Imp) • Definition is independent of definition of implementation.

  4. Correct Implementation • Definition of correctness: • An implementation satisfies its specification if it is amongst its representations. • I satisfies S  I  S • If a specification is inconsistent, then it represents the empty set, and so no implementation can satisfy it.

  5. Is MSC a Specification Language? According to the language, an MSC defines a set of traces. But does each trace define an intended implementation? msc am_I_a_specification upper middle lower m n < !m, ?m, !n, ?n > < !m, !n, ?m, ?n > < !m, !n, ?n, ?m > • MSC defines 3 traces. • Each trace fixes the exact order of events ?m and ?n. MSC semantics does not seem to fit our definition of specification

  6. msc one_implementation_or_two upper middle lower m n MSC is a Specification Language It is possible to define functions that transforms a set of traces into sets of traces. • However, there are different functions. • For example: • one permits only deterministic implementations • one permits non-determinist implementations MSC Semantics not very helpful but permits many interpretations

  7. When is a Specification not a Specification? • When it’s a design. • Specifications commonly tell not just what we can build, but how to build it. • When is a design not a design? • When it’s a specification. • Often designs are vehicles for expressing specifications. • That is, an implementer does not have to follow the design, just the functionality. • Is MSC a design language?

  8. Design • A simple definition: • A prescription for building an implementation • from a set of given components • By ‘given’ we mean specified. • By ‘prescription’ we mean a function. • Notice, the ‘type’ of design is different to the ‘type’ of specification and ‘type’ of implementation. • Definition is independent of implementation, but not of specification.

  9. Correct Design • A design is correct with respect to a specification if: • whenever we take a set of components that meet their specifications, • and construct an implementation following the design prescription, • then it satisfies the specification. • c1 sat S1 …  cn sat Sn D(c1, …, cn) sat S • Note, design correctness is measured against a given specification.

  10. Is MSC a Design Language? • If we partition instances into components, then the partition forms a design. • In particular, if we take each instance as a separate component, it represents a design. • How to consider an MSC as a design: • extract a trace specification for each component • concurrent composition of the components represents the design function MSC is a design language if we define components. MSC language is not very helpful in defining designs.

  11. Overspecification We can define overspecification of a component in a design. If a component specification can be relaxed without altering the set of possible constructions, then it is overspecified. Overspecification represents functional redundancy.

  12. Overspecified Instance msc overspecified upper middle lower Middle specifies that m is sent before n, but upper and lower don’t know or care. m n msc just_right upper middle lower Implementer is free to choose order of sending m and n. m n

  13. Refinement A refinement is a design that satisfies a given specification. Refinement can reduce the choices open to an implementer. Can MSCs be used in refinement? That’s another story …

  14. What is the meaning of MSC? Is it a specification language? Is it a design language? Is it an implementation language? Its whatever you want it to be, but the semantics fit none of the above! No-one agrees on what an MSC means, even though everyone can agree its semantics. If we add a definition of implementation, we find that there are MSCs with well defined semantics, but which are inconsistent (have no possible implementation)!

  15. Call To Arms • Let us agree on meaning of semantic terms • Ensure that: • recommendations use the terms consistently • the semantics reflect the terms • We are worse off than UML, because we pretend to have semantics, even formal semantics

More Related