Evolucin de los Sistemas de Informacin

1
Evolución de losSistemas de Información

• José A. Carsí
• Departamento de Sistemas Informáticos y
  Computación
• Universidad Politécnica de Valencia

2
Justificación

• El software debe evolucionar porque los
  requerimientos de los SI cambian.
• El software que se construye en breve quedará
  desfasado.
• En la construcción de todo software se debe
  partir de la premisa de que tendrá que ser
  modificado.
• Todo es volátil

3
Evolución
Adecuación
4
Unas Cifras sobre Evolución

• 70 5 de la gente que trabaja en informática
  McKee 84
• 80 de los gastos totales del software Yourdon
  89
• Estudio del S.I. de un hospital (18 meses)
  Sjøberg 93
• ? del nº de relaciones en un 138
• ? del nº de atributos en un 279
• Todas las relaciones sufrieron modificaciones

5
La Evolución desde el punto de vista de la
Ingeniería de Software
6
Tipos de Cambios

• Correctivos
• Corregir errores del Software
• (Codificación, Diseño, Requerimientos)
• Adaptativos
• Por cambios en el entorno
• Diferentes plataformas HW, Nuevas tecnologías,
  ...
• Perfectivos
• Implementar nuevos requerimientos

7
Lientz 80 y Nosek 90
8
Más caro añadir a posteriori que al principio

• 1. El equipo de mantenimiento no está
  familiarizado con el dominio de la aplicación.
• Pobre imagen del mantenimiento.
• Encargados mantenimiento recién llegados.
• Motivar a la gente hacía el mantenimiento.
• 2. Desarrollos viejos sin las técnicas
  adecuadas.
• No estructurados, optimizados por eficiencia.
• Técnicas de re-ingeniería para descubrir el
  diseño/estructura.

9

• 3. La introducción de cambios degrada la
  estructura.
• Invertir en mantenimiento preventivo.
• Ocultación de la información, Orientación a
  Objetos.
• 4. Los cambios introducen nuevos errores.
• Ejemplo DLL de Microsoft
• Versiones nuevas de DLL introducen nuevos errores
• Setup de Publisher 97 no funciona con una versión
  posterior de MSVCRT40.DLL
• DLL diferentes con el mismo nº de versión con
  errores diferentes
• Richardson 97

10

• 5. Perdida de los enlaces entre la documentación
  y el soft.
• Pobre gestión de configuraciones.
• Adopción del quick fix.

11
El proceso de Mantenimiento
12
La evolución desde el punto de vista de las Bases
de Datos
13

• Evolución
• Modificación del Esquema
• Migración de las poblaciones

14
Edición del Esquema en SGBDR

• Edición Conjunto de primitivas que permiten
  manipular el modelo
• Entidades
• añadir, borrar, cambiar
• Relaciones
• añadir, borrar, cambiar
• Atributos
• añadir, borrar, cambiar (nombres, tipos)

15
Edición en SGBDOO

• Modelo mucho más complejo.
• Encapsulación de datos y comportamiento
• Herencia

16
Taxonomía de los Cambios de las Definiciones de
Clases (ORION)
definición de las clases
nombre de la clase
métodos
atributos
añadir un método
añadir un atributo
borrar un método
borrar un atributo
nombre del método
dominio
código del método
nombre del atributo
valor por defecto
17
Taxonomía de los Cambios en el Grafo de Clases
(ORION)
grafo de clases
derivar nuevas clases
crear una nueva clase / borrar una clase
mover una clase en el grafo
generalización de n clases
juntar n clases
partición en n clases
18
Tipos de Cambios

• Aditivos aquellos que añaden información al
  esquema.
• P.ej. añadir un atributo/evento, ...
• Substractivos aquellos que eliminan información
  del esquema.
• P.ej. borrar un atributo/evento
• Algunos cambios son aditivos y substractivos a la
  vez.
• P.ej. cambiar el nombre de algo.

19

• Independientes de la Interfaz Algunos cambios no
  afectan a la interfaz, por lo que tienen poca
  influencia sobre la evolución del esquema
• P.ej. cambiar el código de un método

20
Clasificación de los Cambios
Cambios Substractivos
Cambios Aditivos
añadir un método
nombre de la clase
nombre del método
dominio
borrar un atributo
nombre del atributo
código del método
borrar un método
cambios en el grafo de clases
valor por defecto
añadir un atributo
Independientes de la Interfaz
21
Invariantes (ORION, GemStone, O2, Chimera, NO2

• Grafo de Herencia Acíclico
• Unicidad de Nombres
• Todas las clases nombres diferentes. Todos los
  atributos y métodos dentro de una clase también
• Origen Único
• Dos atributos o métodos no pueden tener el mismo
  origen en la jerarquía de herencia

22

• Herencia Total
• Compatibilidad de Dominios

23

• Covarianza y Contravarianza de los Parámetros

Csup
... método(AjeTje AjsTjs) ...
Covarianza Tjs ? Tis Contravarianza Tje ? Tie
Csub
... método(AieTie AisTis) ...
24

• Conservación de la Información
• Cuando se va a eliminar una información de una
  clase se informa a los clientes de la misma para
  que puedan seguir funcionando (GemStone, no
  implementado)
• Correspondencia BD-Esquema
• Los objetos deben ser modelo de las fórmulas que
  definen el esquema.

25
Migración de poblaciones

• A. Evolución del esquema
• ORION, GemStone, OTGen, COCOON, ...

EC1
EC2
EC3
EC4
mod1
mod2
mod3
26
Conversión de los objetos

• Inmediata
• Todos los objetos afectados son actualizados
• Diferido
• Los objetos son actualizados cuando son
  accedidos
• Por demanda
• Es el usuario el que decide cuándo y quiénes son
  actualizados

27

• B. Co-existencia de los esquemas
• Avance, Encore, Multiple Views, CLOSQL,
  Multiperspectves, ...
• Versionado
• Mecanismos de Vistas Avanzados
• BD Activas

28
Versionado

• Las modificaciones generan nuevas versiones

E1
E2
Ci
Ci
mod.
los objetos sólo son visibles en el esquema en el
que fueron creados
o1
o3
o2
29
Vistas Ra 94

• Es necesario extender los mecanismos de vistas
  (añadir atributos y métodos)

add_attribute registro for estudiante
30
(No Transcript)
31
BD Activas Maudes 98

• Utilización de reglas ECA para simular la
  evolución.
• Cambio en el Esquema -gt Conjunto de reglas ECA

Esquema
Esquema
ECA
ECA
32
Bibliografía

• Lientz 80 B.P. Lientz, E.B. Swanson, Software
  Maintenance Management, Readings MA
  Addison-Wesley, 1980.
• Maudes 98 J. Maudes, Concepto de Recubrimiento
  como soporte al Versionado Total de Esquemas en
  BDOO, JIDBD, Valencia 1998.
• McKee 84 J.R. McKee, Maintenance as a Function
  of Design, In Proc. AFIPS National Computer
  Conf., Las Vegas, 1984.
• Nosek 90 J.T. Nosek, P. Palvia, Software
  Maintenance Management changes in the last
  decade, Software Maintenance Research and
  Practice, 1990
• Pressman 97 R.S. Pressman, Ingeniería del
  Software Un enfoque práctico (4ª ed.),
  McGraw-Hill, 1997.
• Ra 94 Y.G. Ra, E.A. Rundensteiner, A
  Trasparent OO Schema Change Approach Using
  View Evolution, University of Michigan, Abril
  1994
• Richardson 97 R. Richardson, Lucha de
  componentes, BYTE Diciembre 97.
• Sjøberg 93 D. Sjøberg, Quantifying Schema
  Evolution, Information and Software Technology,
  vol. 35, no. 1, pp. 35-54, 1993.
• Sommerville 96 I. Sommerville, Software
  Engineering, 5 Edición, Addison-Wesley, 1996.
• Yourdon 89 E. Yourdon, RE-3 re-engineering,
  restructuring and reverse engineering,
  American Programmer, 1989.