Untitled Document
 

Call for Papers (Detailed)
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 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 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.

The workshop will debate several issues related to stability based on several columns are published in Fayad-CACM Thinking Objectively column, made several claims related to software stability model, such as how to build a stable software systems, how to generate stable model-based architectures, and many other issues:
  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. M.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
We want researchers, framework developers, and application developers to answer the following questions:
  1. Are the various claims related to software stability [in CACM's columns] true?
  2. Are the various claims related to stable software patterns [in CACM's columns] true?
  3. Are the various claims related to relationships between aspect-oriented architectures and programming and software stability [in CACM's columns] valid?
  4. Are the various claims related to the impact of software stability on scalability [in CACM's columns] legitimate?
  5. Are the various claims related to software stability model and extreme programming [in CACM's columns] accurate?
  6. What are the relationships between software architecture and software that been stable over time?
  7. How to apply software stability with UML?
  8. What are the relationships between software stability and reuse?
  9. What are the relationships between software stability and integration?
  10. How can we apply software stability to create stable and timeless architectures as model-based for reuse for any field of knowledge?
  11. How can we should how to engineer and model any software entirely as systems of patterns?
  12. What are the relationships between software that been stable over time and management workflow?
  13. How can we achieve software stability over time and extend the life span of software products?
  14. What are the relationships between software that been stable over time and business objects?
  15. What is the role of object-oriented techniques and technologies of making software stable over time?
  16. What are the approaches of making software stable over time?
  17. What is the relationship between software stability and various new technologies, such as aspect-oriented architecture and programming, constraints programming, multi-agent-oriented software developments, component-based software developments, and others?
  18. What is the relationship between application frameworks and software stability?
  19. What are the impacts of software stability on understanding the customers' needs?
  20. What are the impact of software stability on scalability, customizability, extensibility, Integra ability, and configurability?

Paper Format and Submission

People interested in participating in the workshop are requested to submit a short position paper (3-5 pages) or regular workshop papers (limited to 8 pages, double space, including figures) representing views and experience relevant to the discussed topic. The paper should be formatted using the IEEE two-column template (provided at the conference webpage). The title page should include a maximum 200-word abstract, five keywords, full mailing address, e-mail address, phone number, fax number, and a designated contact author. Papers will be selected depending on the originality, quality and relevance for the workshop. Interesting papers will be peer reviewed by 4 reviewers and selected by the organizers and their authors will have the possibility to give a 20 minute presentation of them at the workshop. To foster lively discussions, each author is encouraged to present open questions and one or two main statements that shall be discussed at the workshop. Submissions must be either MS-Word or RTF formats (please, DO NOT compress files).

Depending on the number and spread of contributions, the scope may be narrowed to ensure effective communication and information sharing. Accepted position papers will be published in the workshop proceedings to be distributed to the participants before the workshop, and made generally available through WWW and FTP. A workshop report will be published in the addendum proceedings of the conference.

Please note that workshop participants must register at least on that day at UML conference. Early registration discount is available. We will have an overhead projector, and a flipchart available.

Please note that the deadline for the final version is hard.

For more information please check:
  • http://www.engr.sjsu.edu/~fayad/workshops/iri03
  • http://www.activeframeworks.com/publications.html#iri03
You may also contact the organizers.

Proposed Agenda

A tentative schedule follows:
  1. Welcome and introduction of participants. The organizers will first give a short overview of open issues and of the main arguments arising out of the position papers. (estimated time: 20-30 minutes)
  2. Selected authors (representing the main trends) will be given about 20 minutes to explain how their position relates to other positions and what each sees as the three major issues. We count on having about 5-10 position papers. (Estimated time: 120-130 minutes)
  3. The organizers will propose an identification of the major issues, and the participants will then discuss and select what they hold to be the hottest issues to be examined. (Estimated time: 10-15 minutes)
  4. Next, the participants will work for 70-80 minutes in small groups, with a designated moderator in each group. The groups will each deal with two different hot issues identified, and will produce a summary in the form of points and counterpoints, showing either how several views are irreducibly opposed or how they are complementary. The number of groups will depend on the number of participants and number of issues selected; ideally there should be 3-5 persons in each group. (Estimated time: 75-90 minutes)
  5. Each group will present in 10-15 minutes its findings to all participants, followed by a closing discussion. The workshop report will be written on the basis of these findings and will include an agenda for future exploration and cooperation; it will be made available through WWW and FTP. (Estimated time: 50-60 minutes for five teams)
(Total estimated time: 285-315 minutes, i.e. about five hours +/- 15 minutes, Lunch and breaks are not included.)

Important Dates:

Submission deadlineAugust 15, 2003
Acceptance notificationSeptember 1, 2003
Camera-ready paper due  September 14, 2003
Workshop date:October 27 or 28, 2003

Organizers:

Chair and Point of Contact:
DR. MOHAMED E. FAYAD (primary contact)

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

DR. MARSHALL CLINE - CO-CHAIR
MT Systems Co., 5419 Bent Tree Dr., Dallas, TX 75248
Ph1: 972-931-9470 (office), Ph2: 972-880-9369 (cell)
E-mail: cline@parashift.com