Using requirements to retrace software evolution history

Using requirements to retrace software evolution history Neil Ernst and John Mylopoulos University 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)‏

Software 'history'
Many histories of ‘software’, the industry, etc. focus on what happened – not why
A ‘history’ is a systematic and plausible explanation of past events through disciplined and judicious use of primary sources, where possible

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

Distributed computing
The ability to manipulate resources on new, heterogeneous systems
Protocols describe standard ways of dealing with problems – they constrain possible operations (for some reason, e.g. interoperability)‏

Early days
The introduction of the ‘network’ spurred White to develop remote procedure call
Eight requirements, including:
Report on the outcome of invocation
Represent several types
Arbitrary, named commands

Remote procedure call
Xerox
Stubs and skeletons
Remote invocation should mimic local invocation
Sun's ONC
Handle authentication formally
Discusses call semantics
DCE
Reaction to market dominance
Handle multiple OS
Separate invoker from consumer

Introduction of object-based DC
First standard quite buggy,
prompting 5 years of work on version 2
Numerous, often incomplete vendor implementations led to market fragmentation
True language-independence with IDLs
Handle multiple systems at once with ORBs
CORBA

Java 1.0 introduced in 1995
RMI bundled, implementing RPC object protocol
In 1998, Sun introduced EJBs and notion of separating business logic
Large, dominant player meant comfort for decision-makers (cf. Corba)‏
Java: RMI and EJBs

Extend DCE with a distributed object framework
A Microsoft competitor for CORBA-based solutions
Garbage collection
Access control lists
Remote object evolution
Microsoft: DCOM

The web years
Triumph of HTTP as transport protocol
Advent of XML as data exchange format
'Web services' via XML-RPC and SOAP
Constrained architectures: REST (2000)‏
Constrain the

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.

19/09/07
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.
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.
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.

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)‏

Thank you [email_address]

extra
Towards a `science of software systematics’*
*Scacchi, Walter, “Understanding Open-Source Software Evolution”, in Madhavji, Perry and Ramil, eds., Software Evolution and Feedback: Theory and Practice , Wiley: 2006.
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.
Cf. Jackson’s problem frames
Antòn and Potts described ‘functional paleontology’, a history of user-facing features in a telephony company

Using requirements to retrace software evolution history

by Neil Ernst on Mar 16, 2011

Accessibility

Tags

Upload Details

Usage Rights

Statistics

Using requirements to retrace software evolution history — Presentation Transcript