DESCRIPCIÓN BREVE

El modelo de diseño es un refinamiento y

formalización adicional 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.

TAPIA HERNANDEZ
MODELO DE ARELI

DISEÑO FUNDAMENTOS DE INGENIERIA DE

SOFTWARE
UNIDAD 4
 INDICE

UNIDAD 4 MODELO DE DISEÑO

4.1 Estrategias de diseño……………………………………………………….PAG.2

4.2 Diseño de objetos………...………………………………………………....PAG.3

4.3 Diseño de sistema……………………………………………………..…….PAG.4

4.4 Revisión del diseño………………….…….……………………………….PAG.5

4.5 Diagramas de secuencias del diseño…………………………………...PAG.6

4.6 Herramientas CASE para el diseño…………..………………………..…PAG.7

Bibliografía…………………………………………………………….…..…PAG.9

Página 1 de 9
 4.1 ESTRATEGIA DE DISEÑO
El modelo de diseño es un refinamiento y formalización adicional 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 implementación, 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 de los sistemas proviene de cambios en el ambiente de
implementación. 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
específico.
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.

Página 2 de 9
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.
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.
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

Página 3 de 9
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.
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.
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.

Página 4 de 9
- 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.
4.4.- REVISION DEL DISEÑO
Durante la revisión del diseño, se comprobará que se trabaja según los requisitos
iniciales y cumpliendo las normas y estándares que hayan sido programados con
respecto 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, se
efectuará el plan de pruebas. Este consistirá en sucesivas entradas de datos en
diferentes situaciones, es decir, tanto situaciones rutinarias con operaciones
comunes como acciones más complejas.
De su resultado se verificará el diseño del software o, por el contrario, en caso de
ser necesario se integrarán nuevos componentes y nuevas funcionalidades para
que el software tenga el rendimiento esperado.
Para un mejor control de las aplicaciones y siempre buscando la mejora continua
de esta fase, se empleará el Documento de Cambios donde se recogerá información
delas distintas tipologías de las modificaciones a efectuar para que sirva de
retroalimentació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)

Página 5 de 9
• Revisiones técnicas formales que se aplican durante el proceso del software
• Una estrategia de prueba multi escalada
• 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

Página 6 de 9
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
Las herramientas de diseño, permiten al desarrollador crear un modelo del sistema
que se va a construir y también la evaluación de la validez y consistencia de este
modelo. Proporcionan un grado de confianza en la representación del análisis y
ayudan a eliminar errores con anticipación.
• Herramientas de análisis y diseño (Modelamiento).
• Herramientas de creación de prototipos y de simulación.
• Herramientas para el diseño y desarrollo de interfaces.
• Máquinas de análisis y diseño (Modelamiento).
El sistema experto podría incluir herramientas de diseño asistido por computadora
(CAD) con el fin de materializar las expectativas de los clientes y las aptitudes de la
empresa en el diseño final. Esto se lograría implementando una base de datos
histórica (Data Warehouse) con referencias al desarrollo de otros filtros con el fin de
comparar problemas, inconvenientes o ventajas que se tuvieron al desarrollar
dichos productos. De igual forma, para la parte de los clientes se podría implementar
una interfaz inteligente entre el sistema CAD y la base de datos del marketing que
generara un diseño base del filtro que implicara las preferencias más significativas
de los clientes. A partir de este diseño, los expertos de cada área podrían empezar
a buscar un punto de balance entre lo que el cliente quiere y lo que más le conviene
a la empresa para así obtener un diseño final de nuestro filtro.
 Producción.
 Ventas.
Ventajas de utilizar un Sistema Experto en la IC

Página 7 de 9
Los sistemas expertos propician la efectividad de la empresa en todos sus
departamentos, al automatizar algunas de las tareas de la empresa y al concentrar
toda la información competente al proceso de desarrollo del producto. De esta forma
podemos apreciar las siguientes ventajas al usar los sistemas expertos en la
ingeniería concurrente lo que generalmente se conoce como ingeniería concurrente
asistida por computadora (CACE):

Información integrada. Este aspecto es el que persigue principalmente el sistema

experto, pues se pretende juntar una gran cantidad de información que nos sirva de
base para desarrollar nuestro producto. Esto promueve el hecho de que todos los
participantes del equipo multidisciplinario tengan acceso a la información de los
demás de manera previa, con el fin de que las juntas se lleven a cabo lo más rápido
posible. La arquitectura del sistema experto podría diseñarse como una arquitectura
cliente/servidor con el fin de que los participantes puedan acceder la información en
cualquier momento e inclusive al mismo tiempo.
Comunicación eficaz. La gran cantidad de información que se encuentra al alcance
de los participantes del equipo, propicia que todos conozcan a cierto nivel el proceso
de desarrollo visto desde el punto de vista cada departamento, con esto, se evitan
discusiones sobre aspectos poco comprendidos en el proceso de diseño. Con el
conocimiento general del proceso de desarrollo del producto, la comunicación se
vuelve entonces más eficaz, pues cada participante conoce los inconvenientes y las
ventajas que se tendrían para cada departamento en función de algún cambio en el
diseño del producto.
Rápida toma de decisiones. Con la información integrada en un solo núcleo y con
la agilización de la comunicación entre los participantes del proyecto, se obtiene una
aceleración en la toma de decisiones, producto de tener un equipo de expertos en
cada área pero conocen y comprenden a las demás.
La Ingeniería Concurrente (IC) es una filosofía orientada a integrar
sistemáticamente y en forma simultánea el diseño de productos y procesos, para
que sean considerados desde un principio todos los elementos del ciclo de vida de
un producto, desde la concepción inicial hasta su disposición final, pasando por la
fabricación, la distribución y la venta. Debe otorgar además una organización flexible
y bien estructurada, proponer redes de funciones apoyadas por tecnologías
apropiadas y arquitecturas comunes de referencia (ej: computadores en red y en
bases de datos).
Retomando lo expuesto anteriormente la ingeniería concurrente es un esfuerzo
sistemático para un diseño integrado, concurrente del producto y de su
correspondiente proceso de fabricación y de servicio. Pretende que los
desarrolladores, desde un principio, tengan en cuenta todos los elementos del ciclo
de vida del producto, desde el diseño conceptual, hasta su disponibilidad incluyendo

Página 8 de 9
calidad, costo y necesidades de los clientes. Persigue un estudio sistemático,
simultáneo, en el momento del desarrollo del producto, de las necesidades de
mercado que va a cubrir, de los requisitos de calidad y costos, de los medios y
métodos de fabricación, venta y servicio necesarios para garantizar la satisfacción
del cliente.
Involucra el trabajo coordinado y simultáneo de los diversos departamentos de la
empresa: Marketing, Ingeniería del Producto, Ingeniería del Proceso, Producción,
Calidad, Ventas, Mantenimiento, Costos, etc.
La ingeniería concurrente sustituye el típico entorno de trabajo en el desarrollo y
fabricación del producto basado en un diagrama secuencial de actuación de los
distintos departamentos, por un trabajo concurrente, simultáneo, en equipo, de
todos a partir del mismo momento en que se inicia el proceso.
BIBLIOGRAFIA
http://ithuni4coronel.blogspot.mx/2013/05/46-herramientas-case-para-el-
diseno.html
http://unudad1conceptos.blogspot.mx/2013/05/unidad4.html

Página 9 de 9