Los Problemas de la Creación Actual de Programas

Presentación del tema: "Los Problemas de la Creación Actual de Programas"— Transcripción de la presentación:

1 Los Problemas de la Creación Actual de Programas
Tamaño y Complejidad de los Programas La Complejidad Funcional Las Tecnologías en perpetua mutación: Sistemas Operativos Lenguajes y los entornos de desarrollo Las arquitecturas Una Arquitectura Compleja Prof. Lubiza Osío

2 Los Problemas de la Creación Actual de Programas
Tamaño y Complejidad de los Programas Soluciones Descomponer el proceso de desarrollo de sistemas Dividir el sistema en subsistema Usar una tecnología de alto nivel que esté lo bastante cerca de la realidad Prof. Lubiza Osío

3 Los Problemas de la Creación Actual de Programas
Tamaño Creciente de los Equipos Competencias cada vez mas variadas: Gestionar diferentes competencias técnicas Coordinar los trabajos para asegurar a cada uno una tarea en todo momento Hacer circular información Gestionar el trabajo en paralelo sobre una misma tarea Prof. Lubiza Osío

4 Los Problemas de la Creación Actual de Programas
Tamaño Creciente de los Equipos Aplicaciones estratégicas en la actividad de la empresa Delimitar bien el sistema Comprender y definir bien las funcionalidades Determinar constantes Analizar el ámbito de la aplicación para determinar las constantes del sistema Prof. Lubiza Osío

5 Los Problemas de la Creación Actual de Programas
Tamaño Creciente de los Equipos Debe existir buena comunicación, el lenguaje debe ser: Conciso, sin ambigüedades Expresar todas las facetas del problema Fácilmente comprensible Este lenguaje no puede ser el lenguaje natural. Se necesita de un formalismo que provea: unanimidad, expresión y comprensión Prof. Lubiza Osío

6 Los Problemas de la Creación Actual de Programas
Tamaño Creciente de los Equipos Plazos cada vez mas cortos Importancia creciente de las aplicaciones informáticas Competencia entre empresas Esto hace que sea necesario desplegar equipos mas potentes para poder dar respuesta Prof. Lubiza Osío

7 Los Problemas de la Creación Actual de Programas
Tamaño Creciente de los Equipos Soluciones Se requiere adoptar: Tecnología que unifique vocabulario Sistemas y métodos de organización del trabajo Prof. Lubiza Osío

8 Los Problemas de la Creación Actual de Programas
Especificaciones Poco Precisas Las Especificaciones son la base Permiten Validar y Verificar Son la base de los primeros intercambios entre procurador, usuario y desarrollador Permiten realizar las estimaciones Una interfaz difícil entre la actividad y la informática Prof. Lubiza Osío

9 Los Problemas de la Creación Actual de Programas
Especificaciones Poco Precisas Soluciones Para mejorar la comprensión y realización de las especificaciones, hay que usar modelos. Prof. Lubiza Osío

10 Los Problemas de la Creación Actual de Programas
Evolución Rápida de las Aplicaciones Evolución Funcional y Técnica dentro del proceso de Desarrollo Modificación de las Necesidades del Cliente Modificación de la Actividad del Cliente Modificación del Entorno Técnico Prof. Lubiza Osío

11 Los Problemas de la Creación Actual de Programas
Evolución Rápida de las Aplicaciones Solución Hay que facilitar los retornos entre las diferentes fases de desarrollo del proyecto. Prof. Lubiza Osío

12 ¿Qué es UML? Especificar, contruir, visualizar y documentar los artefactos de un sistema Es simple, común y ampliamente usable Se enfoca sobre un lenguaje de modelamiento estándar y no sobre un proceso estándar. Sin embargo, UML puede ser aplicado en el contexto de un proceso Abarca todo lo que puede ser hecho con los métodos existentes Prof. Lubiza Osío

13 ¿Cómo surge UML? UML 1.1 Industrialización
Nov ‘97 UML es aprobado como estándar por OMG UML 1.1 Sept ‘97 Estandarización Ene ‘97 UML 1.0 Microsoft, Oracle, IBM, HP & otras industrias líderes Unificación Jun ‘96 UML 0.9 Use Case Dr. Ivar Jacobson se une a Rational (Otoño ‘95) Fragmentación Oct ‘95 Unified Method 0.8 Booch OMT Dr. James Rumbaugh se une a Rational (Oct ‘95) Prof. Lubiza Osío

14 Hewlett Packard. Relación UML - Reuso - framework
IBM. Object Constraint Language (OCL) i-Logix. Objetos y modelos de comportamiento ICON Computing. Modelamiento del comportamiento de componentes IntelliCorp. Aspectos de Modelamiento de Negocio MCI Systemhouse. Distribucción y concurrencia. Amplitud alcance Microsoft. Sistema basado en componentes (modelado/interfaz/distrib) ObjecTime. Especif. Formal, extensibilidad y comportamiento Oracle. Modelamiento de Procesos de Negocio y Modelos de Negocio Platinium Technology. Mecanismos de extensión Ptech. Sistemas Distribuidos Rational Software. Definieron UML Reich Technology and Takson. Revisión durante la evolución Softeam Sterlin Software. Modelamiento de componentes y tipos Unisys. Meta-metamodelos. Facilidad con CORBA e IDL ¿Quienes apoyan a UML? Prof. Lubiza Osío

15 La Filosofía de UML Provee un expresivo lenguaje de modelamiento visual con el cual ellos pueden desarrollar y modificar modelos significativos Es independiente de cualquier lenguaje de programación y método de desarrollo Provee una base formal para entender el lenguaje de modelamiento Soporta conceptos de desarrollo de alto nivel: framework, patrones, componentes Integra las mejores prácticas Provee suficiente notación y semántica Prof. Lubiza Osío

16 Modelos Modelos en UML Un modelo es una descripción completa de un
sistema desde una perspectiva particular. Funcional Comportamiento Estado, Colaboración Secuencia, Actividad Casos de Uso Modelos Estructural Implementación Clases, Objetos Componente, Ejecución Prof. Lubiza Osío

17 Diagramas Un diagrama es una vista dentro de un modelo
Presentado desde el aspecto de un punto de vista particular Provee una representación parcial de un sistema Es semánticamente consistente con otras vistas Existen 9 tipos de diagramas: Vistas Estáticas: Uso de Caso, Clase, Objetos Componente y Desarrollo Vistas Dinámicas: Secuencia, Colaboración, Estado y Actividad Prof. Lubiza Osío

18 Modelos y Diagramas Prof. Lubiza Osío Use Case Diagrams Use Case State
Diagrama de Casos de Uso State Diagrams State Diagrams Use Case Diagrams Diagrama de Clases Use Case Diagrams Diagrama de Secuencia State Diagrams State Diagrams Diagrama de Objeto Scenario Diagrams Scenario Diagrams Diagrama de Colaboración Component Diagrams Component Diagrams Diagrama de Componentes Modelos Scenario Diagrams Scenario Diagrams Diagrama de Estados Component Diagrams Component Diagrams Diagrama de Actividad Diagrama de Ejecución Prof. Lubiza Osío

19 Diagrama de Casos de Uso
Son una Técnica para capturar la funcionalidad del sistema desde el punto de vista del usuario. “Es una secuencia de interacciones entre un Sistema y alguien o algo que usa alguno de sus servicios” Propósito: Especificar el contexto de un sistema Capturar los requerimientos del sistema Validar la arquitectura del sistema Manejar implementación y generar pruebas Historia. Introducidos por Jacobson en 1992 con OOSE Prof. Lubiza Osío

20 Diagrama de Casos de Uso
Prof. Lubiza Osío

21 Definiciones Básicas Casos de Uso
Es una secuencia de interacciones entre un sistema y algo o alguien (actor) que usa sus servicios. Características: Es iniciado por un actor El nombre es expresado desde el punto de vista del actor Se documentan con texto informal Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él Están acotados a una determinada funcionalidad del sistema Notación: Su nombre con verbo en infinitivo, seguido por el objeto o entidad del sistema que es afectado por el caso Se representa con un óvalo con el nombre del caso en su interior Casos de Uso Prof. Lubiza Osío

22 Recibir Información de Pedidos
Definiciones Básicas Empleado de Ventas Ingresar Pedido Sistema de Producción Recibir Información de Pedidos Sistema de Ventas Frontera del sistema Nombre de sistema Casos de Uso Regla: una función del sistema es un caso de uso si se debe indicar explícitamente al sistema que uno quiere acceder a esa función. Prof. Lubiza Osío

23 Definiciones Básicas Actores Nombre del Actor Sistema
Agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema que estamos construyendo Características: Son externos al sistema a desarrollar Un actor es una clase de rol -> Un usuario asume un rol Notación: Se representan con dibujos simplificados de personas. Cuando los actores son sistemas se pueden representar con otro icono Actores Nombre del Actor Sistema Nombre del Sistema Prof. Lubiza Osío

24 Relación entre Actores
Definiciones Básicas Asociación: representa la participación del actor con un caso de uso. Notación: una línea sólida que une al actor con el caso de uso Caso de Uso Actor Generalización: una generalización desde un actor A a un actor B indica que una instancia de A puede comunicarse con los mismos casos de uso que puede comunicarse una instancia de B Notación: una línea delgada que une al actor A con el B, la herencia va de A a B y termina con un triangulo vacío. Relación entre Actores * Realizar Orden Actor A La flecha apunta al actor mas general * Establecer Crédito Prof. Lubiza Osío Actor B

25 Descripción de los Casos de Uso
Definiciones Básicas Los Casos de Uso se documentan con Texto Informal Se usa una lista numerada de los pasos que sigue el actor para interactuar con el sistema. Alternativas: Representan un error o excepción en el curso normal de un caso de uso No tienen sentido por si mismas fuera del contexto del caso de uso en que ocurren Descripción de los Casos de Uso Prof. Lubiza Osío

26 Descripción de los Casos de Uso
Definiciones Básicas Basado En el Método RUP Descripción de los Casos de Uso Prof. Lubiza Osío

27 Modularización de los Casos de Uso
Definiciones Básicas Relaciones de Extensión: La funcionalidad de un caso de uso puede ser aumentada por un conjunto de pasos que ocurren sólo en algunas oportunidades (depende del cumplimiento de una condición) Son un caso de uso en sí mismas No necesariamente proviene de un error o excepción Notación: Se representa por una línea de trazos que va desde el caso que “extiende” al caso que es “extendido” Modularización de los Casos de Uso Sistema de Ventas Ingresar Pedido « extiende» Empleado de Ventas Revisar presentación de nuevos productos Prof. Lubiza Osío

28 Modularización de los Casos de Uso
Definiciones Básicas Relación INCLUYE: Define que un caso de uso contiene el comportamiento definido en otro caso de uso. Son un caso de uso en sí mismos El caso (Ordenar Producto) es usado siempre que el caso que lo usa es ejecutado (Ingresar Pedido) Notación: Se representa por una línea de trazos que va desde el caso que “usa” al caso que es “usado” Modularización de los Casos de Uso Sistema de Ventas Ingresar Pedido «incluye» Empleado de Ventas Ordenar Productos Prof. Lubiza Osío

29 Modularización de los Casos de Uso
Definiciones Básicas Relaciones de Generalización: Una generalización desde un caso de uso A hacia un caso de uso B indica que A es una especialización de B. Notación: Se representa por una línea sólida que va desde el caso que se especializa hasta el caso de uso padre. Modularización de los Casos de Uso Padre Hijo Prof. Lubiza Osío

30 Las Pre y Pos Condiciones Modularización de los Casos de Uso
Una condición previa o precondición es el estado del sistema y de sus alrededores se requieren antes de que el caso de uso pueda ser comenzado. Una poscondición son los estados que el sistema puede obtener después que el caso de uso haya finalizado. Prof. Lubiza Osío

31 Las Pre y Pos Condiciones Modularización de los Casos de Uso
Los estados descritos por las pre o las poscondiciones deben ser los estados que el usuario puede observar. “El usuario ha entrado al sistema" o “el usuario ha abierto el documento" son los ejemplos de estados observables. Una condición previa es una restricción que indic a cuando el caso del uso puede comenzar. Una precondición para un caso de uso no es precondición para un solo flujo, sin embargo se pueden definir precondiciones y post condiciones para los diferentes flujos (Normal, Alternos y Excepciones) Un poscondición para un caso del uso debe ser verdad sin importar qué flujos del alternativa fueron ejecutados; no debe ser verdad solamente para el flujo principal. Si algo pudiese fallar, esa falla se cubriría indicando en la poscondición la acción. Por ejemplo: “La acción es completada, o si algo falla, la acción no será ejecutada” Modularización de los Casos de Uso Prof. Lubiza Osío

32 Las Pre y Pos Condiciones Modularización de los Casos de Uso
Ejemplo: Una precondición para el caso de uso Retirar Dinero de un Cajero Automático seria: El cliente tiene una tarjeta personal que quepa en el lector de tarjetas, debe habérsele asignado una clave de uso de la tarjeta, y debe estar incluido sus datos en el sistema bancario. Una poscondición para el caso de uso Retirar Dinero de un Cajero Automático seria: Al final del caso de uso, toda la cuenta y los registros de la transacción deben ser balanceados, la comunicación con el sistema bancario debe ser reinicializada y se le ha devuelto al cliente su tarjeta. Modularización de los Casos de Uso Prof. Lubiza Osío

33 Modularización de los Casos de Uso
Los Flujos de Eventos El Flujo de Eventos. Contenido El flujo de eventos de un caso de uso debe describir el flujo del caso de uso es decir como fluyen los eventos claramente, para que cualquiera lo entienda fácilmente. El flujo de eventos debe presentar lo que hace el sistema, no cómo el sistema es diseño para realizar el comportamiento requerido. Modularización de los Casos de Uso Prof. Lubiza Osío

34 Modularización de los Casos de Uso
Los Flujos de Eventos El Flujo de Eventos. Contenido Las pautas para el contenido del flujo de eventos son: Describa cómo comienza el caso de uso, Describa qué datos se intercambian entre el actor y el caso de uso, No describa los detalles del interfaz utilizada, a menos que sea necesario entender el comportamiento del sistema. Es bueno incluir términos de terminología Web cuando la aplicación es de este tipo. Palabras como: navegar, browser, hiperlink, pagina, enviar, son aceptadas, no use los términos frames o pagina web. Describa el flujo de eventos, no solamente la funcionalidad. Para hacer cumplir esto, comience cada acción con “Cuando el "; Describa solamente los eventos que pertenecen al caso del uso, y no qué sucede en los otros casos del uso o exterior del sistema Modularización de los Casos de Uso Prof. Lubiza Osío

35 Modularización de los Casos de Uso
Los Flujos de Eventos El Flujo de Eventos. Estructura Las dos partes principales del flujo de eventos son flujo básico de eventos y flujos alternativos de eventos: El flujo básico de eventos debe cubrir qué "normalmente" sucede cuando se realiza el caso del uso. Los flujos alternativos de eventos cubren comportamiento del carácter opcional o excepcional en lo referente al comportamiento normal, y también a las variaciones del comportamiento normal. Modularización de los Casos de Uso Prof. Lubiza Osío

36 Modularización de los Casos de Uso
Los Flujos de Eventos El Flujo de Eventos. Estructura Algunos flujos alternativos vuelven al flujo básico de eventos, mientras que otras terminan el caso del uso. El flujo básico de eventos y los eventos alternativos de los flujos se deben estructurar más a fondo en pasos. Cada paso debe ser un segmento del comportamiento dentro del caso del uso que tiene un propósito claro. Usted puede ilustrar la estructura del flujo de eventos con el diagrama de actividad. Modularización de los Casos de Uso Prof. Lubiza Osío

37 Modularización de los Casos de Uso
Los Flujos de Eventos El Flujo de Eventos. Estructura Para clarificar donde un flujo alternativo de eventos se origina, se necesita indicar la desviación explícitamente en el flujo básico de eventos, de la siguiente manera: Donde, en el flujo básico de eventos el comportamiento alternativo puede ser insertado. La condición que necesita ser satisfecha para que el comportamiento alternativo comience. Cómo y donde el flujo básico de eventos es resumido, o cómo el caso de uso termina. Hay también flujo alternativo de los eventos que se pueden insertar en más de una localización, algunos se puede incluso insertar en cualquier localización en el flujo básico de eventos. Modularización de los Casos de Uso Prof. Lubiza Osío

38 De Trazo Grueso vs. de Trazo Fino
Tipos de Casos de Uso Trazo Grueso: Ignoramos detalles sobre la forma de interacción entre el actor y el sistema Sólo incluimos las alternativas mas relevantes No entramos en detalle sobre las acciones que realiza el sistema cuando el usuario interactúa con él Trazo Fino: A medida que se hacen los prototipos de las IU, incluimos detalles sobre la forma de la interfaz en la descripción del caso Incluimos otras alternativas. Errores o excepciones requeridas por el usuario Especificamos con mas detalle el comportamiento interno del sistema De Trazo Grueso vs. de Trazo Fino Prof. Lubiza Osío

39 El Proceso de Análisis de Requerimientos
con Casos de Uso Identificar los Actores Identificar los principales CU por cada actor Identificar los nuevos CU a partir de los existentes Variaciones significativas de los CU existentes CU opuestos CU que preceden a casos existentes CU que suceden a casos existentes Crear descripciones de los CU de Trazo Grueso Definir Prioridades y Seleccionar CU de la Primera Iteración (imprescindible, importante y deseable) Escribir los CU de Trazo Fino y crear Prototipos de Interfaces Prof. Lubiza Osío

40 Reglas para el uso de los Casos de Uso
1) Un Gráfico de C.U. no debe mostrar mas de 15 casos 2) La partición de los Gráficos puede realizarse por actor 3) Si las relaciones de INCLUYE y EXTENSION entran en el diagrama principal, sin dejar de cumplir la regla 1), deben dejarse allí 4) Si las relaciones de INCLUYE no entran en el diagrama principal, se deben mostrar en un gráfico teniendo en cuenta mostrar todos los C.U. que usan dicho caso 5) Cuando un C.U. es usado por gran parte de los C.U. existentes, no debe mostrarse en el gráfico principal Prof. Lubiza Osío

41 La diferencia entre Casos de Uso y Eventos:
Describen que Hace el sistema cuando el evento ocurre Describen el dialogo entre el Sistema y el Usuario Son “atómicos”: reciben una entrada, la procesan y generan una salida Se “prolongan a lo largo del tiempo” mientras dure la interacción del usuario con sistema Lo importante son los datos de entrada o salida del Sistema mientras ocurre el evento La importancia del detalle de información que se intercambia es secundaria Prof. Lubiza Osío

42 Ejemplo de Desarrollo en Magistral
Supongamos que se requiere desarrollar el control de una máquina de entrega de café automática (Nescafe). La máquina debe permitir a una persona depositar una cantidad de dinero en billetes de 500, 1000 o 2000 Bs. Escoger uno de los productos de acuerdo a su precio (capuchino, mokachino o late). Escoger (si es pertinente) un nivel de azúcar, entregar el producto y el vuelto. El dinero que los usuarios introducen se guarda en un recipiente aparte al disponible para vuelto, el cual se encuentra ordenado por denominación. Existen estados de error de la máquina, cuando detecta un mal funcionamiento, no existencia de vuelto o inexistencia de ingredientes. Por lo cual la máquina se apaga. El usuario puede en cualquier momento antes de escoger el azúcar cancelar la operación, mediante un botón existente para este objetivo. Prof. Lubiza Osío