Using requirements to retracesoftware evolution history

Neil Ernst and John MylopoulosUniversity of Toronto

Motivation• Lehman and Ramil describe the nounal view of

software evolution as concerned with “the nature of evolution, its causes . . . [and] its impacts”

• Design for evolvability should learn from past decisions and past requirements• Learn ‘large-scale’ context for problems• Appreciate previous solutions (avoid NIH syndrome)

2

Distributed computing

• Why a history of distributed computing?– Seek to understand the evolution of various tools

and standards–Well-documented and controversial

• Artifacts:– Published specifications and proposals– Contemporary commentary, mailing list posts

• Omit implementation in favour of intention

4

6

Analysis• Change is incremental from year to year, addressing

specific challenges: scalability as the web takes off; true heterogeneity…

• In that light, what does our study suggest about designing an evolvable DC spec?

• Vendor lock-in is a blessing and a curse. In the case of DCOM, tight integration with the dominant platform of the day made development easier. At the same time, extending applications beyond that platform was essentially impossible. Open standards processes can lead to ‘design-by-committee’ syndrome, but can also greatly increase adoption.

13

Conclusions

• Designing for evolvability should consider past decisions. Would a new distributed computing paradigm arise if it did not provide improvements on the past?

• Abstraction is only possible after sufficient pain has been suffered. E.g. REST: SOA is a style w/o constraints (anything can be sent), but the constraints are there for a reason (e.g., loose coupling, uniform identifiers, help scale systems)

15