Unidad
4
4.1 Estrategia de
Diseño
El modelo de diseño es un refinamiento y formalizaciónadicional del modelo del análisis, donde se toman en cuenta las consecuencias del ambiente de implementación. El resultado del modelo de diseño son especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. El modelo de diseño se basa en el diseño por responsabilidades.
* Se requiere un modelo de diseño ya que el modelo de análisis no es lo suficiente formal para alcanzar el código fuente. Por tal motivo se refinan los objetos, incluyendo las operaciones y atributos. Además se debe considerar aspectos como, los requisitos del rendimiento, tiempo real, concurrencia, lenguaje de programación, manejo de base de datos, etc.
* Otro objetivo del diseño es validar los resultados de los modelos de requisitos y análisis. Durante el diseño, se ve si los resultados anteriores son apropiados para la implementación. Si se descubren aspectos que no están claros en algunos de los modelos anteriores, estos se aclaran, posiblemente regresando a etapas anteriores.
* El modelo del diseño se considera como una formalización del espacio del análisis extendiéndolo para incluir una dimensión adicional que corresponde al ambiente del implementación, como se ve en el diagrama de la figura.
Esta nueva dimensión, corresponde al ambiente de implementación, se considera al mismo tiempo que se refina el modelo. La meta es refinarlo hasta que sea fácil escribir el código fuente. Como el modelo del análisis define la arquitectura general del sistema, se busca obtener una arquitectura detallada como resultado del modelo de diseño, de manera que haya una continuidad de refinamiento entre los dos modelos, como se ve en el diagrama de la figura.
La transición de análisis a diseño debe decidirse por separado por cada aplicación en particular . Aunque es posible continuar trabajando sobre el modelo de análisis. Incluso durante la incorporación del ambiente de implementacion, no es recomendable, ya que aumenta su complejidad. Por tanto es conveniente tener un modelo de análisis ideal del sistema durante el ciclo de vida del sistema dado que mucho de los cambios del sistemas provienen de cambios en el ambiente de implementacion. Tales cambios se incorporan fácilmente ya que el mismo modelo del análisis sirve de base para el modelo del diseño. De esta manera, el modelo de diseño se ve como una especialización del modelo de análisis según el ambiente especifico.
Si los cambios en el modelo del diseño provienen de un cambio en la lógica del sistema, entonces deben hacerse cambios en el modelo de análisis. Sin embargo, si el cambio es una consecuencia de la implementación, entonces los cambios no deben incorporarse en el modelo de análisis.
Las estructuras con las cuales se trabajan en el modelo del diseño son básicamente las mismas que en el modelo del análisis. Sin embargo, el punto de vista cambia,ya que se toma un paso hacia la implementación. El modelo del análisis debe verse como un modelo conceptual y lógico del sistema, en tanto que el modelo del diseño debe acercarse al código fuente. Esto significa que se cambia el punto de vista del modelo del diseño a una abstracción del código fuente señal. Por lo tanto, el modelo de diseño debe ser una descripción de cómo debe estructurarse
En general, los cambio en la arquitectura del sistema para mejorar su rendimiento deben proponerse hasta que el sistema este (parcialmente). Construido.
Se considera dos aspectos principales del modelo de diseño.
* Diseño del objeto. Se refina y formaliza el modelo para generar especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. Se describe cómo interactúan los objetos en cada caso de uso específico, especificando que debe hacer cada operación en cada objeto. Este paso genera las interfaces de los objetos, las cuales después deben implementarse mediante métodos.
DISEÑO DE SISTEMA
El modelo se adapta al ambiente de implementación. Este paso incluye identificar e investigar las consecuencias del ambiente de implementación sobre el diseño. Aquí deben tomarse las decisiones de implementación estratégicas: como se incorporara una BD en el sistema: que y como se usaran las bibliotecas de componentes: que lenguajes de programación se utilizaran: como se manejaran los procesos incluyendo comunicación y requisitos de rendimiento: como se diseñaran el manejo de excepciones y recolección de basura,etc.
De manera homogénea entre los objetos permite que cada objeto sepa menos cosas. Esto produce objetos más pequeños y más fáciles de comprender. La desventaja es que la inteligencia del sistema va de la mano con la especialización de las clases. Si todas las clases son inteligentes, esto significara que estas serán muy especializadas dificultando la extensibilidad del sistema que requiere generalizar más las clases.
El tercer enfoque es encontrar un balance entre los dos primeros. La idea es homogeneizar la inteligencia del sistema solo entre ciertas clases, como las de control. El resto de las clases, entidad y borde, serán tontas, generalmente sobreviviendo a modificaciones en el sistema y manteniendo la lógica introducida durante el modelo de requisitos y el modelo de análisis posterior para lograr una mayor robustez del sistema.
La robustez de un sistema debe ser uno de los objetivos principales del diseño. El sistema debe estar protegido contra errores y ofrecer diagnósticos que permitan identificar fallas, en particular aquellas que son fatales. Durante el desarrollo, a veces es bueno insertar instrucciones internas en el código para descubrir fallas, aunque luego se eliminen durante la producción. En general, se debe escoger lenguajes de programación que apoyen estos aspectos, como son el manejo de excepciones. Las principales consideraciones relacionadas con la robustez de un sistema son las siguientes:
El sistema debe estar protegido contra parámetros incorrectos proporcionados por el usuario. Cualquier método que acepte parámetros del usuario debe validar la entrada para evitar problemas. El diseñador de métodos debe considerar dos tipos de condiciones de error: i) errores lógicos que se identifican durante el análisis y ii) errores de implementación, incluyendo errores del sistema operativo, como los errores de asignación de memoria, o errores de archivos de entrada y salida.
El sistema no debe optimizarse hasta que este funcione de manera correcta. se debe estudiar las alternativas, como aspectos de memoria, velocidad y simplicidad de implementación. No se debe optimizar más de lo necesario, ya que la optimización compromete la extensibilidad, reusó y comprensión del sistema.
* El sistema debe incluir estructuras de datos de tamaño variable, sin límites predefinidos. Durante el diseño es difícil predecir la capacidad máxima esperada para la estructura de datos en la aplicación. Por tanto, se deben escoger estructuras de datos como las listas, a diferencia de los arreglos.
* El sistema debe instrumentar un monitoreo de rendimiento y búsqueda de errores. El esfuerzo para llevarlo a cabo depende del ambiente de programación. Si el lenguaje de implementación no proporciona ningún apoyo, se añaden métodos de impresión para cada clase. También se añaden mensajes de entrada y salida a los métodos imprimiendo selectivamente estos valores.
El encapsulamiento es fundamental para la robustez del sistema. Ocultar la información interna, atributos e implementación de métodos de una clase, permite cambiarla sin afectar el resto del sistema. Únicamente la interface de los métodos afecta a las demás clases.
*REUSO
* El reusó es en aspecto fundamental del diseño. Cuanto más se pueda reutilizar el código será mejor la robustez del sistema las siguientes son algunas estrategias para mejorar las posibilidades del reusó de los diseño.
* A través de la herencia se incrementa el reuso del código. Se toman las aspectos comunes a clases similares utilizando superficies comunes. Este en enfoque es efectivo cuando las diferencias entre las clases son pequeñas y las similitudes son grandes. Es importante considerar la naturaleza de cada herencia para asegurar que no se llegue a extremos donde la aplicación de la herencia sea inadecuada.
* El uso impropio de la herencia hace que los programas sean difíciles de mantener y extender. Como alternativa, la delegación provee un mecanismo para el reusó de código, pero sin utilizar la herencia. Esto se basa en el uso de agregación a través de clases intermediarias que ocultan la funcionalidad de las clases a las cuales se delega.
Extensibilidad
* Se debe encapsular otra vez la clases, ocultando su estructura internas a las otras clases. Sólo los métodos de la clase deben accesar a sus atributos.
* No se deben exportar estructuras de datos desde un método. Las estructuras de datos internas son específicas para el algoritmo del método. Si se exportan las estructuras se limita la flexibilidad para cambiar el algoritmo más adelante.
* Una clase particular debe tener un conocimiento limitado de la arquitectura de clases del sistema. Este conocimiento abarcará únicamente las asociaciones entre ésta y sus clases vecinas directas. Cualquier interacción con un vecino indirecto, se deberá hacer mediante llamadas a los vecinos directos
* Se debe evitar expresiones que requieran un conocimiento explícito de los tipos de objetos. En su lugar, se debe de aprovechar el polimorfismo a fin de seleccionar el comportamiento a ejecutarse, basado en el tipo implícito del objeto.
* Se debe distinguir entre operaciones privadas y públicas. Se vuelve costoso cambiar operaciones públicas, debiendo ser definidas con cuidado. Las operaciones privadas son internas en la clase y sirven únicamente de ayuda para implementar operaciones públicas. Las operaciones privadas pueden modificarse sin afectar otras clases.
El modelo de diseño es un refinamiento y formalizaciónadicional del modelo del análisis, donde se toman en cuenta las consecuencias del ambiente de implementación. El resultado del modelo de diseño son especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. El modelo de diseño se basa en el diseño por responsabilidades.
* Se requiere un modelo de diseño ya que el modelo de análisis no es lo suficiente formal para alcanzar el código fuente. Por tal motivo se refinan los objetos, incluyendo las operaciones y atributos. Además se debe considerar aspectos como, los requisitos del rendimiento, tiempo real, concurrencia, lenguaje de programación, manejo de base de datos, etc.
* Otro objetivo del diseño es validar los resultados de los modelos de requisitos y análisis. Durante el diseño, se ve si los resultados anteriores son apropiados para la implementación. Si se descubren aspectos que no están claros en algunos de los modelos anteriores, estos se aclaran, posiblemente regresando a etapas anteriores.
* El modelo del diseño se considera como una formalización del espacio del análisis extendiéndolo para incluir una dimensión adicional que corresponde al ambiente del implementación, como se ve en el diagrama de la figura.
Esta nueva dimensión, corresponde al ambiente de implementación, se considera al mismo tiempo que se refina el modelo. La meta es refinarlo hasta que sea fácil escribir el código fuente. Como el modelo del análisis define la arquitectura general del sistema, se busca obtener una arquitectura detallada como resultado del modelo de diseño, de manera que haya una continuidad de refinamiento entre los dos modelos, como se ve en el diagrama de la figura.
La transición de análisis a diseño debe decidirse por separado por cada aplicación en particular . Aunque es posible continuar trabajando sobre el modelo de análisis. Incluso durante la incorporación del ambiente de implementacion, no es recomendable, ya que aumenta su complejidad. Por tanto es conveniente tener un modelo de análisis ideal del sistema durante el ciclo de vida del sistema dado que mucho de los cambios del sistemas provienen de cambios en el ambiente de implementacion. Tales cambios se incorporan fácilmente ya que el mismo modelo del análisis sirve de base para el modelo del diseño. De esta manera, el modelo de diseño se ve como una especialización del modelo de análisis según el ambiente especifico.
Si los cambios en el modelo del diseño provienen de un cambio en la lógica del sistema, entonces deben hacerse cambios en el modelo de análisis. Sin embargo, si el cambio es una consecuencia de la implementación, entonces los cambios no deben incorporarse en el modelo de análisis.
Las estructuras con las cuales se trabajan en el modelo del diseño son básicamente las mismas que en el modelo del análisis. Sin embargo, el punto de vista cambia,ya que se toma un paso hacia la implementación. El modelo del análisis debe verse como un modelo conceptual y lógico del sistema, en tanto que el modelo del diseño debe acercarse al código fuente. Esto significa que se cambia el punto de vista del modelo del diseño a una abstracción del código fuente señal. Por lo tanto, el modelo de diseño debe ser una descripción de cómo debe estructurarse
En general, los cambio en la arquitectura del sistema para mejorar su rendimiento deben proponerse hasta que el sistema este (parcialmente). Construido.
Se considera dos aspectos principales del modelo de diseño.
* Diseño del objeto. Se refina y formaliza el modelo para generar especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. Se describe cómo interactúan los objetos en cada caso de uso específico, especificando que debe hacer cada operación en cada objeto. Este paso genera las interfaces de los objetos, las cuales después deben implementarse mediante métodos.
DISEÑO DE SISTEMA
El modelo se adapta al ambiente de implementación. Este paso incluye identificar e investigar las consecuencias del ambiente de implementación sobre el diseño. Aquí deben tomarse las decisiones de implementación estratégicas: como se incorporara una BD en el sistema: que y como se usaran las bibliotecas de componentes: que lenguajes de programación se utilizaran: como se manejaran los procesos incluyendo comunicación y requisitos de rendimiento: como se diseñaran el manejo de excepciones y recolección de basura,etc.
De manera homogénea entre los objetos permite que cada objeto sepa menos cosas. Esto produce objetos más pequeños y más fáciles de comprender. La desventaja es que la inteligencia del sistema va de la mano con la especialización de las clases. Si todas las clases son inteligentes, esto significara que estas serán muy especializadas dificultando la extensibilidad del sistema que requiere generalizar más las clases.
El tercer enfoque es encontrar un balance entre los dos primeros. La idea es homogeneizar la inteligencia del sistema solo entre ciertas clases, como las de control. El resto de las clases, entidad y borde, serán tontas, generalmente sobreviviendo a modificaciones en el sistema y manteniendo la lógica introducida durante el modelo de requisitos y el modelo de análisis posterior para lograr una mayor robustez del sistema.
La robustez de un sistema debe ser uno de los objetivos principales del diseño. El sistema debe estar protegido contra errores y ofrecer diagnósticos que permitan identificar fallas, en particular aquellas que son fatales. Durante el desarrollo, a veces es bueno insertar instrucciones internas en el código para descubrir fallas, aunque luego se eliminen durante la producción. En general, se debe escoger lenguajes de programación que apoyen estos aspectos, como son el manejo de excepciones. Las principales consideraciones relacionadas con la robustez de un sistema son las siguientes:
El sistema debe estar protegido contra parámetros incorrectos proporcionados por el usuario. Cualquier método que acepte parámetros del usuario debe validar la entrada para evitar problemas. El diseñador de métodos debe considerar dos tipos de condiciones de error: i) errores lógicos que se identifican durante el análisis y ii) errores de implementación, incluyendo errores del sistema operativo, como los errores de asignación de memoria, o errores de archivos de entrada y salida.
El sistema no debe optimizarse hasta que este funcione de manera correcta. se debe estudiar las alternativas, como aspectos de memoria, velocidad y simplicidad de implementación. No se debe optimizar más de lo necesario, ya que la optimización compromete la extensibilidad, reusó y comprensión del sistema.
* El sistema debe incluir estructuras de datos de tamaño variable, sin límites predefinidos. Durante el diseño es difícil predecir la capacidad máxima esperada para la estructura de datos en la aplicación. Por tanto, se deben escoger estructuras de datos como las listas, a diferencia de los arreglos.
* El sistema debe instrumentar un monitoreo de rendimiento y búsqueda de errores. El esfuerzo para llevarlo a cabo depende del ambiente de programación. Si el lenguaje de implementación no proporciona ningún apoyo, se añaden métodos de impresión para cada clase. También se añaden mensajes de entrada y salida a los métodos imprimiendo selectivamente estos valores.
El encapsulamiento es fundamental para la robustez del sistema. Ocultar la información interna, atributos e implementación de métodos de una clase, permite cambiarla sin afectar el resto del sistema. Únicamente la interface de los métodos afecta a las demás clases.
*REUSO
* El reusó es en aspecto fundamental del diseño. Cuanto más se pueda reutilizar el código será mejor la robustez del sistema las siguientes son algunas estrategias para mejorar las posibilidades del reusó de los diseño.
* A través de la herencia se incrementa el reuso del código. Se toman las aspectos comunes a clases similares utilizando superficies comunes. Este en enfoque es efectivo cuando las diferencias entre las clases son pequeñas y las similitudes son grandes. Es importante considerar la naturaleza de cada herencia para asegurar que no se llegue a extremos donde la aplicación de la herencia sea inadecuada.
* El uso impropio de la herencia hace que los programas sean difíciles de mantener y extender. Como alternativa, la delegación provee un mecanismo para el reusó de código, pero sin utilizar la herencia. Esto se basa en el uso de agregación a través de clases intermediarias que ocultan la funcionalidad de las clases a las cuales se delega.
Extensibilidad
* Se debe encapsular otra vez la clases, ocultando su estructura internas a las otras clases. Sólo los métodos de la clase deben accesar a sus atributos.
* No se deben exportar estructuras de datos desde un método. Las estructuras de datos internas son específicas para el algoritmo del método. Si se exportan las estructuras se limita la flexibilidad para cambiar el algoritmo más adelante.
* Una clase particular debe tener un conocimiento limitado de la arquitectura de clases del sistema. Este conocimiento abarcará únicamente las asociaciones entre ésta y sus clases vecinas directas. Cualquier interacción con un vecino indirecto, se deberá hacer mediante llamadas a los vecinos directos
* Se debe evitar expresiones que requieran un conocimiento explícito de los tipos de objetos. En su lugar, se debe de aprovechar el polimorfismo a fin de seleccionar el comportamiento a ejecutarse, basado en el tipo implícito del objeto.
* Se debe distinguir entre operaciones privadas y públicas. Se vuelve costoso cambiar operaciones públicas, debiendo ser definidas con cuidado. Las operaciones privadas son internas en la clase y sirven únicamente de ayuda para implementar operaciones públicas. Las operaciones privadas pueden modificarse sin afectar otras clases.
4.2 DISEÑO DE OBJETOS O DISEÑO DETALLADO
Este
numeral contiene las definiciones completas de los casos de uso de la solución,
el modelo de clases y las asociaciones que se utilizarán en la implementación,
así como las interfaces y algoritmos de los métodos utilizados para implementar
las operaciones.
Se
recomienda elaborar y documentar los siguientes modelos:
4.1.1. Modelos de Casos de Uso
4.1.1.1. Concepto
En
esta sección se describir el límite y la interacción entre el sistema y los
usuarios mediante casos de uso. Un Caso de Uso es una capacidad funcional
simple e indivisible de un sistema de software, que permite que un usuario que
interactúa con el sistema obtenga un resultado útil. A continuación se aclaran
algunos elementos importantes de esta definición:
- Por simple se entiende que, ante varias alternativas para llegar a un mismo objetivo, se usará el mecanismo más sencillo que esté al alcance del usuario y que cumpla los requerimientos planteados. Por ejemplo, ante varias alternativa de autenticación de un usuario (login/password, reconocimiento de la huella dactilar, reconocimiento del iris, reconocimiento del DNA, etc.), se escogerá la mas sencilla que garantice el objetivo que se busca.
- Por indivisible se entiende que el Caso de Uso maneja una clase de datos que puede ser tratada de manera uniforme. Lo contrario de “indivisible” sería que la clase de datos que se maneja en el Caso de Uso deba ser primero clasificada en una de varias alternativas, y que dependiendo de cual sea la alternativa resultante, tenga un tratamiento significativamente diferente al de otras alternativas. Por ejemplo un Caso de Uso “Registrar contrato laboral” puede considerarse “indivisible” si todos los contratos que se van a registrar son de la misma naturaleza jurídica, y en consecuencia, reciben el mismo tratamiento. Por el contrario, si los contratos son de naturaleza diferente (p. ej. ‘contrato a término indefinido’, ‘contrato por prestación de servicios’, ‘contrato de aprendiz del Sena’, etc.), en realidad habrá un Caso de Uso por cada una de las clases de contrato, puesto que el tratamiento de cada uno de estos es significativamente distinto.
- Por resultado útil se entiende llegar a un estado (p. ej., el contrato laboral fue verificado y guardado en la Base de datos), u obtener un resultado (p. ej. para un contrato dado se obtuvo la lista de descuentos y retenciones por efectuar) que satisface una de las necesidades para las cuales se construye el sistema.
Se
pueden diagramar los casos de uso como procesos generales y procesos
individuales. Un ejemplo de caso de uso es el siguiente:
Figura
3. Ejemplo de Modelo de Casos de Uso
Cada
diagrama va acompañado del documento de descripción correspondiente. Un ejemplo
del formato para la descripción de un caso de uso es el siguiente:
Tabla
1. Ejemplo de Documentación de un Modelo de Casos de Uso
|
Documentación
Modelo de Casos de Uso
|
||
|
Nombre del Caso de
Uso:
Versión:
|
||
|
Descripción
|
||
|
Actores que lo utilizan
·
Actor
o rol
·
Caso
de uso
|
||
|
Propósito
|
||
|
Evento que inicia el caso de uso –
Precondiciones
|
||
|
Proceso del negocio asociado
|
||
|
Clasificación
|
||
|
|
||
|
Descripción de las secuencias
Se explica
la secuencia más común de los pasos del proceso.
|
Respuesta del Sistema / Servicio
Potencial
Descripciones
numeradas de las respuestas o de los resultados del caso de uso.
|
|
|
1.
|
|
|
|
2.
|
|
|
|
Curso Alterno de los Eventos
Describe
opciones importantes o excepciones que pueden presentarse en relación con el
curso normal. Si son complejas se pueden convertir en nuevo caso de uso.
|
||
|
|
||
|
Requerimientos no funcionales:
|
||
|
Responsable:
|
||
|
Criterios de aceptación:
|
||
|
Autor:
|
||
|
Actualizado por:
|
Fecha de actualización:
|
|
4.1.1.2. Categorización
Una
vez desarrollados los diagramas y las respectivas descripciones, se procede a
categorizar los Casos de Uso de acuerdo a su complejidad y grado de importancia
(Por Ej. ¿El caso de uso corresponde a proceso de misión crítica?)y,
relacionarlos en una tabla con aspectos como los siguientes:
1: Repercusión en el diseño
arquitectónico
2: Incluye funciones complejas
3: Representa procesos primarios del
negocio
4.1.1.3. Clasificación
Finalmente
se realiza un resumen de la clasificación.
Tabla
2. Ejemplo para la Clasificación
de Casos de Uso
|
CLASIFICACION
|
CASO
DE USO
|
|
|
|
|
|
|
|
|
|
4.1.2. Modelos de Clases
Un
modelo de clases muestra la estructura (los atributos) y el comportamiento
(operaciones) de una clase y las restricciones que se aplican a la manera en
que se conectan los objetos.
En
esta sección se describen las clases y los objetos que conformarán el sistema:
Se representan los aspectos estáticos del sistema, se describen los tipos de
objetos o conceptos y las diferentes clases de relaciones estáticas que existen
entre ellos.
A
continuación se dan ejemplos de: Formato de documentación de un modelo de
clases, diagrama de modelo de clases y ejemplo de especificación de contratos
para operaciones.
Tabla
3. Ejemplo de Documentación de un Modelo de Clases
|
Documentación Modelo de Clases
|
|||||||
|
|
|||||||
|
Nombre de la Clase
|
|||||||
|
Descripción
|
|||||||
|
Categoría Padre
|
|||||||
|
Atributos
|
|||||||
|
Nombre
|
Descripción*
|
Tipo de datos**
|
|||||
|
|
|
|
|||||
|
|
|
|
|||||
|
|
|
|
|||||
|
Operaciones o Métodos
|
|||||||
|
Nombre
|
Objetivo
|
Parámetros
de entrada
|
Valor
que retorna
|
||||
|
Parámetro
|
Tipo
|
Parámetro
|
Tipo
|
||||
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
||
|
Asociaciones
|
|||||||
*
Incluye valores que puede tomar el atributo.
**Tipo
de datos de atributo: Booleano, Carácter, Clase, etc.
Figura
4. Ejemplo de Diagrama de Modelo de Clases
Tabla
4. Ejemplo de Especificación de Contratos
para Operaciones
|
Especificación de Contratos para
operaciones
|
|
|
|
Nombre: Nombre de la operación y sus
parámetros
|
|
Responsabilidades: Descripción informal de las responsabilidades
que debe cumplir la operación
|
|
Referencias Cruzadas: Número de referencia de las
funciones del sistema, casos de uso, etc.
|
|
Excepciones: Casos excepcionales
|
|
Salida: Salida de la interfaz del usuario;
por ejemplo, mensajes o registros que se muestran al usuario.
|
|
Notas: Notas de diseño, algoritmos e
información a fin
|
|
Precondiciones: Suposiciones acerca del estado del
sistema antes de ejecutar la operación.
|
|
Postcondiciones: Estado del sistema después de la
operación. Describe en forma declarativa los cambios de estado de los objetos
en el modelo de clases.
|
4.1.3. Modelos de Interacción de Objetos o del Comportamiento del Sistema
Este
modelo comprende los diagramas de secuencia del sistema los cuales muestran
típicamente a un usuario o a un actor y los objetos y componentes con los que
interactúen durante la ejecución de un Caso de Uso.
En
esta sección se describe cómo interactuarán los objetos en el sistema entre sí
para realizar el trabajo. Se recomienda describir el flujo de mensajes de un
objeto a otro y, la representación de los métodos y los eventos soportados por
un/a objeto/clase.
Un
ejemplo de diagrama de secuencia se presenta a continuación, con el usuario o
actor a la izquierda iniciando un flujo de eventos y mensajes que corresponden
al escenario del caso de uso.
Figura
5. Ejemplo de Diagrama de Secuencia
4.1.4. Modelo de Componentes
El
diagrama de componentes muestra la relación entre componentes de software, sus
dependencias, su comunicación su ubicación y otras condiciones.
En
esta sección se ilustran los componentes de software que se usarán para
construir el sistema.
Se
pueden construir a partir del modelo de clases y escribir desde cero para el
nuevo sistema o se pueden importar de otros proyectos y de productos de terceros.
Los componentes son agregaciones de alto nivel de las piezas de software más
pequeñas y proveen un enfoque de construcción de bloques de “caja negra” para
la elaboración de software.
Un
ejemplo de un componente puede ser un control ActiveX; la interfaz de usuario
como un servidor de reglas de negocio, etc. A continuación se presenta un
ejemplo de un modelo de componentes:
Figura
6. Ejemplo de Modelo de Componentes
4.1.5. Esquema de Interoperabilidad
En
esta sección se especifica el esquema de interoperabilidad de la solución con
otros sistemas de información y como será dicha interacción, es decir quién la
genera, en qué eventos la genera y qué datos genera.
A
continuación se presenta un ejemplo de tabla resumen sobre el esquema
solicitado:
Tabla
5. Ejemplo de Especificación del Esquema de
Interoperabilidad
|
OBJETIVO DE LA INTEROPERABILIDAD
|
SISTEMA PRESTADOR DEL SERVICIO
|
SISTEMA CONSUMIDOR DEL SERVICIO
|
EVENTO QUE GENERA INTEROPERABILIDAD
|
|
Propósito del
requerimiento de interoperabilidad
|
Nombre que ofrece el
servicio.
|
Nombre del sistema que
utiliza el sistema ofrecido.
|
Describa que acciones o
que eventos generan la interoperabilidad.
|
4.1.6. Esquema de Seguridad
En
esta sección se especifican en forma detallada los componentes de seguridad requeridos
por la solución tecnológica para garantizar aspectos como la integridad,la
confidencialidad y la disponibilidad de la información así como los niveles de
acceso a la misma. Se recomienda indicar los estándares aplicados.
4.1.7. Modelo de Estructura de Datos
En
esta sección, se presenta en forma detallada la estrategia definida para
diseñar e implementar el repositorio de datos que soporta la funcionalidad del
sistema.
4.1.8. Infraestructura Tecnológica
En
esta sección se define la plataforma tecnológica de hardware, software y
comunicaciones que se requiere para implementar y utilizar el sistema propuesto.
Se recomienda tener en cuenta los modelos de clases y de componentes realizados
anteriormente.
4.1.9. Modelo de Despliegue Físico (o de Deployment)
En
esta sección se describe en detalle la forma en la que los componentes se
desplegarán a lo largo de la infraestructura del sistema: Se detallan las
capacidades de red requeridas, las especificaciones del servidor, los
requisitos de hardware, los requisitos de seguridad en telecomunicaciones (firewall,
bloqueo de puertos, etc.), controles de acceso (autenticación y autorización,
encriptación, etc.) y otra información relacionada al despliegue del sistema
propuesto.
Se
recomienda mostrar la arquitectura técnica en términos de procesadores y
configuraciones de dispositivos. A continuación se presenta un ejemplo de dicho
modelo:
Figura
7. Ejemplo de Modelo de Despliegue Físico
4.1.10.Diagramas de Implementación
En
esta sección se muestran los diagramas de implementación, los cuales están asociadosa
los casos de uso para así documentar qué elementos del diseño (por ejemplo,
componentes y clases) implementarán la funcionalidad del caso de uso en el
nuevo sistema. Esto provee un alto grado de trazabilidad al diseñador, al
cliente y al equipo que construirá el sistema. A continuación se presenta un
ejemplo de dicho modelo:
Figura
8. Ejemplo de Diagrama de Implementación
4.1.11.Diseño de Pantallas
En
esta sección se determina el tipo de interfaz gráfica, el tamaño de las
pantallas, el color, el tipo y tamaño de la letra, el estilo de botones, los
logos empresariales a utilizar, etc.
Se
recomienda cumplir con los siguientes estándares:
- Las páginas que reemplazan un formulario físico existente deben asemejarse al formulario correspondiente de la mejor manera posible.
- Si el formulario de captura de datos es extenso, se debe dividir en varias páginas navegables secuencialmente a modo de asistente.
- Los tipos y tamaños de fuentes utilizadas deben ser adecuados para garantizar la legibilidad a la mayor cantidad de usuarios finales.
4.1.12.Diseño de Reportes
En
esta sección se determinanlos tipos de reportes y el contenido de cada uno de
ellos, especificando aspectos estándar, como por ejemplo los siguientes:
- Los reportes deben generarse presentando un encabezado que describa brevemente el tipo de reporte y la fuente de datos que se está usando para su generación, número de páginas y total de páginas, logos, títulos, entre otros.
- La información de los reportes se debe presentar de forma jerárquica y tabulada, garantizando la legibilidad de los diferentes registros resaltándolos de forma alternada.
- Tipo de reporte, detallado o resumido.
- Los totales, promedios y, en general, los datos agregados deben aparecer resaltados y deben ir acompañados de una descripción clara y concisa.
- El diseño de salida de cada reporte (tamaño de papel, tamaño de letra, orientación de la página).
- Si la impresión del reporte obedece a un diseño especifico normatizado por entidades externas o internas a la organización.
- Los datos necesarios para realizar los diferentes filtros.
- Tipo de impresora a utilizar
4.1.13.Requerimientos No Funcionales
En
esta sección se establecen todas las especificaciones no funcionales a tener en
cuenta en la construcción del sistema, por ejemplo:
- Los parámetros especiales
- Las características de usabilidad y disponibilidad
- Los criterios de desempeño y la capacidad de soporte de los elementos esenciales de la plataforma.
- Procesos de conectividad a través de Internet para solicitud, revisión o consulta por parte de usuarios individuales o administradores delegados.
- Procesos de comunicación entre las entidades asociadas al proceso, para trámites y modificaciones al proceso. Para toda esta serie de procesos de interacción y comunicación han de requerirse mecanismos de protección basados en procesos fundamentados en el manejo de certificados digitales.
- Definición de elementos y mecanismos de protección para mantener los canales de comunicación con otros sistemas libres de intervención, monitoreo o modificaciones de alguna índole, sobre la información que transportan.
- Esquemas adicionales de certificación que garanticen que cada uno de los extremos participantes en el proceso transaccional, estén debidamente autenticados ante una entidad certificadora válida, ante las regulaciones legales del gobierno colombiano (por ejemplo Certicámara).
4.3 Diseño del Sistema
Sin duda, realizar de manera adecuada cada una
de las actividades que conlleva la Ingeniería del Software es indispensable
para la realización de un proyecto software de calidad. Por lo tanto, no se
puede decir que ninguna de estas actividades sea más importante que otra. Sin
embargo, si podemos decir que la actividad de diseño es la más delicada y la
más laboriosa de llevar a cabo.
Es delicada porque si no se lleva a cabo
correctamente se hace imposible el codificar, de manera correcta, en la
actividad de implementación el modelo obtenido en el análisis del sistema, lo
que puede repercutir en el desperdicio de todo el esfuerzo realizado durante
las primeras actividades de la Ingeniería del Software.
Y es laboriosa porque las estrategias a seguir
para conseguir que esta traducción entre modelo y código se lleve a cabo correctamente
son muy diversas y bastante complejas.
Se puede decir, por tanto, que el diseño del
sistema es la actividad de la Ingeniería del Software en la que se identifican
los objetivos finales del sistema y se plantean las diversas estrategias para
alcanzarlos en la actividad de implementación.
Sin embargo, el sistema no se suele diseñar de
una sola vez sino que hay que diferenciar entre el diseño y estructura de los
datos que se van a manejar y el diseño de la interfaz entre la aplicación y el
usuario. Estas dos fases del diseño no se realizan de forma consecutiva una detras
de la otra sino que lo normal es realizarlas de manera concurrente y
finalizarlas a la vez.
4.3.1 Diseño de los datos
La intención de esta fase del diseño software es
determinar la estructura que poseen cada uno de los elementos de información
del sistema, es decir, la estructura de los datos sobre los que va a trabajar.
Estos elementos son:
- Las películas, de
las que conocemos su nombre, su ano de producción, su fecha de estreno, el/los géneros
a los que se adscribe y la URL de su entrada en IMDB.
- Los usuarios, de los que conocemos su
edad, si es hombre o mujer, a que se dedica y su código postal además de su
identificador del sistema y el número de películas que ha puntuado.
- Las puntuaciones, de las que conocemos el
usuario que las hace, las películas que las reciben y, obviamente, el valor
numérico de las mismas.
- Las películas alquiladas por
los usuarios pero todavía no puntuadas.
Una vez determinados cuales son los elementos de
información del sistema, se deben obtener sus representaciones en forma de
tablas de una base de datos. Para ello, se debe realizar primeramente un diseño
conceptual de la base de datos para, posteriormente, obtener las tablas
requeridas. Para realizar este diseño conceptual se utilizara el modelo
Entidad-
Relación.
Modelo Entidad-Relación
El modelo Entidad-Relación (también conocido por
sus iniciales: E-R) es una técnica demodelado de datos que utiliza diagramas
entidad-relación. No es la única técnica de modeladopero si es la más extendida
y utilizada.
Un diagrama entidad-relación está compuesto por
tres tipos de elementos principales:
- Entidades: objetos (cosas, conceptos o personas)
sobre los que se tiene información. Se representan mediante rectángulos
etiquetados en su interior con un nombre. Una instancia es
cualquier ejemplar concreto de una entidad.
- Relaciones: interdependencias entre uno o más
entidades. Se representan
Mediante rombos etiquetados en su interior con
un verbo. Si la relación es entre una entidad consigo mismo se denomina reflexiva, si
es entre dos entidades se denomina binaria, ternaria si es
entre tres y múltiple
si es entre más (muy raro).
- Atributos: características propias de una
entidad o relación. Se representan mediante elipses etiquetados en su interior
con un nombre.
En los diagramas entidad-relación también hay
que tener en cuenta otros aspectos como pueden ser:
- Entidades
débiles: son aquellas que no se pueden identificar unívocamente solo con sus
atributos, es decir, necesitan de estar relacionadas con otras entidades para
existir. Se representan con dos rectángulos concéntricos de distinto tamañocon
un nombre en el interior del mas pequeño.
- Cardinalidad
de las relaciones: existen tres tipos de cardinalidades de una relaciónsegún el
número de instancias de cada entidad que involucren:
- Uno a uno: una instancia de la entidad A
se relaciona solamente con unainstancia de la entidad B. (1:1)
- Uno a muchos: cada instancia de la entidad
A se relaciona con varias de laentidad B. (1:*)
- Muchos a muchos: cualquier instancia de la
entidad A se relaciona concualquier instancia de la entidad B. (*:*)
- Claves:
cada entidad de un diagrama entidad-relación debe tener una clave, debeestar
formada por uno o más de sus atributos.
Una vez conocidos los elementos que forman parte
de un diagrama entidad-relaciónpodemos empezar a desarrollar el modelo
entidad-relación. Los pasos a seguir son lossiguientes:
1. Convertir el enunciado del problema (o, como
es nuestro caso, los elementos delsistema software) en un Esquema Conceptual
del mismo.
2. Convertir este Esquema Conceptual (o EC) en
uno más refinado conocido como
Esquema Conceptual Modificado (ECM).
3. Obtener las tablas de la base de datos a
partir del Esquema Conceptual
Modificado.
4.4.- REVICION DE DISEÑO
Durante la revisión del diseño, se comprobará que
se trabaja según los requisitosiniciales y cumpliendo las normas y estándares
que hayan sido programados conrespecto a:
• Gestión de contraseñas.
• Gestión de perfiles de
usuario de la aplicación.
• Registro de accesos.
• Funcionalidad definida
para los distintos módulos de trabajo.
Para verificar el diseño y con ello comprobar su
correcto funcionamiento, seefectuará el plan de pruebas. Este consistirá en
sucesivas entradas de datos endiferentes situaciones, es decir, tanto
situaciones rutinarias con operacionescomunes como acciones más complejas.
De su resultado se verificará el diseño del
software o, por el contrario, en caso deser necesario se integrarán nuevos
componentes y nuevas funcionalidades paraqueel software tenga el rendimiento
esperado.
Para un mejor control de las aplicaciones y
siempre buscando la mejora continua deesta fase, se empleará el Documento de
Cambios donde se recogerá información delas distintas tipologías de las
modificaciones a efectuar para que sirva deretroalimentación para futuros
cambios.
Las inspecciones de
software surgen a partir de la necesidad de producir software de alta calidad
Algunos grupos de desarrollo creen que la calidad del software es algo en lo que deben preocuparse una vez que se ha generado el código. ¡Error¡ La garantía de la calidad del software es una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería de software La SQA (Software QualityAssurance) engloba:
•
Un enfoque de gestión de calidad
•
Tecnología de Ingeniería de Software efectiva (métodos y
herramientas)
•
Revisiones técnicas formales que se aplican durante el
proceso del software
•
Una estrategia de prueba multiescalada
•
Un control de la documentación del software y de los
cambios realizados
•
Un procedimiento que asegure un ajuste a los estándares
de desarrollo de software
•
Mecanismos de medición y de generación de informes
El control
de la calidad es una serie de revisiones, y pruebas utilizados a los largo del
ciclo de desarrollo para asegurar que cada producto cumple con los requisitos
que le han sido asignados.
4.5.- DIAGRAMAS DE SECUENCIA DE DISEÑO
El diagrama de secuencia es
un tipo de diagrama usado para modelar interacción entre objetos en un sistema
según UML. En inglés se pueden encontrar como
"sequencediagram", "event-trace diagrams",
"eventscenarios" o "timing diagrams"1
Utilidad
Un diagrama
de casos de uso muestra la interacción de un conjunto de objetos en
una aplicación a través del tiempo y se modela para cada caso de uso. Mientras
que el diagrama de casos de uso permite el
modelado de una vista business del escenario, el diagrama de
secuencia contiene detalles de implementación del escenario, incluyendo los
objetos y clases que se usan para implementar el escenario y mensajes
intercambiados entre los objetos.
Típicamente se
examina la descripción de un caso de uso para determinar
qué objetos son necesarios para la implementación del escenario. Si se dispone
de la descripción de cada caso de uso como una
secuencia de varios pasos, entonces se puede "caminar sobre" esos
pasos para descubrir qué objetos son necesarios para que se puedan seguir los
pasos. Un diagrama de secuencia muestra los objetos que intervienen en el
escenario con líneas discontinuas verticales, y los mensajes pasados entre los
objetos como flechas horizontales.
Tipos de mensajes
Existen dos tipos de
mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden
con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el
mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se
representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan
inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se
representan con flechas con la cabeza abierta.
También se representa
la respuesta a un mensaje con una flecha discontinua.
Pueden ser usados en dos formas
De instancia: describe un escenario
específico (un escenario es una instancia de la ejecución de un caso de uso).
·
Genérico: describe la interacción para un caso de uso; Utiliza
ramificaciones ("Branches"), condiciones y bucles.
ESTRUCTURA
Los mensajes se
dibujan cronológicamente desde la parte superior del diagrama a la parte
inferior; la distribución horizontal de los objetos es arbitraria. Durante el
análisis inicial, el modelador típicamente coloca el nombre 'business' de un
mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre
'business' es reemplazado con el nombre del método que está siendo llamado por
un objeto en el otro. El método llamado, o invocado, pertenece a la definición
de la clase instanciada por el objeto en la recepción final del mensaje.
4.6 HERRAMIENTAS
CASE PARA EL DISEÑO DEL SOFTWARE
Las computadoras afectan nuestras
vidas nos guste o no. Utilizamos computadoras en nuestra vida diaria,
la mayor parte del tiempo sin reconocer conscientemente que
estamos haciéndolo. Las utilizamos en aplicaciones domésticas
como microondas, televisión, vídeo casseteras o fuera de nuestras casas en
máquinas
para tarjetas de crédito, por
ejemplo. La verdad es que no podemos escapar de las computadoras. El
rápido incremento en performance de las computadoras junto al
dramático decremento en tamaño y costo, dio como resultado una explosión
de tecnología, generándose una larga variedad de aplicaciones que éstas
pueden soportar. Desde el inicio de la escritura de software, ha existido
un conocimiento de la necesidad de herramientas automatizadas para ayudar
al diseñador del software. Inicialmente, la concentración estaba en
herramientas de apoyo a programas como traductores, recopiladores,
ensambladores, procesadores de macros, y montadores
y cargadores. Este conjunto de aplicaciones que pueden
informatizarse, aumentó dramáticamente en un breve espacio de tiempo, causando
una gran demanda por nuevo software a desarrollar. A medida que se
escribía nuevo software, habían ya en existencia millones y millones de
líneas de código que necesitaban se mantenidas y actualizadas.
QUE SON LAS
HERRAMIENTAS
Se puede definir a las Herramientas
CASE como un conjunto de programas y ayudas que dan asistencia a los
analistas, ingenieros de software y desarrolladores, durante todos los
pasos del Ciclo de Vida de desarrollo de un Software. Como es
sabido, los estados en el Ciclo de Vida de desarrollo de un Software
son: Investigación Preliminar, Análisis, Diseño, Implementación e
Instalación. CASE se define también como:
Conjunto de métodos, utilidades
y técnicas que facilitan la automatización del ciclo de vida del
desarrollo de sistemas de información, completamente o en alguna de sus
fases.
La sigla genérica para una
serie de programas y una filosofía de desarrollo de software que ayuda a
automatizar el ciclo de vida de desarrollo de los sistemas. Una innovación
en la organización, un concepto avanzado en la evolución de tecnología con
un potencial efecto profundo en la organización. Se puede ver al
CASE como la unión de las
herramientas automáticas de software y las metodologías de desarrollo de
software formales.
Variaciones en el significado de
La realización de un nuevo software
requiere que las tareas sean organizadas y completadas en forma correcta y
eficiente. Las Herramientas CASE fueron desarrolladas para automatizar
esos procesos y facilitar las tareas de coordinación de los eventos que
necesitan ser mejorados en el ciclo de desarrollo de software.
La mejor razón para la creación de
estas herramientas fue el incremento en la velocidad de desarrollo de
los sistemas. Por esto, las compañías pudieron desarrollar sistemas
sin encarar el problema de tener cambios en las necesidades del
negocio, antes de finalizar el proceso de desarrollo. También permite
a las compañías competir más efectivamente usando estos sistemas
desarrollados nuevamente para compararlos con sus necesidades
de negocio actuales. En un mercado altamente competitivo, esto
puede hacer la diferencia entre el éxito y el fracaso. Las herramientas
CASE también permiten a los analistas tener más tiempo para el análisis y
diseño y minimizar el tiempo para codificar y probar. La introducción
de CASE integradas está comenzando a tener un impacto significativo en los
negocios y sistemas de información de las organizaciones.
Con un CASE integrado, las
organizaciones pueden desarrollar rápidamente sistemas de mejor calidad
para soportar procesos críticos del negocio y asistir en el desarrollo y
promoción intensiva de la información de productos y servicios. Estas
herramientas pueden proveer muchos beneficios en todas las etapas del
proceso de desarrollo de software, algunas de ellas son:
♦ Verificar el uso de todos los
elementos en el sistema diseñado.
♦ Automatizar el dibujo de diagramas.
♦ Ayudar en la documentación del
sistema.
♦ Ayudar en la creación de relaciones
en la Base de Datos.
♦ Generar estructuras de código.
La principal ventaja de la
utilización de una herramienta CASE, es la mejora de la calidad de los
desarrollos realizados y, en segundo término, el aumento de
la productividad. Para conseguir estos dos objetivos es conveniente contar
con una organización y una metodología de trabajo, además de la propia
herramienta. La mejora de calidad se consigue reduciendo sustancialmente
muchos de los problemas de análisis y diseño, inherentes a los proyectos
de mediano y gran tamaño (lógica del diseño, coherencia, consolidación,
etc.). La mejora de productividad se consigue a través de la
automatización de determinadas tareas, como la generación de código y la
reutilización de objetos o módulos.
CLASIFICACION DE
LAS HERRAMIENTAS CASE
No existe una única clasificación de
herramientas CASE y, en ocasiones, es difícil incluirlas en una clase
determinada. Podrían clasificarse atendiendo a:
• Las plataformas que soportan.
• Las fases del ciclo de vida
del desarrollo de sistemas que cubren.
• La arquitectura de las aplicaciones que
producen.
• Su
funcionalidad. Las herramientas CASE, en función de las fases del ciclo de
vida abarcadas, se pueden agrupar
