3 Fundamentos de Ing. de Sw.

FUNDAMENTOS
DE
INGENIERÍA DE SOFTWARE
2018
2018 INGENIERÍA DE SOFTWARE MASI Página 2 de 51
UNIDAD I FUNDAMENTOS DE INGENIERÍA DE SOFTWARE
1.1 CONCEPTOS BÁSICOS
La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas y

técnicas que se utilizan en el desarrollo de los programas informáticos (software).
Esta disciplina trasciende la actividad de programación, que es la actividad principal a la hora de crear un
software. El ingeniero de software se encarga de toda la gestión del proyecto para que éste se pueda
desarrollar en un plazo determinado y con el presupuesto previsto.
La ingeniería de software, por lo tanto, incluye el análisis previo de la situación, el diseño del proyecto, el
desarrollo del software, las pruebas necesarias para confirmar su correcto funcionamiento y la
implementación del sistema.
Cabe destacar que el proceso de desarrollo de software implica lo que se conoce como ciclo de vida del
software, que está formado por cuatro etapas: concepción, elaboración, construcción y transición.
La concepción fija el alcance del proyecto y desarrolla el modelo de negocio; la elaboración define el
plan del proyecto, detalla las características y fundamenta la arquitectura; la construcción es el
desarrollo del producto; y la transición es la transferencia del producto terminado a los usuarios.
Una vez que se completa este ciclo, entra en juego el mantenimiento del software. Se trata de una fase
de esta ingeniería donde se solucionan los errores descubiertos (muchas veces advertidos por los
propios usuarios) y se incorporan actualizaciones para hacer frente a los nuevos requisitos. El proceso de
mantenimiento incorpora además nuevos desarrollos, para permitir que el software pueda cumplir con
una mayor cantidad de tareas.
Los Ingenieros de Software deben:
• Adoptar un enfoque sistemático para llevar a cabo su trabajo.

• Utilizar las herramientas y técnicas apropiadas para resolver el problema planteado, de acuerdo a las
restricciones de desarrollo y a los recursos disponibles.
1.2 EL PAPEL EVOLUTIVO DEL SOFTWARE
Hoy en día, el software tiene un papel dual. Es producto y canal de distribución de este. Como producto,
ofrece la potencia de cómputo presentada como hardware de una computadora o, de manera más
global por una red de computadoras accesible mediante hardware local y de acceso físico. Sin importar
el lugar en que resida el software, ya sea en un celular o dentro de una computadora central, éste es un
transformador de información; realiza la producción, el manejo, la adquisición, la modificación, el
despliegue o la transmisión de la información que puede ser tan simple como un solo bit o tan compleja
como una presentación multimedia. En su papel de vehículo para la entrega de un producto, el software
actúa como la base para el control de la computadora (Sistemas Operativos), la comunicación de
información (redes), y la relación y el control de otros programas (utilerías de software y ambientes).
PRIMERA ERA (1950 – 1965)

• Se trabajaba con la idea de “Codificar y Corregir”.
• No existía un planteamiento previo.
• No existía documentación de ningún tipo.
• Existencia de pocos métodos formales y pocos creyentes en ellos.
• Desarrollo a base de prueba y error.
SEGUNDA ERA (1965 – 1972)

• Se busca simplificar código.
• Aparición de Multiprogramación y Sistemas Multiusuarios.
• Sistemas de Tiempo Real apoyan la toma de decisiones.
• Aparición de Software como producto. (Casas de Software).
• Se buscan procedimientos para el desarrollo del Software.
TERCERA ERA (1972 – 1985)

• Nuevo Concepto: Sistemas Distribuidos.
• Complejidad en los Sistemas de Información.
• Aparecen: Redes de área local y global, y Comunicadores Digitales.
• Amplio Uso de Microprocesadores.
CUARTA ERA (1985 - 1995)

• Impacto Colectivo de Software.
• Aparecen: Redes de Información, Tecnologías Orientadas a Objetos.
• Aparecen: Redes Neuronales, Sistemas Expertos y SW de Inteligencia Artificial.
• La información como valor preponderante dentro de las Organizaciones.
QUINTA ERA (2000 hasta hoy en día)

Utiliza algunos requisitos de las eras anteriores solo que aumenta la omnipresencia de la web, la
reutilización de información y componentes de software:
• Codificar: Transformar mediante las reglas de un código la formulación de un mensaje.
• Hardware: Componente físico de la computadora. Por ejemplo: el monitor, la impresora o el disco
rígido. El hardware por sí mismo no hace que una máquina funcione.
• Multiprogramación: Se denomina multiprogramación a la técnica que permite que dos o más procesos
ocupen la misma unidad de memoria principal y que sean ejecutados al "mismo tiempo “.
1.3 ETAPAS DEL DESARROLLO DEL SOFTWARE
Etapa de análisis: Es el proceso de investigar un problema que se quiere resolver. Definir claramente el
Problema que se desea resolver o el sistema que se desea crear. Identificar los componentes principales
que integrarán el producto.
Etapa de Diseño: Es el proceso de utilizar la información recolectada en la etapa de análisis al diseño del
producto. La principal tarea de la etapa de diseño es desarrollar un modelo o las especificaciones para el
producto o Componentes del Sistema.
Etapa de Desarrollo: Consiste en utilizar los modelos creados durante la etapa de diseño para crear los
componentes del sistema.
Etapa de Pruebas o Verificación Prueba: Consiste en asegurar que los componentes individuales que
integran al sistema o producto cumplen con los requerimientos de la especificación creada durante la
etapa de diseño.
Se recomienda aplicar las etapas:

• Análisis
• Diseño
• Desarrollo
• Prueba
Etapa de Implementación o Entrega Implantación: Consiste en poner a disposición del cliente el

producto.
Etapa de Mantenimiento: Consiste en corregir problemas del producto y re- liberar el producto como
una nueva versión o revisión (producto mejorado).
Etapa final EOL (End-of-Life) El fin del ciclo del producto consiste en realizar todas las tareas necesarias
para asegurar que los clientes y los empleados están conscientes de que el producto ya no será vendido
ni soportado.
1.4 CLASIFICACIÓN DE LA TECNOLOGÍA EN EL DESARROLLO DE SOFTWARE (TECNOLOGÍA

ESTRUCTURADA Y ORIENTADA A OBJETOS)
Tecnologías de desarrollo estructurado

Las tecnologías de desarrollo estructurado son las más convencionales de las empleadas hoy día. Han
surgido de la evolución de las ideas de programación estructurada (hace más de veinticinco años) hacia
las fases iniciales del ciclo de vida. En su formulación actual, las notaciones empleadas en las prime-ras
fases del ciclo de vida (especificación de requisitos de usuario y sistema) suelen estar constituidas por
lenguajes gráficos que permiten: identificar el sistema y el entorno; representar el flujo de información
entre los elementos; y, describir los datos y las actividades del sistema. La idea base de esta tecnología
es que es posible estructurar el modelo de un sistema de software en base a funciones que procesan
información que reciben de otras funciones (o del exterior) y dirigen la información procesada a otros
módulos funcionales (o al exterior). El enfoque seguido, por tanto, es el de pensar en las funciones del
sistema necesarias (extraídas de los requisitos del sistema) y luego en los datos que requieren.
Tecnologías orientadas a objetos

Las tecnologías de desarrollo estructurado han demostrado sus limitaciones a la hora de organizar y
facilitar la evolución de sistemas de software complejos. La descomposición en funciones hace difícil al
diseñador mantener la relación con los objetos del mundo real sobre los que se modifican generalmente
los requisitos del usuario.
Los métodos de descomposición orientada a objetos constituyen la tendencia más influyente observada
en la ingeniería de sistemas de software en los últimos años. Con ellos nos referimos a un conjunto de
métodos (aún en fase de desarrollo o evolución) que permiten al analista diseñador concebir su sistema
identificando clases de objetos, operaciones permitidas y relaciones entre ellos como base para la
estructura del sistema a diseñar.
1.5 DEFINICIÓN E HISTORIA DE LAS HERRAMIENTAS CASE
¿Qué son las Herramientas CASE?

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.
Historia de las Herramientas CASE

Las Herramientas CASE tienen su inicio con el simple procesador de palabras que fue usado para crear y
manipular documentación. Los setentas vieron la introducción de técnicas gráficas y diagramas de flujo
de estructuras de datos. Sobre este punto, el diseño y especificaciones en forma pictórica han sido
extremadamente complejos y consumían mucho tiempo para realizar cambios.
La introducción de las herramientas CASE para ayudar en este proceso ha permitido que los diagramas
puedan ser fácilmente creados y modificados, mejorando la calidad de los diseños de software. Los
diccionarios de datos, un documento muy usado que mantiene los detalles de cada tipo de dato y los
procesos dentro de un sistema, son el resultado directo de la llegada del diseño de flujo de datos y
análisis estructural, hecho posible a través de las mejoras en las Herramientas CASE.
Pronto se reemplazaron los paquetes gráficos por paquetes especializados que habilitan la edición,
actualización e impresión en múltiples versiones de diseño. Eventualmente, las herramientas gráficas
integradas con diccionarios de base de datos para producir poderosos diseños y desarrollar
herramientas, podrían sostener ciclos completos de diseño de documentos.
Como un paso final, la verificación de errores y generadores de casos de pruebas fueron incluidos para
validar el diseño del software. Todos estos procesos pueden saberse integrados en una simple
herramienta CASE que soporta todo el ciclo de desarrollo.
1.6 CLASIFICACIÓN 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 de la
forma siguiente:
1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo
de vida del desarrollo de sistemas. Son llamadas también CASE workbench.
2. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) ofront-end, orientadas a la
automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo:
análisis y diseño.
3. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) oback-end, dirigidas a las últimas
fases del desarrollo: construcción e implantación.
4. Juegos de herramientas o Tools-Case, son el tipo más simple de herramientas CASE. Automatizan una
fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingeniería,
orientadas a la fase de mantenimiento.
UNIDAD II INGENIERÍA DE REQUISITOS
Definición: Requisito
Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.
Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para
satisfacer un contrato, estándar, especificación u otro documento formal.
Ingeniería de requerimientos
El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es
llamado ingeniería de requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una
especificación de requisitos de software correcta y completa.
En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos o Ingeniería de

requerimientos comprende todas las tareas relacionadas con la determinación de las necesidades o de
las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos
requisitos de los inversores, que pueden entrar en conflicto entre ellos.
El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de
alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin
ambigüedades o contradicciones, etc.
La parte más difícil de construir un sistema es precisamente saber qué construir. Ninguna otra parte del
trabajo conceptual es tan difícil como establecer los requisitos técnicos detallados, incluyendo todas las
interfaces con gente, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema
si es hecha mal. Ninguna es tan difícil de corregir más adelante. Entonces, la tarea más importante que
el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los
requerimientos del producto.
Tipos de Requerimientos
Los requerimientos de software pueden dividirse en 2 categorías: requerimientos funcionales y
requerimientos no funcionales.
Requerimientos funcionales
Son los que definen las funciones que el sistema será capaz de realizar, describen las transformaciones
que el sistema realiza sobre las entradas para producir salidas.
Requerimientos no funcionales
Requerimientos no funcionales tienen que ver con características que de una u otra forma puedan
limitar el sistema, como, por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario,
fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad,
estándares, etc.
Características de un Requerimiento
Es importante no perder de vista que un requerimiento debe ser:
 Especificado por escrito: Como todo contrato o acuerdo entre dos partes.
 Posible de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo se sabe

si se cumplió con él o no?
 Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y
clara para aquellos que vayan a consultarlo en un futuro.
 Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si

se proporciona la información suficiente para su comprensión.
 Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
 No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje

usado en su definición no debe causar confusiones al lector.
2.1 TAREAS DE LA INGENIERÍA DE REQUISITOS
Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a
las actividades involucradas en el descubrimiento de los requisitos del sistema.
Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en
descubrir problemas con los requisitos del sistema identificados hasta el momento.
Especificación: En esta fase se documentan los requisitos acordados con el cliente, en un nivel apropiado
de detalle.
Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar los requisitos, es decir, verificar
todos los requisitos que aparecen en el documento especificado para asegurarse que representan una
descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los
requisitos sean consistentes y que estén completos.
2.2 TÉCNICAS DE LA INGENIERÍA DE REQUISITOS
Entrevistas y Cuestionarios
Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o de

grupos.
Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de
preguntas relacionadas con varios aspectos de un sistema.
Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema
propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema
propuesto o que serán afectados por él. El éxito de esta técnica depende de la habilidad del
entrevistador y de su preparación para la misma.
Sistemas existentes
Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el
sistema a ser construido. Por un lado, podemos analizar las interfaces de usuario, observando el tipo de
información que se maneja y cómo es manejada, por otro lado, también es útil analizar las distintas.
Salidas que los sistemas producen (listados, consultas, etc.), porque siempre pueden surgir nuevas ideas
sobre la base de estas.
Lluvia de ideas
Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar la
máxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea
eso no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas
ideas.
Prototipos
Durante la actividad de extracción de requerimientos, puede ocurrir que algunos requerimientos no

estén demasiado claros o que no se esté muy seguro de haber entendido correctamente los
requerimientos.
Obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema final.
Entonces, para validar los requerimientos hallados, se construyen prototipos. Los prototipos son
simulaciones del posible producto, que luego son utilizados por el usuario final, permitiéndonos
conseguir una importante retroalimentación en cuanto a si el sistema diseñado con base a los
requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva.
El desarrollo del prototipo comienza con la captura de requerimientos. Desarrolladores y clientes se

reúnen y definen los objetivos globales del software, identifican todos los requerimientos que son
conocidos, y señalan áreas en las que será necesaria la profundización en las definiciones. Luego de esto,
tiene lugar un “diseño rápido”. El diseño rápido se centra en una representación de aquellos aspectos del
software que serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseño rápido
lleva a la construcción de un prototipo.
Casos de Uso
Los casos de uso son una técnica para especificar el comportamiento de un sistema.
“Un caso de uso es una secuencia de transacciones que son desarrolladas por un Sistema en respuesta a
un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para
especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios
y/o otros sistemas”
Los casos de uso permiten entonces describir la posible secuencia de interacciones entre el sistema y
uno o más actores, en respuesta a un estímulo inicial proveniente de un actor, es una descripción de un
conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el
sistema.
2.3 MODELADO DE REQUISITOS
El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe
ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el
desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la
percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo.
El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de

todos los demás modelos en el desarrollo de software. En general, el cualquier cambio en la
funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a este nivel que
posteriormente. El modelo de requisitos que desarrollaremos se basa en la metodología Objectory
(Jacobson et al. 1992), basada principalmente en el modelo de casos de uso.
Actualmente esta metodología es parte del Proceso Unificado de Rational (RUP). El modelo de casos de
uso y el propio modelo de requisitos son la base para los demás modelos, como se describió
anteriormente en el Capítulo 3.
Se resume aquí:
 Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se
desarrolla en cooperación con otros modelos como se verá más adelante.
 Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de

análisis, que es estable con respecto a cambios, siendo un modelo lógico independiente del ambiente
de implementación.
 Diseño: La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo
de diseño, adaptándose al ambiente de implementación real y refinándose aún más.
 Implementación: Los casos de uso son implementados mediante el código fuente en el modelo de
implementación.
 Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de
integración.
 Documentación: El modelo de casos de uso debe ser documentado a lo largo de las diversas
actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de
administración, etc.
2.4 HERRAMIENTAS CASE PARA LA INGENIERÍA DE REQUISITOS
A medida que pasa el tiempo se logra entender que el empleo del software es una buena opción para
agilizar y sistematizar las tareas en el desarrollo de procesos. El desarrollo de software no es la
excepción; en este caso dichas herramientas se han denominado CASE (Ingeniería De Software Asistida
Por Computador). Estas incluyen un conjunto de programas que facilitan la optimización de un producto
ofreciendo apoyo permanente a los analistas, ingenieros de software y desarrolladores. CASE es la
aplicación de métodos y técnicas que dan utilidades a los programas, por medio de otros,
procedimientos y su respectiva documentación.
En este post se hace referencia a 3 herramientas que ayudan a la gestión de requisitos; es decir al
proceso de identificación, asignación y seguimiento de los mismos, incluyendo interfaz, verificación,
modificación y control de cada requisito, durante el ciclo de vida del proyecto. Los
cambios/actualizaciones de requisitos deben ser gestionados para asegurar que se mantenga la calidad
del producto.
Hasta hace poco tiempo las herramientas para la gestión de requisitos de software se limitaban a
editores de texto, los cuales hacían de esta tarea una labor tediosa y confusa. Actualmente, se cuenta
con múltiples opciones, como las que se mencionan a continuación:
IRQA
Herramienta CASE de Ingeniería de Requisitos, diseñada para soportar las actividades realizadas en el
proceso de especificación de sistemas. Ésta facilita y formaliza la comunicación entre el cliente, el
proveedor y los distintos miembros del equipo de desarrollo. Facilita la captura, organización y análisis
de las condiciones, así como la especificación de la solución mediante el apoyo metodológico adaptable
a cada cliente.
CONTROLA
Herramienta de apoyo al proceso de ingeniería de software en pequeñas empresas. Se creó gracias a la
expansión que tuvo el mercado y a la generación de grandes y pequeñas empresas, las cuales requieren
un instrumento para el desarrollo de sus proyectos. Ofrece recursos importantes tales como:
Administración de requisitos, administración de casos de uso, administración de casos de prueba y error,
planeamiento de liberaciones, administración de implementaciones, control de dependencia entre

Implementaciones, matriz de rastreabilidad y rastreabilidad de los requisitos.
OSRMT (Open Source Requirements Management Tool)

Herramienta libre para la gestión de requisitos, cuyas principales características son: trabaja en
arquitectura cliente/servidor, desarrollada bajo Java; la versión 1.3 trae un módulo para manejar la
trazabilidad y lo introduce para el control de cambios; así mismo, genera la documentación de los
requisitos tratados.
UNIDAD III MODELO DE ANÁLISIS

3.1 ARQUITECTURA DE CLASES
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para
el diseño posterior del sistema. Como se discutió en la introducción del libro, dependiendo del tipo de
aplicación existen diversas arquitecturas que se pueden utilizar, siendo de nuestro interés aquellas
arquitecturas especialmente diseñadas para el manejo de los sistemas de información, las cuales
involucran ricas interfaces de usuario y accesos a base de datos como aspectos fundamentales de la
arquitectura.
En término de las propias arquitecturas, éstas se distinguen según la organización de la funcionalidad

que ofrecen los objetos dentro de ellas o la dimensión de los objetos. Esta dimensión corresponde a los
diferentes tipos de funcionalidad que manejan los objetos dentro la arquitectura. Por ejemplo, en el caso
de funcionalidad para el manejo de interfaces y base de datos, si existen tipos distintos de objetos para
el manejo de cada una de estas por separado, entonces se considera que la arquitectura es de dos
dimensiones. Por el contrario, si todos los objetos manejan de manera indistinta los dos tipos de
funcionalidades, entonces se considera que la arquitectura es de una sala dimensión.
Si aplicamos el concepto de dimensión a los métodos estructurados, podemos ver que estos consisten
de dos dimensiones, correspondientes a funciones y datos. Las funciones representan un eje de
comportamiento que no guarda información, mientras que los datos se ubican en un eje de información
que no contiene comportamiento. En general, ejes de funcionalidad pueden corresponder a distintos
tipos de funcionalidades, como se ve al contrastar funciones y datos versus manejo de interfaces y bases
de datos. Sin embargo, la pregunta más importante que uno se hace respecto al número y tipo de
dimensiones es: ¿Si se diseña un sistema con múltiples dimensiones, se obtendría un sistema más
robusto y sensible a modificaciones? Ante todo esta pregunta se relaciona con el concepto de
modularidad, siendo muy aceptado que cuanto mayor sea la modularidad de un sistema mayor es su
robustez y extensibilidad.
En el caso de los sistemas de información, uno de las tipos de arquitecturas más importantes es la
arquitectura MVC – Modelo, Vista, Control (Model, View, Control) popularizada por los ambientes de
desarrollo de Smalltalk. Esta arquitectura se basa en tres dimensiones principales: Modeló
(información), Vista (presentación) y Control (comportamiento) como se muestra en la Figura 7.2.
Figura 7.2 Diagrama de tres dimensiones correspondiente a la arquitectura

MVC – Modelo, Vista, Control.
La vista o presentación de la información corresponde a las interfaces que se le presentan al usuario para
el manejo de la información, donde por lo general pueden existir múltiples vistas sobre un mismo
modelo. Típicamente la información representa el dominio del problema y es almacenada en una base
de datos. Por otro lado el control corresponde a la manipulación de la información a través de sus
diversas presentaciones. Y aunque existe cierta dependencia entre estas tres dimensiones se considera
que la manera de presentar la información es independiente de la propia información y de cómo esta se
controla. Sin embargo, cada una de ellas probablemente experimente cambios a lo largo de la vida del
sistema, donde el control es el más propenso a ser modificado, seguido de la vista y finalmente el
modelo. En el modelo de análisis descrito aquí utilizaremos como base la arquitectura MVC para
capturar estos tres aspectos de la funcionalidad, como se muestra en la Figura 7.3.
Es importante notar la correspondencia con las tres dimensiones utilizadas durante el modelo de
requisitos. La razón de ser de las tres dimensiones del modelo de requisitos realmente se deriva para
lograr una rastreabilidad con la arquitectura que se desarrollará en el modelo de análisis.
Figura 7.3 Diagrama de tres dimensiones correspondiente a la arquitectura

del modelo de análisis basado en el modelo de casos de uso.
La arquitectura para el modelo de análisis será implementada mediante tres tipos o estereotipos de
objetos como elementos básicos de desarrollo como veremos a continuación.
Clases con Estereotipos
El tipo de funcionalidad o “la razón de ser” de un objeto dentro de una arquitectura se le conoce como
su estereotipo. Para los sistemas de información la arquitectura del sistema según nuestro modelo de
análisis se basa en tres estereotipos básicos de objetos:
El estereotipo entidad para objetos que guarden información sobre el estado interno del sistema, a corto
y largo plazo, correspondiente al dominio del problema. Todo comportamiento naturalmente acoplado
con esta información también se incluye en los objeto entidad. Un ejemplo de un objeto entidad es un
registro de usuario con sus datos y comportamiento asociados.
El estereotipo interface para objetos que implementen la presentación o vista correspondiente a las
interfaces del sistema hacia el mundo externo, para todo tipo de actores, no sólo usuarios humanos. Un
ejemplo de un objeto interface es la funcionalidad de interface de usuario para insertar o modificar
información sobre el registro de usuario.
El estereotipo control para objetos que implementen el comportamiento o control especificando cuando
y como el sistema cambia de estado, correspondiente a los casos de uso. Los objetos control modelan
funcionalidad que no se liga naturalmente con ningún otro tipo de objeto, como el comportamiento que
opera en varios objetos entidad a la vez, por ejemplo, hacer alguna computación y luego devolver el
resultado a un objeto interface. Un ejemplo típico de objeto control es analizar el uso del sistema por
parte de algún usuario registrado y presentar tal información posteriormente. Este comportamiento no
le pertenece a ningún objeto entidad u objeto interface específico.
Nótese que no hay ninguna restricción a los diferentes estereotipos que puedan utilizarse, no solamente
las tres anteriores.
La notación de UML para un estereotipo se muestra en la Figura 7.4.
<< estereotipo >>

Nombre de la Clase
Figura 7.4 Diagrama de clase con estereotipo.
Los tres estereotipos correspondientes a las tres dimensiones para la arquitectura del modelo de análisis
se muestran en la Figura 7.5.
Figura 7.5 Diagrama de clase para los tres estereotipos.
Considerando que habrá interacción entre los diferentes tipos de objetos, existirá cierto traslape en la
funcionalidad que los objetos ofrecen. Como se mencionó anteriormente, este traslape deberá
minimizarse para asegurar una buena extensibilidad, donde típicamente, cada tipo de objeto captura por
lo menos dos de las tres dimensiones. Sin embargo, cada uno de ellos tiene cierta inclinación hacia una
de estas dos dimensiones, como se muestra en la Figura 7.6.
Figura 7.6 Diagrama mostrando traslape en los estereotipos

de los objetos. Clases para Casos de Uso
Cuando se trabaja en el desarrollo del modelo de análisis, normalmente se trabaja con un caso de uso a
la vez. Para cada caso de uso se identifican los objetos necesarios para su implementación. Se identifican
estos objetos según sus estereotipos para corresponder a la funcionalidad ofrecida en cada caso de uso.
Se define explícitamente qué objeto es responsable de cual comportamiento dentro del caso de uso.
Típicamente se toma un caso de uso y se comienza identificando los objetos interface necesarios,
continuando con los objetos entidad y finalmente los objetos control. Este proceso se continúa a los
demás casos de uso. Dado que los objetos son “ortogonales” a los casos de uso, en el sentido de que un
objeto puede participar en varios casos de uso, este proceso es iterativo. Esto significa que cuando un
conjunto de objetos ya existe, estos pueden modificarse para ajustarse al nuevo caso de uso. La meta es
formar una arquitectura lo más estable posible, reutilizando el mayor número de objetos posible. De tal
manera, la descripción original de los casos de uso se transforma a una descripción en base a los tres
tipos de objetos, como se muestra en la Figura 7.7.
Figura 7.7 La funcionalidad de cada caso de uso es asignada a

objetos distintos y de acuerdo a los estereotipos de dichos objetos.
Se parte el caso de uso de acuerdo a los siguientes principios:
La funcionalidad de los casos de uso que depende directamente de la interacción del sistema con el
mundo externo se asigna a los objetos interface.
La funcionalidad relacionada con el almacenamiento y manejo de información del dominio del problema
se asigna a los objetos entidad.
La funcionalidad específica a uno o varios casos de uso y que no se ponen naturalmente en ningún
objeto interface o entidad se asigna a los objetos control. Típicamente se asigna a un sólo objeto control
y si éste se vuelve muy complejo se asignan objetos control adicionales.
Por ejemplo, consideremos el caso de uso imprimir archivo, usado como ejemplo en el capítulo 6 y que
se muestra nuevamente en la Figura 7.8.
Figura 7.8 Caso de uso imprimir archivo.
Para el caso de uso imprimir archivo se pueden utilizar los objetos (descritos según el diagrama de clases
correspondiente) que se muestran en la Figura 7.9. Se utilizan dos clases interface: Interface Archivo e
Interface Impresora, cinco clases entidad: Cola, Archivo con sus subclases Archivo Texto, Archivo
Formateado y Archivo Gráfico y una clase control: Servidor Impresora.
Figura 7.9 Objetos identificados para el caso de uso imprimir archivo.
La arquitectura se completa generando asociaciones entre las distintas clases como se muestra en la
Figura 7.10.
Figura 7.10 Objetos identificados para el caso de uso imprimir archivo mostrando asociaciones entre sí aunque omitiendo
multiplicidad
El desafío para generar esta correspondencia entre objetos o clases y los casos de uso es precisamente
decidir cuáles y cuantos objetos deben utilizarse en dicha correspondencia.
3.2 IDENTIFICACIÓN DE CLASES SEGÚN ESTEREOTIPOS

Para llevar a cabo la transición del modelo de requisitos al modelo de análisis se deben identificar los
objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar
los tres tipos de estereotipos de objetos. Para ello se deben identificar primero las clases borde, las
clases entidad y finalmente las de Control.
En general, los cambios más comunes a un sistema son los de funcionalidad y bordes. Los cambios de las
interfaces deben afectar solo a los objetos borde.
Los cambios a la funcionalidad son más difíciles de administrar, ya que ésta puede abarcar todos los tipos
de objetos bordes.
Toda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente
de los aspectos externos del sistema se ubica en los objetos borde, pues a través de ellos se comunican
los actores con el sistema. La tarea de una clase borde es traducir los eventos generados por un actor en
eventos comprendidos por el sistema, y traducir los eventos del sistema en una presentación
comprensible para el actor.
Las clases borde en otras palabras, describen la comunicación bidireccional entre el sistema y los
actores.
Las clases borde son bastante fáciles de identificar, donde se cuenta con al menos tres estrategias:
1. Se pueden identificar con base a los actores.

2. Se pueden identificar con base en las descripciones de las interfaces del sistema que acompañan al
modelo de requisitos.
3. Se pueden identificar con base en las descripciones de los casos de uso y extraer la funcionalidad
específica a los objetos bordes.
Estrategia correspondiente a los actores.

Cada actor necesita su propia clase borde para comunicarse con el sistema. En muchos casos un actor
puede necesitar de varios objetos borde. Es evidente que los objetos borde no son totalmente
independientes de cada uno, ya que, en ciertos casos deben saber la existencia de los demás.
Entidad
Se utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo
plazo. La información a corto plazo existe durante la ejecución de un caso de uso, mientras que la
información a largo plazo trasciende los casos de uso, por lo que es necesario guardarla en alguna base
de datos o archivos.
Durante la identificación de objeto entidad, se encontrará que objetos que objetos similares aparecen en
varios casos de uso.
Clases entidad:
Validar Usuario: Este casi de uso requiere validar información exclusivamente guardada en el registro de
usuario, lo que se hace en la clase entidad Registro Usuario, utiliza también por el caso de uso Registro
Usuario.
Ofrecer Servicios: Este caso de uso administra las opciones de servicio y no requiere de ninguna clase
entidad.
Registrar Usuario: Este caso de uso requiere guardar información exclusivamente acerca del usuario, lo
que se hace en la clase entidad Registro Usuario.
Registrar Tarjeta: Este caso de uso requiere guardar información exclusivamente acerca de la tarjeta del
usuario lo que hace en la clase entidad Registro Tarjeta.
Consultar Información: Este casi de uso requiere de toda la información relacionada con consultas. Se
puede tomar las clases del dominio del problema y quitar aquellas relacionadas con registros y
reservaciones.
Hacer reservación: Este caso de uso requiere de la información relacionada con reservaciones. Se
pueden tomar las clases del dominio del problema y quitar aquellas relacionadas con registros.
Pagar Reservación: Este caso de uso requiere de la información relacionada con reservaciones. Dado
que es una extensión al caso de uso Hacer Reservación, no es necesario volver a repetir todas las clases
entidad, sino más bien especificar cualquier clase adicional.
Control
En la mayoría de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a
ninguno de los otros dos tipos de objetos ya vistos. Una posibilidad es repartir el comportamiento entre
los dos tipos de objetos, pero la solución no es buena si se considera el aspecto de extensibilidad. Un
cambio en el comportamiento podría afectar varios objetos, dificultando su modificación. Para evitar
estos problemas, tal comportamiento se asigna a objetos control.
Es difícil lograr un buen balance en la distribución del comportamiento del caso de uso entre los objetos
entidad, borde y control. Los objetos de control normalmente proveen a administración de los demás
tipos de objetos.
3.3 CLASES
Los objetos se representan y agrupan en clases que son óptimas para reutilizarse y darles
mantenimiento. Una clase define el conjunto de atributos y comportamientos compartidos por cada
objeto de la clase.
Por ejemplo, los registros de los estudiantes en la sección de un curso almacenan información similar
para cada estudiante. Se podría decir que los estudiantes constituyen una clase. Los valores podrían ser
diferentes para cada estudiante, pero el tipo de información es el mismo.
Los programadores deben definir las diversas clases en el programa que escriben. Cuando el programa
corre, los objetos se pueden crear a partir de la clase establecida. El término instanciar se usa cuando un
objeto se crea a partir de una clase.
Por ejemplo, un programa podría instanciar a un estudiante llamado Peter Wellington como un objeto de
la clase denominada estudiante.
Lo que hace a la programación orientada a objetos, y por consiguiente al análisis y diseño orientado a
objetos, diferente de la programación clásica, es la técnica de poner todos los atributos y métodos de un
objeto en una estructura independiente, la propia clase. Ésta es una situación común en el mundo físico.
Por ejemplo, un paquete con harina para pastel empacado es similar a una clase ya que contiene los
ingredientes y las instrucciones para mezclar y hornear el pastel.
Un suéter de lana es similar a una clase porque incluye una etiqueta con instrucciones del cuidado que
advierten que se debe lavarlo a mano y ponerlo a secar extendido. Cada clase debe tener un nombre
que la distinga de todas las demás. Los nombres de clase normalmente son sustantivos o frases cortas y
empiezan con una letra mayúscula.
En la figura 7.11 la clase se llama Renta Auto. En el UML, una clase se representa como un rectángulo. El
rectángulo contiene otras dos características importantes: una lista de atributos y una serie de métodos.
Estos elementos describen una clase, la unidad de análisis que es una parte principal de lo que llamamos
análisis y diseño orientado a objetos.
Un atributo describe alguna propiedad de todos los objetos de la clase. Observe que la clase Renta Auto
posee los atributos: tamaño, color, marca y modelo. Todos los automóviles poseen estos atributos, pero
los atributos de cada automóvil tendrán diferentes valores.
Por ejemplo, un automóvil puede ser azul, blanco o de algún otro color. Más adelante demostraremos
que es posible ser más específico acerca del rango de valores para estas propiedades. Al especificar
atributos, normalmente la primera letra es minúscula.
Un método es una acción que se puede solicitar a cualquier objeto de la clase. Los métodos son los
procesos que una clase sabe cómo realizar. Los métodos también se llaman operaciones. La clase Renta
Auto podría tener los siguientes métodos: inicio Renta ( ), entrega Auto f) y servicio ( ). Al especificar
métodos, normalmente la primera letra es minúscula.
Figura 7.11 Un ejemplo de una clase de UML, la cual se describe como un rectángulo que consiste en el nombre de la clase,
sus atributos y métodos.
3.4 DIAGRAMAS DE SECUENCIAS
El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos
en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de
caso 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 pasados entre los objetos.
Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios
para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una
secuencia de varios pasos, entonces puedes "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 vectores horizontales. 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.
Figura 5: Diagrama de Secuencia para un escenario
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 case instanciada por el objeto en la recepción final del mensaje.
3.5 DICCIONARIO DE CLASES SEGUN MODULOS

Esta es la última etapa del modelo de análisis, en esta etapa se actualiza el diccionario de clases según
módulos, originalmente descrito en el dominio del problema, aunque no es necesario ordenarlos por
relevancia, a cada clase y caso de uso se le pueden asignar módulos adicionales, que estos a su vez
pueden tener otros módulos o paquetes principales de importancia, estos ayudan a analizar de una
mejor manera.
Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los
elementos y actividades del sistema.
Si se examina una muestra de diagramas de flujo de datos para el procesamiento de pedidos, es

probable que se tengan pocas dificultades para comprender qué datos representan a la factura y al
cheque.
Los dos son términos comunes en el mundo de los negocios y muchas personas conocen su significado.
Los diccionarios de datos registran detalles adicionales relacionados con el flujo de datos en el sistema
de tal forma que todas las personas participantes puedan localizar con rapidez la descripción de flujos de
datos, almacenes de datos o procesos.
3.6 HERRAMIENTA CASE PARA EL ANÁLISIS
1. Borland Caliber Analyst

Se trata de un producto que está compuesto por dos aplicaciones desarrolladas por la compañía
Borland.
Por un lado, está el Caliber DefineIT (la última de las herramientas en cuanto a fecha de lanzamiento)
que permite definir los requisitos del sistema así como capturar los diferentes escenarios de negocio a
través de diferentes herramientas visuales; es necesario señalar que este software es compatible con
gran número de herramientas existentes en el mercado.
Por el otro está Caliber RM que nos permite gestionar dichos requisitos durante el ciclo de vida del
producto, si bien no ayudaba al usuario a visualizar los requerimientos y por lo tanto no resultaba tan
efectiva como ellos demandaban.
El paquete que incluye ambas aplicaciones nos permitirá realizar las siguientes tareas: representar y
especificar los escenarios de manera visual, permitiendo el uso de un lenguaje común; generar
diagramas de casos de pruebas y UML, mejorando tanto la velocidad como la exactitud de la definición
de los requisitos; rastrear los requisitos software durante el ciclo de vida del proyecto, respondiendo de
manera rápida a cualquier cambio que se produzca.
La compañía Seilevel Inc., una de las más fuertes en cuanto a los servicios relacionados con los requisitos
del software, ha seleccionado esta herramienta como la mejor de este tipo. Según palabras de un
directivo de la compañía ven características únicas en esta herramienta, así como una experiencia de
usuario excelente y una oportunidad para mejorar el trabajo de sus clientes en cuanto al análisis y
gestión de requisitos se refiere.
2. CASE Spec
Esta herramienta está desarrollada por la empresa Goda Software, siendo esta una aplicación comercial
de uso exclusivo para el sistema operativo Windows. Las principales características que avalan a esta
herramienta son las siguientes:
Especificación: posibilidad de realizar las especificaciones tanto con las técnicas tradicionales como con
los diagramas de casos de uso. Además, nos permite crear diagramas UML y de flujo de datos.
Seguimiento de los requisitos: a través del uso combinado de un procesador de textos y una hoja de
cálculo, el usuario será capaz de realizar el seguimiento de los requisitos, así como hacer un informe
acerca de los mismos.
Capacidad de rastreo: mediante la existencia de una matriz se representan de manera sencilla las
diferentes relaciones existentes entre los requisitos definidos y otra serie de elementos incidentes en el
proyecto.
Capacidad de importar y exportar archivos.
Generación automática de la documentación del proyecto, así como posibilidad de realizar amplios
informes.
3. IRQA 4
Herramienta desarrollada por Visure y que tiene la meta de servir como aplicación para proporcionar un
soporte integral en la ingeniería de requisitos de un proyecto de informática.
A parte de incluir las tareas más básicas de la ingeniería de requisitos (captura, análisis, modelado,
organización y seguimiento), esta aplicación dispones de las siguientes características:
Reutilización de requisitos: permite que los requisitos definidos en un proyecto puedan ser utilizados en
otros proyectos realizados por la organización, a través del uso de librerías. De esta manera se consigue
ofertar una pequeña ventaja a la hora de realizar líneas de productos.
Vista documental: esta nueva opción ofrece un agrupamiento de los requisitos que permite al usuario
observar una diferenciación clara entre los mismos, así como facilitar toda labor relacionada con estos.
Ingeniería de requisitos: además de la gestión de los requisitos, esta aplicación proporciona

funcionalidades relacionadas con la ingeniería de requisitos, lo que permite centralizar en una sola
herramienta todas las actividades relacionadas con los requisitos (incluyendo las pruebas de validación y
aceptación).
Al ser esta una herramienta integrada, se ofrece al usuario la libertad de seleccionar aquellas otras
aplicaciones más adecuadas para la realización de otras tareas relacionadas con el ciclo de vida de un
proyecto, lo que hace que no se dependa de un solo proveedor de aplicaciones.
4. Tiger Pro
Estamos ante una herramienta shareware desarrollada para facilitar al usuario la tarea de redactar los
requerimientos de un proyecto. Este aplicativo es capaz de solucionar algunos de los defectos que
aparecen a la hora de definir los requisitos de un programa. También ayuda al usuario a aclarar algunos
de los requerimientos desde el punto de vista de las pruebas a realizar, señalando aquellos
requerimientos cuya verificación pueda resultar complicada.
La herramienta, que se va actualizando con el paso del tiempo, permite exportar el trabajo realizado en
archivos bajo el formato CSV.
Los usuarios que utilicen esta herramienta podrán trabajar en los requisitos tomando como referencia
los siguientes conceptos: palabras claves relacionadas con el mismo (hasta 3 palabras para cada
requisito), criterio de aceptación del requisito, seguimiento del mismo (tanto hacia la fuente como hacia
otros lugares), prioridad del requerimiento, riesgo que trae consigo el requisito y coste del mismo.
Además, a la hora de realizar los informes correspondientes, la herramienta nos proporcionará la opción
de redactar los mismos en forma textual o bien nos presentará la información de forma gráfica.
5. GatherSpace
A la hora de realizar la definición de los requisitos para un proyecto de informática, el trabajo conjunto
de todo el equipo de desarrollo es una parte fundamental para conseguir un buen resultado. Esta
herramienta de definición y gestión de requisitos utiliza Internet como su lanzadera, ya que no es
necesario instalar ningún programa para utilizarla: bastará con crear una cuenta en el sitio web de la
misma y comenzar a definir el proyecto que se quiere desarrollar. De esta manera, la aplicación consigue
que la colaboración de todos los miembros del grupo de desarrollo sea posible de una manera mucho
más eficaz.
Las características más representativas de esta herramienta son las siguientes:
Creación de una jerarquía de requerimientos: permite crear paquetes funcionales para después
relacionarlos con componentes de más alto nivel para después permitir asociar casos de uso más
detallados y requisitos del software a dichos componentes.
Manipular varios proyectos al mismo tiempo, controlando el acceso de los usuarios para que estos
puedan ver solo alguno de los proyectos.
Posibilidad de visualizar la documentación generada a partir de los requisitos en tres formatos

diferentes: HTML, PDF y Microsoft Word.
Además de contar con todas estas opciones, la compañía ha dispuesto un buen sistema de seguridad
que protegerá los datos introducidos en la herramienta.
Para asegurar la integridad del trabajo realizado se realizan copias de seguridad diaria de la información
introducida en la herramienta y además existe la posibilidad de encriptar los datos introducidos en la
misma. También es necesario señalar que el usuario podrá descargarse la información desde el servidor
de la empresa tantas veces como le sea necesario.
6. IBM Rational RequisitePro

Esta herramienta, desarrollada por una de las compañías más importantes dentro del campo de la
informática, se considera una de las herramientas más completas y potentes dentro del análisis y la
gestión de los requisitos.
Una de las grandes ventajas que aporta este producto es la compatibilidad existente entre su software y
algunos de los programas más utilizados. Por ejemplo, esta herramienta es capaz de comunicarse de
manera muy eficiente con el Microsoft Word, de manera que la realización de los informes es más
sencilla al tiempo que se ofrece al usuario una interfaz conocida para el desarrollo de su labor.
Además de esta compatibilidad, el programa también se comunica con gran eficiencia con algunos de los
sistemas de bases de datos más utilizados en el mundo de la informática (DB2 de IBM, Microsoft SQL
Server, Microsoft Access y Oracle) de manera tal que se controla el acceso a los datos existentes en el
sistema al tiempo que se tiene un repositorio central de datos.
Por si esto no fuera suficiente, la comunicación entre la base de datos utilizada y el Microsoft Word
permite al usuario gestionar los requisitos desde la base de datos seleccionada al tiempo que estos se
mantienen dentro de su contexto en el procesador de textos.
Al igual que la herramienta estudiada anteriormente, Racional RequisitePro ofrece la posibilidad de

trabajar mediante acceso Web.
De esta manera se logra tener tanto un acceso remoto como un acceso distribuido y además no se
necesita que el software esté instalado en el cliente.
También es necesario mencionar que la herramienta dispone de una matriz de seguimiento de los
requisitos (al igual que la herramienta CASE Spec); en este caso, dicha matriz puede representarse tanto
de forma gráfica como de forma textual.
Además, en este caso se incorpora al seguimiento de los requisitos la existencia de un árbol de

seguimiento global.
7. RaQuest
Se trata de la herramienta de gestión de requisitos desarrollada por la empresa Sparx Systems,
desarrolladora también de la herramienta de análisis y modelado Enterprise Architect, utilizada en la
Escuela.
Las características principales de esta herramienta son las siguientes:
Definición y gestión de los elementos relacionados con los requisitos, entre los que se encuentran el
tipo, el estado, la dificultad del requisito, las relaciones existentes entre diferentes requisitos, etc.
Creación de paquetes para gestionar de manera más sencilla y completa los requisitos.
Generación de documentación del proyecto (tanto parcial como total) en los siguientes formatos:
HTML, CSV, Word, Excel, RTF
Además de estas características, la herramienta nos ofrece una serie de vistas diferentes, dependiendo
de la vista que queramos obtener del proyecto.
Estas vistas son: vista del tipo lista (permite ordenar los requisitos, mostrar diferentes listas, filtrar las
listas en relación a diferentes palabras y buscar en el proyecto) y vista del tipo árbol (se pueden mostrar
los árboles de proyecto y miembro, así como mostrar los árboles por el tipo y por el estado).
Elección de la Herramienta a Utilizar

Debido a la gran compatibilidad existente con el Enterprise Architect, a la variedad de formatos para
generar la documentación y a las numerosas opciones existentes en cuanto al tipo de vistas y la
definición de los elementos relacionados con los requisitos, me he decantado por utilizar la herramienta
RaQuest.
BIBLIOGRAFÍA
http://modelo-de-analisis.blogspot.mx/2013/04/31-arquitectura-de-clases.html
http://modelo-de-analisis.blogspot.mx/2013/04/32-identificacion-de-clases-segun.html
http://modelo-de-analisis.blogspot.mx/2013/04/33-clases.html
http://modelo-de-analisis.blogspot.mx/2013/04/34-diagramas-de-secuencias.html
http://modelo-de-analisis.blogspot.mx/2013/04/35-diccionario-de-clases-segun-modulos.html
http://modelo-de-analisis.blogspot.mx/2013/04/36-herramienta-case-para-el-analisis.html
UNIDAD IV MODELO DE DISEÑO
4.1 Estrategias 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 de la implementación.
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.
Un proyecto de diseño para tener un buen desarrollo debe tener una estructura en cuanto a la
organización de cómo se va a llevar a cabo. Este desarrollo se va dividiendo en etapas lo que va a
constituir la estructura. Entre esas etapas se encuentran:
Briefing, consiste en el primer contacto con el cliente para saber qué es lo que desea del proyecto, cuáles
son sus expectativas, el ‘cómo’ porqué’ ‘cuanto’. Por lo tanto, se logra conocer al cliente y sus
requerimientos y hacia dónde va dirigido o donde se quiere enfocar. Esto va a constituir un documento
escrito donde se especifique qué es lo que quiere el cliente para saber qué es, específicamente, lo que
hay que hacer. Es importante dejar claro todo para que después no haya ninguna confusión de lo que se
hizo y lo que no se hizo o lo que se dijo o no se dijo.
Tabla Gantt o diagrama Gantt, es más bien una organización de cómo se va a trabajar en el proyecto. Por
lo tanto, se van asignando tareas las cuales dependen del tiempo. Además, el tiempo debe ser pagado,
así que se definen las horas hombre, lo que dice del costo de la utilidad.
Benchmark, teniendo en cuenta lo que el cliente quiere, visto en el brief, se van analizando los otros
mercados, la competencia y se comparan. ¿Qué falta? Sin embargo, la idea no es copiarle a los otros,
sino que dependiendo del cliente, estar a la altura de los demás o sobrepasarlos, pero para eso se debe
tomar en cuenta qué recursos tienen que los hacen más populares.
Entrevista a los usuarios, principalmente, el usuario es a quien va dirigido el diseño por lo que es
necesario saber lo que él piensa y sus expectativas, críticas, opiniones más que nada.
Modelos mentales y test, además de saber lo que piensa, es necesario saber cómo piensa, cómo
estructura la información. Para eso hay varios test, donde se pone en juego distintas cosas como:
 La facilidad de encontrar las cosas, como links, información
 Que es lo primero que notan los usuarios al entrar en un sitio web
4.2 Diseño de objetos
Para los sistemas es posible definir un diseño en pirámide con las siguientes cuatro capas:
 Subsistema. Contiene una representación de cada uno de los subsistemas que le permiten al software
conseguir los requisitos definidos por el cliente e implementar la infraestructura técnica que los
soporta.
 Clases y Objetos. Contiene las jerarquías de clases que permiten crear el sistema utilizando
generalizaciones y especializaciones mejor definidas incrementalmente. También contiene
representaciones de diseño para cada objeto.
 Mensajes. Contiene los detalles que permiten a cada objeto comunicarse con sus colaboradores.
Establece las interfaces externas e internas para el sistema.
 Responsabilidades. Contiene las estructuras de datos y el diseño algorítmico para todos los atributos
y operaciones de cada objeto.
Todo el programa está construido en base a diferentes componentes (Objetos), todo objeto del mundo
real tiene 2 componentes: características y comportamiento.
Una clase es una plantilla genérica para un conjunto de objetos de similares características.
La herencia básicamente consiste en que una clase puede heredar sus variables y métodos a varias
subclases.
Por ejemplo:
Los mensajes son invocaciones a los métodos de los objetos.
Esta es una técnica de diseño, la cual se caracteriza por la determinación y delegación de

responsabilidades.
Análisis orientado a objetos
El modelo del análisis orientado a objetos ilustra información, funcionamiento y comportamiento.
El diseño orientado a objetos transforma el modelo del análisis en un modelo de diseño que sirve como
anteproyecto para la construcción de software.
Modelos del diseño
 Estáticos. Estructura de subsistemas y/o clases y sus relaciones.

 Dinámicos. Se describen las estructuras que muestran la interacción entre objetos.
Ejemplos de UML: diagramas de secuencia, diagramas de estado.

Son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos.
Son soluciones basadas en la experiencia y que se ha demostrado que funcionan.
Tipos: de creación, estructurales, de comportamiento.
4.3 Diseño de Sistemas
Diseño: El diseño es el proceso creativo de transformación del problema en una solución.
La solución será la que satisface todos los requerimientos planteados en la especificación de

requerimientos, en muchos casos son ilimitadas.
Para transformar los requerimientos en un sistema que funcione, los diseñadores deben satisfacer tanto
a los clientes como a los constructores de sistemas.
Los clientes deben comprender lo que el sistema debe hacer, y los constructores deben comprender
cómo debe operar el sistema.
El diseño es un proceso iterativo que consta de dos partes: Diseño conceptual o del sistema, Diseño
técnico.
Conceptual o del Sistema:
Se realiza primero, y le dice al cliente que es lo que hará realmente el sistema.
Una vez que se aprueba este diseño, se vuelca el trabajo a un trabajo de diseño más detallado.
El diseño conceptual describe el sistema en un lenguaje que el cliente pueda comprender, en lugar de
usar términos técnicos o jergas de computación.
Un buen diseño conceptual debería tener las siguientes características:
 Se escribe en el lenguaje del cliente.

 No contiene expresiones de jerga técnica.
 Describe claramente las funciones del sistema.
 Es independiente de la implementación.
Está vinculado con los documentos del requerimiento.
Diseño Técnico:
Permite que los constructores comprendan el hardware y el software concretos que se necesitan para
resolver el problema del cliente.
Es decir, este diseño describe:
 La configuración de hardware.
 Las necesidades de software.
 Las interfaces de comunicación.
 Las entradas y salidas del sistema.
 La arquitectura de red.
 Y cualquier otro aspecto que incida en la transformación de los requerimientos en una solución.
 El diseño se describe en un único documento, pero muchas veces se vuelca en dos.
Ejemplo de Diseño Conceptual y Técnico:
4.4 Revisión del diseño
El proceso de revisión se realiza en tres etapas en correspondencia con los pasos del proceso de diseño:
1. Revisión del diseño preliminar.

2. Revisión crítica del diseño.
3. Revisión del diseño de programas.
Revisión del diseño preliminar:
Los clientes y usuarios se reúnen para validar el diseño conceptual.

Se asegura que todos los aspectos relativos a los requerimientos han sido apropiadamente
contemplados en el diseño.
Se invita a participar a ciertas personas claves:
 Cliente (s), quien ayuda a definir los requerimientos del sistema.

 Analista (s), quien colabora para definir los requerimientos del sistema
 Usuario (s), potenciales del sistema.
 Diseñador (es) del sistema.
 Un moderador (solo coordina), un secretario (no se involucra).
 Otros desarrolladores (entregan perspectiva externa)
Durante la revisión se presenta a la audiencia el diseño conceptual. Al hacerlo, se demuestra que el

sistema tiene la estructura requerida, las funciones y las características especificadas por los
documentos de análisis.
Todos los participantes, en conjunto, verifican que el diseño propuesto incluya el hardware necesario,
interfaces con otros sistemas, entradas y salidas.
Los clientes aprueban los diálogos y menús, los formatos de los informes y el tratamiento de defectos
propuestos.
Revisión crítica del diseño:
Realiza una revisión crítica del diseño, donde se presenta una vista general del diseño técnico.
Integrantes:
 Analista (s), quien colabora para definir los requerimientos del sistema.
 Diseñador (es) de programas para este proyecto.
 Probador del sistema.
 Analista que escribirá la documentación del sistema.
 Otros desarrolladores (entregan perspectiva externa).
La revisión trata de aspectos técnicos.
El moderador conduce la reunión para que se traten dos puntos: si el diseño implementa todos los
requerimientos y si es un diseño de calidad, usando diagramas, datos o ambas cosas, se explican las
estrategias de diseño alternativa y como y porque se han tomado las principales decisiones de diseño, Si
se identifican problemas mayores el diseño se rehace.
Revisión del diseño de programas:
Cuando el diseño técnico resulta satisfactorio, los diseñadores de programas estarán en posición de
interpretarlo como el conjunto de descripciones de diseño para los componentes reales, que deben ser
codificados y probados.
Después de completar los diseños de programas, pero antes de comenzar la codificación, presentan sus
planes.
Integrantes:
 Analista (s), que produjeran los requerimientos del sistema.

 Diseñador (es) del programa.
 Diseñador (es) de programas para este proyecto.
 Probador del sistema.
 Analista que escribirá la documentación del sistema.
 Otros desarrolladores (entregan perspectiva externa).
Este proceso se centra en la detección de defectos más que en su corrección. Además se está evaluando
el diseño no a los diseñadores.
El proceso beneficia a todos al encontrar defectos y problemas cuando aún son fáciles y poco costosos
de corregir.
4.5 Diagramas de secuencia del diseño
Los casos de uso deben ser utilizados durante esta etapa, para describir el comportamiento dinámico del
sistema, cualquiera de los diagramas de interacción del UML pueden ser utilizados. Debido a que
Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de
colaboración, utilizando diagramas de secuencia.
En un diagrama de secuencia ponemos varios de los objetos o clases que forman parte de nuestro
programa y ponemos qué llamadas van haciendo unos a otros para realizar una tarea determinada.
Hacemos un diagrama de secuencia por cada caso de uso o para una parte de un caso de uso (lo que
llamo subcaso de uso). En nuestro ejemplo de ajedrez, podemos hacer diagramas de secuencia para
"jugar partida" o bien para partes de "jugar partida", como puede ser "mover pieza".
El detalle del diagrama depende de la fase en la que estemos, lo que pretendamos contar con el
diagrama y a quién. En una primera fase de diseño podemos poner clases grandes y ficticias, que
representen un paquete/librería o, si nuestro programa está compuesto por varios ejecutables corriendo
a la vez, incluso clases que representen un ejecutable.
Si estamos en una fase avanzada, estamos diseñando el programa y queremos dejar bien atados los
detalles entre dos programadores, que cada uno va a programar una de las clases que participan,
entonces debemos posiblemente ir al nivel de clase real de codificación y método, con parámetros y
todo, de forma que los programadores tengan claro que métdos van a implementar, que deben llamar
de la clase del otro, etc. Incluso si es un diagrama para presentar al cliente, podemos hacer un diagrama
de secuencia en el que sólo salga el actor "jugador" y una única clase "juego ajedrez" que representa
nuestro programa completo, de forma que el cliente vea qué datos y en qué orden los tiene que meter
en el programa y vea qué salidas y resultados le va a dar el programa.
El siguiente puede ser un diagrama de secuencia de nuestro ejemplo del ajedrez a un nivel de diseño
muy preliminar.
Aquí ya hemos decidido que vamos a hacer tres librerías/paquetes, una para la interface de usuario, otra
para contener el tablero y reglas del ajedrez (movimientos válidos y demás) y otra para el algoritmo de
juego del ordenador. Hemos puesto una clase representando cada uno de los paquetes y hemos
representado el caso de usa "mover pieza".
En el diagrama de secuencia no se ponen situaciones erróneas (movimientos inválidos, jaques, etc)
puesto que poner todos los detalles puede dar lugar a un diagrama que no se entiende o difícil de leer. El
diagrama puede acompañarse con un texto en el que se detallen todas estas situaciones erróneas y
particularidades. Si se quiere dejar muy claro que un determinado error se contempla, por ejemplo, un
movimiento no válido por el usuario, entonces sí se puede poner en el diagrama de secuencia, siempre
que no "embarulle" demasiado.
En este diagrama sencillo ya vamos dejando algunas cosas claras, como por ejemplo, que la interface de
usuario hace llamadas y, por tanto, ve a los otros dos, mientras que algoritmo sólo ve al tablero/reglas. El
tablero/reglas aparentemente ve a la interface de usuario, pero no nos interesa si seguimos un patrón
modelo-vista-controlador, así que ese "Refresca pantalla" lo implementaremos con un patrón
observador, pero eso son detalles que quizás no vienen al caso ahora
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

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 (ejemplo: 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 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.
BIBLIOGRAFÍA
http://ithuni4coronel.blogspot.mx/2013/05/41-estrategias-de-diseno.html
http://ithuni4coronel.blogspot.mx/2013/05/42-diseno-de-objetos.html
http://ithuni4coronel.blogspot.mx/2013/05/43-diseno-de-sistemas.html
http://ithuni4coronel.blogspot.mx/2013/05/44-revision-del-diseno.html
http://ithuni4coronel.blogspot.mx/2013/05/45-diagramas-de-secuencia-del-diseno.html
http://ithuni4coronel.blogspot.mx/2013/05/46-herramientas-case-para-el-diseño.html
UNIDAD V MODELO DE IMPLEMENTACIÓN
El Modelo de Implementación es comprendido por un conjunto de componentes y subsistemas que

constituyen la composición física de la implementación del sistema. Entre los componentes podemos
encontrar datos, archivos, ejecutables, código fuente y los directorios. Fundamentalmente, se describe la
relación que existe desde los paquetes y clases del modelo de diseño a subsistemas y componentes
físicos.
Un diagrama de implementación muestra:

 Las dependencias entre las partes de código del sistema (diagramas de componentes).
 La estructura del sistema en ejecución (diagrama de despliegue).
5.1 DIAGRAMAS DE COMPONENTES
Un componente es una parte física de un sistema (modulo, base de datos, programa ejecutable, etc.). Se
puede decir que un componente es la materialización de una o más clases, porque una abstracción con
atributos y métodos pueden ser implementados en los componentes.
Respecto a los componentes…

 Es implementado por una o más clases/objetos del sistema.
 Es una unidad autónoma que provee una o más interfaces.
 Las interfaces representan un contrato de servicios que el componente ofrece.
Los componentes pueden ser:

 Archivos
 Código fuente + Cabeceras
 Librerías compartidas (DLLs)
 Ejecutables
 Paquetes
Muestra como el sistema está dividido en componentes y las dependencias entre ellos.
 Proveen una vista arquitectónica de alto nivel del sistema.
 Ayuda a los desarrolladores a visualizar el camino de la implementación.
 Permite tomar decisiones respecto a las tareas de implementación y los Skills requeridos.
En un DC, un componente se representa con un rectángulo en el que se escribe su nombre y en él se
muestran dos pequeños rectángulos al lado izquierdo. O también los siguientes:
Representación simple de un Componente
Elementos del Diagrama de Componentes
Normalmente los diagramas de Componentes contienen:

 Componentes
 Interfaces
 Relaciones de dependencia, generalización, asociación y realización
 Paquetes o subsistemas
Los componentes se pueden agrupar en paquetes, así como los objetos en clases, además puede haber
entre ellos relaciones de dependencia como:
 Generalización
 Asociación
 Agregación
 Realización
Estereotipos de componentes
UML define cinco estereotipos estándar que se aplican en los componentes
 Executable, componente que se puede ejecutar
 Library, biblioteca de objetos estática o dinámica
 Table, Componentes que representa una tabla de base de datos
 File, componente que representa un documento que contiene código fuente o datos.
 Document, Comp. Que representa un documento.
¿Por qué utilizar un Diagrama de Componentes?

 Nos permite ver el modelado de un sistema o subsistema.
 Permite especificar un componente con interfaces bien definidas.
5.2 DIAGRAMAS DE DESPLIEGUE
El Diagrama de Despliegue es un diagrama que se utiliza para modelar el hardware utilizado en las
implementaciones de sistemas y las relaciones entre sus componentes.
 Permiten modelar la disposición física o topología de un sistema.
 Muestra el hardware usado y los componentes instalados en el hardware.
 Muestra las conexiones físicas entre el hardware y las relaciones entre componentes.
Usos que se les da a los diagramas de despliegue son para modelar:

 Sistemas cliente-servidor
 Sistemas completamente distribuidos
El elemento principal del diagrama son los NODOS.

Los nodos representan un recurso físico:
 Computadoras
 Sensores
 Impresoras
 Servidores
 Dispositivos externos
Los nodos pueden ser interconectados mediante líneas para describir una estructura de red.
Un nodo es un objeto físico en tiempo de ejecución que representa un recurso computacional,
generalmente con memoria y capacidad de procesamiento.
Estereotipo de nodo
 Estereotipo, son cosas u objetos q se repiten sin variación.
 El estereotipo de un nodo es la manera de poder verificar que tipo de nodo es el que se está
observando.
Ejemplo Grafico
Se muestra número de estereotipos estándar, nombrados «cdrom»,«disk array», «pc client», «unix
server». etc. Estos mostrarán un icono apropiado en la esquina derecha arriba del símbolo nodo.
Artefactos
Un artefacto es un producto del proceso de desarrollo de software, que puede incluir los modelos del
proceso (modelos de Casos de Uso, modelos de Diseño, etc.), archivos fuente, ejecutables, documentos
de diseño, reportes de prueba, prototipos, manuales de usuario etc.
Donde un artefacto es un conjunto de componentes.
Ejemplo Grafico
Un artefacto se denota por un rectángulo mostrando el nombre del artefacto, el estereotipo «artifact» y
un icono de documento, como a continuación.
5.3 MODELOS DE PRUEBA
Objetivos de las pruebas

 Encontrar defectos en el software
 Una prueba tiene éxito si descubre un defecto
 Una prueba fracasa si hay defectos, pero no los descubre
 Pruebas de Verificación
Ver si cumple las especificaciones de diseño
 Pruebas de Validación
Ver si cumple los requisitos del análisis.
El proceso de pruebas del software tiene dos objetivos:

1. Demostrar al desarrollador y al cliente que el software satisface sus requerimientos.
2. Descubrir defectos en el software: que su comportamiento es incorrecto, no deseable o no cumple
su especificación.
Pruebas de “caja blanca”

Pruebas en que se conoce el código a probar
Caja blanca (clear box: caja clara o transparente)
Se procura ejercitar cada elemento del código
Algunas clases de pruebas
Pruebas de cubrimiento
Pruebas de condiciones
Pruebas de bucles
Pruebas de “caja negra”

Pruebas en que se conoce sólo la interfaz
Caja negra (black box: caja opaca)
Se procura ejercitar cada elemento de la interfaz
Algunas clases de pruebas
Cubrimiento  invocar todas las funciones (100%)
Clases de equivalencia de datos
Pruebas de valores límite
Estrategias de prueba del software

 Pruebas de unidades
 Pruebas de integración
 Pruebas de regresión
 Pruebas de validación
Pruebas de unidades:
 Se concentra en el esfuerzo de verificación de la unidad más pequeña del diseño del software:
el componente o módulo del software.
 Las pruebas de unidad se concentran en la lógica del procesamiento interno.
 Este tipo de prueba se puede aplicar en paralelo a varios componentes.
Pruebas de integración:
 La prueba de integración es una técnica sistemática para construir la arquitectura del software,
mientras, al mismo tiempo, se aplican las pruebas para descubrir errores asociados con la
interfaz.
 El objetivo es tomar componentes a los que se aplicó una prueba de unidad y construir una
estructura de programa que determine el diseño.
Pruebas de regresión:
 La prueba de integración es una técnica sistemática para construir la arquitectura del software,
mientras, al mismo tiempo, se aplican las pruebas para descubrir errores asociados con la
interfaz.
 El objetivo es tomar componentes a los que se aplicó una prueba de unidad y construir una
estructura de programa que determine el diseño.
Pruebas de validación:
 Las pruebas de validación empiezan tras la culminación de la prueba de integración, cuando se
han ejercitado los componentes individuales. Se ha terminado de ensamblar el software como
paquete y se han descubierto y corregido los errores de interfaz.
 La prueba se concentra en las acciones visibles para el usuario y en la salida del sistema que
éste puede reconocer.
BIBLIOGRAFÍA
http://es.scribd.com/doc/7884665/Arquitectura-de-Software-II-Diagrama-de-Componentes-y-Despliegue
http://www.slideshare.net/techmi/curso-uml-25-diagramas-de-implementacion
http://ithleovi.blogspot.mx/2013/06/unidad-5-modelo-deimplementacion-el.html

3 Fundamentos de Ing. de Sw.

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

3 Fundamentos de Ing. de Sw.

Caricato da

Copyright:

Formati disponibili

FUNDAMENTOS

UNIDAD I FUNDAMENTOS DE INGENIERÍA DE SOFTWARE

1.1 CONCEPTOS BÁSICOS

La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas y

Los Ingenieros de Software deben:

• Adoptar un enfoque sistemático para llevar a cabo su trabajo.

1.2 EL PAPEL EVOLUTIVO DEL SOFTWARE

PRIMERA ERA (1950 – 1965)

SEGUNDA ERA (1965 – 1972)

TERCERA ERA (1972 – 1985)

CUARTA ERA (1985 - 1995)

QUINTA ERA (2000 hasta hoy en día)

1.3 ETAPAS DEL DESARROLLO DEL SOFTWARE

Se recomienda aplicar las etapas:

Etapa de Implementación o Entrega Implantación: Consiste en poner a disposición del cliente el

1.4 CLASIFICACIÓN DE LA TECNOLOGÍA EN EL DESARROLLO DE SOFTWARE (TECNOLOGÍA

Tecnologías de desarrollo estructurado

Tecnologías orientadas a objetos

1.5 DEFINICIÓN E HISTORIA DE LAS HERRAMIENTAS CASE

¿Qué son las Herramientas CASE?

CASE se define también como:

Historia de las Herramientas CASE

1.6 CLASIFICACIÓN DE LAS HERRAMIENTAS CASE

UNIDAD II INGENIERÍA DE REQUISITOS

En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos o Ingeniería de

Es importante no perder de vista que un requerimiento debe ser:

 Posible de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo se sabe

 Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si

 Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

 No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje

2.1 TAREAS DE LA INGENIERÍA DE REQUISITOS

2.2 TÉCNICAS DE LA INGENIERÍA DE REQUISITOS

Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o de

Durante la actividad de extracción de requerimientos, puede ocurrir que algunos requerimientos no

El desarrollo del prototipo comienza con la captura de requerimientos. Desarrolladores y clientes se

2.3 MODELADO DE REQUISITOS

El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de

 Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de

2.4 HERRAMIENTAS CASE PARA LA INGENIERÍA DE REQUISITOS

planeamiento de liberaciones, administración de implementaciones, control de dependencia entre

OSRMT (Open Source Requirements Management Tool)

UNIDAD III MODELO DE ANÁLISIS

En término de las propias arquitecturas, éstas se distinguen según la organización de la funcionalidad

Figura 7.2 Diagrama de tres dimensiones correspondiente a la arquitectura

Figura 7.3 Diagrama de tres dimensiones correspondiente a la arquitectura

Clases con Estereotipos

La notación de UML para un estereotipo se muestra en la Figura 7.4.

<< estereotipo >>

Figura 7.4 Diagrama de clase con estereotipo.

Figura 7.5 Diagrama de clase para los tres estereotipos.

Figura 7.6 Diagrama mostrando traslape en los estereotipos

Figura 7.7 La funcionalidad de cada caso de uso es asignada a

Se parte el caso de uso de acuerdo a los siguientes principios:

Figura 7.8 Caso de uso imprimir archivo.

Figura 7.9 Objetos identificados para el caso de uso imprimir archivo.

3.2 IDENTIFICACIÓN DE CLASES SEGÚN ESTEREOTIPOS

1. Se pueden identificar con base a los actores.

Estrategia correspondiente a los actores.

3.4 DIAGRAMAS DE SECUENCIAS

Figura 5: Diagrama de Secuencia para un escenario

Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la

3.5 DICCIONARIO DE CLASES SEGUN MODULOS

Si se examina una muestra de diagramas de flujo de datos para el procesamiento de pedidos, es

3.6 HERRAMIENTA CASE PARA EL ANÁLISIS