Antologia

Licenciatura en Ingenieria de Sistemas Computacionales Mike Zamora Gonzlez

Universidad Tecnolgica Costarricense

Metodologia del diseo de Sistemas I

Autores: Erly Delgado Expsito y Gerardo Moreno Martnez

Contenido
1 Metodologas modernas de desarrollo de Sistemas de Informacin ........... 5 1.1 1.2 1.3 1.4 1.5 1.6 1.7 INTRODUCCION .................................................................................. 5 HISTORIA ............................................................................................. 5 CONCEPTOS BASICOS DE ORIENTACION A OBJETOS .................. 7 QUE ES UNA METODOLOGIA? ........................................................... 9 EL ENFOQUE ....................................................................................... 9 RESULTADO ESPERADO.................................................................. 11 CONCEPTOS...................................................................................... 12
DEFINICIN DEL "OBJETO" EN CADA METODOLOGIA .................... 12 DEFINICIN DE "CLASE" EN CADA METODOLOGIA ......................... 14 DEFINICIN DE "OPERACION" EN CADA METODOLOGIA ............... 16 DEFINICIN DE "METACLASE" EN CADA METODOLOGIA ............... 18

1.7.1 1.7.2 1.7.3 1.7.4

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
COMPONENTES DE LA NOTACIN DE LAS MTODOLOGIAS ......... 23

1.8.1

1.8.2 REPRESENTACIONES GRAFICAS DE ALGUNOS DIAGRAMAS UTILIZADOS POR BOOCH, COAD & YOURDON, Y RUMBAUGH..................... 26 1.8.3 CONCEPTOS ESTTICOS QUE LA NOTACIN ES CAPAZ DE EXPRESAR ......................................................................................................... 27 1.8.4 CONCEPTOS DINMICOS QUE LA NOTACIN ES CAPAZ DE EXPRESAR ......................................................................................................... 28 1.8.5 REGLAS EXPLCITAS PARA DEFINIR LOS SMBOLOS DE LAS NOTACIONES ..................................................................................................... 28 1.8.6 MECANISMO DE PARTICION DENTRO DE LA NOTACION ................ 30

1.9

PROCESOS ........................................................................................ 30
PASOS DEL PROCESO DE DESARROLLO DE CADA METODOLOGA 30

1.9.1

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 1.9.6 1.9.7 1.9.8 1.9.9

DEFINICION DE LOS PASOS DEL PROCESO .................................... 41 HEURSTICA DISPONIBLE PARA LOS PASOS DE PROCESO .......... 42 VERIFICACION DEL PROCESO........................................................... 43 VALIDACION DEL PROCESO .............................................................. 44 Metodologa ........................................................................................... 44

1.10
1.10.1

ASPECTOS PRAGMATICOS .......................................................... 44

RECURSOS DE AYUDA DISPONIBLE ................................................. 44

Recursos ............................................................................................................. 44 1.10.2 ENTRENAMIENTO REQUERIDO PARA LA UTILIZACION DE LA METODOLOGIA (Independiente del entrenamiento del Lenguaje de programacin)...................................................................................................... 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 1.10.7 EJEMPLO COMPARATIVO................................................................... 48 APLICACIN DE LAS METODOLOGIAS .............................................. 49

1.11 1.12 2 2.1 2.2

CONCLUSION ................................................................................. 50 BIBLIOGRAFIA ................................................................................ 51 Introduccin ......................................................................................... 52 Desarrollo ............................................................................................ 53

Metodologas pesadas........................................................................... 53 Metodologas giles. .............................................................................. 54

Metodologas de desarrollo de software. Cul es el camino?.................. 52

2.2.1 2.2.2

2.3

Resumen puntos clave ........................................................................ 61

RUP ....................................................................................................... 61 3P .......................................................................................................... 61 XP ......................................................................................................... 61

2.3.1 2.3.2 2.3.3

2.4 2.5 2.6 3 3.1

Conclusiones ....................................................................................... 62 Referencias ......................................................................................... 62 Bibliografa .......................................................................................... 62 Anlisis de Sistemas de Computacin ................................................ 63
Conceptos y Anlisis ............................................................................. 63 Objetivos del Anlisis............................................................................. 64

Anlisis y Diseo de Sistemas ................................................................... 63

3.1.1 3.1.2

3.2

Diseo de sistemas de computacin ................................................... 66

Conceptos y principios ........................................................................... 66 Herramientas para el Diseo de Sistemas ............................................. 68

3.2.1 3.2.2

3.3

Anlisis de Sistemas de Apoyo a Decisiones Semiestructuradas ....... 69

Mtodos Disponibles ............................................................................. 69 Sistemas de apoyo a Decisiones ........................................................... 69 Conceptos del proceso de Toma de decisiones relevantes para los DSS 70 Fases para la solucin de problemas..................................................... 71

3.3.1 3.3.2 3.3.3 3.3.4

3.4 3.5

Conclusiones ....................................................................................... 72 Bibliografa .......................................................................................... 73

1 Metodologas modernas de desarrollo de Sistemas de Informacin

1.1 INTRODUCCION
En esta investigacin se comparan varias Metdologas Modernas para el Desarrollo de Sistemas de Informacin. Estas utilizan el paradigma de Orientacin 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 comparacin lo que se busca es en primer lugar saber cuales son los nombres de tantas metodologas existentes y en segundo lugar, conocer el enfoque de cada una, la manera en que definen los conceptos bsicos de Orientacin a Objetos, cmo 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 metodologas, existen libros disponibles, qu tipo de conocimientos necesitamos tener para poder utilizarlas, en qu lenguajes de programacin 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 dcada de los 40s, se llam la primera generacin, las computadoras estaban construidas por medio de tubos de vaco y eran programadas en lenguaje de mquina. En la dcada 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 automatizacin de numersos sistemas administrativos rutinarios y de trabajo intensivo. Las computadoras son de la segunda generacin; estaban construdas con circuitos de transistores. Eran programadas con tarjetas perforadas, con lenguajes llamados de alto nivel. No contaban con disco duro. Tampoco existan los discos flexibles. Aparecen los procesadores de palabras como Word Star, hojas de clculo como Visicalc. Los sistemas de informacin que sobresalieron son: Cuentas por Cobrar y Nmina. Los Sistemas de Informacin administrativos, empezaron a desarrollarse en la decada de los 60s y se caracterizaron por utilizarlos para producir informes administrativos que en la mayora de los casos eran elaborados de manera peridica. La programacin Orientada a Objetos fue discutida primeramente a finales de los 60s por la comunidad de SIMULA. Surge la tercera generacin de las computadoras. Su fabricacin electrnica estaba basada en circuitos integrados. Se manejaban por medio de lenguajes de control de los sistemas operativos. Aparecen las minicomputadoras. Los sistemas de informacin que

sobresalieron son: Flujo de Efectivo, Presupuestos, Manejo de Personal y de Manufactura. En los 70s aparecen las computadoras de cuarta generacin. Aparecen los microprocesadores, las computadoras se hacen ms pequeas y baratas por lo que se extiende su uso al mercado industrial. Surgen mas aplicaciones, paquetes grficos. A principios de los 70s, fue una importante parte de el lenguanje Smalltalk desarrollado por Xerox PARK. Mientras, el resto del mundo sala adelante con lenguajes como COBOL o FORTRAN y usaban mtodos de descomposicin funcional para manejar los problemas de diseo e implementacin en los SI. Haba pocas si no es que ninguna, discusiones enfocadas en diseo de orientacin a objetos, y virtualmente ninguna sobre anlisis basado en orientacin a objetos. El procesador principal de esta dcada es el 404. Los sistemas de informacin que sobresalieron son de Planeacin y Pronstico. En la dcada de los 80s, los grandes avances tecnolgicos 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 dependan solo del departamento de sistemas de informacin para resolver todas sus necesidades informativas. La gente se dio cuenta entonces de que era posible utilizar los sistemas de computacin 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 generacin. En las que se cuentan los procesadores 8080, 8086, 80286. Los sistemas de informacin que sobresalieron son: Sistemas de Soporte a Decisiones, Pago a Usuarios Finales y Planeacin Estratgica. Surge la Administracin de Recursos de Informacin y los Centros de Informacin 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, aos 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 informacin son: Servicios de Informacin, Estaciones de Trabajo y Administracin de datos centralizados. Cuatro cambios ocurrieron a travs de las dcadas pasadas y ahora son factores claves para los 90s: El concepto en la aproximacin orientada a objetos en el campo de software ha ido madurando durante dos decadas, y la atencin ha ido gradualmente cambiando hacia los asuntos de codificacin y a los asuntos de diseo y analisis. La tecnologa para construir sistemas ha ido haciendose mas poderosa. Ideas acerca de diseo han influido por ideas preconcebidas acerca de como uno podria escribir codigo; e ideas acerca de codificacion son fuertemente influenciadas por el lenguaje de programacin que esta disponible. Era difcil pensar acerca de programacin estructurada

cuando los lenguajes a elegir eran ensambladores y FORTRAN; las cosas se volvieron mas fciles con Pascal, PL-1, y ALGOL. Similarmente, fue difcil pensar en programar en la moda de Orientacin a Objetos cuando el leguaje a elegir era COBOL o el plano C; se hizo mas fcil con C++ y Samlltalk. Los sistemas construidos hoy en da son diferentes de como eran hace diez o veinte aos atras: son largos, muy complejos y muy voltiles. Una aproximacin orientada a objetos para el anlisis y el diseo es probable conducirlo a un sistema mas estable. Tambin ahora sistemas interactivos requieren mas atencin a la interface de usuarios en comparacin al proceso de sistemas de texto desarrollados en los 70s. Una aproximacin orientado a objetos para tales sistemas desde anlisis hasta diseo y codificacin- es un mtodo mas natural para lidiar con tales sistemas orientados a usuarios. Los sistemas construidos hoy en da 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 comprensin del dominio del problema y las responsabilidades del sistema.

En el 2000 la informacin ejercio un profundo impacto en la sociedad, al grado de que hay quienes llaman a esta poca la Era de la Informacin. La sociedad industrial ha dado paso a una nueva sociedad, en donde la mayora de las personas trabajan con informacin 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 Informacin es el Internet, y los Sistemas de Informacin 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 coleccin de objetos que interactan entre s y que contienen tanto estructuras de datos como un comportamiento. Esto se opone a la programacin convencional, en la cual las estructuras de datos y el comportamiento solamente estan relacionadas de forma dbil, ya que estos se enfocan principalmente a las funciones. Objeto. Los objetos son las cosas fsicas y conceptuales que encontramos en el universo alrededor de nosotros. Hadware, software, documentos, seres humanos, los conceptos son todos los ejemplos de los objetos. Caractersticas de los Objetos. Identidad: Los datos estan cuantificados en entidades discretas y distinguibles denominadas objetos. Ejemplo; una televisin, una bicicleta, un rbol. Los objetos pueden ser concretos, como un archivo en un sistema de archivos, o bien conceptuales como la poltica de planificacin 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 tamao) sean idnticos. Clasificacin: Significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se reunen para formar una clase. La seleccin de clases es arbitraria y depende de la aplicacin. Objetos: Bicicleta de montaa, Bicicleta de carreras, Bicicleta de nios Clase Bicicleta: o Atributos: Tamao del cuadro, tamao 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 operacin puede comportarse de modos distintos en distintas clases. La operacin mover por ejemplo, se puede comportar de modo distinto en las clases Ventana y Pieza de ajedrez. Una operacin es una accin o una transformacin que se lleva a cabo o que se aplica a un objeto. Justificar a la derecha, visualizar y mover son ejemplos de operaciones. Una implementacin especfica de una operacin por parte de una cierta clase es lo que se denomina mtodo. Dado que los operadores orientados a objetos son polimrficos es posible que haya ms de un mtodo que lo implemente. En el mundo real una operacin es simplemente, una abstraccin de comportamiento anlogo 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 mtodo correcto para implementar una operacin basandose en el nombre de la operacin y en la clase del objeto que esta siendo afectado. El usuario de una operacin no necesita ser consciente del nmero de mtodos que existen para implementar una cierta operacin polimrfica. Se pueden aadir nuevas clases sin modificar el cdigo existente, siempre y cuando se proporcionen mtodos para todas las operaciones aplicables a las nuevas clases. Herencia: Es compartir atributos y operaciones entre clases tomando como base una relacin jerrquica. En trminos generales se puede definir una clase que despus se ir refinando sucesivamente para producir subclases. Todas las subclases poseen o heredan, todas y cada una de las popiedades de su superclase y aaden, adems, 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 regin visible de la pantalla. La ventanadedesplazamiento aade una barra de desplazamiento y un ascensor. La capacidad de sacar factor comn a las propiedades de varias clases en una superclase comn y de heredar las

propiedades de la superclase puede reducir muchsimo la reptecin en el diseo 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 mtodos empleados para el diseo de sistemas automatizados. Una metodologa completa es algo ms que una notacin, un proceso, y herramientas. Adems estas "metodologas completas" proporcionan: Guas para estimar costos, Manejo del proyecto en las tareas y entregas, Medidas y mtricas, Formas definidas y direccin en las entregas de la construccin, Polticas y procedimientos para garantizar la calidad del software, Descripciones de los roles y programas de entrenamiento detallados, Ejemplos totalmente trabajados, Ejercicios de entrenamiento, Tcnicas para adaptar el mtodo, y Tcnicas definidas

1.5 EL ENFOQUE
Este capitulo consiste en una comparacin de modernas metodologas 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 metodologas que se van a comprar cumplen completamente con las caractersticas mencionadas anteriormente, ya que falta mucho trabajo por hacer para que sean unas metodologas completas. La comparacin se hace con ese conocimiento y entonces metodologa se considera tambien como un mtodo. Las metodologas a comparar, ordenadas alfabticamente 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 comparacin se consideran cuatro reas especficamente: Conceptos o Esta seccin cita de la ayuda particular del mtodo y de los contrastes para los trminos dentro de cada mtodo. Los trminos tales como objeto, clase, metaclases, y operacin se comparan. Notaciones o Muchos mtodos requieren crear descripciones abstractas, o modelos grficos, del sistema en el anlisis y/o diseo. Se construyen estos modelos usando una cierta forma de notacin. La semntica de la notacin 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 ms manejables". Procesos o Cuanto del ciclo de vida del desarrollo de los sistemas es cubierto por el mtodo, y qu adaptacin o heurstica est disponible para el proceso del mtodo. Es evaluada la cobertura al ciclo de vida. Comprobar que elementos del desarrollo del software se manejan dentro del mtodo. Cada metodologa 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 Anlisis es esa parte de ciclo de vida que describe las caractersticas exterior observables del sistema, ejem, funcionalidad, funcionamiento, capacidad. Esta descripcin incluye normalmente los modelos que representan la construccin lgica de los sistemas, y su colocacin dentro de un ambiente de sistema. El Diseo es la parte del ciclo de vida que prepara definiciones en cuanto a cmo el sistema lograr sus requerimientos. Los modelos preparados en anlisis se refinan, o se transforman, en los modelos del diseo que representan la naturaleza fsica del producto de software. La implementacin es la parte del ciclo de vida que convierte los modelos desarrollados del diseo en el software ejecutable dentro del ambiente del sistema. Este implica la codificacin de las unidades del programa, de la generacin automatizada del cdigo, o del montaje de los componentes reutilizables ya construidos y probados del cdigo 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 anlisis direcciona la busqueda y aplicacin del dominio y la identificacin, documentacin, construccin y prueba y demostracin 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 metodologa.

o Se evalan despus las caractersticas o las cualidades del proceso del mtodo. Las caractersticas de un proceso sirven para medir la capacidad de repeticin del mtodo y flexibilidad. Las caractersticas define la secuencia de pasos, de entradas requeridas y de salidas, papeles implicados, as como la interaccin con otros pasos. Los pasos opcionales deben ser identificados claramente. La heurstica y los mecanismos disponibles para la traceabilidad, la verificacin, y la validacin del proceso son tambin cualidades deseables de un proceso bien definido. Pragmtica La pragmtica de una metodologa consiste en: o Recursos: Qu recursos disponibles hay dentro de la ayuda del mtodo? Existen un libros disponibles? Establecen a los grupos de usuarios? El entrenamiento y la consulta es ofrecida por el vendedor y/o los terceros? Adems, estn las herramientas automatizadas (herramientas CASE) disponibles en la ayuda del mtodo? o Conocimientos Requeridos: Cul es el background requerido de los que aprenden el mtodo? Una caracterstica que distingue de muchos mtodos es el nivel de la sofisticacin matemtica requerido para explotar completamente el mtodo. El mtodo asume conocimiento en una cierta disciplina? o Utilizacin del lenguaje: El mtodo gua a un lenguaje en particular? Algunos mtodos son especficos a COBOL o al Ada, mientras que otros mtodos tienen aplicabilidad ms general.

1.6 RESULTADO ESPERADO

La expectativa de cualquier comparacin de la metodologa es que proporcionar una base para desechar las metodologas que no parecen dar valor dependiendo de la situacin. Esta comparacin maneja esta expectativa. Planteando preguntas de las metodologas presentadas y usando los resultados documentados para contestar a las necesidades particulares. Estas preguntas sirven como punto que partida para una investigacin 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 crtico para el xito de nuestra compaa. Qu mtodos son apropiados para m?" "Mi proyecto requiere el uso del lenguaje C++. Qu mtodos son apropiados considerando que el lenguaje de programacin se ha seleccionado ya para mi proyecto?"

1.7 CONCEPTOS
En esta seccin se cita a cada metodologa para comprarar la opinin de cada autor de un nmero de conceptos orientados al objeto. 1.7.1 DEFINICIN DEL "OBJETO" EN CADA METODOLOGIA 1.7.1.1 Berard 1992. Un objeto que se utiliza para crear las instancias, es decir, una plantilla, descripcin, patrn, o "modelo" es una categora o coleccin de artculos muy similares. Entre otras cosas, una clase describe la interfaz que los estos artculos presentarn al mundo exterior, los mtodos, las constantes, y las excepciones es decir, disponibles y apropiados. Una clase representa una abstraccin de los artculos. Una clase es realmente una familia de clases muy de cerca relacionadas. La clase es un concepto recurrente. Especficamente, podemos definir clases como un compuesto de otras clases (es decir, las clases compuestas heterogneas y clases compuestas homogneas), en trminos de s mismo (una clase recurrentemente definida), como herencia de caractersticas de unas o ms otras clases (es decir, los superclasses de la clase), y como abastecimiento de caractersticas 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 trmino "tipo" se da la definicin 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 comn. Los trminos instancia y objeto son intercambiables. 1.7.1.3 Coad y Yourdon 1990. Una abstraccin de algo en un dominio del problema, reflejando las capacidades de un sistema a mantener la informacin de este, interacta recprocamente con esta informacin, o ambas (interactuar y mantener); una encapsulacin de los valores atributos y sus usos exclusivos (sinnimo: una instancia) 1.7.1.4 Embley y Kurtz 1990. Un objeto es una persona, un lugar, o una cosa. Un objeto puede ser fsico o conceptual... La idea es que un objeto es una sola entidad o nocin. 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 abstraccin, o cosa con lmites para el problema actual. Los objetos responden a dos propsitos: Promueven la comprensin del mundo verdadero y proporcionan una base prctica para la puesta en prctica de la computadora. La descomposicin de un problema en objetos depende del juicio y de la naturaleza del problema. No hay una representacin correcta. 1.7.1.7 Shlaer y Mellor 1992. Un objeto es una abstraccin de un sistema de cosas del mundo real, tales como: todas las cosas en el sistema las instancias - tenga las mismas caractersticas, y todas las instancias estn conforme y se conforman con el mismo sistema de reglas y polticas...

Un objeto en OOA representa un solo caso tpico pero sin especificar algo en el mundo verdadero - cualquier avin, no importa cual, mientras sea representativo. El analista orientado al objeto distingue este concepto de un caso especfico: Avin nmero 8945, una fuerza area, o un avin 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 declaracin, que cierto conocimiento y ciertas operaciones estn relacionados conceptualmente con otro, de modo que tenga sentido el unirlos. 1.7.1.9 ANALISIS En las definciones del trmino "Objeto", se concluye lo siguiente: Indica que ciertos mtodos integran la mencin de abstraccin a sus definiciones del objeto, y otros consideran unicidad e identidad como crtica (solamente Rumbaugh menciona ambos). Adems, la mencin el comportamiento y estado se percibe limitada a esos mtodos el centrarse en unicidad. Metodologa Mencin de Unicidad o ComportamienEstado abstraccin identidad to o acciones

Berard Booch Coad y Yourdon Embley Martin y Odell Rumbaugh Shlaer y Mellor Wirfs-Brock X X X X

X X

X X X X

1.7.2 DEFINICIN DE "CLASE" EN CADA METODOLOGIA 1.7.2.1 Berard 1992. Un objeto el cual es utilizado para crear instancias, es decir, una plantilla, descripcin, patrn, o "modelo" de una categora o de una coleccin de artculos muy similares. Entre otras cosas, una clase describe la interfaz que los artculos presentarn al mundo exterior, ejem. los mtodos apropiados y disponibles, las constantes, y las excepciones. Una clase representa una abstraccin de los artculos. Una clase puede a si misma darse parmetros (ejem, representa realmente una familia de clases muy estrechamente relacionadas), a esto le llamamos dar parametos a la clase. Clase es un concepto recursivo. Especficamente, podemos definir clases como un compuesto de otras clases (es decir, clases compuestas heterogneamente y clases compuestas homogneamente), en trminos de s mismo (una clase definida recursivamente), como caractersticas de herencia de una o ms clases (es decir, los superclasses de la clase), y como abastecimiento de caractersticas 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 trmino "tipo" se da la definicin para clase. 1.7.2.2 Booch 1991. Un conjunto de objetos que comparten una estructura comn y un comportamiento comn. Los trminos clase y tipo son generalmente (pero no siempre) intercambiables; y una clase es un concepto levemente distinto a tipo, en el hecho que acenta la importancia de jerarquas de clases. 1.7.2.3 Coad y Yourdon 1990. Una descripcin de uno o ms objetos con un conjunto uniforme de cualidades y de servicios, incluyendo una descripcin de cmo crear nuevos objetos en la clase. Clase-Objeto. Un significado del trmino "una clase y los objetos en esa clase."

1.7.2.4 Embley y Kurtz 1990.

Identificacin de conjunto de objetos que pertenecen juntos por una cierta razn lgica llamada clasificacin. En OSA, un sistema de objetos que pertenecen juntos por una cierta razn lgica 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 genrico y denota a cualquier miembro de la clase del objeto. As, en un ORM, una clase del objeto con nombre X seala una clasificacin 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 implementacin de un concepto o de un tipo de objeto. En lenguajes de programacin OO, los tipos de datos abstractos se llaman clases. En matemticas, el significado de la clase es similar al de sistema. El significado de la definicin de OOPL de la clase se present de la definicin matemtica. 1.7.2.6 Rumbaugh 1991. Una clase del objeto describe un grupo de objetos con las caractersticas similares (cualidades), el comportamiento comn (operaciones), relaciones comunes a otros objetos, y la semntica comn. La persona, la compaa, el animal, el proceso, y la ventana son todas las clases del objeto. 1.7.2.7 Shlaer y Mellor 1992. No provee una definicin 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 especificacin genrica para un nmero arbitrario de objetos similares. Se puede pensar en una clase como plantilla para una clase especfica de objeto. 1.7.2.9 ANALISIS Mientras que el mtodo de Shlaer y de Mellor utiliza diagramas de la clase y hace la mencin significativa del trmino "clase" en su aproximacin, no proveen ninguna definicin explcita 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 mtodos difieren de los otros mtodos en su enfoque en relaciones como fundamental para el uso del trmino "clase."
Metodologa Mencin de Mencin de Mencin de abstraccin Estructura Comportamiento Estado Relaciones

Berard Booch Coad y Yourdon Embley

X X X

X X X X

Martin y Odell Rumbaugh Shlaer y Mellor Wirfs-Brock

X X

X X X X

1.7.3 DEFINICIN DE "OPERACION" EN CADA METODOLOGIA 1.7.3.1 Berard 1992. Una accin que es afectada por, o requerida por un objeto. Las operaciones pueden ser selectoras, constructivas, o iterativas. Una operacin es contenida en la interfaz del objeto y tiene sus detalles descritos en un mtodo correspondiente. Las operaciones pueden ser compuestas, es decir, integrada por otras operaciones. Sin embargo no es alentada, la encapsulacin de operaciones compuestas dentro de la interfaz a un objeto. 1.7.3.2 Booch 1991. Una cierta accin que un objeto realiza sobre otro para sacar una reaccin. Todas las operaciones sobre un objeto especfico se pueden encontrar en subprogramas libres y funciones o mtodos. Los trminos mensaje, mtodo, y operacin son generalmente intercambiables. 1.7.3.3 Coad y Yourdon 1990. Un servicio es un comportamiento especfico que un objeto es responsable de exhibir. 1.7.3.4 Embley y Kurtz 1990. Adems de estados y de transiciones entre estados, tambin deseamos modelar las acciones que un objeto realiza. Una accin puede causar acontecimientos, crear o destruir objetos y relaciones, observar objetos y relaciones, y enviar o recibir mensajes. Ponemos acciones en dos categoras 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 ejecucin despues. En OSA, pensamos en las acciones asociadas a transiciones como nointerrumptible, 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 podran ms correctamente llamar las

operaciones-cambia-estados).. Sin embargo cada operacin estado-cambia puede estar como transaccin. Una transaccin es un proceso o una serie de procesos que actan como unidad para cambiar el estado de un objeto. Los casos de operaciones se llaman operaciones invocadas. La especificacin de cmo una operacin debe ser realizada se llama mtodo. 1.7.3.6 Rumbaugh 1991. Una operacin es una funcin o una transformacin a la cual puede ser aplicada para o por los objetos en una clase. Contratar, despedir, y pagar utilidades son operaciones en la clase Compaa. 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 operacin publicada que corresponde a cada acontecimiento generado por el objeto bajo consideracin. 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 operacin 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 operacin de la clase y lo nombra: Toma y Crea

1.7.3.8 Wrifs-Brock 1990. Cuando un objeto recibe un mensaje, realiza la operacin solicitada ejecutando un mtodo. 1.7.3.9 ANALISIS En el repaso de cada definicin de la "Operacin", solamente Booch indica que el mtodo y la operacin son equivalentes. Algunos mtodos visualizan los mtodos de un objeto de una perspectiva externa, mientras que otros se centran en los mtodos de un objeto de una perspectiva interna. El mtodo solamente de Martin y de Odell no hace caso de la aplicacin mtodos externos o internos.
Metodologa Operacin Externo Interno = Mtodo Estado

Berard Booch Coad y Yourdon X

X X

Embley Martin y Odell Rumbaugh Shlaer y Mellor Wirfs-Brock

X X X X X X X X

1.7.4 DEFINICIN 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 mencin explcita de metaclase. 1.7.4.4 Embley y Kurtz 1990. No se hace ninguna mencin explcita de metaclase. 1.7.4.5 Martin y Odell 1992. No se hace ninguna mencin explcita de metaclase. 1.7.4.6 Rumbaugh 1991. Las clases se pueden tambin considerar como objetos, pero son meta-objetos y objetos no del mundo real. El objeto del descriptor de la clase tiene caractersticas, y alternadamente tienen sus propias clases, que se llaman metaclases. Tratar todo como objeto proporciona una puesta en prctica ms 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 mencin explcita de metaclase. 1.7.4.8 Wrifs-Brock 1990. No se hace ninguna mencin explcita 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 anlisis orientado a objetos intenta identificar los artculos reutilizables localizados alrededor de los objetos, ejem clases, de instancias, sistemas de objetos interactuando, y kits. Kit: una coleccin de objetos (ejem, clases, metaclasses, instancias de noclase, otros kits, y los sistemas de objetos interactuando) que apoyan a un solo concepto, grande, coherente, orientado al objeto, ejem, ventanas, interruptores, y plizas de seguro. Puede de hecho haber una cierta conexin fsica entre algunos miembros de un kit dado. Sin embargo, los kits son "granulares," es

decir, mientras que todos los componentes de un kit son lgicamente relacionados, all son muy pocas conexiones fsicas las que los unen. Sistema de objetos interactuando: una coleccin 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 conexin fsica directa o indirecta entre cualquier dos objetos arbitrarios dentro de la coleccin. Adems, 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 organizacin de clases en pedazos significativos, que nos conduce a la idea de una categora de clase. ... el dominio del anlisis 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 coleccin de mdulos, 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 travs de un modelo grande, complejo. Los temas son tambin provechosos para los paquetes del trabajo de la organizacin en proyectos ms 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 mencin explcita 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: coleccin organizada de componentes que interactan. Particin: un subsistema que povee un tipo de servicio; una particin puede por si misma construir subsistemas de nivel mas bajo. Capas: un subsistema que provee mltiples servicios, todos los cuales estan en el mismo nivel de abstraccin, construye en sistemas de nivel bajo de abstraccin. 1.7.6.7 Shlaer y Mellor 1992. Mientras que un dominio pequeo (consistiendo en cincuenta o pocos objetos) se puede analizar generalmente como unidad, los dominios grandes se deben

particionar para hacer que el anlisis sea una tarea manejable. Para hacer tal particionamiento, nos aprovechamos del hecho de que los objetos en un modelo de informacin 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 informacin de modo que permanezcan los racimos intactos... Cada seccin del modelo de informacin entonces se convierte en un subsistema separado. Observe que cuando el modelo de informacin 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 componan una aplicacin. Pero dependiendo de la complejidad de su diseo, los varios niveles de la encapsulacin 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 simulacin completamente desarrollada, un sistema del procesamiento de textos, una hoja de clculo, una calculadora, o un sistema del pago de la nmina 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 anlisis orientado a objetos. Shlaer y Mellor sugieren que los objetos se puedan localizar usando las fuentes siguientes: Cosas tangibles (avin, una pipa, una computadora) Roles realizados por personas u organizaciones (doctor, paciente, corredor) Incidentes (vuelo, accidente, funcionamiento) Interacciones (compra, boda, una red elctrica) Especificaciones (tipos de plizas 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 organizacin

Estas dos aproximaciones, aunque son tiles, son limitados. Booch, Berard, y Wirfs-Brock parecen ser los ms 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 carctersticas de los datos (las cualidades y las variables de la isntancia). Despus 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 artculos de objetos. Martin y Odell son los menos orientados a objetos, aparentemente presentando extensiones leves a la ingeniera de informacin con una orientacin del comportamiento muy pesada.

1.8 NOTACIONES
1.8.1 COMPONENTES DE LA NOTACIN DE LAS MTODOLOGIAS Cada metodologa es caracterizada por un sistema especfico de modelos (componentes de la notacin) 1.8.1.1 Berard 1992. 1. Diagrama Objeto-Mensaje 2. Diagrama Semntica de Red 3. Diagrrama Transicin de Estados 4. Grfica Petri-net 5. Diagrama de Tiempos 6. Kit 7. Sistema de Interaccin de Objetos 8. Grfica 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 Mdulos 6. Diagrama de Procesos 1.8.1.3 Coad y Yourdon 1990. 1. El smbolo de clase de OOA, representando una clase, sus cualidades, y sus servicios. 2. El smbolo de OOA Clase-y-Objeto

3. Notacin de la estructura Generalizacin-Especializacin 4. Notacin de la estructura Entero-Parte 5. Notacin del temas 6. Notacin de atributos 7. Notacin de la conexin de la instancia (Instance Connection notation) 8. Notacin de servicio 9. Notacin Diagrama Objeto Estado 10. Notacin de Grafica de Servicio 1.8.1.4 Embley y Kurtz 1990. 1. Modelo Objeto-Relacin (ORM) 2. Alto-Nivel ORM 3. Estado Red 4. Alto Nivel del Estado Red 5. Diagrama de Interaccin 6. Alto-Nivel del Diagrama de Interaccin 1.8.1.5 Martin y Odell 1992. 1. Diagrama de Estructura de Datos 2. Diagrama de la Jerarqua Objeto-Generalizacin 3. Diagrama Objeto-Relacin 4. Diagrama de composicin de Objetos 5. Diagramas de accin 6. Grficas de Estructura (no muestra ejemplos) 7. Tablas declarativas. (no muestra ejemplos) 8. Diagramas Estado-Cambio o Diagramas Transicin Estado 9. Diagramas de Evento o Esquema de Eventos 10. Diagramas de Flujo de Objetos 11. Herramientas para el diseo grfico 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 dinmicos los cuales consisten en: Ecenarios, Traceabilidad de eventos, Diagramas de estado, Jerarquia de eventos, Diagramas concurrentes de estado, Diagramas extendidos de estado por sincronizacin 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 Informacin 2. Diagrama de repaso de la Estructura de Informacin 3. Grafica de Dominio 4. Matriz del Proyecto 5. Modelo de Relacin del Subsistema 6. Modelo de Comunicacin del Subsistema 7. Modelo de Acceso al Subsistema 8. Modelo de Informacin 9. Descripcin de Objetos y Atributos 10. Descripcin de Relaciones 11. Modelo de Comunicacin 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 Accin de Datos 17. Descripcion de Procesos 18. Diagrama de Herencias 19. Diagrama de Dependencias 20. Diagrama de Clases 21. Grfica 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 Delegacin de Subsistema 5. Jerarquas 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 ESTTICOS QUE LA NOTACIN ES CAPAZ DE EXPRESAR Se consideraron los siguientes conceptos: Agregacin: De qu objetos componentes se construye un objeto compuesto?

Metodologa

Agregacin Especializacin Comunicacin

Mdulo de Interfaz

Calificaciones para la reutilizacin

Berard

Red de Semantica

Red de Semantica

Grafica de la Diagrama Red de unidad del Objeto Mensaje Semantica Programa Diagrama de Clases Modulo Diagrama de Objetos

Booch

Diagrama de Diagrama de Clases Clases

Estrcutura Coad y Yourdon Entero-Parte GeneralizacionEspecializacion Modelo Relacion Objeto Modelo Relacion Objeto

Mensaje

Embley

Modelo Relacion Objeto

Martin y Odell

Diagrama de Diagrama de la composicion Jerarqia Objeto de objetos Generalizacion Modelo del

Diagramas de flujo del objeto

Rumbaugh

Modelo del Objeto Escenario

Objeto Modelo Comunicacion de Objetos Colaboradores Diagrama de clases

Shlaer y Mellor

Herencia

Wirfs-Brock

Tarjeta de Clases

Jerarquias

Especializacin: Cmo es un objeto representado siendo una generalizacin, o la especializacin de otro objeto? Comunicacin: Cmo los objetos mostrados se comunican unos con otros? (enviandose mensajes) Mdulo de Interfaz: Cmo son las implementaciones fsicas de los objetos representados? Calificaciones para la reutilizacin: Cmo un caso especfico de un objeto se representa para ser utilizado por otra clase?

1.8.4 CONCEPTOS DINMICOS QUE LA NOTACIN ES CAPAZ DE EXPRESAR La representacin de los cambios de estado, la sincronizacin, y en cierta forma las interacciones del objeto son elementos esenciales para modelar el comportamiento de los sistemas. Metodologia Berard Booch Cambios de Estado Diagrama Transicion Estado / Grafica Petri Net Diagrama Transicion Estado Tiempos Diagrama de Tiempos Diagrama de Tiempos

Coad y Yourdon Diagrama Estado Embley Martin y Odell Rumbaugh Shlaer y Mellor Wirfs-Brock 1.8.5 REGLAS EXPLCITAS NOTACIONES PARA DEFINIR LOS SMBOLOS DE LAS Red de Estado Cambios de Estado Diagrama de Estado Modelo de Estado Estado Extendido Red de Estado

Cada mtodo fue repasado para determinar si los smbolos del mtodo fueron definidos explcitamente, y si as es, donde se definieron; y si existen ejemplos. Berard La notacin no es formalmente definida. Se proporcionan numerosos ejemplos

Booch Coad y Yourdon Embley Martin y Odell

La notacin se documenta en parte de su libro. Se proporcionan numerosos ejemplos Proporciona las reglas especficas para la simbologa de la notacin el apndice A, del anlisis orientado a objetos y proporciona numerosos ejemplos. La notacin es formalmente definida en el Apendice A, y proporciona numerosos ejemplos Se define la notacion en uno de sus capitulos y tambien Diagramas Estandares son recomendados

Rumbaug La notacin si se define en su libro. h Shlaer y Mellor WirfsBrock La notacion es formalmente definida a traves de sus libro. La notacin no se define formalmente, pero se presentan numerosos ejemplos

Adems, de la definicin de la semntica de las notaciones, se buscaron tambin ejemplos y heurstica para la construccin de modelos. Metodologia Berard Booch Coad y Yourdon Embley Martin y Odell Rumbaugh Shlaer y Mellor Wirfs-Brock X X X X X X X X X X X X X X Sintaxis Semntica Definida Definida Provisin de Ejemplos X X X X X X X X X X X Heursticas Presentadas X X X X

En general, cada notacin (excepto Berard) provee una definicin explcita de la semntica de su notacin, ejemplos y heurstica. En muchos casos los

ejemplos son bastante completos, estos son, de los modelos requeridos para un problema especfico, o de una variedad de problemas. 1.8.6 MECANISMO DE PARTICION DENTRO DE LA NOTACION Mientras que el tamao de un sistema aumenta, se requiere un cierto mecanismo para limitar la visibilidad de la informacin solamente a esos objetos de inters en un momento particular. Estos son los mecanismos que proporciona cada metodologa: Metodologa Berard Booch Coad y Yourdon Embley Martin y Odell Rumbaugh Shlaer y Mellor Wirfs-Brock Mecanismo de Particin Kits, sistemas de Interaccion de Objetos Subsistemas, Procesadores Temas Vistas de Alto Nivel * Subsistemas Subsistemas Subsistemas y Frameworks

* Martin y Odell mencionan "reinos" y "especificaciones del reino" en su glosario, pero no proporcionan ninguna referencia de cmo sta se relaciona con la particin del sistema.

1.9 PROCESOS
1.9.1 PASOS DEL PROCESO DE DESARROLLO DE CADA METODOLOGA 1.9.1.1 Berard 1992. Analisis Orientada a Objetos 1. Identificacion de fuentes y requerimientos de informacion 2. Caracterizaer las fuentes y requerimientos deinformacin 3. Identificar objetos candidatos 4. Construir los modelos orientados a objetos de ambos problemas, y de la solucion potencial 5. Re-localizar la informacion candidates de objectos alrededor de los apropiados

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 Diseo 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. Descomposicin a operaciones primitivas 10. Desemparejamiento de objetos 11. Seleccionar, crear, y verificar objetos para diseo 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 diseo 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 Diseo de Orientacion a Objetos 1. Identificacin de Clases y Objetos 2. Identificar las Semanticas de Clases y Objetos 3. Identificar las relaciones entre Clases y Objetos 4. Implementacin de Clases y Objetos 1.9.1.3 Coad y Yourdon 1990. Analisis orientado a Objetos

1.9.1.2 Booch 1991.

1. Identificar Objetos 2. Identificar Estructuras 3. Especializacin-Generalizacin de Estructuras 4. Estructuras de Entero-Parte 5. Estructuras Mltiples Definicin de Temas Definicin de Estructuras 1. Identificacin de los Atributos 2. Posicionar los Atributos 3. Identificacin de las instancias de Coneccin 4. Checar los Casos Especiales 5. Especificar los Atributos Definicin de Servicios 1. Identificacin del Estado del Objeto 2. Identificacin de los Servicios Requeridos 3. Identificacin de los Mensajes de Coneccin 4. Especificar los Servicios 5. Poner el conjunto de documentos OOA juntos Diseo de Orientacin a Objetos 1. Disear el componente del dominio del problema Diseo de la reutilizacin y Clases de Programacin Agrupacionde Clases Problema-Dominio-Especificacin Establezcer un protocolo agregando una clase de la generalizacin Acomodar el nivel apoyado de la herencia Mejora del Funcionamiento Apoyo del Componente de la Administracin de Datos Agregar los Componentes de Nivel Inferior Revisar y desafar las adiciones a los resultados de OOA Clasificacin de Humanos Descripcin de los Humanos y los escenarios de las Tareas Diseo de la Jerarqua del Comando Diseo de la Interaccin Detallada

2. Disear el Componente Humano de la Interaccin

Continuacin del Prototipo Diseo de las Clases de los Compnentes de la Interaccin Humanas Diseo, Contabilidad para el GUI ( cuando es applicable ) Cuando las tareas sean requeridas Identificar las Tareas Manejo-Evento Identificar las Tareas Reloj-Conducidas Identificar las tareas de Prioridad y las Tareas Crticas Identificar un Coordinador Desafiar cada Tarea Definir cada Tarea Aproximacin selecta de la administracin de datos Determinar las herramientas del manejo de datos Disear el componente del Administrador de Datos

3. Diseo del componente del Manejo de tareas

4. Diseo del Componente del Manejo de Datos

1.9.1.4 Embley y Kurtz 1990. Analisis de los Sistemas Orientado a Objetos 1. Construccin de Modelos Objeto-Relacin 2. Costruccion de Modelos Objeto-Comportamiento 3. Construccin de Modelos Objeto Interaccin 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 Operacin 5. Identificar las Causas de Operacin 6. Refinar los Resultados del Ciclo 1.9.1.6 Rumbaugh 1991. Analisis Escribir u obtener una descripcin inicial del problema (declaracin del problema) Construir in modelo del Objeto

1. Identificar Clases de los Objetos 2. Comenzar un diccionario de datos que contenga descripcin 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 mdulos, basados en el acoplador cercano y funcin relacionada. Desarrollar un Modelo Dinmico 1. Prepar los escenarios de las secuencias tpicas de la interaccin. 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 dinmico 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 funcin 4. Identificacin de los contrastes 5. Especificar los criterios de la optimizacin. 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 ms detallados para explorar y para verificar los tres modelos 4. Iterar los pasos antes mencionados tanto como sean necesarios para acompletar el analisis Diseo 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 trminos 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 aproximacin para implementar el control del software 7. Utilice la localizacin dentro del programa para llevar a cabo el estado, o 8. Directamente implemente un estado de mquina, o 9. Utilice las tareas concurrentes 10. Considerar las condiciones de Lmite 11. Establecer las prioridades de compensacin Diseo del Objeto 1. Obtener las operaciones para el modelo del objeto de los otros modelos: 2. Encontrar una operacin para cada proceso en el modelo funcional 3. Definir una operacin para cada evento en el modelo dinmico, dependiendo del control de la implementacin Diseo de algoritmos para implementar las operaciones: 1. Elegir algoritmos que minimicen el costo de implementacin de la operacin 2. Seleccionar las estructuras de datos apropiadas para los algoritmos. 3. Definir nuevas clases internas y operaciones 4. Asignar responsabilidades para las operaciones 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 computacin 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. que son

Disear la implementacin de asociaciones: 1. Analizar el traversal de asociaciones 2. Implementar cada asociacin como a distintos objetos o por adicion del atributo valor-objeto a una o ambas clases en la asociacin.

Determinar la exacta representacin de los atributos de los objetos. Empaquetar clases y asociaciones en modulos. Para los renglones de modelos de informacin 1. Busqueda 2. Desarrollo y Refinacin de los Modelos 3. Integrar con Otros Modelos 4. Revisar

1.9.1.7 Shlaer y Mellor 1992.

Para los renglones de Modelo de Estado 1. Construir el Modelo Estado 2. Verificar las interacciones entre los modelos estados y los modelos de comunicacin de objetos 3. Construir o subsistemas modificar, los modelos de comunicacin de

4. Revisar que esten correctos y su consistencia Para el rengln de los Modelos de Proceso 1. Construccin 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 diseo. 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 guas: 1. Modelo de objetos fsicos

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 abstraccin de superclases agrupamiento de clases que comparten atributos comunes. Uso de categorias para buscar clases que puedan ser olvidadas. Escribir una declaracin cortadel propsito de las clases. Encontrar las responsabilidades utilizando las siguientes guas: 1. Recuerde el propsito de cada clase, segn lo implicado por su nombre y especificado en la declaracin del propsito 2. Extraiga responsabilidades acciones e informacin de la especificacin buscando por

3. Identifique responsabilidades implicadas por las relaciones entre clases. Asignar responsibilidades a las clases utilizando las siguientes guas: 1. Distribuir uniformemente la inteligencia del sistema 2. Definir responsabilidades lo mas posible 3. Matnener el comportamiento con la informacion relacionada 4. Mantener la informacin de cada cosa en un lugar 5. Compartir responsibilidades a travs 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 compartidas entre las clases. representando las responsabilidades

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 diseo. Simplifique los colaboradores entre los subsistemas Construir los protocolos para cada clase. Refinar las responsibilidades entre los sets y firmas que maximizan la utilizacin de las clases. Escribir y disear las especificaciones para cada clase. Escribir y disear las especificaciones para cada subsistema. Escribir y disear 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 nmero y los tipos de entregas que el proceso genera. La documentacin del ciclo de vida incluye generalmente especificaciones de requerimientos, especificaciones de diseo, especificacin del sistema y subsistemas, as como casos de prueba. Las entregas para cada mtodo se evalan usando los criterios siguientes:

 0 indica que no se hace ninguna mencin. 1 indica que la mencin est hecha, pero no se proporciona ninguno detalle 2 indica que la mencin est hecha y se proporciona una definicin 3 indica que la mencin est hecha, una definicin, y por lo menos se presenta un ejemplo 4 indica que la mencin est hecha, una definicin, y por lo menos se presenta un ejemplo, y se define un proceso 5 indica que la mencin est hecha, una definicin, por lo menos se presenta un ejemplo, se define un proceso, y se proporciona la heurstica. Metodologa Berard Booch Coad y Yourdon Embley Martin y Odell Rumbaugh Shlaer y Mellor Wirfs-Brock RequeriObjetos Diseo Pruebas mientos Clases 2 1 2 5 0 2 5 1 5 2 2 1 0 2 5 5 5 0 0 0 0 0 0 0 5 1 5 1 0 5 5 5 Subsistemas 2 1 0 1 0 0 4 5 Total 19 5 9 8 0 9 19 16

La carencia de especificaciones claras, bien-construidas es una debilidad significativa en muchos de los mtodos. Sin tales especificaciones, no puede haber reutilizacin a excepcin del cdigo desarrollado (ningn esfuerzo del anlisis o del diseo puede ser reutilizado, puesto que no esta documentado). Adems, la prueba se afecta seriamente puesto que las pruebas no se pueden hacer sin tales especificaciones. Algunos mtodos consideran las especificaciones como solamente necesarias cuando la programacin es grande." Rumbaugh, por ejemplo, comenta que la documentacin de clases y mtodos es importante al escribir grandes y complejos programas, que implican equipos de programadores; asumiendo que aparentemente es menos importante para los programas pequeos. 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 metodologa. Una metodologa que cubre todos los aspectos del ciclo de vida

del desarrollo del sistema ofrece una solucin atractiva a la organizacin ya que la metodologa por s misma asegura algo completo y consistente. Si una organizacin, por ejemplo, requiere o decide "mezclar y emparejar" una aproximacin del anlisis de una metodologa con la aproximacin del diseo de otra, la organizacin debe enfrentar la responsabilidad de la consistencia y de la completa transicin a partir de una fase del ciclo de vida a otra. Tales estrategias de "mezcla y emparejamiento" introducen un elemento del riesgo en la aproximacin. 0 indica que no se hace ninguna mencin. 1 indica que la mencin est hecha, pero no se proporciona ningun detalle. 2 indica que la mencin est hecha y una definicin est provista. 3 indica que la mencin est hecha, una definicin, y por lo menos se presenta un ejemplo 4 indica que la mencin est hecha, una definicin, y por lo menos se presenta un ejemplo, y se define un proceso. 5 indica que la mencin est hecha, una definicin, por lo menos se presenta un ejemplo, se define un proceso, y se provee la heurstica. Dominio Requerimientos ImplemenMetodologa de Diseo Pruebas Total en el Anlisis tacin Anlisis Berard Booch Coad y Yourdon Embley Martin y Odell Rumbaugh Shlaer y Mellor Wirfs-Brock 4 4 1 0 0 0 0 0 4 2 5 5 3 5 5 3 5 5 5 1 5 5 5 5 5 4 3 0 0 3 1 4 5 0 3 0 0 2 0 3 23 15 17 6 8 15 11 15

1.9.5 DEFINICION DE LOS PASOS DEL PROCESO Cada metodologa debe describir un proceso que, si es seguido, debe brindar un sistema apropiado de productos (ejem, productos del anlisis, productos del diseo, cdigo, y casos de la prueba). La claridad de un proceso simplifica la

ejecucin y la introduccin del proceso en una organizacin de desarrollo. Un proceso bien definido tiene las siguientes cualidades: Cada paso esta bien definido, con instrucciones claras, tips y tcnicas 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 ejecucin de cada paso. Se proporciona software de aseguramiento de la calidad e instrucciones a seguir. Metodologa Berard Booch Coad and Yourdon Embley and Kurtz Martin and Odell Rumbaugh Shlaer and Mellor Wirfs-Brock Definicin EntraSalidas Rol QA Total de Pasos das X X X X X X X X X X X X X X X X X X X X X X X X X X 5 4 4 2 2 4 2 3

1.9.6 HEURSTICA DISPONIBLE PARA LOS PASOS DE PROCESO La heurstica proporciona tips para asistir al analista y al diseador en la ejecucin de los pasos del proceso. En algunos casos esta heurstica es simple y obvia, mientras que en otros son menos obvias. La disponibilidad de un sistema grande de heurstica simplifica la ejecucin del proceso. Estos puntos sirven como un indicador al grado de ayuda que el mtodo proporciona para la heurstica. Un "1" indica pocos si no es que ninguna heurstica, mientras que "3" indica cinco o ms heurstica. Identificacin Metodologa de Clases IdentifiIdentificacin Colocacin Identificacin de de de cacin de Total SubsisteOperaciones Operaciones Estados mas

Berard Booch Coad and Yourdon Embley and Kurtz Martin and Odell Rumbaugh Shlaer and Mellor Wirfs-Brock

1 3 3 3 3 3 3 3

1 3 3 3 3 3 1 1

1 3 0 1 1 1 1 1

3 3 0 1 2 3 3

1 3 1 3 3 3 3 -

7 15 7 11 10 12 11 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 informacin que permite la verificacin de otros modelos. O una especificacin del objeto y de la clase puede ser comprobable contra los modelos usados en su construccin. Sin tales reglas, no son posibles, la verificacin de las especificaciones y otros productos. Metodologa Berard Booch Coad and Yourdon Si provee Reglas de Verificacin 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 metodologa debe proporcionar una forma que permita la validacin independiente de los productos del desarrollo con el cliente, independientemente de la notacin de la misma. Modelos ejecutables, prototipos, y los flujos de escenarios son algunos ejemplos.
Metodologa Berard Booch Coad and Yourdon Embley and Kurtz Martin and Odell Rumbaugh Shlaer and Mellor Wirfs-Brock Prototipo Prototipo Flujo de Eventos Reglas de Validacin Prototipo Prototipo Prototipo

1.10 ASPECTOS PRAGMATICOS

1.10.1 RECURSOS DE AYUDA DISPONIBLE La tabla siguiente identifica los recursos disponibles para apoyar la metodologa. Estos recursos incluyen en sitio o entrenamiento pblico, si el entrenamiento est disponible en fuentes solas o mltiples, la disponibilidad de las cintas video del entrenamiento, el nmero de los textos disponibles que se ocupan de la metodologa, y los servicios de consulta disponibles. Adems, las libreras de componentes reutilizables disponibles que se construyeron para usar la metodologa.
Metodogas Berard Booch Coad and Yourdon Embley and Kurtz Martin and Odell Rumbaugh Shlaer and Mellor Ambas Ambas Ambas 1 1 1 Si Si Entrenamiento Ambas Ambas Ambas Recursos 2 Por lo menos 2 1 Si Si Video Textos Libreras 3 1 2 1 1 1 2 1 1

Wirfs-Brock

Ambas

Por lo menos 2

1.10.2 ENTRENAMIENTO REQUERIDO PARA LA UTILIZACION DE LA METODOLOGIA (Independiente del entrenamiento del Lenguaje de programacin) Esta es una valoracin subjetiva de la complejidad de cada mtodo. Esta valoracin se basa en el nmero de los modelos presentes en cada notacin, la cantidad de maestra requerida para utilizar el mtodo, el nmero de los pasos presentes en cada proceso, y la claridad de la aproximacin. De acuerdo con estos factores, se hace una estimacin del entrenamiento requerido necesitado para utilizar con eficacia el mtodo. Los mtodos altamente complejos requieren la mayora del entrenamiento (mas de 6 semanas), los mtodos medios de la complejidad requerirn aproximadamente 3-6 semanas de entrenamiento, y los mtodos bajos de la complejidad requerirn menos de 3 semanas de entrenamiento. En todos los casos al perodo del tiempo ser requerido (3-6 meses) antes de que el personal haga uso del mtodo.
Metodologa Berard Booch Coad and Yourdon Embley and Kurtz Martin and Odell Rumbaugh Shlaer and Mellor Wirfs-Brock Complejidad Medio Medio Bajo Alto Alto Medio Alto Medio

1.10.3 LENGUAJES QUE UTILIZAN LAS METODOLOGIAS

La independencia del lenguaje es una cualidad deseable de cualquier metodologa esto provee una portabilidad de los productos del anlisis y del diseo a travs de los lenguajes.

Metodogias Berard Booch Coad and Yourdon Embley and Kurtz

Ada Eiffel Smalltalk C++ CLOS Total X X X X X X X X X X X X X 5 5 3 0

Martin and Odell Rumbaugh Shlaer and Mellor Wirfs-Brock X X X X X X X

0 4 2 1

1.10.4 HERRAMIENTAS METODOLOGIA

AUTOMATIZADAS

DISPONIBLES

PARA

CADA

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 Unix (DECStation, RS6000, Silicon Graphics) VAX/VMS, Unix, OS/2, PC-DOS Descripcion y Metodologias que Suporta Martin y Odell set de herramientas CASE con capacidades de orientacion a objetos Shlaer/Mellor, HOOD Analisis y diseo orientados a objetos Rumbaugh Multiusuario, set de herramientas de desarrollo OO Rumbaugh, Coad/Yourdon, y Booch Martin and Odell Analisis y diseo orientado a objetos Berard, Booch, Coad/Yourdon, Rumbaugh, Analisis Orientado a Objetos Coad/Yourdon Diseo Orientado a Objetos Booch Diseo Orientado a Objetos Booch Analisis y Diseo Orientado a Objetos Booch Analisis y Diseo Orientado a Objetos Booch, Coad/Yourdon, Rumbaugh Shlaer/Mellor Analisis Orientado a Objetos, Diseo estructurado WirfsBrock Herramienta de documentacion OO Coad/Yourdon

Ptech

Teamwork

OMTool

Unix

Iconix Power Tools OMW

Macintosh WIndows and Unix MS-Windows, Unix, Macintosh Unix, Macintosh, MSWindows MS-Windows MS-Windows, OS/2 Unix, AIX

ObjectMaker

OOATool Object System/Designer System Architect Rose

ATRIOM

MS-Windows

TurboCase

Macintosh

OOTher

Windows

Metodologia Berard Booch Coad and Yourdon Embley and Kurtz Martin and Odell Rumbaugh Shlaer and Mellor Wirfs-Brock

Numero de Herramientas Disponibles 2 7 7 2 4 3 1

1.10.5 COMPARACION DE METODOLOGIA TRADICIONAL CON METODOLOGIA ORIENTADA A OBJETOS Las metodologas de anlisis y diseo 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 pequeas y que forman los bloques o mdulos de las aplicaciones. En la orientacin a objeto, por su parte, cobra mucho ms importancia el aspecto de modelado del sistema, examinando el dominio del problema como un conjunto de ojbetos que interactan entres s. En las metodologas tradicionales se produce una divisin 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 orientacin al objeto de un enfoque unificador de ambos aspectos, que seunen en los objetos. En las metodologas tradicionales las herramientas que utilizan para el anlisis son: Diagramas de Flujos de Datos, Diccionarios de Datos, Diagramas EntidadRelacin, Diagramas de Trancisin de Estado, Especificaciones de procesos. En las metodologas orientadas a objetos se emplean distintos modelos depende de la metodologa, entre los principales estn Modelo de objetos, Modelo de Estado u Objeto-Estado, entre otros. A continuacin 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 representacin de dinmica de un sistema de Clima (Aire acondicionado), modelado por los dos enfoques de metodologas: 1.10.6.1 METODOLOGIA TRADICIONAL Representada por Diagrama de Flujo

1.10.6.2 METODOLOGIA ORIENTADA A OBJETOS Representada por un Diagrama de Transicin de Estado de Booch

1.10.7 APLICACIN DE LAS METODOLOGIAS La organizacin desea explorar la orientacin 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 organizacin esta provista pesadamente en herramientas, tecnologa, y entrenamiento basado en datos o ingeniera de informacin, y desea cambios mnimos 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 estn muy "orientados al objeto." Como cada uno de estas aproximaciones todava hace el uso significativo en modelos de datos, y el impacto en las herramientas, la tecnologa, y el entrenamiento sera mnimamente afectado. La organizacin 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 pragmtica basada en tamao 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 pragmtica donde su desarrollo esta basado en la reutilizacin. Berard y Booch proporcionan la mayora de esta ayuda. Interesado en un mtodo donde la nica preocupacin 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 da son mejores y ms 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 tecnologa de la informacin ha ejercido un profundo impacto en la sociedad por lo que ahora se le llama la Era de la Informacin. Los empleados administrativos rebasaron el nmero de los trabajadores de produccin. La sociedad industrial ha dado paso a una nueva sociedad, en donde la mayora de las personas trabajan con informacin 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 metodologas buscando la manera optima de desarrollarlos. Las metodogas tambin han evolucionado. Inicialmente hubo un periodo de Desarrollo Convencional, despus surge el Desarrollo Estructurado y en la actualidad aparece el paradigma de la Orientacin a Objetos como un nuevo enfoque en la ingeniera de software. A la fecha se han desarrollado muchsimas metodologa enfocadas a la Orientacin a Objetos, en esta investigacin solo vimos 8 de ellas, siendo de las mas representativas de este paradigma. Cuando inici esta investigacin yo contaba con ninguna o poqusimas bases de Orientacin a Objetos. Poco a poco al ir leyendo y conociendo cada metodologa entend mejor este paradigma. Una de las metodologas que me ayudaron mucho a comprender la Orientacin a Objetos fue la de Booch, ya que se apoya de muchos grficos para definir los conceptos bsicos de Orientacin a Objetos, por lo que yo la recomiendo para principiantes. Por otro lado Rumbaugh me pareci muy completa porque es una de las que ms puntuacin tiene con respecto a entregas de productos dentro de cada etapa del ciclo de vida, cuenta con bastantes tips para el analista y diseadores para la identificacin de clases, operaciones, estados y subsistemas; cuenta con reglas de verificacin y de validacin 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 metodologa 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 metodologas con las que yo propongo para desarrollar sistemas de calidad basados en Orientacin 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. Booch, G. (1996). Anlisis y Diseo Orientado a Objetos con aplicaciones. Mxico: Pearson Educacin. 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/oocontents.html en fecha 29 de Nov. de 2002. Coleman, D.; Arnold, P.; Bodoff, S.; Dollin, C.; Gilchrist, H.; Hayes, F.; Jeremaes, P. Object-Oriented Development The Fusion Method. Estados Unidos: Prentice Hall Rumbaugh, J.; Blaha, M.; Premerlani, W.; Eddy, F.; Lorensen, W. (1999); Modelado y Diseo Orientados a Objetos; Metodologa OMT. Espaa: Prentice Hall. Shneider, P. (S.F.). The Booch Method. Consultado a www.ifra.ing.tubs.de/docs/BoochReferenz/ en fecha 29 de Nov. de 2002. The Object Agency, Inc. (1995). A Comparison of Object-Oriented Development Methodologies. Consultado a www.toa.com/smnn?mcr.html en fecha 26 de Nov. de 2002. Yourdon, E. (1994). Object-Oriented Systems Design an Integrated Approach. Estados Unidos: Yourdon Press.

2 Metodologas de desarrollo de software. Cul es el camino?

2.1 Introduccin
El desarrollo de software no es sin dudas una tarea fcil. Como resultado a este problema ha surgido una alternativa desde hace mucho: la Metodologa. Las metodologas imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo ms predecible y eficiente. Lo hacen desarrollando un proceso detallado con un fuerte nfasis en planificar inspirado por otras disciplinas de la ingeniera. Las metodologas ingenieriles han estado presentes durante mucho tiempo. No se han distinguido precisamente por ser muy exitosas. An menos por su popularidad. La crtica ms frecuente a estas metodologas es que son burocrticas. Hay tanto que hacer para seguir la metodologa que el ritmo entero del desarrollo se retarda. Hoy en da existen numerosas propuestas metodolgicas que inciden en distintas dimensiones del proceso de desarrollo. Un ejemplo de ellas son las propuestas tradicionales centradas especficamente en el control del proceso. Estas han demostrado ser efectivas y necesarias en un gran nmero de proyectos, sobre todo aquellos proyectos de gran tamao (respecto a tiempo y recursos). Sin embargo la experiencia ha demostrado que las metodologas tradicionales no ofrecen una buena solucin para proyectos donde el entorno es voltil y donde los requisitos no se conocen con exactitud, porque no estn pensadas para trabajar con incertidumbre. Aplicar metodologas tradicionales nos obliga a forzar a nuestro cliente a que tome la mayora de las decisiones al principio. Luego el coste de cambio de una decisin tomada puede llegar a ser muy elevado si aplicamos metodologas tradicionales. Es por ello que varios problemas como los que a continuacin mencionamos han sido detectados: Retrasos en la planificacin: llegada la fecha de entregar el software ste no est disponible. Sistemas deteriorados: el software se ha creado pero despus de un par de aos el coste de su mantenimiento es tan complicado que definitivamente se abandona su produccin. Tasa de defectos: el software se pone en produccin 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 resolva nuestro software ha cambiado y nuestro software no se ha adaptado.

Falsa riqueza: el software hace muchas cosas tcnicamente muy interesantes y divertidas, pero no resuelven el problema de nuestro cliente, ni hace que ste gane ms dinero. Cambios de personal: despus de unos aos de trabajo los programadores comienzan a odiar el proyecto y lo abandonan.

Como respuesta a los problemas aplicando metodologas tradicionales surgieron otras metodologas que tratan de adaptarse a la realidad del desarrollo de software. El encanto de estas metodologas giles es su reaccin ante la burocracia de las metodologas monumentales. Estos nuevos mtodos buscan un justo medio entre ningn proceso y demasiado proceso, proporcionando simplemente suficiente proceso para que el esfuerzo valga la pena. El resultado de todo esto es que los mtodos giles cambian significativamente algunos de los nfasis de los mtodos ingenieriles. La diferencia inmediata es que son menos orientados al documento, exigiendo una cantidad ms pequea de documentacin para una tarea dada. De muchas maneras son ms bien orientados al cdigo: siguiendo un camino que dice que la parte importante de la documentacin es el cdigo fuente.

2.2 Desarrollo
2.2.1 Metodologas pesadas. 2.2.1.1 RUP El proceso unificado de desarrollo (RUP) es una metodologa para la ingeniera de software que va ms all del mero anlisis y diseo orientado a objetos para proporcionar una familia de tcnicas 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 Caractersticas principales de RUP Centrado en los modelos: Los diagramas son un vehculo de comunicacin ms 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 anlisis y el diseo 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 mximo provecho de las nuevas tecnologas, mejorando la calidad, le rendimiento, la reutilizacin,

la seguridad y el mantenimiento del software mediante una gestin sistemtica de los riesgos. Permite la produccin de software que cumpla con las necesidades de los usuarios, a travs de la especificacin de los requisitos, con una agenda y costo predecible. Enriquece la productividad en equipo y proporciona prcticas ptimas de software a todos sus miembros. Permite llevar a cabo el proceso de desarrollo prctico, brindando amplias guas, plantillas y ejemplos para todas las actividades crticas. Proporciona guas explicitas para reas tales como modelado de negocios, arquitectura Web, pruebas y calidad. Tambin se proporciona guas 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 caractersticas de los productos Rational, el Lenguaje de Modelado Unificado (UML) y otras prcticas ptimas de la industria. Unifica todo el equipo de desarrollo de software y mejora la comunicacin al brindar a cada miembro del mismo una base de conocimientos, un lenguaje de modelado y un punto de vista de cmo desarrollar software. Optimiza la productividad de cada miembro del equipo al poner al alcance la experiencia derivada de miles de proyectos y muchos lderes de la industria. No solo garantiza que los proyectos abordados sern ejecutados ntegramente sino que adems evita desviaciones importantes respecto a los plazos. Permite una definicin acertada del sistema en un inicio para hacer innecesarias las reconstrucciones parciales posteriores. 2.2.2 Metodologas giles. 2.2.2.1 XP La Programacin Extrema surge ideada por Kent Beck, como proceso de creacin de software diferente al convencional. En palabras de Beck: XP es una metodologa 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 satisfaccin del cliente. Esta metodologa trata de dar al cliente el software que l necesita y cuando lo necesita. Por tanto, debemos responder muy rpido a las necesidades del cliente, incluso cuando los cambios sean al final de ciclo de la programacin. El segundo objetivo es potenciar al mximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y estn involucrados en el desarrollo del software.

2.2.2.1.2 Bases de XP La programacin extrema se basa en la simplicidad, la comunicacin y el reciclado continuo de cdigo, para algunos no es ms que aplicar una pura lgica. Lo que buscan en definitiva es la reduccin 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, cambiarn los requisitos, las reglas de negocio, el personal, la tecnologa, 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: Comunicacin Sencillez Retroalimentacin Valenta

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 bsicas 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 cdigo fuente no hay programa, aunque hay gente que cuenta que existe software en produccin del que se perdi el cdigo fuente. Por tanto necesitamos codificar y plasmar nuestras ideas a travs del cdigo. En una programacin en XP en pareja el cdigo expresa tu interpretacin del problema, as podemos utilizar el cdigo para comunicar, para hacer mas tus ideas, y por tanto para aprender y mejorar. 2.2.2.1.5.2 Hacer pruebas Las caractersticas 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 haba 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 cdigo, con el tiempo llegars a conclusiones sobre las pruebas y podrs 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 ms rpido que slo programar. Puedes ganar media hora de productividad sin hacer pruebas, pero perders mucho tiempo en la depuracin. Tendrs menos errores, tendrs que volver menos veces sobre el cdigo, te costar menos localizar los errores, perders 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 querran ?. Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la informacin. Tenemos que escuchar a nuestros clientes cuales son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fcil y difcil de obtener, y la realimentacin entre ambos nos ayudan a todos a entender los problemas. 2.2.2.1.5.4 Disear El diseo crea una estructura que organiza la lgica del sistema, un buen diseo permite que el sistema crezca con cambios en un solo lugar. Los diseos deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, divdela en varias. Si hay fallos en el diseo o malos diseos, estos deben de ser corregidos cuanto antes. Tenemos que codificar porque sin cdigo 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 disear para poder codificar, probar y escuchar indefinidamente. 2.2.2.1.6 Prcticas Bsicas de XP 2.2.2.1.6.1 El juego de la planificacin. Hay una comunicacin frecuente el cliente y los programadores. El equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin de las historias de usuario y los clientes deciden sobre el mbito y tiempo de las entregas y de cada iteracin.

2.2.2.1.6.2 Pequeas versiones. Cada versin debe de ser tan pequea como fuera posible, conteniendo los requisitos de negocios ms importantes, las versiones tiene que tener sentido como un todo, me explico no puedes implementar media caracterstica y lanzar la versin. Es mucho mejor planificar para 1 mes o 2 que para seis meses y un ao, las compaas que entregan software muy voluminoso no son capaces de hacerlo con mucha frecuencia. 2.2.2.1.6.3 Metfora. Una metfora es una historia que todo el mundo puede contar a cerca de cmo funciona el sistema. Algunas veces podremos encontrar metforas sencillas Programa de gestin de compras, ventas, con gestin de cartera y almacn. Las metforas ayudan a cualquier persona a entender el objeto del programa. 2.2.2.1.6.4 Diseo sencillo. El diseo adecuado para el software es aquel que: 1. Funciona con todas las pruebas. 2. No tiene lgica duplicada. 3. Manifiesta cada intencin importante para los programadores 4. Tiene el menor nmero de clases y mtodos. Haz el diseo lo ms 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, disea para maana, no es del todo correcto si piensas que el futuro es incierto. 2.2.2.1.6.5 Hacer pruebas. No debe existir ninguna caracterstica 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 Recodificacin. Cuando implementamos nuevas caractersticas en nuestros programas nos planteamos la manera de hacerlo lo mas simple posible, despus de implementar esta caracterstica, 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 caractersticas. No debemos de recodificar ante especulaciones si no solo cundo el sistema te lo pida. 2.2.2.1.6.7 Programacin por parejas. Todo el cdigo de produccin lo escriben dos personas frente al ordenador, con un slo ratn y un slo teclado. Cada miembro de la pareja juega su papel: uno

codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa ms estratgicamente, Va a funcionar?, Puede haber pruebas donde no funcione?, Hay forma de simplificar el sistema global para que el problema desaparezca? El emparejamiento es dinmico, puedo estar emparejado por la maana 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 cdigo en cualquier parcela puede hacerlo, ningn miembro del equipo es propietario del cdigo. Si alguien quiere hacer cambios en el cdigo puede hacerlo. Si hacemos el cdigo propietario, y necesitamos de su autor para que lo cambie entonces estaremos alejndonos cada vez mas de la comprensin del problema, si necesitamos un cambio sobre una parte del cdigo lo hacemos y punto. XP propone un propiedad colectiva sobre el cdigo nadie conoce cada parte igual de bien pero todos conoce algo sobre cada parte, esto nos preparar para la sustitucin no traumtica de cada miembro del equipo. 2.2.2.1.6.9 Integracin contina. El cdigo se debe integrar como mnimo una vez al da, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargara de integrar todo el cdigo 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 maana y cansado y satisfecho cada noche. El viernes quiero estar cansado y satisfecho para sentir que tengo dos das para pensar en algo distinto y volver el lunes lleno de pasin e ideas. Esto requiere que trabajemos 40 horas a la semana, mucha gente no puede estar ms 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 sntoma 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 difcil 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 Estndares de codificacin. Si los programadores van a estar tocando partes distintas del sistema, intercambiando compaeros, haciendo refactoring, debemos de establecer un estndar de codificacin aceptado e implantado por todo el equipo.

2.2.2.1.7 Caractersticas esenciales de XP 2.2.2.1.7.1 Roles. Programador: Produce el cdigo del sistema. Cliente: Escribe las HU y las pruebas funcionales para validar su implementacin, as como asigna la prioridad de la HU y decide cul se implementara en cada iteracin. Encargado de pruebas: Ayuda al cliente a escribir las pruebas funcionales, ejecuta las pruebas y difunde resultados adems es responsable de las herramientas de soporte para prueba. Rastreador (Tracker): tambin conocido como Metric Man, observa sin molestar y mantiene los datos histricos. Consultor: Es un miembro externo del equipo con conocimiento especifico de algn tema necesario para el proyecto. Gua al equipo para resolver un problema especfico. Gestor (Big Boss): Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin. 2.2.2.1.7.2 Artefactos esenciales. Historias de Usuario. Tareas de Ingeniera. Pruebas de Aceptacin. 2.2.2.1.7.3 Procesos. Ciclo de desarrollo. Ciclo de vida(Fases) 1. Exploracin 2. Planificacin. 3. Iteraciones. 4. Produccin. 5. Mantenimiento. 6. Muerte Proyecto. 2.2.2.1.7.4 Prcticas. 2.2.2.2 3P. Paradigma 3P es una metodologa de desarrollo de software nacida al calor de la experiencia acumulada del grupo de investigacin y desarrollo Atis debido a la insuficiente capacidad de respuesta a los clientes utilizando las metodologas tradicionales. 2.2.2.2.1 Principios que sustentan el modelo 1. Los individuos y sus interacciones son ms importantes que los procesos y las herramientas: El PERSONAL.

2. La comunicacin con el cliente evita construir una elegante solucin para un problema equivocado: El PROBLEMA. 3. El software que funciona es ms importante que la documentacin exhaustiva. El PROCESO. 2.2.2.2.2 Valores 3P 1. Comunicacin: Sin comunicacin todo proyecto estara 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 dems 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. Retroalimentacin: Saber cundo 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 ms complejas, encararla con esmero y con alegra har que crezca nuestro prestigio entre los dems miembros, la conviccin 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 bsicas 1. Codificar. 2. Probar. 3. Comunicar 4. Idear 5. Escuchar. 6. Disear. 2.2.2.2.4 Roles del proyecto 1. Jefe del Proyecto 2. Cliente 3. Consultor 4. Analista-Programador 5. Programador 6. Diseador de Interfaces 2.2.2.2.5 Principios que sustentan la metodologa 1. EL Personal: Gestin de Proyecto 2. El Problema: Gestin del Cliente 3. El Proceso: Ciclo de Vida de Desarrollo

2.2.2.2.6 Ciclo de vida de desarrollo 1. Definicin del problema. 2. Identificacin de los procesos unitarios. 3. Diseo 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. Implantacin. 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 documentacin 2.3.2 3P gil Cercano al desarrollo, pero sin olvidar el diseo. Se basa en 3 principios: Personal, Problema, Proceso. Gran interaccin con el cliente. Pruebas de funcionalidad y calidad. Logra alcanzar un control y organizacin del proceso. Logra un equilibrio en cuanto a la generacin de documentacin 2.3.3 XP Ligero Cercano al desarrollo Se basa en UserStories Fuerte comunicacin con el cliente

 El cdigo fuente pertenece a todos Programacin por parejas Tests como base de la funcionalidad Solo el mnimo de organizacin Pobre en cuanto a documentacin

2.4 Conclusiones
Qu debemos esperar entonces de un proceso de desarrollo? Qu criterios debe cumplir para que aporte algo a la empresa? Bsicamente 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 ningn proceso estndar, y como dice el refrn (aunque no se cumple exactamente en el mundo de la informtica) 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]. Annimo. 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]. Annimo. Rational Unified Process. http://www.itera.com.mx/itera/productos/fundamentos.asp. (2/5/08) [ANO05,3]. Annimo. Proceso Unificado de Rational para el desarrollo de software. http://www.dybox.cl/metodologia/rup.html. (2/5/08) [BAR08]. Barrientos Enrquez, Aleida Mirian. El desarrollo de sistemas de informacin empleando el lenguaje de modelado unificado UML. [JAC08]. Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El Proceso Unificado de Desarrollo de Software. [ECH08]. Echevarra Cosso, Yanelis. Modelo gil de Desarrollo de Proyectos de Software:Paradigma 3P.

2.6 Bibliografa
Alianza gil, http://www.agilealliance.org Patricio Letelier, Departamento de Sistemas Informticos y Computacin, Universidad Politcnica de Valencia, letelier@dsic.upv.es Manifiesto para el Desarrollo http://www.agilemanifesto.org de Software gil,

 Martn Fowler, La Nueva Metodologa, 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. Echevarra Cosso, Yanelis. Modelo gil de Desarrollo de Proyectos de Software:Paradigma 3P. Annimo. Proceso Unificado de Rational para el desarrollo de software. http://www.dybox.cl/metodologia/rup.html. (2/5/05) Annimo. Rational Unified Process.
http://www.itera.com.mx/itera/productos/fundamentos.asp. (2/5/05)

Annimo. Seminario sobre RUP en un entorno empresarial de desarrollo. http://www5.ibm.com/services/learning/es/tairis.nsf/(ExtCourseNr)/RUPS1ES. (2/5/05) Barrientos Enrquez, Aleida Mirian. El desarrollo de sistemas de informacin empleando el lenguaje de modelado unificado UML.

3 Anlisis y Diseo de Sistemas

3.1 Anlisis de Sistemas de Computacin
3.1.1 Conceptos y Anlisis Es un conjunto o disposicin 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 lgico en la unin de las partes. Un mtodo, plan o procedimiento de clasificacin para hacer algo. Tambin es un conjunto o arreglo de elementos para realizar un objetivo predefinido en el procesamiento de la Informacin. Esto se lleva a cabo teniendo en cuenta ciertos principios: Debe presentarse y entenderse el dominio de la informacin de un problema. Defina las funciones que debe realizar el Software. Represente el comportamiento del software a consecuencias de acontecimientos externos. Divida en forma jerrquica los modelos que representan la informacin, funciones y comportamiento.

El proceso debe partir desde la informacin esencial hasta el detalle de la Implementacin. La funcin del Anlisis 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 documentacin que hacen efectiva la logstica metodologa o controles de requerimientos del Programa. 2. Hardware, dispositivos electrnicos y electromecnicos, que proporcionan capacidad de clculos y funciones rpidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.), que proporcionan una funcin externa dentro de los Sistemas. 3. Personal, son los operadores o usuarios directos de las herramientas del Sistema. 4. Base de Datos, una gran coleccin de informaciones organizadas y enlazadas al Sistema a las que se accede por medio del Software. 5. Documentacin, Manuales, formularios, y otra informacin descriptiva que detalla o da instrucciones sobre el empleo y operacin 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 Anlisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en mente: Identifique las necesidades del Cliente. Evale que conceptos tiene el cliente del sistema para establecer su viabilidad. Realice un Anlisis Tcnico y econmico. Asigne funciones al Hardware, Software, personal, base de datos, y otros elementos del Sistema. Establezca las restricciones de presupuestos y planificacin temporal. Cree una definicin del sistema que forme el fundamento de todo el trabajo de Ingeniera.

Para lograr estos objetivos se requiere tener un gran conocimiento y dominio del Hardware y el Software, as como de la Ingeniera humana (Manejo y Administracin de personal), y administracin de base de datos. 3.1.2 Objetivos del Anlisis 3.1.2.1 Identificacin de Necesidades Es el primer paso del anlisis del sistema, en este proceso en Analista se rene 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 planificacin temporal y presupuestal, lneas de mercadeo y otros puntos que puedan ayudar a la identificacin y desarrollo del proyecto.

Algunos autores suelen llamar a esta parte Anlisis de Requisitos y lo dividen en cinco partes:

Reconocimiento del problema.

Evaluacin y Sntesis.

Modelado. Especificacin. Revisin.

Antes de su reunin con el analista, el cliente prepara un documento conceptual del proyecto, aunque es recomendable que este se elabore durante la comunicacin Cliente analista, ya que de hacerlo el cliente solo de todas maneras tendra que ser modificado, durante la identificacin 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 materializacin sin tener perdidas econmicas y frustracin profesional. La viabilidad y el anlisis de riesgos estn 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 inters: 3.1.2.2.1 Viabilidad econmica Una evaluacin de los costos de desarrollo, comparados con los ingresos netos o beneficios obtenidos del producto o Sistema desarrollado. 3.1.2.2.2 Viabilidad Tcnica Un estudio de funciones, rendimiento y restricciones que puedan afectar la realizacin de un sistema aceptable. 3.1.2.2.3 Viabilidad Legal Es determinar cualquier posibilidad de infraccin, violacin o responsabilidad legal en que se podra incurrir al desarrollar el Sistema. 3.1.2.2.4 Alternativas. Una evaluacin 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 Anlisis Econmico y Tcnico El anlisis econmico incluye lo que llamamos, el anlisis de costos beneficios, significa una valoracin de la inversin econmica comparado con los beneficios que se obtendrn en la comercializacin y utilidad del producto o sistema. Muchas veces en el desarrollo de Sistemas de Computacin estos son intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a la

caractersticas del Sistema. El anlisis de costos beneficios es una fase muy importante de ella depende la posibilidad de desarrollo del Proyecto. En el Anlisis Tcnico, el Analista evala los principios tcnicos del Sistema y al mismo tiempo recoge informacin adicional sobre el rendimiento, fiabilidad, caractersticas de mantenimiento y productividad. Los resultados obtenidos del anlisis tcnico 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 idntico, pero en menor escala (mas pequeo). 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 notacin grfica, informacin y comportamiento del Sistema. Todos los Sistemas basados en computadoras pueden modelarse como transformacin de la informacin empleando una arquitectura del tipo entrada y salida. 3.1.2.5 Especificaciones del Sistema Es un Documento que sirve como fundamento para la Ingeniera Hardware, software, Base de datos, e ingeniera Humana. Describe la funcin y rendimiento de un Sistema basado en computadoras y las dificultades que estarn presente durante su desarrollo. Las Especificaciones de los requisitos del software se produce en la terminacin de la tarea del anlisis.

3.2 Diseo de sistemas de computacin

3.2.1 Conceptos y principios El Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y principios con el propsito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretacin y realizacin fsica. La etapa del Diseo del Sistema encierra cuatro etapas: 3.2.1.1 El diseo de los datos Trasforma el modelo de dominio de la informacin, creado durante el anlisis, en las estructuras de datos necesarios para implementar el Software. 3.2.1.2 El Diseo Arquitectnico Define la relacin entre cada uno de los elementos estructurales del programa. 3.2.1.3 El Diseo 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 Diseo de procedimientos Transforma elementos estructurales de la arquitectura del programa. La importancia del Diseo del Software se puede definir en una sola palabra Calidad, dentro del diseo es donde se fomenta la calidad del Proyecto. El Diseo es la nica manera de materializar con precisin los requerimientos del cliente. El Diseo del Software es un proceso y un modelado a la vez. El proceso de Diseo es un conjunto de pasos repetitivos que permiten al diseador describir todos los aspectos del Sistema a construir. A lo largo del diseo se evala la calidad del desarrollo del proyecto con un conjunto de revisiones tcnicas: El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acumular todos los requisitos implcitos que desea el cliente. Debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban y mantienen el Software. El Diseo 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 Implementacin. Para evaluar la calidad de una presentacin del diseo, se deben establecer criterios tcnicos para un buen diseo como son: Un diseo debe presentar una organizacin jerrquica que haga un uso inteligente del control entre los componentes del software. El diseo debe ser modular, es decir, se debe hacer una particin lgica del Software en elementos que realicen funciones y subfunciones especificas. Un diseo debe contener abstracciones de datos y procedimientos. Debe producir mdulos que presenten caractersticas de funcionamiento independiente. Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los mdulos y el entorno exterior. Debe producir un diseo usando un mtodo que pudiera repetirse segn la informacin obtenida durante el anlisis de requisitos de Software.

Estos criterios no se consiguen por casualidad. El proceso de Diseo del Software exige buena calidad a travs de la aplicacin de principios fundamentales de Diseo, Metodologa sistemtica y una revisin exhaustiva. Cuando se va a disear un Sistema de Computadoras se debe tener presente que el proceso de un diseo incluye, concebir y planear algo en la mente, as como hacer un dibujo o modelo o croquis. 3.2.1.5 5. Diseo de la Salida En este caso salida se refiere a los resultados e informaciones generadas por el Sistema, Para la mayora de los usuarios la salida es la nica razn para el

desarrollo de un Sistema y la base de evaluacin de su utilidad. Sin embargo cuando se realiza un sistema, como analistas deben realizar lo siguiente: Determine que informacin presentar. Decidir si la informacin ser presentada en forma visual, verbal o impresora y seleccionar el medio de salida. Disponga la presentacin de la informacin en un formato aceptable. Decida como distribuir la salida entre los posibles destinatarios.

3.2.1.6 Diseo 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 histricos, o informacin de referencia. Entre las decisiones que se toman durante el diseo 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 caractersticas de los datos que contenga. La secuencia a disposicin de los registros dentro del archivo (La estructura de almacenamiento que puede ser secuencial, indexada o relativa).

No todos los sistemas requieren del diseo de todos los archivos, ya que la mayora 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 Diseo de Interacciones con la Base de Datos La mayora de los sistemas de informacin ya sean implantado en sistemas de cmputos grandes o pequeos, utilizan una base de datos que pueden abarcar varias aplicaciones, por esta razn estos sistemas utilizan u administrador de base de datos, en este caso el diseador 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 Diseo de Sistemas Apoyan el proceso de formular las caractersticas que el sistema debe tener para satisfacer los requerimientos detectados durante las actividades del anlisis: 3.2.2.1 Herramientas de especificacin Apoyan el proceso de formular las caractersticas que debe tener una aplicacin, tales como entradas, Salidas, procesamiento y especificaciones de control. Muchas incluyen herramientas para crear especificaciones de datos. 3.2.2.2 Herramientas para presentacin Se utilizan para describir la posicin 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 diseos en aplicaciones funcionales. 3.2.2.4 Herramientas para Ingeniera de Software Apoyan el Proceso de formular diseos de Software, incluyendo procedimientos y controles, as como la documentacin correspondiente. 3.2.2.5 Generadores de cdigos Producen el cdigo fuente y las aplicaciones a partir de especificaciones funcionales bien articuladas. 3.2.2.6 Herramientas para pruebas Apoyan la fase de la evaluacin de un Sistema o de partes del mismo contra las especificaciones. Incluyen facilidades para examinar la correcta operacin del Sistema as como el grado de perfeccin alcanzado en comparacin con las expectativas. La revolucin del procesamiento de datos de manera computarizada, junto con las prcticas de Diseo sofisticadas est cambiando de forma dramtica la manera en que se trasladan las especificaciones de Diseo d Sistemas de Informacin funcionales.

3.3 Anlisis de Sistemas de Apoyo a Decisiones Semiestructuradas

3.3.1 Mtodos Disponibles Para poder obtener buenos resultados en los sistemas de apoyo a decisiones estructuradas, debemos dividir el trabajo como lo dice anteriormente el anlisis de sistema del que estamos hablando, debe tener en cuenta: Si es analtico o heurstico Cmo son tomadas la decisiones en las tres fases de resolucin de problemas de inteligencia El uso de los mtodos de criterios mltiples tiles para la resolucin de problemas semiestructurados.

Estos sistemas pueden funcionar de varias formas es decir, la organizacin de la informacin para las situaciones de decisin, la interaccin con los tomadores de decisiones que llevan consigo la expansin en la toma de decisiones, la forma de presentar la informacin para su mejor comprensin aadiendo modelos y criterios mltiples. En donde los modelos de criterios mltiples incluyen procesos de compromiso, mtodos ponderados y mtodos de eliminacin secuencial y son los ms adecuados para el manejo de la complejidad y naturaleza semiestructurada. 3.3.2 Sistemas de apoyo a Decisiones Este mtodo posee caractersticas que lo diferencia de los dems sistemas que manejan informacin y que son tradicionales. Los usuarios finales de los DSS

(sistemas de apoyo a decisiones) poseen caractersticas especiales que merecen ser tomadas en cuenta. 3.3.2.1 Caractersticas de un sistema de apoyo a decisiones Debemos tener en cuenta que un sistema de apoyo a decisiones lo definiremos como la manera de organizacin de informacin que se pretende usar en la toma de decisiones. Para lo cual al presentar la informacin debe estar diseada basndose en la solucin de problemas y esto debe darse ya que el usuario no debe tomar la decisin, 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 diseado tpicamente para decisiones de un particular o para un grupo, es decir que el usuario entienda mejor las soluciones por medio de grficas, tablas u otro medio de presentacin y que sea de interfaz para el usuario. Debemos saber utilizar las diferentes herramientas que generan DSS, as como en la construccin de DSS especficos, y generadores de DSS. Para el DSS, el proceso trabajar para la transformacin del usuario, el tomados de decisiones y debe dar como resultado un cambio y mejora del desempeo 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 estratgico, 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 estratgico y administrativo. Es importante que si el usuario final est muy ocupado o preocupado por la interaccin con el DSS, este puede ser utilizado por un intermediario tcnico o ayudante que interacte con la computadora y as las decisiones sern tomadas de una forma desde el proceso y no desde la mecnica. 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 informacin como, el uso de teoras, que tiene como consecuencia el acierto, la incertidumbre y el riesgo, es por eso que debemos diferenciar si el tomador de decisiones en analtico o heurstico y es importante que estos tomen en cuenta las fases de solucin como son la inteligencia, la seleccin y el diseo, 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 decisin, los resultados, las consecuencias y segn 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 slo 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 informacin se recolecta, procesa y se usa en forma de parmetro segn sea el estilo de la toma de decisiones. Y es por eso que los tomadores de decisiones son analticos o heursticos. Un tomador de decisiones analtico se apoya en la informacin que es adquirida y evaluada sistemticamente para estrechar las alternativas y tomar una seleccin que est basada en informacin. En donde los tomadores de decisiones analticos valoran la informacin cuantitativa y los modelos que la generan y la usan. Como comentario adicional, utilizan matemticas para el modelo del problema y usan algoritmos para resolverlos. Un tomador de decisiones heurstico se hace ayudar de lineamientos (reglas), aunque no se adapte, bajo conciencia o un sistema, esto es que la heurstica se basa en la experiencia. Estos tomadores de decisiones aprenden bajo las actuaciones, es decir mediante la prueba y el error hasta encontrar la solucin. Y su apoyo es el sentido comn para que los gue. Tomador de decisiones analtico Tomador de decisiones heurstico

Aprende mediante anlisis Usa procedimientos paso a paso Valora la informacin cuantitativa y los modelos Constituye modelos matemticos y algoritmos Busca soluciones ptimas 3.3.4 Fases para la solucin de problemas La toma de decisiones (o resolucin 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 Aprende actuando Usa prueba y error Valora la experiencia Se apoya en el sentido comn Busca soluciones satisfactorias

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 diseo y la seleccin (Simn 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 bsqueda continua y revisin. Diseo: Formula un problema y analiza las varias soluciones alternativas, proporcionando al tomador de decisiones generar y analizar alternativas para su aplicabilidad potencial. Seleccin: La seleccin del tomador de decisiones de una solucin al problema u oportunidad identificado en la fase de inteligencia. Incluyendo la implementacin de la seleccin del tomador de decisiones. Hay otros autores que incluyen la implementacin y la evaluacin.

3.4 Conclusiones
En Conclusin un proyecto de desarrollo de un Sistema de Informacin comprende varios componentes o pasos llevados a cabo durante la etapa del anlisis, 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, documentacin y procedimientos. En una organizacin o Empresa, el anlisis y Diseo de Sistemas, es el proceso de estudiar su Situacin 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 situacin actual de la empresa. La informacin reunida con este estudio sirve como base para crear varias estrategias de Diseo. Los administradores deciden que estrategias seguir. Los Gerentes, empleados y otros usuarios finales que se familiarizan cada vez mas con el uso de computadoras estn teniendo un papel muy importante en el desarrollo de sistemas. Todas las organizaciones son Sistemas que actan 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 Implantacin. Es por eso que existen varios modelos o mtodos para la realizacin del anlisis y diseo de un sistema, lo primero del trabajo fue revisar que es el Anlisis y el diseo y posteriormente el autor Kendall, presenta varios modelos que podemos utilizar para la realizacin y elaboracin de un proceso y trabajo exhaustivo y dar solucin o respuesta al problema que se ha generado desde la perspectiva del programador y analista.

3.5 Bibliografa
Kendall & Kendall; Anlisis y Diseo de Sistemas; 3 Edicin; Pearson Educacin. Roger S. Pressman; Ingeniera del Software;4 Edicin; Mc Graw Hill