Software A Stability Model Pattern
Ahmed Mahdy and Mohamed E. Fayad Computer Science and Engineering Dept. University of Nebraska-Lincoln Lincoln, NE 68588, USA [e-mail]
Abstract
Building quality software systems has been the focus of many in the field of software engineering. One of the most desirable quality attributes, yet hardest to achieve, is stability [2, 8]. A stable basis provides a foundation for building quality software. The Software Stability approach addresses this issue [6, 7]. The key contribution of this paper is to show how the concepts behind software stability can be used to build stable models.
1. Pattern Name: Software Stability Model (SSM)
This pattern describes how a stable model is built based on the software stability criteria and how to intelligibly present the software stability artifacts.
2. Context
The need for stable models arises in the analysis of problems affected by stability. Model-based reuse is a good example [1]. Building stable architectures is another instance. According to the vision behind introducing software stability, a stable model should be a must for the modeling of any software system [6, 7]. Software Stability Model is usable whenever software stability is used to model a system. This is true because SSM reflects the essential elements of a stable model in terms of the concepts of software stability.
3. Problem
Given a system that needs to be modeled using software stability, how do you translate the components of the system into stability artifacts? A SSM is partitioned into three different levels: Enduring Business Themes (EBTs) [5], Business Objects (BOs), and Industrial Objects (IOs). The EBTs represent elements that remain stable internally and externally. The BOs are objects that are internally adaptable but externally stable, and IOs are the external interface of the system [6]. These artifacts develop a hierarchal order of the system objects, from totally stable at the EBTs level to unstable at the IOs level, through adaptable yet stable at the BOs level. The stable objects of the system are those that do not change over time.
We can also look at the problem from the perspective of tangibility. In addition to the conceptual differences between EBTs and BOs, a BO can be distinguished from an EBT by tangibility. While EBTs are completely intangible concepts, BOs are partially tangible. IOs are tangible objects. Despite the fact that stability artifacts differ by definition, recognizing them is very arduous. The problem comes from the fact that their definitions are more conceptual than concrete. Moreover, the terms stability and tangibility are hard to visualize, and in many cases are relative. Consequently, people tend to misjudge whether a given element of the system is an EBT, a BO, or an IO. A wrong assignment of an element is directly reflected in the correctness of the model. Figure 1 shows an imaginary picture of how the stability artifacts interlace at the boundaries. SSM aims at resolving the confusion of how to distinguish the EBTs, BOs, and IOs from one another.
Figure 1. Stability Artifacts Interlacing
4. Forces
SSM needs to ensure stability. To achieve this goal, SSM should capture the core knowledge of the system so that a stable core can be built. Among the three artifacts of stability, EBTs and BOs reveal the core knowledge. Consequently, the distinction between the EBTs and BOs from one side and IOs from the other side and between EBTs
2
and BOs should be maximized in order to avoid drawing a cloudy image of the system core. The interrelations between the EBTs, BOs, and IOs are hard to realize by nature. This is because the three levels conceptually differ. How an EBT could interact with a BO? Or what is the relation between a BO and an IO? This type of questions needs to be addressed. Software stability aims at accomplishing system reusability [3]. In fact, the way stable models are built should guarantee reusability [1]. Software stability provides a stable core that can serve applications sharing similar core structure [4]. SSM needs to realize what objects of the stable model to be reused and show how to present them. In addition to the stability and reusability characteristics, SSM needs to distinguish the system components according to the tangibility level. SSM has to resolve these characteristics and ensure consistency. A contradiction between any of these characteristics results in a flawed model. For a system to be reusable, a level of abstraction at which the EBTs, BOs, and IOs are identified has to be configured. Otherwise, the objects of the different levels would interchange positions to result in a non-reusable system. The system would be nonreusable because the modeled core encompasses non-stable elements or/and nonstructural components represented by the IOs of the system.
5. Solution
To better visualize SSM, we show first a figure representing the architecture of a stable model according to the stability and tangibility properties of its components. As shown in Figure 2, the EBTs represent the nucleus of the model as they reflect the enduring concepts of the system, while the IOs portray the surface of the system. The BOs lay in between. Intuitively, the further the objects are placed from the interface the more stable and intangible they are.
3
Figure 2. Stable Models Architecture
IOs BOs EBTs
Less Stable/More Tangible
5.1 Participants EBTs Represent the enduring themes of the system. Comprise the stable and intangible objects of the system. Describe the major goals of the systems. BOs IOs
Comprise the partially tangible objects. Comprise the internally unstable though externally stable objects.
Depict the surface of the system. Represent the physical objects. Comprise the unstable objects.
The interactions between the EBTs and BOs form a crucial part of the system. The transition from a conceptual theme to a business-driven object has a great influence on the whole system. An inappropriate transition might diminish one or more of the system objectives, which results in a defective system. These transitions are hard to realize as the EBTs and BOs share the intangibility properties of the system components, the EBTs are fully intangible while the BOs are partially intangible. Such commonality hazes the
4
distinction between them. On the other hand, direct interactions between the EBTs and IOs are inappropriate. They interact through the BOs. The IOs embody the BOs as they become totally tangible. 5.2 Structure Figure 3. Software Stability Model Pattern
EBTs 0..* concrete 0..* BOs 0..* embody 0..* IOs
In addition to the object model, the process of building a stable model can be summarized as follows: To find the EBTs, one needs to answer the question What is this system for? The BOs are the answer to What is the representation of the intangible conceptual themes into more concrete objects? The IOs answer What is the physical representation of the BOs? The object model is partitioned into three columns; each column is dedicated to one of the artifacts (i.e. EBTs, BOs, and IOs). Each column encloses the object of its level. This way makes it easier to realize the different components of the system especially in the case of reusing the model to build a new system. Another benefit is avoiding the inappropriate associations among the objects of each level (i.e. an association between an EBT and an IO).
5
5.3 Collaborations The BOs map the conceptual themes of the EBTs into objects. The IOs physically represent the BOs.
6. Example
This case models a generic simulator. We follow the SSM process of building stable models. Consequently, we need to answer the three questions in order to identify the EBTs, BOs, and IOs of the system. What is this system for? This system is to model the chemical reactions behavior in order to simulate and/or experiment specific instances. Therefore, the EBTs are modeling, simulating, and experimenting. What is the representation of the intangible conceptual themes into more concrete objects? The theme modeling conceptually refers to a model. Experimenting needs some criterion to make it alive. To simulate the function of that model according to this criterion, a test should follow a procedure. Accordingly, the BOs are model, criterion, test, and procedure. What is the physical representation of the BOs? A model could be either a mathematical model or a computer-based model. A procedure is represented in terms of a hypothetical or an actual scenario, a predetermined accuracy, and a set of conditions. A test is represented in terms of its results, which take the form of graphs or/and text.
Figure 4 shows a stable model of this example.
6
Figure 4. Simulation Stable Model EBTs BOs IOs
Mathematical Modeling build 1..* 1..* Model Comput er 1..* run on simulate 1..* Test 1..* Simulating simulate 1..* generate 1..* set 1..* Experiment Condition output Simulation Result Textual Graphical
ExperimentProcedure 1.. * develop imitate 1.. * Experimenting based on 1..* Criterion 1..* Scenario Hy pothetical Actual tolerate Accuracy
The above example shows how SSM builds a stable model. In the following, we present three case studies to illustrate how SSM insures reusability among applications with similar cores; these case studies are introduced in [1]. The core knowledge is represented by the EBTs and BOs. Thus, systems sharing the core knowledge should share also the EBTs and BOs, and this is what these cases show. Case I: Computers Trading This case demonstrates trading computers through a bidding process. One entity specifies its needs; another entity places a bid on such specifications. A negotiation process takes place until a deal/impasse is reached. The process of building a stable model is similar to that of the generic simulator. Figure 5 shows a stable model.
7
Figure 5. Computers Trading Stable Model EBTs BOs IOs
1..* Inspection
Features
*
1..*
Accessories
1.. *
Computers
modify Trading deal trade
addendum
Packages
1..*
Peripherals
Agreement agree 1..* 2..*
Individual
Negotiation
negotiate
2.. *
User
1..* bid *
ComputerShop
Bidding
regulate
0..*
Bid
Case II: Buying a House This case depicts a system for buying houses through bidding too. Case I and Case II look different though buying a house involve bidding, negotiation, trading etc. In fact, both case studies share the same core. Thus, the answers to the first and second questions of the SSM process are the same. Figure 6 presents a stable model.
8
Figure 6. Buying a House Stable Model EBTs BOs IOs
Inspection
Features * modify
1..*
House
addendum
Trading
deal
Agreement
trade 1..* Negotiation negotiate 2..*
agree 2..* User 1..* bid
Individual
Contractor
Broker * Bidding regulate 0..* Bid
Case III: Bidding on a Football Team Again, this case study appears different from the other two case studies but it shares the core with them. When you buy a football team, you are trading, negotiating, and bidding. So buying a football team is not that different from buying a computer. Thus, the EBTs and BOs are the same. Figure 7 shows a stable model of this case.
9
Figure 7. Bidding on a Football Team Stable Model EBTs BOs IOs
1..*
Inspection
Features
* modify addendum
1..*
Team
Member
Properties
Play er Manager Staff
Trading
deal
Agreement
t rade 1..*
Equipment
agree 2.. *
Field
Individual
Negotiation
negotiate
2..*
User
1.. * bid *
Sponsor
Bidding
regulat e
0..*
Bid
Although the three case studies deal with different types of trading, the inner core is the same among these applications. Recognizing this fact results from how software stability approaches the problem domain. Identifying the system EBTs directly reflects the goals of the application. If different applications share the same goals, it would be easy to determine their similarities by following the stability approach. Moreover, the BOs will generally be the same. The only differences appear at the IOs level. In our case studies, the three applications have the same EBTs and BOs. Figure 8 plots the three stable models on top of each other to show their similarities. The way SSM builds stable models assures reusability among common-core applications. The answers to the first and second questions reveal the core knowledge of the system. As a result, the systems with similar cores must have similar answers. Without these questions it is hard to figure out how similar these systems are. As a consequence, SSM maintains the reusability properties of the software stability approach. More important is how the collaborations between the EBTs and BOs recur. The three case studies show how the interrelations remain the same as long as the core remains stable.
10
Figure 8. Combined Stable Models EBTs BOs IOs
Peripherals
1..* 1..*
Computers
Properties
1..*
1..*
1..*
Inspection
Features
* modify addend...