Contenido Estructura del Modelo del análisis Diagrama Entidad

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