Introducción.

 

 

Una vez revisado en forma general el Modelo Orientado a Objetos, ahora nuestro interés particular en este curso será el enfoque que se da actualmente a la parte del proceso de desarrollo de software que corresponde al análisis y al diseño. Este enfoque abarca también a los lenguajes orientados a objetos, de tal manera que el modelado y la programación forman parte del mismo modelo, compartiendo los mismos conceptos.

 

Como ya vimos, el objetivo del análisis es generar modelos del dominio del problema, es decir, entender, haciendo abstracción hacia objetos, en qué consiste el problema mismo; y el del diseño es extender ese entendimiento con otras clases de otros objetos, que permitan poner en práctica un sistema en un ambiente de cómputo.

 

 

 

Panorama de los diferentes modelos de ciclos de vida de los sistemas.

 

 

 

Ingeniería de Software.

 

Objetivo:

 

Definir métodos ingenieriles para que grupos de personas construyan sistemas complejos.

 

 

Programación: actividad personal.

 

Ingeniería de Software: actividad de grupo.

 

 

Su meta es definir el PROCESO de producción de software, es decir, contestar a las

siguientes preguntas:

 

¿Qué es lo que sigue?

Definir el orden de los pasos y actividades en cada paso.

 

¿Hasta cuándo lo vamos a hacer?

Establecer criterios para progresar de un paso a otro.

Transparencia A.1

 

Ingeniería de Software. (Transparencia A1)

 

La Ingeniería de Software define métodos para la construcción de sistemas de cómputo complejos. Estos métodos son técnicas claramente definidas, fácilmente enseñadas, repetidas y utilizadas por grupos de personas que cooperan entre sí para desarrollar software. Esto implica que el enfoque de la Ingeniería de Software no sea personal. Prácticamente hoy en día cualquier sistema de software que se desarrolla tiene un cierto grado de complejidad.

Aún en nuestros días, al hablar de programación puede pensarse que se trata de un acto personal o individual, pero cuando lo hacemos del desarrollado de software en grupos, estamos hablando de Ingeniería de Software ya que necesitamos trabajar de una forma más organizada y con mejores técnicas.

 

En la Ingeniería de Software se propone el proceso que hay que seguir para desarrollar software donde su último enfoque es hacerlo con calidad.

 

Pero, ¿qué es el proceso de software? El proceso de software se define cuando señalamos el orden de pasos y actividades que hay que realizar para desarrollar sistemas de software. Las definiciones más recientes tratan de incluir otros aspectos, especificando ¿qué hacer?, ¿cuáles pasos seguir?, ¿y quién debe hacerlos? Con esto introduce el concepto de diferentes roles, para el proceso de software, quienes se responsabilizan de la realización de las actividades. El proceso de software define el orden especificando el qué se va a hacer, el quién lo va a hacer y el cuándo se va a hacer. Otro aspecto importante dentro de la definición del proceso de software, es que establece criterios para poder decir cuándo hemos terminado una actividad y podemos empezar otra, así como criterios de terminación de actividades basados en el estado del producto que se ha desarrollado.

 

 

 

 

Modelos más destacados del proceso de la producción de software (ciclos de vida).

 

 

  1. Codifica y corrige (code-and-fix).

 

Proceso:

 

Ventaja: efectivo para productos pequeños.

 

Desventaja: diseño "spaghetti", no manejable para sistemas grandes.

 

Característica: basado en la inspiración personal.

 

Transparencia A.2

¿Cuáles son los modelos de procesos de producción de software conocidos como ciclos de vida, que en la breve historia de la computación se han inventado?

 

 

Modelo Codifica y corrige. (Transparencia A2)

 

El ciclo de vida o proceso de desarrollo de software más antiguo y utilizado hasta la fecha, sobre todo por la gente que empieza a aprender la programación, es el llamado "code-and-fix", cuya traducción correcta al español sería "codifica y corrige". En este proceso los pasos ha seguir por los desarrolladores son:

 

 

El ciclo de vida es efectivo para productos o sistemas pequeños, principalmente cuando se trata de desarrollos unipersonales. En contraste, el diseño final puede ser de estilo "spaghetti", es decir, que al ir pegando poco a poco diferentes partes de código, es posible obtener un producto, que aunque funcione, no sea muy coherente, y no cuente, desde el punto de vista del diseño, con una arquitectura legible y razonable.

 

Otra desventaja es que este tipo de arquitectura no es adecuado para sistemas medianos y grandes. Su característica principal es que depende de la inspiración personal, del heroísmo, de la experiencia, del conocimiento y de las habilidades del desarrollador.

 

 

 

Modelo en Cascada. (Transparencia A3)

 

Cuando nace la Ingeniería de Software propiamente como un área se define el proceso de software para grupos de desarrollo conocido como proceso o ciclo de vida en cascada. Este proceso se divide en fases claramente especificadas, que pueden variar dependiendo de los autores consultados, pero conservan siempre la misma idea, de que no puede empezar una fase hasta que no se termine la anterior.

 

La primera fase que se toma en cuenta es el Estudio de Factibilidad del proyecto. Una vez estudiada la factibilidad y aprobado el proyecto, se pasa al Análisis de Requerimientos donde se establecen y se especifican los requerimientos a detalle junto con el cliente, luego pasamos al Diseño de la solución de cómputo, posteriormente a la Codificación y Pruebas de los módulos, (pues en lo general, el sistema debe estar modularizado) sigue la Integración de los módulos en un sistema completo haciendo Pruebas de este sistema integrado, posteriormente la fase de Entrega e Instalación del sistema al usuario, y finalmente el Mantenimiento, el cual puede ser la fase más costosa y más larga en tiempo, por las adaptaciones, modificaciones y correcciones según las necesidades del usuario.

 

En este modelo, el grupo de desarrollo no puede empezar una fase siguiente si la anterior no quedó totalmente terminada. Por ejemplo, si no se hizo la fase de Estudio de Factibilidad, no se documentaron los resultados de esta fase y no se aprobó el proyecto, no se puede empezar la fase de Análisis; si esta tampoco se termina no puede iniciar entonces la de Diseño. Cada fase emite un producto para la siguiente fase, (ya sea documentación o el propio código) el cual es indispensable para formar la entrada de la misma.

 

La ventaja de este modelo, con respecto con al anterior, es que ya tenemos cierta disciplina en el desarrollo de sistemas; se introducen la planeación y administración, pues las fases se deben planear en tiempo y recursos (humanos y físicos), y se deben administrar, es decir, alguien vigila que el grupo de desarrollo realmente se ajuste a lo que se ha planeado y está cumpliendo con este proceso de desarrollo.

 

En este modelo, la fase de Codificación se pospone hasta que se entienda bien el objetivo del proyecto (los requerimientos) y hasta que se haga el diseño de todo el sistema. Esto es una ventaja pues se evita construir productos que finalmente no cumplirán en su totalidad con lo que el usuario requiere. La desventaja de este modelo es que es lineal, rígido y monolítico, por lo tanto irrealista, pues la gente difícilmente se espera, para realizar sus propias actividades, a que terminen sus compañeros de fases anteriores. Podemos ver aquí el antipatrón "análisis - parálisis": la persona que hace el análisis no es capaz de decir que ya entendió el problema, que ya tiene todos los requerimientos porque siempre le parece que falta algo, dando como consecuencia el retardo en la entrega de los documentos de análisis a los grupos responsables de las siguientes partes. Difícilmente en la realidad se puede organizar el trabajo en esta forma tan rígida.

 

Además este modelo presenta dificultad para introducir modificaciones, sobre todo en la fase de Mantenimiento, porque para realizarlo habría que volver a empezar todo el ciclo, modificando la información de cada fase, para tener así una especificación y documentación consistente con el mantenimiento realizado.

 

Esto último es importante puesto que dentro del Mantenimiento tenemos que el 20% es correctivo (se corrigen los errores del sistema original), otro 20% es adaptativo (adaptamos sin cambios esenciales en las funciones originales) y el 60% está dirigido al perfeccionamiento del sistema (ampliamos el sistema con nuevos requerimientos del usuario). De no documentar debidamente cada mantenimiento, corremos el riesgo (que de hecho actualmente existe en gran medida) de tener sistemas que no cuentan con su documentación actualizada.

 

Este modelo está enfocado a la producción de documentos. Cada fase tiene que entregar un producto (documento o software) bien documentado, para que otros grupos puedan trabajar con ellos.

 

 

 

 

 

  1. Cascada (waterfall).
  2.  

    Proceso:

     

     

    Cada fase emite un producto para la siguiente.

     

     

    Ventaja: requiere de disciplina, planeación y administración, la puesta en práctica se pospone hasta que se entienda bien el objetivo.

     

    Desventaja: linear, rígido, monolítico, no realista. Difícil de introducir modificaciones sobre todo en la fase de mantenimiento, la cual en 20% es correctiva, otro 20% adaptativa pero en más del 50% está dirigida al perfeccionamiento del sistema.

     

    Característica: enfocado a la producción de documentación.

     

    Transparencia A.3

     

     

     

    Modelo Evolutivo. (Transparencia A.4)

     

    A partir de este modelo, encontramos los más recientes originados del de cascada, que actualmente están impactando y adaptándose cada vez más a la orientación a objetos.

    El modelo Evolutivo conocido también como incremental e iterativo, consiste en hacer la documentación de las fases, realizando un prototipo del sistema, se evalúa el qué tan lejos el prototipo está de la solución final esperada por el cliente; se toman en cuenta las observaciones de esta evaluación, y se crea un nuevo prototipo que las incluya. Esto se realiza en una vuelta repetitiva donde se incrementa el alcance del prototipo en pequeñas proporciones hasta cumplir los requerimientos totales.

     

    En este método no es necesario esperar hasta que toda una fase esté terminada para iniciar la siguiente. Si se cuenta con una parte del análisis bien entendida, se puede realizar un primer diseño del corazón o de una parte medular del sistema, hacer su codificación y con esto, formar nuestro primer prototipo que ampliaremos en las siguientes iteraciones (vueltas), creando prototipos cada vez mejores y amplios con respecto a los requerimientos originales.

     

    La ventaja es que es ideal para sistemas que no tiene bien definidos los requerimientos, es decir, para la mayoría de los sistemas que se desarrollan. El cliente desde el principio tiene una idea de los requerimientos de su sistema, pero no están claros hasta el último detalle. Aún así podemos basarnos en lo ya entendido (cliente y desarrollador), trabajar con esta información, y mientras se vayan creando prototipos, el cliente detallará sus especificaciones.

     

    Su desventaja es que es difícil distinguirlo del proceso "codifica y corrige", pues en cierta medida son parecidos, la diferencia está que en la práctica se requiere que al construir el prototipo se aplique el análisis y el diseño pero sólo a una parte de los requerimientos ya entendidos, que se documente y se codifique, lográndose con todo esto, un poco de disciplina heredada del modelo en cascada, de esta manera, la desventaja no lo es tanto. La característica de este modelo es que está enfocado a la producción de prototipos.

     

     

     

     

  3. Evolutivo (evolutionary).

 

Proceso:

 

Es un proceso repetitivo y creciente.

 

 

Ventaja: ideal para sistemas que no tienen bien definidos los requerimientos.

 

Desventaja: es difícil de distinguirlo del proceso "codifica y corrige".

 

Característica: enfocado a la producción de prototipos.

 

Transparencia A.4

 

 

  1. Espiral (spiral).
  2.  

    Proceso (1):

    (1) Tomado de A Spiral Model of Software Development and Enhacement, de B. W. Boehm, IEEE Compueter May 1988.

    Transparencia A.5

     

     

     

    Modelo Espiral. (Transparencia A.5)

     

    La misma idea de prototipos la encontramos en este modelo, (se sugiere revisar las notas de la clase de Ingeniería de Software para mayores detalles). En la propuesta de Boehm, la espiral representa muy bien la idea del desarrollo iterativo e incremental, así como la del desarrollo por prototipos, en donde estos al principio abarcan una pequeña parte del sistema, (la evaluación de riesgos) y empiezan en el centro de la espiral.

     

    Es un modelo evolutivo pero en cada vuelta, antes de generar un nuevo prototipo, se evalúa el riesgo que se corre si continuáramos con la siguiente iteración, es decir, si aún por parte del cliente y de nosotros existe tiempo, recursos y decisión para seguir mejorando este proceso de desarrollo o por el contrario, si encontramos que los riesgos son demasiado grandes, pues entonces tomar las decisiones adecuadas como la suspención del proyecto o la solicitud de más recursos. La idea es que antes de generar un prototipo, evaluemos la factibilidad y analicemos los riesgos. Si el resultado es positivo, entonces generamos el primer prototipo (el cual abarca sólo una parte del sistema), continuamos con las fases siguientes (simulación, comparación, validación de requerimientos) hasta que deje de ser prototipo y se convierta en el sistema completo, cuya puesta en operación, ya integrada y aceptada por el cliente, constituye la salida del proceso. Este modelo es iterativo pues repite los pasos incrementándolos cada vez al ir robusteciendo el prototipo en su funcionalidad.

     

     

     

     

  3. Transformador (transformational).

 

Proceso:

 

 

Ventaja: las modificaciones se hacen en el nivel de especificación y no a nivel del código, ahorra tiempo de diseño, codificación y pruebas.

 

Desventaja: bueno para productores relativamente pequeños de áreas limitadas (hojas de cálculo, 4GL’s).

 

Característica: trabajo en el nivel de especificación.

 

Transparencia A.6

 

 

 

Modelo Transformador. (Transparencia A.6)

 

Este modelo actualmente no es ni básico ni popular en la modelación orientada a objetos, pero sí es el sueño dorado de los desarrolladores, puesto que propone la posibilidad de construir código a partir de las especificaciones dadas. Esto constituye la base para las herramientas CASE, donde, utilizando un lenguaje abstracto o gráfico para describir las especificaciones de manera más agradable, la herramienta automatizada se encarga de realizar el código. En el modelo transformador, se realiza la especificación formal del sistema y la herramienta convierte automáticamente esta especificación en el código.

 

Rational Rose pude ser un ejemplo de este modelo porque de una especificación con UML puede generar código en Java, C++ o VisualBasic. En realidad sólo genera esqueletos, especificaciones de clases y encabezados de métodos pero no sus códigos. Existen otras propuestas de lenguajes de especificación formal como Z, que permiten especificar sistemas matemáticamente con mayor precisión y generar el código. Como actualmente estos métodos son poco eficientes y populares, creemos que el proceso de desarrollo de software va encaminado a crear lenguajes de especificación más expresivos.

La desventaja es que es bueno para productores relativamente pequeños de áreas limitadas. Las hojas de cálculo y lenguajes de cuarta generación (4GL) –desarrollados en la práctica para el uso de bases de datos- son ejemplos de lenguajes de especificaciones más abstractas que permite generar el código, pero hasta la fecha, estos lenguajes están restringidos a ciertas aplicaciones (como los constructores de la familia Visual) y aún no existen para propósito general.

 

La característica de este modelo es que se trabaja en el nivel de especificación y no se llega al nivel del lenguaje de programación.

 

 

 

 

Tecnología Orientada a Objetos

 

 

Propone el proceso evolutivo del desarrollo de software, cuyas fases están basadas en el modelo de objetos.

 

 

Transparencia A.7

 

 

 

 

El objetivo es minimizar los riesgos en todas las etapas del desarrollo de un sistema. Es más bien un metamodelo que se aplica a todos los modelos anteriores.

 

 

 

 

Ventaja: toma en cuenta el riesgo y trata de minimizarlo en las siguientes etapas del proceso del desarrollo de un sistema. Permite aplicar lo mejor de los demás modelos.

 

Desventaja: no es maduro, depende de la habilidad humana de evaluar adecuadamente los riesgos y tomar las decisiones correctas, faltan técnicas y métodos para aplicar sus pasos.

 

Transparencia A.8

Estas dos últimas transparencias no se explicaron en clase.

 

 

 

Tecnología orientada a objetos.

 

 

Introducción

 

El modelo del proceso de desarrollo de sistemas que más adquiere popularidad y razonable importancia, es el modelo evolutivo, repetitivo y creciente, que se convierte en la base del modelado para la orientación a objetos. A continuación se hará un repaso de los diferentes métodos orientados a objetos, que hasta antes de leer la última publicación de Jacobson, se basan en el modelo evolutivo.

 

Vimos que es en la segunda mitad de los 80 cuando aparecen los lenguajes orientados a objetos de uso más popular (C++, Eiffel). Según lo muestra la portada de la revista Business Week de septiembre de 1991, entre la gente de negocios se empieza a promover la orientación a objetos, con artículos de los autores de Smalltalk y C++ entre otros, explicando el modelo de objetos. Esta portada (un bebé trabajando con una PC) es muy significativa pues se pensaba que esta metodología convertiría al software tan simple que hasta un niño podría usar la computadora.

 

Pero ¿qué sistemas se van a desarrollar? ¿Qué tan potentes serán para dar una nueva imagen y función a las computadoras? Vemos que después de 8 años aún no hemos llegado a ese estado proyectado. Seguimos sin cumplir aquella promesa, pero estamos avanzando poco a poco en esa dirección. El problema es que el proceso de desarrollo de software basado en objetos, todavía no está maduro. Algo se sabe de la experiencia, pero todavía no hay un método ingenieril, tan completo que cualquiera pueda entenderlo rápidamente y aplicarlo repitiendo sus reglas. Todavía quedan en el camino cosas por hacer.

El método de Booch.

 

 

Grady Booch publicó en 1991 el libro "Object–Oriented Design with Application", una recopilación de experiencias propias y de sus colaboradores quienes han trabajado en el desarrollo de sistemas orientados a objetos.

 

El libro muestra que la fase de análisis no estaba tan clara para ellos, pero sí cuenta con una muy buena introducción de lo qué es el modelo de objetos.

 

Explica muy bien el uso de herencia, encontrando paralelos en otras áreas de las ciencias naturales (física, biología, astronomía) y sociales (política, estructura y organización de un país). Todas éstas son iguales o más complejas que el desarrollo de software y todas de alguna manera, disminuyen esa complejidad al utilizar una forma taxonómica de jerarquía entre sus conceptos, logrando con ello facilitar su trabajo, manejo y entendimiento. Así, la idea de herencia entre clases, resulta un buen camino para disminuir la complejidad dentro del modelado orientado a objetos, estructurando los sistemas de software.

 

Booch también propone su notación pre-UML para representar gráficamente clases, objetos y relaciones entre ellos, siendo sus nubes lo más famoso. Con ellas denotaba clases (nubes con líneas punteadas) y objetos (nubes con líneas continuas) ambas conteniendo su nombre, atributos y métodos. Dio también notación para las diferentes relaciones entre clases (de asociación, agregación y herencia). Este libro da ciertas ideas de cómo hacer el proceso de diseño orientado a objetos. Contiene ejemplos (parte de sistemas modelados con su notación) desarrollados en Smalltalk, Object Pascal, C++, Common Lisp y Ada. Fue el primer libro que causó rápidamente impacto en el mercado y en el área de desarrollo de software, gracias a que Rational (compañía del propio Booch) sacó una herramienta gráfica (Rose) para dibujar esas nubes y generar los documentos conforme a su notación, y también gracias a lo sustancioso del libro (pues en comparación con otros resultó ser mucho más serio).

 

En 1994 gracias a este éxito, Booch saca la 2ª edición de su libro (la presentación ya es parecida a los de la nueva serie que Addison Wesley crea posteriormente para el área de ADOO). En este libro, incorpora propuestas de otros autores, crea un método más completo y robusto que ya abarca la fase de análisis, propone el ciclo de vida donde fluye lo iterativo y acumulable y sus ejemplos ahora sólo están en C++ (se pensaba que este sería el lenguaje para orientación a objetos). A continuación se presenta dicho método.

 

El proceso de desarrollo para la orientación de objetos que propone Booch, es el iterativo, creciente y evolutivo al estilo espiral de Boehm. Es una combinación de un concepto nuevo al que llamó microproceso de desarrollo (basado en el modelo de Boehm) con un macroproceso de desarrollo (basado en el de cascada). Esta combinación es muy difícil de entender y aún más trabajarlo. Aquí daremos sólo nuestra interpretación. (Transparencia B1).

 

El administrador de un desarrollo de software con tecnología orientada a objetos, debe tener una vista panorámica del plan de lo que está y va a suceder en el proyecto. Este plan está en el nivel de macroproceso, basado en el modelo de cascada con todas sus fases, todo esto desde el punto de vista del administrador. Pero desde el punto de vista del grupo de desarrollo quienes cooperan entre sí creando prototipos de las diferentes partes del sistema, este proceso es iterativo, creciente y evolutivo, hablamos del nivel de microproceso.

 

 

Método de Booch

 

Proceso de Desarrollo Orientado a Objetos.

 

 

 

 

 

 

Transparencia B.1

 

 

 

 

 

 

Transparencia B.2

 

El Macroproceso. (Transparencia B2)

 

El macroproceso está orientado a una visión global, la que pudiera tener un administrador o líder de proyecto.

Sirve como marco de referencia para controlar al microproceso. Este procedimiento más amplio dicta una serie de productos y actividades medibles que permiten al equipo de desarrollo tasar el riesgo de forma que se centren mejor las actividades de análisis y diseño del equipo.

 

El microproceso está orientado a la visión de un desarrollador, es más estrecha.

Está dirigido en gran parte por la corriente de escenarios y productos atquitectónicos que emergen del macroproceso y son refinados sucesivas veces por él.

 

 

Las fases que lo constituyen son:

 

 

El caso más sencillo de este macroproceso, es cuando el sistema llega a la fase de puesta en marcha y luego evoluciona simplemente cuando se corrigen y mejoran partes no muy sustanciales del sistema. Se puede ver que el macroproceso es muy parecido al modelo de cascada, sólo que aquí no necesariamente debemos tener bien conceptualizado el sistema, para que un grupo de desarrollo comience a analizarlo, diseñarlo y codificarlo. El responsable del proyecto, desde su punto de vista global, debe verificar que efectivamente las fases del macroporceso se están cumpliendo.

 

 

 

 

 

 

 

 

 

 

 

 

Conceptualización.

 

 

Establecer los requerimientos fundamentales para el sistema.

 

 

 

 

Transparencia B.3

 

 

 

 

 

 

 

La conceptualización. (Transparencia B4)

 

El objetivo es el de establecer los requerimientos fundamentales para el sistema. Los requerimientos se establecen entre el grupo de desarrollo y el cliente. Los productos de esta fase deben ser la documentación y si se requieren, prototipos rápidos que se deshecharán pues sólo servirán para aclarar dudas y obtener el visto bueno del cliente.

 

Las actividades comprenden el definir los requerimientos, detallando las pruebas que se harán para validar que finalmente se cubrió el requerimiento; esto formará el criterio de terminación y de aceptación del producto. Otras actividades son crear el grupo que va a desarrollar el prototipo antes mencionados y evaluarlo enfocándose en los riesgos, es decir, una vez que el cliente tiene todos los pros y contras de algún requerimiento solicitado, entonces él tomará la decisión de realizar o no dicho requerimiento.

 

La terminación de esta fase se da con algún criterio que nos diga si ya tenemos todos los requerimientos del cliente, si éste terminó de enumerar sus requerimientos.

 

 

 

 

 

 

 

 

Análisis.

 

 

Proporcionar el modelo del sistema enfocándose en su comportamiento no en su estructura.

 

    • Productos:
      • Escenarios primarios.
      • Escenarios secundarios.
      • Tarjetas CRC.
      • Diagramas de objetos.
      • Diagramas de clases.

 

    • Actividades:
      • Planeación de escenarios.
      • Identificar funciones primarias del sistema, haciendo escenarios por cada una.

 

    • Terminación:
      • Escenarios para todas las funciones básicas.

 

Transparencia B.4

 

 

 

 

 

El análisis. (Transparencia B5)

 

La parte de análisis tiene como objetivo proporcionar el modelo del sistema enfocándose en su comportamiento no en su estructura. Nos enfocamos en el dominio del problema o sea en la funcionalidad que el usuario desea. Tratamos de entender mejor sus requerimientos pasando la estructura a 2º plano, y comenzamos a modelar las funciones del sistema, es decir entendemos en qué consiste el problema.

 

Los productos en esta fase se utilizan como la documentación del análisis. Los productos que genera son:

 

Los escenarios. El concepto de escenario fue adquirido de Rumbaugh (quien lo presentó en su libro también en 1991) para reforzar el análisis. Para cada requerimiento, (que después Jacobson los llamaría Casos de Uso), se define su escenario. Un Caso de Uso es como una función completa que el usuario espera obtener del sistema, desde que empieza por alguna interacción del usuario con el sistema, hasta que éste realiza una operación completa. Los Casos de Uso sirven para capturar, describir y denotar una función, un requerimiento funcional completo, que se espera del sistema. Los escenarios son pasos que el sistema debe realizar para ejecutar algún Caso de Uso. Los escenarios primarios son aquéllos pasos que el sistema tendrá que realizar para satisfacer un requerimiento de los más importantes; los secundarios, por lo general, son los casos excepcionales que suceden sólo de vez en cuando (por ejemplo cuando el usuario cancela alguna operación).

 

Las tarjetas CRC. (Class Responsability and Cooperation). Este concepto fue adquirido de Beck y Cunningham. Esta es una técnica para hacer análisis basado en tarjetas de papel que usan las secretarias para hacer anotaciones. Se usan como apoyo cuando estamos definiendo con más detalle, el escenario de un Caso de Uso o requerimiento del usuario, (por ejemplo Hacer una compra, su escenario podría ser: Generar una Factura, Actualizar Inventarios, Actualizar Contabilidad).

 

 

 

 

En el modelado de objetos, el escenario se convierte en una colección de clases. Se identifica: qué clases del sistema van a participar en el escenario, cuáles serán sus responsabilidades (lo que sabe hacer, es decir sus métodos) y la cooperación de esta clase con otras para poder realizar dichas responsabilidades, anotándose el nombre de aquélla clase o clases con la que se coopera enviando mensajes para que la responsabilidad se realice.

 

Entonces las tarjetas CRC nos ayudan a analizar los escenarios identificando las clases que aparecen en el dominio del problema, con la responsabilidad representamos los métodos asociados a la clase y con la cooperación encontramos las asociaciones y relaciones entre las clases.

 

 

Los diagramas de objetos y clases. Sirven para documentar el análisis (el dominio del problema). Son las herramienta de documentación que propuso Booch con sus nubes punteadas y continuas, mencionadas previamente. Aquí la relación de herencia entre clases se representa con una línea y una flecha negra apuntando hacia la superclase. La relación de agregación con una pequeña bola del lado de la clase que es la dueña de los objetos de la otra clase, y la relación de asociación con una raya simple. En un diagrama de objetos por convención, los nombres en minúscula denotan al objeto y pertenecen a la clase cuyo nombre empieza con mayúscula. En este diagrama, el envió de mensajes se representa con una flecha y el nombre del mensaje va encima de la flecha. El diagrama de clases representa la vista estática del sistema y el de objetos la dinámica.

 

Las actividades que conforman esta fase son la planeación de escenarios y la identificación de funciones primarias del sistema, haciendo escenarios para cada una. Como ya se mencionó, los escenarios sirven para documentar los requerimientos del sistema, cada escenario tiene sus productos y cuando se tengan todos los escenarios para todas las funciones o casos de uso básicos del sistema, la fase de análisis se da por terminada.

 

Nota: Se mencionó que este método en su momento no estaba aún estandarizado, existía confusión de términos pues ese era el estado del arte cuando el libro de Booch salió al público, esperamos que con el trabajo conjunto reciente de los autores, se clarifiquen y se obtenga un método más claro.

 

 

 

 

 

 

 

Diseño.

 

Objetivo.

 

Crear la arquitectura del sistema para su implementación, a diferencia de la fase de análisis, donde se debía entender el problema a resolver y modelarlo con clases, relaciones entre ellas, etc.

 

Productos.

 

  • Diagramas de todo tipo.

Servirán para modelar cada uno de los aspectos del sistema pensando en la implementación computacional.

Por ejemplo UML tiene varios tipos de diagramas para capturar diferentes vistas: estáticas, dinámicas, de comportamiento y la arquitectura de todo el sistema.

 

  • Definición de tácticas.

Es la definición de las decisiones para la implementación.

Booch toma de la idea de la propuesta de Rumbaugh y define políticas comunes para todo el grupo de desarrollo, especificando cómo se harán cada una de las distintas tareas y se determinar también acuerdos sobre los estándares para manejo de errores y excepciones del sistema, manejo de archivos, memoria, control, etc.

 

Actividades.

 

  • Planear arquitectura.

Se refiere a la estructura del sistema; actualmente tiene mucha importancia.

Anteriormente, con el enfoque modular, se dividía el problema en módulos que se comunicaban de cierta manera y a esto se le conocía como la estructura del sistema; pero al volverse cada vez más complejos los sistemas y con la experiencia y desarrollo de la Orientación a Objetos, se busca encontrar la arquitectura de sistemas al estilo arquitectónico tradicional; se desea encontrar las vigas del software.

Un área de estudio de la Ingeniería de Software, trata de encontrar en la Arquitectura, un apoyo para adaptar su conocimiento de las estructuras en la aplicación del diseño de software.

 

  • Decidir la táctica.

Definir los estándares para el desarrollo de sistemas.

 

  • Planear versiones (release).

El modelo del proceso de desarrollo es similar a un desarrollo evolutivo, por ello, se planean prototipos parciales del sistema, es decir, distintas versiones en las que se van dando mejoras o ampliando funcionalidades en cada nueva versión con respecto a la anterior.

 

Terminación.

 

El diseño termina validando la arquitectura y las tácticas mediante el prototipo y las sugerencias para la versión siguiente.

El primer prototipo sirve para validar las decisiones de la parte de diseño y aporta ideas para mejorar la versión siguiente.

 

 

 

 

 

 

 

Evolución.

 

Esta fase se conoce en otros métodos como la fase de la Implementación, pero Booch la llama de Evolución debido a que es evolutiva.

 

 

Objetivo.

 

  • Ampliar y cambiar las implementaciones para llegar al producto final.

Aquí está expresado el modelo espiral del ciclo de vida, donde se van a desarrollar las implementaciones por versiones cada vez mejores.

 

 

Productos.

 

  • Secuencia de versiones ejecutables.

 

 

 

Actividades.

 

  • Aplicación del Microproceso para cada versión individual.
  • Manejo de cambios (en clases). Se refiere al registro de cambios en código y en los diagramas para que los documentos de análisis y diseño sean consistentes con el producto final.

 

Terminación.

 

  • Cuando la calidad de versiones permite hacer entrega del producto al cliente.

La entrega puede ser parcial o global.

 

 

 

 

Mantenimiento.

 

Esta fase es de post-entrega del sistema.

 

 

Objetivo.

 

  • Manejo de evolución del sistema después de la entrega al cliente.

Es igual a la fase de evolución pero se continúa con otros acuerdos y otros presupuestos, además ya se trabaja sobre productos.

 

 

Productos.

 

  • Parecidos a la fase anterior, es decir, generar nuevas versiones del sistema, pero aquí se continúa con otro presupuesto y acuerdos con el cliente.

Algunas dificultades se pueden presentar en esta fase, como por ejemplo, el uso real del sistema con requerimientos de servicio 7X24 (24 hrs, 7 días a la semana) y por ello, se debe trabajar con nuevas versiones o sustituciones que no ocasionen algún percance.

 

 

Actividades.

 

  • Parecidas a la fase anterior.

 

  • Establecer prioridad para los cambios que mejoran el desempeño y eliminan errores. La mayor prioridad debe otorgarse para realizar los cambios que eliminen errores y mejoren el desempeño del sistema.

La menor prioridad se debe dar a los trabajos de extensiones del sistema o embellecimiento de interfaces.

 

 

Terminación.

 

  • No hay tal, puede ser un proceso infinito, sólo se hacen algunas adaptaciones pertinentes a las nacientes necesidades.

 

  • Se hace mantenimiento si los cambios se hacen fácilmente, cuando requieren de mucho esfuerzo pasamos a la fase de preservación (Sistema Obsoleto), en donde solo se trata de "mantener con vida" al sistema sin hacerlo evolucionar.

 

Con esto termina el macroproceso de desarrollo, en el cual no hay modelado de objetos. Tiene características y actividades con cierto objetivo para generar determinados productos.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

El Microproceso se aplica para generar cada uno de los prototipos o versiones esperadas por el macroproceso. Corresponde a la visión de un ingeniero de sistemas o grupo de ingenieros que son responsables de desarrollar una versión completa.

 

El microproceso ya se puede asociar con el modelado de objetos, visto con el modelado UML.

 

 

Identificar Clases y Objetos.

 

 

Objetivo.

 

  • Descubrir (análisis), inventar (diseño) y reorganizar las clases y los objetos.

Mientras que en el Macroproceso se identifican primero los requerimientos del sistema y se hacía análisis para entender el problema; el complemento de esta tarea es identificar las clases y objetos. Para la notación UML se añade la identificación de casos de uso que corresponde a la captura de los requerimientos del sistema.

 

Productos.

 

  • Diccionario de abstracciones.

 

 

Actividades.

 

  • Generar candidatos para las clases y objetos.

Una manera de rescatar las clases candidatas, es a partir de la descripción del problema, encontrar los sustantivos. Éstos suelen ser clases del dominio del problema. Aunque esta es una buena técnica, se puede caer en confusiones al partir de un problema no descrito correctamente.

Se puede especificar por medio de casos de uso (funcionalidades del sistema) y por medio de escenarios.

 

 

Terminación.

 

  • Diccionario suficientemente estable.

 

 

 

Una vez entendida una parte del sistema y expresada en abstracciones de clases y objetos, se identifica la semántica de las clases.

 

 

Identificar la semántica

de clases y objetos.

 

 

Objetivo.

 

  • Asociar atributos y comportamiento a las clases identificadas en la fase anterior.

 

De la fase anterior, donde se identificaron las clases candidatas, se ve qué atributos y métodos se le asociarán como parte de su responsabilidad.

Identificar la semántica implica asociar a las clases los métodos o responsabilidades que realizarán para expresar cierto comportamiento.

Se asocian a las clases los atributos que representan los datos que las clases deben saber para realizar sus operaciones a través de sus métodos.

Es suficiente identificar que una clase tiene un método pero no se definen parámetros ni tipos ni el tipo del resultado que va a regresar ese método.

Esta identificación de semántica y las interfaces se puede posponer hasta la implementación, porque ya se conoce el lenguaje y las cosas que éste ofrece (especificaciones de tipos, parámetros, etc.)

 

 

 

 

Productos.

 

  • Refinamiento del diccionario asignando responsabilidades, métodos y los atributos a las clases.

 

  • Especificación de abstracciones.

 

  • Interfaces en el lenguaje de programación.

Aquí debe pensarse en un diseño de implementación; se pueden detallar las clases con aspectos dependientes del lenguaje de programación.

 

  • Diagramas de Objetos.

Refuerzan la semántica dinámica, especifica como un objeto de una clase envía mensaje a otro para realizar la operación.

 

  • Diagramas de máquinas de estados finitos.

Permiten expresar para algunas clases si sus objetos pasan por diferentes estados que dependen de las operaciones que se han ejecutado sobre el objeto.

Por ejemplo el objeto documento puede pasar por los siguientes estados: creación, edición y salvado.

 

 

Actividades.

 

  • Tomar escenarios generados por el macroproceso y repartir las actividades del escenario entre las abstracciones de clases. Luego, estas responsabilidades se convierten en los métodos de las clases.

 

  • Refinar cada clase revisando la semántica de los requerimientos.

 

 

  • Buscar patrones para la reutilización.

 

Todas estas actividades permiten desmenuzar los requerimiento de cada caso de uso y expresarlos como semántica de clases en términos de sus atributos y sus métodos.

 

Terminación.

 

  • El conjunto de métodos y atributos asignados a las clases es razonable y completo.

 

 

 

 

 

 

 

 

 

 

Indentificar relaciones

entre clases y objetos

 

Permite ver dependencias las relaciones entre las clases y objetos y su objetivo.

Identificar las relaciones entre las clases corresponde a la estructura estática, que permite saber cual clase necesita de otra, es decir, cómo se relacionan para ofrecer algunos servicios.

 

Las relaciones entre las clases son de asociación, agregación y herencia.

Las relaciones entre objetos se expresan mediante el envío de mensajes (invocación de métodos). Estos representan la estructura dinámica del modelo.

 

Objetivo.

 

  • Definir las relaciones de asociación,agregación y herencia (análisis), mecanismos de colaboración para implementación, categorías(agrupar clases en una unidad lógica), módulos (mapeo a archivos), subsistemas (diseño), instanciación de objetos de las clases, uso de objetos (implementación).

 

Productos.

 

  • Diagramas de clase, objetos, categorías, módulos, subsistemas.

Por ejemplo, con UML se puede tener:

  • Modelado de Estructuras (Conceptos :clases, relaciones entre clases)
  • Modelado de Comportamiento (Modelado de Interacción entre objetos)
  • Modelado de Arquitectura (Componentes, Diagramas de Deployment, Diagramas de Componentes)

 

 

Actividades.

 

  • Especificación de asociaciones.
  • Identificación de colaboraciones.
  • Refinamiento de asociaciones.

 

 

Terminación.

 

  • Relaciones suficientes para hacer la implementación.

 

 

 

 

 

 

 

 

 

Implementación de

clases y objetos

 

 

Objetivo.

 

  • Implementación de clases y objetos que permiten sugerir nuevas abstracciones para la siguiente iteración del microproceso, es decir, obtener prototipos.

 

 

 

Productos.

 

  • Diagramas
  • Código o pseudo-código

 

 

Actividades.

 

  • Escoger la representación de la implementación.
  • Definir los algoritmos e implementarlos.

 

 

Terminación.

 

  • Modelo ejecutable (o casi ejecutable si se trata de pseudocódigo) de las abstracciones.

 

 

El microproceso se repite iterativamente hasta llegar a una versión satisfactoria del prototipo para los requerimientos definidos.