Abstract not found

attention as an important sub#eld of software engineering. During that time there has been considerable progress in developing the technological and methodological base for treating architectural design as an engineering discipline. However, much remains to be done to achieve that goal. Moreover, the changing face of technology raises anumber of new challenges for software architecture. This paper examines some of the important trends of software architecture in research and practice, and speculates on the important emerging trends, challenges, and aspirations.

There is a significant difference between documenting large programs and documenting small ones. By large programs we mean on the order of 1,000,000 lines, usually written by many different people over a long period of time. Most software documentation may be termed documenting-in-the-small, since it typically describes the program at the algorithm and data structure level. To understand large legacy systems, one needs documenting-in-the-large: documentation describing the high-level structural aspects of the software system's architecture from multiple perspectives. This paper outlines an approach to supporting software evolution through documenting-in-the-large. The approach is based on a flexible reverse engineering process which uses virtual subsystem stratifications to represent multiple abstract views of a software system. Keywords: documenting-in-the-large, reverse engineering, software evolution y This work was supported in part by the British Columbia Advanced Systems Inst...

We take software [systems] engineering to consist of three major phases: domain engineering,

1 Introduction Configuration management plays a key role in the engineering of large software systems; it comprises several sub-areas, including versioning, access control, system modelling and system building. While several commercial software development environments have successfully attacked many of the problems of configuration management, most approaches have been tightly integrated with a particular set of tools. Consequently, there is a need for notations and tools for configuration management that are both powerful and intuitive yet not bound to particular environments or languages. Visual notations hold promise, yet they have not yet been investigated very thoroughly.1

Proper design analysis is indispensable to assure quality and reduce emergent costs due to faulty software. Teaching proper design verification skills early during the pedagogical development of a software engineer is crucial, as such analysis is the only tractable way of resolving software problems early when they are easy to fix. The premise of the presented strategy is based on the observation that a fundamental component of any engineering discipline is the use of formal and sound techniques that facilitate analysis of produced artifacts. Yet, fundamental roadblocks exist in bringing the state of the art in formal design analysis to the undergraduate software engineering classroom due to the steep learning curve and quagmire of theoretical details involved in formal methods. This paper suggests a strategy and tool support to improve the attainment of software design verification skills. We illustrate how selective and pragmatic application of model-based verification methods can be used in software design education via tools that aim to bridge the gap between students ' semi-formal design worldview and the formalism underlying formal methods. AUTHOR QUESTIONNAIRE 1. The paper discusses materials/software for a course in Software Engineering. 2. Students are taught this course Computer Science, Software Engineering and Computer

Architecture evolution is a central feature of virtually all software systems. As new market opportunities, technologies, platforms, and frameworks become available systems must change their organizational structures to accommodate them, requiring large-scale and systematic restructuring. Today architects have few tools to help them plan and execute such evolutionary paths. In particular, they have almost no assistance in reasoning about questions such as: How should we stage the evolution to achieve business goals in the presence of limited development resources? How can we reduce risk in incorporating new technologies and infrastructure required by the target architecture? How can we make principled tradeoffs between time and development effort? What kinds of changes can be made independently, and which require coordinated system-wide modifications? How can an evolution plan be represented and communicated within an organization? In this report we outline first steps towards a formal basis for assisting architects in developing and reasoning about architectural evolution paths. The key insight behind the approach is that at an architectural level of abstraction many system evolutions follow certain common patterns – or evolution styles. By taking advantage of regularity in the space of common architectural evolutions, and by making the notion of evolutions styles a first-class entity that can be formally defined, we can provide automated assistance for expressing architecture evolution, and for reasoning about both the correctness and quality of evolution paths.