INSTITUTO TECNOLÓGICO DE HUEJUTLA
CLAVE: 13DIT0001E
CARRERA:
INGENIERÍA
EN SISTEMAS COMPUTACIONALES
NOMBRE DE LA MATERIA:
FUNDAMENTOS DE INGENIERÍA DE SOFTWARE
UNIDAD DE ESTUDIO:
UNIDAD 1 FUNDAMENTOS DE INGENIERÍA DE SOFTWARE
UNIDAD II INGENIERÍA DE REQUISITOS
UNIDAD III MODELOS DE ANÁLISIS
UNIDAD IV MODELO DE DISEÑO
UNIDAD V MODELOS DE IMPLEMENTACIÓN
NOMBRE DEL ALUMNO:
AMBROSIO
ANTONIO MARTÍNEZ
SEMESTRE: V GRUPO: “A”
NOMBRE DEL DOCENTE:
MARÍA
GUADALUPE RIVERA GARCÍA
FECHA DE ENTREGA:
MIÉRCOLES, 03 DE DICIEMBRE DEL 2014
UNIDAD 1 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
A cada uno de los ejercicios de este curso.
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 [12].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?
v
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.
v
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.
v
Consistente: Un requerimiento es consistente si no es contradictorio con
otro requerimiento.
v
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 estereotipo.
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 caso de uso, por lo que es necesario guardarla en alguna base de datos o archivos.
Durante la identificación de objeto entidad, se encontrara 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 18.1 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 rná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.
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.
Esta es la ultima 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.
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.
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
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) del sistema.
• Un moderador (solo coordina), un
secretario (no se involucra).
• 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 sistema.
• Diseñador (es) del programa.
• Un moderador (solo coordina), un
secretario (no se involucra).
• 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 pueden 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
1 comentarios:
Betway Casino in Sarnathuram - Mapyro
The casino is situated in the city of Avadhavagri and 오산 출장안마 is close to Haridra in the district of 안산 출장안마 Narvangam. It is located 서울특별 출장마사지 on the middle of 충청북도 출장마사지 the state 여수 출장마사지 Ganesha Mandir and
Publicar un comentario
Suscribirse a Enviar comentarios [Atom]
<< Inicio