Modelo Basado en Ecenarios

Aunque el éxito de un sistema o producto basado en computadora se mide en muchas formas, la satisfaccion del usuario encabeza la lista. Si los ingenieros de software entienden la manera en que los usuarios finales (y otros actores) quienes interactuan con el sistema, el equipo de sofware sera mas capaz de caracterizar en forma apropiada los requisitos y construir modelos significativos de analisi y diseño.

Escritura de casos de uso

Un caso de uso captura las interacciones que ocurren entre los productores y consumidores de informacion y del sistem en si mismo.

Diagrama de casos de uso

Un caso de uso especifica la manera en la que los actores interactúan con el sistema en un conjunto específico de circunstancias. El desarrollo de una serie de casos de uso se comienza haciendo una lista de las funciones o actividades que realiza un actor específico.

Diagrama de carril

El diagrama de carril de UML. Es una variacion util del diagrama de actividad, ya que permite al modelador la representacion del flujo de actividades descritas por el caso de uso y, al mismo tiempo, indicar que actor (si hay multiples actores involucrados en una funcion especifica) o clase de analisis tiene la responsabilidad de la accion descrita mediante un rectangulo de actividad.

Existen tres clases de analisis porpietario, interfaz y camara con responsabilidades directas o indirectas en el contexto del diagrama de actividad representado en la figura anterior, con respecto a esta figura el diagrama de actividad se reorganiza de forma que las actividades asociadas con una clase de analisis particular pertenezcan al carril correspondiente a dicha clase. Por ejemplo la clase interfaz representa la interfaz con el usuario de acuerdo con la vision del propietario. El diagrama de actividad considera dos opciones que son responsabilidad de la interfaz: opcion para el reingreso y opcion para otra vista. Estas opciones y las decisiones asociadas con ellas pertenecen al carril de interfaz. Sin embargo, las flechas conducen desde ese carril de regreso al carril de propietario, donde ocurren las acciones del propietario.

Modelado Orientado Al Flujo

El modelado de datos orientado al flujo es una de las notaciones de analisis utilizadas con mayor amplitud en la actualidad. Aunque el diagrama de flujo de datos (DFD) y los diagramas y la

informacion relacionados no son ua parte formal de UML, pueden utilizarse para complementar los diagramas en UML y proporcionar un conocimiento adicional de los requisitos y el flujo del sistema.

El DFD se presenta en una forma jerarquica. Esto es, el primer modelo de flujo de datos (algunas vecces llamado un DFD o diagrama de contexto) representa el sistema como un todo. Los diagramas de flujo de datos subsecuentes reafinan el diagrama de contexto, ya que proporcionan una cantidad creciente de detalles con cada nivel subsiguiente.

Creacion de un modelo de flujo de datos

El diagrama de flujo de datos permite que el ingeniero de software desarrolle modelos del dominio de informacion y del dominio funcional al mismo tiempo. A medida que el DFD se refina hacia grados mayores de detalle, el analista desempeña una descomposicion funcional implicita del sistema. Al mismo tiempo, el refinamiento del DFD resulta en un correspondiente refinamiento de datos mientras se mueve hacia los procesos que incorporan la alicacion.

Creacion de un modelo de control flujo

En muchos tipos de aplicaciones el modelo de datos y el diagrama de flujo de datos son todo lo que se necesita para obtener una vision significativa de los requisitos del software. Sin embargo, como ya se ha mencionado, existe una clase muy grande de aplicaciones que estan guiadas por eventos en lugar de datos, que producen informacion de control en lugar de reportes o despliegues, y que procesan informacion con un especial interes por el tiempo y el rendimiento. Dichas aplicaciones requieren aplicar el modelado de control del flujo, ademas del modelado del flujo de datos.

En la seccion de los eventos que son candidatos potenciales se sugieren las siguientes directrices:

Hacer una lista de todos los sensores que el software “lee”. Lista todas las cndiciones de interrupcion.

Listar todos los “interruptores” que maneja un operaador. Listar todas las condiciones de datos. De acuerdo con el analisis de sustantivos y verbos aplicado a la narrativa de

procesamiento, revisar todos los “elementos de control” como posibilidades de entrada y salidas del controlde flujo.

Describir el comportameinto de un sistema mediante la identificacion de sus estados; determinar el grado que alcanza cada estado, y definir las trasiciones entre los estados.

Especificacion de control

Representa el comportamiento del sistema de dos maneras diferentes. La EC contiene un diagrama de estado que es una especificacion secuencial del comportamiento. Tambien puede contener una tabla de activacion del programa; una especificacion combinatoria del comportameinto.

Espesificacion del procceso

Se utiliza para describir todos los procesos del modelo de flujo que aparecen en el nivel final de refinacion. El contenido de la especificacion de proceso puede incluir texto narrativo, una descripcion en lenguaje de diseño de programas del algoritmo del proceso, ecuaciones

matematicas, tablas, diagramas o graficas. Al proporcionar una Ep para acompañar cada burbuja en el modelo de flujo, el ingeniero de software crea una “miniespecificacion” que puede servir como guia para el diseño del componente del software que implementará el proceso.