Modelo de diseño_iv

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 de
archivo 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ódulo
1er_nombre_archivo lee el nombre del archivo, el cual después se valida por
validar_nombre_archivo. El nombre valido se pasa a contar_numero_de_palabras, que hace
precisamente eso. Las palabras contadas se pasan a formatear_palabras_contadas, y la cuenta
de palabras formateadas finalmente se pasa a desplegar_palabras_contadas para que sean la
salida.

Examinando el flujo de datos, la entrada inicial es nombre_archivo. Cuando esto se
convierte en validado_nombre_archivo todavía es un nombre de archivo y por lo mismo no ha
perdido su cualidad de ser un dato de entrada. Pero considere el módulo
contar_numero_de_palabras. Su entrada es validado_nombre_archivo y su salida es
palabras_contadas. La salida de este módulo es totalmente diferente en cualidad a la entrada
del producto completo. Queda claro que el punto de mayor abstracción de entrada es como se
indica en la figura 13.3. Asimismo, aunque la salida de contar_numero_de_palabras pasa por
algún tipo de formateo, en esencia es una salida desde el momento en que emerge del módulo
contar_numero_de_palabras. El punto de mayor abstracción de salida es el que se muestra en
la figura 13.3.

El resultado de dividir el producto utilizando estos dos puntos de mayor abstracción
se muestra en el cuadro estructurado de la figura 13.4, la cual también revela que el diagrama
de flujo de datos de la figura 13.3 es de alguna forma muy simple. El DFD no muestra el flujo
lógico correspondiente a lo que sucede si el archivo especificado por el usuario no existe. El
módulo leer_y_validar_nombre_archivo_ debe regresar una bandera_de_estatus para
ejecutar_contar_palabras y se imprime algún tipo de mensaje de error. Pero, si el nombre es
válido, se pasa a contar_numero_de_palabras. En general, donde exista un flujo de datos
condicional, se necesita un flujo de control correspondiente.


En la figura 13.4, dos módulos tienen cohesión comunicacional,
leer_y_validar_nombre_archivo y formatear_y_desplegar_palabras_contadas. Éstos deben
dividirse más adelante. El resultado final se muestra en la figura 13.5. Los ocho módulos
tienen 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 el
diseño. Aquí, se escogen estructuras de datos y se seleccionan algoritmos. El diseño detallado
de casa módulo se pasa a un programador para que lo implemente. Tal como con cualquier


otra fase de la producción de software, las restricciones de tiempo normalmente requieren
que la implementación se haga por un equipo en lugar de tener un solo programador
responsable de codificar todos los módulos. Por esta razón, el diseño detallado de casa
módulo se debe presentar para que pueda comprenderse sin hacer referencia a algún otro
módulo. El diseño detallado de cuatro de los ocho módulos aparece en la figura 13.6; los otros
cuatro módulos se presentan en un formato diferente.

El diseño de la figura 13.6 es independiente del lenguaje de programación. Sin
embargo, si la administración se decide por un lenguaje de implementación antes de
comenzar 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 (el
pseudocódigo es un nombre primitivo del PDL). PDL esencialmente consiste en comentarios
conectados por sentencias de control del lenguaje de implementación seleccionado. La figura
13.7 muestra un diseño detallado de los cuatro módulos restantes del producto escrito en un
PDL con cierto sabor de C++ o Java.


Un PDL tiene la ventaja de que pos lo general es claro y conciso, y el paso de la
implementación normalmente consiste en traducir los comentarios en el lenguaje de
programación correspondiente. La debilidad es que algunas veces existe una tendencia por
parte de los diseñadores a adentrarse mucho en el detalle y generar una implementación del
código completo del módulo en lugar de un diseño detallado en PDL. Después de haberlo
documentado por completo y probado exitosamente, el diseño detallado se pasa al equipo de
implementación para codificarlo. Después el producto procede con el resto de las fases del
ciclo de vida del software clásico.


Extensiones del análisis del flujo de datos

El lector pudiera sentir que este ejemplo es algo artificial, debido a que el diagrama de
flujo 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 de
entrada 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 encontrar
el punto de mayor abstracción de entrada para cada flujo de entrada y el punto de mayor
abstracción de salida para cada flujo de salida. Utilice estos puntos para dividir el diagrama
del flujo de datos proporcionado en módulos con menos flujos de entrada-salida que el
original. 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. El
aná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, tal
como “procesar una solicitud” o “imprimir una lista de las órdenes del día”. El análisis del flujo
de datos es inapropiado para el procesamiento de transacciones de un producto, en el cual un
sinnú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. El
cliente inserta una tarjeta magnética dentro de una ranura, teclea una contraseña, después
realiza 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 ilustra
en la figura 13.9. Una buena forma de diseñar dicho producto es dividirlo en dos partes, el
analizador y el despachador. El analizador determina el tipo de transacción y pasa esta
informació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 muy
similares y cinco módulos de actualización muy similares. La solución es reutilizar el
software: un módulo de edición básico deberá diseñarse, codificarse, documentarse y
probarse, luego instanciarse cinco veces. Cada versión es ligeramente diferente, pero las
diferencias son tan pequeñas que hacen que este enfoque valga la pena. Asimismo, un módulo
de actualización básico puede instanciarse cinco veces y modificarse ligeramente para
complacer a cinco tipos de actualización diferentes. El diseño resultante tiene alta cohesión y
bajo acoplamiento.

El análisis de transacciones se resume en Cómo realizar, cuadro 13.2.


Elementos del Diseño de Datos

Al igual que otras actividades de la ingeniería del software, el diseño de datos (algunas
veces llamado arquitectura de datos) crea un modelo de datos o información que se
representa 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 manera
progresiva tienen una implementación específica y que pueden procesarse mediante el
sistema basado en computadora. En muchas aplicaciones de software la arquitectura de los
datos tendrá una profunda influencia sobre la arquitectura del software que los debe
procesar.

La estructura de los datos siempre ha sido una parte importante del diseño del
software. Al nivel de los componentes del sistema, las estructuras del diseño de datos y los
algoritmos con que se manipulan son esenciales para la creación de aplicaciones de alta
calidad. Al nivel de aplicación, la traducción de un modelo de datos (obtenido como una base
de la ingeniería de requisitos) a una base de datos es esencial para alcanzar los objetivos de
negocio de un sistema. Al nivel de negados, la colección de información almacenada en bases
de datos dispersas y reorganizadas en una "conjunción de datos" permite la explotación de
datos o el descubrimiento de un conocimiento que puede tener un impacto sobre el éxito del
mismo 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 una
casa. Este plano muestra la configuración general de las habitaciones, su tamaño, forma y las
relaciones entre ellas, y las puertas y ventanas que permiten el movimiento hacia y desde los
cuartos. El plano de planta proporciona una visión global de la casa. Los elementos del diseño
arquitectónico dan una visión general del software.

El modelo arquitectónico [SHA96] se obtiene a partir de tres fuentes: 1) la información
acerca del dominio de aplicación para el software que se va a construir; 2) los elementos del


modelo de análisis específico, tales como diagramas de flujo de datos o clases de análisis, sus
relaciones y colaboraciones para el problema que se tiene a la mano, y 3) la disponibilidad de
patrones y estilos arquitectónicos.

Elementos de diseño de interfaz

El diseño de interfaz para software es el equivalente a un conjunto de dibujos
detallados (y especificaciones) para puertas, ventanas y utilidades externas de una casa. Estos
dibujos representan el tamaño y forma de las puertas y ventanas, la manera en que operan, la
manera 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 intercomunicador
que anuncie la presencia de un visitante y cómo está instalado el sistema de seguridad. En
esencia, los dibujos (y especificaciones) detallados para las puertas, ventanas y utilidades
externas indican cómo fluyen las cosas y la información desde y hacia la casa y dentro de las
habitaciones que son parte del plano de planta. Los elementos del diseño de interfaz para
software 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 o
consumidores 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 y
permiten la comunicación y colaboración interna entre los componentes que pueblan la
arquitectura del software.

El diseño de la IU es una acción primordial de la ingeniería de software. El diseño de
una IU incorpora elementos estéticos (por ejemplo, distribución, color, gráficas, mecanismos
de interacción), elementos ergonómicos (por ejemplo, información y ubicación de la
distribució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 arquitectura
de aplicación general.

El diseño de las interfaces externas requiere información definitiva acerca de la
entidad hacia donde se manda o recibe la información. En todos los casos, esta información
debe recopilarse durante la ingeniería de requisitos y verificarse una vez que comience el
diseñ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 nivel
de los componentes. Las realizaciones del diseño de clases de análisis representan todas las
operaciones y esquemas de mensajes requeridos para permitir la comunicación y
colaboración entre las operaciones de varias clases.


Cada mensaje debe ser diseñado para ajustarse a la transferencia de información de
requisitos 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. El
UML define una interfaz de la siguiente manera [OMGOI] "Una interfaz es un determinante de
las operaciones [públicas] visibles de manera externa de una clase, componente u otro
clasificador (incluidos los subsistemas) sin especificación de estructura interna". Dicho de un
modo más simple, una interfaz es un conjunto de operaciones que describe parte del
comportamiento de una clase y proporciona acceso a esas operaciones.

Por ejemplo, la función de seguridad de HogarSeguro emplea un panel de control que
permite al propietario de la casa controlar ciertos aspectos de la función de seguridad. En una
versión avanzada del sistema, las funciones del panel de control pueden implementarse vía
PDA inalámbrico o teléfono móvil.

La clase Panel de control (figura 9.5) proporciona el comportamiento asociado con un
teclado y, por lo tanto, debe implementar operaciones de leerTeclaPresionada y
decodificarTecla ( ). Si estas operaciones se suministrarán a otra clase (en este caso, a
PDAInaIámbrico y Teléfono Móvil), resulta inútil definir una interfaz como la que se muestra
en la figura. La interfaz llamadaTeclado se muestra como un estereotipo de <<interfaz>> o
como un círculo pequeño y etiquetado que se conecta a la clase con una línea. La interfaz se
define sin atributos y con el conjunto de operaciones necesarias para lograr el
comportamiento 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


parte de su comportamiento. En UML esto se caracteriza como una realización. Esto es, parte
del comportamiento de PaneldeControl se implementará al realizar las operaciones de
Teclado. 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 dibujos
detallados (y especificaciones) para cada cuarto en una casa. Estos dibujos muestran el
alambrado y la instalación sanitaria dentro de cada cuarto, la ubicación de los receptáculos
eléctricos e interruptores, llaves, lavabos, tinas, desagües y armarios. También describen los
pisos que se usarán, los moldes que se aplicarán, y cualquier otro detalle asociado con el
cuarto. El diseño al nivel de componentes para software describe por completo el detalle
interno de cada componente del software.

Para lograrlo el diseño al nivel de componentes define estructuras de datos para todo
los objetos de datos locales, así como detalle algorítmico para todo el procesamiento que
ocurre dentro de un componente y una interfaz que permite el acceso a todas las operaciones
de los componentes (comportamientos).

Dentro del contexto de la ingeniería del software orientada a objetos, un componente
se representa a manera de diagrama en UML como se muestra en la figura 9.6. En esta figura
se representa un componente llamado ManejoSensor (parte de la función de seguridad de
HogarSeguro). El componente está conectado a una clase llamada Sensor, la cual está asignada
a éste mediante una flecha punteada. El componente Manejosensor realiza todas las funciones
asociadas con los sensores de HogarSeguro, entre las que se encuentran su monitoreo y
configuración.

Los detalles de diseño de un componente se pueden modelar a muchos grados
distintos de abstracción. En la representación del procesamiento lógico se puede utilizar un
diagrama de actividad. El flujo detallado de procedimiento para un componente puede
representarse, ya sea mediante un pseudocódigo, o de algún formato diagramático (por
ejemplo, 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 la
funcionalidad y los subsistemas dentro del entorno computacional físico que soportará al
software. Por ejemplo, los elementos del producto HogarSeguro están configurados para
operar dentro de tres entornos de computación primarios: una PC doméstica, el panel de


control de HogarSeguro y un servidor ubicado en CPI Corp. (lo que proporciona acceso al
sistema 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 (en
realidad, debería haber más, si se incluyen sensores, cámaras y otros). Se indican los
subsistemas (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 ha
diseñado un subsistema de acceso externo para controlar todos los intentos de acceso al
sistema HogarSeguro desde una fuente externa. Cada subsistema seria elaborado para indicar
los componentes que implementa.

El diagrama mostrado en la figura 9.7 está en forma de descriptor. Esto significa que el
diagrama de despliegue muestra el entorno computacional, pero no indica de manera explícita
detalles de configuración. Por ejemplo, no se identifica la "computadora personal". Podría ser
una "Wintel" PC o una Macintosh, una estación de trabajo Sun o una Linux-box. Estos detalles
se proporcionan cuando el diagrama de' despliegue se revisa en forma de instancia durante
etapas posteriores del diseño o cuando comienza la construcción. Se identifica cada instancia
del 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 del
diseño orientado a objetos (OOD, por sus siglas en inglés). De acuerdo con esto. Ahora
describimos 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. Los
lenguajes clásicos tales como C, COBOL y el FORTLAN no soportan objetos. Esto parecería
implicar que el OOD está disponible sólo para usuario de lenguaje orientado a objetos como
Smalltalk [Goldberg y Robson, 1989], C++ [Stroustrup, 2000], Ada 95 [ISO/IEC 8652, 1995] y
Java [Flanagan, 2002].


Este no es el caso. Aunque el OOD como tas es soportado por los lenguajes clásicos, se
puede usar un gran subconjunto del OOD. Una clase es un tipo de dato abstracto con herencia
y un objeto es una instancia de clase. Cuando se unas un lenguaje de implementación que no
soporte la herencia, la solución es usar aquellos aspectos del OOD que puedan funcionar
dentro 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 que
soporte sentencias type. Incluso en el lenguaje clásico que no soporte sentencias type como
tal, y por ende no soporte datos de tipo abstracto, aun así todavía pudiera implementar la
encapsulación de datos.

Los dos aspectos claves del OOD son completar el diagrama de clases y realizar el
diseño detallado. Respecto al primer paso, completar el diagrama de clases, se necesitan
determinar los formatos de los atributos y asignarlos métodos a las clases correspondientes.

Por lo general los formatos de los atributos pueden deducirse directamente del
análisis de artefactos. Por ejemplo, es Estados Unidos las especificaciones pudieran establecer
que una fecha como la de diciembre 3, 1947, se representa como 12/03/1947 (formato
mm/dd/yyyy) o en Europa como 03/12/1947 (formato dd/mm/yyyy). Pero sin importar cuál
sea 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 del
análisis, así que seguramente se podrán agregar los diagramas de clases en ese momento. Sin
embargo, el paradigma orientado a objetos es iterativo. Cada iteración genera una
modificación a lo que ya se había terminado. Por razones prácticas, entonces la información
debe 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 del
producto se realiza examinando los diagramas de interacción de cada escenario. Esto es
sencillo, 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 al
objeto de dicha clase. (Un cliente de un objeto es una unidad de programas que envía
mensajes al objeto). Un principio que puede emplearse para ayudar al decidir cómo asignar
una operación es esconder la información. Esto es, las variables de estado de una clase deben
declarase 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 acuerdo
con esto, las operaciones desarrolladas sobre las variables de estado deben ser locales para la
clase.

Un segundo principio, es que sus varios clientes de un objeto invocan una operación es
particular, tiene sentido tener una copia única de la operación implementada como un método
del 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 un
método es utilizar el diseño controlado por responsabilidades. Si un cliente envía un mensaje


a un objeto, entonces el objeto es responsable en cada aspecto de llevar a cabo la solicitud del
cliente. 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 se
hizo.

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 obtiene
agregando las operaciones (métodos) al diagrama de clases de la figura 12.9 (en el caso de
una implementación Java, se necesitan dos clases adicionales. Aplicación Elevador
corresponde a la función main de C++ y Utilidades Elevador contiene las rutinas de Java que
corresponden 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 iniciar
cronómetro, 10 revisar solicitudes y 11 actualizar solicitudes, se asignan al controlador del
elevador con base en el diseño guiado por responsabilidades; dichas tareas se llevan a cabo
por el controlador del elevador.

Por otro lado, las ocho responsabilidades restantes (eventos 1 al 7 y evento 9) tienen
la forma “evitar un mensaje a otra clase para decirle que haga algo”. Esto implica que el
principio que debe usarse para asignar el método correspondiente a las clases otra vez debe


controlarse por el diseño correspondiente a las clases otra vez debe controlarse por el diseño
de responsabilidades. Además, debido a preocupaciones de seguridad, el principio de
esconder 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 clase
Puertas Elevador. Esto es cliente de Puertas Elevador (en este caso una instancia de la clase
Controlador Elevado) envía un mensaje a un objeto de la clase Puertas Elevador para cerrar o
abrir 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, el
esconder información genera una independencia verdadera de la clase Puertas Elevador, de la
cual sus instancias pueden dirigirse en el diseño detallado e implementarse
independientemente 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 un
piso, y se asignan a la clase Elevador. No hay necesidad de que una instrucción explicita
ocasione que le elevador se detenga. Si no se invoca ninguno de estos dos métodos, el
elevador no puede moverse; no existe otra forma de modificarse, el estado de un elevador
distando a invocar alguno de estos dos métodos.

Finalmente, los métodos apagar botón y encender botón se asignan tanto a Botón
Elevador como a Botón Piso. La razón aquí es la misma que la de los métodos asignados a la
clase 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.


por responsabilidades se requieren que los botones tengan control total sobre si están
encendidos o apagados. Segundo, el principio de esconder información requiere que el estado
interno de un botón permanezca escondido. Los métodos que encienden o apagan un botón
del elevador deben ser locales a la clase Botón Elevador y de manera similar para la clase
Botón Piso. Para hacer uso del polimorfismo y del ligamiento dinámico, los métodos encender
botó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 cualquier
técnica que se ajuste. El diseño detallado del método ciclo de eventos del elevador se muestra
en la figura 13.12. Aquí se usó PDL (pseudocódigo), pero una representación tabular de igual
forma puede ser efectiva.

Ahora consideramos el diseño orientado a objetos del caso de estudio de Osbert
Oglesby.

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 la
figura 13.13. La Clase Fecha definida por el usuario se traza punteada para representar que se
necesita Únicamente para la Implementación en C++; Java tiene clases ínterconstruidas para
manejar fechas, incluyendo java,tcxt.Dateformat y Java.util.Calendar. Enseguida, se deducen
los formatos de los atributos de las clases a partir de los requerimientos. El resultado se
muestra en la figura 13.14.

Los métodos del producto aparecen en los distintos diagramas de interacción. La tarea
del diseñador es decidir a qué clase se debe asignar cada método. Por ejemplo, la conversión
en un producto de software orientado a objetos es que cada atributo asociado a una clase
incluye un método setAtributo, utilizado para asignar un valor específico, a dicho atributo, y
un método getAtributo, el cual devuelve el valor actual del atributo.


Por ejemplo, considere el método setTítulo, utilizado para asignar el nombre de una
pintura él un objeto pintura. En el paradigma clásico, necesitaríamos las funciones
poner_título_obra_maestra, poner_título_trabajo_maestro y poner_título_otra_pintura. Sin
embargo. El paradigma orientado a objetos soporta la herencia. Por lo mismo el método
setTitulo deberá asignarse a la Clase Pintura.


Paso 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 dos
métodos del caso de estudio Osbert Oglesby. La figura 13.05 muestra el diseño detallado del
método getAlgoritmoPrecio de la clase CalcularPrecioObraMaestra, y la figura 13.16 muestra
el diseño detallado del método getAlgoritmoPrecio de la clase CalcularPrecioTrabajoMaestro.


El flujo de trabajo del diseño

La entrada del flujo de trabajo del diseño son los artefactos del flujo de trabajo del
análisis. Durante el flujo de trabajo del diseño, estos artefactos se repiten e incrementan hasta
que están en un formato en el que los programadores pueden utilizarlos. Un aspecto de
iteración y de los incrementos es la identificación de método y su ubicación en las clases
apropiadas. Otro aspecto es realizar el diseño detallado. Estos dos pasos constituyen el
componente 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 muchas
decisiones como parte del flujo de trabajo del diseño. Una de estas decisiones es la selección
del lenguaje de programación en el cual se implementará el producto de software. Otra
decisión es que tanto se pueden reutilizar los productos de software existentes en el producto
de software nuevo que se desarrollará. Además, los productos de software grandes por lo
general se implementan en una red de computadoras; por esto es que otra decisión del diseño
es la ubicación de cada componente de software en el en el componente de hardware en el
cual se ejecutará.

La mayor motivación detrás del desarrollo del Proceso Unificado fue presentar una
metodologí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 de
estudio 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 Osbert
Oglesby. De acuerdo con esto. Muchos aspectos del Proceso Unificado no aplican para este
caso de estudio. Por ejemplo, una parte importante del flujo de trabajo del análisis es dividir el
producto de software en paquetes de análisis. Cada paquete se forma de un conjunto de clases
relacionadas, generalmente relevantes a un pequeño subconjunto de actores, que puede


implementarse como una sola unidad. Por ejemplo, cuentas por pagar, cuentas por cobrar y el
libro mayor son típicamente paquetes de análisis. El concepto que sustenta el análisis de los
paquetes es que es más fácil desarrollar productos de software pequeños que productos de
software grandes. De acuerdo con esto, un producto de software grande es más fácil de
desarrollar si es posible dividirlo en paquetes relativamente independientes.

La idea de dividir un flujo de trabajo grande en flujos de trabajo pequeños
relativamente 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, el
caso 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 en
paralelo. Esto genera que el producto de software como un todo se entregue antes. Se debe
recordar que la arquitectura de un producto de software incluye varios componentes y cómo
encajan en conjunto. La ubicación de los componentes en los subsistemas es una parte
importante de las tareas de arquitectura. Decidir la arquitectura de un producto de software
de ningún modo es fácil y, en todos los productos de software excepto los pequeños, un
especialista los desarrolla. El arquitecto de software.

Además de ser un experto técnico, un arquitecto necesita saber cómo negociar. Un
producto de software tiene que satisfacer los requerimientos funcionales, esto es, los casos de
uso. También necesitan satisfacer los requerimientos funcionales, incluyendo portabilidad,
confiabilidad, fortaleza, capacidad de mantenimiento, seguridad, confiabilidad, etc. Pero
necesita hacer todas estas cosas dentro del presupuesto y tiempo. Casi nunca es posible
desarrollar un producto de software que satisfaga todos requerimientos, tanto funcionales
como no funcionales, y que termine dentro del costo y tiempo estimado: casi siempre tienen
que 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 de
algunas de estas cosas. El arquitecto debe ayudar al cliente en su decisión comentando
claramente las fortalezas y debilidades.

En algunos casos las fortalezas y debilidades son obvias. Por ejemplo, el arquitecto
pudiera señalar que un conjunto de requerimientos de seguridad que se acopien al nuevo
estándar de alta seguridad necesitarán tres meses más y 350 000 dólares más para
incorporarlos 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 en
comprometer la seguridad. Sin embargo, en algunos otros casos, el cliente necesita tomar


decisiones críticas respecto a las fortalezas y debilidades y tiene que apoyarse en la
experiencia 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 particular
hasta que el producto de software se haya entregado y se encuentre en mantenimiento
pudiese ahorrar 150 000 dólares por el momento, pero costaría 300 000 dólares incorporarlo
má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 la
decisión correcta.

La arquitectura de un producto de software es un factor vital que determinaría si el
producto entregado es un éxito o un fracaso. Y las decisiones críticas referentes a la
arquitectura tienen que tomarse mientras se realiza el flujo de trabajo del diseño. Si el flujo de
trabajo 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 recuperarse
haciendo un esfuerzo extra como parte del flujo de trabajo del diseño. Pero, si la arquitectura
no 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 experiencia
té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 por
completo las especificaciones dentro del diseño así como asegurar la rectitud del mismo. Por
ejemplo, el diseño no debe tener fallas lógicas y todas las interfaces deben estar definidas de
manera correcta Es importante que se detecte cualquier falla en el diseño antes de comenzar a
codificar; de lo contrario, el costo de reparar tales fallas será considerablemente alto. Las
fallas del diseño pueden detectarse por medio de inspecciones al diseño así como de
revisiones del diseño.

Cuando el producto es orientado a transacciones, la inspección del diseño debe
reflejarlas [Beizer 1990]. Deben calendarizarse inspecciones que incluyan todos los tipos
posibles de transacciones. El revisor debe relacionar cada transacción en el diseño con las
especificaciones, mostrando cómo es que la transacción surge del documento de
especificaciones. Por ejemplo, si la aplicación es un cajero automático, una transacción
corresponde a cada operación que puede realizar el cliente, como depositar o retirar de una
cuenta de tarjeta de crédito. En otros casos, la correspondencia entre especificaciones y
transacciones no es necesariamente una a una.

En un sistema de control de tráfico, por ejemplo, si un automóvil que se encuentra
sobre un sensor genera que el sistema decida cambiar una luz en particular, de rojo a vade en
15 segundos, entonces los siguientes impulsos de dicho sensor pudieran ignorarse. De manera
inversa, para aumentar el flujo del tráfico, un simple impulso pudiera ocasionar que toda una
serie de luces cambiara de rojo a verde.


El restringir a los revisores a inspecciones guiadas por transacciones no detecta los
casos en los cuales los diseñadores pasaron por alto algunas instancias de las transacciones
requeridas por las especificaciones. Para poner un ejemplo extremo, las especificaciones para
el controlador dé trafico pudieran estipular que, entre las 11:00 p.m. y las 6:00 a.m. todas las
luces 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 transacciones
generadas entre las 11:00 p m. y 6:00 a.m. no serán incluidas en diseño; y, no podrán probarse
en una inspección al diseño basado en transacciones. Por esto, no es adecuado calendarizar
inspecciones al diseño que sólo se: controlen por transacciones; las inspecciones controladas
por especificaciones, también son esenciales para asegurar que no se ha pasado por alto o mal
interpretado 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 aspectos
del diseño del caso de estudio de Osbert Oglesby por medio de una inspeccione del diseño. En
particular, se examinar cada artefacto del diseño incluso si no se encontraron falla, es posible
que el diseño cambie otra vez, radicalmente, cuando el caso de estudio Osbert Oglesby sea
implementado.

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ño
detallado utilizando cuadros de flujo. Además del refinamiento escalonado, se pueden usar
técnicas formales para mejorar el diseño detallado. Desarrollar en paralelo las pruebas y el
diseñ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 pierde
información. En lo particular, cada entrada debe procesarse antes de que llegue la siguiente
entrada. Un ejemplo de estos sistemas es un reactor nuclear controlado por computadora. Las
entradas como la temperatura del núcleo y el nivel de agua en la cámara del reactor


continuamente se envían a la computadora la cual lee el valor de cada entrada y analiza el
procesamiento necesario antes de que llegue la siguiente entrada. Otro ejemplo es una unidad
de 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 cada
paciente, e información de emergencia, cuando el sistema deduce que la condición de un
paciente es grave. Cuando ocurren tales emergencias, el software; debe procesar tanto las
entradas 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 Hardware
distribuido. Por ejemplo, el software que controla un aeronave de guerra pudiera tener que
implementarse en cinco computadoras para controlar la navegación, otra el sistema de
alarmas, una tercera para contramedidas electrónicas, una cuarta para controlar el hardware
de 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 de
respaldo adicionalmente que automáticamente reemplazarían una unidad que funciones de
manera 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 como
consecuencias de la naturaleza distribuida del sistema. Por ejemplo, bajo condiciones de
combate, la computadora táctica pudiera sugerir que el piloto se eleve, mientras que la
computadora de armas recomiende que el piloto vaya en picada para poder lanzar
determinada arma en condiciones óptimas. Sin embargo, el piloto humano decide mover la
palanca hacia la derecha, enviando una señal a la computadora de vuelo para que haga los
ajustes necesarios para que el avión se deslice en la dirección indicada. Toda esta información
debe manejarse con cuidado de tal forma que el movimiento real debe pasarse a las
computadoras tácticas y de armas para que puedan formular sugerencias nuevas a la luz de
condiciones 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 dos
operaciones que tienen uso exclusivo de cierta información solicitan uso exclusivo de la
informació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 sistemas
de tiempo-real en los cuales no hay control sobre el orden en que llegan las entradas. Y la
situación puede complicarse por la naturaleza distribuida del hardware. Además del
estancamiento, son posibles otros problemas de sincronización incluyendo condiciones de
competencia.

Es claro que a partir de estos ejemplos la principal dificultad del diseño de sistemas de
tiempo-real es asegurar que las restricciones de tiempo se cumplan en el diseño. Esto es la
técnica de diseño debe proporcionar un mecanismo para revisar que cuando se implemente el
diseño sea capaz de leer y procesar la información que llegue en la tasa requerida. Por lo


mismo, debe ser posible mostrar que los elementos de sincronización también se han
manejado correctamente en el diseño.

Desde el principio de la era de las computadoras, muchos de los avances de la
tecnología de hardware han sobrepasado, casi en todos los aspectos, los avances en la
tecnología de software. Por lo mismo aunque exista el hardware para manejar cualquier
aspecto de los sistemas de tiempo-real antes descritos. La tecnología de diseño de software se
ha 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 ha
alcanzado el mismo nivel de sofisticación. En verdad se han dado grandes progresos, pero la
realidad es que aún no es comparable a lo que se ha alcanzado con las técnicas de análisis. Ya
que casi cualquier técnica de diseño para sistemas de tiempo-real es preferible a no unas
ninguna 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 como
los antes descritos y que estemos seguros que, antes de que el sistema sea implementado, se
cumplirá 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 no
trabajan 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 sistema
estructurado, del análisis de flujo de datos y del análisis de transacciones llevadas hacia
software de tiempo-real. Esta técnica de desarrollo incluye un componente para el diseño de
tiempo-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 en
tiempo-real no esté tan avanzado como uno quisiera. Sin embargo, se están haciendo
esfuerzos para mejorar la información.

Modelo de diseño_iv

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a Modelo de diseño_iv

Similar a Modelo de diseño_iv (20)

Modelo de diseño_iv