27.07.2013 Views

2 Why We Need Model-Based Testing

2 Why We Need Model-Based Testing

2 Why We Need Model-Based Testing

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

170 <strong>Model</strong>ing Systems with Structured State<br />

the source files in the repository. Changes made to this local copy affect the global<br />

repository of source code only when the user commits changes. Changes are always<br />

applied as an atomic transaction.<br />

An important feature of a revision control system is the handling of conflicts, or<br />

cases when two users have made simultaneous updates to the same source file. The<br />

system provides operations that identify the conflicts and allow users to choose how<br />

to resolve them.<br />

In our case study, we have not modeled any particular revision control system;<br />

instead, we have abstracted features that are common to typical revision control<br />

systems. If you want to compare the model with an implementation, you might want<br />

to look at the Subversion revision control system that is available as open source.<br />

10.4.1 Vocabulary of actions<br />

<strong>We</strong> view a revision control system as a model program with the following vocabulary<br />

of user actions:<br />

• Synchronize updates a given client’s local copy to include the latest revisions in<br />

the global repository. However, changed files will not be overwritten; instead,<br />

they will be marked as conflicts to be resolved before committing.<br />

• Edit represents a file change in the client’s local view of the repository.<br />

• Revert undoes a previous edit, restoring a file’s state to the version of the last<br />

Synchronize operation.<br />

• Commit propagates local file changes to the global repository.<br />

• Resolve reconciles conflicts between a local version of a file and changes to the<br />

global repository made in parallel by another user. All files with conflicts must<br />

be resolved before a set of changes may be propagated to the global repository.<br />

The server has two actions that represent the server’s possible repsonses to a<br />

client’s request to commit changes:<br />

• MustResolve occurs after a Commit action for a client with unresolved file conflicts.<br />

No changes to the global repository are made.<br />

• CommitComplete occurs when changes have been successfully propagated to the<br />

repository.<br />

Here is a trace of a sample session for two clients.<br />

Synchronize("alice")<br />

Edit("alice", "file1", Op("Add"))<br />

Commit("alice")<br />

CommitComplete("alice", 1)<br />

Synchronize("bob")<br />

more free ebooks download links at:<br />

http://www.ebook-x.com

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!