Using requirements to retrace software evolution history


Published on

Presented at Software Evolvability at ICSM07

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 17 mins + 5 for questions/setup Thanks for coming. This is a practice talk for a workshop on software evolvability at ICSM in two weeks. The workshop will explore topics around how to design software systems, and their requirements, to support evolving contexts. Please hold questions til after the presentation as you would at a real conference. I'd appreciate any notes on typos, weird colours, inaccuracies, and other mistakes, too. Keep in mind this is a talk on history being given by someone who wasn't there for a lot of it. I welcome clarifications from my more experienced colleagues.
  • The nounal view looks at the 'what' of evolution rather than the verbal view – the how. We want to focus on how a system can be made more 'evolvable'. But evolvability doesn't arise like Athena, fully-formed.
  • e.g., the history of spreadsheets often starts with Visicalc, then 1-2-3, then Excel, etc. But this is just a factual recounting of events, like “napoleon retreated from Moscow and lost most of his army”. We want to understand, for example, 'why did Napoleon invade Russia'?
  • As an example of what software histories – that focus on the why – can teach us, I want to discuss distributed computing. Controversial because Microsoft did not dominate this area as much as, say, word processing. I focus on intentions because I am interested in the problem domain and not specifics of machine domains. I acknowledge that many issues are raised when implementation happens .. but I suggest those issues are then addressed in later releases.
  • What is distributed computing? Possibly parallel – so perhaps a better term in remote computing
  • Here is an overview of the protocols and technologies I cover. Any taxonomy is necessarily a simplification, but this diagram tries to show rough philogeny ... i.e. Connected nodes are more related. There is nonetheless a lot of gene transfer.
  • These requirements were a response to protocols that required reinvention each time, for example FTP and Telnet.
  • Rise of Unix for servers scared smaller vendors (Sun/ATT)‏
  • The HTTP model had demonstrated scalability and support for heterogeneity: everyone had a web server on port 80, but not everyone had a CORBA/DCOM server. A high enough level of abstraction, dealing with call/response, redirects, etc. XML is self-descriptive and simple to start with.
  • A service is: • A possibly remote procedure with an • invocation that is described in a standard (preferably XML-based) machine-readable syntax, • reachable via standard Internet protocols, • including at a minimum a description of the allowed input and output messages, as well as • possible semantic annotation of the service function and data meaning. Dagstuhl session on SOC
  • Using requirements to retrace software evolution history

    1. 1. Using requirements to retrace software evolution history Neil Ernst and John Mylopoulos University of Toronto
    2. 2. Motivation <ul><li>Lehman and Ramil describe the nounal view of software evolution as concerned with “the nature of evolution, its causes . . . [and] its impacts” </li></ul><ul><li>Design for evolvability should learn from past decisions and past requirements </li></ul><ul><ul><li>Learn ‘large-scale’ context for problems </li></ul></ul><ul><ul><li>Appreciate previous solutions (avoid NIH syndrome)‏ </li></ul></ul>
    3. 3. Software 'history' <ul><li>Many histories of ‘software’, the industry, etc. focus on what happened – not why </li></ul><ul><li>A ‘history’ is a systematic and plausible explanation of past events through disciplined and judicious use of primary sources, where possible </li></ul>
    4. 4. Distributed computing <ul><li>Why a history of distributed computing? </li></ul><ul><ul><li>Seek to understand the evolution of various tools and standards </li></ul></ul><ul><ul><li>Well-documented and controversial </li></ul></ul><ul><li>Artifacts: </li></ul><ul><ul><li>Published specifications and proposals </li></ul></ul><ul><ul><li>Contemporary commentary, mailing list posts </li></ul></ul><ul><li>Omit implementation in favour of intention </li></ul>
    5. 5. Distributed computing <ul><li>The ability to manipulate resources on new, heterogeneous systems </li></ul><ul><li>Protocols describe standard ways of dealing with problems – they constrain possible operations (for some reason, e.g. interoperability)‏ </li></ul>
    6. 6.
    7. 7. Early days <ul><li>The introduction of the ‘network’ spurred White to develop remote procedure call </li></ul><ul><li>Eight requirements, including: </li></ul><ul><ul><li>Report on the outcome of invocation </li></ul></ul><ul><ul><li>Represent several types </li></ul></ul><ul><ul><li>Arbitrary, named commands </li></ul></ul>
    8. 8. Remote procedure call <ul><li>Xerox </li></ul><ul><ul><li>Stubs and skeletons </li></ul></ul><ul><ul><li>Remote invocation should mimic local invocation </li></ul></ul><ul><li>Sun's ONC </li></ul><ul><ul><li>Handle authentication formally </li></ul></ul><ul><ul><li>Discusses call semantics </li></ul></ul><ul><li>DCE </li></ul><ul><ul><li>Reaction to market dominance </li></ul></ul><ul><ul><li>Handle multiple OS </li></ul></ul><ul><ul><li>Separate invoker from consumer </li></ul></ul>
    9. 9. <ul><li>Introduction of object-based DC </li></ul><ul><li>First standard quite buggy, </li></ul><ul><ul><li>prompting 5 years of work on version 2 </li></ul></ul><ul><li>Numerous, often incomplete vendor implementations led to market fragmentation </li></ul><ul><ul><li>True language-independence with IDLs </li></ul></ul><ul><ul><li>Handle multiple systems at once with ORBs </li></ul></ul>CORBA
    10. 10. <ul><li>Java 1.0 introduced in 1995 </li></ul><ul><li>RMI bundled, implementing RPC object protocol </li></ul><ul><li>In 1998, Sun introduced EJBs and notion of separating business logic </li></ul><ul><li>Large, dominant player meant comfort for decision-makers (cf. Corba)‏ </li></ul>Java: RMI and EJBs
    11. 11. <ul><li>Extend DCE with a distributed object framework </li></ul><ul><li>A Microsoft competitor for CORBA-based solutions </li></ul><ul><ul><li>Garbage collection </li></ul></ul><ul><ul><li>Access control lists </li></ul></ul><ul><ul><li>Remote object evolution </li></ul></ul>Microsoft: DCOM
    12. 12. The web years <ul><li>Triumph of HTTP as transport protocol </li></ul><ul><li>Advent of XML as data exchange format </li></ul><ul><li>'Web services' via XML-RPC and SOAP </li></ul><ul><li>Constrained architectures: REST (2000)‏ </li></ul><ul><ul><li>Constrain the </li></ul></ul>
    13. 13. Analysis <ul><li>Change is incremental from year to year, addressing specific challenges: scalability as the web takes off; true heterogeneity… </li></ul><ul><li>In that light, what does our study suggest about designing an evolvable DC spec? </li></ul><ul><li>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. </li></ul>
    14. 14. 19/09/07 <ul><li>Successful protocols work best by allowing the developer to focus on what matters to their application. Such generality and encapsulation become more and more successful as the underlying technologies, such as HTTP, are themselves standardized and propagated. </li></ul><ul><li>Service orientation, the separation of business logic and application code, and the ability to separate invoker from consumer are important mechanisms for handling application complexity and promoting reusability. </li></ul><ul><li>Treating remote resources as though they were local is misleading. There are certain properties of local resources, such as latency, that are very difficult to ignore. One of CORBA’s problems was its insistence on this principle. Quality of service properties are important to consider. Web services specifications, such as WS-ReliableMessaging , are attempts to address this. </li></ul>
    15. 15. Conclusions <ul><li>Designing for evolvability should consider past decisions. Would a new distributed computing paradigm arise if it did not provide improvements on the past? </li></ul><ul><li>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)‏ </li></ul>
    16. 16. Thank you [email_address]
    17. 17. extra <ul><li>Towards a `science of software systematics’* </li></ul><ul><li>*Scacchi, Walter, “Understanding Open-Source Software Evolution”, in Madhavji, Perry and Ramil, eds., Software Evolution and Feedback: Theory and Practice , Wiley: 2006. </li></ul><ul><li>It is increasingly difficult to point to any one piece of software or code as a ‘standalone’ system. Even embedded systems interact with servers, other devices, etc. Powerpoint has online help, embedded drawings, etc. </li></ul><ul><li>Cf. Jackson’s problem frames </li></ul><ul><li>Antòn and Potts described ‘functional paleontology’, a history of user-facing features in a telephony company </li></ul>