Tool Support for Design Inspection: Automatic Generation of Questions

Size: px
Start display at page:

Download "Tool Support for Design Inspection: Automatic Generation of Questions"

Transcription

1 Tool Support for Design Inspection: Automatic Generation of Questions Tim Heyer Department of Computer and Information Science, Linköping University, S Linköping, Contents 1. Introduction 2 2. Question Generation (Semantics) The Meaning and Scope of Assertions The Treatment of Use-Cases The Treatment of Sequence Diagrams Example The Use-Case Diagram The Sequence Diagrams The Class Diagrams Question Generation Summary 14 A. Assertions 15 B. Questions 18 1

2 1. Introduction The project Tool Support for Design Inspection was commenced in April The project is supported by the Swedish National Board for Industrial and Technical Development (NUTEK). The project is carried out in cooperation between Ericsson Softlab AB and the Department of Computer and Information Science at Linköpings Universitet. The objective of the project is to develop design principles and tools to support the systematic inspection of software designs expressed in the Unified Modeling Language (UML). The primary goals are: 1. To identify verifiable properties of software developed within the telecommunications industry. 2. To develop and to define a design notation based on the UML 1.3 [1]. The design notation has to be formally definable. 3. To develop and to define a specification notation based on UML. The specification notation has to be formally definable with the exception of natural language predicate definitions as introduced in [2]. 4. To develop methods to automatically generate a set of questions that is appropriate to ensure the specified properties of the software system. The questions are to be answered during design inspection. We are aiming at providing practical means for the inspection of software designs. We assume that software is developed in a way similar to that given by the Unified Software Development Process (USDP) that is described e.g. in [6]. In earlier reports [4, 5] we presented the design notation (item 2 above) and the specification notation (item 3 above). This report is concerned only with item 4 above and to understand it knowledge of the previous reports is necessary, i.e. this report is not self-contained. In the report at hand, we describe how a set of questions can be automatically generated given a specification and a design in the notations introduced earlier. In Sect. 2 we describe what properties we intend to verify and how the conditions (i.e. questions) which are necessary to establish that the properties are indeed satisfied may be generated. Section 3 contains the description of a small example taken from the telecommunications domain. The section introduces the example and the generation of questions. Finally, we summarize in Sect Question Generation (Semantics) In this section we describe the rules for how the questions to be answered during the inspection can be generated given a specification and a design as introduced in [5, 4]. However, before starting with the details we explain in general terms what properties of the design we attempt to verify during the inspection, i.e. what properties are covered by the automatically generated questions. 2

3 Common to approaches to formal verification is the aim to prove that the design, implementation etc. is correct with respect to the specification. Usually, the intention is to prove that the final state of the system satisfies a certain postcondition provided that the initial state satisfies a certain precondition. In our approach the behavior of the system is specified by a set of use-cases and corresponding pre- and postconditions. The system is correct if the execution of each use-case in a state that satisfies the precondition ends in a state that satisfies the postcondition. That is, what we would like to verify corresponds to arrow 1 in Fig. 1. (1) Use-case Precondition Use-case Postcondition (3) (4) Sequence Preconditions Sequence Postconditions (2) Figure 1: Verification model However, to verify the effects of a use-case on the state have to be completely and formally defined. In the USDP each use-case is specified in more detail by a set of sequence diagrams. The sequence diagrams together with the class diagrams form the design. In our approach each sequence diagram comes with corresponding pre- and postconditions. A sequence diagram is correct if its execution in a state that satisfies the precondition ends in a state that satisfies the postcondition (arrow 2 in Fig. 1). This we can verify since a sequence diagram in our approach contains enough detail (expressed in intermediate assertions, operation pre- and postconditions, etc.). If we finally verify that each use-case precondition implies the disjunction of the corresponding sequence preconditions (arrow 3 in Fig. 1) and that each sequence postcondition implies the corresponding use-case postcondition (arrow 4 in Fig. 1) we have achieved our original goal to verify that the system behaves as specified. To verify the last proposition is straight forward. However, to verify the preceding proposition is not that simple: it requires that the set of all sequence diagrams belonging to a use-case describe all possible execution sequences for that use-case. We consider that very hard and 3

4 seldom desirable. We are aiming at the development of practical means for the inspection of designs and our belief is that the verification of critical properties of particularly important uses of the system is sufficient with respect to costs and benefits. It is here where our approach differs in an important way from other approaches. We verify that if the execution of each sequence starts in a state that satisfies the sequence precondition then it ends in a state that satisfies the corresponding use-case postcondition The Meaning and Scope of Assertions We first explain (define) the meaning and the visibility rules for the different assertions. The possible assertions and their scope are: Use-case pre- and postcondition. A use-case precondition specifies a condition that is supposed to be satisfied prior to the execution of the use-case. A postcondition on the other hand specifies a condition that has to be satisfied after the execution of the use-case. The pre- and postcondition can refer to actors, the system, and possible input and output to the use-case. Sequence pre- and postcondition. A sequence precondition specifies a condition that is supposed to be satisfied prior to the execution of the sequence. Accordingly, a postcondition specifies a condition that has to be satisfied after the execution of the sequence. Both assertions may refer to the state of all objects which appear in the sequence diagram. Intermediate assertions. These assertions specify the state changes of an object between receptions and/or dispatches of messages. The assertions are assigned to the activation of a particular object. The assertions can refer to the state of the object itself. Moreover, the input, i.e. the data that is conveyed by messages, can be used (if applicable). If the intermediate assertions appear inside an loop they can also refer to the iterator variable. Loop invariants. Loop invariants specify a condition that is maintained by an loop, i.e. a condition that has to be satisfied prior to the first iteration and that is reestablished after each iteration over a continuous part of a sequence diagram. The scope of the loop is represented graphically by a box over all lifelines in the sequence diagram. The assertion can refer to the state of all objects which are included in the box. Moreover, the iterator variable that is defined for the loop can be used. Operation pre- and postconditions. A operation precondition specifies a condition that is supposed to be satisfied prior to the execution of the operation. A postcondition specifies a condition that has to be satisfied after the execution of the operation. Both assertions can refer to the state of the object and arguments to the operation (if available). Class invariants. These assertions specify a condition that is maintained by each instance of the class. That is, it is assumed that the assertion is satisfied prior to 4

5 each invocation of the object and it has to be satisfied after each invocation of the object. The class invariant may refer to the state of the instance of the class. The visibility rules are reflected by the nesting of context environments as presented in a previous report (see [5]). The scope for the various types of assertions is illustrated in Fig. 2. Class assertions Class Class invariant Operation pre-/postconditions... Use-case assertions Use-case Use-case pre-/postcondition Sequence Sequence pre-/postcondition Object Intermediate assertions Loop Loop invariants Object Intermediate assertions Figure 2: The scope of specification elements 2.2. The Treatment of Use-Cases As mentioned, every use-case and every sequence diagram is in our approach accompanied by a matching pre- and postcondition. For use-case preconditions we would like to verify that they imply the disjunction of all corresponding sequence diagrams. However, as explained in the introduction to Sect. 2 (on p. 3) this is impractical. For use-case postconditions we verify that it is implied by every sequence postcondition of associated sequence diagrams. That is, we generate questions that have to be answered positively to establish that implication The Treatment of Sequence Diagrams A sequence diagram describes a set of similar execution sequences associated with a particular use of the system (as expressed in a use-case diagram). Each sequence diagram is accompanied by a pre- and a postcondition. We can assume that the precondition is initially satisfied and we try to verify that the postcondition is finally satisfied. That is, we generate questions that have to be answered positively to establish the satisfaction of the sequence postcondition. The general appearance of sequence diagrams has been 5

6 described in a previous report [4]. The elements that need further explanation here are activations, messages (i.e. operation invocations and events), and loops Activations Activations indicate that the object to which they belong is performing some computation. We divide each activation of an object into one or more activation segments. An activation segments starts and ends at a breaking point where the object receives or dispatches a message, where a loop starts or ends, or where the activation itself starts or ends. Each activation segment can be accompanied by an intermediate assertion (if it is not provided it is assumed to be true ). Intermediate assertions specify the state changes of an object between two subsequent breaking points. These assertions have a character similar to that of use-case and sequence preconditions, i.e. they do not need to be verified but are assumed to be satisfied Messages The communication between objects in a sequence diagram is expressed with the dispatch and reception of messages. In our approach messages can be of two different kinds: either they are operation invocations or they are events. Operation Invocations. We define operation invocations to be synchronous. The dispatching object (called caller) stops its execution (i.e. its activation ends at the point of message dispatch) and it waits for the invoked operation (provided by an object, called callee) to terminate. Then it continues its execution. Every operation is accompanied by a pre- and a postcondition provided as part of the class description in the class diagram. The focus of our work is on the verification/inspection of designs. At such an early stage of development little is known of the implementation of operations. Operation pre- and postconditions and class invariants form a contract between the callee and the caller. It is up to the caller to ensure that the precondition is satisfied and it is then up to the callee to ensure that the postcondition and class invariant is satisfied. The verification that a callee actually fulfills its part of the contract has to be postponed to a later stage in the development when it is known how the callee works. How this could be done has been described in our previous work [3]. For the design inspection it is assumed that the later realizations of objects are such that they fulfill their part of the contract. What has to be verified in the case of operation invocations is that the precondition is indeed satisfied prior to the dispatch of the message. That is, we generate questions that have to be answered positively to establish the satisfaction of the preconditions. After the termination of the operation the caller assumes that the postcondition is satisfied, i.e. no question have to be generated in that case. Events. Events (or signals) are by definition always asynchronous. We assume that no events are lost but that they all reach the receiver. At the receiver the events are buffered and the receiver is free to pick events when it wishes. Thus, an event has no 6

7 immediate influence on the state. Events can be dispatched and received in various states of the system and it is therefore rather difficult to express the effects of an event on the state of the receiver as a logical condition (postcondition). Moreover, there is no natural ending of the handling of an event by a receiver. Of course an event eventually influences the state of the receiver. Instead of specifying the effects on the state in a general manner as a postcondition we suggest the effects to be specified in the sequence diagram for exactly that particular situation or trace as an intermediate assertion (see p. 4). No questions are generated to verify the intermediate assertions. It is assumed that the object establishes the assertion. Intermediate assertions are used to generate other questions, e.g. the questions for the maintenance of loop invariants. To verify intermediate assertions is part of the code inspection Loops (or Iterations) In our approach a loop is accompanied by an iterator, its initial value, a description of how the iterator changes during each iteration, a guard, and a loop invariant. An iterator is a variable (e.g. an integer variable i). The variable has an initial value (e.g. 0) and changes during each iteration in a specific way (e.g. i = i + 1). The guard specifies a condition for when to continue iterating (e.g. i < N). Finally, the invariant specifies a condition that is maintained by the loop. To verify a loop various questions need to be generated: 1. Questions that have to be answered positively to verify that the invariant is initially satisfied. This is done by replacing all occurrences of the iterator in the invariant with its initial value. This condition then must be a consequence of what is already known at the time immediately before the first iteration. 2. Questions that have to be answered positively to verify that the invariant is indeed an invariant. In this case all occurrences of the iterator in the invariant are replaced with the updated (increased) iterator. Other variables are replaced too if they changed during the iteration. This condition then must be a consequence of the invariant and the guard. Finally, it is assumed that the invariant and the negation of the guard is satisfied after the termination of the loop Question Generation The generation of questions is performed from the bottom to the top. For every sequence diagram and every use-case questions need to be generated to verify the following: For every operation invocation it has to be verified that the operation precondition is satisfied. For every sequence diagram it has to be verified that the sequence postcondition is satisfied. 7

8 For every loop it has to be verified that the loop invariant is initially satisfied (i.e. the invariant has to be satisfied prior to the first iteration). For every loop it has to be verified that the loop invariant is maintained (i.e. that the invariant is satisfied after each iteration). To verify the above conditions, i.e. to generate the questions, we can rely on the following assumptions: Immediately before each execution of the body of any loop the loop invariant and the guard are satisfied. Immediately after the final execution of any loop the loop invariant and the negation of the guard are satisfied. At the end of every activation segment the associated intermediate assertion is satisfied. After the return from an operation invocation (and at the end of the corresponding activation segment) the operation postcondition is satisfied. After the termination of any operation the class invariant of the corresponding object is satisfied. In principle, one question is generated for each of the conditions that has to be verified. The resulting set of questions is the complete set of questions to be answered during the design inspection. A single question consists of a premise and a conclusion, i.e. it is of the form: assume that the following conditions x are satisfied, is then the following condition y satisfied, too? The conditions are concerned with the state of the entities in a sequence diagram. The state is captured in variables used in the assertions (and the sequence diagram). The premise of a question expresses everything that is known up to the point when the conclusion was reached. This knowledge may concern variables at different points during the execution. It is essential that these different points in time can be distinguished during the inspection. Therefore, variables in the questions may be followed by a hash sign (#) and a number n. The notation x#n refers to the value of the variable x at some time n. That is, two occurrences of x#n always denote the same value, while x#m may differ from x#n when m n. 1 Questions are generated in the following manner: 1. The premise of a question is initially empty (i.e. true) and the conclusion is set to the assertion to be verified. For every variable v that occurs in any assertion in the sequence diagram a counter c v is introduced. All counters are initialized to 1. 1 Instead of generating these numbers, later tool implementations may allow to specify meaningful temporal variable names directly in the sequence diagram. Moreover, the generated names might not actually appear in the question as it is presented they could be made distinguishable by other, e.g. graphical, means. 8

9 Moreover, we introduce a bag of lifelines with a lifeline tag each. The tags are used to remember how far the generation of the question has come. The generation is complete if all tags reached the top of their lifeline. The bag contains initially only the lifelines that are in the scope of the assertion, i.e. normally only one except for loop invariants and sequence postconditions. The tags are set to the end of the activation segments where the assertion occurs. Then, starting from the point where the condition to be verified occurs, all prior assertions that are known to be satisfied (see above) are successively added to the premise: 2. All occurrences of all variables v referring to initial values (indicated by the are replaced by the same variable with the appendix #c v. That is, the initial values of all variables are replaced by the actual values of the same variables immediately before the assertion. Naturally, these values are the same but their representation is different. All counters of variables that have just been replaced are increased by one. 3. For each lifeline in the bag the assertion prior to the one indicated by the lifelines tag is added to the top of the premise and the tag is moved up to that assertion. If between the current and the next prior assertion a message is received then the lifeline of the object that dispatched the message is added to the bag and the corresponding lifeline tag is set to the point of the message dispatch. If the tag of every lifeline in the bag is set to the sequence precondition, then finish, otherwise continue with 2. Simplification of the questions is sometimes possible. A straight forward simplification is the removal of duplicates in the premise. Also, arithmetical simplifications may be possible. If the conclusion of a question is contained in the premise the question can be removed altogether. 3. Example In this section we are going to describe by means of a simple example, what the specification, the design, and the generated questions to be asked during design inspection may look like. Complete lists of the assertions (i.e. use-case pre- and postconditions, class invariants, intermediate assertions etc.) and the questions can be found in App. A on page 15 and B on page 18. The example is part of a larger system, namely a GSM Base Transceiver Station (BTS). Such a BTS is an important part of the mobile telephone system. It mediates between the mobile telephones in its cell and the telephone network. The example introduced in the section at hand is a small part of the protocol that may be used by the BTS to communicate with the telephone network. 9

10 3.1. The Use-Case Diagram In this example we are looking at a single use-case. The use-case describes a particular use of the system. Here the use-case describes the sending of a single message from a sender to a receiver over a given connection between the two. The use-case diagram that describes this case is called linkcontrol. The diagram contains two actors of the class LinkUser: one is called sender and the other is called receiver. The use-case is called msgsend. The diagram is shown in Fig. 3. msgsend Sender :LinkUser Receiver :LinkUser linkcontrol Figure 3: Use-case diagram A use-case is accompanied by a precondition and a postcondition. For the given use-case msgsend the precondition and postcondition could be formulated as follows: requires informally Both the "sender" and "receiver" are connected to the system. end requires; msgsend ensures informally The message has correctly and completely been transfered from the "sender" to the "receiver". end ensures; It should be noted that an implementation of a tool for supported design inspection would allow the assertions, e.g. the use-case postcondition, to be attached to and stored with the use-case diagram itself The Sequence Diagrams Sequence diagrams are part of the design and describe a single execution trace (or a set of traces) of a use-case. In this simple example we are looking at one sequence diagram only, namely the sequence diagram for the normal operation of the use-case msgsend. Consequently the diagram is called linkcontrol.msgsend.normaloperation. It can be found in Fig. 4 on the following page. The sequence diagram shows how the message is broken up into a set of segments in the object sendobj. Next all the segments are transfered via the object channel 10

11 sendobj channel receiveobj Sender :LinkUser :LinkSender :L2Channel :LinkReceiver Receiver :LinkUser 1:evSendMsg(msg) 2:segment(msg) sendloop i:=0 while i<n i:=i+1 3:evSendMsg(seg[i]) 4:evConveyMsg(seg[i]) 5:evSendAck(ack[i]) 6:evConveyAck(ack[i]) 7:assemble(msg) 8:evGotMsg(msg) linkcontrol.msgsend.normaloperation Figure 4: Sequence diagram 11

12 to the object receiveobj. The receiveobj acknowledges each segment by sending an acknowledgment back to the sendobj (via the object channel). A sequence diagram is annotated with a set of so called intermediate assertions that specify the change in the state of objects between dispatches and receptions of messages. For instance a intermediate assertion that specifies the state change in the object channel in between the reception of evsendmsg and the dispatch of evconveymsg could be: establishes transmittingseg( channel, channel@pre, i, sendobj@pre ) end establishes; The above predicate transmittingseg could be formally or informally defined. An informal definition may look as follows: define transmittingseg( channel2, channel1, i, sender ) informally "channel2" is the same as "channel1" except that it now carries segment "i" from "sender". Moreover the loop sendloop of the sequence diagram is annotated with assertions i.e. a loop invariant. A loop invariant specifies a condition that is maintained by the loop, i.e. which is satisfied before and after each execution of the loop. For the sequence diagram at hand, the loop invariant could look as follows: sendloop maintains 0 <= i and arrived( receiveobj, receiveobj@pre, i, sendobj@pre ) and acknowledged( sendobj, sendobj@pre, i, receiveobj ) end maintains; The loop invariant expresses that the object sendobj and the object receiveobj are the same as prior to the execution of the loop except that the first i segments have been sent, received, and acknowledged. The predicates used above would be informally or formally defined as e.g. in App. A on page The Class Diagrams In the sequence diagram it can be seen that three types of objects (i.e. classes) are involved LinkSender, L2Channel, and LinkReceiver. The relationships between the classes and their operations are depicted in the class diagram shown in Fig. 5 on the following page. As for the other two types of diagrams, the class diagram is annotated with assertions, i.e. class invariants, preconditions, and postconditions. For instance for the operation segment of class LinkSender the following postcondition could be given: 2 As presented in a previous report, behind channel indicates that the initial state of the variable as seen from the current activation is referred. That is channel@pre refers to the state of channel immediately after the reception of message 3. 12

13 LinkUser LinkSender L2Channel LinkReceiver segment( m:message ) assemble( m:message ) Figure 5: Class diagram linkcontrol segment ensures segmented( self, self@pre, msg, N ) end ensures; An informal definition of the predicate segmented could look as follows: define segmented( sender2, sender1, msg, N ) informally "sender2" is the same as "sender1" except that it contains the "N" segments that "msg" has been broken up into. The operation preconditions and operation postconditions for all classes can be found in App. A on page 15. In the example at hand we do not need to specify any class invariants Question Generation For the design (as outlined in the previous section) to be correct with respect to the specification a number of conditions must be satisfied. These conditions constitute the questions to be asked (and answered) during the design inspection. In principle the questions check whether the requirements for operation and loop invocations are satisfied (i.e. operation pre- and postconditions and loop invariants) and whether the desired outcomes are established (i.e. use-case and sequence postconditions and loop invariants). For the case at hand we would expect questions for the following problems: 1. Does the sequence diagram postcondition imply the use-case postcondition? 2. Is the precondition of segment satisfied? 13

14 3. Is the loop invariant of sendloop satisfied? 4. Is the loop invariant of sendloop maintained? 5. Is the postcondition of normaloperation established? For each of the problems above a concrete question is generated. For instance the concrete question for Item 1, i.e. the question whether the sequence diagram postcondition implies the use-case postcondition, could look as follows: Suppose: samemessage( sender.msg@pre, receiver.msg ) Then: The message has correctly and completely been transfered from the "sender" to the "receiver". The design inspection team then would have to examine and to answer the question. The idea is that all questions must be answered with yes for the design to be correct with respect to the specification. 3 The complete set of possible question can be found in App. B on page 18. We generally refer to the set of questions as the set of possible question, because the questions may differ with respect to the assertions and also because the questions may be simplified to some extend. For instance some arithmetic expressions could be simplified and if a condition appears both in the Suppose - and the Then - part then it could be removed from the Then -part. The questions shown in the appendix are not simplified at all. Like assertions, also the presentation of the questions could be supported by a design inspection tool. For instance it would be possible to highlight the parts of the model (both of the specification and the design) that have been used to generate the current question. Moreover it would be possible to automatically annotate the model with temporary variables that might occur in the questions. 4. Summary The report at hand describes a first approximation of the automatic generation of questions to be answered during design inspection. The questions are generated given a design expressed in the design notation presented in [4] and a specification presented in [5]. The report will be extended in forthcoming revisions. In particular, synchronization points could be introduced in the sequence diagram. That is, points where the state of the whole system is explicitly specified as an assertion. 3 Of course it might be a good idea to negate some of the questions so that no is the desired answer just to keep the team alerted. 14

15 References [1] OMG Unified Modeling Language Specification 1.3, June [2] S. Bonnier and T. Heyer. COMPASS: A comprehensible assertion method. In TAP- SOFT 97: Theory and Practice of Software Development, pages Springer- Verlag, [3] T. Heyer. COMPASS: Introduction of Formal Methods in Code Development and Inspection. Licentiate thesis, Department of Information and Computer Science, Linköping University, Apr LiU-Tek-Lic 1998:30. [4] T. Heyer. Tool support for design inspection: A design notation. Project report, Department of Information and Computer Science, Linköping University, [5] T. Heyer. Tool support for design inspection: A specification notation. Project report, Department of Information and Computer Science, Linköping University, [6] I. Jacobson, G. Booch, and J. Rumbaugh. The Unified Software Development Process. Addison Wesley, A. Assertions context Use-Case-Diagram linkcontrol context Use-Case msgsend requires informally Both the "sender" and "receiver" are connected to the system. end requires; ensures informally The message has correctly and completely been transfered from the "sender" to the "receiver". end ensures; context Sequence normaloperation requires validmessage( sender.msg@pre ) and connected( sendobj@pre, channel@pre, receiveobj@pre ) end requires; ensures samemessage( sender.msg@pre, receiver.msg ) end ensures; 15

16 define connected( sendobj, channel, receiveobj ) informally "sendobj" is via "channel" connected to "receiveobj". The connection is full duplex and no transmission errors can occur. define samemessage( msg1, msg2 ) "msg1" is the same as "msg2", i.e. the two objects have the same state. context Loop sendloop maintains 0 <= i and arrived( receiveobj, receiveobj@pre, i, sendobj@pre ) and acknowledged( sendobj, sendobj@pre, i, receiveobj ) end maintains; define arrived( receiver2, receiver1, i, sender ) informally "receiver2" is the same as "receiver1" except that the first "i" segments have been correctly received from "sender". define acknowledged( sender2, sender1, i, receiver ) informally "sender2" is the same as "sender1" except that the first "i" segments have been acknowledged by "receiver". context Object channel 3-4 establishes transmittingseg( channel, channel@pre, i, sendobj@pre ) end establishes; define transmittingseg( channel2, channel1, i, sender ) informally "channel2" is the same as "channel1" except that it now carries segment "i" from "sender". 5-6 establishes transmittingack( channel, channel@pre, i, receiver@pre ) end establishes; define transmittingack( channel2, channel1, i, receiver ) 16

17 informally "channel2" is the same as "channel1" except that it now carries acknowledgment "i" from "receiver". end context Object channel; context Object receiveobj 4-5 establishes receivedseg( receiver, i, ) end establishes; define receivedseg( receiver2, receiver1, i, channel ) informally "receiver2" is the same as "receiver1" except that it has received a segment "i" from "channel". end context Object receiveobj; context Object sendobj 6-sendLoop.end establishes receivedack( sendobj, sendobj@pre, i, channel@pre ) end establishes; define receivedack( sender2, sender1, i, channel ) informally "sender2" is the same as "sender1" except that it has received an acknowledgment for segment "i" from "channel". end context Object sendobj; end context Loop sendloop; end context Sequence normaloperation; end context Use-Case msgsend end context Use-Case-Diagram linkcontrol; context Class-Diagram linkcontrol context Class LinkSender 17

18 segment requires validmessage( ) end requires; define validmessage( msg ) informally "msg" is a valid message as defined by the communications protocol. segment ensures segmented( self, self@pre, msg, N ) end ensures; define segmented( sender2, sender1, msg, N ) informally "sender2" is the same as "sender1" except that it contains the "N" segments that "msg" has been broken up into. end context Class LinkSender; context Class LinkReceiver assemble ensures assembled( self, msg ) end ensures; define assembled( receiver, msg ) informally The segments stored in "receiver" are assembled into "msg". end context Class LinkReceiver; end context Class-Diagram linkcontrol; B. Questions Question: Does the sequence diagram postcondition imply the use-case postcondition? Suppose: samemessage( sender.msg@pre, receiver.msg ) Then: The message has correctly and completely been transfered from the "sender" to the "receiver". Question: Is the precondition of "segment" satisfied? Suppose: 18

19 validmessage( ) connected( channel@pre, ) Then: validmessage( ) Question: Is the loop invariant of "sendloop" satisfied? Suppose: validmessage( ) connected( channel@pre, ) segmented( sendobj#1, msg, N ) Then: 0 <= 0 and arrived( receiveobj@pre, receiveobj@pre, 0, sendobj#1 ) and acknowledged( sendobj#1, sendobj#1, 0, receiveobj@pre ) Question: Is the loop invariant of "sendloop" maintained? Suppose: validmessage( sender.msg@pre ) connected( sendobj@pre, channel@pre, receiveobj@pre ) segmented( sendobj#1, sendobj@pre, msg, N ) i < N 0 <= i arrived( receiveobj#1, receiveobj@pre, i, sendobj#1 ) acknowledged( sendobj#2, sendobj#1, i, receiveobj#1 ) transmittingseg( channel#2, channel#1, i, sendobj#2 ) receivedseg( receiveobj#2, receiveobj#1, i, channel#2 ) transmittingack( channel#3, channel#2, i, receiveobj#2 ) receivedack( sendobj#3, sendobj#2, i, channel#3 ) Then: 0 <= i+1 arrived( receiveobj#3, receiveobj@pre, i+1, sendobj@pre ) acknowledged( sendobj#3, sendobj#1, i+1, receiveobj#1 ) Question: Is the postcondition of "normaloperation" established? Suppose: validmessage( sender.msg@pre ) connected( sendobj@pre, channel@pre, receiveobj@pre ) segmented( sendobj#1, sendobj@pre, sender.msg, N ) 0 <= N arrived( receiveobj#1, receiveobj@pre, N, sendobj#1 ) acknowledged( sendobj#2, sendobj#1, N, receiveobj#1 ) assembled( receiveobj#1, receiver.msg ) Then: 19

20 samemessage( receiver.msg ) Revisions 1.0 Initial revision (Time-stamp: :48 ) 20

USE CASE BASED REQUIREMENTS VERIFICATION

USE CASE BASED REQUIREMENTS VERIFICATION USE CASE BASED REQUIREMENTS VERIFICATION Verifying the consistency between use cases and assertions Stéphane S. Somé, Divya K. Nair School of Information Technology and Engineering (SITE), University of

More information

Symbolic Execution and Proof of Properties

Symbolic Execution and Proof of Properties Chapter 7 Symbolic Execution and Proof of Properties Symbolic execution builds predicates that characterize the conditions under which execution paths can be taken and the effect of the execution on program

More information

Thirty one Problems in the Semantics of UML 1.3 Dynamics

Thirty one Problems in the Semantics of UML 1.3 Dynamics Thirty one Problems in the Semantics of UML 1.3 Dynamics G. Reggio R.J. Wieringa September 14, 1999 1 Introduction In this discussion paper we list a number of problems we found with the current dynamic

More information

Interactions A link message

Interactions A link message Interactions An interaction is a behavior that is composed of a set of messages exchanged among a set of objects within a context to accomplish a purpose. A message specifies the communication between

More information

Open Work of Two-Hemisphere Model Transformation Definition into UML Class Diagram in the Context of MDA

Open Work of Two-Hemisphere Model Transformation Definition into UML Class Diagram in the Context of MDA Open Work of Two-Hemisphere Model Transformation Definition into UML Class Diagram in the Context of MDA Oksana Nikiforova and Natalja Pavlova Department of Applied Computer Science, Riga Technical University,

More information

Introduction to Software Engineering. 5. Modeling Objects and Classes

Introduction to Software Engineering. 5. Modeling Objects and Classes Introduction to Software Engineering 5. Modeling Objects and Classes Roadmap > UML Overview > Classes, attributes and operations > UML Lines and Arrows > Parameterized Classes, Interfaces and Utilities

More information

Lecture 5 - Axiomatic semantics

Lecture 5 - Axiomatic semantics Program Verification March 2014 Lecture 5 - Axiomatic semantics Lecturer: Noam Rinetzky Scribes by: Nir Hemed 1.1 Axiomatic semantics The development of the theory is contributed to Robert Floyd, C.A.R

More information

8/22/2003. Proposal for VPI model PSL assertion extensions

8/22/2003. Proposal for VPI model PSL assertion extensions 8/22/2003 Proposal for VPI model PSL assertion extensions Cadence Design Systems, Inc. 8/22/2003 This proposal has been prepared by Cadence Design Systems, Inc. for consideration by the IEEE 1364 working

More information

Chapter 1: Principles of Programming and Software Engineering

Chapter 1: Principles of Programming and Software Engineering Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without

More information

SOFTWARE ENGINEERING UML FUNDAMENTALS. Saulius Ragaišis.

SOFTWARE ENGINEERING UML FUNDAMENTALS. Saulius Ragaišis. SOFTWARE ENGINEERING UML FUNDAMENTALS Saulius Ragaišis saulius.ragaisis@mif.vu.lt Information source Slides are prepared on the basis of Bernd Oestereich, Developing Software with UML: Object- Oriented

More information

Ingegneria del Software Corso di Laurea in Informatica per il Management. Introduction to UML

Ingegneria del Software Corso di Laurea in Informatica per il Management. Introduction to UML Ingegneria del Software Corso di Laurea in Informatica per il Management Introduction to UML Davide Rossi Dipartimento di Informatica Università di Bologna Modeling A model is an (abstract) representation

More information

Lecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning

Lecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning Lecture 1 Contracts 15-122: Principles of Imperative Computation (Fall 2018) Frank Pfenning In these notes we review contracts, which we use to collectively denote function contracts, loop invariants,

More information

CS 161 Computer Security

CS 161 Computer Security Wagner Spring 2014 CS 161 Computer Security 1/27 Reasoning About Code Often functions make certain assumptions about their arguments, and it is the caller s responsibility to make sure those assumptions

More information

Chapter 12. UML and Patterns. Copyright 2008 Pearson Addison-Wesley. All rights reserved

Chapter 12. UML and Patterns. Copyright 2008 Pearson Addison-Wesley. All rights reserved Chapter 12 UML and Patterns Copyright 2008 Pearson Addison-Wesley. All rights reserved Introduction to UML and Patterns UML and patterns are two software design tools that can be used within the context

More information

LABORATORY 1 REVISION

LABORATORY 1 REVISION UTCN Computer Science Department Software Design 2012/2013 LABORATORY 1 REVISION ================================================================== I. UML Revision This section focuses on reviewing the

More information

UNIT-IV BASIC BEHAVIORAL MODELING-I

UNIT-IV BASIC BEHAVIORAL MODELING-I UNIT-IV BASIC BEHAVIORAL MODELING-I CONTENTS 1. Interactions Terms and Concepts Modeling Techniques 2. Interaction Diagrams Terms and Concepts Modeling Techniques Interactions: Terms and Concepts: An interaction

More information

Object-Interaction Diagrams: Sequence Diagrams UML

Object-Interaction Diagrams: Sequence Diagrams UML Object-Interaction Diagrams: Sequence Diagrams UML Communication and Time In communication diagrams, ordering of messages is achieved by labelling them with sequence numbers This does not make temporal

More information

Pattern for Structuring UML-Compatible Software Project Repositories

Pattern for Structuring UML-Compatible Software Project Repositories Pattern for Structuring UML-Compatible Software Project Repositories Pavel Hruby Navision Software a/s Frydenlunds Allé 6 2950 Vedbaek, Denmark E-mail: ph@navision.com Web site: www.navision.com/services/methodology/default.asp

More information

BUILDING BLOCKS. UML & more...

BUILDING BLOCKS. UML & more... BUILDING BLOCKS UML & more... banerjee@cs.queensu.ca 1 Main Sections UML Sequence Use Case Diagrams Diagrams 2 So, what is the problem? Software is extremely complex. - Once a structure is in place, very

More information

CIS 890: Safety Critical Systems

CIS 890: Safety Critical Systems CIS 890: Safety Critical Systems Lecture: SPARK -- Analysis Tools Copyright 2007, John Hatcliff. The syllabus and all lectures for this course are copyrighted materials and may not be used in other course

More information

Object-Oriented Modeling. Sequence Diagram. Slides accompanying Version 1.0

Object-Oriented Modeling. Sequence Diagram. Slides accompanying Version 1.0 Object-Oriented Modeling Sequence Diagram Slides accompanying UML@Classroom Version 1.0 Business Informatics Group Institute of Software Technology and Interactive Systems Vienna University of Technology

More information

TIME-BASED CONSTRAINTS IN THE OBJECT CONSTRAINT LANGUAGE OCL

TIME-BASED CONSTRAINTS IN THE OBJECT CONSTRAINT LANGUAGE OCL TIME-BASED CONSTRAINTS IN THE OBJECT CONSTRAINT LANGUAGE OCL Ali Hamie, John Howse School of Computing, Mathematical and Information Sciences, University of Brighton, Brighton, UK. {a.a.hamie@brighton.ac.uk,

More information

Unified Modeling Language (UML)

Unified Modeling Language (UML) Unified Modeling Language (UML) Troy Mockenhaupt Chi-Hang ( Alex) Lin Pejman ( PJ ) Yedidsion Overview Definition History Behavior Diagrams Interaction Diagrams Structural Diagrams Tools Effect on Software

More information

The learning objectives of this chapter are the followings. At the end of this chapter, you shall

The learning objectives of this chapter are the followings. At the end of this chapter, you shall Chapter 5 Sequence diagrams In the previous chapters, we have seen different diagrams. Use case diagrams describe tasks that a system is supposed to perform. It gives high-level information about how a

More information

Programming Languages Third Edition

Programming Languages Third Edition Programming Languages Third Edition Chapter 12 Formal Semantics Objectives Become familiar with a sample small language for the purpose of semantic specification Understand operational semantics Understand

More information

ArchiMate 2.0. Structural Concepts Behavioral Concepts Informational Concepts. Business. Application. Technology

ArchiMate 2.0. Structural Concepts Behavioral Concepts Informational Concepts. Business. Application. Technology ArchiMate Core Structural Concepts Behavioral Concepts Informational Concepts interaction Technology Application Layer Concept Description Notation Concept Description Notation Actor An organizational

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2003 Vol. 2, No. 6, November-December 2003 UML 2 Activity and Action Models Part 3:

More information

1.3. Conditional expressions To express case distinctions like

1.3. Conditional expressions To express case distinctions like Introduction Much of the theory developed in the underlying course Logic II can be implemented in a proof assistant. In the present setting this is interesting, since we can then machine extract from a

More information

Lecture 1 Contracts. 1 A Mysterious Program : Principles of Imperative Computation (Spring 2018) Frank Pfenning

Lecture 1 Contracts. 1 A Mysterious Program : Principles of Imperative Computation (Spring 2018) Frank Pfenning Lecture 1 Contracts 15-122: Principles of Imperative Computation (Spring 2018) Frank Pfenning In these notes we review contracts, which we use to collectively denote function contracts, loop invariants,

More information

Cover Page. The handle holds various files of this Leiden University dissertation

Cover Page. The handle   holds various files of this Leiden University dissertation Cover Page The handle http://hdl.handle.net/1887/22891 holds various files of this Leiden University dissertation Author: Gouw, Stijn de Title: Combining monitoring with run-time assertion checking Issue

More information

Sequence Diagrams. Massimo Felici. Massimo Felici Sequence Diagrams c

Sequence Diagrams. Massimo Felici. Massimo Felici Sequence Diagrams c Sequence Diagrams Massimo Felici What are Sequence Diagrams? Sequence Diagrams are interaction diagrams that detail how operations are carried out Interaction diagrams model important runtime interactions

More information

Propositional Logic. Andreas Klappenecker

Propositional Logic. Andreas Klappenecker Propositional Logic Andreas Klappenecker Propositions A proposition is a declarative sentence that is either true or false (but not both). Examples: College Station is the capital of the USA. There are

More information

An Annotated Language

An Annotated Language Hoare Logic An Annotated Language State and Semantics Expressions are interpreted as functions from states to the corresponding domain of interpretation Operators have the obvious interpretation Free of

More information

Compiler Theory. (Semantic Analysis and Run-Time Environments)

Compiler Theory. (Semantic Analysis and Run-Time Environments) Compiler Theory (Semantic Analysis and Run-Time Environments) 005 Semantic Actions A compiler must do more than recognise whether a sentence belongs to the language of a grammar it must do something useful

More information

Runtime Checking and Test Case Generation for Python

Runtime Checking and Test Case Generation for Python Runtime Checking and Test Case Generation for Python Anna Durrer Master Thesis Chair of Programming Methodology D-INFK ETH Supervisor: Marco Eilers, Prof. Peter Müller 24. Mai 2017 1 Introduction This

More information

Modeling Alternative Courses in Detailed Use Cases

Modeling Alternative Courses in Detailed Use Cases Modeling Alternative Courses in Detailed Use Cases David Gelperin LiveSpecs Software dave@livespecs.com Abstract Real-life interactions between systems and users entail decisions and alternative courses

More information

Distributed Systems Programming (F21DS1) Formal Verification

Distributed Systems Programming (F21DS1) Formal Verification Distributed Systems Programming (F21DS1) Formal Verification Andrew Ireland Department of Computer Science School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh Overview Focus on

More information

PROPER TECHNIQUE OF SOFTWARE INSPECTION USING GUARDED COMMAND LANGUAGE

PROPER TECHNIQUE OF SOFTWARE INSPECTION USING GUARDED COMMAND LANGUAGE International Journal of Computer Science and Communication Vol. 2, No. 1, January-June 2011, pp. 153-157 PROPER TECHNIQUE OF SOFTWARE INSPECTION USING GUARDED COMMAND LANGUAGE Neeraj Kumar Singhania University,

More information

CHAPTER 1. Topic: UML Overview. CHAPTER 1: Topic 1. Topic: UML Overview

CHAPTER 1. Topic: UML Overview. CHAPTER 1: Topic 1. Topic: UML Overview CHAPTER 1 Topic: UML Overview After studying this Chapter, students should be able to: Describe the goals of UML. Analyze the History of UML. Evaluate the use of UML in an area of interest. CHAPTER 1:

More information

Introduction to Software Engineering. 6. Modeling Behaviour

Introduction to Software Engineering. 6. Modeling Behaviour Introduction to Software Engineering 6. Modeling Behaviour Roadmap > Use Case Diagrams > Sequence Diagrams > Collaboration (Communication) Diagrams > Activity Diagrams > Statechart Diagrams Nested statecharts

More information

System Sequence Diagrams. Based on Craig Larman, Chapter 10 and Anuradha Dharani s notes

System Sequence Diagrams. Based on Craig Larman, Chapter 10 and Anuradha Dharani s notes System Sequence Diagrams Based on Craig Larman, Chapter 10 and Anuradha Dharani s notes Dynamic behaviors Class diagrams represent static relationships. Why? What about modeling dynamic behavior? Interaction

More information

Method Description for Semla A Software Design Method with a Focus on Semantics

Method Description for Semla A Software Design Method with a Focus on Semantics Computer Science Method Description for Semla A Software Design Method with a Focus on Semantics Semla for Java, English version May 2000 Method Description for Semla A Software Design Method with a Focus

More information

A Correctness Proof for a Practical Byzantine-Fault-Tolerant Replication Algorithm

A Correctness Proof for a Practical Byzantine-Fault-Tolerant Replication Algorithm Appears as Technical Memo MIT/LCS/TM-590, MIT Laboratory for Computer Science, June 1999 A Correctness Proof for a Practical Byzantine-Fault-Tolerant Replication Algorithm Miguel Castro and Barbara Liskov

More information

Basic Verification Strategy

Basic Verification Strategy ormal Verification Basic Verification Strategy compare behavior to intent System Model of system behavior intent Verifier results Intent Usually, originates with requirements, refined through design and

More information

Question Sheet There are a number of criticisms to UML. List a number of these criticisms.

Question Sheet There are a number of criticisms to UML. List a number of these criticisms. Question Sheet 1 Name: ID: These questions do not have a formal, definitive answer. They are meant to be food for thoughts. Feel free to seek answers on browsing the Internet, talking to other software

More information

Formal Methods. CITS5501 Software Testing and Quality Assurance

Formal Methods. CITS5501 Software Testing and Quality Assurance Formal Methods CITS5501 Software Testing and Quality Assurance Pressman, R. Software Engineering: A Practitioner s Approach. Chapter 28. McGraw-Hill, 2005 The Science of Programming, David Gries, 1981

More information

FreePascal changes: user documentation

FreePascal changes: user documentation FreePascal changes: user documentation Table of Contents Jochem Berndsen February 2007 1Introduction...1 2Accepted syntax...2 Declarations...2 Statements...3 Class invariants...3 3Semantics...3 Definitions,

More information

Distributed minimum spanning tree problem

Distributed minimum spanning tree problem Distributed minimum spanning tree problem Juho-Kustaa Kangas 24th November 2012 Abstract Given a connected weighted undirected graph, the minimum spanning tree problem asks for a spanning subtree with

More information

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN NOTES ON OBJECT-ORIENTED MODELING AND DESIGN Stephen W. Clyde Brigham Young University Provo, UT 86402 Abstract: A review of the Object Modeling Technique (OMT) is presented. OMT is an object-oriented

More information

Model Driven Development Unified Modeling Language (UML)

Model Driven Development Unified Modeling Language (UML) Model Driven Development Unified Modeling Language (UML) An Overview UML UML is a modeling notation standardized by OMG (proposal 1997, ver.1.1 in 1998, ver. 2.0 in 2004) now in 2.4.1 mature based on notations

More information

Semantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics

Semantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics There is no single widely acceptable notation or formalism for describing semantics Operational Describe the meaning of a program by executing its statements on a machine, either simulated or actual. The

More information

Module 3. Requirements Analysis and Specification. Version 2 CSE IIT, Kharagpur

Module 3. Requirements Analysis and Specification. Version 2 CSE IIT, Kharagpur Module 3 Requirements Analysis and Specification Lesson 6 Formal Requirements Specification Specific Instructional Objectives At the end of this lesson the student will be able to: Explain what a formal

More information

Lecture Notes on Contracts

Lecture Notes on Contracts Lecture Notes on Contracts 15-122: Principles of Imperative Computation Frank Pfenning Lecture 2 August 30, 2012 1 Introduction For an overview the course goals and the mechanics and schedule of the course,

More information

Validating Plans with Durative Actions via Integrating Boolean and Numerical Constraints

Validating Plans with Durative Actions via Integrating Boolean and Numerical Constraints Validating Plans with Durative Actions via Integrating Boolean and Numerical Constraints Roman Barták Charles University in Prague, Faculty of Mathematics and Physics Institute for Theoretical Computer

More information

Software Development Methodologies

Software Development Methodologies Software Development Methodologies Lecturer: Raman Ramsin Lecture 3 Seminal Object-Oriented Methodologies: A Feature-Focused Review 1 Responsibility-Driven Design (RDD) Introduced in 1990; a UML-based

More information

Index. business modeling syntax 181 business process modeling 57 business rule 40

Index. business modeling syntax 181 business process modeling 57 business rule 40 OCL.book Page 203 Tuesday, July 22, 2003 9:48 PM Index Symbols OclAny, of 167 = OclAny, of 167 @pre 34, 86, 155 ^ 34, 156 ^^ 157 A abstract syntax 93 accumulator 153 action in statechart 56 activity

More information

Static Analysis Techniques

Static Analysis Techniques oftware Design (F28SD2): Static Analysis Techniques 1 Software Design (F28SD2) Static Analysis Techniques Andrew Ireland School of Mathematical and Computer Science Heriot-Watt University Edinburgh oftware

More information

OCL Support in MOF Repositories

OCL Support in MOF Repositories OCL Support in MOF Repositories Joachim Hoessler, Michael Soden Department of Computer Science Technical University Berlin hoessler@cs.tu-berlin.de, soden@cs.tu-berlin.de Abstract From metamodels that

More information

Repetition Through Recursion

Repetition Through Recursion Fundamentals of Computer Science I (CS151.02 2007S) Repetition Through Recursion Summary: In many algorithms, you want to do things again and again and again. For example, you might want to do something

More information

Engineering Design w/embedded Systems

Engineering Design w/embedded Systems 1 / 40 Engineering Design w/embedded Systems Lecture 33 UML Patrick Lam University of Waterloo April 4, 2013 2 / 40 What is UML? Unified Modelling Language (UML): specify and document architecture of large

More information

Object Oriented Modeling

Object Oriented Modeling Overview UML Unified Modeling Language What is Modeling? What is UML? A brief history of UML Understanding the basics of UML UML diagrams UML Modeling tools 2 Modeling Object Oriented Modeling Describing

More information

Business Process Modeling. Version /10/2017

Business Process Modeling. Version /10/2017 Business Process Modeling Version 1.2.1-16/10/2017 Maurizio Morisio, Marco Torchiano, 2012-2017 3 BP Aspects Process flow Process modeling UML Activity Diagrams BPMN Information Conceptual modeling UML

More information

Unified Modeling Language (UML)

Unified Modeling Language (UML) 1 / 45 Unified Modeling Language (UML) Miaoqing Huang University of Arkansas 2 / 45 Outline 1 Introduction 2 Use Case Diagram 3 Class Diagram 4 Sequence Diagram 3 / 45 Outline 1 Introduction 2 Use Case

More information

Lecture Notes: Hoare Logic

Lecture Notes: Hoare Logic Lecture Notes: Hoare Logic 17-654/17-754: Analysis of Software Artifacts Jonathan Aldrich (jonathan.aldrich@cs.cmu.edu) Lecture 3 1 Hoare Logic The goal of Hoare logic is to provide a formal system for

More information

UML Component Diagrams A.Y 2018/2019

UML Component Diagrams A.Y 2018/2019 UML Component Diagrams A.Y 2018/2019 Component diagrams Component diagrams are integral to building your software system. Drawn out with UML diagramming software, they help your team understand the structure

More information

Meltem Özturan

Meltem Özturan Meltem Özturan www.mis.boun.edu.tr/ozturan/samd 1 2 Modeling System Requirements Object Oriented Approach to Requirements OOA considers an IS as a set of objects that work together to carry out the function.

More information

Chapter 3. Describing Syntax and Semantics

Chapter 3. Describing Syntax and Semantics Chapter 3 Describing Syntax and Semantics Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the Meanings of Programs:

More information

An algorithm for Performance Analysis of Single-Source Acyclic graphs

An algorithm for Performance Analysis of Single-Source Acyclic graphs An algorithm for Performance Analysis of Single-Source Acyclic graphs Gabriele Mencagli September 26, 2011 In this document we face with the problem of exploiting the performance analysis of acyclic graphs

More information

State Machine Diagrams

State Machine Diagrams State Machine Diagrams Introduction A state machine diagram, models the dynamic aspects of the system by showing the flow of control from state to state for a particular class. 2 Introduction Whereas an

More information

Modeling automatic train regulation systems

Modeling automatic train regulation systems Modeling automatic train regulation systems J.K. Tobin Alcatel Canada Inc., Transport Automation Systems, Canada Abstract The increasing complexity of automatic train supervision and regulation systems

More information

Business Process Modeling. Version 25/10/2012

Business Process Modeling. Version 25/10/2012 Business Process Modeling Version 25/10/2012 Maurizio Morisio, Marco Torchiano, 2012, 2013 3 BP Aspects Process flow Process modeling UML Activity Diagrams BPMN Information Conceptual modeling UML Class

More information

A proof-producing CSP solver: A proof supplement

A proof-producing CSP solver: A proof supplement A proof-producing CSP solver: A proof supplement Report IE/IS-2010-02 Michael Veksler Ofer Strichman mveksler@tx.technion.ac.il ofers@ie.technion.ac.il Technion Institute of Technology April 12, 2010 Abstract

More information

6.001 Notes: Section 8.1

6.001 Notes: Section 8.1 6.001 Notes: Section 8.1 Slide 8.1.1 In this lecture we are going to introduce a new data type, specifically to deal with symbols. This may sound a bit odd, but if you step back, you may realize that everything

More information

Verification Condition Generation

Verification Condition Generation Verification Condition Generation Jorge Sousa Pinto Departamento de Informática / Universidade do Minho jsp@di.uminho.pt www.di.uminho.pt/~jsp Outline (1) - From Hoare Logic to VCGen algorithms: an architecture

More information

MODELS OF DISTRIBUTED SYSTEMS

MODELS OF DISTRIBUTED SYSTEMS Distributed Systems Fö 2/3-1 Distributed Systems Fö 2/3-2 MODELS OF DISTRIBUTED SYSTEMS Basic Elements 1. Architectural Models 2. Interaction Models Resources in a distributed system are shared between

More information

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages Harvard School of Engineering and Applied Sciences CS 152: Programming Languages Lecture 19 Tuesday, April 3, 2018 1 Introduction to axiomatic semantics The idea in axiomatic semantics is to give specifications

More information

For 100% Result Oriented IGNOU Coaching and Project Training Call CPD: ,

For 100% Result Oriented IGNOU Coaching and Project Training Call CPD: , Q.1 What is Object Orientation? Explain the concept of class, objects, instance, generalization, and associations. Ans :-- In the past, information systems used to be defined primarily by their functionality:

More information

Activity Nets: A UML profile for modeling workflow and business processes

Activity Nets: A UML profile for modeling workflow and business processes Activity Nets: A UML profile for modeling workflow and business processes Author: Gregor v. Bochmann, SITE, University of Ottawa (August 27, 2000) 1. Introduction 1.1. Purpose of this document Workflow

More information

Outline. Introduction. 2 Proof of Correctness. 3 Final Notes. Precondition P 1 : Inputs include

Outline. Introduction. 2 Proof of Correctness. 3 Final Notes. Precondition P 1 : Inputs include Outline Computer Science 331 Correctness of Algorithms Mike Jacobson Department of Computer Science University of Calgary Lectures #2-4 1 What is a? Applications 2 Recursive Algorithms 3 Final Notes Additional

More information

Axiomatic Specification. Al-Said, Apcar, Jerejian

Axiomatic Specification. Al-Said, Apcar, Jerejian Axiomatic Specification Al-Said, Apcar, Jerejian 1 Axioms: Wffs that can be written down without any reference to any other Wffs. Wffs that are stipulated as unproved premises for the proof of other wffs

More information

UML-Based Conceptual Modeling of Pattern-Bases

UML-Based Conceptual Modeling of Pattern-Bases UML-Based Conceptual Modeling of Pattern-Bases Stefano Rizzi DEIS - University of Bologna Viale Risorgimento, 2 40136 Bologna - Italy srizzi@deis.unibo.it Abstract. The concept of pattern, meant as an

More information

Producing Graphical User Interface from Activity Diagrams Ebitisam K. Elberkawi, Mohamed M. Elammari

Producing Graphical User Interface from Activity Diagrams Ebitisam K. Elberkawi, Mohamed M. Elammari Producing Graphical User Interface from Activity Diagrams Ebitisam K. Elberkawi, Mohamed M. Elammari Abstract Graphical User Interface (GUI) is essential to programming, as is any other characteristic

More information

Unit 1 Chapter 4 ITERATIVE ALGORITHM DESIGN ISSUES

Unit 1 Chapter 4 ITERATIVE ALGORITHM DESIGN ISSUES DESIGN AND ANALYSIS OF ALGORITHMS Unit 1 Chapter 4 ITERATIVE ALGORITHM DESIGN ISSUES http://milanvachhani.blogspot.in USE OF LOOPS As we break down algorithm into sub-algorithms, sooner or later we shall

More information

Pet: An Interactive Software Testing Tool

Pet: An Interactive Software Testing Tool Pet: An Interactive Software Testing Tool Elsa Gunter, Robert Kurshan, and Doron Peled Bell Laboratories 600 Mountain Ave. Murray Hill, NJ 07974 Abstract. We describe here the Pet (standing for path exploration

More information

UML part I. UML part I 1/41

UML part I. UML part I 1/41 UML part I UML part I 1/41 UML part I 2/41 UML - Unified Modeling Language unified it can be shared among workers modeling it can be used for description of software model language it has defined structure

More information

On UML2.0 s Abandonment of the Actors-Call-Use-Cases Conjecture

On UML2.0 s Abandonment of the Actors-Call-Use-Cases Conjecture On UML2.0 s Abandonment of the Actors-Call-Use-Cases Conjecture Sadahiro Isoda Toyohashi University of Technology Toyohashi 441-8580, Japan isoda@tutkie.tut.ac.jp Abstract. UML2.0 recently made a correction

More information

Introduction to Software Engineering. 5. Modeling Objects and Classes

Introduction to Software Engineering. 5. Modeling Objects and Classes Introduction to Software Engineering 5. Modeling Objects and Classes Roadmap > UML Overview > Classes, attributes and operations > UML Lines and Arrows > Parameterized Classes, Interfaces and Utilities

More information

Chapter 2 Overview of the Design Methodology

Chapter 2 Overview of the Design Methodology Chapter 2 Overview of the Design Methodology This chapter presents an overview of the design methodology which is developed in this thesis, by identifying global abstraction levels at which a distributed

More information

A Beginners Guide to UML Part II

A Beginners Guide to UML Part II A Beginners Guide to UML Part II Dan Brown, Dunstan Thomas Consulting Summary In the first part of this article, I examined the origins and definition of the UML to provide a basic understanding of what

More information

The Lean Cuisine+ Notation Revised

The Lean Cuisine+ Notation Revised Res. Lett. Inf. Math. Sci., (2000) 1, 17-23 Available online at http://www.massey.ac.nz/~wwiims/rlims/ The Lean Cuisine+ Notation Revised Chris Scogings I.I.M.S., Massey University Albany Campus, Auckland,

More information

CMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics

CMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics Recall Architecture of Compilers, Interpreters CMSC 330: Organization of Programming Languages Source Scanner Parser Static Analyzer Operational Semantics Intermediate Representation Front End Back End

More information

SOFTWARE ENGINEERING DESIGN I

SOFTWARE ENGINEERING DESIGN I 2 SOFTWARE ENGINEERING DESIGN I 3. Schemas and Theories The aim of this course is to learn how to write formal specifications of computer systems, using classical logic. The key descriptional technique

More information

Activities Radovan Cervenka

Activities Radovan Cervenka Unified Modeling Language Activities Radovan Cervenka Activity Model Specification of an algorithmic behavior. Used to represent control flow and object flow models. Executing activity (of on object) is

More information

Joint Entity Resolution

Joint Entity Resolution Joint Entity Resolution Steven Euijong Whang, Hector Garcia-Molina Computer Science Department, Stanford University 353 Serra Mall, Stanford, CA 94305, USA {swhang, hector}@cs.stanford.edu No Institute

More information

A Partial Correctness Proof for Programs with Decided Specifications

A Partial Correctness Proof for Programs with Decided Specifications Applied Mathematics & Information Sciences 1(2)(2007), 195-202 An International Journal c 2007 Dixie W Publishing Corporation, U. S. A. A Partial Correctness Proof for Programs with Decided Specifications

More information

INTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2

INTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2 INTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2 1 Faculty of Sciences, Lebanese University 2 LINA Laboratory, University of Nantes ABSTRACT:

More information

Interaction Modelling: Sequence Diagrams

Interaction Modelling: Sequence Diagrams Interaction Modelling: Sequence Diagrams Fabrizio Maria Maggi Institute of Computer Science (these slides are derived from the book Object-oriented modeling and design with UML ) Interaction Modelling

More information

Programming Languages and Compilers Qualifying Examination. Answer 4 of 6 questions.1

Programming Languages and Compilers Qualifying Examination. Answer 4 of 6 questions.1 Programming Languages and Compilers Qualifying Examination Monday, September 19, 2016 Answer 4 of 6 questions.1 GENERAL INSTRUCTIONS 1. Answer each question in a separate book. 2. Indicate on the cover

More information

Part II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?

Part II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs? Part II. Hoare Logic and Program Verification Part II. Hoare Logic and Program Verification Dilian Gurov Props: Models: Specs: Method: Tool: safety of data manipulation source code logic assertions Hoare

More information

Business Activity. predecessor Activity Description. from * successor * to. Performer is performer has attribute.

Business Activity. predecessor Activity Description. from * successor * to. Performer is performer has attribute. Editor Definition Language and Its Implementation Audris Kalnins, Karlis Podnieks, Andris Zarins, Edgars Celms, and Janis Barzdins Institute of Mathematics and Computer Science, University of Latvia Raina

More information