Especificaciones de software

Especificaciones de software Acuerdo entre dos partes Especificaciones de requisitos Especificaciones de diseño Puede decirnos Qué hacer Cómo hacerlo División no tan clara

Uso de las especificaciones Dar los requisitos del cliente. Dar los requisitos de diseño. Verificar la implementación. Como punto de referencia en el mantenimiento. mantenimiento correctivo. mantenimiento adaptativo. mantenimiento perfectivo.

Cualidades de las especificaciones Claras, no ambiguas y entendibles. “Seleccionar es el proceso para designar áreas del documento sobre las cuales se quiera trabajar. La mayoría de las acciones de formateado requieren de dos pasos: primero se debe seleccionar el área donde se quiere trabajar y luego iniciar la acción apropiada”.

Cualidades de las especificaciones Consistentes. Completas Internamente. Respecto a los requisitos.

Estilos de especificaciones Formales vs. informales Operacionales vs. descriptivas.

Estilos de especificaciones “Sea a un arreglo de n elementos. El resultado de ordenar a es un arreglo b de n elementos tal que el primer elemento de b es el mínimo de a (si varios elementos de a tienen el mismo valor, cualquiera de ellos es aceptable), el segundo elemento de b es el mínimo del arreglo de n-1 elementos obtenidos de a al remover su mínimo elemento; y así sucesivamente hasta que todos los n elementos de a hayan sido removidos”.

Estilos de especificaciones “El resultado de ordenar a es un arreglo b el cual es una permutación de a y está ordenado”.

Estilos de especificaciones Primero, a debe estar ordenado; donde la definición de “ordenado” se encuentra dada en la especificación descriptiva anterior. Luego, cualquier elemento duplicado del arreglo ordenado debe ser eliminado del arreglo.

Conclusiones No siempre existe una distinción muy clara entre las especificaciones descriptivas y operacionales. No existe un estilo que sea adecuado para todo tipo de problema. Ningún estilo garantizará la calidad de la especificación.

Modelos del Análisis

Modelado del Análisis Análisis Estructurado Análisis Orientado a Objetos En un nivel técnico, la ingeniería del software empieza con una serie de tareas de modelado que llevan a una especificación completa de los requisitos y a una representación del diseño general del software a construir. El modelo de análisis, realmente un conjunto de modelos, es la primera representación técnica de un sistema. El modelo de análisis debe lograr tres objetivos primarios: (1) describir lo que requiere el cliente, (2) establecer una base para la creación de un diseño de software, y (3) definir un conjunto de requisitos que se pueda validar una vez que se construye el software. Con los años se han propuesto muchos métodos para el modelado del análisis. Sin embargo, ahora dos tendencias dominan el panorama del modelado del análisis. El primero, análisis estructurado, es un método de modelado clásico del que hablaremos en esta clase. El otro enfoque, análisis orientado a objetos, se estudia con detalle en Ingeniería de Software II. El análisis estructurado es una actividad de construcción de modelos. Mediante una notación creamos modelos que representan el contenido y flujo de la información (datos y control);

Análisis Estructurado Elementos del modelo de análisis Para lograr sus objetivos, el modelo de análisis extraído durante el análisis estructurado toma la forma ilustrada en la figura. En el centro del modelo se encuentra el diccionario de datos -un almacén que contiene definiciones de todos los objetos de datos consumidos y producidos por el software-. Tres diagramas diferentes rodean el núcleo. El diagrama de entidad-relación (DER) representa las relaciones entre los objetos de datos. El DER es la notación que se usa para realizar la actividad de modelado de datos. Los atributos de cada objeto de datos señalados en el DER se puede describir mediante una descripción de objetos de datos. El diagrama de flujo de datos (DFD) sirve para dos propósitos: (1) proporcionar una indicación de cómo se transforman los datos a medida que se avanza en el sistema, y (2) representar las funciones (y subfunciones) que transforman el flujo de datos. El DFD proporciona información adicional que se usa durante el análisis del dominio de información y sirve como base para el modelado de función. En una especificación de proceso (EP) se encuentra una descripción de cada función presentada en el DFD. El diagrama de transición de estados (DTE) indica cómo se comporta el sistema como consecuencia de sucesos externos. Para lograr esto, el DTE representa los diferentes modos de comportamiento (llamados estados) del sistema y la manera en que se hacen las transiciones de estado a estado. El DTE sirve como la base del modelado de comportamiento. Dentro de la especificación de control (EC) se encuentra más información sobre los aspectos de control del software. El modelo de análisis acompaña a cada diagrama, especificación y descripción, y al diccionario señalado en la figura.

Modelo de datos ¿Qué es un modelo? MODELO REALIDAD Representación Abstracta de la realidad

Modelo de datos Diagramas de Entidad-Relación ¿Cuáles son los objetos de datos primarios que va a procesar el sistema? ¿Cuál es la composición de cada uno de estos objetos y qué atributos los describen? ¿Cuál son las relaciones entre dichos objetos? Primitivas de los DER Entidades Relaciones Atributos

Entidades y atributos Entidad Atributo Instancia de una entidad Abstracción de un objeto del mundo real. Representa una colección de objetos que tienen propiedades comunes. Ejemplo: CLIENTE Atributo Propiedad de una entidad Ejemplo: Nombre y apellido, edad, dirección, etc. Instancia de una entidad Ejemplo.

Entidades y atributos

Relaciones En IDEF1X las relaciones son binarias. Modelo conceptual En IDEF1X las relaciones son binarias. Entidades asociativas

Relaciones uno a muchos Entidad padre Entidad hijo Cardinalidad: cero, una o más

Cardinalidades “P” indica uno o más. “Z” indica cero o una. “n” indica exactamente n. ausencia de símbolo indica cero o más.

Relaciones muchos a muchos No específicas No hay padre ni hay hijo Entidad asociativa

Relaciones identificantes y no-identificantes Identificantes: la clave primaria del padre pasa a ser parte de la clave primaria del hijo. Depende para Formar su identidad Existir Siempre mandatorias. Línea llena Entidad dependiente

Relaciones identificantes y no-identificantes No-identificantes:la clave primaria del padre no migra a la clave del hijo. Puede ser opcional. No depende su identidad. Puede depender su existencia.

Relaciones identificantes y no-identificantes Z n P Uno a cero o más Cero o uno a cero o más Uno a uno o más Cero o uno a uno o más P Z n Uno a cero o más Uno a cero o uno Cero o uno a cero o uno Uno a uno o más Uno a cero o uno Cero o uno a exactamente n Uno a exacta- mente n Uno a exacta- mente n Relaciones identificantes (siempre mandatorias) Relaciones no-identificantes (opcionales o mandatorias)

Capacidad expresiva de los DER En cada curso el número de alumnos inscriptos no puede ser menor de 5 ni puede exceder el valor del atributo “max_inscriptos” de la entidad CURSO.

Entidades dependientes e independientes Entidad independiente Entidad independiente Entidad dependiente

Jerarquías de generalización Jerarquía OR Agrupamiento de entidades que comparten características comunes.

Jerarquías de generalización Jerarquía OR

Jerarquías de generalización Jerarquía AND

Jerarquías de generalización Jerarquía AND

Jerarquías de generalización completas e incompletas

Relaciones Recursivas

Conclusiones DER Notación semi-formal Descriptiva Expresividad limitada Altamente intuitivos

Modelo de Procesos Diagrama de Flujo de Datos (DFD) Características Fáciles de comunicar Notación operacional semi-formal Variedad de nombres y notación Aplicabilidad amplia Descomposición por niveles DD DFD DER DTE

Componentes de un DFD Procesos Flujos de datos Almacenes Terminadores o Entidades Externas.

Procesos Una actividad, tarea, proceso, función, etc. Transforma entradas en salidas Representación Gráfica proceso burbuja función transformación verbo-objeto (qué) en modelos de procesadores (quién) 1 SOLICITAR TARJETA

Flujo de Datos Representan datos en movimiento lógicamente relacionados. Describen el movimiento de paquetes de datos de una parte del sistema a otra. etiqueta del flujo

Flujo de Datos Entra a o sale de proceso entidad externa almacén Elegir nombres significativos 2 VALIDAR USUARIO contraseña + nro_usuario respuesta de validación dirección

Flujos de Datos Diálogo 1 DETERM. ESTADO DEL PEDIDO pregunta sobre estado de pedido respuesta sobre estado de pedido 1 DETERM. ESTADO DEL PEDIDO pregunta sobre estado de pedido respuesta sobre

Flujos de Datos Divergentes ACTUALIZAR INVENTARIO detalle de pedidos OBTENER DETALLE DE ORDEN orden de compra GENERAR FACTURA VALIDAR NUMERO TELEFO-NO CODIGO POSTAL domicilio VALIDAR CALLE código postal numero teléfono calle

Flujos de Datos Convergentes OBTENER NUMERO TELEFO-NO CODIGO POSTAL domicilio OBTENER CALLE código postal numero teléfono calle VALIDAR DOMICILIO

Aplicabilidad azúcar leche harina masa torta huevos manteca 1 2 MEZCLAR INGRE- DIENTES harina 2 HORNEAR masa torta huevos manteca

Almacén de Datos Colección de datos en reposo. Representación gráfica: archivo en disco microfichas datos en un fichero de papel etc. Representación gráfica: nombre del almacén

Almacén de Datos Lectura pasivo nombre en plural datos_cliente OBTENER DATOS PERSONALES datos_cliente CLIENTES nro_cliente no destructiva

Almacén de Datos Escritura info_contacto ACTUALIZAR INFORMACION DE CONTACTO DE CLIENTE CLIENTES nro_cliente info_contacto escritura sólo paquetes que el almacén pueda guardar

CLIENTES = {CLIENTE} CLIENTE = @nro_cliente + nombre + domicilio + teléfono nro_cliente = ... nombre = *nombre de una persona* primer nombre + (segundo nombre) + apellido domicilio = ... teléfono = ... primer nombre = ... segundo nombre = ... apellido = ... datos_cliente = nombre + domicilio + teléfono info_contacto = [domicilio + telefono | domicilio | telefono]

Diccionario de Datos - Notación = Está compuesto por + y () Opcionalidad {} Iteración. Cero o más ocurrencias. [] Selección de una de varias alternativas. | Separador de opciones alternativas. * Principio y fin de comentario. @ Identificador de clave para un almacén. Se coloca precediendo la clave.

Entidad Externa o Terminador Representan objetos con los cuales el sistema se comunica. personas agrupamientos organizaciones otros sistemas de software o hardware Se encuentran por fuera del sistema. Representación gráfica: nombre del terminador

Entidad Externa o Terminador Proveen con datos al sistema y/o esperan algún tipo de salida. “Cuando recibimos los formularios XYZ de Contaduría debemos producir los reportes financieros para el Comité de finanzas”. PRODUCIR REPORTES FINANCIEROS CONTADURIA COMITÉ DE FINANZAS formularios_XYZ reportes_financieros

DFDs por niveles Cuando el DFD es muy complejo. Organización por niveles DFD de nivel inferior proporciona más detalles sobre proceso en DFD de nivel superior.

DFDs por niveles Diagrama de Contexto Nivel más alto. Visión más abstracta del sistema. Da la visión externa del sistema. Muestra todo el sistema proceso único flujos de entrada y salida entidades externas Propósito: delinear el alcance del sistema.

DFDs por niveles Figura 0 Muestra procesos de más alto nivel y sus interfaces. Numerar burbujas. Cada burbuja i de un nivel particular se asocia con una figura del nivel siguiente (si es que se explotó).

E1 E2 E3 a b c Diagrama de Contexto PA PB PD PC Figura 3: PC PE PF PG EL SISTEMA E1 E2 E3 a b c Diagrama de Contexto 1 PA 2 PB 4 PD 3 PC a z b y x c w v Figura 0: EL SISTEMA Figura 3: PC 3.1 PE 3.2 PF 3.3 PG z y x o t

DFDs por niveles ¿Cómo se realiza la partición de los DFDs por niveles? Dos enfoques. ¿Cuántos niveles tiene que tener un DFD? Cada burbuja lleva a cabo un función única indivisible. Pistas para saber que no hemos particionado lo suficiente: proceso difícil de nombrar. proceso con demasiadas entradas y salidas. ¿Deben desarrollarse todas las partes del sistema con el mismo número de niveles? ¿Cómo asegurar que los niveles de un DFD sean consistentes entre sí?

Guía práctica Escoger nombres significativos. Numerar los procesos. Redibujar. Evitar complejidad => niveles Evitar los flujos y procesos no etiquetados. Controlar consistencia entre niveles. Tener cuidado con los almacenes de solo lectura o solo escritura.

Guía práctica Evitar sumideros infinitos. Los datos que entran a una burbuja deberían ser usados. Evitar burbujas de generación espontánea. Los datos no pueden ser generados de la nada. Excepciones: fecha y hora; nro rándom. un “agujero negro” Un “milagro”

Observaciones sobre los DFDs Fáciles de comunicar. Carecen de un significado preciso: La semántica de los componentes usados solamente se encuentra especificada por los nombres elegidos por el analista. Carecen de aspectos de control.

Modelo de Comportamiento Diagramas de Transición de Estados (DTE) Notación gráfica semi-formal operacional. Permite construir modelos de comportamiento dependientes del tiempo. Componentes: Estados Transiciones Condiciones Acciones

Estados El sistema está esperando que: Representación gráfica: algo ocurra en el ambiente externo (evento) o, alguna actividad que se está realizando en ese momento cambie a otra. Representación gráfica: nombre del estado

Transiciones Representan cambios de un estado a otro. estado inicial transición estado final

Condiciones y Acciones Pueden aparecer asociadas a una transición. ESTADO 1 ESTADO 2 Condición Acción

Mostrar “Ingrese contraseña” ESPERANDO TARJETA Se pulsó Cancelar Devolver Trajeta Se pulsó Cancelar Devolver Tarjeta Se pulsó “Finalizar” Devolver Tarjeta ESPERANDO CONTRASEÑA Se ingresó tarjeta Mostrar “Ingrese contraseña” ESPERANDO OPCION Mostrar menú de opciones Se ingresó contraseña Mostrar menú de opciones EXTRACCION Se pulsó “Extraer efectivo” CONSULTAS Se pulsó “Realizar Consulta” Mostrar opciones de consulta TRANSFERENCIA Se pulsó “Transferir Fondos”

IMPRIMIENDO MOVIMIENTOS ESPERANDO ELECCION IMPRIMIENDO SALDO IMPRIMIENDO MOVIMIENTOS Se pulsó “Consulta de Saldo” Se pulsó “Consulta de Ultimos Movimientos”

Balanceo de modelos Balanceo del DFD con el DD Cada flujo de datos y cada almacén de datos deben estar definidos en el DD. Caso contrario se dice que el dato está indefinido. Cada dato y almacén que se define en el DD debe encontrase en alguna parte del DFD. Si no aparece se dice que es un dato fantasma. Balanceo del DFD con el DER Cada almacén del DFD debe corresponderse con una entidad dependiente o independiente del DER. Los nombres de objetos en el DER deben coincidir con los nombres de los almacenes de datos del DFD. CLIENTES = {CLIENTE} CLIENTE = nombre + domicilio + teléfono + ... nombre = ...