Using requirements to retrace software evolution history
•Als PPT, PDF herunterladen•
0 gefällt mir•496 views
Presented at Software Evolvability at ICSM07
![Motivation ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (17)
Ähnlich wie Using requirements to retrace software evolution history
Ähnlich wie Using requirements to retrace software evolution history (20)
Mehr von Neil Ernst
Mehr von Neil Ernst (7)
Using requirements to retrace software evolution history
- 1. Using requirements to retrace software evolution history Neil Ernst and John Mylopoulos University of Toronto
Hinweis der Redaktion
- 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