Ingeniera en Desarrollo de Software CUATRIMESTRE: 04 Programa de la asignatura: Anlisis y diseo orientado a objetos Unidad 1. Introduccin al Anlisis orientado a objetos Clave: 160920413 / 150920413

ndice UNIDAD 1. INTRODUCCIN AL ANLISIS ORIENTADO A OBJETOS ............................ 3 Presentacin de la unidad .............................................................................................. 3 Propsito ........................................................................................................................ 3 Competencia especfica ................................................................................................. 3 Actividad 1. Presentacin ............................................................................................... 3 1.1. Generalidades ......................................................................................................... 4 1.1.1. Definicin ............................................................................................................. 5 1.1.2. Caractersticas ..................................................................................................... 7 1.1.3. Ventajas ............................................................................................................... 8 Actividad 2. Caractersticas y ventajas de la programacin OO ................................... 10 1.2. Identificacin y conceptos bsicos de modelos orientados a objetos ..................... 10 1.2.1. Abstraccin ........................................................................................................ 11 1.2.2. Encapsulamiento ................................................................................................ 12 1.2.3. Modularidad........................................................................................................ 13 1.2.4. Herencia ............................................................................................................. 13 1.2.5. Polimorfismo....................................................................................................... 14 Actividad 3. Ejemplos de sistemas ............................................................................... 14 1.3. Ciclo de vida del software y tipos de ciclos ............................................................ 15 1.3.1. Definicin ........................................................................................................... 15 1.3.2. Espiral ................................................................................................................ 16 1.3.3. Cascada ............................................................................................................. 17 1.3.4. Incremental ........................................................................................................ 18 Actividad 4. Conceptos bsicos de los modelos Orientados a objetos ......................... 19 Autoevaluacin ............................................................................................................. 19 Evidencia de aprendizaje. Mapa mental de los modelos orientados a objetos .............. 19 Cierre de la unidad ....................................................................................................... 20 Para saber ms ........................................................................................................ 20 Fuentes de consulta ..................................................................................................... 21

Unidad 1. Introduccin al anlisis orientado a objetos Presentacin de la unidadBienvenido(a) a la asignatura Anlisis y diseo orientado a objetos. En esta primera unidad se expondrn los principios fundamentales de un buen anlisis para hacer un correcto diseo y as poder programar con orientacin a objetos, lo que permitir dar cumplimiento al propsito de la unidad. En la primera parte de esta unidad te enfrentars en la seccin de anlisis y diseo, con algunos conceptos bsicos como la definicin, las caractersticas y las ventajas de hacer un anlisis previo de la informacin y debers conocer, en la segunda parte de esta unidad, los conceptos de orientacin a objetos para que cuando hagas tu diseo sepas darle ese enfoque, tambin distinguirs las caractersticas de este tipo de programacin. Finalmente, conocers el ciclo de vida del software y algunos tipos de ciclos. Toda esta informacin es el principio bsico de un buen anlisis de diseo orientado a objetos.

PropsitoConocer los atributos de los modelos orientados a objetos para poder establecer las necesidades del diseo de un sistema con estas caractersticas, as como ubicar las etapas de vida del software.

Competencia especficaIdentificar las etapas de un sistema orientado a objetos para decidir su ciclo de vida, utilizando los conceptos de orientacin a objetos.

Actividad 1. PresentacinAntes de entrar de lleno en el estudio de la asignatura, te presentamos un foro de discusin general, el cual fue creado con la finalidad de que te presentes con tus compaeros y comentes cualquier asunto relacionado con la asignatura; en l, conocers a tus compaeros de grupo y entre todos podrn apoyarse para resolver dudas, inquietudes, externar comentarios, etctera. Para comenzar tu participacin, ingresa al foro Presentacin.

1.1. GeneralidadesEl objetivo principal del anlisis orientado a objetos (AOO), es desarrollar un software capaz de cubrir con las necesidades esenciales del usuario final, y su diseo se enfoca en los objetos. El anlisis orientado a objetos y su diseo se basa en definir una serie de actividades relevantes al problema que se va a resolver, en donde son comnmente utilizadas las operaciones y atributos asociados. Para cumplir con esto se deben tener en cuenta las siguientes tareas: 1.- Debe de existir una comunicacin sobre los requisitos bsicos del usuario ya que ser el usuario final del software. 2.- Se deben definir los mtodos a utilizar para el anlisis. 3.- Se debe definir la jerarqua de los mtodos utilizados para el anlisis. 4.- Deben existir relaciones de objeto a objeto, as como todas sus conexiones. 5.- Debe modelarse el comportamiento del objeto. Las actividades anteriores se aplican de forma iterativa hasta que el modelo est completo. El software orientado a objetos es ms fcil de mantener debido a que su estructura es inherentemente poco acoplada. Adems los sistemas orientados a objetos son ms fciles de adaptar y escalables. El enfoque realizado sobre el desarrollo orientado a objetos no debe implicar hacer las tareas diferentes del enfoque clsico de desarrollo de software puesto que se desarrollan actividades similares en un proceso evolutivo.

El modelo orientado a objetos tiene como caracterstica el hecho de que un elemento del mundo real se puede representar a travs de sus caractersticas y de sus comportamientos. Los conceptos como clase, objeto, instancia, atributos y mtodos, se hacen cotidianos en el AOO, ya que son parte de su vocabulario. Los conceptos fundamentales que llevan a un diseo de alta calidad son igualmente aplicables a sistemas desarrollados usando mtodos orientados a objetos. Por esa razn, un AOO debe exhibir abstracciones de datos y procedimientos que conducen a una modularidad eficaz. La gestin de un proyecto de software orientado a objetos por lo general tiene actividades como: 1.- Establecer un proceso comn para el proyecto. 2.- Usar mtricas para desarrollar estimaciones de tiempo y esfuerzo. 3.- Especificar productos de trabajo e hitos que permitirn medir el progreso. 4.- Tener puntos de comprobacin para la gestin de la calidad y control. 5.- Controlar cambios que se generan durante el progreso del proyecto. 6.- Realizar el seguimiento y control del progreso. El AOO se basa en un conjunto de principios bsicos comnmente usados: 1.- Modelado de la informacin. 2.- Descripcin de funciones. 3.- Representacin del comportamiento del modelo. 4.- Desarrollo de modelos de datos, funcional y de comportamiento. El anlisis y desarrollo orientado a objetos puede ser interpretado como el conjunto de disciplinas que desarrollan y modelan un software que facilita la construccin de sistemas de informacin complejos a partir de la formacin de sus componentes. Las tcnicas orientadas a objetos proporcionan mejoras y metodologas para construir sistemas de software complejos a partir de unidades de software, el enfoque del AOO debe ser capaz de manipular sistemas grandes y pequeos que sean flexibles con facilidad de mantenimiento y capaces de evolucionar con respecto a las necesidades y requerimientos del usuario final.

1.1.1. DefinicinPara comenzar a entender en qu consiste el anlisis y diseo de software orientado a objetos, empezaremos por definir el trmino orientado a objetos, pero vayamos por partes, como se muestra a continuacin: Objeto: Instancia de una clase especfica. Los objetos heredan los atributos y operaciones de una clase. Clase: Representa a una entidad que tiene un estado interno y un comportamiento caracterstico. Atributos: Son los datos a los que se refiere el estado del objeto (Booch-Grady, 1996). Los objetos tienen un estado interno y un comportamiento, el estado de un determinado objeto es un conjunto de parmetros con valores que lo caracterizan. Estos parmetros son atributos y representan lo mismo que los campos de una tabla de una base de datos o las variables de un programa estructurado, por ejemplo: La edad de una persona El nombre de un animal La altura de un edificio La jornada de un trabajo El comportamiento de un objeto se forma por el conjunto de operaciones que se pueden realizar. Cada una de esas operaciones recibe el nombre de mtodo. Los mtodos podran ser: Dibujar un tringulo

Asignar laboratorio de trabajo a un grupo Prestar un libro de la biblioteca Cada objeto de una clase tiene sus propios atributos, que describen y caracterizan el estado en cada momento, y un conjunto de mtodos, sobre los cuales ejecuta las operaciones que manifiesta su comportamiento. El anlisis orientado a objetos (AOO) construye un modelo orientado a objetos y a las clases que se basan en la comprensin de los conceptos orientado a objetos (OO). El enfoque orientado a objetos permite que los objetos estn auto-contenidos. Los objetos existen por s mismos, con una funcionalidad para invocar comportamientos de otros objetos. Por definicin son modulares, es decir, pequeas unidades lgicas de cdigos independientes entre s que se comunican entre ellas mediante mensajes en su construccin. Esto quiere decir que son entidades completas y, por lo tanto, tienden a ser altamente reutilizables. Las aplicaciones orientadas a objetos se constituyen sobre el paradigma de los mensajes a otros objetos. Por lo general la mayora de los programadores desarrolla sobre un lenguaje y solo utiliza su propio estilo de programacin. Desarrollan sobre un paradigma forzado por el lenguaje que utilizan, tienden a no enfrentarse a mtodos alternativos de resolucin de un problema y como resultado se presentan con la dificultad de ver las ventajas de elegir un estilo ms apropiado al problema a manejar. Autores como Bobrow y Stefik (1986, citados en Booch-Grady, 1996) sugieren que existen cuatro clases de estilo de programacin: 1 Orientada a procedimientos (Algoritmos). 2 Orientada a objetos (Clases y objetos). 3 Orientada a la lgica (Expresado en clculo de predicados). 4 Orientada a reglas (Reglas if-Then). Anlisis y diseo orientado a objetos (ADOO) es un enfoque de la ingeniera de software que modela un sistema como un grupo de objetos que interactan entre s. Este enfoque representa un dominio en trminos de conceptos compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional. En este mtodo de anlisis y diseo se crea un conjunto de modelos utilizando una notacin acordada, como por ejemplo, el lenguaje unificado de modelado (UML). ADOO aplica tcnicas de modelado de objetos para analizar los requerimientos en un contexto (un sistema de negocio, un conjunto de mdulos de software) y para disear una solucin para mejorar los procesos involucrados. Este mtodo no est restringido al diseo de programas de computadora, sino que cubre sistemas enteros de distinto tipo. Las metodologas de anlisis y diseo ms modernas son casos de uso guiados a travs de requerimientos, diseo, implementacin, pruebas, y despliegue. El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estndar usado en anlisis y diseo orientado a objetos. Las estrategias que se utilizan para hacer un correcto desarrollo orientado a objetos son: anlisis, diseo y programacin. En el anlisis se consideran las actividades que hay que hacer para desarrollar un programa OO y se identifican los objetos, transformndolos en entidades y operaciones para asociarlos con el problema a resolver. En el diseo, los objetos se relacionan con la solucin del problema. Finalmente, en la programacin se hace la codificacin del problema en algn lenguaje con orientacin a objetos.

1.1.2. CaractersticasEl modelo AOO se basa en el concepto de objeto. Un objeto que tiene estado, comportamiento e identidad. La estructura y el comportamiento de los objetos son similares y estn definidos en su clase comn.

De tal modo, los sistemas deben estar funcionando siempre de manera correcta, su complejidad a veces es tan grande que el mismo ser humano o su capacidad intelectual se ve excedida, por lo que resulta imposible comprenderlo en su totalidad por una sola persona. As, el software es complejo de forma innata, es una caracterstica esencial de l. Es complejo porque hereda la complejidad del problema, la dificultad de gestionar el proceso de desarrollo, la flexibilidad que se puede alcanzar a travs del software y los problemas que plantea: 0 1. El problema presenta tantos requisitos que compiten entre s o se contradicen, y esas contradicciones existen porque los usuarios no saben expresar sus necesidades 0 de forma clara para que las otras personas que participan en el proyecto lo puedan entender. 1 2. Los requisitos, adems, son cambiados con frecuencia durante el desarrollo, incluso porque la mera existencia de un proyecto de solucin altera al sistema real. 2 3. Un sistema grande, debido a la inversin financiera que implica, no puede desecharse y reemplazarse por uno nuevo cada vez que los requisitos cambian, debe evolucionar, considerando: Evolucin del software: responder al cambio de requerimientos. Mantenimiento del software: corregir errores. Conservacin del software: emplear recursos para mantener en operacin un elemento de software anticuado y decadente. 0 4. La principal tarea del grupo de desarrollo es dar una ilusin de simplicidad para los usuarios de esta complejidad arbitraria del problema, se hace lo posible por escribir menos cdigo pero a veces es imposible y ms en un sistema tan grande, por lo que se debe recurrir a la aplicacin de varias tcnicas de re-utilizacin de cdigo existente. 1 5. Debe tambin enfrentarse la existencia de miles de mdulos separados y esto implica un grupo de desarrolladores, nunca una nica persona. 2 6. Un proyecto de software es muy frecuentemente apoyado en pilares construidos por los mismos desarrolladores, por lo que el desarrollo del proyecto de software sigue siendo una tarea muy laboriosa. 3 7. En algunos sistemas, una pequea modificacin en la entrada provoca una pequea modificacin en la salida. Mientras que en otros, y sobre todo de gran tamao, se percibe una explosin combinatoria que hace que la salida se modifique enormemente. 4 8. Se intenta disear los sistemas con una separacin de intereses, de forma que el comportamiento de una parte del sistema tenga el mnimo impacto en el comportamiento de otra parte del sistema. 5 9. En un sistema de gran volumen, uno debe contentarse con un grado de confianza determinado a lo que refiere su correccin, ya que no puede llevarse a cabo una prueba a fondo exhaustiva por no tener las herramientas matemticas ni intelectuales para un sistema no continuo. 6 10. Las consecuencias de la complejidad ilimitada. Mientras ms complejo es el sistema, ms abierto est al derrumbamiento total. 7 11. Crisis del software: ha existido tanto tiempo que debe considerarse normal. Es cuando se pretende dominar la complejidad del sistema a un extremo que lleva al presupuesto a niveles excedentes y que transforman en deficiente al sistema respecto a los requerimientos fijados.

1.1.3. VentajasLos beneficios del enfoque OO, de acuerdo con Booch-Grady (1996), son:

1

Primero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos los lenguajes de programacin basados en objetos y los orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada y recientemente Java. 2 Segundo, el uso del modelo OO alienta el re-uso no solo del software, sino de diseos completos. 3 Tercero, produce sistemas que estn construidos en formas intermedias estables y por ello son ms resistentes al cambio en especificaciones y tecnologa. Se considera que el principal beneficio del AOO, es que da un esquema para formalizar el modelo real. El anlisis orientado a objetos (AOO) es un mtodo de anlisis que examina los requerimientos desde la perspectiva de las clases y objetos encontrados en el vocabulario del dominio del problema. El diseo orientado a objetos es un mtodo de diseo que abarca el proceso de descomposicin orientado a objetos y una notacin para representar ambos modelos (lgico y fsico), como los modelos estticos y dinmicos del sistema bajo diseo. Dentro de las metodologas del anlisis y diseo orientado a objetos, hay una variedad de mtodos en la actualidad. Muchos de los mtodos pueden ser clasificados como orientados a objetos porque soportan de manera central los conceptos de la orientacin a objetos. Algunas de las metodologas ms conocidas y estudiadas hasta antes de UML (Jacobson 1996, citado en Booch-Grady, 1996) son:

METODOLOGA Diseo orientado a objetos (DOO) Tcnica de modelado de objetos (TMO) Anlisis orientado a objetos (AOO) Jerarqua de diseo orientada a objetos (JDOO) Diseo estructurado orientado a objetos (DEOO) Anlisis de sistemas orientado a objetos (ASOO)

AUTOR Grady Booch Rumbaugh Coad/Yourdon ESA Wasserman Shaler y Mellor, entre otros

Actualmente las metodologas ms importantes de anlisis y diseo de sistemas orientados a objetos se han basado en lo que es el UML, bajo el respaldo del Grupo Administrador de objetos. El modelo de objetos ha demostrado ser aplicable a una amplia variedad de dominios de problema. Hoy en da, el ADOO puede que sea el nico mtodo que logre emplearse para atacar la complejidad innata de muchos sistemas grandes. Sin embargo, puede no ser aconsejable en dominios, no por razones tcnicas sino por cuestiones como falta de personal con entrenamiento adecuado o buenos entornos de desarrollo. Lo interesante de la Programacin Orientada a Objetos (POO) es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible.

Actividad 2. Caractersticas y ventajas de la programacin OOCon el fin de reflexionar sobre la importancia de hacer un adecuado anlisis y diseo previo para realizar un buen programa, tomando en cuenta los temas abordados, realiza lo que se te pide a continuacin: 1. Retoma los conceptos desarrollados hasta ahora. 2. Identifica las diferencias entre anlisis, diseo y programacin orientada a objetos. 3. Ingresa al foro y realiza lo que en l se te pide.

1.2. Identificacin y conceptos bsicos de modelos orientados a objetosEl anlisis orientado a objetos es una forma de hacer frente a la comprensin y solucin de problemas, usando modelos a partir de conceptos. La pieza fundamental es el objeto, el cual se combina en una sola entidad. Para dar nfasis sobre los conceptos en el anlisis orientado a objetos, a continuacin se detallan los ms bsicos o utilizados con mayor frecuencia. Objeto: Es una entidad bien definida, real o abstracta, que tiene sentido sobre el contexto de alguna aplicacin y un papel bien definido. A su vez se puede diferenciar en dos tipos: 1 Concretos: Ejemplo de objetos concreto, una unidad de almacenamiento, un archivo de computadora, un automvil, un profesor 2 Conceptuales: Ejemplo de objetos conceptuales, un programa de computadora, una variable de programacin, un pensamiento. Atributo: Es un valor atribuido a un objeto, por ejemplo un alumno es un objeto y sus atributos podran ser su nmero de control, su nombre y su calificacin. Se entiende que se pueden llegar a tener ms atributos, pero si el contexto de la aplicacin es solo obtener un resultado especfico, los atributos sern los nicos que son relevantes para esa aplicacin. Comportamiento: Es el conjunto de cada accin o transformacin que el objeto ejecuta, tambin podra ser llamado operacin y mtodo. Por ejemplo, para el objeto alumno se requiere de algunas acciones y transformaciones: asignar calificacin, leer nombre y leer nmero de control; estas acciones representan el comportamiento del objeto alumno. En el caso de asignar calificacin, leer nombre y leer nmero de control, se refieren a transformaciones, ya que modificarn el valor de la calificacin final. Identificacin: Cada objeto posee una identificacin mediante la cual se puede hacer alusin a l de modo exclusivo. Clase: describe propiedades importantes para una aplicacin y que ignora el resto. La seleccin de clases es arbitraria y depende de la aplicacin. Instancia: Se considera que cada objeto es una instancia de su clase. Toda clase describe un conjunto posiblemente finito de objetos individuales. Identidad. Se refiere a que cada objeto conserva de manera inherente su propia identidad. O sea, 2 objetos son distintos an si el valor de todos sus atributos es idntico. Por ejemplo, los 8 peones negros de un juego de ajedrez, son todos negros, tienen las mismas dimensiones, textura, pero todos son diferentes, existen y tienen su propia identidad. Dos gotas de agua es otro ejemplo de la caracterstica de identidad de los objetos. Clasificacin. Se refiere a que los objetos con los mismos atributos y comportamiento mtodos-, son agrupados en clases. Cada objeto perteneciente a una clase, se dice que es una instancia de la clase. As que una clase, representa a un posible conjunto infinito de objetos individuales. Por ejemplo a todos los alumnos que aparecern en la lista de calificaciones finales, los clasificamos en la clase Alumno. A todos los amigos que registramos en nuestra agenda, los podemos clasificar en la clase Persona.

(Kendall, 2005 y Booch-Grady, 1996)

1.2.1. AbstraccinEn la abstraccin la mente humana modela la realidad en forma de objetos. Para ello busca semejanzas entre la realidad y la posible implementacin de objetos del programa que simulen el funcionamiento de los objetos reales. Los humanos entendemos la realidad como objetos ya definidos y no como un conjunto de situaciones menores que se unen para dar forma a algo. No es necesario conocer detalles del cmo, cundo, donde o por qu las cosas, solamente necesitamos saber que cuando queremos caminar lo haremos y punto. Es la caracterizacin de un objeto de acuerdo a las propiedades que nos interesen en un instante de tiempo. Las caractersticas escogidas son relativas a la perspectiva del observador.

3

1.2.2. EncapsulamientoCuando un objeto es encapsulado tenemos la libertad de saber qu informacin se hace pblica o no, para ello podemos hacer privados e inaccesibles los datos de este objeto a travs otro previamente publicado. Con esto logramos que los datos solo sean utilizados por su interfaz dejando de lado cmo est implementada, haciendo as, ms fcil la utilizacin del mismo. As pues, la manera de ocultar los detalles de la representacin interna de un objeto es presentando solo la interface para el usuario.

4

1.2.3. ModularidadA travs de la modularidad, se propone al programador dividir su aplicacin en varios mdulos diferentes (ya sea en forma de clases, paquetes o bibliotecas), cada uno de ellos con un sentido propio. Esta fragmentacin disminuye el grado de dificultad del problema al que da respuesta el programa, pues se afronta ste como un conjunto de problemas de menor dificultad, adems de facilitar la comprensin del programa.

1.2.4. HerenciaLa herencia se base en la capacidad para reflejar la abstraccin que realiza automticamente y se refiere a compartir atributos y mtodos entre objetos que se relacionan de manera jerrquica durante un proceso de anlisis de informacin. Se percibe en la realidad como un agregado de objetos relacionados. Estas interrelaciones, pueden verse como un conjunto de generalizaciones que se asimilan con el tiempo. As pues, la herencia es el mecanismo fundamental de relacin entre clases en la orientacin a objetos. Del mismo modo, las distintas clases de un programa se organizan mediante la jerarqua. La representacin de dicha organizacin da lugar a los denominados rboles de herencia:

La capacidad de descomponer un problema o concepto en un conjunto de objetos relacionados entre s, y cuyo comportamiento es fcilmente identificable, puede ser muy til para el desarrollo de programas informticos. Del mismo modo, Relaciona las clases de manera jerrquica; una clase padre o superclase sobre otras clases hijas o subclases.

1.2.5. PolimorfismoMediante el denominado paso de mensajes, un objeto puede solicitar de otro objeto que realice una accin determinada o que modifique su estado. El paso de mensajes se suele implementar como llamadas a los mtodos de otros objetos. Desde el punto de vista de la programacin estructurada, esto correspondera con la llamada a funciones (Garca, s/f: 1) Ahora bien, el polimorfismo es una caracterstica de la orientacin a objetos, que significa que un mismo mtodo puede tener diferente manera de realizarse, en las diferentes clases que haya bajo estudio. Cada objeto perteneciente a una clase y sabe cmo ejecutar sus propios mtodos. Cuando se programa orientado a objetos, el lenguaje de programacin automticamente selecciona el mtodo correcto para efectuar una cierta accin o transformacin sobre el objeto al que se aplica. Por ejemplo, si tenemos los objetos bicicleta, carro, barco y les aplicamos la operacin Mover, la accin se ejecuta de manera diferente para cada objeto. Otro ejemplo tpico

es el de los objetos de la clase Figura, digamos crculo, rectngulo, tringulo, apliqumosles la accin de Dibujar, cada uno de ellos tendr su propio mtodo Dibujar definido, ya que la accin debe implementarse de manera diferente para cada objeto.

Actividad 3. Ejemplos de sistemasEsta actividad tiene como finalidad distinguir, en un primer acercamiento, cada uno de los modelos del ciclo de vida del software. Realiza lo siguiente: 1. En un archivo de texto, realiza ejemplos de sistemas que un cliente pudiera necesitar (por ejemplo, un sistema que controle una zapatera) y describe qu hara en cada una de las etapas en los ciclos cascada y espiral incremental. Ejemplo: Modelo de ciclo de vida de Etapa Descripcin zapatera Espiral Planificacin En esta etapa en la zapatera se va a

2. Guarda tu actividad con la nomenclatura DOO_U1_A3_XXYZ. 3. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

1.3. Ciclo de vida del software y tipos de ciclosLa metodologa para el desarrollo de software tiene pasos establecidos en la realizacin y administracin de un proyecto para llevarlo a cabo con xito. Para facilitar esto, se debe dividir un gran proyecto en mdulos ms pequeos llamados etapas. Las acciones que corresponden en cada una de ellas ayudan a definir entradas y salidas para cada una de las etapas y sobre todo, normaliza el modo en que administraremos el proyecto.

1.3.1. DefinicinLlevar a cabo la metodologa para el desarrollo del software requiere seguir puntualmente una serie de pasos o procesos para analizar, disear y realizar un producto software, desde que surge la necesidad hasta que cumplimos el objetivo por el cual fue creado. Desde un punto de vista puede considerarse que el ciclo de vida de un software tiene capas claramente diferenciadas: 1 Planificacin: planteamiento detallado que los pasos a seguir durante el desarrollo del proyecto, considerando aspectos de tiempo y dinero. 2 Implementacin: decidir las actividades que componen la realizacin del producto.

1

Produccin: EL proyecto es presentado al cliente o usuario final, sabiendo que funciona correctamente y responde a los requerimientos solicitados en su momento.

1.3.2. EspiralEste ciclo de vida puede considerarse una variacin del modelo prototpico que fue diseado por Boehm en el ao 1988 (citado en Kendall, E., 2005). El modelo se basa en una serie de ciclos repetitivos para ir ganando madurez en el producto final. Conforme se va desarrollando el sistema se hace un primer prototipo se presenta al cliente y sobre este se hacen adecuaciones y nuevos prototipos as se tiene un avance en espiral hasta llegar a la perfeccin de todas las funcionalidades o mdulos. En este modelo hay cuatro actividades principales para las etapas: 1 Planificacin: Relevamiento de requerimientos iniciales o luego de una iteracin. 2 Anlisis del riesgo: De acuerdo con el relevamiento de requerimientos decidimos si continuamos con el desarrollo. 3 Implementacin: Desarrollamos un prototipo basado en los requerimientos. 4 Evaluacin: El cliente evala el prototipo, si da su conformidad termina el proyecto. En caso contrario incluimos los nuevos requerimientos solicitados por el cliente en la siguiente iteracin.

1.3.3. CascadaEl primer modelo de proceso de desarrollo de software que se public, se deriv de

procesos de ingeniera de sistemas ms generales (Royce, 1970, citado en Sommerville, I. 2005). A continuacin se ve cmo de un diseo previo se deriva otro, dando as su nombre a Cascada. Cayendo de una a otra, las etapas de este modelo se transforman en actividades fundamentales de desarrollo: 1. Anlisis y definicin de requerimientos. Los servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. 2. Diseo del sistema y del software. El proceso de diseo del sistema divide los requerimientos en sistemas hardware o software. 3. Implementacin y prueba de unidades. Durante esta etapa, el diseo del software se lleva a cabo como un conjunto o unidades de programas. 4. Integracin y prueba del sistema. Los programas o las unidades individuales de programas se integran y prueban como un sistema completo para asegurar que se cumplan los requerimientos del software. 5. Funcionamiento y mantenimiento. Por lo general (aunque no necesariamente), esta es la fase ms larga del ciclo de vida. El sistema se instala y se pone en funcionamiento prctico. El mantenimiento implica corregir errores.

1.3.4. IncrementalEste modelo est basado en varios ciclos Cascada realimentados aplicados repetidamente, es decir que va incrementando las funcionalidades del programa. Se realiza construyendo por mdulos que cumplen las diferentes funciones del sistema, lo que permite ir aumentando gradualmente las capacidades del software. Desarrollar un mdulo o mdulos por separado resulta excelente modelo cuando es desarrollado por varios programadores.

El modelo de ciclo de vida incremental nos genera algunos beneficios como: 1 Construir un sistema pequeo siempre es menos riesgoso que construir un sistema grande. 2 Como desarrollamos independientemente las funcionalidades, es ms fcil relevar los requerimientos del usuario. 3 Si se detecta un error grave solo se desecha la ltima iteracin.

No es necesario disponer de los requerimientos de todas las funcionalidades en el comienzo del proyecto y adems facilita la labor del desarrollo con la conocida filosofa de divide y vencers Este modelo de ciclo de vida no est pensado para cierto tipo de aplicaciones, sino que est orientado a cierto tipo de usuario o cliente.

1

Actividad 4. Conceptos bsicos de los modelos Orientados a objetosCon el fin de distinguir cada uno de los conceptos bsicos de la programacin orientada a objetos, en esta actividad debes proponer ejemplos que hagan referencia a cada uno de ellos: abstraccin, encapsulamiento, polimorfismo, modularidad, herencia, jerarqua y paso de mensajes. Con base en lo anterior, realiza lo que a continuacin se te pide: 1. En un archivo de texto, anota el nombre de cada concepto bsico de los sistemas orientados a objetos. 2. De acuerdo con la definicin que se revis en los temas anteriores, inventa un ejemplo de la vida diaria que se apegue a cada uno de ellos. 3. Guarda tu actividad con la nomenclatura DOO_U1_A4_XXYZ. 4. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

AutoevaluacinPara reforzar los conocimientos relacionados con los temas que se abordaron en esta primera unidad del curso, es necesario que resuelvas la autoevaluacin de la unidad. Recuerda que es muy importante leer cuidadosamente los planteamientos indicados y elegir la opcin adecuada para cada uno.

Evidencia de aprendizaje. Mapa mental de los modelos orientados a objetosComo parte de la evaluacin de esta unidad, llevars a cabo esta actividad cuyo propsito es organizar los conceptos abordados a lo largo de la unidad con la finalidad de tener presente las definiciones revisadas. Realiza lo siguiente: 1. En un archivo de texto o Microsoft Visio, crea un mapa mental con las definiciones de los temas tratados durante la presente unidad. Recuerda que un mapa mental contiene cuadros de texto, lneas que representan uniones entre ellos e imgenes que pueden substituir textos. 2. Consulta la Escala de evaluacin. 3. Guarda tu evidencia con la nomenclatura DOO_U1_EA_XXYY. 4. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin. Recuerda que puedes volver a enviar tu archivo tomando en cuenta las observaciones de tu Facilitador(a). Adems de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses al foro Preguntas de Autorreflexin y consultes las preguntas que tu Facilitador(a) presente, a partir de ellas, debes elaborar tu Autorreflexin en un archivo de texto llamado DOO_U1_ATR_XXYZ. Posteriormente enva tu archivo mediante la herramienta Autorreflexiones.

Cierre de la unidadHas concluido la primera unidad del curso. A lo largo de sta se revisaron conceptos generales sobre el anlisis orientado a objetos, su definicin, caractersticas y ventajas. Posteriormente identificaste los conceptos bsicos de los modelos orientados a objetos, tales como abstraccin, encapsulamiento, modularidad, herencia y polimorfismo, cuyo propsito fue dar un panorama para identificar un modelo orientado a objetos. De la misma manera, se identificaron los ciclos de vida del software y los tipos de ciclos que existen al disear un sistema orientado a objetos. Es aconsejable que revises nuevamente la unidad en caso de que los temas que se

acaban de mencionar no te sean familiares o no los recuerdes, de no ser este tu caso, ya ests preparado(a) para seguir con la unidad 2, en donde abordars los requerimientos para el anlisis del diseo orientado a objetos, realizars levantamientos de requerimientos y la documentacin necesaria, teniendo en cuenta los estndares que deben cumplir y los tipos de modelos para el desarrollo de software.

Para saber msSi deseas saber ms acerca de la programacin orientada a objetos, visita las siguientes direcciones electrnicas: 1 I.1. INTRODUCCIN A LA PROGRAMACIN ORIENTADA A OBJETOS: http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/ 2 Programacin orientada a objetos: http://zarza.usal.es/~fgarcia/doc/tuto2/I_1.htm

Fuentes de consultaBibliografa bsica 1 Booch-Grady (1996). Anlisis y Diseo Orientado a Objetos con Aplicaciones. Mxico: Pearson Educacin. 2 Kendall, E. (2005). Anlisis y Diseo de Sistemas. Mxico: Pearson Educacin. 3 Seen, J. (1990). Anlisis y Diseo de Sistemas de Informacin. Mxico: Mc Graw Hill. Bibliografa complementaria 1 Ciberaula (2010). Programacin orientada a objetos. Recuperado el 10 de octubre de 2011 de: http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/ 2 Coad, P. y Yourdon, E. (1990). Object Oriented Programming. USA: Yourdon Press. 3 Fowler, M. y Kendall, S. (2000). UML Gota a gota. Mxico: Prentice-Hall. 4 Fernndez, S. (1995). Fundamentos del diseo y la programacin orientada a objetos. Mxico: McGraw Hill. 5 Garca, F. (s/f). I.1. Introduccin a la programacin orientada a objetos. Recuperado el 10 de octubre de 2011 de: http://zarza.usal.es/~fgarcia/doc/tuto2/I_1.htm 6 Microsoft Autorized Academic (2010). Principles of Components Desing 1518. USA: Microsoft. 7 Sommerville, I. (2005). Ingeniera del Software. Mxico: Pearson Educacin.

Ingeniera en Desarrollo de Software Cuatrimestre 04 Programa de la asignatura: Anlisis y diseo orientado a objetos Unidad 2. Requerimientos para el anlisis del diseo orientado a objetos Clave: 160920413 / 150920413

ndice Unidad 2. Requerimientos para el anlisis del diseo orientado a objetos ......................... 3 Presentacin de la unidad ........................................................................................................... 3 Propsito .................................................................................................................. ..................... 4 Competencia especfica .............................................................................................................. 4 2.1. Levantamiento de requerimientos ...................................................................................... 5 2.1.1. Introduccin a los requerimientos ................................................................................... 5 2.1.2. Actividades para el levantamiento de requerimientos ................................................. 6 Actividad 1. Anlisis y diseo en un programa orientado a Objetos .................................... 7 2.2. Documentacin para levantamientos y especificaciones ............................................... 7 2.2.1. Documentacin .................................................................................................................. 8 2.2.2. Especificaciones ................................................................................................................ 9 2.3. Estndares de especificacin ............................................................................................. 9 2.3.1. Fases de la estandarizacin .......................................................................................... 10 2.3.2. Anlisis de restricciones ................................................................................................. 11 Actividad 2. Requerimientos para disear un programa ...................................................... 11 2.4. Modelos del desarrollo del software ................................................................................ 12 2.4.1. giles ................................................................................................................................ 13 2.4.2. Predictivos ........................................................................................................................ 14 Actividad 3. Listado de caractersticas de los modelos giles y predictivos ..................... 15 Autoevaluacin .......................................................................................................... ................. 16 Evidencia de aprendizaje. Requerimientos para disear un programa con O O ............. 16 Cierre de la unidad ..................................................................................................................... 17 Fuentes de consulta

................................................................................................................... 17

Unidad 2. Requerimientos para el anlisis del diseo orientado a objetos Presentacin de la unidadEl trabajo de ir detallando la definicin de un problema en forma de requisitos se realiza de manera repetitiva, progresiva, incremental. Por un lado, supone la planificacin, realizacin y evaluacin de las entrevistas con los clientes y usuarios finales del sistema, que son los portadores de la informacin necesaria para conocer el problema y definir el proyecto. Por otro lado, supone la identificacin y descomposicin reiterada (hasta el nivel de detalle que en cada caso sea necesario) de los problemas y necesidades expresados por el cliente y los usuarios, para as ir redactando un conjunto de requisitos formales. Principalmente, se utiliza la siguiente tcnica: Entrevista. Es una conversacin dirigida por objetivos entre un entrevistador, miembro del equipo de desarrollo, y un entrevistado, que suele ser el cliente o un usuario final. Es importante crear desde el principio un clima de cordialidad y confianza, atendiendo siempre a las opiniones del entrevistado. l es nuestra fuente de informacin principal y de la relacin que establezcamos depende la facilidad o dificultad para conocer sus necesidades. Es bueno tener en cuenta que a veces surgen dificultades y mal entendidos; la resistencia al cambio, usuarios que ven el nuevo sistema como una amenaza para su futuro trabajo, expertos reticentes a compartir conocimientos. Durante la realizacin de una entrevista lo habitual es la toma de notas, para redactar ms tarde el informe de evaluacin de la misma. Para la grabacin en audio o en video es preceptivo el permiso expreso del entrevistado, siendo conveniente tener en cuenta si esto va a interferir en la entrevista, hacindole sentir incmodo. Pese a su costo, se va generalizando el uso de videoconferencias para la realizacin de entrevistas remotas, con la consiguiente comodidad para ambas partes. Toda entrevista requiere de una preparacin previa: establecer los objetivos, seleccionar al entrevistado, concertar la cita, hacer lectura de antecedentes, proporcionar y pedir documentacin, elegir el tipo de preguntas para finalmente utilizar la informacin recabada

para lograr los fines. Segn el tipo de preguntas, existen diferentes clases de entrevista: 1 Inductiva: se comienza con preguntas cerradas, para ir pasando, a lo largo de la entrevista, hacia preguntas abiertas.

Unidad 2. Requerimientos para el anlisis del diseo orientado a objetos Presentacin de la unidadEl trabajo de ir detallando la definicin de un problema en forma de requisitos se realiza de manera repetitiva, progresiva, incremental. Por un lado, supone la planificacin, realizacin y evaluacin de las entrevistas con los clientes y usuarios finales del sistema, que son los portadores de la informacin necesaria para conocer el problema y definir el proyecto. Por otro lado, supone la identificacin y descomposicin reiterada (hasta el nivel de detalle que en cada caso sea necesario) de los problemas y necesidades expresados por el cliente y los usuarios, para as ir redactando un conjunto de requisitos formales. Principalmente, se utiliza la siguiente tcnica: Entrevista. Es una conversacin dirigida por objetivos entre un entrevistador, miembro del equipo de desarrollo, y un entrevistado, que suele ser el cliente o un usuario final. Es importante crear desde el principio un clima de cordialidad y confianza, atendiendo siempre a las opiniones del entrevistado. l es nuestra fuente de informacin principal y de la relacin que establezcamos depende la facilidad o dificultad para conocer sus necesidades. Es bueno tener en cuenta que a veces surgen dificultades y mal entendidos; la resistencia al cambio, usuarios que ven el nuevo sistema como una amenaza para su futuro trabajo, expertos reticentes a compartir conocimientos. Durante la realizacin de una entrevista lo habitual es la toma de notas, para redactar ms tarde el informe de evaluacin de la misma. Para la grabacin en audio o en video es preceptivo el permiso expreso del entrevistado, siendo conveniente tener en cuenta si esto va a interferir en la entrevista, hacindole sentir incmodo. Pese a su costo, se va generalizando el uso de videoconferencias para la realizacin de entrevistas remotas, con la consiguiente comodidad para ambas partes. Toda entrevista requiere de una preparacin previa: establecer los objetivos, seleccionar al entrevistado, concertar la cita, hacer lectura de antecedentes, proporcionar y pedir documentacin, elegir el tipo de preguntas para finalmente utilizar la informacin recabada para lograr los fines. Segn el tipo de preguntas, existen diferentes clases de entrevista: 2 Inductiva: se comienza con preguntas cerradas, para ir pasando, a lo largo de la entrevista, hacia preguntas abiertas.

Unidad 2. Requerimientos para el anlisis del diseo orientado a objetos Presentacin de la unidadEl trabajo de ir detallando la definicin de un problema en forma de requisitos se realiza de manera repetitiva, progresiva, incremental. Por un lado, supone la planificacin, realizacin y evaluacin de las entrevistas con los clientes y usuarios finales del sistema, que son los portadores de la informacin necesaria para conocer el problema y definir el proyecto. Por otro lado, supone la identificacin y descomposicin reiterada (hasta el nivel de detalle que en cada caso sea necesario) de los problemas y necesidades expresados por el cliente y los usuarios, para as ir redactando un conjunto de requisitos formales. Principalmente, se utiliza la siguiente tcnica: Entrevista. Es una conversacin dirigida por objetivos entre un entrevistador, miembro del equipo de desarrollo, y un entrevistado, que suele ser el cliente o un usuario final. Es importante crear desde el principio un clima de cordialidad y confianza, atendiendo

siempre a las opiniones del entrevistado. l es nuestra fuente de informacin principal y de la relacin que establezcamos depende la facilidad o dificultad para conocer sus necesidades. Es bueno tener en cuenta que a veces surgen dificultades y mal entendidos; la resistencia al cambio, usuarios que ven el nuevo sistema como una amenaza para su futuro trabajo, expertos reticentes a compartir conocimientos. Durante la realizacin de una entrevista lo habitual es la toma de notas, para redactar ms tarde el informe de evaluacin de la misma. Para la grabacin en audio o en video es preceptivo el permiso expreso del entrevistado, siendo conveniente tener en cuenta si esto va a interferir en la entrevista, hacindole sentir incmodo. Pese a su costo, se va generalizando el uso de videoconferencias para la realizacin de entrevistas remotas, con la consiguiente comodidad para ambas partes. Toda entrevista requiere de una preparacin previa: establecer los objetivos, seleccionar al entrevistado, concertar la cita, hacer lectura de antecedentes, proporcionar y pedir documentacin, elegir el tipo de preguntas para finalmente utilizar la informacin recabada para lograr los fines. Segn el tipo de preguntas, existen diferentes clases de entrevista: 3 Inductiva: se comienza con preguntas cerradas, para ir pasando, a lo largo de la entrevista, hacia preguntas abiertas.

Unidad 2. Requerimientos para el anlisis del diseo orientado a objetos Presentacin de la unidadEl trabajo de ir detallando la definicin de un problema en forma de requisitos se realiza de manera repetitiva, progresiva, incremental. Por un lado, supone la planificacin, realizacin y evaluacin de las entrevistas con los clientes y usuarios finales del sistema, que son los portadores de la informacin necesaria para conocer el problema y definir el proyecto. Por otro lado, supone la identificacin y descomposicin reiterada (hasta el nivel de detalle que en cada caso sea necesario) de los problemas y necesidades expresados por el cliente y los usuarios, para as ir redactando un conjunto de requisitos formales. Principalmente, se utiliza la siguiente tcnica: Entrevista. Es una conversacin dirigida por objetivos entre un entrevistador, miembro del equipo de desarrollo, y un entrevistado, que suele ser el cliente o un usuario final. Es importante crear desde el principio un clima de cordialidad y confianza, atendiendo siempre a las opiniones del entrevistado. l es nuestra fuente de informacin principal y de la relacin que establezcamos depende la facilidad o dificultad para conocer sus necesidades. Es bueno tener en cuenta que a veces surgen dificultades y mal entendidos; la resistencia al cambio, usuarios que ven el nuevo sistema como una amenaza para su futuro trabajo, expertos reticentes a compartir conocimientos. Durante la realizacin de una entrevista lo habitual es la toma de notas, para redactar ms tarde el informe de evaluacin de la misma. Para la grabacin en audio o en video es preceptivo el permiso expreso del entrevistado, siendo conveniente tener en cuenta si esto va a interferir en la entrevista, hacindole sentir incmodo. Pese a su costo, se va generalizando el uso de videoconferencias para la realizacin de entrevistas remotas, con la consiguiente comodidad para ambas partes. Toda entrevista requiere de una preparacin previa: establecer los objetivos, seleccionar al entrevistado, concertar la cita, hacer lectura de antecedentes, proporcionar y pedir documentacin, elegir el tipo de preguntas para finalmente utilizar la informacin recabada para lograr los fines. Segn el tipo de preguntas, existen diferentes clases de entrevista: 4 Inductiva: se comienza con preguntas cerradas, para ir pasando, a lo largo de la entrevista, hacia preguntas abiertas.

Figura 2.1. Modelos. En la fase de anlisis se pretende que los modelos (de procesos, de datos y de eventos) estn lo suficientemente detallados sin llegar a descender al diseo. El anlisis tiene por objetivo entender el problema: las necesidades del cliente, las restricciones que se deben cumplir. El diseo pretende obtener una solucin ptima que cumpla todos los requisitos. Se orienta hacia la mquina, centrndose en cmo crear un sistema software que rena todas las necesidades y cumpla todas las restricciones.

2.1.2. Actividades para el levantamiento de requerimientosEl levantamiento de requerimientos incluye tres tipos de actividad: Figura 2.1. Modelos. En la fase de anlisis se pretende que los modelos (de procesos, de datos y de eventos) estn lo suficientemente detallados sin llegar a descender al diseo. El anlisis tiene por objetivo entender el problema: las necesidades del cliente, las restricciones que se deben cumplir. El diseo pretende obtener una solucin ptima que cumpla todos los requisitos. Se orienta hacia la mquina, centrndose en cmo crear un sistema software que rena todas las necesidades y cumpla todas las restricciones. iii. Manejo de excepciones 6. Anlisis de alternativas a. Descripcin de la alternativa 1 b. Descripcin de la alternativa 2 c. Descripcin detallada de la alternativa seleccionada i. Modelo lgico de procesos ii. Anlisis costo-beneficio iii. Diferencias significativas con las dems alternativas 7. Apndices (si es necesario)

2.2.1. DocumentacinLa documentacin de los requerimientos, es una de la parte importante durante en el anlisis. En la prctica es comn describir los requerimientos en un documento, llamado especificacin de requerimientos del software, su principal objetivo es de comunicar de forma efectiva los requerimientos, objetivos del dominio. En primera instancia la documentacin contiene la informacin que aporta el cliente que encarga la aplicacin, contiene todos los registros de las reuniones de trabajo del grupo de anlisis. Documentos bsicos de anlisis orientado a objetos: 1 Documentos de anlisis 2 Especificacin de requisitos o requerimientos 3 Diagramas de casos de uso

4 5

Escenarios y sub-escenarios Prototipos y su evaluacin

Todos los documentos deben estar identificados y codificados. Identificacin Es necesario identificar todos los elementos del proceso de desarrollo de software de una forma nica. El ttulo debe reflejar de la mejor forma posible sus fines y su funcionalidad. Descripcin Autores Versin. Notacin decimal. Revisin. Autores Fecha Cdigo de cada documento o diagrama Documentos de anlisis Contiene la documentacin que aporta el cliente que encarga la aplicacin. Tambin contiene las actas de las reuniones de trabajo del grupo de anlisis, es necesario un secretario que tome acta y es necesario aprobar el acta de cada reunin por todos los miembros.

2.2.2. EspecificacionesExpresa las caractersticas esenciales de un objeto, las cuales distinguen al objeto uno de otro. A parte de distinguir los objetos tambin provee lmites conceptuales, permitiendo que se disponga de las caractersticas de un objeto que se necesite. El objetivo principal de las especificaciones, es en entregar una especificacin de requisitos que ayuden a determinar de forma completa y correcta el diseo orientado a objetos.

2.3. Estndares de especificacinLas especificaciones del software determina el proceso de comprensin y definicin sobre los servicios que se requieren del sistema y de identificacin de las restricciones de funcionamiento y desarrollo del mismo. La ingeniera de requerimientos es un proceso crtico en el proceso del software, los errores en esta etapa originan problemas posteriores en el diseo e implementacin del sistema. En la siguiente figura se muestra el proceso de ingeniera de requerimientos. ste conduce a la produccin de un documento de requerimientos, que es la especificacin del sistema. Normalmente en este documento los requerimientos se presentan en dos niveles de detalle. Los usuarios finales y los clientes necesitan una declaracin de alto nivel de los requerimientos, mientras que los desarrolladores del sistema necesitan una especificacin ms detallada de ste.

2.3.1. Fases de la estandarizacin

Existen cuatro fases principales en el proceso de estndares de ingeniera de requerimientos: 1. Estudio de viabilidad. Se estima si las necesidades del usuario se pueden satisfacer con las tecnologas actuales de software y hardware. El estudio analiza si el sistema propuesto ser rentable desde un punto de vista de negocios y si se puede desarrollar dentro de las restricciones de presupuesto existentes. Este estudio debe ser relativamente econmico de elaborar. EI resultado debe informar si se va a continuar con un anlisis ms detallado. 2. Obtencin y anlisis de requerimientos. Es el proceso de obtener los requerimientos del sistema por medio de la observacin de los sistemas existentes, discusiones con los usuarios potenciales y proveedores, el anlisis de tareas, etctera. Esto puede implicar el desarrollo de uno o ms modelos y prototipos del sistema que ayudan al analista a comprender el sistema a especificar. 3. Especificacin de requerimientos. Es la actividad de traducir la informacin recopilada durante la actividad de anlisis en un documento que define un conjunto de requerimientos. En este documento se pueden incluir dos tipos de requerimientos: los requerimientos del usuario, que son declaraciones abstractas de los requerimientos del cliente y del usuario final del sistema, y los requerimientos del sistema, que son una descripcin ms detallada de la funcionalidad a proporcionar. 4. Validacin de requerimientos. Esta actividad comprueba la veracidad, consistencia y completitud de los requerimientos. Durante este proceso, inevitablemente se descubren errores en el documento de requerimientos. Se debe modificar entonces para corregir estos problemas. Por supuesto, las actividades en el proceso de requerimientos no se llevan a cabo de forma estrictamente secuencial. El anlisis de requerimientos contina durante la definicin y especificacin, y a lo largo del proceso surgen nuevos requerimientos. Por lo tanto, las actividades de anlisis, definicin y especificacin se entrelazan. En los mtodos giles como la programacin extrema, los requerimientos se desarrollan de forma incremental conforme a las prioridades del usuario, y la obtencin de requerimientos viene de los usuarios que forman parte del equipo de desarrollo.

2.3.2. Anlisis de restriccionesLas restricciones son relaciones entre entidades de un modelo de objetos, el trmino de entidad, incluye los objetos, clases, atributos, enlaces y asociaciones. Una restriccin reduce los valores que una entidad puede tomar. 1 Restricciones entre objetos. Determina el estado en el cual los objetos se diferencian uno al otro, ejemplo: Horario de entrada de un empleado de oficina no puede ser despus de las 9:00, suponiendo que el horario de entrada al trabajo es a las 9:00. 2 Restricciones entre atributos de un objeto: Determina los atributos especficos de un objeto, ejemplo: El objeto alumno solo debe tener como atributos, nombre completo y no apellido paterno, apellido materno y nombre. 3 Restricciones sobre un objeto a lo largo del tiempo. Determina el estado del objeto donde especifica que nunca debe de cambiar su estado, ejemplo: El objeto alumno no puede aumentar su nmero de control. Las restricciones simples pueden situarse en el modelo de objetos, restricciones complejas aparecern en el modelo funcional. Las restricciones no tienen por qu aparecer inicialmente en el modelo de objetos, estas irn aadindose conforme se vaya concretando en la definicin del modelo.

Actividad 2. Requerimientos para disear un programaCon el fin de aplicar cada uno de los conceptos bsicos de los estndares de

especificaciones de un anlisis, disea un programa con orientacin a objetos haciendo un documento que sirva como base para conocer los requerimientos para disear el programa de un saln de belleza. 1 1. Plantea una situacin hipottica o pregunta al encargado(a) de un saln de belleza acerca de qu le gustara controlar por computadora (Obtencin y anlisis de requerimientos). 1 2. Con base en la informacin obtenida, en un archivo de texto escribe los requerimientos del usuario y del sistema (Especificacin de requerimientos).

1 1 1

3. Apunta si es viable o no (Validacin de requerimientos). 4. Guarda tu actividad con la nomenclatura DOO_U2_A2_XXYZ. 5. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

2.4. Modelos del desarrollo del softwareLas metodologas se centra en una serie de combinaciones de los modelos de proceso genricos (cascada, evolutivo, incremental, etc. Adicionalmente una metodologa debe definir con precisin los roles y actividades involucradas, junto con prcticas, guas de adaptacin. Habitualmente se utiliza el trmino mtodo para referirse a tcnicas, notaciones y guas asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de mtodos de anlisis y/o diseo. La comparacin y/o clasificacin de metodologas no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, informacin disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de anlisis y diseo, podemos clasificar las metodologas en dos grupos: Metodologas Estructuradas y Metodologas Orientadas a Objetos. Por otra parte, considerando su filosofa de desarrollo, aquellas metodologas con mayor nfasis en la planificacin y control del proyecto, en especificacin precisa de requisitos y modelado, reciben el apelativo de Metodologas Tradicionales (o peyorativamente denominada Metodologas Pesadas, o Peso Pesado). Otras metodologas, denominadas Metodologas giles, estn ms orientadas a la generacin de cdigo con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeos, hacen especial hincapi en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso. Los mtodos estructurados comenzaron a desarrollarse a fines de los 70s con la Programacin Estructurada, luego a mediados de los 70s aparecieron tcnicas primero para el Diseo (por ejemplo: el diagrama de Estructura) y posteriormente para el Anlisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologas son particularmente apropiadas en proyectos que utilizan para la implementacin lenguajes de 3ra y 4ta generacin. Ejemplos de metodologas estructuradas de mbito gubernamental: MERISE (Francia), MTRICA (Espaa), SSADM (Reino Unido). Ejemplos de propuestas de mtodos estructurados en el mbito acadmico: Gane & Sarson, Ward & Mellor, Yourdon & De Marco e Information Engineering. Metodologas orientadas a objetos, va unida a la evolucin de los lenguajes de programacin orientada a objeto, los ms representativos: a fines de los 60s SIMULA, a fines de los 70s Smalltalk-80, la primera versin de C++ por Bjarne Stroustrup en 1981 y actualmente Java o C# de Microsoft. A fines de los 80s comenzaron a consolidarse algunos mtodos Orientados a Objeto

En 1995 Booch y Rumbaugh proponen el Mtodo Unificado con la ambiciosa idea de conseguir una unificacin de sus mtodos y notaciones, que posteriormente se reorienta a un objetivo ms modesto, para dar lugar al Unified Modeling Language (UML), la notacin OO ms popular en la actualidad (Booch-Grady, 1996)). Algunos mtodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE (Jacobson), Coad&Yourdon, Shaler&Mellor y OMT (Rumbaugh). Algunas metodologas orientadas a objetos que utilizan la notacin UML son: Rational Unified Process (RUP), OPEN, MTRICA (que tambin soporta la notacin estructurada).

2.4.1. gilesNuevas tcnicas para aplicar las prcticas esenciales de la programacin extrema y mtodos giles para desarrollar sistemas orientados a objetos se encuentre la metodologa gil. Es cuando el desarrollo de software es incremental (entregas pequeas de software, con ciclos rpidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicacin), sencillo (el mtodo en s mismo es fcil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de ltimo momento) El modelado gil tambin abarca un conjunto de principios esenciales. Adems delos principios esenciales de la programacin extrema, el modelado gil agrega principios tales como "modelar con un propsito", "el software es su meta principal" y "viajar con poco equipaje", una forma de decir que poca documentacin es suficiente. Entre las metodologas giles identificadas: Extreme Programming Scrum Familia de Metodologas Crystal Feature Driven Development ProcesoUnificado Rational, unaconfiguracingil Dynamic Systems Development Method Adaptive Software Development Open Source Software Development

2.4.2. PredictivosLas metodologas no giles son aquellas que estn guiadas por una fuerte planificacin durante todo el proceso de desarrollo; llamadas tambin metodologas tradicionales o clsicas, donde se realiza una intensa etapa de anlisis y diseo antes de la construccin del sistema. Todas las propuestas metodolgicas antes indicadas pueden considerarse como metodologas tradicionales por el especial nfasis que presenta en cuanto a su adaptacin a las condiciones del proyecto (mediante su configuracin previa a aplicarse), realizando una configuracin adecuada, podra considerarse gil. La inspiracin usual para las metodologas han sido disciplinas como las ingenieras civil o mecnica. Tales disciplinas enfatizan que hay que planear antes de construir. Los ingenieros trabajan sobre una serie de esquemas que indican precisamente qu hay que construir y cmo deben juntarse estas cosas. Muchas decisiones de diseo, como la manera de controlar la carga sobre un puente, se toman conforme los dibujos se producen. Los dibujos se entregan entonces a un grupo diferente, a menudo una compaa diferente, para ser construidos. Se supone que el proceso de la construccin seguir los dibujos. En la prctica los constructores se encuentran con algunos problemas, pero stos son normalmente poco importantes. Como los dibujos especifican las piezas y cmo deben unirse, actan como los fundamentos de un plan de construccin detallado. Dicho plan define las tareas que necesitan hacerse y las dependencias que existen entre estas tareas. Esto permite un plan de trabajo y un presupuesto de construccin razonablemente predecibles. Tambin

dice en detalle cmo deben hacer su trabajo las personas que participan en la construccin. Esto permite que la construccin requiera menos pericia intelectual, aunque se necesita a menudo mucha habilidad manual. As que lo que vemos aqu son dos actividades fundamentalmente diferentes. El diseo, que es difcil de predecir y requiere personal caro y creativo, y la construccin que es ms fcil de predecir. Una vez que tenemos el diseo, podemos planear la construccin. Una vez que tenemos el plan de construccin, podemos ocuparnos de la construccin de una manera ms predecible. En ingeniera civil la construccin es mucho ms costosa y tardada que el diseo y la planeacin. As el acercamiento de muchas metodologas es: queremos un plan de trabajo predecible que pueda usar gente del ms bajo nivel. Para hacerlo debemos separar el plan de la construccin. Por consiguiente necesitamos entender cmo hacer el diseo de software de modo que la construccin pueda ser sencilla una vez que el plan est hecho. Qu forma toma este plan? Para muchos, ste es el papel de notaciones de diseo como el UML. (Lenguaje de Modelado Unificado) Si podemos hacer todas las decisiones significativas usando UML, podemos armar un plan de construccin y entonces podemos dar planes a los programadores como una actividad de construccin. Pero aqu surgen preguntas cruciales. Es posible armar un plan que sea capaz de convertir el cdigo en una actividad de construccin predecible? Y en tal caso, es la construccin suficientemente grande en costo y tiempo para hacer valer la pena este enfoque? Todo esto trae a la mente ms preguntas. La primera es la cuestin de cun difcil es conseguir un diseo UML en un estado que pueda entregarse a los programadores. El problema con un diseo tipo UML es que puede parecer muy bueno en el papel, pero resultar seriamente fallido a la hora de la programacin. Los modelos que los ingenieros civiles usan estn basados en muchos aos de prctica guardados en cdigos ingenieriles. Adems los problemas importantes, como el modo en que juegan las fuerzas, son dciles al anlisis matemtico. La nica verificacin que podemos hacer con los diagramas UML es la revisin cuidadosa. Mientras esto es til trae errores al diseo que slo se descubren durante la codificacin y pruebas. Incluso los diseadores experimentados se sorprenden a menudo cuando convierten dichos diseos en software. Otro problema es el costo comparativo. Cuando se construye un puente, el costo del esfuerzo en el plan es aproximadamente un 10% del total, siendo el resto la construccin. En software la cantidad de tiempo gastada codificando es mucho, mucho menor. Se sugiere que para un proyecto grande, slo 15% del proyecto son cdigo y pruebas unitarias, una inversin casi perfecta de las proporciones de la construccin del puente. Aun cuando se consideren las pruebas parte de la construccin, el plan es todava 50% del total. Esto genera una pregunta importante sobre la naturaleza del diseo en software comparado con su papel en otras ramas de la ingeniera.

Actividad 3. Listado de caractersticas de los modelos giles y predictivosComo parte de la evaluacin realiza la siguiente actividad cuyo propsito es distinguir entre modelos giles y predictivos. 1. En un archivo de texto, realiza un listado comparativo de los modelos giles y predictivos, teniendo en cuenta las definiciones vistas en los temas anteriores. Ejemplo:

2. Guarda tu actividad con la nomenclatura DOO_U2_A3_XXYZ. 3. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

AutoevaluacinPara reforzar los conocimientos relacionados con los temas que se abordaron en esta segunda unidad del curso, es necesario que resuelvas la autoevaluacin. Recuerda que es muy importante leer cuidadosamente los planteamientos indicados y elegir la opcin adecuada para cada uno.

Evidencia de aprendizaje. Requerimientos para disear un programa con OOComo parte de la evaluacin de esta unidad, debes llevar a cabo esta actividad cuyo propsito es aplicar los conceptos aprendidos en la unidad. 1. En un archivo de texto detalla un levantamiento de requerimientos que cumpla con los estndares para disear un programa con OO para el control de una papelera y menciona el modelo de software a aplicar en la misma. 2. Consulta la Escala de evaluacin. 3. Guarda la evidencia con el nombre DOO_U2_EA_XXYZ. 4. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

AutorreflexionesAdems de enviar tu Evidencia de aprendizaje, es importante que ingreses al foro Preguntas de Autorreflexin y consultes las preguntas que tu Facilitador(a) presente, a partir de ellas, debes elaborar tu Autorreflexin en un archivo de texto llamado DOO_U2_ATR_XXYZ. Posteriormente enva tu archivo mediante la herramienta Autorreflexiones.

Cierre de la unidadHas concluido la unidad 2 del curso a lo largo de esta trabajaste con la documentacin de requerimientos para el anlisis orientado a objetos, comenzando con la parte de levantamiento de requerimientos, que incluye el describir cules son los requerimientos y que actividades necesitas realizar para el levantamiento de los mismos. Tambin identificas cual es la documentacin para el levantamiento y que especificaciones debe cumplir considerando sus estndares, divididos en sus fases y anlisis de restricciones. Por ltimo en esta unidad debes distinguir que modelos del desarrollo de software se manejan y si son giles o predictivos. Es aconsejable que revises nuevamente la unidad en caso de que los temas que se acaban de mencionar no te sean familiares o no los recuerdes, de no ser este t caso, ya ests preparado(a) para seguir con la unidad 3, en donde continuars con la Metodologas de Diseo para la Generacin de Sistemas Orientados a Objetos, tales como Bosh, OOC, OMT y UML. Todo ello con el fin de terminar la ltima unidad del curso de Anlisis y diseo orientado a objetos.

Fuentes de consulta

Booch-Grady (1996) Anlisis y Diseo Orientado a Objetos con Aplicaciones. Mxico: Pearson Educacin. 2 Cueva, J. (2005) Ingeniera del Software. Madrid: Pearson Educacin. 3 Cueva, J. (2005) Anlisis orientado a objetos, en: El proceso de desarrollo de software. Recuperado el 22 de julio de 2011 de: http://www.di.uniovi.es/~cernuda/pfc/aoo.pdf 4 Fowler, M. (2003) La nueva metodologa. Traduccin de Alejandro Sierra para programacionextrema.org. Recuperado el 22 de julio de 2011 de: http://www.programacionextrema.org/articulos/newMethodology.es.html 5 Garca, S. y Morales, E. (2003) Desarrollo de aplicaciones informticas. Anlisis y diseo detallado de aplicaciones informticas de gestin. Mxico: Ed. Thompson. 6 Kendall, E. (2005) Anlisis y Diseo de sistemas. Mxico: Pearson Educacin. 7 Letelier, P. y Penads, M. (s/f) Metodologas giles para el desarrollo de software: eXtremeProgramming (XP). Universidad Politcnica de Valencia. Recuperado el 22 de julio de 2011 de: http://www.willydev.net/descargas/masyxp.pdf 8 WorldLingo (2011) Anlisis de requisitos. WorldLingoTranslations LLC. Recuperado el 22 de julio de 2011 de: http://www.worldlingo.com/ma/enwiki/es/Requirements_analysis

1

Ingeniera en Desarrollo de software CUATRIMESTRE: 04 Programa de la asignatura: Anlisis y diseo orientado a objetos Unidad 3. Metodologas de diseo para la generacin de sistemas orientados a objetos

ndiceUnidad 3. Metodologas de diseo para la generacin de sistemas orientados a objetos .. 3 Presentacin de la unidad .............................................................................................. 3 Propsito ........................................................................................................................ 5 Competencia especfica ................................................................................................. 6 3.1. Booch ...................................................................................................................... 6 3.1.1. Introduccin .......................................................................................................... 6 3.1.2. Modelos ................................................................................................................ 7 3.2. OOSE .................................................................................................................... 12 3.2.1. Introduccin ........................................................................................................ 13 3.2.2. Modelos .............................................................................................................. 15 3.3. OMT ...................................................................................................................... 18 3.3.1. Introduccin ........................................................................................................ 19 3.3.2. Modelos .............................................................................................................. 20 Actividad 1. Metodologa para la generacin de sistemas OO ...................................... 22 3.4. UML ...................................................................................................................... 22 3.4.1. Introduccin ........................................................................................................ 23 3.4.2. OCL (Lenguaje de Especificaciones de Objetos) ................................................ 25 Actividad 2. Cuadro comparativo de las diferentes metodologas ................................. 26 Autoevaluacin ............................................................................................................. 27 Evidencia de aprendizaje. Cuadro comparativo de los mtodos de modelado ............. 27 Cierre de la unidad ....................................................................................................... 28 Para saber ms. ....................................................................................................... 28 Fuentes de consulta ..................................................................................................... 28

Unidad 3. Metodologas de diseo para la generacin de sistemas orientados a objetos Presentacin de la unidadEn las metodologas de anlisis y diseo orientado a objetos, se utilizan algunos conceptos que se definen a continuacin. 1 Mtodo. Es un conjunto de lineamientos y reglas, incluyendo los siguientes componentes. 2 Conceptos de modelado. Permiten la captura de la semntica y el conocimiento acerca de un problema y su solucin. 3 Modelo es una representacin formal de un sistema con cierto nivel de abstraccin. En las etapas de especificacin de requerimientos y anlisis el nivel de abstraccin normalmente es alto, omitiendo detalles de implementacin. 4 Meta modelo. Es un modelo que describe otros modelos, describe los conceptos del mtodo modelo y sus relaciones, define los modelos legales que pueden ser construidos dentro del mtodo, describe la informacin que debe ser capturada. 5 Vistas y notaciones. Son tiles en la presentacin fundamental del modelo de informacin para que los seres humanos puedan comprenderla, examinarla y modificarla en su caso. 6 Una vista solo muestra una parte de la semntica del modelo y diferentes vistas pueden presentar la misma informacin en varias formas. 7 Notacin. Permite construir, examinar y manipular modelos, el mismo modelo se puede dibujar de diferentes maneras mediante el uso de diferentes smbolos, donde algunos de ellos pueden tener el mismo significado. Cada persona puede adoptar su propio formato para describir sus diagramas. 8 Proceso de desarrollo iterativo. Representa una secuencia de pasos para la

construccin e implementacin de modelos. El proceso puede estar distribuido en varios niveles de detalle, desde el nivel ms alto del proyecto, hasta etapas especficas para la construccin de modelos de bajo nivel. El proceso indica qu modelos se debern construir y cmo construirlos. 9 Proceso. Es la gua que indica como producir un modelo, proporciona un esqueleto de trabajo (frameworks) para el desarrollo, describe los artefactos a ser producidos y las etapas para producirlos. A alto nivel, describe el desarrollo del ciclo de vida y las etapas de iteracin dentro de l. A bajo nivel describe un esqueleto de trabajo para la produccin de modelos; las etapas para la construccin del modelo, lineamientos para describir componentes de l, principios de diseo a seguirse, 1 mediciones de calidad, referencias cruzadas, reglas de consistencia y banderas rojas para identificar posibles problemas. 2 Patrn. Es una solucin estndar escrita para resolver un problema, basada en una secuencia de tiempo. No existen museos de programas donde los nuevos diseadores puedan aprender, emulando programas que all existen, mas bien, tratan de captar ideas de los diseadores expertos. Actualmente existe un Movimiento de Patrones con el propsito de coleccionar, catalogar y explicar patrones tiles de diseo, de tal forma que otros diseadores puedan aprender de ellos. Por lo tanto, Los Patrones son resmenes de casos de diseo basados en la experiencia. 3 Reglas de Diseo. Son estados o propiedades que debern llevarse a cabo u omitirse en un diseo o estrategias generales de diseo a utilizar. Tips y Reglas de dedo. Son recomendaciones que se aplican donde sea necesario, no se organizan en etapas. Son presentaciones informales de patrones. En los mtodos AOO/DOO existen dos tipos principales, dividiendo a estos en: 1 Estticos (enfocados a datos), lo importante es la estructura de datos anexa a los objetos y las operaciones que sobre ella operan. 2 Dinmicos (enfocados a comportamientos o enfocados a responsabilidades): un objeto tiene sentido en estos mtodos cuando exhibe un comportamiento diferencial respecto del resto delos objetos.

En la tabla anterior se mezclan mtodos de anlisis y de diseo porque, pese a lo que anuncien sus autores o aun su mismo nombre, la distincin entre anlisis y diseo se difumina, aqu presentamos los ms utilizados y que dieron origen al que actualmente se utiliza para el ADOO.

PropsitoCon el transcurso de esta unidad ubicars las diferentes metodologas para el diseo de sistemas orientados a objetos: Booch, OOSE (Object-Oriented Software Engineering / Ingeniera de software orientado a objetos), OMT (Object Modeling Technique / Tcnica de modelado de objetos) y UML (Unified Modeling Language / Lenguaje Unificado de Modelado) las cuales nos servirn despus de hacer un anlisis para hacer un buen diseo apoyado con estas tcnicas.

Competencia especficaComparar las metodologas de diseo para la generacin de sistemas orientados a objetos mediante los diagramas con los mtodos de modelado Booch, OOSE, OMTy UML.

3.1. BoochEs una metodologa que se utiliza en el anlisis y diseo de software creada por Booch durante su estancia en Rational Software Corporation. El mtodo BOOCH define modelos para describir un sistema, soportando el desarrollo iterativo e incremental. El mtodo incluye diferentes diagramas segn el enfoque que se le d ya sea: 1 De clases 2 De objetos 3 De transicin de estados 4 De mdulos 5 De procesos 6 De interaccin

3.1.1. IntroduccinEl mtodo cuenta con una notacin expresiva y bien definida que le permite al diseador expresar sus ideas y concentrarse en problemas ms serios. Son necesarias dos dimensiones para especificar la estructura y comportamiento de un sistema orientado a objetos: Dimensin uno: Fsica / Lgica. Dimensin dos: Esttica / Dinmica. Para cada dimensin se definen una serie de diagramas que denotan una vista de los modelos del sistema, stos reflejan "toda la verdad" sobre sus clases, relaciones y otras entidades y cada diagrama representa una proyeccin de estos modelos. En el estado estable, todos estos diagramas deben ser consistentes con el modelo y tambin consistentes entre ellos mismos. Dimensin lgica: Describe la existencia y significado de las abstracciones principales y los mecanismos que forman el espacio del problema o para definir la arquitectura del sistema. Dimensin fsica: Describe la composicin concreta en cuanto a hardware y software del contexto o implantacin del sistema. Dimensin esttica: Estn formados por los diagramas de: 1.- Diagramas de clases: Muestra la existencia de clases y sus relaciones, en la visin lgica de un sistema, utilizada en la etapa de anlisis. 2.- Diagramas de objetos: Muestran la existencia de objetos y sus relaciones en la etapa de diseo lgico de un sistema. 3.- Diagramas de mdulos: Muestran la asignacin de clases y objetos a mdulos en el diseo fsico de un sistema. 4.- Diagramas de procesos: Muestran la asignacin de procesos a procesadores en el diseo fsico de un sistema. Dimensin dinmica: La semntica dinmica de un problema se expresa mediante los siguientes diagramas: 1.-Diagrama de transicin de estados: Muestra el comportamiento de cada instancia de una clase, los eventos que provocan una transicin de un estado a otro y las acciones que resultan de este cambio de estado, por lo que, cada clase puede contar con este tipo de diagrama. 2.- Diagramas de interaccin: Muestra el orden temporal en que se suceden los mensajes en un conjunto de objetos que representan un escenario. Estn en el mismo contexto que los diagramas de objetos.

3.1.2. ModelosDiagramas de Clases

Un diagrama de clases es utilizado para mostrar la existencia de clases y sus relaciones en la visin lgica de un sistema. Los dos elementos esenciales de un diagrama de clases son: las clases y sus relaciones bsicas. La figura siguiente muestra el icono que se utiliza para representar una clase en un diagrama de clases. En ciertos diagramas de clases, es til exponer algunos de los atributos y operaciones asociados con una clase:

Los atributos denotan una parte de un objeto agregado, durante el diseo expresan una propiedad singular de la clase. A Nombre del atributo solamente. C Clase del atributo solamente. A:C Nombre y clase del atributo. Las operaciones denotan algn servicio proporcionado por la clase, se distinguen de los atributos aadiendo parntesis. N() Nombre de la operacin solamente. R N(Argumento) Clase de retorno de la operacin, nombre y parmetros formales (si los hay). Las relaciones de clase representan una colaboracin con otras clases de diversas maneras. Las conexiones esenciales entre clases incluyen las siguientes relaciones:

Figura 3.2. Conexiones entre clases La asociacin conecta dos clases y denota una conexin semntica, se etiquetan con expresiones sustantivas, denotando la naturaleza de la relacin. La herencia denota una relacin de generalizacin / especializacin (una relacin ), y aparece como una asociacin con una cabeza de flecha. La flecha apunta a la superclase, y el extremo opuesto de la asociacin designa la subclase. La subclase hereda la estructura y comportamiento de su superclase. Las relaciones de herencia no pueden llevar indicaciones de cardinalidad. La Posesin: denota una relacin todo / parte (relacin o agregacin), aparece como una asociacin con un crculo relleno en el extremo que seala al agregado, la clase que est en el otro extremo denota la parte cuyas instancias estn contenidas por el objeto agregado.

La Utilizacin: denota una relacin cliente / servidor y aparece como una asociacin con una circunferencia en el extremo que denota al cliente. En esta relacin de alguna forma el cliente depende del servidor para que ste le proporcione determinados servicios.

Figura 3.3. Utilizacin Diagramas de Objetos Un diagrama de objetos se utiliza para mostrar la existencia de objetos y sus relaciones en el diseo lgico de un sistema. Los dos elementos esenciales de un diagrama de objetos son los objetos y sus relaciones. Objetos en la figura siguiente muestra el icono que se usa para representar un objeto en un diagrama de objetos. Al igual que en el diagrama de clases, tambin se pueden especificar algunos atributos del objeto.

Figura 3.4. Objeto Relaciones entre objetos: los objetos interaccionan a travs de sus enlaces con otros objetos, un enlace es una instancia de una asociacin, al igual que un objeto es una instancia de una clase.

Figura 3.5. Relaciones entre objetos Flujo de datos: los datos pueden fluir en la misma direccin que un mensaje o en direccin contraria. El mostrar explcitamente la direccin del flujo de datos ayuda a explicar la semntica de un escenario particular. Objetos activos: son aquellos que incorporan su propio hilo de control.

Figura 3.6. Objetos activos Diagramas de mdulos Se utiliza un diagrama de mdulos para mostrar la asignacin de clases y objetos a mdulos en el diseo fsico de un sistema. Un solo diagrama de mdulos representa una vista de la estructura de mdulos de un sistema. Los dos elementos esenciales de un diagrama de mdulos son los mdulos y sus dependencias. Programa principal: Denota un archivo que contiene la raz del programa. Especificacin y cuerpo: Denotan archivos que contienen la declaracin y la definicin de las entidades. Subsistema: Los subsistemas sirven para modularizar el modelo fsico de un sistema. Un subsistema es un agregado que contiene otros mdulos y otros subsistemas. Cada mdulo engloba la declaracin o definicin de clases, objetos y otros detalles del lenguaje. Dependencias: la nica relacin que puede darse entre dos mdulos es una dependencia de compilacin, representada por una lnea dirigida que apunta al mdulo respecto al cual existe la dependencia. Las flechas denotan dependencias, la flecha sale del el icono dependiente. Diagrama de procesos Se usa un diagrama de procesos para mostrar la asignacin de procesos a procesadores en el diseo fsico de un sistema. Un solo diagrama de procesos presenta una vista de la estructura de procesos de un sistema. Elementos del diagrama Procesadores. Elemento de hardware capaz de ejecutar programas. Dispositivos. Elemento de hardware incapaz de ejecutar un programa. Conexiones. Son lneas no dirigidas para indicar conexiones entre procesadores y/o dispositivos.

Figura 3.7. Diagrama de procesos El proceso de diseo orientado a objetos no puede describirse mediante reglas, aunque est bastante bien definido como para brindar un proceso predecible y repetible para una organizacin de software madura.

Un proyecto de software bien hecho es aquel en el que el software entregado satisface y posiblemente excede las expectativas del cliente. Se ha desarrollado de forma econmica, entregado en tiempo, y es flexible al cambio y al crecimiento.

3.2. OOSEEste mtodo fue desarrollado por Ivar Jacobson OOSE un enfoque para el manejo de casos de uso, este modelo de casos de uso sirve como un modelo central para otros modelos. Este modelo es la base en la etapa de anlisis, construccin y prueba. OOSE presenta cinco tcnicas para modelar un sistema: 1 Modelo de requerimientos: delimita el sistema y define su funcionalidad. 2 Modelo de anlisis: estructura el sistema, modelando tres tipos de objetos (objetos de interface, objetos entidad y objetos de control). 1 implementacin. Consiste de diagramas de interaccin y diagramas de transicin de estados. 2 Modelo de implementacin: consiste en el cdigo fuente de los objetos especificados en el modelo de diseo. 3 Modelo de prueba: es llevado a cabo mediante la realizacin de pruebas al modelo de implementacin. La idea bsica de estos modelos es capturar el concepto inicial de todos los requerimientos funcionales y usar sus perspectivas. Es por eso que la relacin entre ellos es importante. Para ser posible el mantenimiento del sistema es tambin necesario que los modelos sean tangibles.

3.2.1. IntroduccinEste mtodo proporciona un soporte para el diseo creativo de productos de software, inclusive a escala industrial. El autor plantea el problema del diseo y construccin de software haciendo una comparacin con la industria de la construccin, contemplando las siguientes fases: 1 Herramientas. Soportan todos los aspectos de la empresa, explcitamente las actividades de arquitectura, mtodos y procesos. 2 Procesos. Permite el escalamiento de los mtodos, de tal forma que puedan ser aplicados a proyectos de forma interactiva y en partes. 3 Mtodos. Establece de manera explcita los procedimientos etapa por etapa que deben seguirse para aplicar la arquitectura al proyecto. 4 Arquitectura. Una buena estructura del sistema es fcil de entender, de cambiar y realizar pruebas y mantenimiento. Las propiedades del sistema determinan cmo la arquitectura debe ser tratada durante el tiempo de vida. Las propiedades de la arquitectura son extremadamente importantes y forman la base del mtodo. Diseo creativo. Las actividades creativas de un desarrollo, consisten en la transformacin de un conjunto de requerimientos y nociones vagas, en un plan estructurado de construccin y un plan de accin para su implementacin .El diseo creativo tomando como referencia una base arquitectnica es seguir paso a paso los mtodos y procesos con la asistencia de herramientas, para convertir los requerimientos dentro de una arquitectura viable para la construccin de un proyecto incluyendo la creacin de prototipos. Un aspecto importante durante el desarrollo del sistema, es considerar explcitamente el proceso de cambio. Todos los sistemas cambian durante su ciclo de vida. Hoy en da el desarrollo de los nuevos mtodos es conocer qu cambios son los principales en la parte global del ciclo de vida, as como el costo del sistema. Una industrial del proceso debe por lo tanto saber

sobre los cambios del sistema. Un sistema normalmente desarrolla cambios incorporndose en nuevas versiones. La primera versin de un sistema representa una pequea parte de una composicin durante el ciclo de vida del sistema. Las actividades de un ciclo de vida son las mismas tanto para desarrollar una nueva versin de u