metodologia de diseño de sistemas
TRANSCRIPT
Antologia
Licenciatura en Ingenieria de Sistemas Computacionales
Mike Zamora González
Universidad Tecnológica Costarricense
Metodologia del diseño de Sistemas I Autores: Erly Delgado Expósito y Gerardo Moreno Martínez
Contenido 1 Metodologías modernas de desarrollo de Sistemas de Información ........... 5
1.1 INTRODUCCION .................................................................................. 5
1.2 HISTORIA ............................................................................................. 5
1.3 CONCEPTOS BASICOS DE ORIENTACION A OBJETOS .................. 7
1.4 QUE ES UNA METODOLOGIA? ........................................................... 9
1.5 EL ENFOQUE ....................................................................................... 9
1.6 RESULTADO ESPERADO.................................................................. 11
1.7 CONCEPTOS...................................................................................... 12 1.7.1 DEFINICIÓN DEL "OBJETO" EN CADA METODOLOGIA .................... 12
1.7.2 DEFINICIÓN DE "CLASE" EN CADA METODOLOGIA ......................... 14
1.7.3 DEFINICIÓN DE "OPERACION" EN CADA METODOLOGIA ............... 16
1.7.4 DEFINICIÓN DE "METACLASE" EN CADA METODOLOGIA ............... 18
1.7.5 SIMBOLOGIA UTILIZADA PARA REPRESENTAR LOS CONCEPTOS POR BOOCH, COAD & YOURDON, Y RUMBAUGH .......................................... 19
1.7.6 COMO LIDIA EL METODO CON CONCEPTOS QUE SON MAS GRANDES Y QUE PUEDEN SER REPRESENTADOS RAZONABLEMENTE POR UNA CLASE ........................................................................................................ 20
1.7.7 ENFOQUE A LA ORIENTACION DE OBJETOS ................................... 22
1.8 NOTACIONES..................................................................................... 23 1.8.1 COMPONENTES DE LA NOTACIÓN DE LAS MÉTODOLOGIAS ......... 23
1.8.2 REPRESENTACIONES GRAFICAS DE ALGUNOS DIAGRAMAS UTILIZADOS POR BOOCH, COAD & YOURDON, Y RUMBAUGH ..................... 26
1.8.3 CONCEPTOS ESTÁTICOS QUE LA NOTACIÓN ES CAPAZ DE EXPRESAR ......................................................................................................... 27
1.8.4 CONCEPTOS DINÁMICOS QUE LA NOTACIÓN ES CAPAZ DE EXPRESAR ......................................................................................................... 28
1.8.5 REGLAS EXPLÍCITAS PARA DEFINIR LOS SÍMBOLOS DE LAS NOTACIONES ..................................................................................................... 28
1.8.6 MECANISMO DE PARTICION DENTRO DE LA NOTACION ................ 30
1.9 PROCESOS ........................................................................................ 30 1.9.1 PASOS DEL PROCESO DE DESARROLLO DE CADA METODOLOGÍA 30
1.9.2 VISION GRAFICA DEL PROCESO DE DESARROLLO DE BOOCH, COAD & YOURDON, Y RUMBAUGH .................................................................. 38
1.9.3 ENTREGAS QUÉ GENERA EL PROCESO DEL DESARROLLO ......... 39
1.9.4 ASPECTOS DEL CICLO DE VIDA QUE SON CUBIERTOS POR LA APROXIMACION ................................................................................................. 40
1.9.5 DEFINICION DE LOS PASOS DEL PROCESO .................................... 41
1.9.6 HEURÍSTICA DISPONIBLE PARA LOS PASOS DE PROCESO .......... 42
1.9.7 VERIFICACION DEL PROCESO ........................................................... 43
1.9.8 VALIDACION DEL PROCESO .............................................................. 44
1.9.9 Metodología ........................................................................................... 44
1.10 ASPECTOS PRAGMATICOS .......................................................... 44 1.10.1 RECURSOS DE AYUDA DISPONIBLE ................................................. 44
Recursos ............................................................................................................. 44
1.10.2 ENTRENAMIENTO REQUERIDO PARA LA UTILIZACION DE LA METODOLOGIA (Independiente del entrenamiento del Lenguaje de programación)...................................................................................................... 45
1.10.3 LENGUAJES QUE UTILIZAN LAS METODOLOGIAS ........................... 45
1.10.4 HERRAMIENTAS AUTOMATIZADAS DISPONIBLES PARA CADA METODOLOGIA .................................................................................................. 46
1.10.5 COMPARACION DE METODOLOGIA TRADICIONAL CON METODOLOGIA ORIENTADA A OBJETOS ........................................................ 47
1.10.6 EJEMPLO COMPARATIVO ................................................................... 48
1.10.7 APLICACIÓN DE LAS METODOLOGIAS .............................................. 49
1.11 CONCLUSION ................................................................................. 50
1.12 BIBLIOGRAFIA ................................................................................ 51
2 Metodologías de desarrollo de software. ¿Cuál es el camino? .................. 52
2.1 Introducción ......................................................................................... 52
2.2 Desarrollo ............................................................................................ 53 2.2.1 Metodologías pesadas. .......................................................................... 53
2.2.2 Metodologías ágiles. .............................................................................. 54
2.3 Resumen puntos clave ........................................................................ 61 2.3.1 RUP ....................................................................................................... 61
2.3.2 3P .......................................................................................................... 61
2.3.3 XP ......................................................................................................... 61
2.4 Conclusiones ....................................................................................... 62
2.5 Referencias ......................................................................................... 62
2.6 Bibliografía .......................................................................................... 62
3 Análisis y Diseño de Sistemas ................................................................... 63
3.1 Análisis de Sistemas de Computación ................................................ 63
3.1.1 Conceptos y Análisis ............................................................................. 63
3.1.2 Objetivos del Análisis ............................................................................. 64
3.2 Diseño de sistemas de computación ................................................... 66 3.2.1 Conceptos y principios ........................................................................... 66
3.2.2 Herramientas para el Diseño de Sistemas ............................................. 68
3.3 Análisis de Sistemas de Apoyo a Decisiones Semiestructuradas ....... 69 3.3.1 Métodos Disponibles ............................................................................. 69
3.3.2 Sistemas de apoyo a Decisiones ........................................................... 69
3.3.3 Conceptos del proceso de Toma de decisiones relevantes para los DSS 70
3.3.4 Fases para la solución de problemas..................................................... 71
3.4 Conclusiones ....................................................................................... 72
3.5 Bibliografía .......................................................................................... 73
1 Metodologías modernas de desarrollo de Sistemas de Información
1.1 INTRODUCCION En esta investigación se comparan varias Metdologías Modernas para el Desarrollo de Sistemas de Información. Estas utilizan el paradigma de Orientación a Objetos. Este es el enfoque actual de los Desarrollos de Sistemas; primero se tuvo un enfoque en Desarrollo Convencional, despues Estructurado y actualmente Orientado a Objetos. En esta comparación lo que se busca es en primer lugar saber cuales son los nombres de tantas metodologías existentes y en segundo lugar, conocer el enfoque de cada una, la manera en que definen los conceptos básicos de Orientación a Objetos, cómo son sus notaciones, sus procesos, qué parte del ciclo de vida abarcan o si abarcan todo el ciclo de vida. Qué recursos disponibles hay para utilizar una de estas metodologías, existen libros disponibles, qué tipo de conocimientos necesitamos tener para poder utilizarlas, en qué lenguajes de programación se apoyan. Y teneniendo esta base de conocimientos, ahora sí poder elegir una de ellas para utilizarla en el desarrollo de los sistemas en los que sea participe tanto yo, como cualquier persona que lea este documento.
1.2 HISTORIA Las primeras computadoras salieron en la década de los 40s, se llamó la primera generación, las computadoras estaban construidas por medio de tubos de vacío y eran programadas en lenguaje de máquina. En la década de los 50s se empezó con los Sistemas de Procesamiento de Transacciones, el objetivo de muchos de esos primeros sistemas era reducir costos, el cual era posible mediante la automatización de numersos sistemas administrativos rutinarios y de trabajo intensivo. Las computadoras son de la segunda generación; estaban construídas con circuitos de transistores. Eran programadas con tarjetas perforadas, con lenguajes llamados de alto nivel. No contaban con disco duro. Tampoco existían los discos flexibles. Aparecen los procesadores de palabras como Word Star, hojas de cálculo como Visicalc. Los sistemas de información que sobresalieron son: Cuentas por Cobrar y Nómina. Los Sistemas de Información administrativos, empezaron a desarrollarse en la decada de los 60s y se caracterizaron por utilizarlos para producir informes administrativos que en la mayoría de los casos eran elaborados de manera periódica. La programación Orientada a Objetos fue discutida primeramente a finales de los 60s por la comunidad de SIMULA. Surge la tercera generación de las computadoras. Su fabricación electrónica estaba basada en circuitos integrados. Se manejaban por medio de lenguajes de control de los sistemas operativos. Aparecen las minicomputadoras. Los sistemas de información que
sobresalieron son: Flujo de Efectivo, Presupuestos, Manejo de Personal y de Manufactura. En los 70s aparecen las computadoras de cuarta generación. Aparecen los microprocesadores, las computadoras se hacen más pequeñas y baratas por lo que se extiende su uso al mercado industrial. Surgen mas aplicaciones, paquetes gráficos. A principios de los 70s, fue una importante parte de el lenguanje Smalltalk desarrollado por Xerox PARK. Mientras, el resto del mundo salía adelante con lenguajes como COBOL o FORTRAN y usaban métodos de descomposición funcional para manejar los problemas de diseño e implementación en los SI. Había pocas si no es que ninguna, discusiones enfocadas en diseño de orientación a objetos, y virtualmente ninguna sobre análisis basado en orientación a objetos. El procesador principal de esta década es el 404. Los sistemas de información que sobresalieron son de Planeación y Pronóstico. En la década de los 80s, los grandes avances tecnológicos permitieron el desarrollo de SI de menor costo y mayor potencia que los anteriores. Empleados de todos los niveles comenzaron a utilizar computadoras personales para realizar las mas diversas tareas; ya no dependían solo del departamento de sistemas de información para resolver todas sus necesidades informativas. La gente se dio cuenta entonces de que era posible utilizar los sistemas de computación en apoyo a actividades adicionales de toma de decisiones. Y se generaron los Sistemas de Apoyo para la toma de Decisiones. Las computadoras entonces cambiaron a ser de quinta generación. En las que se cuentan los procesadores 8080, 8086, 80286. Los sistemas de información que sobresalieron son: Sistemas de Soporte a Decisiones, Pago a Usuarios Finales y Planeación Estratégica. Surge la Administración de Recursos de Información y los Centros de Información A partir de los 90s surgen los procesadores 80386, 80486, y Microprocesadores Pentium. En esta se han conseguido importantes avances tanto en la IA como en los SE. El valor excepcional de los sistemas expertos radica en el hecho de que permiten a los organizadores proveerse de y utilizar el saber de expertos y especialistas. Por lo tanto, años de experiencia y habilidades especificas no se pierden del todo cuando un experto muere, se retira o cambia de trabajo. Son aplicables a casi cualquier campo o disciplina. Los temas principales en los sistemas de información son: Servicios de Información, Estaciones de Trabajo y Administración de datos centralizados. Cuatro cambios ocurrieron a través de las décadas pasadas y ahora son factores claves para los 90s: El concepto en la aproximación orientada a objetos en el campo de
software ha ido madurando durante dos decadas, y la atención ha ido gradualmente cambiando hacia los asuntos de codificación y a los asuntos de diseño y analisis.
La tecnología para construir sistemas ha ido haciendose mas poderosa. Ideas acerca de diseño han influido por ideas preconcebidas acerca de como uno podria escribir codigo; e ideas acerca de codificacion son fuertemente influenciadas por el lenguaje de programación que esta disponible. Era difícil pensar acerca de programación estructurada
cuando los lenguajes a elegir eran ensambladores y FORTRAN; las cosas se volvieron mas fáciles con Pascal, PL-1, y ALGOL. Similarmente, fue difícil pensar en programar en la moda de Orientación a Objetos cuando el leguaje a elegir era COBOL o el plano C; se hizo mas fácil con C++ y Samlltalk.
Los sistemas construidos hoy en día son diferentes de como eran hace diez o veinte años atras: son largos, muy complejos y muy volátiles. Una aproximación orientada a objetos para el análisis y el diseño es probable conducirlo a un sistema mas estable. También ahora sistemas interactivos requieren mas atención a la interface de usuarios en comparación al proceso de sistemas de texto desarrollados en los 70s. Una aproximación orientado a objetos para tales sistemas –desde análisis hasta diseño y codificación- es un método mas natural para lidiar con tales sistemas orientados a usuarios.
Los sistemas construidos hoy en día son mas “dominio-orientado” que los sistemas construidos en los 70s y 80s. La complejidad funcional es menos preocupante de como lo era antes; el modelado de datos se ha convertido en una prioridad moderada; a tomado una prioridad alta el modelar la comprensión del dominio del problema y las responsabilidades del sistema.
En el 2000 la información ejercio un profundo impacto en la sociedad, al grado de que hay quienes llaman a esta época la Era de la Informació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 procesadores principales son mas poderosos que los Pentium, tienen mas de un core en sus circuitos. Y el tema principal en Sistemas de Información es el Internet, y los Sistemas de Información de la Linea del Frente.
1.3 CONCEPTOS BASICOS DE ORIENTACION A OBJETOS Qué es Orientado a Objetos? Significa que el sistema se organiza como una colección de objetos que interactúan entre sí y que contienen tanto estructuras de datos como un comportamiento. Esto se opone a la programación convencional, en la cual las estructuras de datos y el comportamiento solamente estan relacionadas de forma débil, ya que estos se enfocan principalmente a las funciones. Objeto. Los objetos son las cosas físicas y conceptuales que encontramos en el universo alrededor de nosotros. Hadware, software, documentos, seres humanos, los conceptos son todos los ejemplos de los objetos. Características de los Objetos. Identidad: Los datos estan cuantificados en entidades discretas y distinguibles denominadas objetos. Ejemplo; una televisión, una bicicleta, un árbol. Los objetos pueden ser concretos, como un archivo en un sistema de archivos, o bien conceptuales como la política de planificación en un sistema operativo con multiprocesos. Cada objeto posee su propia identidad inherente. En otras
palabras: dos objetos seran distintos aun cuando los valores de todos sus atributos (tales como el nombre y el tamaño) sean idénticos. Clasificación: Significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se reunen para formar una clase. La selección de clases es arbitraria y depende de la aplicación.
Objetos: Bicicleta de montaña, Bicicleta de carreras, Bicicleta de niños
Clase Bicicleta: o Atributos: Tamaño del cuadro, tamaño de rueda, material, marca,
velocidad o Operaciones: mover, reparar, cambiar velocidad
Objetos: Triangulo, Cuadrado, Octagono
Clase Poligonos: o Atributos: vertices, color del borde, color del interior o Operaciones: dibujar, borrar, mover
Polimorfismo: Significa que una misma operación puede comportarse de modos distintos en distintas clases. La operación mover por ejemplo, se puede comportar de modo distinto en las clases Ventana y Pieza de ajedrez. Una operación es una acción o una transformación que se lleva a cabo o que se aplica a un objeto. Justificar a la derecha, visualizar y mover son ejemplos de operaciones. Una implementación específica de una operación por parte de una cierta clase es lo que se denomina método. Dado que los operadores orientados a objetos son polimórficos es posible que haya más de un método que lo implemente. En el mundo real una operación es simplemente, una abstracción de comportamiento análogo entre distintas clases de objetos. Cada objeto “sabe” llevar a cabo sus propias operaciones. Sin embargo, en un lenguaje orientado a objetos es este el que selecciona automaticamente el método correcto para implementar una operación basandose en el nombre de la operación y en la clase del objeto que esta siendo afectado. El usuario de una operación no necesita ser consciente del número de métodos que existen para implementar una cierta operación polimórfica. Se pueden añadir nuevas clases sin modificar el código existente, siempre y cuando se proporcionen métodos para todas las operaciones aplicables a las nuevas clases. Herencia: Es compartir atributos y operaciones entre clases tomando como base una relación jerárquica. En términos generales se puede definir una clase que después se irá refinando sucesivamente para producir subclases. Todas las subclases poseen o heredan, todas y cada una de las popiedades de su superclase y añaden, además, sus propiedades exclusivas. No es necesario repetir las propiedades de las superclases en cada subclase. Por ejem Ventanadedesplazamiento y ventanafija son subclases de ventana. Ambas subclases heredan las propiedades de ventana tales como una región visible de la pantalla. La ventanadedesplazamiento añade una barra de desplazamiento y un ascensor. La capacidad de sacar factor común a las propiedades de varias clases en una superclase común y de heredar las
propiedades de la superclase puede reducir muchísimo la repteción en el diseño y en los programas siendo una de las ventajas pricipales de un sistema orientado a objetos.
1.4 QUE ES UNA METODOLOGIA? Es un conjunto de métodos empleados para el diseño de sistemas automatizados. Una metodología completa es algo más que una notación, un proceso, y herramientas. Además estas "metodologías completas" proporcionan:
Guías para estimar costos,
Manejo del proyecto en las tareas y entregas,
Medidas y métricas,
Formas definidas y dirección en las entregas de la construcción,
Políticas y procedimientos para garantizar la calidad del software,
Descripciones de los roles y programas de entrenamiento detallados,
Ejemplos totalmente trabajados,
Ejercicios de entrenamiento,
Técnicas para adaptar el método, y
Técnicas definidas
1.5 EL ENFOQUE
Este capitulo consiste en una comparación de modernas metodologías de desarrollo de sistemas orientados a objetos en las que se identificará y cuantificará la ayuda de estas para el proceso de desarrollo. Debido a que a la fecha ninguna de las metodologías que se van a comprar cumplen completamente con las características mencionadas anteriormente, ya que falta mucho trabajo por hacer para que sean unas metodologías completas. La comparación se hace con ese conocimiento y entonces “metodología” se considera tambien como un método. Las metodologías a comparar, ordenadas alfabéticamente son:
Berard 1992,
Booch 1991,
Coad y Yourdon 1990,
Embley y Kurtz 1990,
Martin y Odell 1992,
Rumbaugh 1991,
Shlaer y Mellor 1992, y
Wirfs-Brock 1990 En esta comparación se consideran cuatro áreas específicamente:
Conceptos o Esta sección cita de la ayuda particular del método y de los
contrastes para los términos dentro de cada método. Los términos tales como objeto, clase, metaclases, y operación se comparan.
Notaciones o Muchos métodos requieren crear descripciones abstractas, o
modelos gráficos, del sistema en el análisis y/o diseño. Se construyen estos modelos usando una cierta forma de notación. La semántica de la notación proporciona el significado a los modelos. Las notaciones, para ser eficaces en el desarrollo de grandes sistemas, requieren un mecanismo para dividir los componentes en "pedazos más manejables".
Procesos o Cuanto del ciclo de vida del desarrollo de los sistemas es cubierto
por el método, y qué adaptación o heurística está disponible para el proceso del método. Es evaluada la cobertura al ciclo de vida. Comprobar que elementos del desarrollo del software se manejan dentro del método. Cada metodología puede tener elementos que sean útiles a una parte del ciclo de vida del desarrollo. Las fases del ciclo de vida se definen de la siguiente manera: El Análisis es esa parte de ciclo de vida que describe las
características exterior observables del sistema, ejem, funcionalidad, funcionamiento, capacidad. Esta descripción incluye normalmente los modelos que representan la construcción lógica de los sistemas, y su colocación dentro de un ambiente de sistema.
El Diseño es la parte del ciclo de vida que prepara definiciones en cuanto a cómo el sistema logrará sus requerimientos. Los modelos preparados en análisis se refinan, o se transforman, en los modelos del diseño que representan la naturaleza física del producto de software.
La implementación es la parte del ciclo de vida que convierte los modelos desarrollados del diseño en el software ejecutable dentro del ambiente del sistema. Este implica la codificación de las unidades del programa, de la generación automatizada del código, o del montaje de los componentes reutilizables ya construidos y probados del código de una biblioteca interna de la reusabilidad.
La prueba se centra en asegurarse de que cada una de las entregas a partir de cada fase cumple con las necesidades indentificadas por el/los usuarios.
El domininio del análisis direcciona la busqueda y aplicación del dominio y la identificación, documentación, construcción y prueba y demostración de los componentes reutilizables utiles en el dominio. Aunque esto no es una actividad del ciclo de vida del proyecto, es una parte importante de considerar en la ayuda brindada por la metodología.
o Se evalúan después las características o las cualidades del proceso del método. Las características de un proceso sirven para medir la capacidad de repetición del método y flexibilidad. Las características define la secuencia de pasos, de entradas requeridas y de salidas, papeles implicados, así como la interacción con otros pasos. Los pasos opcionales deben ser identificados claramente. La heurística y los mecanismos disponibles para la traceabilidad, la verificación, y la validación del proceso son también cualidades deseables de un proceso bien definido.
Pragmática La pragmática de una metodología consiste en:
o Recursos: ¿Qué recursos disponibles hay dentro de la ayuda del método? ¿Existen un libros disponibles? ¿Establecen a los grupos de usuarios? ¿El entrenamiento y la consulta es ofrecida por el vendedor y/o los terceros? ¿Además, están las herramientas automatizadas (herramientas CASE) disponibles en la ayuda del método?
o Conocimientos Requeridos: ¿Cuál es el background requerido de los que aprenden el método? Una característica que distingue de muchos métodos es el nivel de la sofisticación matemática requerido para explotar completamente el método. ¿El método asume conocimiento en una cierta disciplina?
o Utilización del lenguaje: ¿El método guía a un lenguaje en particular? Algunos métodos son específicos a COBOL o al Ada, mientras que otros métodos tienen aplicabilidad más general.
1.6 RESULTADO ESPERADO
La expectativa de cualquier comparación de la metodología es que proporcionará una base para desechar las metodologías que no parecen dar valor dependiendo de la situación. Esta comparación maneja esta expectativa. Planteando preguntas de las metodologías presentadas y usando los resultados documentados para contestar a las necesidades particulares. Estas preguntas sirven como punto que partida para una investigación posterior. Una muestra de las preguntas incluye:
"Deseo aprender sobre el desarrollo orientado al objeto en un sentido general. El proceso del desarrollo orientado al objeto del software y de la
disponibilidad de herramientas no es realmente muy importante para mí en este tiempo. Apenas quiero informacion sobre objetos."
"Tengo que iniciar un gran proyecto que implique veinte personas, fuera de consultores, y es crítico para el éxito de nuestra compañía. Qué métodos son apropiados para mí?"
"Mi proyecto requiere el uso del lenguaje C++. Qué métodos son apropiados considerando que el lenguaje de programación se ha seleccionado ya para mi proyecto?"
1.7 CONCEPTOS En esta sección se cita a cada metodología para comprarar la opinión de cada autor de un número de conceptos orientados al objeto. 1.7.1 DEFINICIÓN DEL "OBJETO" EN CADA METODOLOGIA
1.7.1.1 Berard 1992. Un objeto que se utiliza para crear las instancias, es decir, una plantilla, descripción, patrón, o "modelo" es una categoría o colección de artículos muy similares. Entre otras cosas, una clase describe la interfaz que los estos artículos presentarán al mundo exterior, los métodos, las constantes, y las excepciones es decir, disponibles y apropiados. Una clase representa una abstracción de los artículos. Una clase es realmente una familia de clases muy de cerca relacionadas. La clase es un concepto recurrente. Específicamente, podemos definir clases como un compuesto de otras clases (es decir, las clases compuestas heterogéneas y clases compuestas homogéneas), en términos de sí mismo (una clase recurrentemente definida), como herencia de características de unas o más otras clases (es decir, los superclasses de la clase), y como abastecimiento de características a otras clases (es decir, las subclases de la clase). En algunos lugares, se definen las clases como "el sistema de todos las instancias de un tipo," y del término "tipo" se da la definición antedicha para la clase. 1.7.1.2 Booch 1991. Algo a lo que se le pueden hacer cosas. Un objeto tiene estado, comportamiento, e identidad; la estructura y el comportamiento de objetos similares se definen en su clase común. Los términos instancia y objeto son intercambiables. 1.7.1.3 Coad y Yourdon 1990.
Una abstracción de algo en un dominio del problema, reflejando las capacidades de un sistema a mantener la información de este, interactúa recíprocamente con esta información, o ambas (interactuar y mantener); una encapsulación de los valores atributos y sus usos exclusivos (sinónimo: una instancia) 1.7.1.4 Embley y Kurtz 1990.
Un objeto es una persona, un lugar, o una cosa. Un objeto puede ser físico o conceptual... La idea es que un objeto es una sola entidad o noción. Cada
objeto es un individuo único. Un objeto se puede relacionar con o componer de otros objetos, pero cada objeto es único. 1.7.1.5 Martin y Odell 1992.
Cualquier cosa a la cual un concepto, o tipo de objeto, se aplica – una instancia de un concepto o tipo de objeto. En OOPLs, es cualquier instancia de una clase." 1.7.1.6 Rumbaugh 1991.
Definimos un objeto como un concepto, una abstracción, o cosa con límites para el problema actual. Los objetos responden a dos propósitos: Promueven la comprensión del mundo verdadero y proporcionan una base práctica para la puesta en práctica de la computadora. La descomposición de un problema en objetos depende del juicio y de la naturaleza del problema. No hay una representación correcta. 1.7.1.7 Shlaer y Mellor 1992.
Un objeto es una abstracción de un sistema de cosas del mundo real, tales como:
todas las cosas en el sistema – las instancias - tenga las mismas características, y
todas las instancias están conforme y se conforman con el mismo sistema de reglas y políticas...
Un objeto en OOA representa un solo caso típico pero sin especificar algo en el mundo verdadero - cualquier avión, no importa cual, mientras sea representativo. El analista orientado al objeto distingue este concepto de un caso específico: Avión número 8945, una fuerza aérea, o un avión de Aeromexico, por ejemplo. 1.7.1.8 Wrifs-Brock 1990. Los objetos saben ciertos datos sobre sí mismos (como por ejemplo, una persona sabe los colores de su pelo y ojos), y los objetos saben como hacer ciertas funciones (asi como una persona sabe comprar en el mercado o hacer su trabajo). En un sentido, un objeto se puede ver como una declaración, que cierto conocimiento y ciertas operaciones están relacionados conceptualmente con otro, de modo que tenga sentido el unirlos. 1.7.1.9 ANALISIS En las definciones del término "Objeto", se concluye lo siguiente:
Indica que ciertos métodos integran la mención de abstracción a sus definiciones del objeto, y otros consideran unicidad e identidad como crítica (solamente Rumbaugh menciona ambos). Además, la mención el comportamiento y estado se percibe limitada a esos métodos el centrarse en unicidad.
Metodología Mención de abstracción
Unicidad o identidad
Comportamien-to o acciones Estado
Berard X X
Booch X X X
Coad y Yourdon X X
Embley X
Martin y Odell X
Rumbaugh X
Shlaer y Mellor X
Wirfs-Brock X X X
1.7.2 DEFINICIÓN DE "CLASE" EN CADA METODOLOGIA
1.7.2.1 Berard 1992.
Un objeto el cual es utilizado para crear instancias, es decir, una plantilla, descripción, patrón, o "modelo" de una categoría o de una colección de artículos muy similares. Entre otras cosas, una clase describe la interfaz que los artículos presentarán al mundo exterior, ejem. los métodos apropiados y disponibles, las constantes, y las excepciones. Una clase representa una abstracción de los artículos. Una clase puede a si misma darse parámetros (ejem, representa realmente una familia de clases muy estrechamente relacionadas), a esto le llamamos dar parametos a la clase. Clase es un concepto recursivo. Específicamente, podemos definir clases como un compuesto de otras clases (es decir, clases compuestas heterogéneamente y clases compuestas homogéneamente), en términos de sí mismo (una clase definida recursivamente), como características de herencia de una o más clases (es decir, los superclasses de la clase), y como abastecimiento de características a otras clases (es decir, las subclases de la clase). En algunos lugares, las clases se definen como "el conjunto de todas los instancias de un tipo," y del término "tipo" se da la definición para clase. 1.7.2.2 Booch 1991. Un conjunto de objetos que comparten una estructura común y un comportamiento común. Los términos clase y tipo son generalmente (pero no siempre) intercambiables; y una clase es un concepto levemente distinto a tipo, en el hecho que acentúa la importancia de jerarquías de clases. 1.7.2.3 Coad y Yourdon 1990.
Una descripción de uno o más objetos con un conjunto uniforme de cualidades y de servicios, incluyendo una descripción de cómo crear nuevos objetos en la clase. Clase-Objeto. Un significado del término "una clase y los objetos en esa clase."
1.7.2.4 Embley y Kurtz 1990. Identificación de conjunto de objetos que pertenecen juntos por una cierta razón lógica llamada clasificación. En OSA, un sistema de objetos que pertenecen juntos por una cierta razón lógica se le llama clase del objeto. El modelo de la Objeto-Relacion insita a los analistas a que organicen objetos en clases del objeto. Cada clase del objeto tiene un nombre genérico y denota a cualquier miembro de la clase del objeto. Así, en un ORM, una clase del objeto con nombre X señala una clasificación de los objetos cada uno de los cuales se considera ser un X. Como cada objeto en clase del objeto X es un X, los objetos en la clase son semejantes, por lo menos en un cierto sentido.
1.7.2.5 Martin y Odell 1992. Una implementación de un concepto o de un tipo de objeto. En lenguajes de programación OO, los tipos de datos abstractos se llaman clases. En matemáticas, el significado de la clase es similar al de sistema. El significado de la definición de OOPL de la clase se presentó de la definición matemática. 1.7.2.6 Rumbaugh 1991.
Una clase del objeto describe un grupo de objetos con las características similares (cualidades), el comportamiento común (operaciones), relaciones comunes a otros objetos, y la semántica común. La persona, la compañía, el animal, el proceso, y la ventana son todas las clases del objeto. 1.7.2.7 Shlaer y Mellor 1992.
No provee una definición explicita de “clase” 1.7.2.8 Wrifs-Brock 1990.
Los objetos que comparten el mismo comportamiento se dice que pertenecen a la misma clase. Una clase es una especificación genérica para un número arbitrario de objetos similares. Se puede pensar en una clase como plantilla para una clase específica de objeto. 1.7.2.9 ANALISIS Mientras que el método de Shlaer y de Mellor utiliza diagramas de la clase y hace la mención significativa del término "clase" en su aproximación, no proveen ninguna definición explícita de la clase. Otra nota es que, Rumbaugh menciona que una clase debe identificar sus relaciones con otras clases, mientras que Embley menciona que el modelo de la Objeto-Relacion es útil en identificar clases. Estos dos métodos difieren de los otros métodos en su enfoque en relaciones como fundamental para el uso del término "clase."
Metodología Mención de abstracción
Mención de Estructura
Mención de Comportamiento Estado Relaciones
Berard X X X
Booch X X
Coad y Yourdon X X
Embley X X
Martin y Odell X X
Rumbaugh X X X X
Shlaer y Mellor
Wirfs-Brock X
1.7.3 DEFINICIÓN DE "OPERACION" EN CADA METODOLOGIA 1.7.3.1 Berard 1992.
Una acción que es afectada por, o requerida por un objeto. Las operaciones pueden ser selectoras, constructivas, o iterativas. Una operación es contenida en la interfaz del objeto y tiene sus detalles descritos en un método correspondiente. Las operaciones pueden ser compuestas, es decir, integrada por otras operaciones. Sin embargo no es alentada, la encapsulación de operaciones compuestas dentro de la interfaz a un objeto. 1.7.3.2 Booch 1991. Una cierta acción que un objeto realiza sobre otro para sacar una reacción. Todas las operaciones sobre un objeto específico se pueden encontrar en subprogramas libres y funciones o métodos. Los términos mensaje, método, y operación son generalmente intercambiables. 1.7.3.3 Coad y Yourdon 1990.
Un servicio es un comportamiento específico que un objeto es responsable de exhibir. 1.7.3.4 Embley y Kurtz 1990.
Además de estados y de transiciones entre estados, también deseamos modelar las acciones que un objeto realiza. Una acción puede causar acontecimientos, crear o destruir objetos y relaciones, observar objetos y relaciones, y enviar o recibir mensajes. “Ponemos acciones en dos categorías en OSA: acciones no-interrumpibles y acciones interrumpibles. Las acciones no-interrumptibles son las acciones que el analista espera correr al terminar a menos que ocurran las excepciones o los fallos del sistema. Las acciones interrumpibles pueden ser suspendidas antes de que acaben de ejecutarse y puedan reasumir la ejecución despues. En OSA, pensamos en las acciones asociadas a transiciones como no-interrumptible, mientras que las acciones asociadas a los estados son interrumpibles.” 1.7.3.5 Martin y Odell 1992. Un proceso que se puede solicitar como unidad. Un solo paso que se realiza en una serie de pasos. Las operaciones pueden o pueden no cambiar el estado de un objeto. Las funciones son las operaciones que no cambian el estado. Sin embargo, en un esquema del acontecimiento, las operaciones que dan lugar a acontecimientos cambian estados (y se podrían más correctamente llamar las
operaciones-cambia-estados).. Sin embargo cada operación estado-cambia puede estar como transacción. Una transacción es un proceso o una serie de procesos que actúan como unidad para cambiar el estado de un objeto. Los casos de operaciones se llaman operaciones invocadas. La especificación de cómo una operación debe ser realizada se llama método. 1.7.3.6 Rumbaugh 1991. Una operación es una función o una transformación a la cual puede ser aplicada para o por los objetos en una clase. Contratar, despedir, y pagar utilidades son operaciones en la clase Compañía. Abiertas, cerradas, escondidas, y desplegadas son las operaciones de la clase ventana. Todos los objetos en una clase comparten las mismas operaciones. 1.7.3.7 Shlaer y Mellor 1992. Tomadores de acontecimientos. Define una operación publicada que corresponde a cada acontecimiento generado por el objeto bajo consideración. Tales operaciones publicadas se conocen como tomadores de acontecimientos. Hay dos casos a considerar:
si el acontecimiento generado por el generador de acontecimientos no causa un nuevo caso del objeto a ser creado, define a tomador correspondiente del acontecimiento como operación del caso. Lo nombra: “Acontecimiento Tomado”
si el acontecimiento generado por el generador de acontecimientos hace un nuevo caso del objeto a ser creado, define a tomador correspondiente del acontecimiento como operación de la clase y lo nombra: Toma y Crea
1.7.3.8 Wrifs-Brock 1990.
Cuando un objeto recibe un mensaje, realiza la operación solicitada ejecutando un método. 1.7.3.9 ANALISIS En el repaso de cada definición de la "Operación", solamente Booch indica que el método y la operación son equivalentes. Algunos métodos visualizan los métodos de un objeto de una perspectiva externa, mientras que otros se centran en los métodos de un objeto de una perspectiva interna. El método solamente de Martin y de Odell no hace caso de la aplicación métodos externos o internos.
Metodología Operación = Método Externo Interno Estado
Berard X X
Booch X X
Coad y Yourdon X
Embley X
Martin y Odell X
Rumbaugh X X
Shlaer y Mellor X X X
Wirfs-Brock X
1.7.4 DEFINICIÓN DE "METACLASE" EN CADA METODOLOGIA 1.7.4.1 Berard 1992.
Metaclase: una clase que sus isntancias son asi mismos clases. 1.7.4.2 Booch 1991.
Metaclase: la clase de una clase; una clase que sus instancias son asi mismos clases 1.7.4.3 Coad y Yourdon 1990.
No se hace ninguna mención explícita de metaclase. 1.7.4.4 Embley y Kurtz 1990.
No se hace ninguna mención explícita de metaclase. 1.7.4.5 Martin y Odell 1992.
No se hace ninguna mención explícita de metaclase. 1.7.4.6 Rumbaugh 1991.
Las clases se pueden también considerar como objetos, pero son meta-objetos y objetos no del mundo real. El objeto del descriptor de la clase tiene características, y alternadamente tienen sus propias clases, que se llaman metaclases. Tratar todo como objeto proporciona una puesta en práctica más uniforme y una mayor funcionalidad para solucionar problemas complejos. Metaclase: una clase que describe otras clases. 1.7.4.7 Shlaer y Mellor 1992.
No se hace ninguna mención explícita de metaclase. 1.7.4.8 Wrifs-Brock 1990.
No se hace ninguna mención explícita de metaclase.
1.7.5 SIMBOLOGIA UTILIZADA PARA REPRESENTAR LOS CONCEPTOS POR BOOCH, COAD & YOURDON, Y RUMBAUGH
1.7.5.1 OBJETOS
1.7.5.2 CLASES
1.7.5.3 ASOCIACION
1.7.5.4 HERENCIA
1.7.5.5 AGREGACION
1.7.6 COMO LIDIA EL METODO CON CONCEPTOS QUE SON MAS GRANDES Y
QUE PUEDEN SER REPRESENTADOS RAZONABLEMENTE POR UNA CLASE
1.7.6.1 Berard 1992. El dominio del análisis orientado a objetos intenta identificar los artículos reutilizables localizados alrededor de los objetos, ejem clases, de instancias, sistemas de objetos interactuando, y kits. Kit: una colección de objetos (ejem, clases, metaclasses, instancias de no-clase, otros kits, y los sistemas de objetos interactuando) que apoyan a un solo concepto, grande, coherente, orientado al objeto, ejem, ventanas, interruptores, y pólizas de seguro. Puede de hecho haber una cierta conexión física entre algunos miembros de un kit dado. Sin embargo, los kits son "granulares," es
decir, mientras que todos los componentes de un kit son lógicamente relacionados, allí son muy pocas conexiones físicas las que los unen. Sistema de objetos interactuando: una colección de objetos (ejem, clases, metaclasses, instancias de no-clase, kits, y otros los sistemas de objetos interactuando) todos aquellos que apoyan un concepto solo, grande, coherente, orientado al objeto, y en cuales allí deben ser una conexión física directa o indirecta entre cualquier dos objetos arbitrarios dentro de la colección. Además, los sistemas de objetos interactuando tienen por lo menos uno interno, independientemente del control ejecutado 1.7.6.2 Booch 1991. Sin embargo, la estructura de la clase de un sistema grande puede contener varios cientos o algunos miles de clases. El intentar poner todas estas clases en un diagrama de la clase llega a ser poco manejable. Para ocuparse de este problema, necesitamos algunos medios de organización de clases en pedazos significativos, que nos conduce a la idea de una categoría de clase. ... el dominio del análisis intenta identificar las clases y los objetos que son comunes a todos los usos dentro de un dominio dado, tal como un software de la contabilidad. ... subsistema una colección de módulos, algunos de los cuales son visibles a otros subsistemas y otros de las cuales se ocultan. 1.7.6.3 Coad y Yourdon 1990.
Tema. Un tema es un mecanismo para dirigir a un lector (analista, experto del dominio del problema, encargado, cliente) a través de un modelo grande, complejo. Los temas son también provechosos para los paquetes del trabajo de la organización en proyectos más grandes, basado sobre investigaciones iniciales de OOA. 1.7.6.4 Embley y Kurtz 1990.
Una clase de alto nivel de objetos agrupa las clases de los objetos, sistemas de relaciones, y notas en una sola clase objeto. 1.7.6.5 Martin y Odell 1992.
No se hace ninguna mención explícita de esto. 1.7.6.6 Rumbaugh 1991.
Subsistema un componente importante de un sistema organizado alrededor de un cierto tema coherente. Un sistema se puede dividir en subsistemas usando particiones o capas. Sistema: colección organizada de componentes que interactúan. Partición: un subsistema que povee un tipo de servicio; una partición puede por si misma construir subsistemas de nivel mas bajo. Capas: un subsistema que provee múltiples servicios, todos los cuales estan en el mismo nivel de abstracción, construye en sistemas de nivel bajo de abstracción. 1.7.6.7 Shlaer y Mellor 1992. Mientras que un dominio pequeño (consistiendo en cincuenta o pocos objetos) se puede analizar generalmente como unidad, los dominios grandes se deben
particionar para hacer que el análisis sea una tarea manejable. Para hacer tal particionamiento, nos aprovechamos del hecho de que los objetos en un modelo de información tienden a formar racimos: grupos de objetos que son interconectados el uno con el otro por muchas relaciones. Por el contrario, relativamente pocas relaciones conectan objetos en diversos racimos. Al particionar un dominio, dividimos el modelo de la información de modo que permanezcan los racimos intactos... Cada sección del modelo de información entonces se convierte en un subsistema separado. Observe que cuando el modelo de información se particiona en subsistemas, cada objeto está asignado a exactamente un subsistema. 1.7.6.8 Wrifs-Brock 1990. Hemos estado hablando de clases como si fueran las únicas entidades conceptuales que componían una aplicación. Pero dependiendo de la complejidad de su diseño, los varios niveles de la encapsulación se pueden jerarquizar, una dentro del otro... Un subsistema es un sistema de clases (y posiblemente de otros subsistemas) que colaboran para satisfacer un sistema de responsabilidades. Aunque no existen los subsistemas mientras que el software se ejecuta, son entidades conceptuales útiles. Los aplicaciones son programas completos. Una simulación completamente desarrollada, un sistema del procesamiento de textos, una hoja de cálculo, una calculadora, o un sistema del pago de la nómina son ejemplos de aplicaciones. 1.7.7 ENFOQUE A LA ORIENTACION DE OBJETOS Solamente Booch y Berard tienen una cantidad significativa de texto en describir el dominio del análisis orientado a objetos. Shlaer y Mellor sugieren que los objetos se puedan localizar usando las fuentes siguientes:
Cosas tangibles (avión, una pipa, una computadora)
Roles realizados por personas u organizaciones (doctor, paciente, corredor)
Incidentes (vuelo, accidente, funcionamiento)
Interacciones (compra, boda, una red eléctrica)
Especificaciones (tipos de pólizas de seguro) Coad y Yourdon recomiendan la busqueda de objetos con las siguientes fuentes:
Estructuras
Otros Sistemas
Dispositivos
Cosas o acontecimientos recordados
Los roles jugados
Procedimientos operacionales
Sitios
Unidades de la organización Estas dos aproximaciones, aunque son útiles, son limitados. Booch, Berard, y Wirfs-Brock parecen ser los más orientados al objeto, con su énfasis terminante en objetos, y el bajo enfoque en asociaciones y relaciones. Coad y Yourdon parecen ser los siguientes, con las carácterísticas de los datos (las cualidades y las variables de la isntancia). Después Rumbaugh, Embley y Kurtz, y Shlaer y Mellor, con un énfasis fuerte en asociaciones y relaciones casi en un nivel que hace a estos pares de los artículos de objetos. Martin y Odell son los menos orientados a objetos, aparentemente presentando extensiones leves a la ingeniería de información con una orientación del comportamiento muy pesada.
1.8 NOTACIONES
1.8.1 COMPONENTES DE LA NOTACIÓN DE LAS MÉTODOLOGIAS Cada metodología es caracterizada por un sistema específico de modelos (componentes de la notación) 1.8.1.1 Berard 1992.
1. Diagrama Objeto-Mensaje 2. Diagrama Semántica de Red 3. Diagrrama Transición de Estados 4. Gráfica Petri-net 5. Diagrama de Tiempos 6. Kit 7. Sistema de Interacción de Objetos 8. Gráfica de la Unidad del Programa
1.8.1.2 Booch 1991. 1. Diagrama de Clases 2. Diagrama de Objetos 3. Diagrama de Transiciones de Estados 4. Diagrama de Tiempos 5. Diagrama de Módulos 6. Diagrama de Procesos
1.8.1.3 Coad y Yourdon 1990.
1. El símbolo de clase de OOA, representando una clase, sus cualidades, y sus servicios.
2. El símbolo de OOA Clase-y-Objeto
3. Notación de la estructura Generalización-Especialización 4. Notación de la estructura Entero-Parte 5. Notación del temas 6. Notación de atributos 7. Notación de la conexión de la instancia (Instance Connection notation) 8. Notación de servicio 9. Notación Diagrama Objeto Estado 10. Notación de Grafica de Servicio
1.8.1.4 Embley y Kurtz 1990.
1. Modelo Objeto-Relación (ORM) 2. Alto-Nivel ORM 3. Estado Red 4. Alto Nivel del Estado Red 5. Diagrama de Interacción 6. Alto-Nivel del Diagrama de Interacción
1.8.1.5 Martin y Odell 1992. 1. Diagrama de Estructura de Datos 2. Diagrama de la Jerarquía Objeto-Generalización 3. Diagrama Objeto-Relación 4. Diagrama de composición de Objetos 5. Diagramas de acción 6. Gráficas de Estructura (no muestra ejemplos) 7. Tablas declarativas. (no muestra ejemplos)
8. Diagramas Estado-Cambio o Diagramas Transición Estado 9. Diagramas de Evento o Esquema de Eventos 10. Diagramas de Flujo de Objetos 11. Herramientas para el diseño gráfico de la interfaz del usuario
1.8.1.6 Rumbaugh 1991. 1. Modelo Objeto utilizado para describir clases, objetos, atributos,
operaciones, especializaciones, generalizaciones y herencias 2. Modelos dinámicos los cuales consisten en: Ecenarios, Traceabilidad de
eventos, Diagramas de estado, Jerarquia de eventos, Diagramas concurrentes de estado, Diagramas extendidos de estado por sincronización y ocurrencia de actividades
3. Modelos funcionales consistentes en: Diagrama de flujo de datos, Diagramas de flujo de control
4. Arquitectura del sistema 1.8.1.7 Shlaer y Mellor 1992.
1. Diagrama de Estructura de Información 2. Diagrama de repaso de la Estructura de Información 3. Grafica de Dominio 4. Matriz del Proyecto 5. Modelo de Relación del Subsistema 6. Modelo de Comunicación del Subsistema 7. Modelo de Acceso al Subsistema 8. Modelo de Información 9. Descripción de Objetos y Atributos 10. Descripción de Relaciones 11. Modelo de Comunicación de Objetos 12. Lista de Eventos 13. Modelo de Acceso a Objetos 14. Tabla de Estados del Proceso 15. Modelo de Estado 16. Diagrama de Flujo de la Acción de Datos 17. Descripcion de Procesos 18. Diagrama de Herencias 19. Diagrama de Dependencias 20. Diagrama de Clases 21. Gráfica de Estructura de Clases
1.8.1.8 Wirfs-Brock 1990. 1. Tarjeta de Clases 2. Tarjeta de Clases con Responsabilidades 3. Tarjeta de Clases con Colaboradores 4. Una Tarjeta de Clase con una Delegación de Subsistema 5. Jerarquías 6. Modelo de Interfaz del Usuario 7. Grafica de Colaboraciones 8. Tarjeta de Subsistemas con Delegaciones.
1.8.2 REPRESENTACIONES GRAFICAS DE ALGUNOS DIAGRAMAS UTILIZADOS POR BOOCH, COAD & YOURDON, Y RUMBAUGH
1.8.2.1 BOOCH
1.8.2.2 COAD & YOURDON
1.8.2.3 RUMBAUGH
1.8.3 CONCEPTOS ESTÁTICOS QUE LA NOTACIÓN ES CAPAZ DE EXPRESAR Se consideraron los siguientes conceptos:
Agregación: ¿De qué objetos componentes se construye un objeto compuesto?
Metodología Agregación Especialización Comunicación Módulo de Interfaz
Calificaciones para la
reutilización
Berard Red de Semantica
Red de Semantica
Diagrama Objeto Mensaje
Grafica de la unidad del Programa
Red de Semantica
Booch Diagrama de Clases
Diagrama de Clases
Diagrama de Clases Modulo Diagrama de
Objetos
Coad y Yourdon Entero-Parte Estrcutura Generalizacion-Especializacion
Mensaje
Embley Modelo Relacion Objeto
Modelo Relacion Objeto
Modelo Relacion Objeto
Martin y Odell Diagrama de composicion de objetos
Diagrama de la Jerarqia Objeto Generalizacion
Diagramas de flujo del objeto
Rumbaugh Modelo del Modelo del Objeto Escenario
Especialización: ¿Cómo es un objeto representado siendo una generalización, o la especialización de otro objeto?
Comunicación: ¿Cómo los objetos mostrados se comunican unos con otros? (enviandose mensajes)
Módulo de Interfaz: ¿Cómo son las implementaciones físicas de los objetos representados?
Calificaciones para la reutilización: ¿Cómo un caso específico de un objeto se representa para ser utilizado por otra clase?
1.8.4 CONCEPTOS DINÁMICOS QUE LA NOTACIÓN ES CAPAZ DE EXPRESAR
La representación de los cambios de estado, la sincronización, y en cierta forma las interacciones del objeto son elementos esenciales para modelar el comportamiento de los sistemas.
Metodologia Cambios de Estado Tiempos
Berard Diagrama Transicion Estado / Grafica Petri Net
Diagrama de Tiempos
Booch Diagrama Transicion Estado
Diagrama de Tiempos
Coad y Yourdon Diagrama Estado
Embley Red de Estado Red de Estado
Martin y Odell Cambios de Estado
Rumbaugh Diagrama de Estado Estado Extendido
Shlaer y Mellor Modelo de Estado
Wirfs-Brock
1.8.5 REGLAS EXPLÍCITAS PARA DEFINIR LOS SÍMBOLOS DE LAS NOTACIONES
Cada método fue repasado para determinar si los símbolos del método fueron definidos explícitamente, y si así es, donde se definieron; y si existen ejemplos.
Berard La notación no es formalmente definida. Se proporcionan numerosos ejemplos
Objeto
Shlaer y Mellor Herencia Modelo Comunicacion de Objetos
Diagrama de clases
Wirfs-Brock Tarjeta de Clases Jerarquias Colaboradores
Booch La notación se documenta en parte de su libro. Se proporcionan numerosos ejemplos
Coad y Yourdon
Proporciona las reglas específicas para la simbología de la notación el apéndice A, del análisis orientado a objetos y proporciona numerosos ejemplos.
Embley La notación es formalmente definida en el Apendice A, y proporciona numerosos ejemplos
Martin y Odell
Se define la notacion en uno de sus capitulos y tambien Diagramas Estandares son recomendados
Rumbaugh La notación si se define en su libro.
Shlaer y Mellor La notacion es formalmente definida a traves de sus libro.
Wirfs-Brock
La notación no se define formalmente, pero se presentan numerosos ejemplos
Además, de la definición de la semántica de las notaciones, se buscaron también ejemplos y heurística para la construcción de modelos.
Metodologia Sintaxis Definida
Semántica Definida
Provisión de
Ejemplos
Heurísticas Presentadas
Berard X X
Booch X X X X
Coad y Yourdon X X X X
Embley X X X X
Martin y Odell X X X
Rumbaugh X X X X
Shlaer y Mellor X X X X
Wirfs-Brock X X X X
En general, cada notación (excepto Berard) provee una definición explícita de la semántica de su notación, ejemplos y heurística. En muchos casos los
ejemplos son bastante completos, estos son, de los modelos requeridos para un problema específico, o de una variedad de problemas. 1.8.6 MECANISMO DE PARTICION DENTRO DE LA NOTACION
Mientras que el tamaño de un sistema aumenta, se requiere un cierto mecanismo para limitar la visibilidad de la información solamente a esos objetos de interés en un momento particular. Estos son los mecanismos que proporciona cada metodología:
Metodología Mecanismo de Partición
Berard Kits, sistemas de Interaccion de Objetos
Booch Subsistemas, Procesadores
Coad y Yourdon Temas
Embley Vistas de Alto Nivel
Martin y Odell *
Rumbaugh Subsistemas
Shlaer y Mellor Subsistemas
Wirfs-Brock Subsistemas y Frameworks
* Martin y Odell mencionan "reinos" y "especificaciones del reino" en su glosario, pero no proporcionan ninguna referencia de cómo ésta se relaciona con la partición del sistema.
1.9 PROCESOS
1.9.1 PASOS DEL PROCESO DE DESARROLLO DE CADA METODOLOGÍA
1.9.1.1 Berard 1992.
Analisis Orientada a Objetos 1. Identificacion de fuentes y requerimientos de informacion 2. Caracterizaer las fuentes y requerimientos deinformación 3. Identificar objetos candidatos 4. Construir los modelos orientados a objetos de ambos problemas,
y de la solucion potencial 5. Re-localizar la informacion alrededor de los apropiados
candidates de objectos 6. Seleccionar, crear, y verificar objetos candidatos
7. Asignar los objetos candidatos a las apropiadas secciones de los requerimientos especificados de la orientacion a objetos (OORS)
8. Desarrollar y refinar la precisa y concisa descripcion del sistema
Diseño Orientado a Objetos 1. Identificacion de los Objetos Candidatos 2. Desarrollo de un modelo de solucion de orientacion a objetos 3. Identificar objetos de interes del modelo 4. Asociar atributos con las operaciones de interes 5. Identificar operaciones afectadas por, y requeridas por, los
objetos candidatos 6. Identificacion de operaciones de interes 7. Asociacion de atributos con las operaciones de interes 8. Manejo de Operaciones compuestas 9. Descomposición a operaciones primitivas 10. Desemparejamiento de objetos 11. Seleccionar, crear, y verificar objetos para diseño 12. Unir objetos y operaciones 13. Examinar objetos para ser completados 14. Decidir sobre el lenguaje de programacion de objetos 15. Identificacion de Objetos durante el analisis 16. Idetificacion de Objetos durinte el diseño 17. Crear modelos graficos de orientacion a objetos 18. Establecer la interface para cada articulo orientado a objetos 19. Implementar cada articulo orientado a objetos
Refinar la interface de objetos
Refinar los otros objetos
Aplicar recursividad al proceso de desarrollo orientado a objetos 1.9.1.2 Booch 1991.
Diseño de Orientacion a Objetos 1. Identificación de Clases y Objetos 2. Identificar las Semanticas de Clases y Objetos 3. Identificar las relaciones entre Clases y Objetos 4. Implementación de Clases y Objetos
1.9.1.3 Coad y Yourdon 1990.
Analisis orientado a Objetos
1. Identificar Objetos 2. Identificar Estructuras 3. Especialización-Generalización de Estructuras 4. Estructuras de Entero-Parte 5. Estructuras Múltiples
Definición de Temas
Definición de Estructuras 1. Identificación de los Atributos 2. Posicionar los Atributos 3. Identificación de las instancias de Conección 4. Checar los Casos Especiales 5. Especificar los Atributos
Definición de Servicios 1. Identificación del Estado del Objeto 2. Identificación de los Servicios Requeridos 3. Identificación de los Mensajes de Conección 4. Especificar los Servicios 5. Poner el conjunto de documentos OOA juntos
Diseño de Orientación a Objetos 1. Diseñar el componente del dominio del problema
Diseño de la reutilización y Clases de Programación
Agrupacionde Clases Problema-Dominio-Especificación
Establezcer un protocolo agregando una clase de la generalización
Acomodar el nivel apoyado de la herencia
Mejora del Funcionamiento
Apoyo del Componente de la Administración de Datos
Agregar los Componentes de Nivel Inferior
Revisar y desafíar las adiciones a los resultados de OOA 2. Diseñar el Componente Humano de la Interacción
Clasificación de Humanos
Descripción de los Humanos y los escenarios de las Tareas
Diseño de la Jerarquía del Comando
Diseño de la Interacción Detallada
Continuación del Prototipo
Diseño de las Clases de los Compnentes de la Interacción Humanas
Diseño, Contabilidad para el GUI ( cuando es applicable ) 3. Diseño del componente del Manejo de tareas
Cuando las tareas sean requeridas
Identificar las Tareas Manejo-Evento
Identificar las Tareas Reloj-Conducidas
Identificar las tareas de Prioridad y las Tareas Críticas
Identificar un Coordinador
Desafiar cada Tarea
Definir cada Tarea 4. Diseño del Componente del Manejo de Datos
Aproximación selecta de la administración de datos
Determinar las herramientas del manejo de datos
Diseñar el componente del Administrador de Datos 1.9.1.4 Embley y Kurtz 1990.
Analisis de los Sistemas Orientado a Objetos 1. Construcción de Modelos Objeto-Relación 2. Costruccion de Modelos Objeto-Comportamiento 3. Construcción de Modelos Objeto Interacción 4. Integrar los Modelos
1.9.1.5 Martin y Odell 1992.
Analisis del Comportamiento Orientado a Objetos 1. Definir las Metas del Analisis 2. Clarificar el Tipo de Evento 3. Generalizar el Tipo de Evento 4. Definir las Condiciones de Operación 5. Identificar las Causas de Operación 6. Refinar los Resultados del Ciclo
1.9.1.6 Rumbaugh 1991.
Analisis
Escribir u obtener una descripción inicial del problema (declaración del problema)
Construir in modelo del Objeto
1. Identificar Clases de los Objetos 2. Comenzar un diccionario de datos que contenga descripción de
Clases, Atributos y Asociaciones 3. Agregar asocioaciones entre Clases 4. Agregar los atributos para los Objetos y sus ligas 5. Organizar y simplificar las clases del objeto usando herencia. 6. Probar los caminos de acceso usando panoramas e iterando los
pasos antedichos como necesarios 7. Agrupar las clases en los módulos, basados en el acoplador
cercano y función relacionada.
Desarrollar un Modelo Dinámico 1. Prepar los escenarios de las secuencias típicas de la interacción. 2. Identificar Eventos entre Objetos y preparar una traciabilidad de
Eventos para cada Escenario 3. Preparar un organigrama del Evento para el sistema. 4. Desarrollar un diagrama de estado para cada clase que tenga
comportamiento dinámico importante 5. Comprobar para saber si hay consistencia y lo completo de los
Eventos compartidos entre los diagramas de estado.
Construir un Modelo Funcional 1. Identificar los valores de la entrada y de la salida. 2. Usar diagramas de flujo como sean necesarios para mostrar la
dependencia funcional 3. Describir lo que hace cada función 4. Identificación de los contrastes 5. Especificar los criterios de la optimización.
Verificar, iterar, y refinar los tres modelos 1. Agregar operaciones claves de lo Funcional al Objeto Modelo 2. Verificar la consistencia y lo completo de las Clases, Atributos, de
Asociaciones, y de Operaciones 3. Desarrollar modelos más detallados para explorar y para verificar
los tres modelos 4. Iterar los pasos antes mencionados tanto como sean necesarios
para acompletar el analisis
Diseño del Sistema 1. Organizar el Sistema en Subsistemas 2. Identificar la concurrencia inherente en el problema. 3. Asigne los subsistemas a los procesadores y a las tareas.
4. Elegir la estrategia basica para implementar almacenes de datos en términos de estructuras de datos, archivos y bases de datos
5. Identificar los recursos globales y determinar los mecanismos para controlar el acceso a ellos
6. Elegir una aproximación para implementar el control del software 7. Utilice la localización dentro del programa para llevar a cabo el
estado, o 8. Directamente implemente un estado de máquina, o 9. Utilice las tareas concurrentes 10. Considerar las condiciones de Límite 11. Establecer las prioridades de compensación
Diseño del Objeto 1. Obtener las operaciones para el modelo del objeto de los otros
modelos: 2. Encontrar una operación para cada proceso en el modelo
funcional 3. Definir una operación para cada evento en el modelo dinámico,
dependiendo del control de la implementación
Diseño de algoritmos para implementar las operaciones: 1. Elegir algoritmos que minimicen el costo de implementación de la
operación 2. Seleccionar las estructuras de datos apropiadas para los
algoritmos. 3. Definir nuevas clases internas y operaciones 4. Asignar responsabilidades para las operaciones que son
claramiente asociadas con las clases solas.
Optimizar las rutas de acceso a los datos: 1. Agregar asocaciones redundante para minimizar el costo del
acceso y maximizar la conveniencia 2. Reorganizar la computación para mayor eficiencia 3. Grabar valores derivados de evitar las expresiones complicadas.
Implementar el software de control
Ajustar la estructura de clases para incrementar la herencia: 1. Reorganizar y ajustar las clases y operaciones para incrementar
la herencia. 2. Abstraccion del comportamiento comun de los grupos y clases. 3. Utilizar delegacion para compartir el comportamiento donde la
herencia es semanticamente invalida.
Diseñar la implementación de asociaciones: 1. Analizar el traversal de asociaciones 2. Implementar cada asociación como a distintos objetos o por
adicion del atributo valor-objeto a una o ambas clases en la asociación.
Determinar la exacta representación de los atributos de los objetos.
Empaquetar clases y asociaciones en modulos. 1.9.1.7 Shlaer y Mellor 1992.
Para los renglones de modelos de información 1. Busqueda 2. Desarrollo y Refinación de los Modelos 3. Integrar con Otros Modelos 4. Revisar
Para los renglones de Modelo de Estado 1. Construir el Modelo Estado 2. Verificar las interacciones entre los modelos estados y los
modelos de comunicación de objetos 3. Construir o modificar, los modelos de comunicación de
subsistemas 4. Revisar que esten correctos y su consistencia
Para el renglón de los Modelos de Proceso 1. Construcción de Diagramas de Flujo de Datos Activos 2. 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
3. Revisar 1.9.1.8 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:
1. Modelo de objetos físicos
2. Modelo conceptual de entidades 3. Uso de un termino solo para cada concepto 4. Ser cuidadoso en el uso de adjectivos 5. Modelo de categorias de objetos 6. Modelo de interfaces externas 7. Modelo los valores de los abributos de los objetos
Identificar candidatos para la abstracción de superclases por agrupamiento de clases que comparten atributos comunes.
Uso de categorias para buscar clases que puedan ser olvidadas.
Escribir una declaración cortadel propósito de las clases.
Encontrar las responsabilidades utilizando las siguientes guías: 1. Recuerde el propósito de cada clase, según lo implicado por su
nombre y especificado en la declaración del propósito 2. Extraiga responsabilidades de la especificación buscando
acciones e información 3. Identifique responsabilidades implicadas por las relaciones entre
clases.
Asignar responsibilidades a las clases utilizando las siguientes guías: 1. Distribuir uniformemente la inteligencia del sistema 2. Definir responsabilidades lo mas posible 3. Matnener el comportamiento con la informacion relacionada 4. Mantener la información de cada cosa en un lugar 5. Compartir responsibilidades a través de las clases relacionadas.
Encontrar responsabilidades adicionales observando las relaciones entre las clases.
1. Utilizar relaciones "es-tipo-de" para encontrar herencias en las relaciones.
2. Utilizar relaciones "es-analogo-para" para encongrar superclases perdidas.
3. Utilizar relaciones "es-parte-de" para encontrar otras clases perdidas.
Encontrar y enlistar colaboradores examinando las relaciones asociadas con las clases.
Identificar colaboradores adicionales.
Desechar las clases que no colaboran con ellas, y las que colaboran con otras clases.
Construir graficas de herencias para ilustrar las relaciones de herencias entre las clases.
Identificar cuales clases son abstractas y cuales son concretas.
Dibujar Diagramas Venn representando las responsabilidades compartidas entre las clases.
Construir herencias de las clases.
Construir los contratos definidos para cada clases.
Dibujar y completar graficas de colaboradore del sistema.
Identificar posibles subsistemas con el diseño.
Simplifique los colaboradores entre los subsistemas
Construir los protocolos para cada clase. Refinar las responsibilidades entre los sets y firmas que maximizan la utilización de las clases.
Escribir y diseñar las especificaciones para cada clase.
Escribir y diseñar las especificaciones para cada subsistema.
Escribir y diseñar las especificaciones para cada contrato. 1.9.2 VISION GRAFICA DEL PROCESO DE DESARROLLO DE BOOCH, COAD &
YOURDON, Y RUMBAUGH
1.9.2.1 BOOCH
1.9.2.2 COAD & YOURDON
1.9.2.3 RUMBAUGH
1.9.3 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.
Metodología Requeri-mientos Diseño Pruebas Objetos
Clases Sub-
sistemas Total
Berard 2 5 5 5 2 19
Booch 1 2 0 1 1 5
Coad y Yourdon 2 2 0 5 0 9
Embley 5 1 0 1 1 8
Martin y Odell 0 0 0 0 0 0
Rumbaugh 2 2 0 5 0 9
Shlaer y Mellor 5 5 0 5 4 19
Wirfs-Brock 1 5 0 5 5 16
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. 1.9.4 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.
Metodología Dominio
de Análisis
Requerimientos en el Análisis Diseño Implemen-
tación Pruebas Total
Berard 4 4 5 5 5 23
Booch 4 2 5 4 0 15
Coad y Yourdon 1 5 5 3 3 17
Embley 0 5 1 0 0 6
Martin y Odell 0 3 5 0 0 8
Rumbaugh 0 5 5 3 2 15
Shlaer y Mellor 0 5 5 1 0 11
Wirfs-Brock 0 3 5 4 3 15
1.9.5 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.
Metodología Definición de Pasos
Entra-das Salidas Rol QA Total
Berard X X X X X 5
Booch X X X X 4
Coad and Yourdon X X X X 4
Embley and Kurtz X X 2
Martin and Odell X X 2
Rumbaugh X X X X 4
Shlaer and Mellor X X 2
Wirfs-Brock X X X 3
1.9.6 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.
Metodología Identificación de Clases
Identificación de
Operaciones
Colocación de
Operaciones
Identifi-cación de Subsiste-
mas
Identifi-cación de Estados
Total
Berard 1 1 1 3 1 7
Booch 3 3 3 3 3 15
Coad and Yourdon 3 3 0 0 1 7
Embley and Kurtz 3 3 1 1 3 11
Martin and Odell 3 3 1 - 3 10
Rumbaugh 3 3 1 2 3 12
Shlaer and Mellor 3 1 1 3 3 11
Wirfs-Brock 3 1 1 3 - 8
1.9.7 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.
Metodología Reglas de Verificación
Berard Si provee
Booch
Coad and Yourdon Si provee
Embley and Kurtz Si provee
Martin and Odell
Rumbaugh Si provee
Shlaer and Mellor Si provee
Wirfs-Brock Si provee
1.9.8 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.
Metodología Reglas de Validación
Berard Prototipo
Booch Prototipo
Coad and Yourdon Prototipo
Embley and Kurtz
Martin and Odell Prototipo
Rumbaugh Flujo de Eventos
Shlaer and Mellor
Wirfs-Brock Prototipo
1.10 ASPECTOS PRAGMATICOS
1.10.1 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.
Metodogías Entrena-miento Recursos Video Textos Librerías
Berard Ambas 2 3 1
Booch Ambas Por lo menos 2 Si 1 1
Coad and Yourdon Ambas 1 Si 2
Embley and Kurtz 1
Martin and Odell Ambas 1 Si 1
Rumbaugh Ambas 1 Si 1
Shlaer and Mellor Ambas 1 2
Wirfs-Brock Ambas Por lo menos 2 1
1.10.2 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.
Metodología Complejidad
Berard Medio
Booch Medio
Coad and Yourdon Bajo
Embley and Kurtz Alto
Martin and Odell Alto
Rumbaugh Medio
Shlaer and Mellor Alto
Wirfs-Brock Medio
1.10.3 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.
Metodogias Ada Eiffel Smalltalk C++ CLOS Total
Berard X X X X X 5
Booch X X X X X 5
Coad and Yourdon X X X 3
Embley and Kurtz 0
Martin and Odell 0
Rumbaugh X X X X 4
Shlaer and Mellor X X 2
Wirfs-Brock X 1
1.10.4 HERRAMIENTAS AUTOMATIZADAS DISPONIBLES PARA CADA METODOLOGIA
Estas son algunas de las herramientas CASE orientadas a objetos disponibles para las metodologias presentadas en este documento.
Nombre de la herramienta
Plataforma en la que trabaja
Descripcion y Metodologias que
Suporta
Ptech
Unix (DECStation, RS6000, Silicon Graphics)
Martin y Odell
Teamwork VAX/VMS, Unix, OS/2, PC-DOS
set de herramientas CASE con capacidades de orientacion a objetos Shlaer/Mellor, HOOD
OMTool Unix Analisis y diseño orientados a objetos Rumbaugh
Iconix Power Tools Macintosh
Multiusuario, set de herramientas de desarrollo OO Rumbaugh, Coad/Yourdon, y Booch
OMW WIndows and Unix Martin and Odell
ObjectMaker MS-Windows, Unix, Macintosh
Analisis y diseño orientado a objetos Berard, Booch, Coad/Yourdon, Rumbaugh,
OOATool Unix, Macintosh, MS-Windows
Analisis Orientado a Objetos Coad/Yourdon
Object System/Designer MS-Windows Diseño Orientado a
Objetos Booch
System Architect MS-Windows, OS/2
Diseño Orientado a Objetos Booch
Rose Unix, AIX Analisis y Diseño Orientado a Objetos Booch
ATRIOM MS-Windows
Analisis y Diseño Orientado a Objetos Booch, Coad/Yourdon, Rumbaugh Shlaer/Mellor
TurboCase Macintosh
Analisis Orientado a Objetos, Diseño estructurado Wirfs-Brock
OOTher Windows Herramienta de documentacion OO Coad/Yourdon
Metodologia Numero de Herramientas Disponibles
Berard 2
Booch 7
Coad and Yourdon 7
Embley and Kurtz -
Martin and Odell 2
Rumbaugh 4
Shlaer and Mellor 3
Wirfs-Brock 1
1.10.5 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: 1.10.5.1 METODOLOGIA TRADICIONAL Representada por Diagrama de Flujo de Datos
1.10.5.2 METODOLOGIA ORIENTADA A OBJETOS
Representada por Diagrama de Objetos de Rumbaugh
1.10.6 EJEMPLO COMPARATIVO
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: 1.10.6.1 METODOLOGIA TRADICIONAL Representada por Diagrama de Flujo
1.10.6.2 METODOLOGIA ORIENTADA A OBJETOS Representada por un Diagrama de Transición de Estado de Booch
1.10.7 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.
1.11 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.
1.12 BIBLIOGRAFIA o Berard, Edward V. (1998). Basic Object-Oriented Concepts. Consultado
a www.toa.com/pub/oobasics/oobasics.htm en fecha 26 de Nov. de 2002.
o Booch, G. (1996). Análisis y Diseño Orientado a Objetos con aplicaciones. México: Pearson Educación.
o 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.
o Coleman, D.; Arnold, P.; Bodoff, S.; Dollin, C.; Gilchrist, H.; Hayes, F.; Jeremaes, P. Object-Oriented Development The Fusion Method. Estados Unidos: Prentice Hall
o 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.
o Shneider, P. (S.F.). The Booch Method. Consultado a www.ifra.ing.tu-bs.de/docs/BoochReferenz/ en fecha 29 de Nov. de 2002.
o 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.
o Yourdon, E. (1994). Object-Oriented Systems Design an Integrated Approach. Estados Unidos: Yourdon Press.
2 Metodologías de desarrollo de software. ¿Cuál es el camino?
2.1 Introducción El desarrollo de software no es sin dudas una tarea fácil. Como resultado a este problema ha surgido una alternativa desde hace mucho: la Metodología. Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente. Lo hacen desarrollando un proceso detallado con un fuerte énfasis en planificar inspirado por otras disciplinas de la ingeniería. Las metodologías ingenieriles han estado presentes durante mucho tiempo. No se han distinguido precisamente por ser muy exitosas. Aún menos por su popularidad. La crítica más frecuente a estas metodologías es que son burocráticas. Hay tanto que hacer para seguir la metodología que el ritmo entero del desarrollo se retarda. Hoy en día existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Un ejemplo de ellas son las propuestas tradicionales centradas específicamente en el control del proceso. Estas han demostrado ser efectivas y necesarias en un gran número de proyectos, sobre todo aquellos proyectos de gran tamaño (respecto a tiempo y recursos). Sin embargo la experiencia ha demostrado que las metodologías tradicionales no ofrecen una buena solución para proyectos donde el entorno es volátil y donde los requisitos no se conocen con exactitud, porque no están pensadas para trabajar con incertidumbre. Aplicar metodologías tradicionales nos obliga a forzar a nuestro cliente a que tome la mayoría de las decisiones al principio. Luego el coste de cambio de una decisión tomada puede llegar a ser muy elevado si aplicamos metodologías tradicionales. Es por ello que varios problemas como los que a continuación mencionamos han sido detectados:
Retrasos en la planificación: llegada la fecha de entregar el software éste no está disponible.
Sistemas deteriorados: el software se ha creado pero después de un par de años el coste de su mantenimiento es tan complicado que definitivamente se abandona su producción.
Tasa de defectos: el software se pone en producción pero los defectos son tantos que nadie lo usa.
Requisitos mal comprendidos: el software no resuelve los requisitos planificados inicialmente.
Cambios de negocio: el problema que resolvía nuestro software ha cambiado y nuestro software no se ha adaptado.
Falsa riqueza: el software hace muchas cosas técnicamente muy interesantes y divertidas, pero no resuelven el problema de nuestro cliente, ni hace que éste gane más dinero.
Cambios de personal: después de unos años de trabajo los programadores comienzan a odiar el proyecto y lo abandonan.
Como respuesta a los problemas aplicando metodologías tradicionales surgieron otras metodologías que tratan de adaptarse a la realidad del desarrollo de software. El encanto de estas metodologías ágiles es su reacción ante la burocracia de las metodologías monumentales. Estos nuevos métodos buscan un justo medio entre ningún proceso y demasiado proceso, proporcionando simplemente suficiente proceso para que el esfuerzo valga la pena. El resultado de todo esto es que los métodos ágiles cambian significativamente algunos de los énfasis de los métodos ingenieriles. La diferencia inmediata es que son menos orientados al documento, exigiendo una cantidad más pequeña de documentación para una tarea dada. De muchas maneras son más bien orientados al código: siguiendo un camino que dice que la parte importante de la documentación es el código fuente.
2.2 Desarrollo 2.2.1 Metodologías pesadas.
2.2.1.1 RUP El proceso unificado de desarrollo (RUP) es una metodología para la ingeniería de software que va más allá del mero análisis y diseño orientado a objetos para proporcionar una familia de técnicas que soportan el ciclo completo de desarrollo de software. El resultado es un proceso basado en componentes, dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental. 2.2.1.1.1 Características principales de RUP
“Centrado en los modelos: Los diagramas son un vehículo de comunicación más expresivo que las descripciones en lenguaje natural. Se trata de minimizar el uso de descripciones y especificaciones textuales del sistema.”
“Guiado por los Casos de Uso: Los Casos de Uso son el instrumento para validar la arquitectura del software y extraer los casos de prueba.”
“Centrado en la arquitectura: Los modelos son proyecciones del análisis y el diseño constituye la arquitectura del producto a desarrollar.”
“Iterativo e incremental: Durante todo el proceso de desarrollo se producen versiones incrementales (que se acercan al producto terminado) del producto en desarrollo.”
2.2.1.1.2 Beneficios que aporta RUP
Permite desarrollar aplicaciones sacando el máximo provecho de las nuevas tecnologías, mejorando la calidad, le rendimiento, la reutilización,
la seguridad y el mantenimiento del software mediante una gestión sistemática de los riesgos.
Permite la producción de software que cumpla con las necesidades de los usuarios, a través de la especificación de los requisitos, con una agenda y costo predecible.
Enriquece la productividad en equipo y proporciona prácticas óptimas de software a todos sus miembros.
Permite llevar a cabo el proceso de desarrollo práctico, brindando amplias guías, plantillas y ejemplos para todas las actividades críticas.
Proporciona guías explicitas para áreas tales como modelado de negocios, arquitectura Web, pruebas y calidad. También se proporciona guías para desarrollar en plataformas IBM WebSphere y Microsoft Web Solution para acelerar el desarrollo de los proyectos.
Se integra estrechamente con herramientas Rational, permitiendo a los equipos de desarrollo aprovechar todas las ventajas de las características de los productos Rational, el Lenguaje de Modelado Unificado (UML) y otras prácticas óptimas de la industria.
Unifica todo el equipo de desarrollo de software y mejora la comunicación al brindar a cada miembro del mismo una base de conocimientos, un lenguaje de modelado y un punto de vista de cómo desarrollar software.
Optimiza la productividad de cada miembro del equipo al poner al alcance la experiencia derivada de miles de proyectos y muchos líderes de la industria.
No solo garantiza que los proyectos abordados serán ejecutados íntegramente sino que además evita desviaciones importantes respecto a los plazos.
Permite una definición acertada del sistema en un inicio para hacer innecesarias las reconstrucciones parciales posteriores.
2.2.2 Metodologías ágiles. 2.2.2.1 XP
La Programación Extrema surge ideada por Kent Beck, como proceso de creación de software diferente al convencional. En palabras de Beck: “XP es una metodología ligera, eficiente, con bajo riesgo, flexible, predecible y divertida para desarrollar software”. 2.2.2.1.1 Objetivos de XP: Los objetivos de XP son muy simples: la satisfacción del cliente. Esta metodología trata de dar al cliente el software que él necesita y cuando lo necesita. Por tanto, debemos responder muy rápido a las necesidades del cliente, incluso cuando los cambios sean al final de ciclo de la programación. El segundo objetivo es potenciar al máximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y están involucrados en el desarrollo del software.
2.2.2.1.2 Bases de XP
La programación extrema se basa en la simplicidad, la comunicación y el reciclado continuo de código, para algunos no es más que aplicar una pura lógica. Lo que buscan en definitiva es la reducción de costes. 2.2.2.1.3 Valores XP
Una de las cosas que a los programadores nos tiene que quedar muy claro es que en el ciclo de vida del desarrollo de un proyecto software los cambios van a aparecer, cambiarán los requisitos, las reglas de negocio, el personal, la tecnología, todo va a cambiar. Por tanto el problema no es el cambio en si, ya que este va a suceder sino la incapacidad de enfrentarnos a estos cambios. Como en otra cualquier actividad humana necesitamos valores para desarrollar nuestro trabajo y conseguir los planteamientos iniciales. Estos cuatro valores son:
Comunicación
Sencillez
Retroalimentación
Valentía 2.2.2.1.4 Variables XP
XP define cuatro variables para proyectos de software:
Coste
Tiempo
Calidad
Ámbito.
2.2.2.1.5 Actividades básicas XP Ahora que tenemos nuestros cuatro valores estamos preparados para construir una disciplina de desarrollo de software. ¿Qué tareas debemos de llevar a cabo para desarrollar un buen software? 2.2.2.1.5.1 Codificar
Es la única actividad de la que no podremos prescindir. Sin código fuente no hay programa, aunque hay gente que cuenta que existe software en producción del que se perdió el código fuente. Por tanto necesitamos codificar y plasmar nuestras ideas a través del código. En una programación en XP en pareja el código expresa tu interpretación del problema, así podemos utilizar el código para comunicar, para hacer mías tus ideas, y por tanto para aprender y mejorar. 2.2.2.1.5.2 Hacer pruebas
Las características del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas me dan la oportunidad de saber si lo que implementé es lo que en realidad yo pensaba que había implementado. Las pruebas nos indican que nuestro trabajo funciona, cuando
no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema entonces has acabado por completo. No debemos de escribir tan solo una prueba ver que funciona y salir corriendo, debemos de pensar en todas las posibles pruebas para nuestro código, con el tiempo llegarás a conclusiones sobre las pruebas y podrás pensar que si dos de tus pruebas ya funcionan la tercera prueba no será necesaria escribirla, sin caer en demasiada confianza. Programar y probar es más rápido que sólo programar. Puedes ganar media hora de productividad sin hacer pruebas, pero perderás mucho tiempo en la depuración. Tendrás menos errores, tendrás que volver menos veces sobre el código, te costará menos localizar los errores, perderás menos tiempo escuchado como tus clientes te dicen que no funciona. Las pruebas deben de ser sensatas y valientes. No podemos hacer pruebecillas que no testen a fondo el sistema, esos agujeros que vamos dejando nos esperan para cuando pasemos de nuevo por allí y volveremos a caer dentro. 2.2.2.1.5.3 Escuchar
Los programadores no lo conocemos todo, y sobre todo muchas cosas que las personas de negocios piensan que son interesantes. Si ellos pudieran programarse su propio software ¿ para que nos querrían ?. Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la información. Tenemos que escuchar a nuestros clientes cuales son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fácil y difícil de obtener, y la realimentación entre ambos nos ayudan a todos a entender los problemas. 2.2.2.1.5.4 Diseñar
El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, divídela en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes. Tenemos que codificar porque sin código no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos que codificar ni probar, y tenemos que diseñar para poder codificar, probar y escuchar indefinidamente. 2.2.2.1.6 Prácticas Básicas de XP
2.2.2.1.6.1 El juego de la planificación.
Hay una comunicación frecuente el cliente y los programadores. El equipo técnico realiza una estimación del esfuerzo requerido para la implementación de las historias de usuario y los clientes deciden sobre el ámbito y tiempo de las entregas y de cada iteración.
2.2.2.1.6.2 Pequeñas versiones.
Cada versión debe de ser tan pequeña como fuera posible, conteniendo los requisitos de negocios más importantes, las versiones tiene que tener sentido como un todo, me explico no puedes implementar media característica y lanzar la versión. Es mucho mejor planificar para 1 mes o 2 que para seis meses y un año, las compañías que entregan software muy voluminoso no son capaces de hacerlo con mucha frecuencia. 2.2.2.1.6.3 Metáfora.
Una metáfora es una historia que todo el mundo puede contar a cerca de cómo funciona el sistema. Algunas veces podremos encontrar metáforas sencillas “Programa de gestión de compras, ventas, con gestión de cartera y almacén”. Las metáforas ayudan a cualquier persona a entender el objeto del programa. 2.2.2.1.6.4 Diseño sencillo.
El diseño adecuado para el software es aquel que: 1. Funciona con todas las pruebas. 2. No tiene lógica duplicada. 3. Manifiesta cada intención importante para los programadores 4. Tiene el menor número de clases y métodos.
Haz el diseño lo más simple posible borra todo lo que puedas sin violar las reglas 1,2 y 3. Contrariamente a lo que se pensaba el “Implementa para hoy, diseña para mañana”, no es del todo correcto si piensas que el futuro es incierto. 2.2.2.1.6.5 Hacer pruebas.
No debe existir ninguna característica en el programa que no haya sido probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa mas seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios. 2.2.2.1.6.6 Recodificación.
Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo mas simple posible, después de implementar esta característica, nos preguntamos como hacer el programa mas simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring). Esto a veces nos puede llevar a hacer mas trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas características. No debemos de recodificar ante especulaciones si no solo cuándo el sistema te lo pida. 2.2.2.1.6.7 Programación por parejas.
Todo el código de producción lo escriben dos personas frente al ordenador, con un sólo ratón y un sólo teclado. Cada miembro de la pareja juega su papel: uno
codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa más estratégicamente, ¿Va a funcionar?, ¿Puede haber pruebas donde no funcione?, ¿Hay forma de simplificar el sistema global para que el problema desaparezca? El emparejamiento es dinámico, puedo estar emparejado por la mañana con una persona y por la tarde con otra, si tienes un trabajo sobre un área que no conoces muy bien puedes emparejarte con otra persona que si conozca ese área. Cualquier miembro del equipo se puede emparejar con cualquiera. 2.2.2.1.6.8 Propiedad colectiva.
Cualquiera que crea que puede aportar valor al código en cualquier parcela puede hacerlo, ningún miembro del equipo es propietario del código. Si alguien quiere hacer cambios en el código puede hacerlo. Si hacemos el código propietario, y necesitamos de su autor para que lo cambie entonces estaremos alejándonos cada vez mas de la comprensión del problema, si necesitamos un cambio sobre una parte del código lo hacemos y punto. XP propone un propiedad colectiva sobre el código nadie conoce cada parte igual de bien pero todos conoce algo sobre cada parte, esto nos preparará para la sustitución no traumática de cada miembro del equipo. 2.2.2.1.6.9 Integración continúa.
El código se debe integrar como mínimo una vez al día, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargara de integrar todo el código en una maquina y realizar todas las pruebas hasta que estas funcionen al 100%. 2.2.2.1.6.10 40 Horas semanales.
Si queremos estar frescos y motivados cada mañana y cansado y satisfecho cada noche. El viernes quiero estar cansado y satisfecho para sentir que tengo dos días para pensar en algo distinto y volver el lunes lleno de pasión e ideas. Esto requiere que trabajemos 40 horas a la semana, mucha gente no puede estar más de 35 horas concentrados a la semana, otros pueden llegar hasta 45 pero ninguno puede llegar a 60 horas durante varias semanas y aun seguir fresco, creativo y confiado. Las horas extras son síntoma de serios problemas en el proyecto, la regla de XP dice nunca 2 semanas seguidas realizando horas extras. 2.2.2.1.6.11 Cliente In-situ.
Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades. Lo difícil es que el cliente nos ceda una persona que conozca el negocio para que se integre en el equipo normalmente estos elementos son muy valiosos, pero debemos de hacerles ver que será mejor para su negocio tener un software pronto en funcionamiento, y esto no implica que el cliente no pueda realizar cualquier otro trabajo. 2.2.2.1.6.12 Estándares de codificación.
Si los programadores van a estar tocando partes distintas del sistema, intercambiando compañeros, haciendo refactoring, debemos de establecer un estándar de codificación aceptado e implantado por todo el equipo.
2.2.2.1.7 Características esenciales de XP
2.2.2.1.7.1 Roles.
Programador: Produce el código del sistema. Cliente: Escribe las HU y las pruebas funcionales para validar su
implementación, así como asigna la prioridad de la HU y decide cuál se implementara en cada iteración.
Encargado de pruebas: Ayuda al cliente a escribir las pruebas funcionales, ejecuta las pruebas y difunde resultados además es responsable de las herramientas de soporte para prueba.
Rastreador (Tracker): también conocido como “Metric Man”, observa sin molestar y mantiene los datos históricos.
Consultor: Es un miembro externo del equipo con conocimiento especifico de algún tema necesario para el proyecto. Guía al equipo para resolver un problema específico.
Gestor (Big Boss): Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.
2.2.2.1.7.2 Artefactos esenciales.
Historias de Usuario. Tareas de Ingeniería. Pruebas de Aceptación.
2.2.2.1.7.3 Procesos.
Ciclo de desarrollo. Ciclo de vida(Fases)
1. Exploración 2. Planificación. 3. Iteraciones. 4. Producción. 5. Mantenimiento. 6. Muerte Proyecto.
2.2.2.1.7.4 Prácticas.
2.2.2.2 3P.
Paradigma 3P es una metodología de desarrollo de software nacida al calor de la experiencia acumulada del grupo de investigación y desarrollo Atis debido a la insuficiente capacidad de respuesta a los clientes utilizando las metodologías tradicionales. 2.2.2.2.1 Principios que sustentan el modelo
1. Los individuos y sus interacciones son más importantes que los procesos y las herramientas: El PERSONAL.
2. La comunicación con el cliente evita construir una elegante solución para un problema equivocado: El PROBLEMA.
3. El software que funciona es más importante que la documentación exhaustiva. El PROCESO.
2.2.2.2.2 Valores 3P
1. Comunicación: Sin comunicación todo proyecto estaría destinado a fracasar , comunicar no es escribir o hablar muchas palabras sino utilizar solo las palabras necesarias para trasmitir una idea.
2. Sencillez: Nadie es mejor o peor que los demás miembros del grupo de desarrollo , todos tenemos fortalezas y debilidades, conocerlas hará que nuestras relaciones con los miembros del grupo sean mejores en el orden profesional y personal.
3. Retroalimentación: Saber cuándo se debe rehacer algo que no funciona, equivocarse es de humanos, encarar nuevamente la tarea con emprendimiento y optimismo.
4. Emprendimiento: estar dispuesto siempre a acometer las tareas más complejas, encararla con esmero y con alegría hará que crezca nuestro prestigio entre los demás miembros, la convicción y el deseo del triunfo debe prevalecer.
5. Optimismo: Ser realista pero tener siempre el pensamiento orientado hacia el éxito.
2.2.2.2.3 Actividades básicas 1. Codificar. 2. Probar. 3. Comunicar 4. Idear 5. Escuchar. 6. Diseñar.
2.2.2.2.4 Roles del proyecto
1. Jefe del Proyecto 2. Cliente 3. Consultor 4. Analista-Programador 5. Programador 6. Diseñador de Interfaces
2.2.2.2.5 Principios que sustentan la metodología 1. EL Personal: Gestión de Proyecto 2. El Problema: Gestión del Cliente 3. El Proceso: Ciclo de Vida de Desarrollo
2.2.2.2.6 Ciclo de vida de desarrollo
1. Definición del problema. 2. Identificación de los procesos unitarios. 3. Diseño del prototipo. 4. Desarrollo del prototipo. 5. Prueba del prototipo. 6. Si <no prueba de Prototipo>ir a Paso 3. 7. Si <Prototipo difiere Sistema Deseado>ir a Paso 2. 8. Si <no Necesidades satisfechas>ir a Paso 2. 9. Implantación. 10. Mantenimiento.
2.3 Resumen puntos clave 2.3.1 RUP Pesado Dividido en cuatro fases, que se dividen en iteraciones El discurrir del proyecto se define en Workflows Los artefactos son el objetivo de cada actividad Se basa en roles UML Muy organizativo Mucha documentación
2.3.2 3P
Ágil Cercano al desarrollo, pero sin olvidar el diseño. Se basa en 3 principios: Personal, Problema, Proceso. Gran interacción con el cliente. Pruebas de funcionalidad y calidad. Logra alcanzar un control y organización del proceso. Logra un equilibrio en cuanto a la generación de documentación
2.3.3 XP
Ligero Cercano al desarrollo Se basa en UserStories Fuerte comunicación con el cliente
El código fuente pertenece a todos Programación por parejas Tests como base de la funcionalidad Solo el mínimo de organización Pobre en cuanto a documentación
2.4 Conclusiones
¿Qué debemos esperar entonces de un proceso de desarrollo? ¿Qué criterios debe cumplir para que aporte algo a la empresa? Básicamente el proceso de desarrollo tiene que ayudarnos a escribir software, tiene que poner las reglas necesarias para alcanzar el éxito en nuestro proyecto pero dejando la libertad suficiente para no sentirnos agobiados. Esto no nos lo va a ofrecer ningún proceso estándar, y como dice el refrán (aunque no se cumple exactamente en el mundo de la informática) todos los caminos conducen a Roma.
De forma que es tarea de cada empresa, casi para cada proyecto, decidir cual es el mejor modo de llegar a nuestra meta.
2.5 Referencias [ANO08,1]. Anónimo. Seminario sobre RUP en un entorno empresarial
de desarrollo. http://www-5.ibm.com/services/learning/es/tairis.nsf/(ExtCourseNr)-/RUPS1ES. (2/5/08)
[ANO08,2]. Anónimo. Rational Unified Process. http://www.itera.com.mx/itera-/productos/fundamentos.asp. (2/5/08)
[ANO05,3]. Anónimo. Proceso Unificado de Rational para el desarrollo de software. http://www.dybox.cl/metodologia/rup.html. (2/5/08)
[BAR08]. Barrientos Enríquez, Aleida Mirian. El desarrollo de sistemas de información empleando el lenguaje de modelado unificado UML.
[JAC08]. Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El Proceso Unificado de Desarrollo de Software.
[ECH08]. Echevarría Cossío, Yanelis. Modelo Ágil de Desarrollo de Proyectos de Software:Paradigma 3P.
2.6 Bibliografía
Alianza Ágil, http://www.agilealliance.org Patricio Letelier, Departamento de Sistemas Informáticos y
Computación, Universidad Politécnica de Valencia, [email protected] Manifiesto para el Desarrollo de Software Ágil,
http://www.agilemanifesto.org
Martín Fowler, La Nueva Metodología, http://www.programacion.net Alistair, Desarrollo de Software Ágil, http://www.amazon.com/exec/obidos/ASIN/0201699699/programacione-20 Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El Proceso Unificado
de Desarrollo de Software. Echevarría Cossío, Yanelis. Modelo Ágil de Desarrollo de Proyectos de
Software:Paradigma 3P. Anónimo. Proceso Unificado de Rational para el desarrollo de software. http://www.dybox.cl/metodologia/rup.html. (2/5/05) Anónimo. Rational Unified Process.
http://www.itera.com.mx/itera/productos/fundamentos.asp. (2/5/05) Anónimo. Seminario sobre RUP en un entorno empresarial de
desarrollo. http://www-5.ibm.com/services/learning/es/tairis.nsf/(ExtCourseNr)/RUPS1ES. (2/5/05)
Barrientos Enríquez, Aleida Mirian. El desarrollo de sistemas de información empleando el lenguaje de modelado unificado UML.
3 Análisis y Diseño de Sistemas 3.1 Análisis de Sistemas de Computación 3.1.1 Conceptos y Análisis
Es un conjunto o disposición de procedimientos o programas relacionados de manera que juntos forman una sola unidad. Un conjunto de hechos, principios y reglas clasificadas y dispuestas de manera ordenada mostrando un plan lógico en la unión de las partes. Un método, plan o procedimiento de clasificación para hacer algo. También es un conjunto o arreglo de elementos para realizar un objetivo predefinido en el procesamiento de la Información. Esto se lleva a cabo teniendo en cuenta ciertos principios:
Debe presentarse y entenderse el dominio de la información de un problema.
Defina las funciones que debe realizar el Software.
Represente el comportamiento del software a consecuencias de acontecimientos externos.
Divida en forma jerárquica los modelos que representan la información, funciones y comportamiento.
El proceso debe partir desde la información esencial hasta el detalle de la Implementación. La función del Análisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios. Para
conseguir este objetivo, un Sistema basado en computadoras hace uso de seis (6) elementos fundamentales:
1. Software, que son Programas de computadora, con estructuras de datos y su documentación que hacen efectiva la logística metodología o controles de requerimientos del Programa.
2. Hardware, dispositivos electrónicos y electromecánicos, que proporcionan capacidad de cálculos y funciones rápidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.), que proporcionan una función externa dentro de los Sistemas.
3. Personal, son los operadores o usuarios directos de las herramientas del Sistema.
4. Base de Datos, una gran colección de informaciones organizadas y enlazadas al Sistema a las que se accede por medio del Software.
5. Documentación, Manuales, formularios, y otra información descriptiva que detalla o da instrucciones sobre el empleo y operación del Programa.
6. Procedimientos, o pasos que definen el uso especifico de cada uno de los elementos o componentes del Sistema y las reglas de su manejo y mantenimiento.
Un Análisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en mente:
Identifique las necesidades del Cliente.
Evalúe que conceptos tiene el cliente del sistema para establecer su viabilidad.
Realice un Análisis Técnico y económico.
Asigne funciones al Hardware, Software, personal, base de datos, y otros elementos del Sistema.
Establezca las restricciones de presupuestos y planificación temporal.
Cree una definición del sistema que forme el fundamento de todo el trabajo de Ingeniería.
Para lograr estos objetivos se requiere tener un gran conocimiento y dominio del Hardware y el Software, así como de la Ingeniería humana (Manejo y Administración de personal), y administración de base de datos. 3.1.2 Objetivos del Análisis 3.1.2.1 Identificación de Necesidades
Es el primer paso del análisis del sistema, en este proceso en Analista se reúne con el cliente y/o usuario (un representante institucional, departamental o cliente particular), e identifican las metas globales, se analizan las perspectivas del cliente, sus necesidades y requerimientos, sobre la planificación temporal y presupuestal, líneas de mercadeo y otros puntos que puedan ayudar a la identificación y desarrollo del proyecto.
Algunos autores suelen llamar a esta parte ¨ Análisis de Requisitos ¨ y lo dividen en cinco partes:
Reconocimiento del problema. Evaluación y Síntesis.
Modelado.
Especificación.
Revisión. Antes de su reunión con el analista, el cliente prepara un documento conceptual del proyecto, aunque es recomendable que este se elabore durante la comunicación Cliente – analista, ya que de hacerlo el cliente solo de todas maneras tendría que ser modificado, durante la identificación de las necesidades. 3.1.2.2 Estudio de Viabilidad Muchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recursos y el tiempo no son realistas para su materialización sin tener perdidas económicas y frustración profesional. La viabilidad y el análisis de riesgos están relacionados de muchas maneras, si el riesgo del proyecto es alto, la viabilidad de producir software de calidad se reduce, sin embargo se deben tomar en cuenta cuatro áreas principales de interés: 3.1.2.2.1 Viabilidad económica
Una evaluación de los costos de desarrollo, comparados con los ingresos netos o beneficios obtenidos del producto o Sistema desarrollado. 3.1.2.2.2 Viabilidad Técnica Un estudio de funciones, rendimiento y restricciones que puedan afectar la realización de un sistema aceptable. 3.1.2.2.3 Viabilidad Legal
Es determinar cualquier posibilidad de infracción, violación o responsabilidad legal en que se podría incurrir al desarrollar el Sistema. 3.1.2.2.4 Alternativas. Una evaluación de los enfoques alternativos del desarrollo del producto o Sistema. El estudio de la viabilidad puede documentarse como un informe aparte para la alta gerencia. 3.1.2.3 Análisis Económico y Técnico
El análisis económico incluye lo que llamamos, el análisis de costos – beneficios, significa una valoración de la inversión económica comparado con los beneficios que se obtendrán en la comercialización y utilidad del producto o sistema. Muchas veces en el desarrollo de Sistemas de Computación estos son intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a la
características del Sistema. El análisis de costos – beneficios es una fase muy importante de ella depende la posibilidad de desarrollo del Proyecto. En el Análisis Técnico, el Analista evalúa los principios técnicos del Sistema y al mismo tiempo recoge información adicional sobre el rendimiento, fiabilidad, características de mantenimiento y productividad. Los resultados obtenidos del análisis técnico son la base para determinar sobre si continuar o abandonar el proyecto, si hay riesgos de que no funcione, no tenga el rendimiento deseado, o si las piezas no encajan perfectamente unas con otras. 3.1.2.4 Modelado de la arquitectura del Sistema Cuando queremos dar a entender mejor lo que vamos a construir en el caso de edificios, Herramientas, Aviones, Maquinas, se crea un modelo idéntico, pero en menor escala (mas pequeño). Sin embargo cuando aquello que construiremos es un Software, nuestro modelo debe tomar una forma diferente, deben representar todas las funciones y subfunciones de un Sistema. Los modelos se concentran en lo que debe hacer el sistema no en como lo hace, estos modelos pueden incluir notación gráfica, información y comportamiento del Sistema. Todos los Sistemas basados en computadoras pueden modelarse como transformación de la información empleando una arquitectura del tipo entrada y salida. 3.1.2.5 Especificaciones del Sistema Es un Documento que sirve como fundamento para la Ingeniería Hardware, software, Base de datos, e ingeniería Humana. Describe la función y rendimiento de un Sistema basado en computadoras y las dificultades que estarán presente durante su desarrollo. Las Especificaciones de los requisitos del software se produce en la terminación de la tarea del análisis.
3.2 Diseño de sistemas de computación
3.2.1 Conceptos y principios El Diseño de Sistemas se define el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretación y realización física. La etapa del Diseño del Sistema encierra cuatro etapas: 3.2.1.1 El diseño de los datos Trasforma el modelo de dominio de la información, creado durante el análisis, en las estructuras de datos necesarios para implementar el Software. 3.2.1.2 El Diseño Arquitectónico
Define la relación entre cada uno de los elementos estructurales del programa. 3.2.1.3 El Diseño de la Interfaz
Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con el y con los operadores y usuarios que lo emplean.
3.2.1.4 El Diseño de procedimientos Transforma elementos estructurales de la arquitectura del programa. La importancia del Diseño del Software se puede definir en una sola palabra Calidad, dentro del diseño es donde se fomenta la calidad del Proyecto. El Diseño es la única manera de materializar con precisión los requerimientos del cliente. El Diseño del Software es un proceso y un modelado a la vez. El proceso de Diseño es un conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del Sistema a construir. A lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un conjunto de revisiones técnicas: El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acumular todos los requisitos implícitos que desea el cliente. Debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el Software. El Diseño debe proporcionar una completa idea de lo que es el Software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementación. Para evaluar la calidad de una presentación del diseño, se deben establecer criterios técnicos para un buen diseño como son:
Un diseño debe presentar una organización jerárquica que haga un uso inteligente del control entre los componentes del software.
El diseño debe ser modular, es decir, se debe hacer una partición lógica del Software en elementos que realicen funciones y subfunciones especificas.
Un diseño debe contener abstracciones de datos y procedimientos.
Debe producir módulos que presenten características de funcionamiento independiente.
Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los módulos y el entorno exterior.
Debe producir un diseño usando un método que pudiera repetirse según la información obtenida durante el análisis de requisitos de Software.
Estos criterios no se consiguen por casualidad. El proceso de Diseño del Software exige buena calidad a través de la aplicación de principios fundamentales de Diseño, Metodología sistemática y una revisión exhaustiva. Cuando se va a diseñar un Sistema de Computadoras se debe tener presente que el proceso de un diseño incluye, concebir y planear algo en la mente, así como hacer un dibujo o modelo o croquis. 3.2.1.5 5. Diseño de la Salida
En este caso salida se refiere a los resultados e informaciones generadas por el Sistema, Para la mayoría de los usuarios la salida es la única razón para el
desarrollo de un Sistema y la base de evaluación de su utilidad. Sin embargo cuando se realiza un sistema, como analistas deben realizar lo siguiente:
Determine que información presentar. Decidir si la información será presentada en forma visual, verbal o impresora y seleccionar el medio de salida.
Disponga la presentación de la información en un formato aceptable.
Decida como distribuir la salida entre los posibles destinatarios. 3.2.1.6 Diseño de Archivos Incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se fuera a emplear para guardar detalles de las transacciones, datos históricos, o información de referencia. Entre las decisiones que se toman durante el diseño de archivos, se encuentran las siguientes:
Los datos que deben incluirse en el formato de registros contenidos en el archivo.
La longitud de cada registro, con base en las características de los datos que contenga.
La secuencia a disposición de los registros dentro del archivo (La estructura de almacenamiento que puede ser secuencial, indexada o relativa).
No todos los sistemas requieren del diseño de todos los archivos, ya que la mayoría de ellos pueden utilizar los del viejo Sistema y solo tenga que enlazarse el nuevo Sistema al Archivo maestro donde se encuentran los registros. 3.2.1.7 Diseño de Interacciones con la Base de Datos
La mayoría de los sistemas de información ya sean implantado en sistemas de cómputos grandes o pequeños, utilizan una base de datos que pueden abarcar varias aplicaciones, por esta razón estos sistemas utilizan u administrador de base de datos, en este caso el diseñador no construye la base de datos sino que consulta a su administrador para ponerse de acuerdo en el uso de esta en el sistema. 3.2.2 Herramientas para el Diseño de Sistemas Apoyan el proceso de formular las características que el sistema debe tener para satisfacer los requerimientos detectados durante las actividades del análisis: 3.2.2.1 Herramientas de especificación Apoyan el proceso de formular las características que debe tener una aplicación, tales como entradas, Salidas, procesamiento y especificaciones de control. Muchas incluyen herramientas para crear especificaciones de datos. 3.2.2.2 Herramientas para presentación Se utilizan para describir la posición de datos, mensajes y encabezados sobre las pantallas de las terminales, reportes y otros medios de entrada y salida.
3.2.2.3 Herramientas para el desarrollo de Sistemas Estas herramientas nos ayudan como analistas a trasladar diseños en aplicaciones funcionales. 3.2.2.4 Herramientas para Ingeniería de Software Apoyan el Proceso de formular diseños de Software, incluyendo procedimientos y controles, así como la documentación correspondiente. 3.2.2.5 Generadores de códigos
Producen el código fuente y las aplicaciones a partir de especificaciones funcionales bien articuladas. 3.2.2.6 Herramientas para pruebas
Apoyan la fase de la evaluación de un Sistema o de partes del mismo contra las especificaciones. Incluyen facilidades para examinar la correcta operación del Sistema así como el grado de perfección alcanzado en comparación con las expectativas. La revolución del procesamiento de datos de manera computarizada, junto con las prácticas de Diseño sofisticadas está cambiando de forma dramática la manera en que se trasladan las especificaciones de Diseño d Sistemas de Información funcionales.
3.3 Análisis de Sistemas de Apoyo a Decisiones Semiestructuradas
3.3.1 Métodos Disponibles
Para poder obtener buenos resultados en los sistemas de apoyo a decisiones estructuradas, debemos dividir el trabajo como lo dice anteriormente el análisis de sistema del que estamos hablando, debe tener en cuenta:
Si es analítico o heurístico
Cómo son tomadas la decisiones en las tres fases de resolución de problemas de inteligencia
El uso de los métodos de criterios múltiples útiles para la resolución de problemas semiestructurados.
Estos sistemas pueden funcionar de varias formas es decir, la organización de la información para las situaciones de decisión, la interacción con los tomadores de decisiones que llevan consigo la expansión en la toma de decisiones, la forma de presentar la información para su mejor comprensión añadiendo modelos y criterios múltiples. En donde los modelos de criterios múltiples incluyen procesos de compromiso, métodos ponderados y métodos de eliminación secuencial y son los más adecuados para el manejo de la complejidad y naturaleza semiestructurada. 3.3.2 Sistemas de apoyo a Decisiones Este método posee características que lo diferencia de los demás sistemas que manejan información y que son tradicionales. Los usuarios finales de los DSS
(sistemas de apoyo a decisiones) poseen características especiales que merecen ser tomadas en cuenta. 3.3.2.1 Características de un sistema de apoyo a decisiones
Debemos tener en cuenta que un sistema de apoyo a decisiones lo definiremos como la manera de organización de información que se pretende usar en la toma de decisiones. Para lo cual al presentar la información debe estar diseñada basándose en la solución de problemas y esto debe darse ya que el usuario no debe tomar la decisión, sino el DSS. Un DSS permite al tomador de decisiones interactuar con él, y esto debe verse en la interfaz del usuario. Un DSS puede ser construido para dar soporte a decisiones de una sola vez y son aquellas que son poco frecuentes a otras que suceden rutinariamente. Un DSS debe ser diseñado típicamente para decisiones de un particular o para un grupo, es decir que el usuario entienda mejor las soluciones por medio de gráficas, tablas u otro medio de presentación y que sea de interfaz para el usuario. Debemos saber utilizar las diferentes herramientas que generan DSS, así como en la construcción de DSS específicos, y generadores de DSS. Para el DSS, el proceso trabajará para la transformación del usuario, el tomados de decisiones y debe dar como resultado un cambio y mejora del desempeño en la toma de decisiones. 3.3.2.2 Usuarios de los sistemas de apoyo a decisiones Dentro de las organizaciones existen tres niveles, el estratégico, el administrativo y el operacional, es por eso que a nivel operacional las decisiones se pueden tomar y ser automatizadas satisfactoria y completamente. Los tipos de problemas que ayuda a solucionar un DSS son complejos y semiestructurados ya que este tipo de problemas los ve registrados en los niveles estratégico y administrativo. Es importante que si el usuario final está muy ocupado o preocupado por la interacción con el DSS, este puede ser utilizado por un intermediario técnico o ayudante que interactúe con la computadora y así las decisiones serán tomadas de una forma desde el proceso y no desde la mecánica.
3.3.3 Conceptos del proceso de Toma de decisiones relevantes para los DSS Para la toma de decisiones sabemos que es necesario hacer uso de la información como, el uso de teorías, que tiene como consecuencia el acierto, la incertidumbre y el riesgo, es por eso que debemos diferenciar si el tomador de decisiones en analítico o heurístico y es importante que estos tomen en cuenta las fases de solución como son la inteligencia, la selección y el diseño, tal como se le da soporte en los sistemas de apoyo a decisiones. 3.3.3.1 La toma de decisiones bajo riesgo
Las decisiones son tomadas por lo general bajo tres condiciones importantes como lo es la: certidumbre, incertidumbre y el riego.
La certidumbre es aquella que nos muestra todo por anticipado antes de la decisión, los resultados, las consecuencias y según sean las necesidades presentadas por el usuario. La incertidumbre es lo contrario de la certidumbre, no tenemos resultados, ni probabilidades o las consecuencias de las decisiones. Entre estos dos aspectos o condiciones tienen por medio el riesgo, es decir que tenemos el conocimiento (certidumbre) de las alternativas (variables controlables), existen sólo las estimaciones y no está en nuestras manos el controlar (variables ambientales) y de las que no estamos seguros de su resultado (variables dependientes). Bajo estas alternativas que tenemos muchas de las tomas de decisiones en las empresas o negocios se realizan bajo riesgo. 3.3.3.2 El estilo de la toma de decisiones
Por lo general la información se recolecta, procesa y se usa en forma de parámetro según sea el estilo de la toma de decisiones. Y es por eso que los tomadores de decisiones son analíticos o heurísticos. Un tomador de decisiones analítico se apoya en la información que es adquirida y evaluada sistemáticamente para estrechar las alternativas y tomar una selección que esté basada en información. En donde los tomadores de decisiones analíticos valoran la información cuantitativa y los modelos que la generan y la usan. Como comentario adicional, utilizan matemáticas para el modelo del problema y usan algoritmos para resolverlos. Un tomador de decisiones heurístico se hace ayudar de lineamientos (reglas), aunque no se adapte, bajo conciencia o un sistema, esto es que la heurística se basa en la experiencia. Estos tomadores de decisiones aprenden bajo las actuaciones, es decir mediante la prueba y el error hasta encontrar la solución. Y su apoyo es el sentido común para que los guíe.
Tomador de decisiones analítico
Tomador de decisiones heurístico
Aprende mediante análisis Usa procedimientos paso a paso Valora la información cuantitativa y los modelos Constituye modelos matemáticos y algoritmos Busca soluciones óptimas
Aprende actuando Usa prueba y error Valora la experiencia Se apoya en el sentido común Busca soluciones satisfactorias
3.3.4 Fases para la solución de problemas
La toma de decisiones (o resolución de problemas) es un proceso, y está concebido en fases en vez de pasos. Puesto que en las fases, la ocurrencia de comportamiento se agranda y se escoge, y como diferencia de los pasos es
que estos se llevan a cabo mediante una secuencia, es decir no podemos seguir sino se ha terminado el anterior y se realizan de forma independiente. Las fases para la toma de decisiones son la: Inteligencia, el diseño y la selección (Simón 1965) Y se inicia en la forma como se ha escrito.
Inteligencia: es la conciencia de un problema u oportunidad, el tomador de decisiones busca en los ambientes de negocios interno y externo, revisando las decisiones que deberá tomar, problemas a resolver u oportunidades a examinar. La inteligencia se traduce como la vigilancia, la búsqueda continua y revisión.
Diseño: Formula un problema y analiza las varias soluciones alternativas, proporcionando al tomador de decisiones generar y analizar alternativas para su aplicabilidad potencial.
Selección: La selección del tomador de decisiones de una solución al problema u oportunidad identificado en la fase de inteligencia. Incluyendo la implementación de la selección del tomador de decisiones. Hay otros autores que incluyen la implementación y la evaluación.
3.4 Conclusiones En Conclusión un proyecto de desarrollo de un Sistema de Información comprende varios componentes o pasos llevados a cabo durante la etapa del análisis, el cual ayuda a traducir las necesidades del cliente en un modelo de Sistema que utiliza uno mas de los componentes: Software, hardware, personas, base de datos, documentación y procedimientos. En una organización o Empresa, el análisis y Diseño de Sistemas, es el proceso de estudiar su Situación con la finalidad de observar como trabaja y decidir si es necesario realizar una mejora; el encargado de llevar a cabo estas tareas es el analista de sistemas. Antes de comenzar con el desarrollo de cualquier proyecto, se conduce un estudio de Sistemas para detectar todos los detalles de la situación actual de la empresa. La información reunida con este estudio sirve como base para crear varias estrategias de Diseño. Los administradores deciden que estrategias seguir. Los Gerentes, empleados y otros usuarios finales que se familiarizan cada vez mas con el uso de computadoras están teniendo un papel muy importante en el desarrollo de sistemas. Todas las organizaciones son Sistemas que actúan de manera reciproca con su medio ambiente recibiendo entradas y produciendo salidas. Los Sistemas que pueden estar formados por otros Sistemas de denominan subsistemas y funcionan para alcanzar los fines de su Implantación. Es por eso que existen varios modelos o métodos para la realización del análisis y diseño de un sistema, lo primero del trabajo fue revisar que es el Análisis y el diseño y posteriormente el autor Kendall, presenta varios modelos que podemos utilizar para la realización y elaboración de un proceso y trabajo exhaustivo y dar solución o respuesta al problema que se ha generado desde la perspectiva del programador y analista.
3.5 Bibliografía Kendall & Kendall; Análisis y Diseño de Sistemas; 3ª Edición; Pearson
Educación. Roger S. Pressman; Ingeniería del Software;4ª Edición; Mc Graw Hill