Untitled Document
 

Overview
Abstract:

This workshop will examine how software stability can be applied with UML and discuss a pattern language for how to be creative with software stability and UML to create timeless architectures, systems of patterns, and model-based for reuse and integration. It examines how software stability provides a way for building stable systems using UML.

Software stability model (SSM) consists of three levels: Enduring Business Themes (EBTs), Business Objects (BOs), and Industrial Objects (IOs). EBTs represent intangible objects that remain stable internally and externally and they are definitely stable analysis patterns. BOs are objects that are internally adaptable but externally stable and they are stable design patterns. IOs are considered as implementation and applications specific classes. The way SSMs are built directly guarantees system reusability and shows how to build any system as a system of stable analysis/design patterns. The EBTs and BOs can be reused among common-core applications without change. Accordingly, we should be able to build multiple systems that have identical cores.

SSMs using UML can provide a base for building system of patterns that is reusable, stable over time. In addition, it will show, in one picture, how stable analysis/design patterns can be knitting together using UML to develop software systems as systems of patterns.

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?