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
Participation Forms
Participation in the workshop can be done in one of three ways:
· by submitting a position paper of 1-4 pages that address any of the relevant topics related to the workshop. Participants who are submitting position papers will have the opportunity to present their experiences or findings at the workshop. Submissions must be either MS-Word or RTF formats (please, DO NOT compress files).
- by sending an email to the workshop chair describing their relevant experience in the area. The organizers will select some of those applicants to join the workshop, based on the experiences, positions or ideas stated in the email.
- by just attending the workshop and participating in active discussions. However, this kind of participation is limited by the number of available places. Preferences will be given to participants of the above two forms.
To foster lively discussions, participants are encouraged to present open questions and one or two main statements that shall be discussed at the workshop. Accepted papers will be published in the workshop proceedings as a technical report at the University of Nebraska-Lincoln,
USA
. The length of the Camera-Ready papers should follow the IEEE two-column template (http://computer.org/author/psguide.htm) and are limited to 4 pages
For more information please check
<http://www.engr.sjsu.edu/~fayad/workshops/ AICCSA05 > or <http://www.activeframeworks.com/publications.html#workshops>
You may also contact the organizers.
IMPORTANT DATES -- Will be updated based on acceptance process
Submission deadline
August 15, 2004
Acceptance notification
September 26, 2004
Camera ready paper due
October 13, 2004
Conference registration
October 15, 2004
Please see the conference registration page
Conference registration page Link
Workshop date:
January 3, 2005
Organizers
ORGANIZERS
Dr. Mohamed E. Fayad - CHAIR
Professor of Computer Engineering
Computer Engineering Dept.,
College
of
Engineering
San José
State
University
One Washington Square
,
San José
,
CA
95192-0180
Ph: (408) 924-7364, Fax: (408) 924-4153
E-mail: m.fayad@sjsu.edu, fayad@activeframeworks.com
http://www.engr.sjsu.edu/fayad
Haitham Hamza – Co-Chair
Computer Science & Engineering Dept
University
of
Nebraska
, Lincoln
115
Ferguson
Hall,
P.O. Box 880115
,
Lincoln
,
NE
68588-0115
Ph: (402) 472-3485 (office)
E-mail: hhamza@cse.unl.edu
