Configuration Management and
Distributed Software Engineering
Jon A. Preston
Dr. Xiaolin Hu
CSc8350 – Spring 2005
Agenda
• SE = Coordination and collaboration
• CM = Artifact management
• IDE = Integrating CMS/CSCW
• Code visualization techniques
• Open-systems architecture
Collaboration/Coordination
• Software engineering involves
coordinating multiple developers,
architects, testers, designers, and
managers
• Net-centric computing dominates
– Resultant distributed nature of SE projects
– Leverage geography to achieve SE “shifts”
Configuration Management
• Principally involves artifact management and
coordination
• Allow maximum concurrency
• Minimize collisions (lost and/or replicated work)
• Recent study (2001)
– 12.5% of all changes to a file occur within 24 hours
– 16 parallel versions to be merged
Configuration Management
Document A
Edits A → A’
Edits A → A’’
Update with A’
or A’’
or merge
User 1
User 2
Optimistic vs. Pessimistic
• Two approaches to CM
• Optimistic
– High concurrency (hopefully disjoint)
– Must deal with possible merge
• Pessimistic
– Low concurrency
– Avoids the merge problem
– Users can check out “read only” and edit
Pessimistic Coordination
Document A
Checks out A
Checkout denied
until A’ is checked in
Edits A → A’
Checks in A’
The differential
User 1
is saved
User 2
Optimistic Coordination
Document A
Accesses A
Accesses A
Edits A → A’
Edits A’ → A’’
Changes to A
and A’ are
immediately
User 1
coordinated
User 2
Distributed Configuration
Management
•
•
•
•
•
Network-centric computing
Distributed file system
Distribute artifacts among many machines
Coordinate among machines (lookup, etc.)
Can offer replication services (reliability,
performance)
– Must then deal with replicating locks and
changes
Distributed CM
Locks file C
User 1
Files A-I
Locks file T
Locks file J
…
User 2
User N
Files J-Q
Locks file Z
Locks file L
Files R-Z
Distributed CM with Replication
Locks file C
User 1
Files A-I
Locks file T
Locks file J
…
User 2
Files J-Q
Locks file Z
Files R-Z
User N
Locks file L
Files R-Z
Distributed CM with Replication
Locks file C
User 1
Files A-I
Locks file T
Locks file J
Files J-Q
Updates file Z
Files R-Z
User N
Locks file L
Files R-Z
Updates file Z
…
User 2
Structure of Software Systems
• Highly structured – code blocks
• Hierarchical – trees/graphs
• Reuse leads to interdependencies
• Can auto-detect such structures and
interdependencies
Fine-grain Differentials
Version n
Node data
Node
Version n+1
Edited code
block
Collaborative IDE and Versioning
• Locking (pessimistic CM) doesn’t scale
• Highly-structured nature of software code
helpful
• Supports “wait-free” collaboration
• Must deal with collisions/merging
• Evolution graph (branching and merging)
presented
Collaborative Editing in Jazz
• Plug in for Eclipse (Java IDE)
• Shows “Rear View Window” of other users
• Connects with IM, email, and screen
sharing
• “Lightweight” collaboration
Microsoft’s Integrated Approach
• Visual Studio 2005 Team System
• Integrates architecture, design,
development, testing, and
oversight/tracking
• Includes communication “hooks”
Visual
Studio
2005
Team
System
Test Integration and Coverage
Code Visualization
• Augur
• Extends “SeeSoft”
• Allows for an aggregate view of distributed
software development
• Colors indicate users as well as structure
of code and age of change
• Multiple views
• Presented at ICSE’04
SeeSoft
Augur – Visualizing Source Code
Augur – Visualizing Source Code
Open-systems Architecture
• Current research in CSCW
– Web-based systems
– Change tracking in Office
• Web-services
– Access remotely
– Subscriber pattern for notification
• Middleware
– Update legacy CMS with new functionality
Core Functionality
•
•
•
•
•
Optimistic check out
Pessimistic check out
Check in
Subscribe and unsubscribe
Publish lists
– Artifacts (and state)
– Users (contact information, presence, etc.)
– Subscriptions
IDE
Notification
(Email, IM, etc.)
Fine-grain
middleware
…
Fine-grain
middleware
Fine-grain
middleware
Web Services-Provided Core Functionality
Network
Connection
middleware
Doc
Editor
Connection
middleware
…
Open-systems Architecture
CVS
VSS
CMS
Conclusion
• Traditional CM does not scale well
– Pessimistic locking inhibits concurrency
– Fine-grain locking a possible solution
• Integration of CSCW and IDE critical
• Visualization techniques useful
– Track changes over time
– Provide meta-view of structure
• Open-systems architecture is promising