Legacy System Migration

1
Legacy System Migration
2
What to keep?

• General, what you see on that board is not
  reality. It is a computer-generated
  hallucination! line from War Games
• All large-scale information systems operate in a
  broader organisational/business context
• Where this is ignored then, over time, inputs and
  outputs will conflict with the reality

3
Data Quality

• When migrating a large-scale system then usually
  something of value needs to be kept
• most often data
• less often embedded, highly prioritised process
• There is a need to audit the data to ensure its
  quality

4
Ken Orrs Data Quality Rules

• DQ1. Unused data cannot remain correct for very
  long
• DQ2. Data quality in an information system is a
  function of its use, not its collection
• DQ3. Data quality will, ultimately, be no better
  than its most stringent use
• DQ4. Data quality problems become worse as the
  system ages
• DQ5. The less likely some data element is to
  change, the more traumatic change will be
• DQ6. Laws of data quality apply equally well to
  meta-data
• Summary Use it or Lose it!

5
Use-based Data Quality Audits

• What data are we interested in?
• What is the data design?
• What is the data model?
• What is the metadata?
• How is the data used today?
• Who uses it?
• For what purposes is the data used?
• How often is the data used?
• What is the data quality?
• What is in the database?
• How does it compare with current data in the real
  world?
• How current is the data?

6
Implications for Migration

• Existing legacy data needs to be mapped to the
  problem space
• Data quality is established by looking at system
  behaviour
• Therefore build an Object-oriented Analysis
  Model of the legacy system and its
  business/organisational context
• This can be done using Use Cases to model
  business processes and system behaviour

7
Use Cases

• Developed at Ericsson by Ivar Jacobson to help
  build long-lived, flexible telecoms systems
• Premise the most volatile part of a system is
  its users behaviour
• Conclusion Model systems from the point of view
  of its interactions with its users
• Use cases part of the Objectory method, and now
  in UML

8
Use Case Texts and Diagrams

• A Use Case is a textual description of an
  interaction between a system or sub-system and
  one or more of its users.
• Users need not be human, can be other systems
• More generally, an Actor is a User in a role
• Theoretically, a complete set of Use Cases is a
  complete black box description of functional
  requirements

9
An Example Use Case Diagram
An ATM application which offers three use cases
is shown. The possible communication between the
Actor (Bank Customer) and use case instances are
shown by bi-directional ltltcommunicationgtgt
associations.
Deposit Money
Withdraw Money
Transfer Between Accounts
Bank Customer
10
Example Use Case for Withdraw Money
The Bank Customer chooses a Withdrawal option.
The ATM Interface asks the Customer to identify
herself and verifies her ID with the system. If
the ID is verified, the ATM interface asks the
Bank Customer to select the amount to be
withdrawn from Account. The ATM interface
requests the withdrawal amount from the system.
The system asks the Account to validate the
request and, if possible, withdraws the
amount. The system then asks the Dispenser to
dispense the appropriate amount.
11
Use Case-driven Development

• Problem statement is mapped to Use Case texts and
  diagrams
• Candidate classes extracted from Use Cases
• OO Analysis model constructed and subjected to
  robustness analysis
• objects categorised as boundary, entity or
  control objects
• OO Design and Implementation follows
• Changes traced back to requirements via Use Cases

12
Problems with Use Cases

• How broad is a use case?
• How deep is a use case?
• How many use cases should there be in some
  typical system?
• Can be confused with DFDs
• Can lead to main sub-programs through
  misinterpretation of control objects

13
Task Scripts A more rigorous alternative?

• Ian Graham offers Task Scripts as an alternative
  to Use Cases.
• Task Scripts are
• semiotic
• prototypical
• can be classified as objects with subscripts and
  side-scripts
• use SVDPI sentences
• Subject Verb Direct.object Preposition
  indirect.Object

14
Anatomy of a Task Script

• Task scripts may be one sentence or an essay
• Task analysis decomposes complex scripts to
  atomic scripts
• Atomic scripts should ideally be in SVDPI format
• There may be subscripts
• There may be side-scripts to deal with exceptions
• Textual analysis is used to discover objects and
  their behaviour
• Any logical attributes and associations should be
  recorded (if known)

15
Examples of Atomic Task Scripts

• The trader enters the counterparty details
• The system manager changes the authorisation of
  the trader
• The user selects Edit using the mouse
• The driver turns left using the wheel.