Contenido 1.
INGENIERIA DE SOFTWARE Tema 3: Modelado del análisisMétodo Estructurado
2. 3. 4.
Introducción Estructura del modelo del análisis Conclusiones Referencias
Presenta: David Martínez Torres Universidad Tecnológica de la Mixteca
[email protected] IEC37 1
Estructura del Modelo del análisis
1. Introducción
El modelo del análisis debe lograr 3 objetivos:
2
Describir lo que quiere el cliente Establecer una base para la creación de un diseño del software D fi i un conjunto Definir j t de d requisitos i it que se puedan d validad una vez que se ha construido el software.
Diagrama Diagrama Entidad- Diccionario de Flujo de datos relación de datos
El modelado del sistema permite al analista entender la funcionalidad del sistema, y los modelos son utilizados para comunicarse con los clientes Los modelos son abstractos - estos siempre dejan fuera alguna información del sistema
Diagrama Transición Estados
3
Diagrama Entidad-Relación (DER)
Representa las relaciones entre los objetos de datos Esta notación se usa para la actividad de modelado de datos Los atributos de cada objeto se pueden describir mediante d una descripción d ó de d objetos b de d datos d
4
Diagrama de flujo de datos (DFD)
Sirve para dos propósitos:
Indica como se transforman los datos conforme avanza el sistema Representa las funciones (y subfunciones) que transforman el flujo de datos datos.
En una especificación de proceso (EP) se encuentra una descripción de cada función representada en el DFD
Modelado de Datos (DER)
Diagrama transición estados (DTE)
Indica como se comporta el sistema como consecuencia de sucesos externos DTE representa los diferentes modos de comportamiento (estados) del sistema y la manera en que se hacen las transiciones de estado a estado. estado EL DTE sirve como la base del modelado de comportamiento Dentro de la Especificación de Control (EC) se encuentra mas información sobre aspectos de control del software
Modelo propuesto inicialmente por Peter Chen [CHE77] Utilizado para describir la estructura lógica de los procesados por p el sistema datos p Resalta las entidades en el sistema, las relaciones entre estas entidades, y sus atributos Ampliamente utilizada en el diseño de Bases de Datos relacionales
8
Ejemplos DER [Editado de pressman]
Ejemplos DER
9
Ejemplos DER
Ejemplo DER
Agregue al diagrama anterior las siguientes entidades y relaciones: Entidades: Distribuidor y t a spo t sta transportista Relaciones: autoriza, almacena, contrata y transporta
12
Diagramas de Flujos de Datos
DER de Software Hogar Seguro
Puede ser utilizado para mostrar el procesamiento a distintos niveles de abstracción, desde un alto nivel de abstracción hasta muy detallado Puede ser también usado para la descripción arquitectónica mostrando el intercambio de datos entre los subsistemas que componen el sistema.
Notación: Proceso : Es un transformador de datos que reside dentro de los límites del sistema a ser modelado
Proceso
14
Diagramas de Flujos de Datos
Diagramas de Flujos de Datos
Flujo de Datos : Traspaso de objetos de datos de una función a otra o bien a entidades externas al sistema.
Almacén de datos : Depósito o repositorio de datos, para el uso de uno o varios procesos. Puede ser cualquier estructura.
datos
Entidad Externa : Un productor o consumidor de información que reside fuera de los límites del sistema a ser modelado. Ejemplo hardware, persona, otro programa etc.
Cliente
Nombre
15
16
17
18
Ej. 1 DFD de nivel contextual para HogarSeguro
Panel de
Ordenes y datos de usuario
Información para visualizar
Monitor del panel de control
control
Software HogarSeguro
Tipo de alarma
Alarma
ç
Sensores
Estado del sensor
Tonos del número de teléfono
Línea telefónica
DFD de nivel 2 que refina el proceso monitorizar sensores
Ejemplo 3
19
20
Diagrama de Transición
Ejemplo
Luego se deben desarrollar los niveles siguientes, los que consisten en ir desagregando con mayor detalle, las funciones que componen el sistema. Para el ejemplo, se identifican las funciones de : ¾ Recepción de pedidos ¾ Preparación de pedidos ¾ Generación de boleta ¾ Cobranza ¾ Asignación de entrega ¾ Despacho. Construya el Nivel 1 y al menos 1 de Nivel2 del DFD
21
Se aplica al diseño de equipos o dispositivos cuyo funcionamiento está controlado por un producto de SW. Permite representar los cambios de estado del sistema, tiempos de espera, envío y procesamiento de mensaje o señales.
22
DTE Para HogarSeguro
24
Diccionarios de datos
Diccionarios de datos
El diccionario de datos es una lista de nombres y descripciones de entidades usadas en el sistema Representa un repositorio compartido con información del sistema Sirve como:
Uso de BNF para definir la estructura de grupos de datos*
Un mecanismo para manejo de nombres. Como modelo del sistema puede ser desarrollado por distintas personas. Una liga del análisis al diseño y la implementacion
25
Entradas del diccionario de datos
26
7. Referencias
Todos los nombres usados en el modelo del sistema, en el diseño y la implementacion deben estar en el diccionario de datos Debe crearse soporte de software para crear, mantener el DD así como realizar queries El diccionario de datos puede integrarse con herramientas CASE, de forma que su construcción y mantenimiento pueden automatizarse parcialmente
1. 2. 3. 4 4. 5. 6. 7.
Pressman, S Roger (1998) “Ingeniería del Software: Un enfoque práctico”, 4a edición McGraw-Hill. Kotonya, G., Sommerville, I. (1998) “Requirements Engineering. Processes and Techniques”. Wiley. Kovitz, B.L. (1999) “Practical Software Requirements: A Manual of Content and Style”, Manning. Sommerville II., Sawyer P Sommerville, P. (1998) “Requirements Requirements Engineering. A Good Practice Guide”, Wiley. Davis, A. (1993) “Software Requirements: Objects, Functions and States” Prentice-Hall, 1993. Somerville, Ian (2002) “Ingeniería de software”. 6a
edición. Addison Wesley. Braude Eric J. (2003) “Ingeniería de Software Una perspectiva orientada a objetos”, Alfaomega
27
28
7. Referencias 8.
9.
10.
11.
12.
Gause, D. C., Weinberg, G. M. (1989) “Exploring Requirements: Quality Before Design”, Dorset House. Jackson, M. (1995) “Requirements and
¿Preguntas? Gracias!
p A Lexicon of Practice,, Principles p and Specifications: Prejudices” Addison-Wesley. Robertson, S., Robertson, J. (1999) “Mastering the Requirements Process”, Addison-Wesley. Wiegers, K. (1999) “Software Requirements”, Microsoft Press. http://www.paper-review.com/tools/rms/read.php
29
30