Stable Model-Based Software Design for Reuse and Maintenance

1
Stable Model-Based Software Design for Reuse and
Maintenance

• Majid Nabavi
• University of Nebraska

2
The Project Starts

• Goal Developing a system that automates business
  process in part or totally, keeps track of
  operational data,
• Systems analysis and design
• Initial steps of the software lifecycle
• Requires extensive domain knowledge and insight
• Identifies business processes
• Clarifies the limits of the system
• Essential for determining software architecture
• To determine the project requirements as well

3
Systems Analysis and Design

• What is different?
• Analysis
• Problem space
• Analysis
• One problem
• The What

• Design
• Solution space
• Design
• Many solutions
• The How

• Systems analysis is traditionally based on the
  present business processes

4
Business Process

• Business processes are subject to change
• Technology
• Business model
• Scope and intensity of change may not be
  identified from the beginning
• When change in work system happens, the software
  system should change too

5
Maintenance, Upgrade, Reusability

• Decision depends on scope of change
• Maintenance is a high cost item even for
  standardized software modules, at least 25
• Up to 70 commonality between software modules
• If upgrade or design a new system, how to reuse
  modules?
• The modules should have been designed right in
  the first place to be reusable without extensive
  rework

6
Stability Model

• Object oriented modeling popular and supported
  by CASE tools
• Consider probability of future extension and
  change in systems analysis and design
• Classify objects in the system
• Enduring Business Themes (EBT)
• Business Objects (BO)
• Industrial Objects (IO)

7
Identification Criteria for Objects
8
How the Stability Model Helps?

• The core methods and attributes of the system
  will go to EBTs and BOs
• The EBTs and BOs dont change easily
• If add or obsolete IOs the system is stable
• Longer life cycle
• Lower costs of maintenance, upgrade, and redesign

9
Case Study

• A control and dispatching system for material
  transport
• Ore waste go to different destinations
• Need scheduling
• Data gathering

10
Traditional Model Works Well

• All objects and relationships in the model
• Represents the current system

11
Stable Model

• More complicated

12
First Change New Technology
13
Stable Model Merge The Changes
14
Second Change Different Technology

• No similarity in model
• No merging possible
• Extensive update effort
• Redesign the system

15
Stable Model Merge the Changes
16
More Extensions
17
Stable ModelMerge The Changes
18
Conclusion

• In stable modeling
• Abstract classes designed to explain the core
  purpose of the system
• Modeling does not conclude to the solution of
  present problem
• System is adaptable and extensible
• System stays in service for a longer time
• When upgrading, modules are reusable
• Eliminates need for designing a new system
• Reduces the scope of reengineering
• Investing in analysis and design can well pay off
  in time of change, by reducing maintenance and
  upgrade efforts

19
(No Transcript)