Metodologías modernas de desarrollo de Sistemas de Información (página 3)

• Organizar el Sistema en Subsistemas
• Identificar la concurrencia inherente en el problema.
• Asigne los subsistemas a los procesadores y a las tareas.
• Elegir la estrategia basica para implementar almacenes de datos en términos de estructuras de datos, archivos y bases de datos
• Identificar los recursos globales y determinar los mecanismos para controlar el acceso a ellos
• Elegir una aproximación para implementar el control del software
• Utilice la localización dentro del programa para llevar a cabo el estado, o
• Directamente implemente un estado de máquina, o
• Utilice las tareas concurrentes
• Considerar las condiciones de Límite
• Establecer las prioridades de compensación

8Diseño del Objeto

• Obtener las operaciones para el modelo del objeto de los otros modelos:
• Encontrar una operación para cada proceso en el modelo funcional
• Definir una operación para cada evento en el modelo dinámico, dependiendo del control de la implementación

9Diseño de algoritmos para implementar las operaciones:

• Elegir algoritmos que minimicen el costo de implementación de la operación
• Seleccionar las estructuras de datos apropiadas para los algoritmos.
• Definir nuevas clases internas y operaciones
• Asignar responsabilidades para las operaciones que son claramiente asociadas con las clases solas.

10. ptimizar las rutas de acceso a los datos:

• Agregar asocaciones redundante para minimizar el costo del acceso y maximizar la conveniencia
• Reorganizar la computación para mayor eficiencia
• Grabar valores derivados de evitar las expresiones complicadas.

10. Implementar el software de control
11. Ajustar la estructura de clases para incrementar la herencia:

• Reorganizar y ajustar las clases y operaciones para incrementar la herencia.
• Abstraccion del comportamiento comun de los grupos y clases.
• Utilizar delegacion para compartir el comportamiento donde la herencia es semanticamente invalida.

10. iseñar la implementación de asociaciones:

• Analizar el traversal de asociaciones
• Implementar cada asociación como a distintos objetos o por adicion del atributo valor-objeto a una o ambas clases en la asociación.

10. eterminar la exacta representación de los atributos de los objetos.
11. Empaquetar clases y asociaciones en modulos.

Shlaer y Mellor 1992.

• Para los renglones de modelos de información

Busqueda

Desarrollo y Refinación de los Modelos

Integrar con Otros Modelos

Revisar

• Para los renglones de Modelo de Estado

Construir el Modelo Estado

Verificar las interacciones entre los modelos estados y los modelos de comunicación de objetos

Construir o modificar, los modelos de comunicación de subsistemas

Revisar que esten correctos y su consistencia

• Para el renglón de los Modelos de Proceso

Construcción de Diagramas de Flujo de Datos Activos

Integrar con las Tablas de Proceso de Estado y producir los modelos de acceso de datos para los subsistemas y modificar los modelos de acceso a subsistemas

Revisar

Wirfs-Brock 1990.

• Leer y Entender las Especificaciones
• Probar varios escenarios para explorar diferentes posibilidades. Grabar los resultados en tarjetas de diseño.
• Extraer frases de sustantivos de las especificaciones y construir una lista.
• Escoger los sustantivos que pueden ser escondidos (ejem, el uso de la voz pasiva) y agregarlos a la lista
• Identificar clases candidates para las frases de los sustantivos para aplicarlas en las siguientes guías:

Modelo de objetos físicos

Modelo conceptual de entidades

Uso de un termino solo para cada concepto

Ser cuidadoso en el uso de adjectivos

Modelo de categorias de objetos

Modelo de interfaces externas

Modelo los valores de los abributos de los objetos

1. Identificar candidatos para la abstracción de superclases por agrupamiento de clases que comparten atributos comunes.
3. Uso de categorias para buscar clases que puedan ser olvidadas.
4. Escribir una declaración cortadel propósito de las clases.
5. Encontrar las responsabilidades utilizando las siguientes guías:

Recuerde el propósito de cada clase, según lo implicado por su nombre y especificado en la declaración del propósito

Extraiga responsabilidades de la especificación buscando acciones e información

Identifique responsabilidades implicadas por las relaciones entre clases.

1. Asignar responsibilidades a las clases utilizando las siguientes guías:

2. Distribuir uniformemente la inteligencia del sistema

   Definir responsabilidades lo mas posible

   Matnener el comportamiento con la informacion relacionada

   Mantener la información de cada cosa en un lugar

   Compartir responsibilidades a través de las clases relacionadas.

   Utilizar relaciones "es-tipo-de" para encontrar herencias en las relaciones.

   Utilizar relaciones "es-analogo-para" para encongrar superclases perdidas.

   Utilizar relaciones "es-parte-de" para encontrar otras clases perdidas.

3. Encontrar responsabilidades adicionales observando las relaciones entre las clases.
4. Encontrar y enlistar colaboradores examinando las relaciones asociadas con las clases.
5. Identificar colaboradores adicionales.
6. Desechar las clases que no colaboran con ellas, y las que colaboran con otras clases.
7. Construir graficas de herencias para ilustrar las relaciones de herencias entre las clases.
8. Identificar cuales clases son abstractas y cuales son concretas.
9. Dibujar Diagramas Venn representando las responsabilidades compartidas entre las clases.
10. Construir herencias de las clases.
11. Construir los contratos definidos para cada clases.
12. Dibujar y completar graficas de colaboradore del sistema.
13. Identificar posibles subsistemas con el diseño.
14. Simplifique los colaboradores entre los subsistemas
15. Construir los protocolos para cada clase. Refinar las responsibilidades entre los sets y firmas que maximizan la utilización de las clases.
16. Escribir y diseñar las especificaciones para cada clase.
17. Escribir y diseñar las especificaciones para cada subsistema.
18. Escribir y diseñar las especificaciones para cada contrato.

B. VISION GRAFICA DEL PROCESO DE DESARROLLO DE BOOCH, COAD & YOURDON, Y RUMBAUGH

BOOCH

 Para ver el gráfico seleccione la opción "Descargar"

COAD & YOURDON

 Para ver el gráfico seleccione la opción "Descargar" 

RUMBAUGH

  Para ver el gráfico seleccione la opción "Descargar"

C. ENTREGAS QUÉ GENERA EL PROCESO DEL DESARROLLO

Una cualidad de cualquier proceso del desarrollo es el número y los tipos de entregas que el proceso genera. La documentación del ciclo de vida incluye generalmente especificaciones de requerimientos, especificaciones de diseño, especificación del sistema y subsistemas, así como casos de prueba. Las entregas para cada método se evalúan usando los criterios siguientes:

• 0 indica que no se hace ninguna mención.
• 1 indica que la mención está hecha, pero no se proporciona ninguno detalle
• 2 indica que la mención está hecha y se proporciona una definición
• 3 indica que la mención está hecha, una definición, y por lo menos se presenta un ejemplo
• 4 indica que la mención está hecha, una definición, y por lo menos se presenta un ejemplo, y se define un proceso
• 5 indica que la mención está hecha, una definición, por lo menos se presenta un ejemplo, se define un proceso, y se proporciona la heurística.

La carencia de especificaciones claras, bien-construidas es una debilidad significativa en muchos de los métodos. Sin tales especificaciones, no puede haber reutilización a excepción del código desarrollado (ningún esfuerzo del análisis o del diseño puede ser reutilizado, puesto que no esta documentado). Además, la prueba se afecta seriamente puesto que las pruebas no se pueden hacer sin tales especificaciones. Algunos métodos consideran las especificaciones como solamente necesarias cuando la "programación es grande." Rumbaugh, por ejemplo, comenta que la documentación de clases y métodos es importante al escribir grandes y complejos programas, que implican equipos de programadores; asumiendo que aparentemente es menos importante para los programas pequeños.

D. ASPECTOS DEL CICLO DE VIDA QUE SON CUBIERTOS POR LA APROXIMACION

La cobertura del ciclo de vida proporciona una idea de lo completo de la metodología. Una metodología que cubre todos los aspectos del ciclo de vida del desarrollo del sistema ofrece una solución atractiva a la organización ya que la metodología por sí misma asegura algo completo y consistente. Si una organización, por ejemplo, requiere o decide "mezclar y emparejar" una aproximación del análisis de una metodología con la aproximación del diseño de otra, la organización debe enfrentar la responsabilidad de la consistencia y de la completa transición a partir de una fase del ciclo de vida a otra. Tales estrategias de "mezcla y emparejamiento" introducen un elemento del riesgo en la aproximación.

• 0 indica que no se hace ninguna mención.
• 1 indica que la mención está hecha, pero no se proporciona ningun detalle.
• 2 indica que la mención está hecha y una definición está provista.
• 3 indica que la mención está hecha, una definición, y por lo menos se presenta un ejemplo
• 4 indica que la mención está hecha, una definición, y por lo menos se presenta un ejemplo, y se define un proceso.
• 5 indica que la mención está hecha, una definición, por lo menos se presenta un ejemplo, se define un proceso, y se provee la heurística.

E. DEFINICION DE LOS PASOS DEL PROCESO

Cada metodología debe describir un proceso que, si es seguido, debe brindar un sistema apropiado de productos (ejem, productos del análisis, productos del diseño, código, y casos de la prueba). La claridad de un proceso simplifica la ejecución y la introducción del proceso en una organización de desarrollo. Un proceso bien definido tiene las siguientes cualidades:

• Cada paso esta bien definido, con instrucciones claras, tips y técnicas apropiadas
• Las entradas de cada paso se definen, con posibles ejemplos.
• Las salidas, o los productos, de cada paso se definen, con posibles ejemplos.
• Se delinea el rol responsable en la ejecución de cada paso.
• Se proporciona software de aseguramiento de la calidad e instrucciones a seguir.

F. HEURÍSTICA DISPONIBLE PARA LOS PASOS DE PROCESO

La heurística proporciona tips para asistir al analista y al diseñador en la ejecución de los pasos del proceso. En algunos casos esta heurística es simple y obvia, mientras que en otros son menos obvias. La disponibilidad de un sistema grande de heurística simplifica la ejecución del proceso. Estos puntos sirven como un indicador al grado de ayuda que el método proporciona para la heurística. Un "1" indica pocos si no es que ninguna heurística, mientras que "3" indica cinco o más heurística.

G. VERIFICACION DEL PROCESO

Un proceso definido debe contener reglas para verificar los productos desarrollados. Por ejemplo, los diversos modelos construidos pueden presentar la información que permite la verificación de otros modelos. O una especificación del objeto y de la clase puede ser comprobable contra los modelos usados en su construcción. Sin tales reglas, no son posibles, la verificación de las especificaciones y otros productos.

H. VALIDACION DEL PROCESO

Cada metodología debe proporcionar una forma que permita la validación independiente de los productos del desarrollo con el cliente, independientemente de la notación de la misma. Modelos ejecutables, prototipos, y los flujos de escenarios son algunos ejemplos.

10. ASPECTOS PRAGMATICOS

A. RECURSOS DE AYUDA DISPONIBLE

La tabla siguiente identifica los recursos disponibles para apoyar la metodología. Estos recursos incluyen en sitio o entrenamiento público, si el entrenamiento está disponible en fuentes solas o múltiples, la disponibilidad de las cintas video del entrenamiento, el número de los textos disponibles que se ocupan de la metodología, y los servicios de consulta disponibles. Además, las librerías de componentes reutilizables disponibles que se construyeron para usar la metodología.

B. ENTRENAMIENTO REQUERIDO PARA LA UTILIZACION DE LA METODOLOGIA (Independiente del entrenamiento del Lenguaje de programación)

Esta es una valoración subjetiva de la complejidad de cada método. Esta valoración se basa en el número de los modelos presentes en cada notación, la cantidad de maestría requerida para utilizar el método, el número de los pasos presentes en cada proceso, y la claridad de la aproximación. De acuerdo con estos factores, se hace una estimación del entrenamiento requerido necesitado para utilizar con eficacia el método. Los métodos altamente complejos requieren la mayoría del entrenamiento (mas de 6 semanas), los métodos medios de la complejidad requerirán aproximadamente 3-6 semanas de entrenamiento, y los métodos bajos de la complejidad requerirán menos de 3 semanas de entrenamiento. En todos los casos al período del tiempo será requerido (3-6 meses) antes de que el personal haga uso del método.

C. LENGUAJES QUE UTILIZAN LAS METODOLOGIAS

La independencia del lenguaje es una cualidad deseable de cualquier metodología esto provee una portabilidad de los productos del análisis y del diseño a través de los lenguajes.

D. HERRAMIENTAS AUTOMATIZADAS DISPONIBLES PARA CADA METODOLOGIA

Estas son algunas de las herramientas CASE orientadas a objetos disponibles para las metodologias presentadas en este documento.

• • . COMPARACION DE METODOLOGIA TRADICIONAL CON METODOLOGIA ORIENTADA A OBJETOS
• Las metodologías de análisis y diseño estructurado, se examinan los sistemas desde el punto de vista de las funciones o tareas que deben realizar, tareas que se van descomponiendo sucesivamente en otras tareas mas pequeñas y que forman los bloques o módulos de las aplicaciones. En la orientación a objeto, por su parte, cobra mucho más importancia el aspecto de "modelado" del sistema, examinando el dominio del problema como un conjunto de ojbetos que interactúan entres sí.

En las metodologías tradicionales se produce una división entre los dos elementos de un sistema: funciones que llevan a cabo los programas y datos que se almacenan en archivos o bases de datos. Y por otro lado, la orientación al objeto de un enfoque unificador de ambos aspectos, que seunen en los objetos.

En las metodologías tradicionales las herramientas que utilizan para el análisis son: Diagramas de Flujos de Datos, Diccionarios de Datos, Diagramas Entidad-Relación, Diagramas de Trancisión de Estado, Especificaciones de procesos. En las metodologías orientadas a objetos se emplean distintos modelos depende de la metodología, entre los principales están Modelo de objetos, Modelo de Estado u Objeto-Estado, entre otros.

A continuación veremos un ejemplo de un sistema de Cuentas Bancarias, visto por los dos enfoques:

METODOLOGIA TRADICIONAL

Representada por Diagrama de Flujo de Datos

 Para ver el gráfico seleccione la opción "Descargar" 

METODOLOGIA ORIENTADA A OBJETOS

Representada por Diagrama de Objetos de Rumbaugh

 Para ver el gráfico seleccione la opción "Descargar" 

Ahora veamos un ejemplo de la representación de dinámica de un sistema de Clima (Aire acondicionado), modelado por los dos enfoques de metodologías:

METODOLOGIA TRADICIONAL

Representada por Diagrama de Flujo

 Para ver el gráfico seleccione la opción "Descargar" 

METODOLOGIA ORIENTADA A OBJETOS

Representada por un Diagrama de Transición de Estado de Booch

 Para ver el gráfico seleccione la opción "Descargar" 

12. APLICACIÓN DE LAS METODOLOGIAS

• La organización desea explorar la orientación a objetos y está solamente interesada en una respuesta "qué es un objeto?"

Seleccione los mas altos candidatos de conceptos, como son: Booch, Berard, y Wirfs-Brock.

• La organización esta provista pesadamente en herramientas, tecnología, y entrenamiento basado en datos o ingeniería de información, y desea cambios mínimos a esta base.

Seleccione a candidatos que tienen conceptos que no son tan altos en orientacion a objetos. Tales como Rumbaugh, Shlaer y Mellor, y Kurtz y Embley puesto que no están muy "orientados al objeto." Como cada uno de estas aproximaciones todavía hace el uso significativo en modelos de datos, y el impacto en las herramientas, la tecnología, y el entrenamiento sería mínimamente afectado.

• La organización está construyendo una gran aplicacion, con enfoque en tiempo real.

Seleccione los metodos donde el proceso se ocupa de las ediciones grandes de aplicaciones, y de la pragmática basada en tamaño del proyecto y ayuda en tiempo real. Booch, Berard, Shlaer y Mellor, y posiblemente, Rumbaugh son los posibles a elegir.

• El desarrollo requiere altas pruebas confiabilidad.

Berard provee una gran ayuda en esto, Booch, Shlaer/Mellor, y Rumbaugh le siguen.

• El esfuerzo está orientado a componentes reutilizables para la venta comercial.

Seleccione el modelo y la pragmática donde su desarrollo esta basado en la reutilización. Berard y Booch proporcionan la mayoría de esta ayuda.

• Interesado en un método donde la única preocupación es que el proceso del desarrollo esté bien definido.

Seleccione los metodos de Rumbaugh, Shlaer y Mellor, Wirfs-Brock, Berard, son procesos relativamente bien definidos.

13. CONCLUSION

En el transcurso del tiempo el ambiente computacional ha ido evolucionando en todos los aspectos, las computadoras cada día son mejores y más rapidas. Los usuarios se vuelven cada vez mas exigentes y buscan el servicio de los sistemas estando en cualquier parte del mundo, no solamente en sus oficinas. La tecnología de la información ha ejercido un profundo impacto en la sociedad por lo que ahora se le llama la Era de la Información. Los empleados administrativos rebasaron el número de los trabajadores de producción. La sociedad industrial ha dado paso a una nueva sociedad, en donde la mayoría de las personas trabajan con información en lugar de producir bienes.

Los sistemas se han ido enfocando mas a la comodidad del usuario lo cual ha provocado dos cosas, que se realicen sistemas cada vez mas complejos y que se desarrollen muchas metodologías buscando la manera optima de desarrollarlos.

Las metodogías también han evolucionado. Inicialmente hubo un periodo de Desarrollo Convencional, después surge el Desarrollo Estructurado y en la actualidad aparece el paradigma de la Orientación a Objetos como un nuevo enfoque en la ingeniería de software.

A la fecha se han desarrollado muchísimas metodología enfocadas a la Orientación a Objetos, en esta investigación solo vimos 8 de ellas, siendo de las mas representativas de este paradigma.

Cuando inicié esta investigación yo contaba con ninguna o poquísimas bases de Orientación a Objetos. Poco a poco al ir leyendo y conociendo cada metodología entendí mejor este paradigma. Una de las metodologías que me ayudaron mucho a comprender la Orientación a Objetos fue la de Booch, ya que se apoya de muchos gráficos para definir los conceptos básicos de Orientación a Objetos, por lo que yo la recomiendo para principiantes.

Por otro lado Rumbaugh me pareció muy completa porque es una de las que más puntuación tiene con respecto a entregas de productos dentro de cada etapa del ciclo de vida, cuenta con bastantes tips para el analista y diseñadores para la identificación de clases, operaciones, estados y subsistemas; cuenta con reglas de verificación y de validación y existen suficientes recursos para aprenderla.

Debido a las comparaciones realizadas en este documento, podemos darnos cuenta que la debilidad que tiene en cierta area una metodología se compensa con alguna fuerza que tiene en otro punto, siendo asi todas útiles dependiendo del caso que tengamos para aplicarlas. Pero por lo que a mi respecta, y con lo anteriormente expuesto, las metodologías con las que yo propongo para desarrollar sistemas de calidad basados en Orientación a Objetos son Booch y Rumbaugh.

14. BIBLIOGRAFIA

Berard, Edward V. (1998). Basic Object-Oriented Concepts. Consultado a www.toa.com/pub/oobasics/oobasics.htm en fecha 26 de Nov. de 2002.

Booch, G. (1996). Análisis y Diseño Orientado a Objetos con aplicaciones. México: Pearson Educación.

Brinkkemper, S.; Hong, S.; Bulthuis, A.; Goor, G. (1994). Object-Oriented Analysis and Design Methods Contents. Consultado a http://panoramix.univ_paris1.fr/crinfo/ dmrg/oodoc/oodoc/oo-contents.html en fecha 29 de Nov. de 2002.

Coleman, D.; Arnold, P.; Bodoff, S.; Dollin, C.; Gilchrist, H.; Hayes, F.; Jeremaes, P. Object-Oriented Development The Fusion Method. Estados Unidos: Prentice Hall

Rumbaugh, J.; Blaha, M.; Premerlani, W.; Eddy, F.; Lorensen, W. (1999); Modelado y Diseño Orientados a Objetos; Metodología OMT. España: Prentice Hall.

Shneider, P. (S.F.). The Booch Method. Consultado a www.ifra.ing.tu-bs.de/docs/BoochReferenz/ en fecha 29 de Nov. de 2002.

The Object Agency, Inc. (1995). A Comparison of Object-Oriented Development Methodologies. Consultado a www.toa.com/smnn?mcr.html en fecha 26 de Nov. de 2002.

Yourdon, E. (1994). Object-Oriented Systems Design an Integrated Approach. Estados Unidos: Yourdon Press.