Ch. 51 Specification. Ch. 52 Outline Discussion of the term "specification" Types of specifications –operational Data Flow Diagrams (Some) UML diagrams.

Slides:



Advertisements
Similar presentations
Chapter 7 System Models.
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Software Requirements Engineering
Software Engineering COMP 201
Introduction To System Analysis and Design
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
The Unified Software Development Process - Workflows Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
© 2005 Prentice Hall3-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Lecture 6 & 7 System Models.
Software Requirements
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Ch5: Software Specification. 1 Overview  Use of specifications  Specification qualities  Classification of specification styles  Verification of specifications.
S R S S ystem R equirements S pecification Specifying the Specifications.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System modeling 1.
Chapter 7: The Object-Oriented Approach to Requirements
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach.
Software Engineering 8. System Models.
Introduction To System Analysis and design
Functional Modeling Joseph Valacich, Joey George and Jeff Hoffer, Essentials of System Analysis and Design, 4 th edition, Prentice Hall, 2009.
Chapter 5: Specification Yuanfang Cai CS751 Jan 29, 2003.
Data Flow Diagrams.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System Models Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn Lecture 6 & 7.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 Object-oriented and Structured System Models.
Approaching a Problem Where do we start? How do we proceed?
Chapter 7 System models.
Slide 1 System models. Slide 2 Objectives l To explain why the context of a system should be modelled as part of the RE process l To describe behavioural.
System models l Abstract descriptions of systems whose requirements are being analysed.
Pertemuan 19 PEMODELAN SISTEM Matakuliah: D0174/ Pemodelan Sistem dan Simulasi Tahun: Tahun 2009.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4 th edition, Prentice Hall, Hans Van Vliet, Software.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
1 Introduction to Software Engineering Lecture 1.
1 Specification Some slides for Chapter 5 Of Ghezzi, Jazayeri, and Mandrioli.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Requirements Engineering Methods for Requirements Engineering Lecture-30.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
Ch. 51 Specification. Ch. 52 Outline Discussion of the term "specification" Types of specifications –operational Data Flow Diagrams (Some) UML diagrams.
Requirements Specification. Welcome to Software Engineering: “Requirements Specification” “Requirements Specification”  Verb?  Noun?  “Specification”
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
Requirements Engineering-Based Conceptual Modelling From: Requirements Engineering E. Insfran, O. Pastor and R. Wieringa Presented by Chin-Yi Tsai.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Functional Modeling Joseph Valacich, Joey George and Jeff Hoffer, Essentials of System Analysis and Design, 4 th edition, Prentice Hall, 2009.
Winter 2007SEG2101 Chapter 31 Chapter 3 Requirements Specifications.
Capturing Requirements. Questions to Ask about Requirements 1)Are the requirements correct? 2)Consistent? 3)Unambiguous? 4)Complete? 5)Feasible? 6)Relevant?
Requirement Analysis SOFTWARE ENGINEERING. What are Requirements? Expression of desired behavior Deals with objects or entities, the states they can be.
1 Specification A broad term that means definition Used at different stages of software development for different purposes Generally, a statement of agreement.
 To explain why the context of a system should be modelled as part of the RE process  To describe behavioural modelling, data modelling and object modelling.
1 CEN 4020 Software Engineering PPT4: Requirement analysis.
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4 th edition, Prentice Hall, Hans Van Vliet, Software.
Introduction to Software Engineering 1. Software Engineering Failures – Complexity – Change 2. What is Software Engineering? – Using engineering approaches.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini VII. System Specification (I)
Engineering, 7th edition. Chapter 8 Slide 1 System models.
Object-oriented and Structured System Models
Requirements Engineering (continued)
Structured Analysis and Dataflow Diagrams
Abstract descriptions of systems whose requirements are being analysed
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4th edition, Prentice Hall, Hans Van Vliet, Software Engineering:
Presentation transcript:

Ch. 51 Specification

Ch. 52 Outline Discussion of the term "specification" Types of specifications –operational Data Flow Diagrams (Some) UML diagrams Finite State Machines Petri Nets –descriptive Entity Relationship Diagrams Logic-based notations Algebraic notations Languages for modular specifications –Statecharts –Z

Ch. 53 Specification A broad term that means definition Used at different stages of software development for different purposes Generally, a statement of agreement (contract) between –producer and consumer of a service –implementer and user All desirable qualities must be specified

Ch. 54 Uses of specification Statement of user requirements –major failures occur because of misunderstandings between the producer and the user –"The hardest single part of building a softwarem system is deciding precisely what to build" (F. Brooks)

Ch. 55 Uses of specification (cont.) Statement of the interface between the machine and the controlled environment –serious undesirable effects can result due to misunderstandings between software engineers and domain experts about the phenomena affecting the control function to be implemented by software

Ch. 56 Uses of specification (cont.) Statement of requirements for implementation –design process is a chain of specification (i.e., definition)–implementation–verification steps requirements specification refers to definition of external behavior –design specification must be verified against it design specification refers to definition of the software architecture –code must be verified against it

Ch. 57 Uses of specification (cont.) A reference point during maintenance –corrective maintenance only changes implementation –adaptive and perfective maintenance occur because of requirements changes requirements specification must change accordingly

Ch. 58 Specification qualities Precise, clear, unambiguous Consistent Complete –internal completeness –external completeness Incremental

Ch. 59 Clear, unambiguous, understandable Example: specification fragment for a word-processor Selecting is the process of designating areas of the document that you want to work on. Most editing and formatting actions require two steps: first you select what you want to work on, such as text or graphics; then you initiate the appropriate action. can an area be scattered?

Ch. 510 Precise, unambiguous, clear Another example (from a real safety- critical system) The message must be triplicated. The three copies must be forwarded through three different physical channels. The receiver accepts the message on the basis of a two-out-of-three voting policy. can a message be accepted as soon as we receive 2 out of 3 identical copies of message or do we need to wait for receipt of the 3 rd ?

Ch. 511 Consistent Example: specification fragment for a word-processor The whole text should be kept in lines of equal length. The length is specified by the user. Unless the user gives an explicit hyphenation command, a carriage return should occur only at the end of a word. What if the length of a word exceeds the length of the line?

Ch. 512 Complete Internal completeness –the specification must define any new concept or terminology that it uses glossary helpful for this purpose –the specification must document all the needed requirements difficulty: when should one stop?

Ch. 513 Incremental Referring to the specification process –start from a sketchy document and progressively add details Referring to the specification document –document is structured and can be understood in increments

Ch. 514 Classification of specification styles Informal, semi-formal, formal Operational –Behavior specification in terms of some abstract machine Descriptive –Behavior described in terms of properties

Ch. 515 Example 1 Specification of a geometric figure E: E can be drawn as follows: 1.Select two points P1 and P2 on a plane 2.Get a string of a certain length and fix its ends to P1 and P2 3.Position a pencil as shown in next figure 4.Move the pen clockwise, keeping the string tightly stretched, until you reach the point where you started drawing this is an operational specification

Ch. 516

Ch. 517 A descriptive specification Geometric figure E is describe by the following equation ax2 + by2 + c = 0 where a, b, and c are suitable constants

Ch. 518 How to verify a specification? “Observe” dynamic behavior of specified system (simulation, prototyping, “testing” specs) Analyze properties of the specified system Analogy with traditional engineering –physical model of a bridge –mathematical model of a bridge

Ch. 519 Data Flow Diagrams (DFDs) A semi-formal operational specification System viewed as collection of data manipulated by “functions” Data can be persistent –they are stored in data repositories Data can flow –they are represented by data flows DFDs have a graphical notation

Ch. 520 Graphical notation –bubbles represent functions –arcs represent data flows –open boxes represent persistent store –closed boxes represent I/O interaction

Ch. 521 Example specifies evaluation of (a + b) * (c + a * d)

Ch. 522 A construction “method” (1) 1. Start from the “context” diagram

Ch. 523 A construction “method” (2) 2. Proceed by refinements until you reach “elementary” functions (preserve balancing)

Ch. 524 A library example

Ch. 525 Refinement of “Get a book”

Ch. 526 Patient monitoring systems The purpose is to monitor the patients’ vital factors--blood, pressure, temperature, …--reading them at specified frequencies from analog devices and storing readings in a DB. If readings fall outside the range specified for patient or device fails an alarm must be sent to a nurse. The system also provides reports.

Ch. 527 A refinement

Ch. 528 More refinement

Ch. 529 An evaluation of DFDs (1) Easy to read, but … Informal semantics –How to define leaf functions? –Inherent ambiguities Outputs from A, B, C are all needed? Outputs for E and F are produced at the same time?

Ch. 530 An evaluation of DFDs (2) Control information is absent Possible interpretations: (a)A produces datum, waits until B consumes it (b)B can read the datum many times without consuming it (c)a pipe is inserted between A and B

Ch. 531 UML use-case diagrams Define functions on basis of actors and actions borrow book return book library update librarian customer

Ch. 532 UML sequence diagrams Describe how objects interact by exchanging messages Provide a dynamic view

Ch. 533 UML collaboration diagrams Give object interactions and their order Equivalent to sequence diagrams

Ch. 534 Finite state machines (FSMs) Can specify control flow aspects Defined as a finite set of states, Q; a finite set of inputs, I; a transition function d : Q x I  Q (d can be a partial function)

Ch. 535 Example: a lamp

Ch. 536 Another example: a plant control system

Ch. 537 A refinement

Ch. 538 Classes of FSMs Deterministic/nondeterministic FSMs as recognizers –introduce final states FSMs as transducers –introduce set of outputs...

Ch. 539 Declarative specifications ER diagrams: semiformal specs Logic specifications Algebraic specifications

Ch. 540 ER diagrams Often used as a complement to DFD to describe conceptual data models Based on entities, relationships, attributes They are the ancestors of class diagrams in UML

Ch. 541 Example

Ch. 542 Relations Relations can be partial They can be annotated to define –one to one –one to many –many to one –many to many

Ch. 543 Logic specifications Examples of first-order theory (FOT) formulas: x > y and y > z implies x > z x = y  y = x for all x, y, z (x > y and y > z implies x > z) x + 1 < x – 1 for all x (exists y (y = x + z)) x > 3 or x < -6

Ch. 544 Example of views document production data flow view (1)

Ch. 545 Control flow view (2)

Ch. 546 Conclusions (1) Specifications describe –what the users need from a system (requirements specification) –the design of a software system (design and architecture specification) –the features offered by a system (functional specification) –the performance characteristics of a system (performance specification) –the external behavior of a module (module interface specification) –the internal structure of a module (internal structural specification)

Ch. 547 Conclusions (2) Descriptions are given via suitable notations –There is no “ideal” notation They must be modular They support communication and interaction between designers and users