---------- Forwarded Message ----------
Subject: (SEWORLD) UML'03 Ist Workshop on Software Stability and Stable Analysis Patterns Date: Sat, 17 May 2003 15:07:08 -0500 (CDT) From: Mohamed Fayad fayad@cse.unl.edu To: Undisclosed recipients: ;
== Sorry for multiple copies == _____________________________________________________________________ UML '03 First Workshop on Stable Analysis Patterns: A True Problem Understanding with UML Call for Papers UML '03 Full day workshop UML 2003 Sixth International Conference on UML - Modeling Languages and Applications October 20-24, 2003, San Francisco, USA http://www.umlconference.org/ (UML' 03 Link) http://www.engr.sjsu.edu/~fayad/workshops/UML03 http://www.activeframworks.com/publications/workshops/UML03 _____________________________________________________________________
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", 9th 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?
PAPER FORMAT AND SUBMISSION
People interested in participating to the workshop are requested to submit a short position paper (3-5 pages) or regular workshop papers (limited to 10 pages, double space, including figures) representing views and experience relevant to the discussed topic. 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 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). In alternative, initial submission can by done by emailing a URL pointing to an HTML version of the paper.
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, computer projector, and a flipchart available.
For more information please check http://www.engr.sjsu.edu/~fayad/workshops/UML03 or <www.activeframeworks.com/publication/workshops/UML03>
You may also contact the organizers.
PROPOSED AGENDA A tentative agenda 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 major issues. We count on having about 5-10 position papers' presentations. (Estimated time: 140-150 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: 20-30 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 15-20 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: 60-75 minutes for four-five teams)
(Total estimated time: 315-345 minutes, i.e. about six hours +/- 15 minutes, Lunch and breaks are not included.)
IMPORTANT DATES
Position papers due on or before: September 1, 2003 Notification of acceptance/rejection: September 17, 2003 Camera-ready papers due September 30, 2003 Workshop date: October 20, 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, www.activeframeworks.com
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
============================================================ To contribute to SEWORLD, send your submission to seworld@cs.colorado.edu.
http://www.cs.colorado.edu/serl/seworld provides more information on SEWORLD as well as a complete archive of messages posted to the list.
To subscribe to SEWORLD, send the following (as the body of a message) to seworld-subscribe@cs.colorado.edu:
subscribe seworld <desired e-mail address> end
To unsubscribe from SEWORLD, send the following (as the body of a message) to seworld-unsubscribe@cs.colorado.edu:
unsubscribe seworld <registered e-mail address> end ============================================================
-------------------------------------------------------