540 likes | 773 Views
Chapter 5: Specification. Yuanfang Cai CS751 Jan 29, 2003. Overview. Definition 5.1 The Uses of Specification 5.2 Specification Qualities 5.3 Classification of Specification Styles 5.4 Verification of Specification 5.5 Operational Specifications 5.6 Descriptive Specifications
E N D
Chapter 5: Specification Yuanfang Cai CS751 Jan 29, 2003
Overview Definition 5.1 The Uses of Specification 5.2 Specification Qualities 5.3 Classification of Specification Styles 5.4 Verification of Specification 5.5 Operational Specifications 5.6 Descriptive Specifications 5.7 Building and Using Specifications in Practice
Overview Definition 5.1 The Uses of Specification 5.2 Specification Qualities 5.3 Classification of Specification Styles 5.4 Verification of Specification 5.5 Operational Specifications 5.6 Descriptive Specifications 5.7 Building and Using Specifications in Practice
Overview Definition 5.1 The Uses of Specification 5.2 Specification Qualities 5.3 Classification of Specification Styles 5.4 Verification of Specification 5.5 Operational Specifications 5.5.1 Data Flow Diagram (DFD): Function 5.5.2 Unified Modeling Language (UML): Behavior 5.5.3 Finite State Machine (FSM): Control Flow 5.5.4 Petri Nets: Asynchronous Systems 5.6 Descriptive Specifications 5.7 Building and Using Specifications in Practice
Overview Definition 5.1 The Uses of Specification 5.2 Specification Qualities 5.3 Classification of Specification Styles 5.4 Verification of Specification 5.5 Operational Specifications 5.6 Descriptive Specifications 5.6.1 Entity Relationship Diagrams 5.6.2 Logic Specification 5.6.3 Algebraic Specifications 5.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 user • Requirement 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 user • Requirement specification • Between end user and the system architect/developer • 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 user • Requirement specification • Between end user and the system architect/developer • Design specification • Between the architect and the implementers • 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 user • Requirement specification • Between end user and the system architect/developer • Design specification • Between the architect and the implementers • Module specification • Between the implementer and the user of a module • Requirements, Specification and Design
5.1 The use of Specifications • A statement of user requirement • A statement of interface between the machine and the controlled environment • A statement of requirements for the implementation • A reference point during product maintenance.
5.2 Specification Quality • Clear, unambiguous and understandable • Consistency • Complete • Internally complete • Externally complete
5.3 Classification of Specification Styles • Formal, informal and Semiformal Specifications • Operational and descriptive specifications • Operational specifications: desired behavior • Descriptive specifications: desired properties
5.4 Verification of Specifications • Dynamic analysis • Static analysis • Formalism and verification • Simulation • Prototype • Verify all three aspects: • Functional • Consistency • completeness
5.5 Operational Specifications 5.5.1 Data Flow diagrams • Features • Example • limitations 5.5.2 UML Diagram for Specifying Behaviors 5.5.3 Finite State Machine: Describing Control Flow 5.5.4 Pretri Nets: Specifying Asynchronous Systems
5.5.1 Data Flow Diagram: Specifying Functions of Information Systems • Features • Describe systems as collections of functions that manipulate data • Can be expressed by means of graphical notation • Elements: Function symbol Input device symbol Output device symbol Data flow Data store symbol
5.5.1 DFD Example c d b a + * (a + b) * ( c + a * d) + *
5.5.1 DFD limitations • The semantics of the symbol is specified only by the identifiers chosen by the user. • Control aspects are not defined by the model A E D B F C
5.5.1 DFD Limitations • The semantics of the symbol is specified only by the identifiers chosen by the user. • Control aspects are not defined by the model A E D B F C
5.5.1 DFD Limitations • The semantics of the symbol is specified only by the identifiers chosen by the user. • Control aspects are not defined by the model A E D B F C
5.5 Operational Specifications 5.5.1 Data Flow diagrams 5.5.2 UML Diagram for Specifying Behaviors • Features • Example • Limitations 5.5.3 Finite State Machine: Describing Control Flow 5.5.4 Pretri Nets: Specifying Asynchronous Systems
5.5 Operational Specifications 5.5.1 Data Flow diagrams 5.5.2 UML Diagram for Specifying Behaviors 5.5.3 Finite State Machine: Describing Control Flow • Definiation • Features • Example • Limitations 5.5.4 Pretri Nets: Specifying Asynchronous Systems
5.5.3 Finite State Machines: Describing Control Flow • Definition A finite automata is a 5-tuple (Q, , , q0, F), where • Q is a finite set called the states, • is a finite set called the alphabet (inputs), • : Q Q is the transition function, • q0 Q is thestart state, and • F Q is theset of accept states (final states).
5.5.3 Finite State Machines: Describing Control Flow • Features • Formal notation • Suitable 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.
Push switch Push switch 5.5.3 Finite State Machines: Describing Control Flow • Example Off On
High-pressure alarm High-temperature alarm Restart 5.5.3 Finite State Machines: Describing Control Flow • Example: Chemical plant Off On
Temperature signal Pressure signal Unsuccessful recovery Successful recovery Successful recovery Unsuccessful recovery Pressure signal Temperature signal 5.5.3 Finite State Machines: Describing Control Flow • Example: Chemical plant Pressure Recovery Off Normal Temperature Recovery
5.5.3 Finite State Machines: Describing Control Flow • Limitations • Finite states: need assistance such as natural language or accompanied by action descriptions, like: Cooling_effort := k * (present_temperature – standard temperature) • Can’t describe concurrent, asynchronous systems. consume write C2 P2 C1 P1 read produce write write 1 2 0 full empty read read
5.5.3 FSM: Describing Control Flow write write <2,p1,c1> <0,p1,c1> <1,p1,c1> • Example continued: the Cartesian Product of the component state sets: consume consume consume Produce Produce Produce <0,p2,c1> <0,p2,c1> <1,p2,c1> <2,p1,c2> <0,p1,c2> <1,p1,c2> read read Produce read Produce Produce read write consume consume consume <2,p2,c2> <0,p2,c2> <1,p2,c2>
5.5.3 Finite State Machines: Describing Control Flow • Limitations: • 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*…Kn • FSM 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 diagrams 5.5.2 UML Diagram for Specifying Behaviors 5.5.3 Finite State Machine: Describing Control Flow 5.5.4 Pretri Nets: Specifying Asynchronous Systems • Definition • Example • Features • Limitations
5.5.4 Petri Nets: Specifying Asynchronous System • Definition A Petri Net is a quadruple (P, T, F, W), where • P is the finite set of places; • T is a finite set of transitions; • P T ; • F { P T} { T P} is the flow relation; and • W: 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 System • Example: p2 is the input place of transition write Transition p1 is the output place of transition write write Produce is the enabled, so transitionproducemayfire Place p2 p1 Token produce
5.5.4 Petri Nets: Specifying Asynchronous System • Example: p2 is the input place of transition write Transition p1 is the output place of transition write write Produce is the enabled, so transitionproducemayfire Place p2 p1 2 Token produce
5.5.4 Petri Nets: Specifying Asynchronous System • Example: After produce fired p2 is the input place of transition write Transition p1 is the output place of transition write write Now, write is the enabled, so transitionwritemayfire Place p2 p1 2 Token produce
5.5.4 PN: Specifying Asynchronous System write consume • Example: producer and consumer p2 c2 p1 c1 produce read read read 2 1 0 write write
5.5.4 PN: Specifying Asynchronous System consume c2 c1 • Example continued: producer and consumer: read read Now the system is at the state <0, p1, c1> 2 1 0 write write p2 p1 produce
5.5.4 PN: Specifying Asynchronous System consume c2 c1 • Example continued: producer and consumer: read read Now the system is at the state <0, p2, c1> 2 1 0 write write p2 p1 produce
5.5.4 PN: Specifying Asynchronous System consume c2 c1 • Example continued: producer and consumer: read read Now the system is at the state <1, p2, c1> 2 1 0 write write p2 p1 produce
5.5.4 Petri Nets: Specifying Asynchronous System • Features Good at describing concurrent and asynchronous system • Limitations • Tokens are anonymous • Can’t specify a selection policy • Can’t resolve deadlock or starving…
5.6 Descriptive Specifications 5.6.1 Entity Relationship (ER) Diagrams A semiformal notation 5.6.2 Logic Specification 5.6.3 Algebraic Specifications
5.6.1 Entity Relationship Diagrams NAME Entities: a collection of items that share common properties Relations: A set of pairs <a, b>, where a is an element of STUDENT and b is an element of CLASS Attribute: AGE STUDENT SEX ENROLLED_IN SUBJECT CLASS COURSE_ID MAX_ENROLLMENT
5.6.1 Entity Relationship Diagrams Relation Attributes: R B A A R B is one to one R A R B is one to many B A R B A A R B is many to one R B A A R B is many to many
Unified Modeling Language • A 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 Language • Static Structure (Descriptive) • Static view: class diagram • User Case View • Physical Views • Implementation view • Deployment view • Dynamic behavior (Operational) • Interaction view • Sequence diagram • Collaboration diagram • State machine view • Activity view
Unified Modeling Language • Static Structure (Operational) • Static View: class diagram • User Case View • Physical Views • Implementation view • Deployment view • Dynamic behavior (Descriptive) • Interaction view • Sequence diagram • Collaboration diagram • State machine view • Activity view
Class Class Diagram: attributes class-scope operation 1 association * generalization 1 multiplicities 0..1 0..1 1..* 3..6 1 Seat: Sting * 1 qualifier
Use Case Diagram: system actor buy tickets Clerk <<include>> buy subscription relationship <<include>> make charges Kiosk Credit card service Use case survey sales Supervisor
Unified Modeling Language • Static Structure (Operational) • Static View: class diagram • User Case View • Physical Views • Implementation view • Deployment view • Dynamic behavior (Descriptive) • Interaction view • Sequence diagram • Collaboration diagram • State machine view • Activity view
Request (count, performance) Show availability (seat-list) Select(seats) Demand payment(cost) Insert card(card number) charge(card number,cost)) authorized Print tickets (performance, seats) Eject card Sequence Diagram Active object credit card service box office Kiosk lifeline (active) message
1:request (count, performance) 4: offer(seat-list) 5:buy(seats) 8:confirm (seats, cost) 2: db := findDB(performance) Collaboration Diagram: active object Kiosk link 3: seat-list := lock(count) 6: claim (seats) passive object 7: unlock(seat-list) ticketseller Db: performanceDB <<local>>db transient link message multi object Db: performanceDB performanceGuide