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:
- Are the various claims
related to software stability [in CACM’s
columns] true?
- Are the various claims
related to stable software patterns [in CACM's
columns] true?
- Are the various claims
related to relationships between aspect-oriented architectures and
programming and software stability [in CACM's
columns] valid?
- Are the various claims
related to the impact of software stability on scalability [in CACM's columns] legitimate?
- Are
the various claims related to software stability model and extreme
programming [in CACM's columns] accurate?
- 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?
- How can we achieve
software stability over time and extend the life span of software
products?
- What are the
relationships between software that been stable over time and business
objects?
- What
is the role of object-oriented techniques and technologies of making
software stable over time?
- What are the approaches
of making software stable over time?
- 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?
- What is the
relationship between application frameworks and software stability?
- What are the impacts of
software stability on understanding the customers’ needs?
- 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/publications.html#workshops>
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 25, 2003
Notification of
acceptance/rejection: September 30, 2003
Camera-ready papers due October
10, 2003
Workshop date: October 20, 2003
ORGANIZERS
Chair and Point of
Contact:
Dr. Mohamed E. Fayad
(primary contact)
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
