FUNDAMENTOS DE INGENIERIA DE SOFTWARE

INSTITUTO TECNOLOGICO DEL

FUNDAMENTOS DE INGENIERIA DE SOFTWARE

WILFRIDO LOPEZ LOPEZALUMNO:

PROFESOR:MARIO NUÑEZ CORDOBA

INSTITUTO TECNOLOGICO DEL


1


FUNDAMENTOS DE INGENIERIA DE SOFTWARE1.- UNIDAD : Fundamentos ingeniería de software(ANEXO)………………………...…..........................2

2.- UNIDAD: INGENIERÍA DE REQUISITOS............................................................................................9

¿Para qué un Proceso de Ingeniería de Requerimientos?...................................................9

Ingeniería de Requerimientos....................................................................................................10

Importancia de los requerimientos..........................................................................................10

División de los Requerimientos................................................................................................10

Características de los Requerimientos...................................................................................11

Dificultades para definir los requerimientos..........................................................................11

Importancia de la Ingeniería de Requerimientos..................................................................12

2.1.- Tareas de la ingeniería de requisitos........................................................................................12

2.2.- Técnicas de la ingeniería de requisitos...................................................................................14

2.3.- Modelado de requisitos................................................................................................................16

2.4.- Herramientas case para la ingeniería de requisitos..............................................................17

3.- UNIDAD: MODELO DE ANALISIS......................................................................................................20

3.1.- Arquitectura de clase..................................................................................................................20

3.2.- Identificación de clases según estereotipos.........................................................................26

3.3.- Clases.............................................................................................................................................29

3.4 - Diagrama de secuencia...............................................................................................................31

3.5.- Diccionario de clases según módulos....................................................................................32

3.6.- Herramientas case para el análisis..........................................................................................33

4.- UNIDAD: MODELO DE DISEÑO.........................................................................................................35

4.1.- Estrategias de diseño..................................................................................................................37

4.2.- Diseño de objetos........................................................................................................................41

4.3.- Diseño de sistemas......................................................................................................................42

4.4.- Revisión del diseño.....................................................................................................................44

4.5.- Diagramas de secuencia............................................................................................................46

4.6.- Herramientas case para el diseño............................................................................................49

5.- UNIDAD: MODELO DE IMPLEMENTACIÓN....................................................................................51

5.1 Diagramas de componentes........................................................................................................52

5.2.- Diagramas de despliegue...........................................................................................................55

5.3.- Modelos de prueba......................................................................................................................57

BIBLIOGRAFIA………………………………………………………………………………………………………………………………………….… 53

2


Unidad I: Fundamentos de Ingeniería de Software

1.1. Conceptos básicos

a) Ingeniería

• Es la profesión en la que el conocimiento de las ciencias naturales y matemáticas obtenidas con el estudio, la práctica y la experiencia se aplica con juicio para desarrollar formas de utilizar de modo económico, los materiales y fuerzas de la naturaleza para beneficio de la humanidad

b) Software

• Es el conjunto de todos los programas que existen dentro de una computadora.

• Es el producto del desarrollo que realizan los ingenieros de software resultado de requerimientos de información) La Ingeniería de Software• Es una disciplina de la Ingeniería que comprende todos los aspectos de la producción del software desde las etapas iníciales de la especificación del sistema hasta el mantenimiento de éste después de que se libera.

La Ingeniería de Software incluye:

• Personas (quién lo hace)

·Proceso (la manera en que se hace)

·Proyecto (la realización)

·Producto (la aplicación de artefactos)

1.2. El papel evolutivo del software

El término fue introducido a fines del 60 y comienzo del 70, tras la crisis del software que se caracterizó por:

• Imprecisión en la planificación del proyecto y estimación de los costos.

• Baja calidad del Software.

• Dificultad de mantenimiento de programas con un diseño poco estructurado, etc.

En las décadas de 1980 y 1990 dos tendencias dominaron la ingeniería de software:

3


• El florecimiento explosivo de aplicaciones, incluyendo las de Internet.

• El Nacimiento de nuevas herramientas y paradigmas (formas de pensamiento, como la orientación a objetos).

Mitos del Software

Mitos: Son las creencias acerca del software y los procesos empleados para realizarlo.

·Mitos de la Administración

·Mitos del Cliente

·Mitos del Desarrollador

1.3. Etapas del desarrollo software

1) Investigación preliminar:

• Parte de una solicitud de requerimiento de un sistema de información, tiene tres partes:

a) Aclaración de la Solicitud

b) Estudio de Factibilidad: Técnica, Económica, Operacional

c) Aprobación de la Solicitud

2) Análisis de requerimientos:

Comprender todas las facetas importantes de la parte de la empresa bajo estudio:

a) ¿Qué es lo que hace?

b) ¿Cómo se hace?

c) ¿Con qué frecuencia se presenta?

d) Volumen de transacciones o decisiones

e) Grado de eficiencia de las tareas

f) ¿Existe algún problema?

4


g) ¿Qué tan serio y causa que lo origina?

3. Diseño del sistema: • Plasma en un modelo los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis

4. Desarrollo de Software:

• Se puede instalar software comprado (software genérico) o escribir programas diseñados a la medida del solicitante (software personalizado)

• La elección depende del costo, tiempo y disponibilidad de programadores.

5. Pruebas:

• En esta fase, el sistema se emplea de manera experimental para asegurarse que el software no tenga fallas, es decir, que funcione de acuerdo a las especificaciones del usuario y en la forma en que los usuarios esperan que lo haga.

6. Implementación:

Es el proceso de: Verificar e Instalar nuevo equipo, capacitar a usuarios, instalar la aplicación y dejar “montada” toda la infraestructura para su aplicación.

1.4. Clasificación de la tecnología en el desarrollo de software (Tecnología

Estructurada y Orientada a Objetos)

Tecnología estructurada

Programación Estructurada es una técnica en la cual la estructura de un programa, esto es, la interpelación de sus partes realiza tan claramente cómo es posible mediante el uso de tres estructuras lógicas de control:

·Secuencia: Sucesión simple de dos o más operaciones.

·Selección: bifurcación condicional de una o más operaciones.

·Interacción: Repetición de una operación mientras se cumple una condición.

Estos tres tipos de estructuras lógicas de control pueden ser combinados para producir programas que manejen cualquier tarea de procesamiento de información.

5


Un programa estructurado está compuesto de segmentos, los cuales puedan estar constituidos por unas pocas instrucciones o por una página o más de codificación.

Cada segmento tiene solamente una entrada y una salida, estos segmentos, asumiendo que no poseen lazos infinitos y no tienen instrucciones que jamás se ejecuten, se denominan programas propios. Cuando varios programas propios se combinan utilizando las tres estructuras básicas de control mencionadas anteriormente, el resultado es también un programa propio.

La programación Estructurada está basada en el Teorema de la Estructura, el cual establece que cualquier programa propio (un programa con una entrada y una salida exclusivamente) es equivalente a un programa que contiene solamente las estructuras lógicas mencionadas anteriormente.

Una característica importante en un programa estructurado es que puede ser leído en secuencia, desde el comienzo hasta el final sin perder la continuidad de la tarea que cumple el programa, lo contrario de lo que ocurre con otros estilos de programación. Esto es importante debido a que, es mucho más fácil comprender completamente el trabajo que realiza una función determinada, si todas las instrucciones que influyen en su acción están físicamente contiguas y encerradas por un bloque. La facilidad de lectura, de comienzo a fin, es una consecuencia de utilizar solamente tres estructuras de control y de eliminar la instrucción de desvío de flujo de control, excepto en circunstancias muy especiales tales como la simulación de una estructura lógica de control en un lenguaje de programación que no la posea.

VENTAJAS POTENCIALES

Un programa escrito de acuerdo a estos principios no solamente tendrá una estructura, sino también una excelente presentación.

Un programa escrito de esta forma tiende a ser mucho más fácil de comprender que programas escritos en otros estilos.

La facilidad de comprensión del contenido de un programa puede facilitar el chequeo de la codificación y reducir el tiempo de prueba y depuración de programas. Esto último es cierto parcialmente, debido a que la programación estructurada concentra los errores en uno de los factores más generador de fallas en programación: la lógica.

Un programa que es fácil para leer y el cual esta compuesto de segmentos bien definidos tiende a ser simple, rápido y menos expuesto a mantenimiento. Estos beneficios derivan en parte del hecho que, aunque el programa tenga una extensión significativa, en documentación tiende siempre a estar al día, esto no suele suceder con los métodos convencionales de programación.

6


La programación estructurada ofrece estos beneficios, pero no se la debe considerar como una panacea ya que el desarrollo de programas es, principalmente, una tarea de dedicación, esfuerzo y creatividad.

Tecnología Orientada a Objetos

Lenguajes de Programación Orientado a Objetos

En 1985, E. Stroustrup extendió el lenguaje de programación C a C++, es decir C con conceptos de clases y objetos, también por esas fechas se creó desde sus bases el lenguaje EIFFEL.

En 1995 apareció el más reciente lenguaje OO, Java desarrollado por SUN, que hereda conceptos de C++.

El lenguaje de desarrollo más extendido para aplicaciones Web, el PHP 5, trae todas las características necesarias para desarrollar software orientado a objetos.

Además de otros lenguajes que fueron evolucionando, como el Pascal a Delphi.

Finalmente también otros lenguajes script como el ActionScript que si bien no es totalmente orientado a objetos pero sí posee las características.

La programación orientada a objetos es una de las formas más populares de programar y viene teniendo gran acogida en el desarrollo de proyectos de software desde los últimos años. Esta acogida se debe a sus grandes capacidades y ventajas frente a las antiguas formas de programar.

Hoy en día la tecnología orientada a objetos ya no se aplica solamente a los lenguajes de programación, además se viene aplicando en el análisis y diseño con mucho éxito, al igual que en las bases de datos. Es que para hacer una buena programación orientada a objetos hay que desarrollar todo el sistema aplicando esta tecnología, de ahí la importancia del análisis y el diseño orientado a objetos.

Ventajas:

· Fomenta la reutilización y extensión del código.

· Permite crear sistemas más complejos.

· Relacionar el sistema al mundo real.

· Facilita la creación de programas visuales.

· Construcción de prototipos

7


· Agiliza el desarrollo de software

· Facilita el trabajo en equipo

· Facilita el mantenimiento del software

Lo interesante de la POO es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible.

El modelo Orientado a Objetos

· Objetos

· Clases

· Herencia

· Envío de mensajes

1.5. Definición e historia de las herramientas CASE

Las [[herramientas CASE]] (Computer Aided Software Engineering, Ingeniería de

Software Asistida por Ordenador) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero.

Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costes, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.

Es un sistema de software que intenta proporcionar ayuda automatizada a las actividades del proceso de software. Los sistemas CASE a menudo se utilizan como apoyo al método. La primera herramienta CASE como hoy la conocemos fue Exceleratoren 1984 , era para PC . Actualmente la oferta de herramientas

CASE es muy amplia y tenemos por ejemplo el EASYCASE o WINPROJECT .

1.6. Clasificación de las herramientas CASE

Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas

CASE se pueden clasificar teniendo en cuenta los siguientes parámetros:

8


1. Las plataformas que soportan.

2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.

3. La arquitectura de las aplicaciones que producen.

4. Su funcionalidad.

La clasificación basada en las fases del ciclo de desarrollo cubre:

Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación, análisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.

Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la aplicación.

Lower CASE (L-CASE), herramientas que semi-automatizan la generación de código, crean programas de detección de errores, soportan la depuración de programas y pruebas. Además automatizan la documentación completa de la aplicación. Aquí pueden incluirse las herramientas de Desarrollo rápido de aplicaciones.

Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificación excluyente entre sí, ni con la anterior:

· Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde análisis hasta implementación.

· MetaCASE, herramientas que permiten la definición de nuestra propia técnica de modelado, los elementos permitidos de la meta modelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiéramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles.

CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software.

IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestión de proyectos y gestión de la configuración.

Por funcionalidad podríamos diferenciar algunas como:

· Herramientas de generación semiautomática de código.

9


· Editores UML.

· Herramientas de Refactorización de código.

· Herramientas de mantenimiento como los sistemas de control de versiones.

2.- INGENIERÍA DE REQUISITOS.

Definición: “Ingeniería de Requerimientos es el proceso por el cual se transforman los

requerimientos declarados por los clientes, ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones”.

La Ingeniería de Requerimientos, se utiliza para definir todas las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos para un producto determinado. El uso del término "ingeniería" implica que se deben utilizar técnicas sistemáticas y repetibles para asegurar que los requerimientos del sistema estén completos y sean consistentes y relevantes.

Normalmente, un tema de la Ingeniería de Software tiene diferentes significados.

De las muchas definiciones que existen para requerimiento, a continuación se presenta la definición que aparece en el glosario de la IEEE.

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.

Una representación documentada de una condición o capacidad como en los puntos anteriores (1) o (2).

¿Para qué un Proceso de Ingeniería de Requerimientos? El Proceso de Ingeniería de Requerimientos es un conjunto estructurado de actividades, mediante las cuales obtenemos, validamos y mantenemos el documento de especificación de requerimientos.

Las actividades del proceso incluyen la extracción de requerimientos, el análisis, la negociación y la validación.

No existe un proceso único que sea válido de aplicar en todas las organizaciones.

10


Cada organización debe desarrollar su propio proceso de acuerdo al tipo de producto que se esté desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad de las personas involucradas en la ingeniería de requerimientos.

Ingeniería de Requerimientos

El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema llamado Ingeniería de Requerimientos.

i. La meta de la Ingeniería de Requerimientos es entregar una especificación de requisitos de software correcta y completa.

Importancia de los requerimientos

“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 requerimientos técnicos detallados, incluyendo todas las interfaces con gente, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema l. 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." Los requerimientos se deben descubrir antes de empezar a construir un producto, y que puede ser algo que el producto debe hacer o una cualidad que el producto debe tener. Un requerimiento existe ya sea porque el tipo de producto demanda ciertas funciones o cualidades, o porque el cliente quiere que ese requerimiento sea parte del producto final. Así que si no se tienen los requerimientos correctos, no se puede diseñar o construir el producto correcto y, consecuentemente, el producto no permitirá a los usuarios finales realizar su trabajo.

División de los Requerimientos. Los requerimientos se pueden dividir en funcionales y no funcionales, a continuación se definen:

Los requerimientos funcionales Definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas, especifican los servicios que debe proporcionar la aplicación (por ejemplo, “la aplicación debe calcular el valor del portafolio de inversión del usuario”).

Los requerimientos no funcionales

11


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 (robuste 2 del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, es el cómo, cuándo y cuánto del qué.

Características de los Requerimientos.

Las características de los requerimientos son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de atributos tanto individualmente como en grupo.

Características más importantes:

Necesario: Si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

Conciso: Si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlos en un futuro.

Completo: Si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.

Consistente: Si no es contradictorio con otro requerimiento.

No ambiguo: Cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.

Dificultades para definir los requerimientos.

Los requerimientos no son obvios y vienen de muchas fuentes. Son difíciles de expresar en palabras (el lenguaje es ambiguo) Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difícil de manejar. Nunca son iguales. Algunos son más difíciles, más riesgosos, más

importantes o más estables que otros. Los requerimientos están relacionados unos con otros, y a su vez se

relacionan con otras partes del proceso. Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales

específicas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

12


Importancia de la Ingeniería de Requerimientos.

Los principales beneficios que se obtienen de la Ingeniería de Requerimientos son:

Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y

bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, así como

sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.

Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro.

Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc...

Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores, si este consenso no ocurre, el proyecto no será exitoso.

2.1.- TAREAS DE LA INGENIERÍA DE REQUISITOS

Se define como un conjunto de actividades en los cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución. La ingeniería de requisitos es el proceso de desarrollar una especificación de software.

Inicio:

Tiene por objetivo identificar el ámbito del proyecto general. Comienza con una serie de conversaciones informales entre los participantes del mismo. Esta fase suele ser acompañada de los documentos de definición de la visión global y la visión del dominio del sistema. Se inicia muchas veces por: se descubre un nuevo mercado y se descubre un nuevo servicio.

Obtención:

13


Se sugiere a los ingenieros recopilar requisitos de manera organizada, preguntando a los usuarios y otros interesados cuales son os objetivos para el sistema o producto, que es lo que se debe lograr, de que forma el producto satisface las necesidades del negocio y como se utilizara el producto día d día. Se identifican una serie de problemas que ayudan a entender porque es difícil la obtención de requisitos:

Problema de ámbitoProblema de comprensiónProblemas de volatilidad

Elaboración:

Se crea un modelo de análisis con la información obtenida del cliente en las fases de inicio y obtención. La información conseguida con el cliente durante el inicio y obtención se expande y se refina durante la elaboración. Esta actividad se enfoca en el desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software. La elaboración se conduce mediante la creación y refinamiento de escenarios del usuario que describan la forma en que el usuario final y otros actores interactúan con el sistema.

Negociación:

En esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y límites del sistema. De forma iterativa los requisitos se prioriza, modifican, combinan o eliminan buscando acuerdos que beneficien a todas las partes. Se identifican y analizan los riesgos asociados con cada requisito.

Especificación:

Es el producto final de la ingeniería de requisitos, y se convierte en la materia prima para las actividades posteriores en el proceso de desarrollo del sistema. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, una colección de escenarios de uso, un prototipo o cualquier combinación de estos.

Validación:

Un equipo de validación toma el producto de la fase de especialización, lo revisa para detectar errores, conflictos u omisiones y los corrige con el fin de garantizar la consistencia de requisitos. La validación de requisitos examina la especificación para asegurar que todos los requisitos de software se han establecidos de manera precisa; que se han detectado las inconsistencias omisiones y errores y que estos han sido corregidos y que el producto de trabajo cumple con los estándares establecidos para el proceso, proyecto y producto.

14


Gestión de requisitos:

Ayuda a rastrear los requisitos según las características de los mismos, el código fuente relacionado, dependencia entre requisitos, subsistemas e interfaces internas y externas de forma que pueda identificarse con rapidez para entender como afectara una modificación diferentes aspectos del sistema a construir. Es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto.

2.2.- TÉCNICAS DE LA INGENIERÍA DE REQUISITOS

En la Ingeniería de Requisitos se describen técnicas que permiten la captura requisitos de software, la recopilación de la información y en qué casos es adecuada usar cada cual. A continuación se hace un análisis de estas técnicas. (Sommerville, 1997).

Existen varias técnicas para la IR, sin embargo, se mencionarán algunas de las más importantes. Cada técnica puede aplicarse en una o más actividades de la

IR; en la práctica, la técnica más apropiada para cada actividad dependerá del proyecto que esté desarrollándose.

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. Las preguntas que deben realizarse en esta técnica, deben ser preguntas de alto nivel y abstractas que pueden realizarse al inicio del proyecto para obtener información sobre aspectos globales del problema del usuario y soluciones potenciales.

Las preguntas pueden ser enfocadas a un elemento del sistema, tales como usuarios, procesos, etc.

15


Lluvia de ideas (Brainstorm).

Este método comenzó en el ámbito de las empresas, aplicándose a temas tan variados como la productividad, la necesidad de encontrar nuevas ideas y soluciones para los productos del mercado, encontrar nuevos métodos que desarrollen el pensamiento creativo a todos los niveles, etc. Pero pronto se extendió a otros ámbitos, incluyendo el mundo de desarrollo de sistemas; básicamente se busca que los involucrados en un proyecto desarrollen su creatividad, promoviendo la introducción de los principios creáticos. A esta técnica se le conoce también como torbellino de ideas, tormenta de ideas, Desencadenamiento de ideas, movilización verbal, bombardeo de ideas, sacudidas de cerebros, promoción de ideas, tormenta cerebral, avalancha de ideas, tempestad en el cerebro y tempestad de ideas, entre otras.

Prototipos. Los prototipos permiten al desarrollador crear un modelo del software que debe ser construido. Al igual que todos los enfoques al proceso de desarrollo del software, el 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 la construcción de un prototipo. El prototipo es evaluado por el cliente y el usuario, y utilizado para refinar los requerimientos del software a ser desarrollado. Un proceso de iteración tiene lugar a medida que el prototipo es “puesto a punto" para satisfacer las necesidades del cliente y permitiendo al mismo tiempo una mejor comprensión del problema por parte del desarrollador.

Sistemas existentes.

Consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser construido, podemos analizar las interfaces de usuario observando el tipo de información que se maneja y como es manejada.

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 interacciones entre un sistema y alguien o algo que usa alguno de sus servicios."

16


Todo sistema de software ofrece a su entorno una serie de servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando se dice "alguien o algo" se hace referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software.

Por ejemplo, un sistema de ventas, si pretende tener éxito, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que está "ejecutando" el caso de uso ingresando pedido.

Los casos de uso tienen las siguientes características:

Están expresados desde el punto de vista del actor. Se documentan con texto informal. Describen tanto lo que hace el actor como lo que hace el sistema

cuando interactúa con él, aunque el énfasis está puesto en la interacción.

Son iniciados por un único actor. Están acotados al uso de una determinada funcionalidad del

sistema, claramente diferenciada.

Herramientas automatizadas para la administración de requerimientos.

Las herramientas case (ingeniería del software asistida por computadora) se le conoce a todo aquel software que es usado para ayudar a las actividades del proceso de desarrollo del software. Estas herramientas se concentran en capturar requerimientos, administrarlos y producir una especificación de requisitos. Entre otras cosas estas herramientas permiten un control mayor en proyectos complejos, reducir costos y retrasos en los proyectos, ayudan a determinar la complejidad y los esfuerzos necesarios.

RequisitePro.

Es la herramienta tener un mayor control sobre los requerimientos planteados por el usuario y todos aquellos requerimientos técnicos o nuevos requerimientos planteados por el usuario y todos aquellos requerimientos técnicos o nuevos requerimientos de usuario que surjan durante el ciclo de vida del proyecto. Esta herramienta se integra con aplicaciones para la administración de cambios, herramientas de modelado de sistemas y con herramientas de pruebas. Esta integración asegura que los diseñadores conocen los requerimientos del usuario, del sistema y del software en el momento de su desarrollo.

2.3.- MODELADO DE REQUISITOS

17


Modelado de requisitos nos sirve y tiene como propósito comprender completamente el problema y todo lo que éste implica y conlleva. Su objetivo principal es delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Además el modelo de requisitos captura las principales características del sistema de software que se desea construir. Por medio de él representamos los requisitos del sistema de forma sencilla, para que de esta manera cualquier usuario pueda revisarlo y además entenderlo, sin necesidad de tener conocimientos previos al modelo e información. Intervienen en el los modelos de caso de uso, que desempeñan un papel importante de gran relevancia. En el estudio del modelo de requisitos se encuentran los funcionales y no funcionales. Cabe mencionar que los requisitos determinan lo que hará el sistema, es decir, como funcionará además, las restricciones sobre su operación e implementación. La e licitación, análisis y especificación de requisitos es el proceso del estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema.

Un requisito es una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado. Puede verse como una declaración abstracta de alto nivel de un servicio que el sistema debe proporcionar.

Los requisitos funcionales: son la característica requerida del sistema que expresa una capacidad de acción del mismo, una funcionalidad; generalmente expresada en una declaración en forma verbal. No todo lo que necesitaremos en nuestro sistema es funcionalidad pura; por el contrario a veces se necesitan otras cualidades, si se quieren generalidades, que no son objeto decodificación si bien es cierto que pueden llegar a afectar a esta. Pueden ser frases muy generales sobre lo que el sistema debería hacer.

Los requisitos no funcionales pueden clasificarse en:

Requisitos del producto.Requisitos organizacionales.Requisitos externos.

Además existen los requisitos de usuarios que nos dice que el sistema debe permitir representar y acceder a archivos externos creados por otras herramientas.

2.4.- HERRAMIENTAS CASE PARA LA INGENIERÍA DE REQUISITOS

El desarrollo de software ha ocupado un lugar importante en la Ingeniería, pero al igual que otras disciplinas, aún presenta fallas. Debido a esto se han planteado

18


técnicas y métodos para minimizar los problemas identificados en la crisis del software. Es así como surge la Ingeniería de Software, presentando distintos modelos de procesos que se ajustan a las necesidades y proyectos requeridos. La mayoría de ellos involucran en sus fases iníciales tareas como planeación, levantamiento de información, determinación de las características que debe cumplir el software, agrupadas en lo que hoy se conoce como Ingeniería de Requisitos (IR).

IRQA 43

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.

RETO

Esta herramienta propone un modelo de requisitos para capturar los aspectos funcionales del sistema; básicamente, mediante tres técnicas complementarias entre sí: la definición de la Misión del Sistema, la construcción del Árbol de

Refinamiento de Funciones y el desarrollo del Modelo de Casos de Uso. Además, se introduce un Proceso de Análisis que permite traducir el Modelo de Requisitos en el Mo- delo Conceptual, manteniendo la trazabilidad entre ambos y propiciando una representación de la información en el segundo prototipo.

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)4

19


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.

JEREMIA5

Se trata exclusivamente de una aplicación cliente exclusivamente, lo cual no permite la posibilidad de trabajar en equipo. Ésta, ayuda durante el desarrollo del sistema, especialmente en el seguimiento de cambios de los requisitos a lo largo del ciclo de vida. Con JEREMIA es posible captar las necesidades, analizarlas y clasificarlas. Implementa un módulo orientado a la generación de la documentación posible de exportar en formato DocBook XML, la cual junto con los requisitos, se almacena en una base de datos en MySQL.

RAMBUTAN6

Esta herramienta está basada en XML, realmente consta de un conjunto de aplicaciones para el usuario final, ayudando a los analistas de sistemas en la recopilación y categorización de hechos en un documento de especificación de requisitos. Lo curioso es que tiene un cliente para palm (PDA), el cual se utiliza para recopilar los hechos en el lugar donde está ubicado el cliente mientras que la aplicación de escritorio recibe la información, edita y perfecciona. Ambas aplicaciones permiten al usuario introducir, modificar y visualizar los datos que componen un documento de especificación de requisitos.

BORLAND CALIBER ANALYST:

Se trata de un producto que está compuesto por dos aplicaciones desarrolladas por la compañía borland. Por un lado están el caliber define (la última de las herramientas en cuanto a fecha de lanzamiento) que permite definir los requisitos del sistema así como a capturar las diferentes herramientas visuales, es necesario señalar que este software es compatible con gran número de herramientas existentes en el mercado.

Case espec:

Esta herramienta está desarrollada por la empresa coda software. Especificación, seguimiento de los requisitos, capacidad de rastres, importar y exportar archivos.

20


Tiger pro:

Herramienta shoreware desarrollado para facilitar al usuario la tarea de redactar los requerimientos de un proyecto. Este aplicativo es capaz de solucionar algunos de los aspectos.

1 IBM rational requisite pro:

Esta herramienta desarrollada por una de las compañías más importantes dentro del campo de la informática, se considera una de las herramienta más completas y potentes dentro del análisis y la gestión de requisitos: una de las grandes ventajas que aporta este producto es la compatibilidad y algunos programas más usados.

3.- MODELO DE ANALISIS

3.1.- ARQUITECTURA DE CLASE.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 sóla 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

21


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. La respuesta particular a la pregunta tiene que ver con qué tan independiente sea un eje de funcionalidad del otro, ya que en el caso de los métodos estructurados, usualmente se debe modificar las funciones cada vez que se modifica la estructura de información, lo cual no es algo deseable. Si logramos ejes de funcionalidad ortogonales, el efecto de cambios en una dimensión no debe afectar a las otras dimensiones. Y aunque estas dimensiones no son del todo ortogonales, si son lo suficientemente independientes se puede limitar el efecto de posibles cambios. En relación al número de dimensiones, esto depende de la funcionalidad que la arquitectura debe manejar, algo que a su vez depende del tipo de aplicación que se está desarrollando.

En el caso de los sistemas de información, uno de las tipos de arquitecturas mas importantes es la arquitectua MVC – Modelo, Vista, Control (Model, View, Control) popularizada por los ambientes de desarrollo de Smalltalk. Esta arquitectura se basa en tres dimensiones principales:Modelo (información), Vista (presentación) y Control (comportamiento) como se muestra en la Figura 1.

Figura 1 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 2.

22


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 2 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

23


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 3.

<< estereotipo >>

Nombre de la Clase

Figura 3 Diagrama de clase con estereotipo.

Los tres estereotipos correspondientes a las tres dimensiones para la arquitectura del modelo de análisis se muestra en la Figura 4.

Figura 4 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 5.

Figura 5 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.

24


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 6.

Figura 6 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.

Figura 7 Caso de uso imprimir archivo.

25


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 8. Se utilizan dos clases interface:Interface Archivo e Interface Impresora, cinco clases entidad: Cola, Archivo con sus subclasesArchivo Texto, Archivo Formateado y Archivo Gráfico y una clase control: Servidor Impresora.

Figura 8 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 9.

Figura 9 Objetos identificados para el caso de uso imprimir archivo mostrando asociaciones entre si 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.

26


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 como se discutió anteriormente. Para lograr esto se debe identificar primero las clases interface, luego las entidad y finalmente las de control. En general, se desea asignar la funcionalidad más especializada correspondiente a la “política” de la aplicación a los objetos control, la cual depende y afecta al resto de los objetos. Por otro lado, los objetos entidad e interface deben contener funcionalidad más bien local limitando su efecto en los demás objetos. El trabajo del analista consiste en distribuir lo mejor posible el comportamiento especificado en el modelo de requisitos en los diferentes tipos de objetos de la arquitectura de análisis. La asignación de funcionalidad es bastante difícil en la práctica afectando de gran manera la robustez y mantenimiento del sistema. Los buenos analistas consideran cambios potenciales al sistema a la hora de llevar a cabo este proceso.

En general, los cambios más comunes a un sistema son los cambios en su funcionalidad e interfaces. Cambios a las interfaces deben afectar típicamente solo los objetos interface. Cambios a la funcionalidad son más difíciles, ya que la funcionalidad puede abarcar todos los tipos de objetos. Si la funcionalidad está ligada a la información existente, tales cambios afecta al objeto entidad representada esa información, o puede involucrar múltiples objetos incluyendo objetos control. Típicamente, esta funcionalidad se define en uno o varios casos de uso y se asigna a uno o varios objetos control.

A continuación describimos en más detalles el proceso de identificación de los tres tipos de objetos.

Interface

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 de interfaces. Es a través de estos objetos que se comunican los actores con el sistema. La tarea de una clase interface es traducir los eventos generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema a una presentación comprensible por el actor.

Las clases interface, en otras palabras, describen comunicación bidireccional entre el sistema y los actores. Las clases interface son bastante fáciles de

27


identificar, donde se cuenta con al menos tres estrategias:

1. Se pueden identificar en base a los actores.

2. Se pueden identificar en base a las descripciones de las interfaces del sistema que acompañan al modelo de requisitos.

3. Se pueden identificar en base a las descripciones de los casos de uso y extraer la funcionalidad que es específica a las interfaces.

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 por lo general durante la ejecución del caso de uso, mientras que la información a largo plazo sobrevive a los casos de uso, por lo cual es necesario guardar esta información en alguna base de datos. Adicionalmente, se debe incluir comportamiento para manejar la propia información local al objeto entidad. Los objetos entidad se identifican en los casos de uso, donde la mayoría se identifica del modelo del dominio del problema en el modelo de requisitos. Objetos entidad adicionales pueden ser más difíciles de encontrar. Es muy común que se identifiquen muchos objetos entidad, aunque se debe limitar estos objetos a los realmente necesarios para la aplicación, siendo esto lo más difícil del proceso de identificación. Es por lo tanto esencial trabajar de forma organizada cuando se modelan los objetos entidad. Las necesidades de los casos de uso deben ser las guías y solamente aquellos objetos entidad que puedan justificarse de la descripción del caso de uso deben ser incluidos. No es siempre fácil decidir cuándo cierta información debe ser modelada como un objeto entidad o como un atributo. Esto depende de cómo se usará la información, si ésta se maneja de forma separada, debe modelarse como un objeto entidad, mientras que la información que esta acoplada fuertemente a alguna otra información y nunca se usa por si misma debe modelarse como un atributo de un objeto entidad. Todo depende de cómo los casos de uso manejen la información. Cierta información puede modelarse como objeto entidad en un sistema, mientras que en otro sistema puede ser un atributo.

Es también difícil identificar qué operaciones y cuales atributos serán incluidos dentro de los objetos entidad. Dado que la única forma para manipular un objeto entidad es por medio de sus operaciones, las operaciones identificadas deben ser suficientes para manipular completamente al objeto entidad. La descripción detallada de los casos de uso es de nuevo un medio extremadamente valioso para encontrar las operaciones deseadas. El flujo completo de eventos que se describe en los casos de uso, permite extraer las operaciones que conciernen a los objetos entidad.

28


Las operaciones asignadas a los objetos entidad pueden ser más o menos complejas. En el caso menos complejo un objeto entidad consta sólo de operaciones de acceso a los valores de los atributos. En el caso más complejo un objeto entidad puede tener flujos de eventos más allá de simples accesos a los valores de los atributos. Sea cual sea la complejidad de estas operaciones, el objetivo es que éstas sólo dependan y afecten información local. La siguiente es una lista de las operaciones típicas que deben ser ofrecidas por un objeto entidad:

Guardar y traer información

Comportamiento que debe modificarse si el objeto entidad cambia

Crear y remover el objeto entidad

Dada la complejidad de obtener operaciones, esto es un aspecto que se deja para la etapa de diseño, como se mencionó anteriormente.

Durante la identificación de objetos entidad, se encontrará que objetos similares aparecen en varios casos de uso. En tales circunstancias se debe verificar si deben ser los mismos objetos entidad o si deben haber objetos entidad separados. Incluso si los casos de uso no interactúan de la misma manera sobre los objetos, el objeto entidad puede ofrecer operaciones que satisfagan las necesidades de diversos casos de uso. Si se considera que dos objetos entidad representan un mismo objeto, las operaciones, atributos y asociaciones también tienen que integrarse.

De manera similar, se puede hacer una identificación preliminar de los atributos, sin embargo estos se desarrollarán más ampliamente durante el modelo de diseño.

Control

Hasta ahora se han identificado partido objetos interface y entidad a partir de cada caso de uso. En algunas situaciones todo un caso de uso pudiera implementarse exclusivamente mediante estos dos tipos de objetos. De tal manera no se necesitaría ningún objeto control para el respectivo caso de uso. Sin embargo, 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 que realmente no pertenece de manera natural a ninguno de ellos. Una posibilidad es repartir el comportamiento entre los dos tipos de objetos, como lo sugieren algunos métodos, 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 la su modificación. Por lo tanto, para evitar estos problemas tal comportamiento se asigna en objetos control. Sin embargo, es difícil lograr un

29


buen balance en la asignación del comportamiento entre los objetos entidad, interface y control.

Los objetos de control típicamente actúan como “pegamento” entre los otros tipos de objetos y por lo tanto proveen la comunicación entre los demás tipos de objetos. Son típicamente los más efímeros de todos los tipos de objetos, dependiendo de la existencia del propio caso de uso. Los objetos control se identifican directamente de los casos de uso. Como primera aproximación, se asigna un objeto control a cada caso de uso, concreto y abstracto. Dado que se asigna inicialmente el comportamiento a los objetos interface y entidad para cada caso de uso, el comportamiento restante se asigna a los objetos control. A menudo un manera de asignar el comportamiento es modelar inicialmente el caso de uso sin ningún objeto control, o sea sólo utilizar objetos interface y objetos entidad. Cuando tal modelo se ha desarrollado, se verá que hay ciertos comportamientos que no se asignan de forma natural, ni en los objetos entidad ni en los objetos interface, o peor aún, se dispersan sobre varios objetos. Estos comportamientos deben ubicarse en los objetos control. Sin embargo, puede darse la situación donde no queda comportamiento restante para modelar en el caso de uso. En tal caso no se necesita un objeto control. Otra situación es si el comportamiento que queda, después de distribuir el comportamiento relevante entre objetos interface y entidad, es demasiado complicado, la funcionalidad puede ser dividida en varios objetos control. Por otro lado, si un caso de uso se acopla a varios actores esto puede indicar que existen variados comportamientos en relación a los diferentes actores y por lo tanto deben asignarse varios objetos control. La meta debe ser ligar solo un actor con cada objeto control ya que los cambios en los sistemas a menudo son originados por los actores y de tal manera se logra modularizar los posibles cambios. La estrategia de asignación de control se debe decidir según cada aplicación. En la mayoría de los casos, sin embargo, se promueve la separación del control de un caso de uso en un objeto control que delega funcionalidad de manejo más local a los otros dos tipos de objetos.

3.3.- CLASES

Las clases son declaraciones o abstracciones de objetos, lo que significa, que una clase es la definición de un objeto. Cuando se programa un objeto y se definen sus características y funcionalidades, realmente se programa una clase.Una clase es un contenedor de uno o más datos (variables o propiedad miembro) junto a las operaciones de manipulación de dichos datos (funciones/métodos). Las clases pueden definirse como estructuras (struct), uniones (union) o clases (class) pudiendo existir diferencias entre cada una de las definiciones según el lenguaje. Además las clases son agrupaciones de objetos que describen su comportamientoClases

30


Las clases son lo más simple de Java. Todo en Java forma parte de una clase, es una clase o describe cómo funciona una clase. El conocimiento de las clases es fundamental para poder entender los programas Java.

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 RentaAuto. 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 RentaAuto 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.

31


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 RentaAuto podría tener los siguientes métodos: inicioRenta( ), entregaAutof ) y servicio( ). Al especificar métodos, normalmente la primera letra es minúscula.

3.4 - DIAGRAMA DE SECUENCIA

El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"

Utilidad

Un diagrama de utilidad muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Tipos de mensajes

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.

32

http://es.wikipedia.org/wiki/UML


Pueden ser usados en dos formas

•De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).

•Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles. Esta para atrás

Estructura

Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la clase instanciada por el objeto en la recepción final del mensaje

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.

3.5.- DICCIONARIO DE CLASES SEGÚN MÓDULOS.

Un diccionario de clases es un catálogo, un depósito, de los elementos en un sistema. Como su nombre lo sugiere, estos elementos se centran alrededor de los datos y la forma en que están estructurados para satisfacer los requerimientos de los usuarios y las necesidades de la organización. En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos en todo el sistema. Los elementos más importantes son flujos de datos, almacenes de datos y procesos. El diccionario guarda los detalles y descripciones de todos estos elementos.

El diccionario se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos de sistemas.

33


Importancia del diccionario

Los analistas utilizan los diccionarios de datos por cinco razones importantes:

1. Para manejar los detalles en sistemas grandes.

2. Para comunicar un significado común para todos los elementos del sistema.

3. Para documentar las características del sistema.

4. Para facilitar el análisis de los detalles con la finalidad de evaluar las características y determinar dónde efectuar cambios en el sistema.

5. Localizar errores y omisiones en el sistema.

Manejo de detalles

Los sistemas grandes tienen enormes volúmenes de datos que fluyen por ellos en forma de documentos, reportes e incluso pláticas. De manera similar, se llevan a cabo muchas actividades que utilizan los datos existentes o que generan nuevos detalles. Recuérdese, como se mencionó en la historia al inicio de este capítulo, que Lodos los sistemas experimentan cambios continuos y manejar de manera completa todos los detalles es un desafió. Con franqueza, es imposible que los analistas recuerden todo. Los que tratan de hacerlo cometen de manera invariable equivocaciones u olvidan elementos importantes. Los mejores analistas no intentan recordarlo todo, en lugar de hacerlo registran toda la información. Algunos lo hacen sobre hojas de papel y otros quizá sobre tarjetas indexadas. Muchos emplean para tal fin un procesador de palabras y una computadora personal por supuesto. Los analistas mejor organizados y más eficaces utilizan diccionarios de datos automatizados diseñados de manera específica para el análisis y diseño de sistemas.

Comunicación de significados

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.

34


3.6.- HERRAMIENTAS CASE PARA EL ANÁLISIS

Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o front-end, orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.

Herramientas de análisis y 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. Se tienen:

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)

ERwin

PLATINUM ERwin es una herramienta de diseño de base de datos. Brinda productividad en diseño, generación, y mantenimiento de aplicaciones. Desde un modelo lógico de los requerimientos de información, hasta el modelo físico perfeccionado para las características específicas de la base de datos diseñada, ERwin permite visualizar la estructura, los elementos importantes, y optimizar el diseño de la base de datos.

Genera automáticamente las tablas y miles de líneas de stored procedure y triggers para los principales tipos de base de datos. ERwin hace fácil el diseño de una base de datos. Los diseñadores de bases de datos sólo apuntan y pulsan un botón para crear un gráfico del modelo E-R (Entidadrelación) de todos sus requerimientos de datos y capturar las reglas de negocio en un modelo lógico, mostrando todas las entidades, atributos, relaciones, y llaves importantes.

PowerDesigner

PowerDesigner es una suite de aplicaciones de Powersoft para la construcción, diseño y modelado de datos a través de diversas aplicaciones. Es la herramienta para el análisis, diseño inteligente y construcción sólida de una base de datos y un desarrollo orientado a modelos de datos a nivel físico y conceptual, que dan a los desarrolladores Cliente/Servidor la más firme base para aplicaciones de alto rendimiento

35


4.- MODELO DE DISEÑO

El modelo de diseño es un refinamiento y formalización adicional del modelo de 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.

Se requiere un modelo de diseño ya que el modelo de análisis no es lo suficientemente formal para poder llegar al código fuente. Por tal motivo se debe refinar los objetos, incluyendo las operaciones que se deben ofrecer, la comunicación entre los diferentes objetos, los eventos que los objetos envían entre sí, etc. El sistema real debe adaptarse al ambiente de implementación. En el análisis se asume un mundo ideal para el sistema, en la realidad se debe adaptar el sistema al ambiente de implementación, algo que puede cambiar durante el ciclo de vida del sistema. Se busca además aspectos como, los requisitos de rendimiento, necesidades de tiempo real, concurrencia, el lenguaje de programación, el sistema de manejo de base de datos, etc. Se desea también validar los resultados del análisis. Según el sistema crece y se formaliza, se verá qué tan bien los modelos de requisitos y análisis describen al sistema. Durante el diseño, se puede ver si los resultados del análisis son apropiados para su implementación. Si se descubre aspectos que no están claros en alguno de los modelos anteriores, estos deben ser clarificados, quizás regresando a etapas anteriores.

Aunque esto pudiera verse como deficiencias del resultado de las fases anteriores que deben ser clarificadas aquí, esto sería una visión incorrecta de las diferentes etapas del desarrollo, ya que el propósito de los modelos de requisitos y análisis es comprender el sistema y darle una buena estructura. También es importante comprender que las consideraciones tomadas en cuenta durante el diseño deben influir en la estructura del sistema lo menos posible. Es la propia aplicación la que controla la estructura, no las circunstancias de su implementación. Se considera el modelo de diseño como una formalización del espacio de análisis, extendiéndolo para incluir una dimensión adicional correspondiente al ambiente de implementación

36


Las estructuras con las cuales se trabaja en el modelo de diseño son básicamente las mismas que en el modelo de análisis. Sin embargo, el punto de vista cambia, ya que se toma un paso hacia la implementación. El modelo de análisis debe ser visto como un modelo conceptual y lógico del sistema, mientras que el modelo de diseño debe acercarse al código fuente. Esto significa que se cambia el punto de vista del modelo de diseño a una abstracción del código fuente final. Por lo tanto el modelo de diseño debe ser una descripción de cómo el código fuente debe ser estructurado, administrado y escrito.

En cierta manera este enfoque es una extensión del concepto de la separación de la “política” de la implementación, donde la política fue definida durante el modelo de análisis y el diseño tiene la responsabilidad mantener esta separación durante el diseño de métodos, aquellos que sirven para tomar decisiones (control) y aquellos que no (interface y entidad).

En general, cambios en la arquitectura del sistema para mejorar el rendimiento del sistema deben ser pospuestos hasta que el sistema esté (parcialmente) construido. La experiencia muestra que en los sistemas grandes y complejos, uno frecuentemente adivina incorrectamente cuales son los cuellos de botella críticos al rendimiento.

Para hacer una evaluación más adecuada es necesario evaluar parte del rendimiento del sistema construido, algo que también se puede ir adelantando a nivel de prototipos.

Para llevar a cabo estos objetivos, se considera por separado los dos aspectos principales del modelo de diseño: el diseño de sistema y el diseño de objetos:

Diseño de Sistema. Se adapta el modelo al ambiente de implementación. Este paso incluye identificar e investigar las consecuencias del ambiente de implementación sobre el diseño. Aquí deben ser tomadas las decisiones de implementación estratégicas:

Cómo se incorporará una base de datos en el sistema,

Qué bibliotecas de componentes se usarán y cómo,

Qué lenguajes de programación se utilizarán,

Cómo se manejarán los procesos, incluyendo comunicación y requisitos de rendimiento,

Cómo se diseñará el manejo de excepciones y recolección de basura, etc.

Durante el diseño se debe decidir cómo mecanismos abstractos como la asociación, serán implementados. Similarmente, si el lenguaje de programación no ofrece ninguna técnica para apoyar herencia, se debe especificar cómo ésta será

37


implementada. En resumen, se debe especificar cómo las circunstancias del ambiente de implementación deben ser manejadas en el sistema.

Diseño de Objetos. Se refina y formaliza el modelo para generar especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. Se describe cómo interaccionan los objetos en cada caso de uso específico, especificando qué debe hacer cada operación en cada objeto. Este paso genera las interfaces de los objetos, las cuales deben ser luego implementadas mediante métodos.

En general, si el ambiente de implementación tiene pocas consecuencias en el sistema, el diseño se basará casi exclusivamente en el diseño de objetos, o sea, en un modelo de análisis muy detallado describiendo los atributos y operaciones del sistema. Por el contrario, si el ambiente de implementación afecta mucho al sistema, el diseño se basará principalmente en el diseño de sistema, o sea, en un modelo de análisis que afecta de menor manera el resultado final del sistema y que deberá ser refinado posteriormente. En nuestro caso minimizaremos el efecto del ambiente de implementación sobre el sistema, razón por la cual comenzaremos con la descripción del diseño de objetos. Posteriormente describiremos los aspectos particulares relacionados con el diseño de sistema. A continuación describimos algunas estrategias generales de diseño antes de proseguir con los aspectos específicos del diseño, tanto de objetos como de sistema.

4.1.- ESTRATEGIAS DE DISEÑO

Antes de poder resolver el diseño es necesario tomar decisiones generales sobre las estrategias de diseño a seguir. Algunas de las decisiones a tomar se presentan a continuación y se relacionan con aspectos que incluyen la arquitectura, robustez, reuso y extensibilidad del sistema.

Arquitectura

El término arquitectura se refiere, en nuestro caso, a la organización de las clases dentro del sistema. Durante el modelo de análisis se generó una arquitectura de clases para el sistema y se definió la funcionalidad “conceptual” ofrecida por las distintas clases dentro de la arquitectura. Durante el diseño esta arquitectura debe detallarse, pudiéndose cambiar los aspectos considerados inicialmente, como fue la funcionalidad inicialmente asignada a cada clase, e incluso las propias clases, como hemos mencionado al inicio del capítulo.

38


El conocimiento y funcionalidad asignada a cada clase puede ser vista como la “inteligencia” de cada clase dentro del sistema. En otras palabras, algunas clases pueden ser vistas como más inteligentes que otras según el conocimiento y control que tengan sobre las demás clases. Por ejemplo, colecciones de objetos tales como listas o arreglos, no se consideran como particularmente inteligentes ya que pueden manipular y obtener información sobre las clases que almacenan, pero tienen relativamente poco impacto sobre estas u otras clases dentro del sistema. Por otro lado, un manejador de interface de usuario requiere mayor inteligencia, ya que debe poder administrar la interacción con el usuario, incluyendo manejo de eventos y manipulaciones sobre las pantallas. Una clase aún más inteligente es el controlador o manejador de la lógica completa de la aplicación, ya que es responsables de administrar a los propios manejadores de interface de usuario y relacionar su funcionalidad con el resto del sistema.

Como parte de la arquitectura de diseño se debe decidir cómo distribuir la inteligencia entre la clase y qué aspectos de la inteligencia total del sistema debe ser asignada a cada una de ellas. Para esto existen tres alternativas principales:

Un enfoque es minimizar el número de clases inteligentes. En el caso más extremo, sólo un objeto tendría conocimiento sobre todo el sistema. Todos los demás objetos tendrán un mínimo de inteligencia y el objeto inteligente servirá como controlador del resto. Una ventaja de este enfoque es que sólo se requeriría comprender el flujo de control dentro del objeto principal para comprender toda de la aplicación. Sin embargo, se vuelve más compleja la extensibilidad del sistema, ya que cualquier cambio en el flujo de control se llevaría a cabo en un mismo objeto afectando potencialmente la lógica de toda la aplicación. En cierta manera esto puede considerarse como la “estructuración” del programa, en otras palabras, transformando la orientación a objetos a programación estructurada, donde toda la aplicación consta de un solo “objeto”.

Otro enfoque opuesto es distribuir la inteligencia del sistema lo más homogéneamente posible, diseñando todas las clases con inteligencia similar. Este enfoque va más con el espíritu de la orientación a objetos. Sin embargo, una distribución perfectamente homogénea es una tarea casi imposible, ya que los objetos varían en sus responsabilidades dependiendo de su razón de ser en la aplicación. Por otro lado, distribuyendo la inteligencia del sistema de manera homogénea entre los objetos permite que cada objeto sepa relativamente menos cosas. Esto produce objetos más pequeños y más fáciles de comprender. La desventaja es que la inteligencia del sistema va de la mano con la especialización de las clases. Si todas las clases son “inteligentes”, esto significará que ellas serán muy especializadas, dificultando la extensibilidad del sistema que requiere mayor generalización en las clases.

39


El tercer enfoque es encontrar un balance entre los dos primeros. La idea es homogenizar la inteligencia del sistema sólo entre ciertas clases, tales como las de control. El resto de las clases serán “tontas” o genéricas, cómo las clases entidad e interface, permitiendo un buen porcentaje de extensibilidad en el sistema. Esto sigue la lógica introducida durante el modelo de requisitos y posteriormente análisis, donde se distingue entre las diversas razones de ser de las clases (comportamiento, presentación y dominio) para lograr una mayor robustez del sistema.

Robustez

La robustez de un sistema debe ser uno de los objetivos principales del diseño. Jamás debe agregarse funcionalidad o simplificar código a expensas de la robustez. El sistema debe estar protegido contra errores y debe al menos ofrecer diagnósticos para las fallas que aún pudiesen ocurrir, en particular aquellas que son fatales. Durante el desarrollo es a veces bueno insertar instrucciones internas en el código para descubrir fallas, aunque luego sean removidas durante la producción. En general se debe escoger lenguajes de programación que apoyen estos aspectos, como son el manejo de excepciones. Las principales consideraciones relacionadas con la robustez de un sistema son las siguientes:

El sistema debe estar protegido contra parámetros incorrectos proporcionados por el usuario. Cualquier método que acepte parámetros del usuario debe validar la entrada para evitar problemas. El diseñador de métodos debe considerar dos tipos de condiciones de error: (i) errores lógicos que son identificados durante el análisis y (ii) errores de implementación, incluyendo errores del sistema operativo, tales como los errores de asignación de memoria, o errores de archivos de entrada y salida, etc.

El sistema no debe optimizarse hasta que este funcione de manera correcta. A menudo los programadores le dedican demasiado esfuerzo a mejorar partes del código que se ejecutan poco frecuente. Optimizar requiere primero medir el rendimiento del sistema. Se debe estudiar las alternativas, como aspectos de memoria, velocidad, y simplicidad de implementación. No se debe optimizar más de lo necesario, ya que la optimización compromete la extensibilidad, reuso y comprensión del sistema.

El sistema debe incluir estructuras de datos que no tengan límites predefinidos. Durante el diseño es difícil predecir la capacidad máxima

40


esperada para la estructura de datos en la aplicación. Por lo tanto, se debe escoger estructuras de datos como las listas, a diferencia de los arreglos.

El sistema debe instrumentar un monitoreo de rendimiento y búsqueda de errores. El esfuerzo para llevarlo a cabo depende del ambiente de programación. Si el lenguaje de implementación no proporciona ningún apoyo, se pueden añadir métodos de impresión para cada clase. También se pueden añadir mensajes de entrada y salida a los métodos, imprimiendo selectivamente estos valores.

El encapsulamiento juega un papel fundamental para la robustez del sistema. Ocultar la información interna, atributos e implementación de métodos, a una clase permite que ésta pueda ser cambiada sin afectar al resto del sistema. Únicamente la interface delos métodos afecta a las demás clases.

Reuso

El reuso es un aspecto fundamental del diseño. Cuanto más se pueda reutilizar el código mejor será la robustez del sistema. Las siguientes son algunas estrategias para mejorar las posibilidades de reuso del diseño:

A través de la herencia se puede incrementar el reuso de código. Se toman los aspectos comunes a clases similares utilizando superclases comunes. Este enfoque es efectivo cuando las diferencias entre las clases son pequeñas y las similitudes son grandes. Es importante considerar la naturaleza de cada herencia para asegurar que no se está llendo a extremos donde la aplicación de la herencia sea inadecuada.

El uso impropio de herencia puede hace que los programas sean difíciles de mantener y extender. Como alternativa, la delegación provee un mecanismo para lograr el reuso de código pero sin utilizar herencia. Esto se basa en el uso de agregación a través de clases intermediarias que ocultan la funcionalidad de las clases a las cuales se delega.

El encapsulamiento es muy efectivo para lograr el reuso, pudiéndose aplicar tanto al nivel de los objetos como de componentes desarrollados en otras aplicaciones. Estos componentes pueden ser reutilizables como fueron diseñados a simplemente agregando nuevas interfaces.

Extensibilidad

41


La mayoría de los sistemas son extendidos en manera no prevista por el diseño original. Por lo tanto, los componentes reutilizables mejorarán también la extensibilidad. Las siguientes son algunas de las perspectivas de extensibilidad:

Nuevamente, se debe encapsular clases, ocultando su estructura interna a las otras clases. Sólo los métodos de la clase deben accesar sus atributos.

No se debe exportar estructuras de datos desde un método. Las estructuras de datos internas son específicas al algoritmo del método. Si se exporta las estructuras se limita la flexibilidad para poder cambiar el algoritmo más tarde.

Una clase debe tener un conocimiento limitado de la arquitectura de clases del sistema. Este conocimiento debe abarcar únicamente las asociaciones entre ella y sus vecinos directos. Para interactuar con un vecino indirecto, se debe llamar una operación del objeto vecino para atravesar la siguiente relación. Si la red de asociaciones cambia, el método de la clase puede ser modificado sin cambiar la llamada.

Se debe evitar expresiones de casos (case statements) sobre tipos de objetos. Para ello, se debe usar métodos (polimorfismo) para seleccionar el comportamiento a ejecutarse basado en el tipo del objeto en lugar de expresiones de casos. El polimorfismo evita muchas de estas comparaciones de tipos.

Se debe distinguir entre operaciones privadas y públicas. Cuando una operación pública es usada por otras clases, se vuelve costoso cambiar la interface, por lo cual las operaciones públicas deben ser definidas con cuidado. Las operaciones privadas son internas a la clase y sirven únicamente de ayudan para implementar operaciones públicas. Las operaciones privadas pueden ser removidas o su interface cambiada para modificar la implementación de la clase, teniendo un impacto limitado en los demás métodos de la clase.

4.2.- DISEÑO DE OBJETOS.

42


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.

43


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

Durante el diseño de sistema se toman consideraciones en base al ambiente de implementación teniendo como objetivo lograr una buena rastreabilidad de la arquitectura de objetos al código final. Estos objetos deben ser vistos como abstracciones del código a ser escrito donde, por ejemplo, un típico objeto sería representado por un archivo en el sistema, como es el caso de Java. En otros lenguajes, como C++, en lugar de un archivo se escriben dos, uno correspondiente a la interface del objeto y el otro a su implementación. En general, el diseño de sistema incluye diversos aspectos como:

Selección del lenguajes de programación a utilizarse, típicamente estructurados u orientados a objetos;

Incorporación de una base de datos, típicamente relacionales, relacionales extendidos u orientados a objetos;

Acceso a archivos, en sus diferentes formatos; Inclusión de bibliotecas, como por ejemplo, interfaces gráficas (GUI),

bibliotecas numéricas y de estructuras de datos; Consideraciones de tiempo real, si las hay; Aspectos de procesamiento, como concurrencia, paralelismo y distribución; Aspectos transaccionales, típicamente en el acceso a bases de datos; Organización del sistema en subsistemas; Asignación de subsistemas a componentes de hardware y software.

Estos aspectos pueden variar radicalmente entre uno y otro sistema y también pueden afectar de gran manera la arquitectura resultante del sistema. En general existen diversos enfoques para la incorporación del ambiente de implementación a la arquitectura del sistema:

44


Agregando clases abstractas o interfaces que luego serán especializadas según el ambiente de implementación particular. Esto es posible hacer, por ejemplo, cuando el lenguaje de programación, como en el caso de Java, es común a los diversos ambientes.

Instanciando objetos especializados que administren los aspectos particulares del ambiente de implementación particular. Esto puede significar una integración parcial o completa de componentes adicionales a la arquitectura del sistema. Por ejemplo, una integración con las interfaces nativas de Java (JNI) para manejo de aspectos de bajo nivel del ambiente.

Configurando múltiples versiones del sistema correspondientes a diferentes plataformas. Este es el enfoque más flexible, aunque por lo general el de mayor costo de desarrollo. Por ejemplo, cambios radicales en los lenguajes de programación incluyendo diseños para lenguajes estructurados.

Interfaces Gráficas

Las interfaces gráficas tienen como aspecto esencial que toda interacción con el usuario es a través de elementos gráficos, como lo son los botones, menús y textos. En lo que se refiere a la aplicación, todo sistema que interactúe mediante interfaces gráficas está dirigido por eventos. Estos eventos corresponden al movimiento del ratón, el oprimir o soltar uno de sus botones, el oprimir una tecla, junto con los que no son directamente iniciados por el usuario, como los eventos de desplegar una pantalla o interrumpir un programa.

El desarrollar un sistema dirigido por eventos significa que la aplicación debe desde un inicio considerar un diseño adecuado. Por ejemplo, en el caso de Java, se debe inicialmente escoger una de sus bibliotecas gráficas, como AWT, para luego utilizar el manejo apropiado a través de clases como Event.

El uso de estas bibliotecas también afecta la lógica de diseño, ya que se debe contemplar, por ejemplo, en que momentos es apropiado procesar nuevos eventos y cómo se inicializará el sistema. Estas consideraciones y su efecto sobre el resto del sistema serán discutidas más adelante durante el diseño de objetos.

Bases de Datos

El aspecto de bases de datos siempre juega un papel fundamental en los sistemas de información. La decisión estratégica más importante en nuestro contexto es si

45


utilizar bases de datos relacionales o las orientadas a objetos. Dado su amplia utilización y la situación actual en el mercado, escogeremos para nuestro desarrollo una base de datos relacional utilizando el lenguaje SQL estándar. Simplificaremos al máximo el diseño de la base de datos para minimizar su efecto sobre el sistema completo. Más bien, demostraremos cómo es posible diseñar buenas clases que permitan en un futuro cambiar de manejadores de bases de datos.

4.4.- REVISIÓN DEL DISEÑO

Cuando el diseño se completa se mantienen reuniones con los clientes para revisarlo antes de avanzar al desarrollo.

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.

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.

2.- 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.

46


Este grupo es más técnico que el anterior. Ya que 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.

3.- 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 requisitos 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.

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.

Hemos terminado de estudiar los refinamientos que se hicieron sobre las abstracciones. En esta etapa, las clases tienen ya definidas las operaciones que en la parte de análisis eran sólo 'frases'. A continuación se presentan nuevos diagramas de secuencia en donde se aplican las modificaciones que acabamos de realizar.

Para empezar, se muestra el diagrama de inicio de la aplicación.

47


En este diagrama podemos ver como la aplicación crea las instancias del manejador, del procesador y del stack con el que se va a trabajar. Enseguida, la aplicación le pide al manejador que se cree la ventana correspondiente, y esta entra en su ciclo de espera. Cuando la aplicación termina, se ve como se destruyen los objetos.

Diagrama Cargar Datos:

48


En este diagrama vemos como la instancia de alguna de las clases derivadas de la colección, al recibir el mensaje de carga de datos, pide una ventana (recordemos que la ColeccionDeDatos tiene una referencia al manejador), a través de la cual obtendrá el nombre del archivo de donde se cargaran los datos. No vamos a presentar el diagrama de Guardar Datos, ya que se trata esencialmente de la misma situación.

Diagrama: Aplicación de un proceso.

49


En este diagrama podemos ver cómo se selecciona el algoritmo, se instancia el proceso, se pide una ventana para llenar los parámetros y finalmente se aplica.

Diagrama de clases.

50


De la misma manera que se cerró el ciclo de análisis, se terminó la etapa de diseño con los diagramas de secuencia y con un diagrama de clases más completo que se presenta a continuación.

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

51

http://www.humbertocervantes.net/homepage/itzamna/DOCUMENTACION/DiagClases_Diseno.gif


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

52


tener un equipo de expertos en cada área pero conocen y comprenden a las demás.

La Ingeniería Concurrente (IC) es una filosofía orientada a integrar sistemáticamente y en forma simultánea el diseño de productos y procesos, para que sean considerados desde un principio todos los elementos del ciclo de vida de un producto, desde la concepción inicial hasta su disposición final, pasando por la fabricación, la distribución y la venta. Debe otorgar además una organización flexible y bien estructurada, proponer redes de funciones apoyadas por tecnologías apropiadas y arquitecturas comunes de referencia (ej: computadores en red y en bases de datos).

Retomando lo expuesto anteriormente la ingeniería concurrente es un esfuerzo sistemático para un diseño integrado, concurrente del producto y de su correspondiente proceso de fabricación y de servicio. Pretende que los desarrolladores, desde un principio, tengan en cuenta todos los elementos del ciclo de vida del producto, desde el diseño conceptual, hasta su disponibilidad incluyendo 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.

5.- 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.

53


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.

54


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

55

http://3.bp.blogspot.com/-xYNNiiYAh_k/Uap6N6Mhh9I/AAAAAAAAAH0/_AQ4ELBoAo8/s1600/kkkk.png

http://1.bp.blogspot.com/-hGn71uTrqFM/Uap6S_WwIvI/AAAAAAAAAH8/EStakSJ5M6Q/s1600/lllllll.png


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.

56

http://3.bp.blogspot.com/-2rK0e0LAQm4/Uap9dC5MySI/AAAAAAAAAII/-rsRbo6pgXQ/s1600/%C3%B1%C3%B1%C3%B1%C3%B1.png

http://4.bp.blogspot.com/-UC3Fy4jMOEk/Uap6BFC7pfI/AAAAAAAAAHU/UkXEqKMIo98/s1600/444.png


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.

57


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.

58

http://2.bp.blogspot.com/-Bhdav1dGCSQ/Uap6J3VW7_I/AAAAAAAAAHs/U45L3S6Afsk/s1600/5555.png

http://3.bp.blogspot.com/-qtlwDV_soPY/Uap6FylvgII/AAAAAAAAAHk/AfLmJf-Fdcg/s1600/777.png

http://3.bp.blogspot.com/-OzNP-_sQYJw/Uap6DrZ7_7I/AAAAAAAAAHc/USwVJMCAI8Q/s1600/66.png


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

59


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.

60


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.

61


BIBLIOGRAFIA

o http://es.scribd.com/doc/7884665/Arquitectura-de-Software-II-Diagrama-de- Componentes-y-Despliegue

o http://www.slideshare.net/techmi/curso-uml-25-diagramas-deimplementacion

o http://www.sites.upiicsa.ipn.mx/polilibros/portal/Polilibros/P_proceso/ ANALISIS_Y_DISEnO_DE_SISTEMAS/IngenieriaDeSoftware/CIS/UNIDAD%20VIII/8.3.htm

o http://ithleovi.blogspot.mx/2013/06/unidad-5-modelo-deimplementacion- el.html

o http://unidad5-modeloimplenacion-israel.blogspot.mx/2013/06/modelo-deimplementacion.html

o http://unidad4-desarrollo-de-software-lisr.blogspot.mx/2013/05/41- estrategias-de-diseno.html

o http://ithuni4coronel.blogspot.mx/

o http://sisbib.unmsm.edu.pe/bibvirtualdata/tesis/basic/mendoza_nj/cap5.pdf

o https://mundokramer.wordpress.com/2011/05/20/modelo-de-analisis- software/

o http://www.humbertocervantes.net/homepage/itzamna/ DOCUMENTACION/Doc7.html

o http://www.escet.urjc.es/~gtazon/IS/ModeladoAnalisis.pdf

o https://documat.unirioja.es/servlet/tesis?codigo=12692

o https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos

o http://dgsa.uaeh.edu.mx:8080/bibliotecadigital/bitstream/handle/ 231104/415/Ingenieria%20de%20requerimientos.pdf?sequence=1

o http://sedici.unlp.edu.ar/bitstream/handle/10915/4057/2_-_Ingenier %C3%ADa_de_requerimientos.pdf?sequence=4

62

http://sedici.unlp.edu.ar/bitstream/handle/10915/4057/2_-_Ingenier%C3%ADa_de_requerimientos.pdf?sequence=4

http://sedici.unlp.edu.ar/bitstream/handle/10915/4057/2_-_Ingenier%C3%ADa_de_requerimientos.pdf?sequence=4

http://dgsa.uaeh.edu.mx:8080/bibliotecadigital/bitstream/handle/231104/415/Ingenieria%20de%20requerimientos.pdf?sequence=1

http://dgsa.uaeh.edu.mx:8080/bibliotecadigital/bitstream/handle/231104/415/Ingenieria%20de%20requerimientos.pdf?sequence=1

https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos

https://documat.unirioja.es/servlet/tesis?codigo=12692

http://www.escet.urjc.es/~gtazon/IS/ModeladoAnalisis.pdf

http://www.humbertocervantes.net/homepage/itzamna/DOCUMENTACION/Doc7.html

http://www.humbertocervantes.net/homepage/itzamna/DOCUMENTACION/Doc7.html

https://mundokramer.wordpress.com/2011/05/20/modelo-de-analisis-software/

https://mundokramer.wordpress.com/2011/05/20/modelo-de-analisis-software/

http://sisbib.unmsm.edu.pe/bibvirtualdata/tesis/basic/mendoza_nj/cap5.pdf

http://ithuni4coronel.blogspot.mx/

http://unidad4-desarrollo-de-software-lisr.blogspot.mx/2013/05/41-estrategias-de-diseno.html

http://unidad4-desarrollo-de-software-lisr.blogspot.mx/2013/05/41-estrategias-de-diseno.html

http://unidad5-modeloimplenacion-israel.blogspot.mx/2013/06/modelo-de-implementacion.html

http://unidad5-modeloimplenacion-israel.blogspot.mx/2013/06/modelo-de-implementacion.html

http://ithleovi.blogspot.mx/2013/06/unidad-5-modelo-deimplementacion-el.html

http://ithleovi.blogspot.mx/2013/06/unidad-5-modelo-deimplementacion-el.html

http://www.sites.upiicsa.ipn.mx/polilibros/portal/Polilibros/P_proceso/ANALISIS_Y_DISEnO_DE_SISTEMAS/IngenieriaDeSoftware/CIS/UNIDAD%20VIII/8.3.htm



http://www.slideshare.net/techmi/curso-uml-25-diagramas-de-implementacion

http://www.slideshare.net/techmi/curso-uml-25-diagramas-de-implementacion

http://es.scribd.com/doc/7884665/Arquitectura-de-Software-II-Diagrama-de-Componentes-y-Despliegue

http://es.scribd.com/doc/7884665/Arquitectura-de-Software-II-Diagrama-de-Componentes-y-Despliegue


63

Documents

FUNDAMENTOS DE INGENIERIA DE SOFTWARE