CSE 436—Requirements and Version Control Systems

1. CSE 436—Requirements and Version Control Systems Ron K. Cytron http://www.cs.wustl.edu/~cytron/cse436/ 26 September 2005

2. Today • Requirements discussion • Break (15 minute): groups organize presentations • Source-control systems (CVS) • Break (5 minutes) • Groups present intro/overview. A different person gives each of the following talks: • Elevator pitch (15 seconds, 30 seconds, 1 minute) • Customer pitch • Technical pitch to generate interest in forming team • Requirements discussion within groups

3. Requirements in the SRRD • Type • Functional: what the system will do. Transformational properties of the system. Example: system shall compute y=sqrt(x) such that y*y = x. This can get very detailed, and supporting documentation such as protocol specifics can be very useful. “System shall support protocol x.y.z” • Nonfunctional: outside of the code, metaproperties • Physical: form factors, sizing, power • Goals: not strictly requirements, but desirable outcomes from the customer’s perspective • Derived: depends on other requirements. Must state the relationship so that if the main requirement changes, this can be examined.

4. Requirements in the SRRD • ID: a unique number, never changes, so that the requirement can be specified uniquely and consistently • Description: text of the requirement • Source: where does this come from? Source should be customer or some super requirement • Verification: how do you plan to verify that the requirement is met? • Traced-to: what components are affected by the requirement? It may help to organize software in part based on requirement partitions

5. Requirements [ Pressman ] • Inception • How did the project get started? • Who is involved? • Intro and overview cover this in SRRD • Elicitation • Elaboration • Negotiation • Specification • Validation

6. Eliciting Requirements • We did a mock setting of this last week • Articulate use cases • Name of case • Primary actor • Goal in this case • Precondition (start state) • Trigger for case • Steps in scenario • 1, 2, 3, etc • Exceptions • Open issues / unresolved questions about requirements (behavior, nonfunctional, etc)

7. Elaboration • Models are built • Many possible models • I/O automata • Petri nets • Finite state automata • Model helps formalize interactions and behaviors

8. Negotiation • After elaboration, feasibility may be in doubt • “Do you really need Windows?” • Go for “win win” • Don’t get personal • Be creative • Be ready to commit when you can

9. Specification • Write it down

10. Validation • Do the requirements make sense? • Prototyping may be necessary • Go back to negotiation as needed

11. Source Control Systems • Software evolves through source edits • How do we track software? • How do we manage multiple developers’ activities? • How do we tie development to testing? • How do we prototype new features? • How do we apply bug fixes? • Models for source control • It’s mine, ALL mine • Shared vision of who has token to modify what • Library model: check it out and nobody can have it until you check it in • Concurrent access

12. Concurrent access • Many developers • Different time zones • Different work habits • Need to manipulate code base frequently • Low access cost • Developers may not know each other • Token and locks are impractical • What happens when developers collide?

13. CVS • Nobody ever has a lock on anything • Versions • Main repository version (head of repo) • Many developer working copies • “Commit” changes back to the repository when ready • Version numbers change • Attempt to merge changes via serializability • Conflicts pushed back to “last to commit” • Branching • Repo can fork so development can proceed from a common code base along divergent paths • Forked development can be brought back into main trunk if needed • Files stored as text-based “diffs” • Head of repo is kept in full text • Back versions kept by diffs • Binary files don’t diff  each version stored fully • Keyword substitution $Id: $  becomes version identifier

14. Using CVS • CVSROOT points to repo directory • cvs init • Sets things up • cvs import module vendor release • module = where stored in the repo (this matters) • vendor = where did this come from (doesn’t matter) • release = “initial” (doesn’t matter) • This imports a directory into the repo • cvs co module[/x/y/…/z] • Gives you a working copy • You can add, delete, modify files • When you commit, changes are sent back • cvs add file file … file • Schedules list of files for addition to repo • Add a .cvsignore file for things that should be ignored by CVS in a directory (*.o *.class) • cvs upd • Updates your working copy against the repo • Use “cvs –n upd” to check what would happen if you updated • Tries to merge disparate changes • When unsuccessful, conflicts are reported and you must address these • Commit early, commit often (XP philosophy) • cvs commit –m’meaningful message about the changes’ • Checks in each file at and below the current directory that has changed

15. Subversion • Like CVS, but perhaps better • Entire repo is at some version number • Check-in of multiple files considered atomic • $Id$ supported but you have to really ask for it • Binary diffs are stored