Fundamentos de Ingenieria de Software(1-5)

FUNDAMENTOS DE INGENIERIA DE SOFTWARE

UNIDAD 1 FUNDAMENTOS DE INGENIERIA 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.c) 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)

(la manera en que se hace)

Proyecto (la realización)

Producto (la aplicación de artefactos)

1.2. EL PAPEL EVOLUTIVO DEL SOFTWARE.

GUERRA HERNANDEZ ANA LAURA 5° ”X” Página 5


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:• 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 SoftwareMitos: 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?

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álisis4. 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 ELDESARROLLO DE SOFTWARE (TECNOLOGÍAESTRUCTURADA Y ORIENTADA A OBJETOS).

Tecnología orientada a objetosHoy 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.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.Una Perspectiva HistóricaTradicionalmente, la programación fue hecha en una manera secuencial o lineal, es decir una serie de pasos consecutivos con estructuras consecutivas y bifurcaciones.Los lenguajes basados en esta forma de programación ofrecían ventajas al principio, pero el problema ocurre cuando los sistemas se vuelven complejos. Estos programas escritos al estilo “espaguetti” no ofrecen flexibilidad y el mantener una gran cantidad de líneas de código en sólo bloque se vuelve una tarea complicada.Frente a esta dificultad aparecieron los lenguajes basados en la programación estructurada. Pues la creciente tendencia de crear programas cada vez más grandes y complejos llevó a los desarrolladores a crear una nueva forma de programar que les permita crear sistemas de niveles empresariales y con reglas de negocios muy complejas. Para estas necesidades ya no bastaba la programación estructurada ni mucho menos la programación lineal. Es así como aparece la programación orientada a objetos (POO). La POO viene de la evolución de la programación estructurada;



básicamente la POO simplifica la programación con la nueva filosofía y nuevos conceptos que tiene.

¿Cuáles son las ventajas de un lenguaje orientado a objetos?· 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· Agiliza el desarrollo de software· Facilita el trabajo en equipo· Facilita el mantenimiento del softwareLo 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.

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, calculo 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 fueExcelerator en 1984 , era para PC . Actualmente la oferta de herramientas CASE es muy amplia y tenemos por ejemplo el EASYCASE o WINPROJECT .

Ingeniería de Software Asistida por OrdenadorYa en los años 70 un proyecto llamado ISDOS [diseñó] un lenguaje y por lo tanto un producto que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language)



y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).

Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el año 1984 y trabajaba bajo una plataforma PC.

Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASEha muerto completamente abriendo el mercado de diversas herramientas más específicas para cada fase del ciclo de vida del software.

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:

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

UNIDAD 2INGENIERIA DE REQUISITOS

2.1. TAREAS DE LA INGENIERÍA DE REQUISITOS. Extracción: Esta fase representa el comienzo de cada ciclo. Extracción

es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requisitos del sistema.



Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requisitos del sistema identificados hasta el momento.

Especificación: En esta fase se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle.

Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar los requisitos, es decir, verificar todos los requisitos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requisitos sean consistentes y que estén completos.

2.2. TÉCNICAS DE LA INGENIERÍA DE REQUISITOS.Entrevistas y Cuestionarios

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

Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema.

Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que serán afectados por él. El éxito de esta técnica, depende de la habilidad del entrevistador y de su preparación para la misma.

Sistemas existentes

Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser construido. Por un lado, podemos analizar las interfaces de usuario, observando el tipo de

Información que se maneja y cómo es manejada, por otro lado también es útil analizar las distintas



Salidas que los sistemas producen (listados, consultas, etc.), porque siempre pueden surgir nuevas ideas sobre la base de estas.

Lluvia de ideas

Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea eso no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas.

Prototipos

Durante la actividad de extracción de requerimientos, puede ocurrir que algunos requerimientos no estén demasiado claros o que no se esté muy seguro de haber entendido correctamente los requerimientos

Obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema final.

Entonces, para validar los requerimientos hallados, se construyen prototipos. Los prototipos son

Simulaciones del posible producto, que luego son utilizados por el usuario final, permitiéndonos conseguir una importante retroalimentación en cuanto a si el sistema diseñado con base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva.

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

Reúnen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y señalan áreas en las que será necesaria la profundización en las definiciones. Luego de esto, tiene lugar un “diseño rápido”. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseño rápido lleva a la construcción de un prototipo.

Casos de Uso

Los casos de uso son una técnica para especificar el comportamiento de un sistema.



“Un caso de uso es una secuencia de transacciones que son desarrolladas por un Sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas”

Los casos de uso permiten entonces describir la posible secuencia de interacciones entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de un actor, es una descripción de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el sistema.

2.3. MODELADO DE REQUISITOS.El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo.

El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de todos los demás modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a este nivel que posteriormente. El modelo de requisitos que desarrollaremos se

Basa en la metodología Objectory (Jacobson et al. 1992), basada principalmente en el modelo de casos de uso.

Actualmente esta metodología es parte del Proceso Unificado de Rational(RUP). El modelo de casos de uso y el propio modelo de requisitos son la base para los demás modelos, como se describió anteriormente en el Capítulo 3 y

se resume aquí:

Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en

cooperación con otros modelos como se verá más adelante.

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



que es estable con respecto a cambios, siendo un modelo lógico independiente del ambiente de implementación.

Diseño: La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo de

diseño, adaptándose al ambiente de implementación real y refinándose aún más.

Implementación: Los casos de uso son implementados mediante el código fuente en el modelo de

implementación.

Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración.

Documentación: El modelo de casos de uso debe ser documentado a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de administración, etc.

2.4. HERRAMIENTAS CASE PARA LA INGENIERÍADE REQUISITOS.A medida que pasa el tiempo se logra entender que el empleo del software es una buena opción para agilizar y sistematizar las tareas en el desarrollo de procesos. El desarrollo de software no es la excepción; en este caso dichas herramientas se han denominado CASE (Ingeniería De Software Asistida Por Computador). Estas incluyen un conjunto de programas que facilitan la optimización de un producto ofreciendo apoyo permanente a los analistas, ingenieros de software y desarrolladores. CASE es la aplicación de métodos y técnicas que dan utilidades a los programas, por medio de otros, procedimientos y su respectiva documentación.En este post se hace referencia a 3 herramientas que ayudan a la gestión de requisitos; es decir al proceso de identificación, asignación y seguimiento de los mismos, incluyendo interfaz, verificación, modificación y control de cada requisito, durante el ciclo de vida del proyecto. Los cambios/actualizaciones de requisitos deben ser gestionados para asegurar que se mantenga la calidad del producto.Hasta hace poco tiempo las herramientas para la gestión de requisitos de software se limitaban a editores de texto, los cuales hacían de esta



tarea una labor tediosa y confusa. Actualmente, se cuenta con múltiples opciones, como las que se mencionan a continuación: IRQA

Herramienta CASE de Ingeniería de Requisitos, diseñada para soportar las actividades realizadas en elproceso de especificación de sistemas. Ésta facilita y formaliza la comunicación entre el cliente, el proveedor y los distintos miembros del equipo de desarrollo. Facilita la captura, organización y análisis de las condiciones, así como la especificación de la solución mediante el apoyo metodológico adaptable a cada cliente. CONTROLA

Herramienta de apoyo al proceso de ingeniería de software en pequeñas empresas. Se creó gracias ala expansión que tuvo el mercado y a la generación de grandes y pequeñas empresas, las cuales requieren un instrumento para el desarrollo de sus proyectos. Ofrece recursos importantes tales como: Administración de requisitos, administración de casos de uso, administración de casos de prueba y error, planeamiento de liberaciones, administración de implementaciones, control de dependencia entre Implementaciones, matriz de rastreabilidad y rastreabilidad de los requisitos. OSRMT (Open Source Requirements Management Tool)

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

UNIDAD 3MODELO DE ANALISIS

3.1. ARQUITECTURA DE CLASES.Arquitectura de Clases.El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Como se discutió en la introducción del libro, dependiendo del tipo de



aplicación existen diversas arquitecturas que se pueden utilizar, siendo de nuestro interés aquellas arquitecturas especialmente diseñadas para el manejo de los sistemas de información, las cuales involucran ricas interfaces de usuario y accesos a base de datos como aspectos fundamentales de la arquitectura.

En término de las propias arquitecturas, éstas se distinguen según la organización de la funcionalidad que ofrecen los objetos dentro de ellas o ladimensió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.

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.

3.2. IDENTIFICACIÓN DE CLASES SEGÚNESTEREOTIPOS.Para llevar a cabo la transicion del modelo de requisitos al modelo de analisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos. Para ello se deben identificar primero las clases borde, las clases entidad y finalmente las de Control.En general, los cambios mas comunes a un sistema son los de funcionalidad y bordes. Los cambios de las interfaces deben afectar solo a los objetos borde.



Los cambios a la funcionalidad son más dificiles de administrar, ya que ésta puede abarcar todos los tipos de objetos.

Toda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema, se ubica en los objetos borde, pues a traves de ellso se comunican los actores con el sistema. La tarea de una clase borde es traducir los eventos generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema en una presentacion comperensible para el actor.

Las clases borde en otras palabras , describen la comunicación bidireccional entre el sistema y los actores.

Las clases borde son bastante fáciles de identificar, donde se cuenta con al menos tres estrategias:

1. Se pueden identificar con base a los actores.

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

3. Se pueden identificar con base en las descripciones de los casos de uso y extraer la funcionalidad específica a los objetos bordes.

Entidad

Se utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo plazo. La información a corto plazo existe durante la ejecución de un caso de uso, mientras que la información a largo plazo trasciende los caso de uso, por lo que es necesario guardarla en alguna base de datos o archivos.

Durante la identificación de objeto entidad, se encontrara que objetos que objetos similares aparecen en varios casos de uso.

Control



En la mayoría de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos ya vistos. Una posibilidad es repartir el comportamiento entre los dos tipos de objetos, pero la solución no es buena si se considera el aspecto de extensibilidad. Un cambio en el comportamiento podría afectar varios objetos, dificultando su modificación. Para evitar estos problemas, tal comportamiento se asigna a objetos control.

Es difícil lograr un buen balance en la distribución del comportamiento del caso de uso entre los objetos entidad, borde y control. Los objetos de control normalmente proveen a administración de los demás tipos de objetos.3.3. CLASESLas 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 propiedades 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 comportamientoClasesLas 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.

Todas las acciones de los programas Java se colocan dentro del bloque de una clase o un objeto. Todos los métodos se definen dentro del bloque de la clase, Java no soporta funciones o variables globales. Esto puede despistar a los programadores de C++, que pueden definir métodos fuera del bloque de la clase, pero esta posibilidad es más un intento de no separarse mucho y ser compatible con C, que un buen diseño orientado a objetos. Así pues, el esqueleto de cualquier aplicación Java se basa en la definición de una clase.

Todos los datos básicos, como los enteros, se deben declarar en las clases antes de hacer uso de ellos. En C la unidad fundamental son los ficheros con código fuente, en Java son las clases. De hecho son pocas las sentencias que se pueden colocar fuera del bloque de una clase. La palabra clave import (equivalente al #include) puede colocarse al principio de un fichero, fuera del bloque de la clase. Sin embargo, el



compilador reemplazará esa sentencia con el contenido del fichero que se indique, que consistirá, como es de suponer, en más clases.3.4. DIAGRAMAS DE SECUENCIAS.Un diagrama de secuencia es una forma de diagrama de interacción que muestra los objetos como líneas de vida a lo largo de la página y con sus interacciones en el tiempo representadas como mensajes dibujados como flechas desde la línea de vida origen hasta la línea de vida destino. Los diagramas de secuencia son buenos para mostrar qué objetos se comunican con qué otros objetos y qué mensajes disparan esas comunicaciones. Los diagramas de secuencia no están pensados para mostrar lógicas de procedimientos complejos.

Línea de Vida

Una línea de vida representa un participante individual en un diagrama de secuencia. Una línea de vida usualmente tiene un rectángulo que contiene el nombre del objeto. Si el nombre es self entonces eso indica que la línea de vida representa el clasificador que posee el diagrama de secuencia.

Algunas veces un diagrama de secuencia tendrá una línea de vida con un símbolo del elemento actor en la parte superior. Este usualmente sería el caso si un diagrama de secuencia es contenido por un caso de uso. Los elementos entidad, control y límite de los diagramas de robustez también pueden contener líneas de vida.



MensajesLos mensajes se muestran como flechas. Los mensajes pueden ser completos, perdidos o encontrados; síncronos o asíncronos: llamadas o señales. En el siguiente diagrama, el primer mensaje es un mensaje síncrono (denotado por una punta de flecha oscura), completo con un mensaje de retorno implícito; el segundo mensaje es asíncrono (denotado por una punta de flecha en línea) y el tercero es un mensaje de retorno asíncrono (denotado por una línea punteada).

Ocurrencia de ejecución

Un rectángulo fino a lo largo de la línea de vida denota la ocurrencia de ejecución o activación de un foco de control. En el diagrama anterior hay tres ocurrencias de ejecución. El primero es el objeto origen que envía dos mensajes y recibe dos respuestas, el segundo es el objeto destino que recibe un mensaje asíncrono y retorna una respuesta, y el tercero es el objeto destino que recibe un mensaje asíncrono y retorna una respuesta.

Mensaje Self

Un mensaje self puede representar una llamada recursiva de una operación, o un método llamando a otro método perteneciente al mismo objeto. Este se muestra como cuando crea un foco de control anidado en la ocurrencia de ejecución de la línea de vida.



Mensajes perdidos y encontrados

Los mensajes perdidos son aquellos que han sido enviados pero que no han llegado al destino esperado, o que han llegado a un destino que no se muestra en el diagrama actual. Los mensajes encontrados son aquellos que llegan de un remitente no conocido, o de un remitente no conocido en el diagrama actual. Ellos se denotan yendo o llegando desde un elemento de punto final.

3.5. DICCIONARIO DE CLASES SEGÚN MÓDULOS.Es un listado organizado de todos los datos pertinentes al sistema.Posee definiciones precisas de todos los flujos de datos, elementos y estructuras de datos, almacenes y entidades, para que tanto el usuario como el analista tengan un conocimiento completo de ellos.

La segunda herramienta de modelado importante, aunque no tiene la presencia y atractivo gráfico de los DFD, los diagramas Entidad-Relación o los diagramas de estructuras, es el diccionario de datos.



El diccionario de datos es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento común de todas las entradas, salidas, componentes de los almacenes y cálculos intermedios. El diccionario de datos define los datos haciendo lo siguiente:

– Describe el significado de los flujos y almacenes que se muestran en los DFD.

– Describe la composición de agregados de paquetes de datos que se mueven a lo largo de los flujos, es decir, paquetes complejos que pueden descomponerse en unidades más elementales.

– Describen la composición de los paquetes de datos en los almacenes.

– Especifica los valores y unidades relevantes de piezas elementales de información en los flujos de datos y en los almacenes de datos.

– Describe los detalles de las relaciones entre almacenes que se enfatizan en un diagrama de entidad-relación u otro modelo de datos.

3.6. HERRAMIENTAS CASE PARA EL ANÁLISIS.Las Herramientas case es la mejor base para el proceso de análisis y desarrollo de software, así que las computadoras afectan nuestras vidas nos guste o no. Utilizamos las maquinas en nuestra vida diaria, la mayor parte del tiempo sin reconocer conscientemente que estamos haciéndolo, a diario utilizamos aplicaciones domésticas como microondas, televisión, vídeo Caseteras o en la calle los cajeros automáticos, entre otros. La verdad es que no podemos escapar de las computadoras.



Las Herramientas CASE. Se iniciaron con un procesador de palabras que fue usado para crear y manipular documentación. Los 70’s vieron la introducción de técnicas gráficas y diagramas de flujo de datos. Sobre este punto, el diseño y especificaciones en forma pictórica han sido extremadamente complejos y consumían mucho tiempo para realizar cambios. La introducción de las herramientas CASE para ayudar en este proceso ha permitido que los diagramas puedan ser fácilmente creados y modificados, mejorando la calidad de los diseños de software. Los diccionarios de datos, un documento muy usado que mantiene los detalles de cada tipo de dato y los procesos dentro de un sistema, son el resultado directo de la llegada del diseño de flujo de datos y análisis estructural, hecho posible a través de las mejoras en las Herramientas CASE. Pronto se reemplazaron los paquetes gráficos por paquetes especializados que habilitan la edición, actualización e impresión en múltiples versiones de diseño.Herramienta CASE Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciónes informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas 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 costos, 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. Ya en los años 70 un proyecto llamado ISDOS diseñó un lenguaje y por lo tanto un producto que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).

UNIDAD 4MODELO DE DISEÑO

4.1. ESTRATEGIAS DE DISEÑO.A través de la historia de la ingeniería de software ha evolucionado un conjunto de conceptos fundamentales de diseño de software. Cada uno



ofrece al ingeniero de software un fundamento sobre el cual pueden aplicarse métodos de diseño más elaborados. Los conceptos fundamentales del diseño de software ofrecen el marco de trabajo necesario para hacer las cosas del “modo correcto”.

La meta del diseño es crear un modelo de software que implemente todos los requisitos del cliente de manera correcta y complazca a aquéllos que lousen. El proceso de diseño avanza de una visión general del software a una visión más estrecha que define el detalle requerido para implementar un sistema.El proceso de diseño comienza con un enfoque en la arquitectura. Se definen los subsistemas, se establecen mecanismos de comunicación entre los subsistemas; se identifican los componentes y se realiza una descripción detallada de cada componente. Además, se diseñan las interfaces internas, externas y del usuario.

ABSTRACCIÓN: Para un problema determinado se pueden considerar muchos grados de abstracción. En un alto grado de abstracción una solución se establece en términos generales con el lenguaje de entorno del problema. En los grados de menor abstracción se proporciona una solución más detallada de la solución. Una abstracción procedimental se refiere a una secuencia de instrucciones que tiene una función específica y limitada.Una abstracción de datos es una colección nombrada de datos que describe un objeto de datos. Por ejemplo, se puede decir que la abstracción procedimental abrir emplearía la información contenida en los atributos de la abstracción de datos puerta.

ARQUITECTURA: La arquitectura del software alude a la estructura general del software y las formas en las que la estructura proporcionan una integridad conceptual para un sistema. La arquitectura es la estructura u organización de los componentes del programa (módulos), la manera en que estos componentesinteractúan, y la estructura de datos que utilizan los



componentes.

PATRONES: Un patrón de diseño describe una estructura de diseño que resuelve un problema recurrente de diseño particular dentro de un contexto específico y en medio de fuerzas que pueden tener un impacto en la manera en que se aplica y utiliza el patrón.

MODULARIDAD: Los patrones de arquitectura y diseño de softwarematerializan la modularidad; es decir, el software se divide en componentes con nombres independientes y que es posible abordar en forma individual. Estos componentes llamados módulos se integran para satisfacer los requisitos del problema. La modularidad se basa en la estrategia divide y vencerás (es más fácil resolver un problema complejo cuando éste se divide en piezas más manejables).

4.2. DISEÑO DE OBJETOS. Un sistema orientado a objetos está compuesto de objetos que

interactúan, los cuales mantienen ellos mismos su estado local y proveen operaciones sobre su estado. La representación del estado es privada y no se puede acceder a ella directamente desde fuera del objeto. El proceso de diseño de objetos comprende el diseño de clases de objetos y las relaciones entre estas clases. El diseñoorientado a objetos comprende el desarrollo de un modelo orientado a objetos de un sistema de software para implementar los requerimientos identificados. Los objetos en un diseño orientado a objetos están relacionados con el problema aresolver.

Un proceso general para el diseño orientado a objetos puede contener las siguientes etapas:

Comprender y definir el contexto y los modos de utilización del sistema

Diseñar la arquitectura del sistema

Identificar los objetos principales del sistema

Desarrollar los modelos de diseño

Especificar las interfaces de los objetos



Todas estas actividades se pueden ver como actividades entrelazadas que influyen entre sí. Los objetos se identifican y las interfaces se especifican completa o parcialmente en el momento de definir la arquitectura del sistema.

4.3. DISEÑO DE SISTEMA.Durante el diseño de objetos, se ha desarrollado un diseño detallado con base en la arquitectura especificada. En general, el diseño de sistemas incluye aspectos como los siguientes:

Selección del lenguaje de programación a utilizarse

Incorporación de bibliotecas (para interfaces gráficas, estructuras de datos, etc.)

Incorporación de una base de datos

Incorporación de archivos en sus diferentes formatos

Consideraciones de procesamiento, como concurrencia, paralelismo, distribución y tiempo real.

Estos aspectos pueden variar entre un sistema y otro. Además, pueden afectar de manera importante la arquitectura final del sistema.

Existen diferentes enfoques para la incorporación del ambiente de implementación a la arquitectura del sistema:

Agregar clases abstractas o interfaces que luego se especializarán según el ambiente de implementación

Instanciar objetos especializados para la administración del ambiente de implementación

Configurar múltiples versiones del sistema

Correspondientes a diferentes plataformas.



LENGUAJES DE PROGRAMACIÓN

Es importante señalar que un diseño orientado a objetos no necesariamente se tiene que implementar mediante un lenguaje orientado a objetos. Sin embargo, es más natural hacerlo de esta manera. Esto es debido a que los lenguajes orientados a objetos tienen un apoyo directo a los conceptos del análisis orientado a objetos (encapsulamiento, generalización, polimorfismo).Sin embargo, se puede traducir cualquier concepto o mecanismo orientado a objetos a otros existentes en los lenguajes no orientados a objetos. El problema con este tipo de lenguajes es su conveniencia, mantenimiento y protección contra errores. Un lenguaje orientado a objetos hace que la escritura, mantenimiento y extensión de los programas sea más fácil y segura.Cabe mencionar que no todos los lenguajes de programación orientados a objetos implementan de la misma forma los conceptos de la metodología orientada a objetos. Aspectos como manejo de encapsulamiento, referencias, herencia múltiple varían de manera importante entre los lenguajes de programación.

INTERFACES GRÁFICAS: Las interfaces gráficas tienen como objetivo principal administrar la interacción entre el usuario mediante elementos gráficos, como son botones, menús y textos. Las aplicaciones interactivas donde el control del ratón y teclado desempeñan un papel importante se conocen como sistemas controlados o dirigidos por eventos. Estos eventos comprenden: mover el ratón, oprimir uno de sus botones, oprimir una tecla, etc.

BASES DE DATOS: Las bases de datos son fundamentales en los sistemas de información. Una decisión importante en tal contexto es si debe utilizar bases de datos relacionales u orientados a objetos.En general se consideran tres modelos de bases de datos principales:

ARCHIVOS: Aunque es más efectivo trabajar con bases de datos, es posible utilizar archivos, sobre todo cuando la especificación del sistema así lo requiera. En el caso de usar una base de datos, regularmente una clase se comunica con el DBMS



para hacer solicitudes a cualquier tabla. Sin embargo, en el caso de los archivos, tal manejador no existe por lo que el proceso se hace manualmente.4.4. REVISIÓN DEL DISEÑO.Una revisión es un proceso o reunión durante la cual un producto de trabajo, un conjunto de productos de trabajo o la evidencia de la ejecución de un proceso se presenta al equipo del proyecto, a los administradores, usuarios, clientes u otras partes interesadas para su comentario o aprobación.

Las revisiones al diseño de los productos de software se realizan por demanda con el objetivo de detectar e identificar no conformidades en el diseño antes de pasar a la codificación, así como también identificar aspectos de mejoramiento. Entre otros, en esta actividad se verifica la arquitectura y utilización de patrones en el diseño.

Una revisión es una forma de aprovechar la diversidad de un grupo de personas para:

Señalar la necesidad de mejoras en el producto de una sola persona o de un equipo

Confirmar las partes del producto en las que no es necesaria o no es deseable una mejora.

Conseguir un trabajo de mayor calidad maximizando los criterios de Correctitud y Completitud principalmente.

Las revisiones software pueden ser:

Informales: No hay procedimientos definidos, por lo que la revisión se realiza de la forma más flexible posible.

Ventajas: menor coste y esfuerzo, preparación corta, etc.

Desventajas: Detectan menos defectos

Semi-formales: Se definen unos procedimientos mínimos a seguir (walkthroughs)

Formales (Inspecciones): Se define completamente el proceso Revisión en detalle, por una persona o grupo distintos del autor, para: Verificar si el producto se ajusta a sus especificaciones o atributos de calidad y a los estándares utilizados en la empresa Señalar las



desviaciones sobre los estándares y las especificaciones Recopilar datos que realimenten inspecciones posteriores defectos.

4.5. DIAGRAMAS DE SECUENCIAS DEL DISEÑO.En un diagrama de secuencia se indicarán los módulos o clases que forman parte del programa y las llamadas que se hacen en cada uno de ellos para realizar una tarea determinada.

Se realizan diagramas de secuencia para definir acciones que se pueden realizar en la aplicación en cuestión.

En una primera fase de diseño podemos poner clases grandes y ficticias, que representen un paquete/librería o, si nuestro programa está compuesto por varios ejecutables corriendo a la vez, incluso clases que representen un ejecutable.

Si estamos en una fase avanzada, estamos diseñando el programa y queremos dejar bien atados los detalles entre dos programadores, que cada uno va a programar una de las clases o módulos que participan, entonces debemos posiblemente ir al nivel de clase real de codificación y método, con parámetros y todo, de forma que los programadores tengan claro que métodos van a implementar, qué deben llamar de la clase o módulo del otro, etc.

Aquí ya se ha decidido que se van a desarrollar tres librerías/paquetes/módulos, una para la interface de usuario, otra para contener el tablero y reglas del ajedrez (movimientos válidos y demás) y otra para el algoritmo de juego del ordenador.

El Diagrama de Secuencia de un sistema muestra gráficamente los eventos que fluyen de los actores al sistema. Su creación forma parte de la investigación para conocer el sistema; se incluye dentro de la etapa del análisis.

En UML el Diagrama de Secuencia muestran gráficamente los eventos que pasan de los actores al sistema.

4.6. HERRAMIENTAS CASE PARA EL DISEÑO.Son un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases.



El empleo de herramientas Case permiten integrar el proceso de ciclo de vida:

Análisis de datos y procesos integrados mediante un repositorio.

Generación de interfaces entre el análisis y el diseño.

Generación del código a partir del diseño.

Control de mantenimiento.

Requisitos de aplicación de Case:

1. Conocimiento y manejo de metodologías.

2. Capacidad de trabajo en equipo.

3. Desarrollo conjunto con los usuarios (Prototipos).

4. Equipamiento apropiado.

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

UNIDAD 5MODELO DE IMPLEMENTACION

5.1. DIAGRAMA DE COMPONENTES.



Los diagramas de componentes describen la descomposición físicos de los elementos de un sistema (modulo, base de datos, programa ejecutable, etc.) y sus relaciones. Muestran las opciones de realización incluyendo código fuente, binario y ejecutable, pueden ser simples archivos, paquetes, bibliotecas cargadas dinámicamente, etc.Representación grafica:

Elementos

› Normalmente los DC contienen los siguientes elementos:› Componentes› Interfaces› Relaciones de dependencia, generalización, asociación y realización.› Paquetes o subsistemas.

Relaciones de dependencia de los DC.› Se pueden agrupar en paquetes así como los objetos de clases,

además pueden tener entre ellos relaciones, tales como:› Generalización› Asociación› Agregación› Realización Dependencia

Estereotipos de los componentes.


http://1.bp.blogspot.com/-aPW41pSycok/UbOCeIdm6kI/AAAAAAAAAFU/gj0pqXTEQHY/s1600/1.1.png

http://1.bp.blogspot.com/-37pfqgA7pRM/UbOCeR3SfHI/AAAAAAAAAFg/N4maDioI_NQ/s1600/2-2.png


UML define cinco estereotipos estándar que se aplican a los componentes:

• Executable: Especifica un componente que se puede ejecutar en un nodo.

• Library: Especifica una biblioteca de objetos estática o dinámica.• Table: Especifica un componente que representa una tabla de una

base de datos.• File: Especifica un componente que representa un documento que

contiene código fuente o datos.• Document: Especifica un componente que representa un

documento.

Dependencias entre componentes.Se utilizan en los DC para indicar que un componente se refiere a los servicios ofrecidos por otro componente.



Subsistemas:• Los distintos componentes pueden agruparse en paquetes según un

criterio lógico y con vistas a simplificar la implementación.• Son paquetes estereotipados en <<subsistemas>>.

Funcionalidad de los subsistemas.• Los subsistemas organizan la vista de realización de un sistema.• Cada subsistema puede contener componentes y otros subsistemas.• La descomposición en subsistemas no es necesariamente una

descomposición funcional.• La relación entre paquetes y clases en el nivel lógico es el que

existe entre subsistemas y componentes en el nivel físico.• Paquetes (Categorias) y clases en el nivel lógico. Paquetes

(Subsistemas) y componentes en el nivel físico.

Interfaces.• Es el lazo de unión entre varios componentes.


http://1.bp.blogspot.com/-qAPlu66MM6k/UbOCjeQ95wI/AAAAAAAAAFo/O_YbNgb4-FY/s1600/2-3.png


• Las interfaces pueden representarse de varias formas, como vemos en la grafica:

Ejemplo de Diagrama de componentes:

Pasos para elaborar un diagrama de componentes:1. Previamente al diagrama de componentes debemos de tener hecho el diagrama de clases.2. Se debe identificar a todos las clases que participaran en el sistema o subsistema a desarrollar.3. Una vez identificado las clases, se procede a identificar sus métodos.


http://4.bp.blogspot.com/-2w40AjFgm48/UbOCoyod4bI/AAAAAAAAAF4/0qUI1QlkesQ/s1600/2-4.png

http://2.bp.blogspot.com/-dQhFMU7Kp94/UbOClVNiUYI/AAAAAAAAAFs/ZUlZ9uJDvBQ/s1600/2-5.png

http://4.bp.blogspot.com/-gICv_EW9T-Q/UbOCzxqlszI/AAAAAAAAAGA/GbQ7tW2Wt3w/s1600/2-6.png


4. Estos métodos pasaran a ser módulos con líneas de código independientes.5. Estos módulos serán los componentes de nuestro diagrama.6. Estos componentes se relacionan entre si por medio de sus interfaces.

5.2. DIAGRAMA DE DESPLIEGUE.Un diagrama de despliegue muestra las relaciones físicas entre los componentes hardwarey softwareen el sistema final, es decir, la configuración de los elementos de procesamiento en tiempo de ejecución y los componentes software(procesos y objetos que se ejecutan en ellos).

L Los diagramas de despliegue representan a los nodos y sus relaciones.

Los nodos son conectados por asociaciones de comunicación tales como enlaces de

red, conexiones TCP/IP, microondas, etc.Características

Describen la arquitectura física del sistema durante la ejecución, en términos de:–procesadores–dispositivos–componentes de software-Describen la topología del sistema: la estructura de los elementos de hardware y el software que ejecuta cada uno de ellos.

Componentes de diagrama de despliegue

Nodo: son objetos físicos que existen en tiempo de ejecución, y que representan algún tipo de recurso computacional (capacidad de memoria y procesamiento):

* Instancia de nodo. * Estereotipo de nodo.


http://3.bp.blogspot.com/-kq3T_4ZTcBw/UbN1eUV8XjI/AAAAAAAAAFA/gSYPpRGCoWQ/s1600/2.1.jpg


Artefactos: es un producto del proceso de desarrollo de software, que puede incluir los modelos del proceso Ej: archivos fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos, manuales de usuario y más.

Asociación: Una asociación representa una ruta de comunicación entre los nodos. Donde esta asociación va incluida con misma dependencia del diagrama de componentes.

Usos• Sistemas cliente-servidor• Sistemas completamente distribuidos

Ejemplo de un diagrama de despliegue:

Un diagrama de despliegue muestra las relaciones físicas entre los componentes hardwarey softwareen el sistema final, es decir, la configuración de los elementos de procesamiento en tiempo de ejecución y los componentes software(procesos y objetos que se ejecutan en ellos).

Los diagramas de despliegue representan a los nodos y sus relaciones.

Los nodos son conectados por asociaciones de comunicación tales como enlaces de red, conexiones TCP/IP, microondas, etc.


http://3.bp.blogspot.com/-kq3T_4ZTcBw/UbN1eUV8XjI/AAAAAAAAAFA/gSYPpRGCoWQ/s1600/2.1.jpg


Los diagramas de despliegue son los complementos de los diagramas de componentes que unidos, proveen la vista de implementación del sistema.

Características

Describen la arquitectura física del sistema durante la ejecución, en términos de:–procesadores–dispositivos–componentes de software-Describen la topología del sistema: la estructura de los elementos de hardware y el software que ejecuta cada uno de ellos.Componentes de diagrama de despliegue

Nodo: son objetos físicos que existen en tiempo de ejecución, y que representan algún tipo de recurso computacional (capacidad de memoria y procesamiento):

* Instancia de nodo. * Estereotipo de nodo.

Artefactos: es un producto del proceso de desarrollo de software, que puede incluir los modelos del proceso Ej: archivos fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos, manuales de usuario y más.

Asociación: Una asociación representa una ruta de comunicación entre los nodos. Donde esta asociación va incluida con misma dependencia del diagrama de componentes.

Usos• Sistemas cliente-servidor• Sistemas completamente distribuidos

Ejemplo de un diagrama de despliegue:



5.3. MODELOS DE PRUEBAS.La fase de pruebas del sistema tiene como objetivo verificar el sistema software paracomprobar si este cumple sus requisitos. Dentro de esta fase pueden desarrollarse varios tiposdistintos de pruebas en función de los objetivos de las mismas. Algunos tipos son pruebasfuncionales, pruebas de usabilidad, pruebas de rendimiento, pruebas de seguridad, etc. Estetrabajo se centra en pruebas funcionales de aplicaciones con interfaces gráficas. Estas pruebasverifican que el sistema software ofrece a los actores humanos la funcionalidad recogida en suespecificación.Una de las técnicas más empleadas para la especificación funcional de sistemas software sonlos casos de uso.

EL PROCESO DE GENERACIÓN DE PRUEBAS DEL SISTEMA

Toda prueba consta tradicionalmente de tres elementos: interacciones entre el sistema y laprueba, valores de prueba y resultados esperados. Los dos primeros elementos permitenrealizar la prueba y el tercer elemento permite evaluar si la prueba se superó con éxito o no.Un proceso de pruebas consta generalmente de cuatro fases: la fase de diseño de pruebas, lafase de codificación, la fase de ejecución y la fase de análisis de los resultados.El objetivo de un proceso de generación de pruebas del sistema es desarrollar las dos primerasfases y obtener esos tres elementos a partir del modelo de requisitos del propio sistema bajoprueba. Dicho proceso toma como punto de partida los requisitos y, a partir de ellos generalos resultados y construye las pruebas.. A partir de este estudio GUERRA HERNANDEZ ANA LAURA 5° ”X” Página 39

http://2.bp.blogspot.com/-px6mHRGpIes/UbN1eZ1bLCI/AAAAAAAAAE8/keqihq8HCOI/s1600/2.3.jpg


comparativo yde varios casos prácticos, se han identificado un conjunto de actividades pertenecientes alproceso de generación de pruebas de la figura 1 que son independientes de la plataforma de laimplementación. Es decir, dichas actividades no se ven afectadas si, por ejemplo, el sistema aprueba es un sistema web o un sistema de escritorio mono usuario. De esta manera, es posiblegenerar un conjunto de pruebas independientes de la plataforma. Sólo es necesario conocerlos detalles de la plataforma a la hora de implementar las pruebas generadas. MODELOS DE PRUEBAEn este punto se describen un conjunto de modelos de prueba independientes ydependientes de la plataforma (PITs y PDTs).

Los óvalos de la figura 2 representan los distintos modelos implicados. Los óvalossombreados representan los modelos de requisitos, los óvalos claros representan losmodelos independientes de prueba y los óvalos a rayas representan los modelosdependientes. Las líneas entre modelos implican las dependencias y las futurastransformaciones. Todos los modelos siguen el Testing Profile de UML. Siempreque ha sido posible. Los modelos de la figura 2 se describen en los siguientes puntos.

Conclusión



Como se pudo observar el desarrollo de un software es altamente complicado, ya que es muy difícil lograr un software que cumpla con todas las expectativas que el usuario requiere.

El diseño, análisis, y otras etapas son sumamente importantes porque nos permite el menor margen de error para la solución del problema.

Como se ha visto y leído las herramientas case son el mejor método para el análisis y soluciones del software, ya que han venido a mejorar los aspectos claves en el desarrollo de los sistemas de información.

Desde el momento en el que fueron creadas estas herramientas case de 1984 hasta la actualidad, las herramientas cuentan con una credibilidad y exactitud que tienen un reconocimiento universal, siendo utilizadas por cualquier programador que busca un resultado exitoso, para cada uno de sus procesos.

REFERENCIAS

Análisis y Diseño de Sistemas de Información, Senn, Editorial Mc Graw Hill



• Ingeniería del Software, Pressman, Editorial Mc Graw Hill

• Ingeniería de Software, Somerville, Editorial Pearson

http://www.slideshare.net/IngenierosD/definicin-e-historia-de-las- herramientas-case

http://www.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5103/Libro.pdf

http://www.ecured.cu/index.php/ Herramienta_CASE#Clasificaci.C3.B3n

http://h3d2jos3.blogspot.mx/2013/06/53-modelos-de-prueba.html


Documents

Fundamentos de Ingenieria de Software(1-5)