concluciones del trabajo

En la especificación del UML podemos comprobar que una de las partes que lo componen es un meta modelo formal. Un metamodelo es un modelo que define el lenguaje para expresar otros modelos. Un modelo en OO es una abstracción cerrada semánticamente de un sistema y un sistema es una colección de unidades conectadas que son organizadas para realizar un propósito específico. Un sistema puede ser descripto por uno o más modelos, posiblemente desde distintos puntos de vista.

Una parte del UML define, entonces, una abstracción con significado de un lenguaje para expresar otros modelos (es decir, otras abstracciones de un sistema, o conjunto de unidades conectadas que se organizan para conseguir un propósito). Lo que en principio puede parecer complicado no lo es tanto si pensamos que uno de los objetivos del UML es llegar a convertirse en una manera de definir modelos, no sólo establecer una forma de modelo, de esta forma simplemente estamos diciendo que UML, además, define un lenguaje con el que podemos abstraer cualquier tipo de modelo.

El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación.

Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del original y por lo tanto facilita dicha comprensión.

Los modelos se utilizan en muchas actividades de la vida humana: antes de construir una casa el arquitecto utiliza un plano, los músicos representan la música en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de empezar a utilizar los óleos, etc. Unos y otros abstraen una realidad compleja sobre unos bocetos, modelos al fin y al cabo. La OMT, por ejemplo, intenta abstraer la realidad utilizando tres clases de modelos OO: el modelo de objetos, que describe la estructura estática; el modelo dinámico, con el que describe las relaciones temporales entre objetos; y el modelo funcional que describe las relaciones funcionales entre valores. Mediante estas tres fases de construcción de modelos, se consigue una abstracción de la realidad que tiene en sí misma información sobre las principales características de ésta.

Los modelos además, al no ser una representación que incluya todos los detalles de los originales, permiten probar más fácilmente los sistemas que modelan y determinar los errores. Según se indica en la Metodología OMT (Rumbaugh), los modelos permiten una mejor comunicación con el cliente por distintas razones:

Es posible enseñar al cliente una posible aproximación de lo que será el producto final.
Proporcionan una primera aproximación al problema que permite visualizar cómo quedará el resultado.
Reducen la complejidad del original en subconjuntos que son fácilmente tratables por separado.

 Se consigue un modelo completo de la realidad cuando el modelo captura los aspectos importantes del problema y omite el resto. Los lenguajes de programación que estamos acostumbrados a utilizar no son adecuados para realizar modelos completos de sistemas reales porque necesitan una especificación total con detalles que no son importantes para el algoritmo que están implementando. En OMT se modela un sistema desde tres puntos de vista diferentes donde cada uno representa una parte del sistema y una unión lo describe de forma completa. En esta técnica de modelado se utilizó una aproximación al proceso de implementación de software habitual donde se utilizan estructuras de datos (modelo de objetos), las operaciones que se realizan con ellos tienen una secuencia en el tiempo (modelo dinámico) y se realiza una transformación sobre sus valores (modelo funcional).

UML utiliza parte de este planteamiento obteniendo distintos puntos de vista de la realidad que modela mediante los distintos tipos de diagramas que posee. Con la creación del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea informático o no, mediante los diagramas, es decir, mediante representaciones gráficas que contienen toda la información relevante del sistema. Un diagrama es una representación gráfica de una colección de elementos del modelo, que habitualmente toma forma de grafo donde los arcos que conectan sus vértices son las relaciones entre los objetos y los vértices se corresponden con los elementos del modelo. Los distintos puntos de vista de un sistema real que se quieren representar para obtener el modelo se dibuja dé forma que se resaltan los detalles necesarios para entender el sistema.

recomendaciones para un modelado en uml

la primera recomendación que para mi gusto es una de las mejores es el software libre dia.

 

Ventajas del Software Libre

• Libre Uso. Cualquier persona puede disponer del software libre bajo las condiciones de la licencia.  
• Bajo Costo. Es gratuito.  
• Existe Libertad de Conocimiento y trabajo cooperativo entre sus usuarios lo que permite una mayor innovación tecnológica.
• Rápida corrección de errores facilitado por el trabajo comunitario a través de Internet y de su libre acceso al código fuente.
• Total independencia de un proveedor. El usuario puede administrar libremente su crecimiento y operación con total autonomía.
• Independencia de las condiciones del mercado. A salvo de cambios drásticos por parte del proveedor o modificaciones que realice por las condiciones del mercado o baja rentabilidad.
• Contribuye a la formación de profesionales y el desarrollo de la industria local, generando conocimiento y trabajo).
• Facilidad para personalizar el software de acuerdo a las necesidades del usuario.
• Posibilidad de traducir el mismo a cualquier idioma, inclusive a una lengua regional o indígena.
• Independencia tecnológica de los Estados con respecto a grandes grupos económicos.
• Fácil acceso por parte del sector educativo público y privado.
• Mayor seguridad y privacidad de los datos. Disminuye los riesgos de filtración, aumenta la imposibilidad de acceso y manipulación de los datos críticos del Estado.
• Asegura la durabilidad de la información y su migración, gracias al acceso al código fuente.
• Disminuye los riesgos de "puertas traseras" que introduzcan códigos maliciosos o de espionaje.
• El conocimiento de códigos fuente permite la rápida solución a funcionamientos erróneos.
• Elimina el sistema operativo monousuario. Ya que permite el uso y trabajo de varios usuarios al mismo tiempo.
• Elimina el derecho exclusivo de la innovación.
• Abre la posibilidad del trabajo compartido entre diferentes empresas o dependencias de gobierno.
• Elimina la inseguridad ante cierre de compañías de provisión o discontinuidad del producto.
• No depende de prácticas monopólicas.

Desventajas del Software Libre

1. Dificultad en el intercambio de archivos (doc. de texto), dan errores o se pierden datos.
2. Mayor dificultad en la instalación y migración de datos para el usuario común.
3. Desconocimiento. El usuario común está muy familiarizado con los soportes de Microsoft, lo que hace elevar el costo de aprendizaje.
4. Ausencia de garantía. El software libre no se hace responsable por los daños.
5. Para su configuración se requieren conocimientos previos de funcionamiento del sistema operativo.
6. Por lo general para su implementación se necesitan conocimiento previo de programación.
7. Se debe monitorear en forma constante la corrección de errores por Internet.
8. No existe un control de calidad previo.
9. Hay aplicaciones específicas que no se encuentran en el software libre.
10. Baja expansión de su uso en centros educativos.
11. Baja difusión en publicaciones.
12. En ambientes de red todavía hay software propietario con mejores desempeños.

 

la segunda recomendación de un software libre es el software llamado ARGO UML es una aplicación de diagramado de UML escrita en Java y publicada bajo la Licencia BSD. Dado que es una aplicación Java, está disponible en cualquier plataforma soportada por Java.

 

El Magazine de Desarrollo de Software entrega premios anuales a herramientas de desarrollo de software populares en varias categorías. En 2003 ArgoUML fue una de las finalistas en la categoría "Design and Analysis Tools". ArgoUML recibió un premio "runner-up"(revelación), derrotando a muchas herramientas comerciales.

Características

1. Nuevas Características en V0.20:
2. UML 1.4 - Características de extensibilidad mejoradas de UML 1.4
3. Diagramas de Secuencia
4. Compatibilidad AndroMDA
5. Calidad - Cientos de bugs han sido arreglados.
6. La mayoría de las funciones ahora soportan la selección múltiple de los elementos del modelo.
7. Arrastrar y soltar desde el árbol de exploración al diagrama y dentro del árbol de exploración.

Otras características:

• Construido en diseños críticos suministra una revisión no obstructiva del diseño y sugerencias para mejoras.
• Interfaz de módulos Extensible.
• Soporte de Internacionalización para Inglés, Alemán, Francés, Español y Ruso.
• Restricciones OCL para Clases.
• Soporte para el lenguaje de generación de Código: Java, PHP, Python, C++ y Csharp (C#)
• Ingeniería inversa
• Disposición(layout) automática del diagrama de clases.
• Generación de ficheros PNG, GIF, JPG, SVG, EPS desde diagramas.
• Soporte para comentarios para múltiples elementos.
• Todos los diagramas 1.4 están soportados.

ArgoUml maneja los siguientes tipos de diagrama:

• Clases
• Estados
• Casos de Uso
• Actividad
• Colaboración
• Desarrollo
• Secuencia

DESVENTAJAS

• No tiene botón "deshacer".
• Los Modelos a veces no pueden ser re-abiertos.
• Import/Export a Java.
• No hay llamadas-reflexivas en los diagramas de secuencia--> si existen las llamadas reflexivas, es un poco complejo hacerlas, pero sí se pueden, se hacen al tomar una acción, partir desde el objeto que se quiere reflexivo, generar 2 puntos (como haciendo un cuadrado) fuera del objeto y luego volviendo al objeto.
• Al mover una clase las relaciones no se mueven de forma correcta.
• Al seleccionar un área no se seleccionan las clases de relación.
• Debes de crear un diagrama de clases, para crear algún otro diagrama.

 

 

ejemplo (Agencia de viajes)

AGENCIA DE VIAJES

CASO DE USO

diagrama de
clases

 

diagrama de secuencia

 

 

 

diagrama de estados

 

 

diagrama de actividades

 

 

Diagrama de actividades

Elementos básicos de un diagrama de actividad

Los diagramas de actividad permiten describir como un sistema implementa su funcionalidad.

Los diagramas de actividad modelan el comportamiento dinámico de un procedimiento, transacción o caso de uso haciendo énfasis en el proceso que se lleva a cabo.

Los diagramas de actividad es uno de los elementos de modelado que son mejor comprendidos por todos, ya que son herederos directos de los diagramas de flujo.

Los diagramas de actividad son mas expresivo que los diagramas de flujo. También heredan características de: „

• Los diagramas de estado. „
• Los diagramas de flujo de datos. „ 
• Las redes de Petri.

Actividades y acciones

Una acción es un paso de un proceso que tiene la semática “run to completion” (Se inicia para ser terminado) 

Una actividad es un conjunto de acciones que modelan un proceso. No tiene la semántica “run to completion”. Una actividad se modela mediante un diagrama de actividad. 

Enjabonar, enjuagar o secar un coche son acciones de la actividad “Lavar un coche” 

Branching and merges

Las decisiones representan las alternativas de flujo de control en un diagrama que se llevan a cabo en función de una condición. 

La condiciones de guarda asociadas a cada rama de salida determinan la opción de flujo de control que se sigue. 

Las ramas de flujo de control abiertas en una o varias condiciones se cierran en un punto de convergencia (merge).

Decisiones consistentes 

La opciones de una decisión deben ser: „ 

• Completas. „ 
• No ambiguas.

Fork y Joint

Los fork y los joint se utilizan en los diagramas de actividad para describir concurrencia entre acciones o actividades.

Las líneas de flujo de salida de un fork representa líneas de ejecución que se ejecutan concurrentemente. 

Las líneas de flujo de entrada de un joint se sincronizan para continuar en una única línea de flujo. 

Todas la acciones de las líneas de flujo previas a un joint deben completarse antes de que se ejecute la primera acción de la línea posterior a él. 

Time events

Los eventos de tiempo modelan: „ 

• Activaciones temporizadas. „ 
• Timeouts „ 
• Retrasos. „ 

Un evento de tiempo puede ser el inicio de una actividad.

Un evento temporizado con flujo de entrada representa una única activación tras llegarle el flujo.

Un evento de tiempo sin flujo de entrada representa una activación que puede ser repetida en el tiempo. 

Calling other activities

Objects 

En un diagrama de actividad se pueden representar los objetos de datos que se generan, se consumen o se intercambian en un proceso y que son relevantes para su descripción. 

Cuando un objeto de datos se representan como una caja, significa que esos datos existen en el punto de flujo de control en que se insertan. 

Cuando un objeto de datos se representa mediante unos pines asociados a las acciones o actividades, representan objetos de datos de entrada o de salida. 

Sending and receiving signals

En un diagrama de actividad las señales representan interacciones del proceso que se Describe con operadores sistemas u otros procesos externos a él. 

• Cuando un receptor de señales tiene flujo de entrada representa que cuando el flujo le llega se habilita para aceptar una única señal. 

• Cuando no tiene flujo de entrada, representa que puede aceptar uno o muchas señales. 

Starting an activity

Una actividad se puede iniciar por: „ 

• Cuando se invoca de forma regular: se representa mediante un circulo. „ 
• Cuando se recibe un objeto de dato de entrada „ 
• Cuando se produce un evento temporizado „ 
• Cuando se recibe una señal externa.

Interrupting an activity

Una actividad de duración no atómica puede concluirse por la ocurrencia de un evento o una señal externa. Para ello se define una región de interrupción mediante una línea que engloba las actividades o acciones que pueden ser interrumpidas por el evento o señal que también se incluye en la región.

Partitions or swinglanes

Los swinglanes representan los procesos, participantes o elementos responsables de ejecutar un conjunto de acciones.

Diagrama de estados

Los diagramas de máquinas de estado son útiles para describir el comportamiento de clases y sistemas que han sido concebidos haciendo uso de un modelo de estados. En un modelo de estados se identifican las situaciones en la que el comportamiento o capacidad de respuesta con cualitativamente diferentes, así como los eventos o condiciones bajos las que se pasa de una situación a otra (transiciones de estados).

 Los diagramas de estados son intensivamente utilizados en: „ 

• Sistemas de tiempo real y críticos. „ 
• La descripción de sistemas reactivos. 
• „La descripción de sistemas basados en protocolos

Un estado puede cualificarse: „ 

• Estáticamente en función del valor que tienen sus atributos. „
•  Dinámicamente, esto es en función de la actividad que ejecuta.

Comportamiento completo de un estado

El comportamiento describe las acciones que se producen mientras que el sistema se encuentra en un estado:

• entrry/behavior => Acción que se realiza cuando se llega a un estado. 

• do/behavior => Actividad que se ejecuta mientras se está en un estado. 

• Exit/behavior => Acciones que se ejecuta cuando se abandona un estado. 

• Transiciones internas => Se formulan como trigger[guard]/behavior.

Transiciones

Una transición representa las causas circunstancias y efectos de un cambio entre dos estados. 

Una transacción tiene un nombre y una descripción completa del tipo trigger[guard]/behavior :

•  „Trigger: Es el evento que da origen a una transición. „ 
• Guard:Es una función booleana que esevaluada cuando ocurre el trigger. Si es True la transición se produce. Si vale False la transición no ocurre. „ 
• Behavior: Es una acción ininterrumpible que tiene lugar cuando se produce la transición.

Múltiples transiciones

La posibles combinación de triggers y condiciones de guardas dan lugar a diferentes conjuntos de transiciones entre estados:

Si una transición no tiene trigger ni guarda, la transición se produce por finalización de la actividad asociada al estado.

Trigger, guardas y repuesta en programas

Es muy frecuente cuando se modela software que: „ 

• El trigger puede ser la invocación de un metodo de la clase modelada. „ 
• La guarda es la invocación de un metodo booleano o una relación entre los atributos. „ 
• La respuesta puede ser la invocación de un metodo sobre el propio objeto o sobre un objeto al que tenga acceso.

Estados compuestos

UML permite que varias máquinas de estados se asocien a una misma clase o sistema. Su situación puede estar descrita en un mismo instante por varios estados, cada uno de ellos pertenecientes a diferentes máquinas.  

Un estado de inicio histórico asociado a una región de estado representa que cuando se accede a la región se accede al estado en que se encontraba la región cuando se abandonó.

Pseudoestados

Recepción y transmisión de señales

Máquinas de estados de protocolo

Una máquina de estados de protocolos es un tipo especial de máquina de estados que se utiliza para describir un protocolo de interacción. 

No describe el comportamiento asociado a los estados y a las transiciones. 

Resalta las secuencias de estados que son posibles y los eventos que dan lugar a esas transiciones. 

Se representa en una caja rectangular con una pestaña que contiene el estereotipo <<protocolo>>

Diagrama de secuencia

Utilidad
Un de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Tipos de mensajes
Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas

De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).
Genérico: describe la interacción para un caso de uso. Utiliza ramificaciones ("Branches"), condiciones y bucles.

Estructura
Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado o invocado pertenece al objeto receptor del mensaje.

Diagrama de clases

¿Qué es un diagrama de clases?
Un diagrama de clases es una representación gráfica que sirve para representar la estructura de un sistema que será implementado utilizando un lenguaje orientado a objetos. Los diagramas de clases se realizan en la fase de diseño del software después de la fase de requisitos. La idea de estos diagramas es representar las clases que tendrá el sistema así como su contenido y sus relaciones con otras clases. La implementación de sistemas medianamente grandes no sería abordable sin este tipo de diagramas, y aunque fuera abordable se tardaría mucho más y sería más fácil cometer errores.

Componentes de un diagrama de clases
Los componentes que describiré son los que se incluyen en UML(Unified Modeling Language) que es el lenguaje de modelado más extendido y más usado en todo el mundo.

Clase
Este es el elemento básico del diagrama de clases. Las clases representan entidades o conceptos. Normalmente cada vez que aparece un sustantivo en un documento de descripción de un sistema ese sustantivo es una clase. En cada clase se definen los atributos y métodos que tendrán los objetos de esa clase. La siguiente imagen es un ejemplo de representación de una clase.

Atributos y métodos
Los atributos y los métodos se muestran con su nombre además de su tipo. En el caso de los métodos también se muestra el tipo de retorno en caso de que retorne algo y el nombre y tipo de sus parámetros. Los atributos pueden tener un valor inicial. Además, los símbolos que se encuentran antes del nombre de los atributos y métodos representan la visibilidad de éstos:

El símbolo – representa atributos privados.
El símbolo + representa atributos públicos.
El símbolo # representa atributos protegidos.

Relaciones
Como he dicho antes las clases se relacionan con otras. En cada relación aparece el nombre del atributo que se usará para representar esa relación y la multiplicidad. Las relaciones que existen son las siguientes: 

Generalización: Esta relación representa la herencia o la extensión de una clase de otra. En la siguiente imagen podemos ver un ejemplo.

 
Asociación: Representa una relación básica entre dos clases. Pueden ser unidireccionales (sólo una de las clases conoce a la otra) o bidireccionales (ambas clases tienen conocimiento de la otra). En la siguiente imagen podemos ver un ejemplo. La primera es una asociación bidireccional que representa que un curso tiene desde 1 hasta varios alumnos y que un alumno puede estar en 0 o varios cursos. La segunda es una asociación unidireccional que representa que una asignatura tiene un único profesor responsable. 

Agregación: Es un tipo de asociación con la que se representa que cada objeto de una de las clases contiene objetos de la otra clase. El objeto contenedor seguirá existiendo aunque los objetos contenidos dejen de existir. 

Composición: Es un tipo de asociación, pero podemos decir que son agregaciones fuertes. La diferencia con las agregaciones es que no tiene sentido que el objeto contenedor siga existiendo si no existen los objetos contenidos.

Narrativa Caso de Uso

El caso de uso se puede ver como un documento narrativo que describe la secuencia de eventos de un actor que utiliza un sistema para completar un proceso. Los casos de uso son historias o casos de utilización de un sistema; no son exactamente los requerimientos ni las especificaciones funcionales, sino que ejemplifican e incluyen los requerimientos en las historias que narran. El siguiente ejemplo corresponde a un caso de uso de alto nivel, que describe clara y concisamente el proceso de comprar artículos en una tienda cuando se emplea una caja una caja registradora en el punto de venta.

La explicación del formato es: 

· Caso de uso: nombre del caso de uso.

· Actores: lista de actores en la que se indica quién inicia el caso de uso. 

· Tipo: que puede ser Primario, Secundario, Opcional, entre otros.

· Descripción: repetición del caso de uso de alto nivel o alguna síntesis similar.

· Propósito: intención del caso de uso.

· Referencias Cruzadas: casos de uso y funciones relacionadas con el sistema. 

· Curso Normal de los Eventos: es la parte medular del formato expandido; describe los detalles de la conversión interactiva entre los actores y el sistema. Un aspecto esencial de la sección es explicar la secuencia más común de eventos: la historia normal de las actividades y el término exitoso de un proceso. No incluye situaciones alternativas. 

· Cursos Alternativos: describe importantes opciones o excepciones que pueden presentarse en relación al curso normal. Si son éstas son complejas, se pueden expandir y convertir en nuevos casos de uso.

Actores(caso de uso)

Un actor es una agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema que estamos construyendo de la misma forma.

Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos empezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer objetivo de todo analista, ya que un proyecto sin alcance definido nunca podrá alcanzar sus objetivos.

Es importante tener clara la diferencia entre usuario y actor. Un actor es una clase de rol, mientras que un usuario es una persona que, cuando usa el sistema, asume un rol. De esta forma, un usuario puede acceder al sistema como distintos actores. La forma más simple de entender esto es pensar en perfiles de usuario de un sistema operativo. Una misma persona puede acceder al sistema con distintos perfiles, que le permiten hacer cosas distintas. Los perfiles son en este caso equivalentes a los actores.

Otro sistema que interactúa con el que estamos construyendo también es un actor. Por ejemplo, si nuestro sistema deberá generar asientos contables para ser procesados por el sistema de contabilidad, este último sistema será un actor, que usa los servicios de nuestro sistema.

Los Casos de Uso y UML

A partir de la publicación del libro de Jacobson, gran parte de los más reconocidos especialistas en métodos Orientados a Objetos coincidieron en considerar a los casos de uso como una excelente forma de especificar el comportamiento externo de un sistema. De esta forma, la notación de los casos de uso fue incorporada al lenguaje estándar de modelado UML –Unified Modelling Language– propuesto por Ivar Jacobson, James Rumbaugh y Grady Booch, tres de los precursores de las metodologías de Análisis y Diseño Orientado a Objetos, y avalado por las principales empresas que desarrollan software en el mundo. UML va en camino de convertirse en un estándar para modelado de sistemas de software de amplia difusión.

A pesar de ser considerada una técnica de Análisis Orientado a Objetos, es importante destacar que los casos de uso poco tienen que ver con entender a un sistema como un conjunto de objetos que interactúan, que es la premisa básica del análisis orientado a objetos “clásico”. En este sentido, el éxito de los casos de uso no hace más que dar la razón al análisis estructurado, que propone que la mejor forma de empezar a entender un sistema es a partir de los servicios o funciones que ofrece a su entorno, independientemente de los objetos que interactúan dentro del sistema para proveerlos.

Como era de esperar, es probable que en el futuro los métodos de análisis y diseño que prevalezcan hayan adoptado las principales ventajas de todos los métodos disponibles en la actualidad (estructurados, métodos formales, métodos orientados a objetos, etc.).

De lo dicho anteriormente podemos concluir que los casos de uso son independientes del método de diseño que se utilice, y por lo tanto del método de programación. Luego de documentar los requerimientos de un sistema con casos de uso, se puede diseñar un sistema “estructurado” (manteniendo una separación entre datos y funciones), o un sistema Orientado a Objetos, sin que la técnica sea de mayor o menor utilidad en alguno de los dos casos. Esto da más flexibilidad al método, y probablemente contribuya a su éxito.

Historia casos de uso

Los Casos de Uso fueron introducidos por Jacobson en 1992 [Jacobson92]. Sin embargo, la idea de especificar un sistema a partir de su interacción con el entorno es original de Mc Menamin y Palmer, dos precursores del análisis estructurado, que escribieron en 1984 un excelente libro cuya lectura recomendamos [McMenamin84]. En ese libro, se define un concepto muy parecido al del caso de uso: el evento. Para Mc Menamin y Palmer, un evento es algo que ocurre fuera de los límites del sistema, ante lo cual el sistema debe responder. Siguiendo con nuestro ejemplo anterior, nuestro sistema de ventas tendrá un evento “Cliente hace Pedido”. En este caso el sistema deberá responder al estimulo que recibe procesándolo.

Sin embargo, existen algunas diferencias entre los casos de uso y los eventos. Las principales son:

 1) Los eventos se centran en describir qué hace el sistema cuando el evento ocurre, mientras que los casos de uso se centran en describir cómo es el diálogo entre el usuario y el sistema.

2) Los eventos son “atómicos”: se recibe una entrada, se la procesa, y se genera una salida, mientras que los casos de uso se prolongan a lo largo del tiempo mientras dure la interacción del usuario con el sistema. De esta forma, un caso de uso puede agrupar a varios eventos.

3) Para los eventos, lo importante es qué datos ingresan al sistema o salen de él cuando ocurre el evento (estos datos se llaman datos esenciales), mientras que para los casos de uso la importancia del detalle sobre la información que se intercambia es secundaria. Según esta técnica, ya habrá tiempo más adelante en el desarrollo del sistema para ocuparse de este tema.

Los casos de uso combinan el concepto de evento del análisis estructurado con otra técnica de especificación de requerimientos bastante poco difundida: aquella que dice que una buena forma de expresar los requerimientos de un sistema es escribir su manual de usuario antes de construirlo. Esta técnica, si bien ganó pocos adeptos, se basa en un concepto muy interesante: al definir requerimientos, es importante describir al sistema desde el punto de vista de aquél que lo va a usar, y no desde el punto de vista del que lo va a construir. De esta forma, es más fácil validar que los requerimientos documentados son los verdaderos requerimientos de los usuarios, ya que éstos comprenderán fácilmente la forma en la que están expresados.

Casos de uso

¿Que son los casos de uso?
Los casos de usos son una técnica para especificar el comportamiento de un sistema.
"Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios" 

Todo sistema de software ofrece a su entorno una serie de servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos "alguien o algo" hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software.

Qué proporciona UML

Proporciona un vocabulario y las reglas para utilizarlo para así tener una representación conceptual y física de un sistema.

Introducción

UML es un lenguaje con un alcance muy grande y que cubre diversos conjuntos de dominios arquitectónicos en el diseño de aplicaciones.
Por ello, no todas sus capacidades de modelados son necesariamente útiles en todos los dominios o aplicaciones.
UML permite seleccionar sólo aquellas partes del lenguaje que sean realmente útiles.

Introducción a UML

Se presentará la revision 2 del OMG (Object Management Group) de noviembre de 2007.
• UML: Unified Modeling Language.

• El objetivo de UML es “proporcionar a desarrolladores de software, arquitectos de sistemas e ingenieros de software de herramientas para el análisis, diseño e implementación de sistemas basados en software, así como modelar procesos de negocio y similares .

• El modelado captura las partes esenciales del sistema.

UML es un lenguaje con un alcance muy grande y que cubre diversos conjuntos de dominios arquitectónicos en el diseño de aplicaciones.
• Por ello, no todas sus capacidades de modelados son necesariamente útiles en todos los dominios o aplicaciones.

• UML permite seleccionar sólo aquellas partes del lenguaje que sean realmente útiles.

• “El 80 por ciento de la mayoría de los problemas pueden modelarse usando alrededor del 20 por ciento de UML” - Grady Booch Modelado.

Modelado
• Busca representar los planos del software.

• El modelado es la espina dorsal del desarrollo de software de calidad.

• Modelo: Simplificación de la realidad.

• UML busca
     – Visualizar cómo es o queremos que sea un sistema.
     – Especificar la estructura o el comportamiento de un sistema.
     – Proporcionar plantillas que nos guíen en la construcción de un sistema.
     – Documentar las decisiones que hemos adoptado.
Modelado (II) 
• Principios básicos del modelado.
     – Seleccionar el modelo adecuado para cada momento, y dependiendo de qué modelo se elija se obtendrán diferentes beneficios y diferentes costes.

• El modelado orientado a objetos proporciona sistemas más flexibles y readaptables.
     – Todo modelo puede ser expresado en base a diferentes niveles de precisión.
     – Obtener modelos que representen la realidad lo más claramente posible.
     – Un único modelo no es suficiente.

Caratula

Universidad Latina campus sur.
Proyecto Final.
Informática IV.
Maestra: Adriana Vega Palos.
Alumno: Octavio Santiesteban.
Fecha de entrega: 13 de mayo del 2016.