CSE 436—Requirements and Version Control Systems Ron K. Cytron 26 September 2005

CSE 436 Software Engineering Workshop 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

CSE 436 Software Engineering Workshop 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, metapropertiesNonfunctional –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.

CSE 436 Software Engineering Workshop 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

CSE 436 Software Engineering Workshop Requirements [ Pressman ] Inception –How did the project get started? –Who is involved? –Intro and overview cover this in SRRD Elicitation Elaboration Negotiation Specification Validation

CSE 436 Software Engineering Workshop 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)

CSE 436 Software Engineering Workshop Elaboration Models are built –Many possible models I/O automata Petri nets Finite state automata –Model helps formalize interactions and behaviors

CSE 436 Software Engineering Workshop 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

CSE 436 Software Engineering Workshop Specification Write it down

CSE 436 Software Engineering Workshop Validation Do the requirements make sense? Prototyping may be necessary Go back to negotiation as needed

CSE 436 Software Engineering Workshop 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

CSE 436 Software Engineering Workshop 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?

CSE 436 Software Engineering Workshop 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

CSE 436 Software Engineering Workshop Using CVSCVS 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

CSE 436 Software Engineering Workshop 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