Capitulo 3 Ing de Software

TECNOLOGICO DE ESTUDIOS SUPERIORES TIANGUISTENCO

FUNDAMENTOS DE ING. DE SOFTWARE

CAPITULO III.

ALUMNO:
JESÚS BALDEMAR ESTRADA LÓPEZ

PROFESOR:
ARTURO DÍAZ MARTÍNEZ

GRUPO:
501

Índice.
Introducción………………………………………………………………………………..…...3
Capítulo 3. Modelo de Análisis.
3.1. Arquitectura de clases……………………………………………………….……………….4
3.2. Identificación de clases segúnestereotipos……………………………………….……...6
3.3. Clases…………………………………………………………………………………………..7
3.4. Diagramas de secuencias…………………………………………………………………...9
3.4.1. Desarrollo de Diagramas de Clase durante el análisis……………………….…........10
3.4.1.1. Aproximación a un Caso de Uso guiado……………………………………………..10
3.4.1.2. Extensión guiada por la responsabilidad……………………………………………..11
3.4.2. Diseño del sistema con Diagramas deClase…………………………………………..11
3.4.2.1. Arquitecturas Multicapas………………………………………………………….…....12
3.4.2.2. Diseño de Componentes…………………………………………………………..…...12
3.4.2.3. Análisis y diseño 'Iterative'…………………………………………………………......13
3.4.2.5. Modelando el comportamiento de las Clases con Diagramas de Estado………..13
3.4.2.6 Diagramas de Actividad…………………………………………………………….......14
3.4.2.6.1. Usando Diagramas de Actividad para modelar Casos deUso……………….....14
3.4.2.7. Modelando Componentes de Software……………………………………………....14
3.4.2.8. Modelando la Distribución y la Implementación……………………………………..14
3.4.2.9. Diseño de Bases de Datos Relacionales -- Una extensión informal de UML…...15
3.4.2.6.2. Usando Diagramas de Actividad para modelar Clases……………………….....15
3.5 Diccionario de clases según Módulos……………………………………………………..17
3.6Herramientas CASE para el análisis…………………………………………………….....22
Conclusiones.

Índice de figuras.
Figura 1: Ejemplo de modelado de clases……………………………………………………....4
Figura 2: Diagrama de Secuencia para un escenario………………………………………….9
Figura 3: Diagrama de Colaboración para un grupo de Objetos…………………………….10
Figura 4: Diagrama de Clase durante la fase de análisis……………………………………11
Figura 5: Extensióninformal de UML -- Tarjetas CRC para análisis guiados por la
responsabilidad…………………………………………………………………………………...11
Figura 6: Diseño de Componentes: Especificando la Interfaz de la Clase………………..12
Figura 7: Análisis, diseño y documentación 'Iterative' con el Diagrama de Clase………..13
Figura 8: Modelando Comportamiento Dinámico de un objeto 'Vuelo' con un diagrama deestado……………………………………………………………………………………………...14
Figura 9: Modelando componentes con el Diagrama de Componentes……………………15
Figura 10: Modelando la Distribución del Sistema con el Diagrama de Implementación...15
Figura 11: Extensión de UML -- Diseño de Bases de Datos Relacionales con el Diagrama
de Relación de Entidad (ER Diagram)………………………………………………………….16
2

Introducción.
La ingeniería de requisitos del software es un proceso de descubrimiento,
refinamiento, modelado yespecificación. Se refinan en detalle los requisitos del sistema y
el papel asignado al software.
Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de
requisitos – un conjunto de actividades que son denominadas análisis – El cliente intenta
replantear un sistema confuso, a nivel de descripción de datos, funciones y
comportamiento, en detalles concretos. El desarrollador actúacomo interrogador, como
consultor, como persona que resuelve problemas y como negociador.
El análisis y la especificación de requisitos pueden parecer una tarea
relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es
muy denso. Abundan las ocasiones para malas interpretaciones o falta de información. Es
muy probable que haya ambigüedad. El dilema al que seenfrenta el ingeniero de software
puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que
cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de
que lo que escuchó no es lo que yo quise decir”.
El análisis de requisitos es una tarea de ingeniería del...