Overview

Abstract:

 

There are two issues will be debated in this workshop: Software Stability Model and Stable Analysis Patterns: a True Problem Understanding with UML.

Software stability concepts, introduced by me with the aid of UML, have demonstrated great promise in the area of software reuse and lifecycle improvement. Software stability models apply the concepts of  “Enduring Business Themes” (EBTs) and “Business Objects” (BOs). These concepts have been shown to produce models that are both stable over time, and stable across various paradigm shifts within a domain or application context.  By applying stability model concepts with UML to the notion of analysis patterns we propose the concept of Stable Analysis Patterns. The idea behind the stable analysis patterns is to analyze the problem under consideration in terms of its EBTs and the BOs with the goal of increased stability and broader reuse. By analyzing the problem in terms of its EBTs and the BOs, the resultant pattern models the core knowledge of the problem.  The goal of this concept is stability.

 

Software analysis patterns play a major role in reducing the cost and condensing the time of software project lifecycles. However, building reusable and stable analysis patterns is still a challenge. This workshop examines the novel concept of Stable Analysis Patterns as a new approach for building stable and reusable analysis patterns with UML.

 

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.

 

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.      M.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.      M.E. Fayad. Accomplishing Software Stability, Communications of the ACM, Thinking Objectively, Vol. 45, No. 1, January 2002.

3.      M.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 that been stable over time and management workflow?
9. How can we achieve software stability over time and extend the life span of software products?
10. What are the relationships between software that been stable over time and business objects?
11. What is the role of object-oriented techniques and technologies of making software stable over time?
12. What are the approaches of making software stable over time?
13. 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?
14. What is the relationship between application frameworks and software stability?
15. What are the impacts of software stability on understanding the customers’ needs?
16. What are the impact of software stability on scalability, customizability, extensibility, Integra ability, and configurability?

Stable Analysis Patterns:

This workshop examines software stable analysis patterns with respect to four central themes:

 

1.      How can we understand and model the problem through software stability concepts and UML?

 

The workshop discusses how to use software stability concepts, with the aid of UML, for modeling the core knowledge of the problem. It shows the reader how to analyze the problems in terms of its Enduring Business Themes (EBTs), and Business Objects (BOs) using UML. In addition, it shows how to glue these components together to build a stable model.

 

2.      What are the unique roles of stable analysis patterns in capturing the core knowledge of the problem at hand and in providing stable and undisputed solutions for such problems on the other hand?

 

The workshop examines a complete and domain indpendent list of stable analysis patterns that are provided by the workshop organizers and they are useful for problem understanding and modeling with UML. Each pattern will illustrate how to capture the core knowledge and to address the issues underneath the surface of the problem. In addition, the workshop discusses the different design issues that will smoothly transfer the stable analysis pattern into the solution space (the design phase) using UML.

 

3.      How can we achieve software stability over time and build stable analysis patterns that can be effectively reused?

 

The use of the Enduring Business Themes (EBTs) and the Business Objects (BOs) has proven to construct models, with the aid of UML, that are both stable over time, and stable across various paradigm shifts within a domain or application context.   Since the idea behind the stable analysis patterns is to analyze the problem under consideration in terms of its EBTs and the BOs the resultant stable patterns will capture the core knowledge of the problem. Moreover these stable patterns can be reused to model the same problem in any context.

 

4.      What is the most efficient way for documenting the stable analysis patterns in order to ensure efficient reusability?

 

The workshop examines the proposed and new documentation template by the organizers for the stable analysis patterns. The proposed template provides a complete description for each presented analysis pattern. This description utilizes several modeling artifacts using UML to insure the clarity of the pattern. It provides: the static models (i.e., UML class diagrams and object diagrams), the dynamic models (i.e., UML sequence diagrams and state charts), the use case diagram, the use case descriptions, and the Collaboration and Responsibility Cards (CRC) for each pattern. This detailed description will increase the reusability of the proposed patterns. The new documentation template will be provided to the workshop participants to examine.

 

The workshop will debate several issues related to stable analysis patterns based on several columns are published in Fayad-CACM Thinking Objectively column, made several claims related to stable analysis patterns, such as how to identify and classify analysis patterns and distinguish them from any other patterns, and many other issues:

1.      M.E. Fayad and H. Hamza. “Software Stability Background,” White Paper, 2002.

2.      M.E. Fayad and H. Hamza. “Introduction to Stable Analysis Patterns,” Communications of the ACM, December 2003.

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 “A Foundation For Building Stable Analysis Patterns.” Master thesis. University of Nebraska-Lincoln, 2002

5.      H. Hamza and M.E. Fayad. "A Pattern Language for Building Stable Analysis Patterns”, 9^th Conference on Pattern Language of Programs (PLoP 02), Illinois, USA, September 2002.

 

We want researchers in patterns’ communities, framework developers, and application developers to answer the following questions: 

1. Are the various claims related to stable analysis patterns true?
2. What are the relationships between stable analysis patterns using UML and software that been stable over time?
3. What are the approaches of making software stable over time?
4. What are the differences between current analysis patterns and stable analysis patterns?
5. What are the impacts of stable analysis patterns using UML on understanding the customers’ needs?
6. What are the impact of stable analysis patterns using UML on scalability, customizability, extensibility, Integra ability, and configurability?
7. How to distinguish between stable analysis patterns and stable design patterns?
8. Taken testability, verification, and validation as criteria, what are the differences between current analysis patterns and stable analysis patterns?
9. What are the major roles of using UML for generating stable analysis patterns?
10. How can we achieve software stability over time and build stable analysis patterns that can be effectively reused?
11. How can the stable analysis pattern capture and model the core knowledge of the problem with the aid of UML?
12. How can we achieve the necessary level of abstraction using UML that makes the resultant analysis patterns effectively reusable, yet easy to understand?
13. What is the necessary information that analysis patterns should provide in order to ensure a smooth transition from the analysis phase to the design phase?
14. What is the most efficient way to describe analysis patterns in order to make them easy to understand and reuse?