Chapter 5: SpecificationYuanfang CaiCS751 Jan 29, 2003

OverviewDefinition5.1 The Uses of Specification5.2 Specification Qualities5.3 Classification of Specification Styles5.4 Verification of Specification5.5 Operational Specifications5.6 Descriptive Specifications5.7 Building and Using Specifications in Practice

OverviewDefinition5.1 The Uses of Specification5.2 Specification Qualities5.3 Classification of Specification Styles5.4 Verification of Specification5.5 Operational Specifications5.6 Descriptive Specifications5.7 Building and Using Specifications in Practice

OverviewDefinition5.1 The Uses of Specification5.2 Specification Qualities5.3 Classification of Specification Styles5.4 Verification of Specification5.5 Operational Specifications5.5.1 Data Flow Diagram (DFD): Function5.5.2 Unified Modeling Language (UML): Behavior5.5.3 Finite State Machine (FSM): Control Flow5.5.4 Petri Nets: Asynchronous Systems5.6 Descriptive Specifications5.7 Building and Using Specifications in Practice

OverviewDefinition5.1 The Uses of Specification5.2 Specification Qualities5.3 Classification of Specification Styles5.4 Verification of Specification5.5 Operational Specifications5.6 Descriptive Specifications5.6.1 Entity Relationship Diagrams5.6.2 Logic Specification5.6.3 Algebraic Specifications5.7 Building and Using Specifications in Practice

Definition The statement of an agreement between a producer of a service and the consumer of the service or between an implementer and a userRequirement specification

Design specification

Module specification

Requirements, Specification and Design

Definition The statement of an agreement between a producer of a service and the consumer of the service or between an implementer and a userRequirement specificationBetween end user and the system architect/developerDesign specification

Module specification

Requirements, Specification and Design

Definition The statement of an agreement between a producer of a service and the consumer of the service or between an implementer and a userRequirement specificationBetween end user and the system architect/developerDesign specificationBetween the architect and the implementersModule specification

Requirements, Specification and Design

Definition The statement of an agreement between a producer of a service and the consumer of the service or between an implementer and a userRequirement specificationBetween end user and the system architect/developerDesign specificationBetween the architect and the implementersModule specificationBetween the implementer and the user of a moduleRequirements, Specification and Design

5.1 The use of SpecificationsA statement of user requirementA statement of interface between the machine and the controlled environmentA statement of requirements for the implementationA reference point during product maintenance.

5.2 Specification Quality Clear, unambiguous and understandableConsistencyCompleteInternally completeExternally complete

5.3 Classification of Specification Styles Formal, informal and Semiformal SpecificationsOperational and descriptive specificationsOperational specifications: desired behaviorDescriptive specifications: desired properties

5.4 Verification of Specifications Dynamic analysisStatic analysisFormalism and verificationSimulation PrototypeVerify all three aspects:FunctionalConsistency completeness

5.5 Operational Specifications 5.5.1 Data Flow diagramsFeaturesExamplelimitations5.5.2 UML Diagram for Specifying Behaviors5.5.3 Finite State Machine: Describing Control Flow5.5.4 Pretri Nets: Specifying Asynchronous Systems

5.5.1 Data Flow Diagram: Specifying Functions of Information SystemsFeaturesDescribe systems as collections of functions that manipulate dataCan be expressed by means of graphical notationElements:Input device symbolFunction symbolData flowOutput device symbolData store symbol

5.5.1 DFD Examplea+*+*bdc(a + b) * ( c + a * d)

5.5.1 DFD limitationsThe semantics of the symbol is specified only by the identifiers chosen by the user. Control aspects are not defined by the model BDECFA

5.5.1 DFD LimitationsThe semantics of the symbol is specified only by the identifiers chosen by the user. Control aspects are not defined by the model BDECFA

5.5.1 DFD LimitationsThe semantics of the symbol is specified only by the identifiers chosen by the user. Control aspects are not defined by the model BDECFA

5.5 Operational Specifications 5.5.1 Data Flow diagrams5.5.2 UML Diagram for Specifying BehaviorsFeaturesExampleLimitations5.5.3 Finite State Machine: Describing Control Flow5.5.4 Pretri Nets: Specifying Asynchronous Systems

5.5 Operational Specifications 5.5.1 Data Flow diagrams5.5.2 UML Diagram for Specifying Behaviors5.5.3 Finite State Machine: Describing Control FlowDefiniationFeaturesExampleLimitations5.5.4 Pretri Nets: Specifying Asynchronous Systems

5.5.3 Finite State Machines: Describing Control FlowDefinitionA finite automata is a 5-tuple (Q, , , q0, F), whereQ is a finite set called the states, is a finite set called the alphabet (inputs), : Q Q is the transition function, q0 Q is the start state, and F Q is the set of accept states (final states).

5.5.3 Finite State Machines: Describing Control FlowFeaturesFormal notationSuitable for describing systems that can be in a finite set of states and that can go from one state into another as a consequence of some event, modeled by an input symbol. Widely used: specification of control systems, compilation, pattern matching, etc.

5.5.3 Finite State Machines: Describing Control FlowExample

OnOff

5.5.3 Finite State Machines: Describing Control FlowExample: Chemical plant

OnOff

5.5.3 Finite State Machines: Describing Control FlowExample: Chemical plantNormalOffPressureRecoveryTemperatureRecovery

5.5.3 Finite State Machines: Describing Control FlowLimitationsFinite states: need assistance such as natural language or accompanied by action descriptions, like:Cooling_effort := k * (present_temperature standard temperature)Cant describe concurrent, asynchronous systems. P1P2C1C2012writeproducereadconsumewritewritereadreademptyfull

5.5.3 FSM: Describing Control FlowExample continued: the Cartesian Product of the component state sets:consumeconsumeProduceProduce

consumeconsumeProduceProduce

consumeconsumeProduceProduce

writewritereadreadwritereadread

5.5.3 Finite State Machines: Describing Control FlowLimitations:The cardinality of the state space grows dramatically: if we have n subsystems, each with ki states, the resulting system has a cardinality of k1*k2*KnFSM are essentially a synchronous model: at any time, a global state of the system must be defined and a single transition must occur.

5.5 Operational Specifications 5.5.1 Data Flow diagrams5.5.2 UML Diagram for Specifying Behaviors5.5.3 Finite State Machine: Describing Control Flow5.5.4 Pretri Nets: Specifying Asynchronous SystemsDefinitionExampleFeaturesLimitations

5.5.4 Petri Nets: Specifying Asynchronous SystemDefinitionA Petri Net is a quadruple (P, T, F, W), whereP is the finite set of places;T is a finite set of transitions; P T ;F { P T} { T P} is the flow relation; andW: F N {0} is the weight function, which associates a nonzero natural value to each element of F. If no weight value is explicitly associated with a flow element, the default value 1 is assumed for the function

5.5.4 Petri Nets: Specifying Asynchronous SystemExample:writeproducep1p2PlaceTokenTransitionp2 is the input place of transition writep1 is the output place of transition writeProduce is the enabled, so transition produce may fire

5.5.4 Petri Nets: Specifying Asynchronous SystemExample:writeproducep1p2PlaceTokenTransitionp2 is the input place of transition writep1 is the output place of transition writeProduce is the enabled, so transition produce may fire2

5.5.4 Petri Nets: Specifying Asynchronous SystemExample: After produce firedwriteproducep1p2PlaceTokenTransitionp2 is the input place of transition writep1 is the output place of transition writeNow, write is the enabled, so transition write may fire2

5.5.4 PN: Specifying Asynchronous SystemExample: producer and consumerwriteproducep1p2consumereadc1c2readwrite01readwrite2

5.5.4 PN: Specifying Asynchronous SystemExample continued:producer and consumer:

consumec1c2producep1p2readwrite01readwrite2Now the system is at the state

5.5.4 PN: Specifying Asynchronous SystemExample continued:producer and consumer:

consumec1c2producep1p2readwrite01readwrite2Now the system is at the state

5.5.4 PN: Specifying Asynchronous SystemExample continued:producer and consumer:

consumec1c2producep1p2readwrite01readwrite2Now the system is at the state

5.5.4 Petri Nets: Specifying Asynchronous SystemFeaturesGood at describing concurrent and asynchronous systemLimitationsTokens are anonymousCant specify a selection policyCant resolve deadlock or starving

5.6 Descriptive Specifications5.6.1 Entity Relationship (ER) DiagramsA semiformal notation5.6.2 Logic Specification5.6.3 Algebraic Specifications

5.6.1 Entity Relationship DiagramsSTUDENTCLASSAGESEXNAMEENROLLED_INSUBJECTCOURSE_IDMAX_ENROLLMENTEntities: a collection of items that share common propertiesRelations: A set of pairs , where a is an element of STUDENT and b is an element of CLASSAttribute:

5.6.1 Entity Relationship DiagramsRelation Attributes:ABRABRABRABRA R B is one to oneA R B is one to manyA R B is many to oneA R B is many to many

Unified Modeling LanguageA general-purpose visual modeling language that is used to specify, visualize, construct and document the artifacts of a software system. Static Structure (Descriptive)Dynamic behavior (Operational)

Unified Modeling LanguageStatic Structure (Descriptive)Static view: class diagramUser Case ViewPhysical ViewsImplementation viewDeployment viewDynamic behavior (Operational)Interaction viewSequence diagramCollaboration diagramState machine viewActivity view

Unified Modeling LanguageStatic Structure (Operational)Static View: class diagramUser Case ViewPhysical ViewsImplementation viewDeployment viewDynamic behavior (Descriptive)Interaction viewSequence diagramCollaboration diagramState machine viewActivity view

Seat: Sting1*1*11..*Classattributesclass-scope operationassociationgeneralizationmultiplicities

Class Diagram: qualifier0..13..60..11

CustomerName: StringPhone: StringAdd(name,phone)

ReservationDate: Date

Subscription SeriesSeries: integer

Individual Reservation

TicketAvailable: BooleanSell (c. Customer)Exchange()

ShowName: String

PerformanceDate: DateTime: TimeOfDay

Kioskbuy ticketsbuy subscriptionmakechargessurveysalesrelationshipUse case

ClerkCredit card serviceSupervisorsystemactor

Use Case Diagram:

Unified Modeling LanguageStatic Structure (Operational)Static View: class diagramUser Case ViewPhysical ViewsImplementation viewDeployment viewDynamic behavior (Descriptive)Interaction viewSequence diagramCollaboration diagramState machine viewActivity view

Kioskbox officecredit card servicemessagelifeline (active)Active object

Sequence Diagram

Kioskticketsellermessageactive objectperformanceGuideDb: performanceDBlinkmulti objectDb: performanceDBdbtransient linkpassive object3: seat-list := lock(count) 6: claim (seats) 7: unlock(seat-list)

Collaboration Diagram:

Initial stateAvailableLockedSoldstatetransitionTrigger eventAssign to subscriptionTime outlockunlockexchangebuy

State chart Diagram

activityPick showschedule showpublicize showBuy scripts and musicHireartistsBuild setsDesign lightingMakecostumesSell ticketsrehearseDress rehearsalperformCompletion transitionjoinfork

Activity Diagram

Questions?