Instituto Tecnológico Superior de Huatusco                                                    Asignatura: Fundamentos de I...
Instituto Tecnológico Superior de Huatusco                                                    Asignatura: Fundamentos de I...
Instituto Tecnológico Superior de Huatusco                                                     Asignatura: Fundamentos de ...
Instituto Tecnológico Superior de Huatusco                                                  Asignatura: Fundamentos de Ing...
Instituto Tecnológico Superior de Huatusco                                                      Asignatura: Fundamentos de...
Instituto Tecnológico Superior de Huatusco                                                     Asignatura: Fundamentos de ...
Instituto Tecnológico Superior de Huatusco                                                     Asignatura: Fundamentos de ...
Instituto Tecnológico Superior de Huatusco                                                     Asignatura: Fundamentos de ...
Instituto Tecnológico Superior de Huatusco                                                    Asignatura: Fundamentos de I...
Instituto Tecnológico Superior de Huatusco                                                     Asignatura: Fundamentos de ...
Instituto Tecnológico Superior de Huatusco                                                     Asignatura: Fundamentos de ...
Instituto Tecnológico Superior de Huatusco                                                      Asignatura: Fundamentos de...
Instituto Tecnológico Superior de Huatusco                                                     Asignatura: Fundamentos de ...
Instituto Tecnológico Superior de Huatusco                                                     Asignatura: Fundamentos de ...
Instituto Tecnológico Superior de Huatusco                                                  Asignatura: Fundamentos de Ing...
Instituto Tecnológico Superior de Huatusco                                                   Asignatura: Fundamentos de In...
Instituto Tecnológico Superior de Huatusco                                                      Asignatura: Fundamentos de...
Instituto Tecnológico Superior de Huatusco                                                     Asignatura: Fundamentos de ...
Instituto Tecnológico Superior de Huatusco                                                      Asignatura: Fundamentos de...
Instituto Tecnológico Superior de Huatusco                                                     Asignatura: Fundamentos de ...
Instituto Tecnológico Superior de Huatusco                                                      Asignatura: Fundamentos de...
Instituto Tecnológico Superior de Huatusco                                                    Asignatura: Fundamentos de I...
Upcoming SlideShare
Loading in...5
×

Modelo de diseño_iv

342

Published on

Muy bueno

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
342
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Modelo de diseño_iv

  1. 1. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Software Mini Caso de Estudio Contador de palabras Considere el problema de diseñar un producto que toma como entrada un nombre dearchivo y regresa el número de palabras endicho archivo, parecido a la utilidad de UNIX. La figura 13.3 ilustra el diagrama de flujo de datos. Existen cinco módulos. El módulo1er_nombre_archivo lee el nombre del archivo, el cual después se valida porvalidar_nombre_archivo. El nombre valido se pasa a contar_numero_de_palabras, que haceprecisamente eso. Las palabras contadas se pasan a formatear_palabras_contadas, y la cuentade palabras formateadas finalmente se pasa a desplegar_palabras_contadas para que sean lasalida. Examinando el flujo de datos, la entrada inicial es nombre_archivo. Cuando esto seconvierte en validado_nombre_archivo todavía es un nombre de archivo y por lo mismo no haperdido su cualidad de ser un dato de entrada. Pero considere el módulocontar_numero_de_palabras. Su entrada es validado_nombre_archivo y su salida espalabras_contadas. La salida de este módulo es totalmente diferente en cualidad a la entradadel producto completo. Queda claro que el punto de mayor abstracción de entrada es como seindica en la figura 13.3. Asimismo, aunque la salida de contar_numero_de_palabras pasa poralgún tipo de formateo, en esencia es una salida desde el momento en que emerge del módulocontar_numero_de_palabras. El punto de mayor abstracción de salida es el que se muestra enla figura 13.3. El resultado de dividir el producto utilizando estos dos puntos de mayor abstracciónse muestra en el cuadro estructurado de la figura 13.4, la cual también revela que el diagramade flujo de datos de la figura 13.3 es de alguna forma muy simple. El DFD no muestra el flujológico correspondiente a lo que sucede si el archivo especificado por el usuario no existe. Elmódulo leer_y_validar_nombre_archivo_ debe regresar una bandera_de_estatus paraejecutar_contar_palabras y se imprime algún tipo de mensaje de error. Pero, si el nombre esválido, se pasa a contar_numero_de_palabras. En general, donde exista un flujo de datoscondicional, se necesita un flujo de control correspondiente.
  2. 2. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Software En la figura 13.4, dos módulos tienen cohesión comunicacional,leer_y_validar_nombre_archivo y formatear_y_desplegar_palabras_contadas. Éstos debendividirse más adelante. El resultado final se muestra en la figura 13.5. Los ocho módulostienen cohesión funcional, ya sea con acoplamiento de datos o sin acoplamiento entre ellos.b) Ahora que el diseño de arquitectura se ha completado, el próximo paso es detallar eldiseño. Aquí, se escogen estructuras de datos y se seleccionan algoritmos. El diseño detalladode casa módulo se pasa a un programador para que lo implemente. Tal como con cualquier
  3. 3. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Softwareotra fase de la producción de software, las restricciones de tiempo normalmente requierenque la implementación se haga por un equipo en lugar de tener un solo programadorresponsable de codificar todos los módulos. Por esta razón, el diseño detallado de casamódulo se debe presentar para que pueda comprenderse sin hacer referencia a algún otromódulo. El diseño detallado de cuatro de los ocho módulos aparece en la figura 13.6; los otroscuatro módulos se presentan en un formato diferente. El diseño de la figura 13.6 es independiente del lenguaje de programación. Sinembargo, si la administración se decide por un lenguaje de implementación antes decomenzar el diseño detallado, la utilización de un lenguaje de descripción de programa (PDL,por sus siglas en inglés) para representar el diseño detallado es una alternativa atractiva (elpseudocódigo es un nombre primitivo del PDL). PDL esencialmente consiste en comentariosconectados por sentencias de control del lenguaje de implementación seleccionado. La figura13.7 muestra un diseño detallado de los cuatro módulos restantes del producto escrito en unPDL con cierto sabor de C++ o Java.
  4. 4. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Software Un PDL tiene la ventaja de que pos lo general es claro y conciso, y el paso de laimplementación normalmente consiste en traducir los comentarios en el lenguaje deprogramación correspondiente. La debilidad es que algunas veces existe una tendencia porparte de los diseñadores a adentrarse mucho en el detalle y generar una implementación delcódigo completo del módulo en lugar de un diseño detallado en PDL. Después de haberlodocumentado por completo y probado exitosamente, el diseño detallado se pasa al equipo deimplementación para codificarlo. Después el producto procede con el resto de las fases delciclo de vida del software clásico.
  5. 5. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de SoftwareExtensiones del análisis del flujo de datos El lector pudiera sentir que este ejemplo es algo artificial, debido a que el diagrama deflujo de datos (figura 13.3) tiene sólo un flujo de entrada y un flujo de salida. Para ver quésucede en situaciones más complejas considere la figura 13.8. Ahora existen cuatro flujos deentrada y cinco flujos de salida, una situación que corresponde más a la realidad. Cuando existen múltiples flujos de entrada y salida, la forma de procedes es encontrarel punto de mayor abstracción de entrada para cada flujo de entrada y el punto de mayorabstracción de salida para cada flujo de salida. Utilice estos puntos para dividir el diagramadel flujo de datos proporcionado en módulos con menos flujos de entrada-salida que eloriginal. Continúe de esta forma hasta que cada módulo resultante tenga alta cohesión. Porúltimo, determine el acoplamiento entre cada par de módulos y haga los ajustes necesarios. Elanálisis de flujo de datos se resume en Cómo realizar, cuadro 13.1.Análisis de transacciones Una transacción es una operación desde el punto de vista del usuario del software, talcomo “procesar una solicitud” o “imprimir una lista de las órdenes del día”. El análisis del flujode datos es inapropiado para el procesamiento de transacciones de un producto, en el cual unsinnúmero de operaciones relacionadas, similares en su estructura pero diferentes en detalle,se deben realizar. Un ejemplo típico es el software que controla un cajero automático. Elcliente inserta una tarjeta magnética dentro de una ranura, teclea una contraseña, despuésrealiza operaciones tales como depósitos a cuentas de cheques, ahorros o tarjetas de crédito,hace un retiro de una cuenta; o consulta el saldo de su cuenta. Este tipo de producto se ilustraen la figura 13.9. Una buena forma de diseñar dicho producto es dividirlo en dos partes, elanalizador y el despachador. El analizador determina el tipo de transacción y pasa estainformación al despachador, el cual realiza la transacción. Por otro lado, parece una pérdida de tiempo tener cinco módulos de edición muysimilares y cinco módulos de actualización muy similares. La solución es reutilizar elsoftware: un módulo de edición básico deberá diseñarse, codificarse, documentarse yprobarse, luego instanciarse cinco veces. Cada versión es ligeramente diferente, pero lasdiferencias son tan pequeñas que hacen que este enfoque valga la pena. Asimismo, un módulode actualización básico puede instanciarse cinco veces y modificarse ligeramente paracomplacer a cinco tipos de actualización diferentes. El diseño resultante tiene alta cohesión ybajo acoplamiento.El análisis de transacciones se resume en Cómo realizar, cuadro 13.2.
  6. 6. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de SoftwareElementos del Diseño de Datos Al igual que otras actividades de la ingeniería del software, el diseño de datos (algunasveces llamado arquitectura de datos) crea un modelo de datos o información que serepresenta con un alto grado de abstracción (la visión de los datos del cliente/usuario). Después, este modelo de datos se refina en representaciones que de maneraprogresiva tienen una implementación específica y que pueden procesarse mediante elsistema basado en computadora. En muchas aplicaciones de software la arquitectura de losdatos tendrá una profunda influencia sobre la arquitectura del software que los debeprocesar. La estructura de los datos siempre ha sido una parte importante del diseño delsoftware. Al nivel de los componentes del sistema, las estructuras del diseño de datos y losalgoritmos con que se manipulan son esenciales para la creación de aplicaciones de altacalidad. Al nivel de aplicación, la traducción de un modelo de datos (obtenido como una basede la ingeniería de requisitos) a una base de datos es esencial para alcanzar los objetivos denegocio de un sistema. Al nivel de negados, la colección de información almacenada en basesde datos dispersas y reorganizadas en una "conjunción de datos" permite la explotación dedatos o el descubrimiento de un conocimiento que puede tener un impacto sobre el éxito delmismo negocio. En cada caso, el diseño de datos juega un papel importante.Elementos del diseño arquitectónico El diseño arquitectónico para el software es el equivalente al plano de planta de unacasa. Este plano muestra la configuración general de las habitaciones, su tamaño, forma y lasrelaciones entre ellas, y las puertas y ventanas que permiten el movimiento hacia y desde loscuartos. El plano de planta proporciona una visión global de la casa. Los elementos del diseñoarquitectónico dan una visión general del software. El modelo arquitectónico [SHA96] se obtiene a partir de tres fuentes: 1) la informaciónacerca del dominio de aplicación para el software que se va a construir; 2) los elementos del
  7. 7. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Softwaremodelo de análisis específico, tales como diagramas de flujo de datos o clases de análisis, susrelaciones y colaboraciones para el problema que se tiene a la mano, y 3) la disponibilidad depatrones y estilos arquitectónicos.Elementos de diseño de interfaz El diseño de interfaz para software es el equivalente a un conjunto de dibujosdetallados (y especificaciones) para puertas, ventanas y utilidades externas de una casa. Estosdibujos representan el tamaño y forma de las puertas y ventanas, la manera en que operan, lamanera en que las conexiones de las utilidades (como agua, energía eléctrica, gas, teléfono)llegan a la casa y se distribuyen entre las habitaciones representadas en el plano de planta. Estos dibujos dónde está localizado el timbre de la puerta, si hay un intercomunicadorque anuncie la presencia de un visitante y cómo está instalado el sistema de seguridad. Enesencia, los dibujos (y especificaciones) detallados para las puertas, ventanas y utilidadesexternas indican cómo fluyen las cosas y la información desde y hacia la casa y dentro de lashabitaciones que son parte del plano de planta. Los elementos del diseño de interfaz parasoftware muestran cómo fluye la información hacia o fuera del sistema y cómo éste estácomunicado entre los componentes definidos como parte de la arquitectura. Existen tres elementos importantes del diseño de interfaz: 1) la interfaz con ti usuario(IU); 2) interfaces externas a otros sistemas, artefactos, redes u otros productores oconsumidores de información; y 3) interfaces internas entre varios componentes de diseño.Estos elementos de diseño de interfaz permiten al software comunicarse de manera externa ypermiten la comunicación y colaboración interna entre los componentes que pueblan laarquitectura del software. El diseño de la IU es una acción primordial de la ingeniería de software. El diseño deuna IU incorpora elementos estéticos (por ejemplo, distribución, color, gráficas, mecanismosde interacción), elementos ergonómicos (por ejemplo, información y ubicación de ladistribución, metáforas, navegación de la IU), y elementos técnicos (como patrones de la IU,componentes reutilizables). En general, la IU es un subsistema único dentro de la arquitecturade aplicación general. El diseño de las interfaces externas requiere información definitiva acerca de laentidad hacia donde se manda o recibe la información. En todos los casos, esta informacióndebe recopilarse durante la ingeniería de requisitos y verificarse una vez que comience eldiseño de la interfaz. El diseño de interfaces externas debe incorporar revisión de errores y(cuando sea necesario) características apropiadas de seguridad. El diseño de las interfaces internas está cercanamente alineado con el diseño al nivelde los componentes. Las realizaciones del diseño de clases de análisis representan todas lasoperaciones y esquemas de mensajes requeridos para permitir la comunicación ycolaboración entre las operaciones de varias clases.
  8. 8. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Software Cada mensaje debe ser diseñado para ajustarse a la transferencia de información derequisitos y los requerimientos funcionales específicos de la operación que ha sido solicitada. En algunos casos, una interfaz se modela de una manera muy parecida a una clase. ElUML define una interfaz de la siguiente manera [OMGOI] "Una interfaz es un determinante delas operaciones [públicas] visibles de manera externa de una clase, componente u otroclasificador (incluidos los subsistemas) sin especificación de estructura interna". Dicho de unmodo más simple, una interfaz es un conjunto de operaciones que describe parte delcomportamiento de una clase y proporciona acceso a esas operaciones. Por ejemplo, la función de seguridad de HogarSeguro emplea un panel de control quepermite al propietario de la casa controlar ciertos aspectos de la función de seguridad. En unaversión avanzada del sistema, las funciones del panel de control pueden implementarse víaPDA inalámbrico o teléfono móvil. La clase Panel de control (figura 9.5) proporciona el comportamiento asociado con unteclado y, por lo tanto, debe implementar operaciones de leerTeclaPresionada ydecodificarTecla ( ). Si estas operaciones se suministrarán a otra clase (en este caso, aPDAInaIámbrico y Teléfono Móvil), resulta inútil definir una interfaz como la que se muestraen la figura. La interfaz llamadaTeclado se muestra como un estereotipo de <<interfaz>> ocomo un círculo pequeño y etiquetado que se conecta a la clase con una línea. La interfaz sedefine sin atributos y con el conjunto de operaciones necesarias para lograr elcomportamiento de un teclado. La línea punteada con un triángulo abierto con un triángulo abierto en su extremo(figura 9.5) indica que: la clase PaneldeControl proporciona operaciones de Teclado como
  9. 9. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Softwareparte de su comportamiento. En UML esto se caracteriza como una realización. Esto es, partedel comportamiento de PaneldeControl se implementará al realizar las operaciones deTeclado. Estas operaciones se proporcionarán a otras clases que entren a la interfaz.Elementos de diseño al nivel de componentes El diseño al nivel de componentes para el software equivale a un conjunto de dibujosdetallados (y especificaciones) para cada cuarto en una casa. Estos dibujos muestran elalambrado y la instalación sanitaria dentro de cada cuarto, la ubicación de los receptáculoseléctricos e interruptores, llaves, lavabos, tinas, desagües y armarios. También describen lospisos que se usarán, los moldes que se aplicarán, y cualquier otro detalle asociado con elcuarto. El diseño al nivel de componentes para software describe por completo el detalleinterno de cada componente del software. Para lograrlo el diseño al nivel de componentes define estructuras de datos para todolos objetos de datos locales, así como detalle algorítmico para todo el procesamiento queocurre dentro de un componente y una interfaz que permite el acceso a todas las operacionesde los componentes (comportamientos). Dentro del contexto de la ingeniería del software orientada a objetos, un componentese representa a manera de diagrama en UML como se muestra en la figura 9.6. En esta figurase representa un componente llamado ManejoSensor (parte de la función de seguridad deHogarSeguro). El componente está conectado a una clase llamada Sensor, la cual está asignadaa éste mediante una flecha punteada. El componente Manejosensor realiza todas las funcionesasociadas con los sensores de HogarSeguro, entre las que se encuentran su monitoreo yconfiguración. Los detalles de diseño de un componente se pueden modelar a muchos gradosdistintos de abstracción. En la representación del procesamiento lógico se puede utilizar undiagrama de actividad. El flujo detallado de procedimiento para un componente puederepresentarse, ya sea mediante un pseudocódigo, o de algún formato diagramático (porejemplo, un diagrama de actividad o un diagrama de flujo).Elementos de diseño al nivel del despliegue Los elementos de diseño al nivel del despliegue indican cómo se ubicarán lafuncionalidad y los subsistemas dentro del entorno computacional físico que soportará alsoftware. Por ejemplo, los elementos del producto HogarSeguro están configurados paraoperar dentro de tres entornos de computación primarios: una PC doméstica, el panel de
  10. 10. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Softwarecontrol de HogarSeguro y un servidor ubicado en CPI Corp. (lo que proporciona acceso alsistema a través de Internet). Durante el diseño se desarrolla un diagrama de despliegue en UML y después se refina,como se muestra en la figura 9.7. En ésta se muestran tres ambientes computacionales (enrealidad, debería haber más, si se incluyen sensores, cámaras y otros). Se indican lossubsistemas (funcionalidad) que se alojan dentro de cada elemento de cómputo. Por ejemplo, la computadora personal aloja subsistemas que implementan seguridad,vigilancia, administración del hogar y características de comunicación. Además, se hadiseñado un subsistema de acceso externo para controlar todos los intentos de acceso alsistema HogarSeguro desde una fuente externa. Cada subsistema seria elaborado para indicarlos componentes que implementa. El diagrama mostrado en la figura 9.7 está en forma de descriptor. Esto significa que eldiagrama de despliegue muestra el entorno computacional, pero no indica de manera explícitadetalles de configuración. Por ejemplo, no se identifica la "computadora personal". Podría seruna "Wintel" PC o una Macintosh, una estación de trabajo Sun o una Linux-box. Estos detallesse proporcionan cuando el diagrama de despliegue se revisa en forma de instancia duranteetapas posteriores del diseño o cuando comienza la construcción. Se identifica cada instanciadel despliegue (una configuración de hardware con un nombre específico).Diseño orientado a objetos Como ya antes se estableció, el proceso Unificado asume conocimiento previo deldiseño orientado a objetos (OOD, por sus siglas en inglés). De acuerdo con esto. Ahoradescribimos el OOD y después discutimos el flujo de trabajo del Proceso Unificado. El propósito del OOD es diseñar el producto en términos de objetos, esto es,instalaciones de las clases y subclases extrudidas durante el análisis orientado a objetos. Loslenguajes clásicos tales como C, COBOL y el FORTLAN no soportan objetos. Esto pareceríaimplicar que el OOD está disponible sólo para usuario de lenguaje orientado a objetos comoSmalltalk [Goldberg y Robson, 1989], C++ [Stroustrup, 2000], Ada 95 [ISO/IEC 8652, 1995] yJava [Flanagan, 2002].
  11. 11. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Software Este no es el caso. Aunque el OOD como tas es soportado por los lenguajes clásicos, sepuede usar un gran subconjunto del OOD. Una clase es un tipo de dato abstracto con herenciay un objeto es una instancia de clase. Cuando se unas un lenguaje de implementación que nosoporte la herencia, la solución es usar aquellos aspectos del OOD que puedan funcionardentro del lenguaje usado en el proyecto, esto es utilizar el diseño de datos de tipo abstracto.Los datos de tipo abstracto prácticamente pueden implementar en cualquier lenguaje quesoporte sentencias type. Incluso en el lenguaje clásico que no soporte sentencias type comotal, y por ende no soporte datos de tipo abstracto, aun así todavía pudiera implementar laencapsulación de datos. Los dos aspectos claves del OOD son completar el diagrama de clases y realizar eldiseño detallado. Respecto al primer paso, completar el diagrama de clases, se necesitandeterminar los formatos de los atributos y asignarlos métodos a las clases correspondientes. Por lo general los formatos de los atributos pueden deducirse directamente delanálisis de artefactos. Por ejemplo, es Estados Unidos las especificaciones pudieran establecerque una fecha como la de diciembre 3, 1947, se representa como 12/03/1947 (formatomm/dd/yyyy) o en Europa como 03/12/1947 (formato dd/mm/yyyy). Pero sin importar cuálsea la convención para las fechas utilizadas se necesita un total de 10 caracteres. La información para determinar los formatos se obtiene durante el flujo de trabajo delanálisis, así que seguramente se podrán agregar los diagramas de clases en ese momento. Sinembargo, el paradigma orientado a objetos es iterativo. Cada iteración genera unamodificación a lo que ya se había terminado. Por razones prácticas, entonces la informacióndebe agregarse a los diagramas UML lo más tarde que se pueda. Otro componente principal del primer paso OOD, es asignar los métodos(implementación de operaciones) a las clases. A identificación de todas las operaciones delproducto se realiza examinando los diagramas de interacción de cada escenario. Esto essencillo, la parte difícil es determinar cómo decidir por métodos asociar cada clase. Un método puede asignarse ya sea a una clase o a un cliente que envía un mensaje alobjeto de dicha clase. (Un cliente de un objeto es una unidad de programas que envíamensajes al objeto). Un principio que puede emplearse para ayudar al decidir cómo asignaruna operación es esconder la información. Esto es, las variables de estado de una clase debendeclarase como privadas (accesibles sólo dentro del objeto de dicha clase) o protegidas(accesibles sólo dentro del objeto de dicha clase o de una subclase de dicha clase). De acuerdocon esto, las operaciones desarrolladas sobre las variables de estado deben ser locales para laclase. Un segundo principio, es que sus varios clientes de un objeto invocan una operación esparticular, tiene sentido tener una copia única de la operación implementada como un métododel objeto, en lugar de tener una copia de cada cliente del objeto. Un tercer principio que puede emplearse para ayudar a decidir dónde ubicar unmétodo es utilizar el diseño controlado por responsabilidades. Si un cliente envía un mensaje
  12. 12. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Softwarea un objeto, entonces el objeto es responsable en cada aspecto de llevar a cabo la solicitud delcliente. El cliente no necesita saber cómo se lleva a cabo su solicitud y no se le permite saber,una vez que la solicitud se ha llevado a cabo, el control regresa al cliente. Hasta ese punto,todo lo que el cliente sabe es que la solicitud se llevó a cabo, pero aún no tiene idea de cómo sehizo. Caso de estudio Diseño orientado a objetos: el caso de estudio del problema del elevador.Paso 1. Completar el diagrama de Clases. Un flujo de trabajo del diseño de un diagrama de clases (figura 13.11) se obtieneagregando las operaciones (métodos) al diagrama de clases de la figura 12.9 (en el caso deuna implementación Java, se necesitan dos clases adicionales. Aplicación Elevadorcorresponde a la función main de C++ y Utilidades Elevador contiene las rutinas de Java quecorresponden a las funciones de C++ declaradas como externas a las clases de C++). Considere la segunda iteración de la tarjeta CRC para el controlador del elevador(figura 12.9). Las responsabilidades caen en dos grupos. Tres responsabilidades, 8 iniciarcronómetro, 10 revisar solicitudes y 11 actualizar solicitudes, se asignan al controlador delelevador con base en el diseño guiado por responsabilidades; dichas tareas se llevan a cabopor el controlador del elevador. Por otro lado, las ocho responsabilidades restantes (eventos 1 al 7 y evento 9) tienenla forma “evitar un mensaje a otra clase para decirle que haga algo”. Esto implica que elprincipio que debe usarse para asignar el método correspondiente a las clases otra vez debe
  13. 13. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Softwarecontrolarse por el diseño correspondiente a las clases otra vez debe controlarse por el diseñode responsabilidades. Además, debido a preocupaciones de seguridad, el principio deesconder información aplica por igual en los ocho casos. Por estas dos razones, los métodos cerrar puertas y abrir puertas se asignan a la clasePuertas Elevador. Esto es cliente de Puertas Elevador (en este caso una instancia de la claseControlador Elevado) envía un mensaje a un objeto de la clase Puertas Elevador para cerrar oabrir las puertas del elevador, y la solicitud se lleva a cabo por el método correspondiente.Cada aspecto de estos dos métodos se encapsula dentro del Puertas Elevador. Además, elesconder información genera una independencia verdadera de la clase Puertas Elevador, de lacual sus instancias pueden dirigirse en el diseño detallado e implementarseindependientemente y reutilizarse más tarde en otros productos. Los dos mismos principios de diseño se aplican a los métodos bajar un piso y subir unpiso, y se asignan a la clase Elevador. No hay necesidad de que una instrucción explicitaocasione que le elevador se detenga. Si no se invoca ninguno de estos dos métodos, elelevador no puede moverse; no existe otra forma de modificarse, el estado de un elevadordistando a invocar alguno de estos dos métodos. Finalmente, los métodos apagar botón y encender botón se asignan tanto a BotónElevador como a Botón Piso. La razón aquí es la misma que la de los métodos asignados a laclase Puertas Elevador y a la clase Elevador. Primero, el principio del diseño guiado FIGURA 13.12 El diseño detallado del método cicloDeEventosElevador.
  14. 14. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Softwarepor responsabilidades se requieren que los botones tengan control total sobre si estánencendidos o apagados. Segundo, el principio de esconder información requiere que el estadointerno de un botón permanezca escondido. Los métodos que encienden o apagan un botóndel elevador deben ser locales a la clase Botón Elevador y de manera similar para la claseBotón Piso. Para hacer uso del polimorfismo y del ligamiento dinámico, los métodos encenderbotón y apagar botón se declaran abstractos (virtuales) en la clase Botón.Paso 2 Realizar el diseño detallado. Ahora se desarrolla un diseño detallado para todas las clases. Se puede usar cualquiertécnica que se ajuste. El diseño detallado del método ciclo de eventos del elevador se muestraen la figura 13.12. Aquí se usó PDL (pseudocódigo), pero una representación tabular de igualforma puede ser efectiva. Ahora consideramos el diseño orientado a objetos del caso de estudio de OsbertOglesby.Diseño orientado a objetos: el caso de estudio de Osbert Oglesby El diseño orientado a objetos consiste en dos pasos.Paso 1. Completar el diagrama de clases El diagrama de las clases final del caso de estudio de Osbert Oglesby se muestra en lafigura 13.13. La Clase Fecha definida por el usuario se traza punteada para representar que senecesita Únicamente para la Implementación en C++; Java tiene clases ínterconstruidas paramanejar fechas, incluyendo java,tcxt.Dateformat y Java.util.Calendar. Enseguida, se deducenlos formatos de los atributos de las clases a partir de los requerimientos. El resultado semuestra en la figura 13.14. Los métodos del producto aparecen en los distintos diagramas de interacción. La tareadel diseñador es decidir a qué clase se debe asignar cada método. Por ejemplo, la conversiónen un producto de software orientado a objetos es que cada atributo asociado a una claseincluye un método setAtributo, utilizado para asignar un valor específico, a dicho atributo, yun método getAtributo, el cual devuelve el valor actual del atributo.
  15. 15. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Software Por ejemplo, considere el método setTítulo, utilizado para asignar el nombre de unapintura él un objeto pintura. En el paradigma clásico, necesitaríamos las funcionesponer_título_obra_maestra, poner_título_trabajo_maestro y poner_título_otra_pintura. Sinembargo. El paradigma orientado a objetos soporta la herencia. Por lo mismo el métodosetTitulo deberá asignarse a la Clase Pintura.
  16. 16. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de SoftwarePaso 2. Realizar el diseño detallado Enseguida, se construye el diseño detallado, tomando cada método e identificando quéhace. Las figuras 13.15 y 13.16 muestran el diseño detallado (en un PDL para C++) de los dosmétodos del caso de estudio Osbert Oglesby. La figura 13.05 muestra el diseño detallado delmétodo getAlgoritmoPrecio de la clase CalcularPrecioObraMaestra, y la figura 13.16 muestrael diseño detallado del método getAlgoritmoPrecio de la clase CalcularPrecioTrabajoMaestro.
  17. 17. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de SoftwareEl flujo de trabajo del diseño La entrada del flujo de trabajo del diseño son los artefactos del flujo de trabajo delanálisis. Durante el flujo de trabajo del diseño, estos artefactos se repiten e incrementan hastaque están en un formato en el que los programadores pueden utilizarlos. Un aspecto deiteración y de los incrementos es la identificación de método y su ubicación en las clasesapropiadas. Otro aspecto es realizar el diseño detallado. Estos dos pasos constituyen elcomponente del diseño orientado a objetos del flujo de trabajo del diseño. Además, al realizar el diseño orientado a objetos., se tienen que tomar muchasdecisiones como parte del flujo de trabajo del diseño. Una de estas decisiones es la seleccióndel lenguaje de programación en el cual se implementará el producto de software. Otradecisión es que tanto se pueden reutilizar los productos de software existentes en el productode software nuevo que se desarrollará. Además, los productos de software grandes por logeneral se implementan en una red de computadoras; por esto es que otra decisión del diseñoes la ubicación de cada componente de software en el en el componente de hardware en elcual se ejecutará. La mayor motivación detrás del desarrollo del Proceso Unificado fue presentar unametodología que pudiera ser utilizada para desarrollar productos de software a gran escala,típicamente, 500 000 líneas de código o más, Por otro lado, las implementaciones del caso deestudio Osbert Oglesby en los apéndices H e I son menores a 5 0OO líneas de C++ y Java,respectivamente. En otras palabras el Proceso Unificado está dirigido principalmente hacia,productos del software de al menos cientos de veces mayores que el caso de estudio OsbertOglesby. De acuerdo con esto. Muchos aspectos del Proceso Unificado no aplican para estecaso de estudio. Por ejemplo, una parte importante del flujo de trabajo del análisis es dividir elproducto de software en paquetes de análisis. Cada paquete se forma de un conjunto de clasesrelacionadas, generalmente relevantes a un pequeño subconjunto de actores, que puede
  18. 18. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Softwareimplementarse como una sola unidad. Por ejemplo, cuentas por pagar, cuentas por cobrar y ellibro mayor son típicamente paquetes de análisis. El concepto que sustenta el análisis de lospaquetes es que es más fácil desarrollar productos de software pequeños que productos desoftware grandes. De acuerdo con esto, un producto de software grande es más fácil dedesarrollar si es posible dividirlo en paquetes relativamente independientes. La idea de dividir un flujo de trabajo grande en flujos de trabajo pequeñosrelativamente independientemente se lleva a cabo a lo largo del flujo de trabajo del diseño.Aquí, el objetivo es dividir flujo de trabajo de la implementación en piezas manejables,denominadas subsistemas. De nuevo no tiene sentido dividir el caso de estudio Osbert Oglesby en subsistemas, elcaso de estudio es demasiado pequeño.Existen dos razones del porque los flujos de trabajos grandes se dividen en subsistemas: 1. Es más fácil implementar varios subsistemas pequeños que un sistema grande. 2. Si los subsistemas a implementan en verdad son relativamente independientes. Entonces pueden implementarse por equipos de programación que trabajen enparalelo. Esto genera que el producto de software como un todo se entregue antes. Se deberecordar que la arquitectura de un producto de software incluye varios componentes y cómoencajan en conjunto. La ubicación de los componentes en los subsistemas es una parteimportante de las tareas de arquitectura. Decidir la arquitectura de un producto de softwarede ningún modo es fácil y, en todos los productos de software excepto los pequeños, unespecialista los desarrolla. El arquitecto de software. Además de ser un experto técnico, un arquitecto necesita saber cómo negociar. Unproducto de software tiene que satisfacer los requerimientos funcionales, esto es, los casos deuso. También necesitan satisfacer los requerimientos funcionales, incluyendo portabilidad,confiabilidad, fortaleza, capacidad de mantenimiento, seguridad, confiabilidad, etc. Peronecesita hacer todas estas cosas dentro del presupuesto y tiempo. Casi nunca es posibledesarrollar un producto de software que satisfaga todos requerimientos, tanto funcionalescomo no funcionales, y que termine dentro del costo y tiempo estimado: casi siempre tienenque hacerse compromisos. El cliente tiene que perdonar algunos de los requerimientos. Incrementar el presupuesto, o mover la fecha límite de entrega, o hacer más dealgunas de estas cosas. El arquitecto debe ayudar al cliente en su decisión comentandoclaramente las fortalezas y debilidades. En algunos casos las fortalezas y debilidades son obvias. Por ejemplo, el arquitectopudiera señalar que un conjunto de requerimientos de seguridad que se acopien al nuevoestándar de alta seguridad necesitarán tres meses más y 350 000 dólares más paraincorporarlos en el producto de software. Si el producto es una red internacional de la banca,el punto se somete él discusión, no existe forma de que el cliente pudiera estar de acuerdo encomprometer la seguridad. Sin embargo, en algunos otros casos, el cliente necesita tomar
  19. 19. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Softwaredecisiones críticas respecto a las fortalezas y debilidades y tiene que apoyarse en laexperiencia técnica del arquitecto para que lo ayude a tomar decisión correcta para el negocio.Por ejemplo. El arquitecto pudiera señalar que si se pospone un requerimiento en particularhasta que el producto de software se haya entregado y se encuentre en mantenimientopudiese ahorrar 150 000 dólares por el momento, pero costaría 300 000 dólares incorporarlomás tarde. La decisión sobre posponer o no el requerimiento solo la puede tomar el cliente,pero él o ella necesitan la experiencia técnica del arquitecto para que los ayude a tomar ladecisión correcta. La arquitectura de un producto de software es un factor vital que determinaría si elproducto entregado es un éxito o un fracaso. Y las decisiones críticas referentes a laarquitectura tienen que tomarse mientras se realiza el flujo de trabajo del diseño. Si el flujo detrabajo de los requerimientos fue muy mal hecho, aún es posible tener un proyecto exitoso,proporcionando más tiempo e invirtiendo, más dinero en el flujo de trabajo del análisis. Asimismo, si el flujo de trabajo del análisis es inadecuado, es posible recuperarsehaciendo un esfuerzo extra como parte del flujo de trabajo del diseño. Pero, si la arquitecturano es óptima, no hay manera de recuperarse; se debe rediseñar de inmediato la arquitectura.Por ello es esencial que el equipo de desarrollo incluya un arquitecto con la experienciatécnica necesaria y habilidades sociales.El flujo de trabajo de las pruebas: diseño El objetivo de probar el diseño es verificar que se han incorporad correctamente y porcompleto las especificaciones dentro del diseño así como asegurar la rectitud del mismo. Porejemplo, el diseño no debe tener fallas lógicas y todas las interfaces deben estar definidas demanera correcta Es importante que se detecte cualquier falla en el diseño antes de comenzar acodificar; de lo contrario, el costo de reparar tales fallas será considerablemente alto. Lasfallas del diseño pueden detectarse por medio de inspecciones al diseño así como derevisiones del diseño. Cuando el producto es orientado a transacciones, la inspección del diseño debereflejarlas [Beizer 1990]. Deben calendarizarse inspecciones que incluyan todos los tiposposibles de transacciones. El revisor debe relacionar cada transacción en el diseño con lasespecificaciones, mostrando cómo es que la transacción surge del documento deespecificaciones. Por ejemplo, si la aplicación es un cajero automático, una transaccióncorresponde a cada operación que puede realizar el cliente, como depositar o retirar de unacuenta de tarjeta de crédito. En otros casos, la correspondencia entre especificaciones ytransacciones no es necesariamente una a una. En un sistema de control de tráfico, por ejemplo, si un automóvil que se encuentrasobre un sensor genera que el sistema decida cambiar una luz en particular, de rojo a vade en15 segundos, entonces los siguientes impulsos de dicho sensor pudieran ignorarse. De manerainversa, para aumentar el flujo del tráfico, un simple impulso pudiera ocasionar que toda unaserie de luces cambiara de rojo a verde.
  20. 20. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Software El restringir a los revisores a inspecciones guiadas por transacciones no detecta loscasos en los cuales los diseñadores pasaron por alto algunas instancias de las transaccionesrequeridas por las especificaciones. Para poner un ejemplo extremo, las especificaciones parael controlador dé trafico pudieran estipular que, entre las 11:00 p.m. y las 6:00 a.m. todas lasluces tienen que parpadear en amarillo en una dirección y en rojo en la dirección. Si los diseñadores pasaron por alto esta estipulación, entonces las transaccionesgeneradas entre las 11:00 p m. y 6:00 a.m. no serán incluidas en diseño; y, no podrán probarseen una inspección al diseño basado en transacciones. Por esto, no es adecuado calendarizarinspecciones al diseño que sólo se: controlen por transacciones; las inspecciones controladaspor especificaciones, también son esenciales para asegurar que no se ha pasado por alto o malinterpretado alguna parte del documento de especificaciones.El flujo de trabajo delas pruebas: el caso de estudio de Osbert Oglesby Ahora que aparentemente el diseño está completo se debe revisar todos los aspectosdel diseño del caso de estudio de Osbert Oglesby por medio de una inspeccione del diseño. Enparticular, se examinar cada artefacto del diseño incluso si no se encontraron falla, es posibleque el diseño cambie otra vez, radicalmente, cuando el caso de estudio Osbert Oglesby seaimplementado.Técnicas formales para el diseño detallado Ya se ha presentado una técnica para el diseño detallado. Después se aplicó al diseñodetallado utilizando cuadros de flujo. Además del refinamiento escalonado, se pueden usartécnicas formales para mejorar el diseño detallado. Desarrollar en paralelo las pruebas y eldiseño detallado, así corno probar el código es otra cosa muy diferente. Las técnicas formales aplicadas al diseño detallado pueden ayudar de tres maneras: 1. El arte de probar la rectitud es tal que, aunque por lo general DO pueda aplicarse al producto completo, pueda aplicarse a piezas modulares de un producto. 2. Desarrollar las pruebas junto con el diseño detallado conducirá a un diseño con menos fallas que si no se hubieran realizado las pruebas. 3. Si el mismo programador es el responsable del diseño detallado y de la implementación, entonces dicho programador estará confiado en que el diseño detallado es correcto Esta entonces actitud positiva hacia el diseño conducirá a menos fallas en el código.Técnicas de diseño de tiempo-real El software de tiempo-real se caracteriza por restricciones de tiempo esto es,restricciones de tiempo de tal naturaleza que si no se cumple una restricción, se pierdeinformación. En lo particular, cada entrada debe procesarse antes de que llegue la siguienteentrada. Un ejemplo de estos sistemas es un reactor nuclear controlado por computadora. Lasentradas como la temperatura del núcleo y el nivel de agua en la cámara del reactor
  21. 21. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Softwarecontinuamente se envían a la computadora la cual lee el valor de cada entrada y analiza elprocesamiento necesario antes de que llegue la siguiente entrada. Otro ejemplo es una unidadde cuidado intensivo controlado por computadora. Existen dos tipos de datos de los pacientes:información de rutina como pulsos del corazón, temperatura y presión de la sangre de cadapaciente, e información de emergencia, cuando el sistema deduce que la condición de unpaciente es grave. Cuando ocurren tales emergencias, el software; debe procesar tanto lasentradas de rutina como las entradas de emergencia de uno o más pacientes.Una característica de muchos sistemas de tiempo-real es que se implementan en Hardwaredistribuido. Por ejemplo, el software que controla un aeronave de guerra pudiera tener queimplementarse en cinco computadoras para controlar la navegación, otra el sistema dealarmas, una tercera para contramedidas electrónicas, una cuarta para controlar el hardwarede vuelo como los alerones y los motores, y una quinta para proponer tácticas de combate. Ya que el hardware no es totalmente confiable, pudiera haber computadoras derespaldo adicionalmente que automáticamente reemplazarían una unidad que funciones demanera incorrecta. El diseño de tal sistema no sólo tiene implicaciones en las comunicaciones,sino que los elementos de tiempo, sobre aquellos del tipo descritos surgen comoconsecuencias de la naturaleza distribuida del sistema. Por ejemplo, bajo condiciones decombate, la computadora táctica pudiera sugerir que el piloto se eleve, mientras que lacomputadora de armas recomiende que el piloto vaya en picada para poder lanzardeterminada arma en condiciones óptimas. Sin embargo, el piloto humano decide mover lapalanca hacia la derecha, enviando una señal a la computadora de vuelo para que haga losajustes necesarios para que el avión se deslice en la dirección indicada. Toda esta informacióndebe manejarse con cuidado de tal forma que el movimiento real debe pasarse a lascomputadoras tácticas y de armas para que puedan formular sugerencias nuevas a la luz decondiciones actuales, en lugar de las sugeridas. Otra dificultad de los sistemas de tiempo-real es el problema de la sincronización.Suponga que se va implementar un sistema de tiempo-real en hardware distribuido.Situaciones tales como el estacionamiento (o abrazo mortal) pueden surgir cuando dosoperaciones que tienen uso exclusivo de cierta información solicitan uso exclusivo de lainformación que tiene la otra. Por supuesto, el estancamiento no sólo ocurre en sistemas de tiempo-real,implementados en hardware distribuido. Pero es particularmente problemático en sistemasde tiempo-real en los cuales no hay control sobre el orden en que llegan las entradas. Y lasituación puede complicarse por la naturaleza distribuida del hardware. Además delestancamiento, son posibles otros problemas de sincronización incluyendo condiciones decompetencia. Es claro que a partir de estos ejemplos la principal dificultad del diseño de sistemas detiempo-real es asegurar que las restricciones de tiempo se cumplan en el diseño. Esto es latécnica de diseño debe proporcionar un mecanismo para revisar que cuando se implemente eldiseño sea capaz de leer y procesar la información que llegue en la tasa requerida. Por lo
  22. 22. Instituto Tecnológico Superior de Huatusco Asignatura: Fundamentos de Ingeniería de Softwaremismo, debe ser posible mostrar que los elementos de sincronización también se hanmanejado correctamente en el diseño. Desde el principio de la era de las computadoras, muchos de los avances de latecnología de hardware han sobrepasado, casi en todos los aspectos, los avances en latecnología de software. Por lo mismo aunque exista el hardware para manejar cualquieraspecto de los sistemas de tiempo-real antes descritos. La tecnología de diseño de software seha retrasado considerablemente. En algunas áreas, de ingeniería de software de tiempo-real.Se han hecho grandes procesos. Desafortunadamente, el diseño de software aún no haalcanzado el mismo nivel de sofisticación. En verdad se han dado grandes progresos, pero larealidad es que aún no es comparable a lo que se ha alcanzado con las técnicas de análisis. Yaque casi cualquier técnica de diseño para sistemas de tiempo-real es preferible a no unasninguna técnica, un sinnúmero de técnicas de diseño de tiempo-real se usan en la práctica.Pero aún hay un largo camino antes de que sea posible diseñar sistemas de tiempo-real comolos antes descritos y que estemos seguros que, antes de que el sistema sea implementado, secumplirá cualquier restricción de tiempo-real y no surgirán problemas de sincronización. Las técnicas antiguas de diseño de tiempo-real son extensiones delas técnicas que notrabajan en tiempo-real. Por ejemplo, el desarrollo estructurado de sistemas en tiempo-real(SDRTS) [Ward y Meilor, 1995] en esencia es una extensión del análisis de sistemaestructurado, del análisis de flujo de datos y del análisis de transacciones llevadas haciasoftware de tiempo-real. Esta técnica de desarrollo incluye un componente para el diseño detiempo-real. Se describen técnicas más nuevas en Liu [2000] y en Gomaa [2000]. Como se estableció con anterioridad, es desafortunado que en la realidad el diseño entiempo-real no esté tan avanzado como uno quisiera. Sin embargo, se están haciendoesfuerzos para mejorar la información.

×