Overview
Motivations
Developing stable software can alleviate the tremendous projected cost associated with future changes in the system. This workshop will examine software stability with respect to six central themes: "How can we engineer software systems that are timeless and stable overtime?," "What are the approaches of making software systems stable over time?", “How can we build software as a system of stable patterns?, "What are the stable software patterns?", “How can we achieve an timeless, model based architectures for reuse?”, and What are the impact\ relationship of software stability on\with new technologies, such as aspect-oriented architecture and programming, multi-agent technology, constraints-oriented software development, component-based software development, application and enterprise frameworks’ developments, and others.
Background:
I. What is Software Stability?
Current Problems
There is little doubt that software engineering, like all other engineering fields, has helped to make life what it is today. With software controlling more equipment and becoming an integral part of more of our lives, the field of software engineering is quickly becoming more and more important. Unlike many other engineering fields, however, the products produced through software engineering are largely intangible. Also, unlike the products of other engineering fields, software products are unlikely to remain stable over a long period of time.
In hardware areas, the failure rates of products often start high, then drop low, and then go high again. Early in a hardware product's lifecycle, there are some problems with the system. As these problems are fixed, the failure rate of the hardware products drops. However, as hardware gets old, physical deterioration causes the hardware to fail. In other words, the hardware wears out and the failure rate rises again.
Software, on the other hand, is not subject to the same wear and tear that hardware is. There are no environmental factors that cause software to break. Software is a set of instructions, or a recipe, for a piece of hardware to follow. There are no moving parts in software. There is nothing that can physically deteriorate. Software should not wear out. Unfortunately, it does. Countless authors in the field of software engineering have identified this problem. However, the software engineering techniques outlined by many software-engineering authors have not achieved a good amount of stability in software projects.
This problem is more than just an inconvenience for software engineers and software users. The reengineering that is required for these software products does not come without a price. It is not uncommon to hear of these reengineering projects costing hundreds of thousands to millions of dollars. This does not take into account the time that is wasted by this continual reengineering process.
Software defects and “deterioration” are caused by changes in software. Many of these changes cannot be avoided. These changes can be minimized, however. Currently, when a change must be made to a software program, most of the time the entire program is reengineered. It does not matter if the change required is due to new technology or a change in clientele. This reengineering process is ridiculous. The core purpose of the software product has not changed. Why, then, must the entire project be reengineered to incorporate a change?
This workshop will examine software stability with respect to four central themes: "How can we engineer software systems that are stable overtime?," "What are the approaches of making software systems stable over time?", "What are the stable software patterns?", and What are the impact of software stability on new technologies, such as aspect-oriented architecture and programming, multi-agent technology, constraints-oriented software development, component-based software development, application and enterprise frameworks’ developments, and many more.
References and suggested reading in the topic:
1. Mohamed E. Fayad and Adam Altman. Introduction to Software Stability, Communications of the ACM, Thinking Objectively, Vol. 44, No. 9, Sept. 2001, pp. 95-98.
2. Mohamed E. Fayad. Accomplishing Software Stability, Communications of the ACM, Thinking Objectively, Vol. 45, No. 1, January 2002.
3. Mohamed E. Fayad. How to Deal with Software Stability, Communications of the ACM, Thinking Objectively, Vol. 45, No. 4, April 2002.
4. Mohamed E. Fayad and Shasha Wu. Merging Multiple Traditional Models in one Stable Model. Communications of the ACM, Thinking Objectively, Vol. 45, No. 9, Sept. 2002.
5. Mohamed E. Fayad and H. Hamza. “Software Stability Background,” White Paper, 2002
II. What is Stable Analysis Patterns?
Stable analysis pattern is a new approach for developing patterns by utilizing software stability concepts. Stable analysis pattern was proposed as a solution for the limitations of contemporary analysis patterns. The goal of stable analysis pattern was to develop models that capture the core knowledge of the problem and presented it in terms of the EBTs and the BOs of that problem. Consequently, the resultant pattern will inherent the stability features and hence can be reused to capture the essence the same problem whenever it appears.
References and suggested reading in the topic:
1. Mohamed E. Fayad and H. Hamza. “Introduction to Stable Analysis Patterns,” Communications of the ACM, December 2003.
2. H. Hamza “A Foundation For Building Stable Analysis Patterns.” Master thesis. University of Nebraska-Lincoln, 2002 (http://www.cse.unl.edu/~hhamza)
3. H.
Hamza
,
M.E.
Fayad “Model-base Software Reuse Using Stable Analysis Patterns” ECOOP 2002, Workshop on Model-based Software Reuse, June 2002,
Malaga
,
Spain
.
4. H. Hamza and M.E. Fayad. "A Pattern Language for Building Stable Analysis Patterns”, 9th Conference on Pattern Language of Programs (PLoP 02),
Illinois
,
USA
, September 2002.
5. H. Hamza and M.E. Fayad. "Towards a Pattern Language for developing Stable Patterns”, 10 th Conference on Pattern Language of Programs (PLoP 03),
Illinois
,
USA
, September 2002.
Workshop Theme
This workshop will bring together practitioners and researchers who have been involved in the development of stable and adaptable software architectures, or are interested in learning more about the state-of-the-art in software stability and stable patterns.
Papers are invited on both theoretical and practical aspects relevant to software stability. Topics include (but are not restricted to):
· Theories of software stability
· Stable software architectures
· Model-based software reuse
· Impact of stability on software reuse
· Case studies of the building stable software
· Stable software patterns
· Extracting and reusing patterns from developed architectures
· Metrics for the stability of the constructed systems
· Impact of software stability on new technologies (such as aspect-oriented architecture and programming, multi-agent technology, constraints-oriented software development, component-based software development, etc)
· Patterns compositions
