Abstract:
In the development of software, architecture has been conceptualized largely as a fully preplanned and imposed structure. However, planning is so difficult in our chaotic world that successful software projects must continually adapt to the shifting conditions of technology and the market. Consequently, software projects must admit the need to restructure their systems to introduce structure as needed as well as find architecture where none was seen before. By delaying the introduction of costly architecture, software projects can get to market more quickly, developing a customer base to fund future architectural efforts and providing much neededfeedback on what architecture would be appropriate. 1 Problem: Planning in an Uncertain World Our technologyinfrastructure hasbecomeso highly evolvedthat the changes it induces are perceptible daily. Change is now so rapid and unpredictable that it is nearly impossible to perform effective longterm planning. A business's commitment to a partic...
Citations
|
852
|
On the Criteria to be Used in Decomposing Systems into Modules
– Parnas
- 1972
|
|
715
|
A spiral model of software development and enhancement
– Boehm
- 1986
|
|
225
|
Software reflexion models: Bridging the gap between source and high level models
– Murphy, Notkin, et al.
- 1995
|
|
209
|
On the Design and Development of Program Families
– Parnas
- 1976
|
|
111
|
Beyond the Black Box: Open Implementation
– Kiczales
- 1996
|
|
82
|
Automated Assistance for Program Restructuring
– Griswold, Notkin
- 1993
|
|
68
|
Program Restructuring to Aid Software Maintenance
– Griswold
- 1991
|
|
43
|
Reconciling environment integration and component independence
– Sullivan, Notkin
- 1990
|
|
38
|
Design Paradigms: Case Histories of Error and Judgment in Engineering
– Petroski
- 1994
|
|
37
|
Mediators: Easing the Design and Evolution of Integrated Systems
– Sullivan
- 1994
|
|
32
|
Tool support for planning the restructuring of data abstractions in large systems
– Griswold, Chen, et al.
- 1996
|
|
31
|
Supporting the restructuring of data abstractions through manipulation of a program visualization
– Bowdidge, Griswold
- 1998
|
|
31
|
A reverse engineering environment based on spatial and visual software interconnection models
– Muller, Tilley, et al.
- 1992
|
|
21
|
Automated support for encapsulating abstract data types
– Bowdidge, Griswold
- 1994
|
|
21
|
Architectural tradeoffs for a meaning-preserving program restructuring tool
– Griswold, Notkin
- 1995
|
|
20
|
Lightweight Structural Summarization as an Aid to Software Evolution
– Murphy
- 1996
|
|
11
|
Semi-automatic update of applications in response to library changes
– Chow, Notkin
- 1996
|
|
9
|
How software tools organize programmer behavior during the task of data encapsulation
– Bowdidge, Griswold
- 1997
|
|
6
|
Economics of Software Reuse Revisited
– Malan, Wentzel
- 1993
|
|
5
|
Direct update of dataflow representations for a meaningpreserving program restructuring tool
– Griswold
- 1993
|
|
4
|
Program Analysis for Practical Program Restructuring
– Morgenthaler, Griswold
- 1995
|
|
3
|
Why black boxes are so hard to reuse: A new approach to abstraction for the engineering of software. Videotape. Selections from OOPSLA '94
– Kiczales
- 1994
|
|
1
|
On systems architecture
– DeMarco
- 1995
|
