UNIVERSIDAD YACAMBU
MINISTERIO DE
EDUCACION
DIRECCION DE
INVESTIGACION Y POSTGRADOS VIRTUALES
GERENCIA
Asignatura: Análisis y
Diseño de Sistemas
Trabajo 1
Integrantes: Pérez
Isilrobert José
Feliana Ochoa
- Introducción
- Para que sirve UML
- Modelos o Diagramas que contiene, Descripción, Características,
Ejemplos.
- Utilidad de cada uno de los Diagramas.
- Herramientas de Software que apoyan el modelo UML. Ejemplos y
demos.
- Caso Práctico. Aplicar el diagrama de casos de uso a una
problemática presentada en su empresa.
- Conclusiones
1 Introducción
Durante los
ochenta y principios de los noventa Grady Booch, James Rumbaugh, e Ivar
Jacobson trabajaban por separado en desarrollo de notaciones para el análisis y
diseño de sistemas orientados a objetos. Los tres llegaron por separado a
obtener bastante reconocimiento.
Booch había escrito "Object-Oriented
Analysis and Design with Applications
" un
libro de referencia en el análisis y diseño orientado a objetos desarrollando
su propia notación.
Por su parte James
Rumbaugh había desarrollado su propia notación de diseño orientado a
objetos llamada OMT (Object Modeling Technique) en su libro "Object-Oriented
Modeling and Design".
Por otro lado Jacobson
se había revelado como un visionario del análisis (padre de los casos de uso) y
sobre todo del diseño orientado a objetos, sorprendiendo a todo el mundo en
"Object-Oriented
Software Engineering: A Use Case Driven Approach".
A mediados de
los noventa empezaron a intercambiar documentos y trabajar en conjunto
produciendo grandes avances en el modelado de sistemas orientados a objetos.
En 1994
Rational contrató a Rumbaugh en donde ya trabajaba Booch, un año después
Jacobson se unía a ellos en Rational.
En 1997 salió a
la luz la versión 1.0 de UML.
2.)
Para que sirve UML
El lenguaje unificado de diagrama o notación (UML) sirve para especificar, visualizar y documentar esquemas de sistemas de software orientado a objetos. UML no es un método de desarrollo, lo que significa que no sirve para determinar qué hacer en primer lugar o cómo diseñar el sistema, sino que simplemente le ayuda a visualizar el diseño y a hacerlo más accesible para otros. UML está controlado por el grupo de administración de objetos (OMG) y es el estándar de descripción de esquemas de software.
UML está diseñado para su uso con software orientado a objetos, y tiene un uso limitado en otro tipo de cuestiones de programación.
También
se encuentra lo siguiente:
Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables.
Es importante resaltar que UML es un "lenguaje" para especificar y no para describir métodos o procesos. Se utiliza para definir un sistema de software, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en una gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa (Lengua de Modelación Unificada), no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la orientación a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
3.) Modelos o Diagramas de UML,
descripción y características, ejemplos.
En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil categorizarlos jerárquicamente, como se muestra en la figura de la derecha.
Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:
·
Diagrama de estructura compuesta (UML 2.0)
Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:
Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:
·
Diagrama de tiempos
(UML 2.0)
·
Diagrama de vista de interacción (UML 2.0)
Para tener una visión más amplia de cada diagrama es
importante mencionar las características y elementos que los conforman, por lo
tanto tenemos:
Diagramas
Uso-Caso
Definición
y Usos
Un diagrama Uso-Caso describe lo que hace un sistema
desde el punto de vista de un observador externo, debido a esto, un diagrama de
este tipo generalmente es de los más sencillos de interpretar en UML, ya que su
razón de ser se concentra en un Que hace el sistema, a
diferencia de otros diagramas UML que intentan dar respuesta a un Como
logra su comportamiento el sistema.
Un Uso-Caso esta muy relacionado con lo que pudiera
ser considerado un escenario en el sistema, esto es, lo que ocurre cuando
alguien interactúa con el sistema: "Acude un mesero a colocar la orden,
la orden es tomada por el cocinero, y posteriormente se abona a la cuenta del
cliente el cargo".
Un Uso-Caso es empleado con más frecuencia en alguna
de las siguientes etapas:
·
Determinación de
Requerimientos: Por lo general nuevos requerimientos de sistema generan nuevos
usos-casos, conforme es analizado y diseñado el sistema.
·
Comunicación con
el Cliente: Debido a la sencillez de este tipo de diagramas, son fáciles de
emplear para comunicarse con el cliente final del proyecto.
·
Generación de
pruebas de Sistemas: A través de los diagramas uso-caso se pueden generar una
serie de pruebas de sistema.
En la siguiente sección se describen los diversos
elementos que componen un diagrama Uso-Caso.
Composición
·
Actor: Un actor representa quien o que inicia una acción
dentro del sistema, en otras palabras, es simplemente un rol que es llevado
acabo por una persona o cosa. Un Actor en un diagrama Uso-Caso es representado
por una figura en forma de persona.
·
Uso-Caso: El uso-caso en sí es representado por un ovalo que
describe la funcionalidad a grosso modo que se requiere por el sistema.
·
Comunicación: Este elemento representa la relación que existe
entre un Uso-Caso y un Actor, dicho elemento es representado simplemente por
una linea recta que se extiende de la figura del actor hacia el ovalo del
uso-caso.
·
Limite de
Sistema (System Boundry): Empleado
para delimitar los límites del sistema, y representado por un rectángulo con
color de fondo distintivo.
·
Generalización: Una generalización indica que un uso-caso (ovalo) es
un caso especial de otro caso, en otros términos, representa una relación
padre-hijo, donde el hijo puede ser suplido directamente por el padre en
cualquier momento. Este elemento es representado por una linea con flecha que
se extiende del uso-caso hijo hacia el uso caso padre (general).
·
Inclusión: Una inclusión es utilizada para indicar que un
uso-caso (ovalo) depende de otro caso, dicho de otra manera, significa que la
funcionalidad de determinado caso se requiere para realizar las tareas de otro.
Este elemento es representado por una linea punteada con flecha y comentario <<include>>
que se extiende del uso-caso base hacia el uso caso de inclusión.
·
Extensión: Una extensión representa una variación de un
uso-caso a otro, aunque similar a una generalización, una extensión
representa una dependencia especifica, mientras una generalización no implica
que los usos-casos dependen uno del otro. Este elemento es representado por una
linea punteada con flecha y comentario <<extend>>
que origina del uso-caso base hacia el uso caso de extensión.
Ilustración
|
|
Fuente: http://www.osmosislatina.com/lenguajes/uml/casos.htm
Es posible representar las ideas en UML utilizando diversos tipos de diagramas. Umbrello UML Modeller 1.2 soporta los siguientes tipos:
Diagrama de clases
Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se relacionan unas con otras. Se dice que los diagramas de clases son diagramas «estáticos» porque muestran las clases, junto con sus métodos y atributos, así como las relaciones estáticas entre ellas: qué clases «conocen» a qué otras clases o qué clases «son parte» de otras clases, pero no muestran los métodos mediante los que se invocan entre ellas.
UML Modeller mostrando un diagrama de clases
Clase
Una clase define los atributos y los métodos de una serie de objetos. Todos los objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada objetos tiene el suyo propio). En ocasiones se utiliza el término «tipo» en lugar de clase, pero recuerde que no son lo mismo, y que el término tipo tiene un significado más general.
En ¨, las clases están representadas por rectángulos, con el nombre de la clase, y también pueden mostrar atributos y operaciones de la clase en otros dos «compartimentos» dentro del rectángulo.
Representación visual de una clase en UML
Atributos
En UML, los atributos se muestran al menos con su nombre, y también pueden mostrar su tipo, valor inicial y otras propiedades. Los atributos también pueden ser mostrados visualmente:
·
+
Indica atributos públicos
·
#
Indica atributos protegidos
·
-
Indica atributos privados
Operaciones
La operaciones (métodos) también se muestran al menos con su nombre, y pueden mostrar sus parámetros y valores de retorno. Las operaciones, al igual que los atributos, se pueden mostrar visualmente:
·
+
Indica operaciones públicas
·
#
Indica operaciones protegidas
·
-
Indica operaciones privadas
Plantillas
Las clases pueden tener plantillas, un valor usado para una clase no especificada o un tipo. El tipo de plantilla se especifica cuando se inicia una clase (es decir cuando se crea un objeto). Las plantillas existen en C++ y se introducirán en Java 1.5 con el nombre de Genéricos.
Asociaciones de clases
Las clases se puede relaciones con otras de diferentes maneras:
Generalización
La herencia es uno de los conceptos fundamentales de la programación orientada a objetos, en la que una clase «recoge» todos los atributos y operaciones de la clase de la que es heredera, y puede alterar/modificar algunos de ellos, así como añadir más atributos y operaciones propias.
En UML, una asociación de generalización entre dos clases, coloca a estas en una jerarquía que representa el concepto de herencia de una clase derivada de la clase base. En UML, las generalizaciones se representan por medio de una línea que conecta las dos clases, con una flecha en el lado de la clase base.
Representación visual de una generalización en UML
Asociaciones
Una asociación representa una relación entre clases, y aporta la semántica común y la estructura de muchos tipos de «conexiones» entre objetos.
Las asociaciones son los mecanismos que permite a los objetos comunicarse entre sí. Describe la conexión entre diferentes clases (la conexión entre los objetos reales se denomina conexión de objetos o enlace).
Las asociaciones pueden tener un papel que especifica el propósito de la asociación y pueden ser unidireccionales o bidireccionales (indicando si los dos objetos participantes en la relación pueden intercambiar mensajes entre sí, o es únicamente uno de ellos el que recibe información del otro). Cada extremo de la asociación también tiene un valor de multiplicidad, que indica cuántos objetos de ese lado de la asociación están relacionados con un objeto del extremo contrario.
En UML, las
asociaciones se representan por medio de líneas que conectan las clases
participantes en la relación, y también pueden mostrar el papel y la
multiplicidad de cada uno de los participantes. La multiplicidad se muestra
como un rango [mín...máx] de valores no negativos, con un asterisco (*) representando el infinito en el lado
máximo.
Representación visual de una asociación en UML
Acumulación
Las acumulaciones son tipos especiales de asociaciones en las que las dos clases participantes no tienen un estado igual, pero constituyen una relación «completa». Una acumulación describe cómo se compone la clase que asume el rol completo de otras clases que se encargan de las partes. En las acumulaciones, la clase que actúa como completa, tiene una multiplicidad de uno.
En UML, las acumulaciones están representadas por una asociación que muestra un rombo en uno de los lados de la clase completa.
Representación visual de una relación de acumulación en UML
Composición
Las composiciones son asociaciones que representan acumulaciones muy fuertes. Esto significa que las composiciones también forman relaciones completas, pero dichas relaciones son tan fuertes que las partes no pueden existir por sí mismas. Únicamente existen como parte del conjunto, y si este es destruido las partes también lo son.
En UML, las composiciones están representadas por un rombo sólido al lado del conjunto.
Otros cmopnentes de los diagrama de clases
Los diagramas de clases pueden contener más componentes aparte de clases.
Interfaces
Las interfaces son clases abstractas, esto es, instancias que no pueden ser creadas directamente a partir de ellas. Pueden contener operaciones, pero no atributos. Las clases pueden heredarse de las interfaces pudiendo así realizarse instancias a partir de estos diagramas.
Tipo de datos
Los tipo de datos son primitivas incluidas en algunos lenguajes de programación. Algunos ejemplos son: bool y float. No pueden tener relación con clases, pero las clases sí pueden relacionarse con ellos.
Enumeraciones
Las enumeraciones son simples listas de valores. Un ejemplo típico de esto sería una enumeración de los días de la semana. Al igual que los tipos de datos, no pueden relacionarse con las clases, pero las clases sí pueden hacerlo con ellos.
Paquetes
Los paquetes, en lenguajes de programación, representan un espacio de nombres en un diagrama se emplean para representar partes del sistema que contienen más de una clase, incluso cientos de ellas.
Diagramas de secuencia
Los diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en que se invocan) en un momento dado. Los diagramas de secuencia ponen especial énfasis en el orden y el momento en que se envían los mensajes a los objetos.
En los diagramas de secuencia, los objetos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operación y los parámetros.
Umbrello UML Modeller mostrando un diagrama de secuencia
Los mensajes pueden ser o bien síncronos, el tipo normal de llamada del mensaje donde se pasa el control a objeto llamado hasta que el método finalize, o asíncronos donde se devuelve el control directamente al objeto que realiza la llamada. Los mensajes síncronos tienen una caja vertical en un lateral del objeto invocante que muestra el flujo del control del programa.
Diagramas de colaboración
Los diagramas de colaboración muestran las interacciones que ocurren entre los objetos que participan en una situación determinada. Esta es más o menos la misma información que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los diagramas de colaboración fijan el interés en las relaciones entre los objetos y su topología.
En los diagramas de colaboración los mensajes enviados de un objeto a otro se representan mediante flechas, mostrando el nombre del mensaje, los parámetros y la secuencia del mensaje. Los diagramas de colaboración están indicados para mostrar una situación o flujo programa específicos y son unos de los mejores tipos de diagramas para demostrar o explicar rápidamente un proceso dentro de la lógica del programa.
Umbrello UML Modeller mostrando un diagrama de colaboración
Diagrama de estado
Los diagramas de estado muestran los diferentes estados de un objeto durante su vida, y los estímulos que provocan los cambios de estado en un objeto.
Los diagramas de estado ven a los objetos como máquinas de estado o autómatas finitos que pueden estar en un conjunto de estados finitos y que pueden cambiar su estado a través de un estímulo perteneciente a un conjunto finito. Por ejemplo, un objeto de tipo NetServer puede tener durante su vida uno de los siguientes estados:
· Listo
· Escuchando
· Trabajando
· Detenido
y los eventos que pueden producir que el objeto cambie de estado son
· Se crea el objeto
· El objeto recibe un mensaje de escucha
· Un cliente solicita una conexión a través de la red
· Un cliente finaliza una solicitud
· La solicitud se ejecuta y ser termina
· El objeto recibe un mensaje de detención
Umbrello UML Modeller mostrando un diagrama de estado
Estado
Los estados son los ladrillos de los diagramas de estado. Un estado pertenece a exactamente una clase y representa un resumen de los valores y atributos que puede tener la clase. Un estado UML describe el estado interno de un objeto de una clase particular
Tenga en cuenta que no todos los cambios en los atributos de un objeto deben estar representados por estados, sino únicamente aquellos cambios que pueden afectar significativamente a la forma de funcionamiento del objeto
Hay dos tipos especiales de estados: inicio y fin. Son especiales en el sentido de que no hay ningún evento que pueda devolver a un objeto a su estado de inicio, y de la misma forma no hay ningún evento que pueda sacar a un objeto de su estado de fin.
Diagrama de actividad
Los diagramas de actividad describen la secuencia de las actividades en un sistema. Los diagramas de actividad son una forma especial de los diagramas de estado, que únicamente (o mayormente) contienen actividades.
Umbrello UML Modeller mostrando un diagrama de actividad
Los diagramas de actividad son similares a los diagramas de flujo procesales, con la diferencia de que todas las actividades están claramente unidas a objetos.
Los diagramas de actividad siempre están asociados a una clase, a una operación o a un caso de uso.
Los diagramas de actividad soportan actividades tanto secuenciales como paralelas. La ejecución paralela se representa por medio de iconos de fork/espera, y en el caso de las actividades paralelas, no importa en qué orden sean invocadas (pueden ser ejecutadas simultáneamente o una detrás de otra).
Actividad
Una actividad es un único paso de un proceso. Una activa es un estado del sistema que actividad interna y, al menos, una transición saliente. Las actividades también pueden tener más de una transición saliente, si tienen diferentes condiciones.
Las actividades pueden formar jerarquías, lo que significa que una actividad puede estar formada de varias actividades «de detalle», en cuyo caso las transiciones entrantes y salientes deberían coincidir con las del diagrama de detalle.
Elementos de ayuda
Existen unos pocos elementos en UML que no tiene un valor semántico real en la maqueta, pero que ayudan a clarificar partes del programa. Estos elementos son
· Línea de texto
· Notas de texto y enlaces
· Cajas
Las líneas de texto son útiles para añadir información textual a un diagrama. Es texto es libre y no tiene ningún significado para la maqueta.
Las notas son útiles para añadir información más detallada de un objeto o una situación específica. Tienen la gran ventaja de que se pueden anclar a los elementos UML para mostrar que una nota «pertenece» a un objeto o situación específicos
Las cajas son rectángulos repartidos libremente que pueden usarse para juntar objetos haciendo los diagramas más legibles. No tienen significado lógico en la maqueta
Diagramas de componentes
Los diagramas de componentes muestran los componentes del software (ya sea las tecnologías que lo forman como Kparts, componentes CORBA, Java Beans o simplemente secciones del sistema claramente distintas) y los artilugios de que está compuesto como los archivos de código fuente, las librerías o las tablas de una base de datos.
Los componentes pueden tener interfaces (es decir clases abstractas con operaciones) que permiten asociaciones entre componentes.
Diagramas de implementación
Los diagramas de implementación muestran las instancias existentes al ejecutarse así como sus relaciones. También se representan los nodos que identifican recursos físicos, típicamente un ordenador así como interfaces y objetos (instancias de las clases).
Diagramas de relación de entidad
Los diagramas de relaciones de entidad (diagramas ER) muestran el diseño conceptual de las aplicaciones de bases de datos. Representan varias entidades (conceptos) en el sistema de información y las relaciones y restricciones existentes entre ellas. Una extensión de los diagramas de relaciones de entidad llamado «diagramas de relaciones de entidad extendida» o «diagramas de relaciones de entidad mejoradas» (EER), se utiliza para incorporar las técnicas de diseño orientadas a objetos en los diagramas ER.
Umbrello mostrando un diagrama de relaciones de entidad
Entidad
Una Entidad es cualquier concepto del mundo real con una existencia independiente. Puede ser un objeto con una existencia física (ejemplo, máquina, robot) o puede ser un objeto con una existencia conceptual (p. ej.: Curso de universidad). Cada entidad tiene un conjunto de atributos que describen las propiedades de la entidad.
Nota: No existen notaciones estándar para representar los diagramas ER. Los diferentes textos sobre este asunto utilizan diferentes notaciones. Los conceptos y notaciones para los diagramas EER utilizados en Umbrello provienen del siguiente libro: Elmasri R. y Navathe S. (2004). Fundamentals of Database Systems 4ª ed. Addison Wesley (Fundamentos de los sistemas de bases de datos)
En un diagrama ER, las entidades se representan como rectángulos, con el nombre de la clase, y también pueden mostrar atributos y operaciones de la clase en otros dos «compartimentos» dentro del rectángulo.
Representación visual de una entidad en un diagrama ER
Atributos de la entidad
En los diagramas ER, los atributos de la entidad se muestra con su nombre en un compartimiento diferente de la entidad a la que pertenecen.
Restricciones
Las restricciones en los diagramas ER especifican las restricciones de los datos en el esquema de información.
Existen cuatro tipos de restricciones soportadas por Umbrello:
· Clave primaria: El conjunto de atributos declarados como clave primaria es única para la entidad. Solo puede haber una clave primaria en una entidad y ninguno de los atributos que la componen puede ser NULL.
· Clave única: El conjunto de atributos declarados como única son únicos para la entidad. Pueden haber muchas restricciones únicas en una entidad. Los atributos que lo componen pueden tener el valor NULL. Las claves únicas y primarias identifican de forma única una fila de una tabla (entidad)
· Clave externa: Una clave externa es una restricción referencia entre dos tablas. La clave externa identifica una columna o un conjunto de columnas en una tabla (referenciada) que referencia una columna o conjunto de columnas en otra tabla (referenciada). Las columnas en la tabla referenciada deben formar una clave primaria o una clave única.
· Restricción de comprobación: Una restricción de comprobación (también conocida como restricción de comprobación de tabla) es una condición que define los datos válidos cuando se añaden o actualizan datos en una tabla de la base de datos relacional. Se aplicará una restricción a cada fila de la tabla. La restricción debe ser un predicado. Puede referirse a una o varias columnas de la tabla.
Ejemplo: precio >= 0
Conceptos del diagrama de relaciones de entidades
extendido (EER)
Especialización
La especialización es una manera de formar nuevas entidades utilizando entidades que ya se hayan definido. Las entidades nuevas, conocidas como entidades derivadas, asumir (o heredar) atributos de las entidades que ya existían, y que se refieren a las entidades base. Se pretende ayudar a reutilizar datos con pequeñas o ninguna modificación.
En Umbrello, se puede especificar la especialización de separación y de solapamiento
La especialización de separación
La especialización de separación especifica que las subclases de la especialización se pueden separar. Esto significa que una entidad puede ser miembro de más de una de las entidades derivadas de la especialización
Representación visual de una especialización de separación en un diagrama EER
Especialización de solapamiento
Cuando las entidades derivadas no tienen restricciones para separarse, el conjunto de entidades se dice que están en una especialización de solapamiento. Esto significa que al igual que en el mundo real la entidad puede ser miembro de más de una entidad entidad derivada de la especialización
Representación visual de la especialización de solapamiento en un diagrama EER
Categoría
Una entidad derivada se dice que es una Categoría cuando representa una colección de objetos que es un subconjunto de unión de distintos tipos de entidades. Una categoría se modela cuando se necesita relaciones de superclase/subclase sencillas con más de una superclase, donde las superclases representan diferentes tipos de entidad (similar a la herencia múltiple en la programación orientada a objetos).
Representación visual de una categoría en un diagrama EER
La fuente de esta información se puede encontrar más
información sobre UML en la página web de OMG, http://www.omg.org.
4.) Utilidad de cada uno de los
diagramas
Antes de introducir cada uno de los diagramas de
UML, debemos recordar que como lenguaje que es, si no se usa con frecuencia, se
puede olvidar un poco. La meta de estos diagramas y el lenguaje entero es
captar las estructuras y arquitectura de un sistema de software, y diseñarlo
con la mayor exactitud posible, con respecto a los requerimientos y/o
resultados esperados.
Tipos de Diagramas de modelado UML
Existen diversos tipos de diagrama que pueden ser
implementados en la representación de su proyecto de software. Cada uno de
ellos contiene un nivel de información relacionado con el objeto de
representación del mismo. Los principales diagramas de UML son:
Diagramas de Casos de Uso
El diagrama de casos de uso representa la forma
en cómo un Actor opera con el sistema en desarrollo, además de la forma, tipo y
orden en como los elementos interactúan. Estas operaciones son las que llamamos
casos de uso. Los diagramas de casos de uso tienen la responsabilidad de
documentar los macro requisitos del sistema.
Los símbolos principales de un caso de uso son el
actor; el óvalo del caso de uso y las relaciones de asociación.
Diagrama de Actividades
Los diagramas de Actividades en UML son el
equivalente de diagramas de flujo en la documentación clásica de software.
Estos diagramas son de gran utilidad para analizar procesos sin requerir el uso
de códigos de programación e igualmente para refinar procesos que comprenden el
sistema.
Diagrama de Clases
Los diagramas de clases representan una visión
estática del sistema a desarrollar; estos no describen comportamiento o
interacción del mismo y solamente representan las clases de un sistema y cuál
es la relación existente entre ellas.
En el desarrollo de un sistema pueden existir
diversos diagramas de clases que representan las partes del mismo. No es
necesario el uso de un solo diagrama de clases para representar un sistema, y
generalmente suele no hacerse. La importancia de los diagramas de clases es mostrar
desde varias perspectivas la estructura de un sistema visto desde las
clases que lo componen. Para representar una visión de comportamiento de un
sistema se utilizan los diagramas de interacción.
Diagramas de Interacción
Como se mencionó antes, estos diagramas
representan la visión de comportamiento o interacción entres los diferentes
componentes que conforman su sistema. Existen dos tipos de diagrama de
interacción: Los de secuencia y los de colaboración, teniendo ambos la misma
finalidad siendo su única diferencia es respecto a su construcción.
Los diagramas de secuencia usan la perspectiva de
línea de tiempo para representar el comportamiento del sistema o componente de
software. Esta línea de tiempo se lee en el orden que va desde la esquina
superior izquierda hasta la esquina inferior derecha del diagrama.
Los diagramas de colaboración no están ordenados
en tiempo, por lo que su lectura está determinada por números que indican la
secuencia de hechos.
Diagramas de Estado
Mientras que los diagramas de interacción
muestran los objetos y los mensajes que se pasan entre ellos, un diagrama de
estado muestra el estado cambiante de un solo objeto.
Diagrama de Componentes
Un diagrama de componentes representa las
dependencias entre componentes software, incluyendo componentes de código
fuente, componentes del código binario, y componentes ejecutables. El diagrama
de componente hace parte de la vista física de un sistema, la cual modela la
estructura de implementación de la aplicación por sí misma, su organización en
componentes y su despliegue en nodos de ejecución. Esta vista proporciona la
oportunidad de establecer correspondencias entre las clases y los componentes
de implementación y nodos. La vista de implementación de un sistema se
representa con los diagramas de componentes.
5.) Herramientas de Software que apoyan
el modelo UML
Siempre se ha tenido la idea de que obtener
herramientas de modelado de software, implica una gran inversión para la
organización, en cuanto a costos y entrenamiento de usuarios que utilizarán la
herramienta.
Gracias al gran esfuerzo que desarrolla toda la
comunidad de software libre en el mundo entero, podemos hoy en día, contar con
herramientas de alto nivel profesional de libre acceso, relacionadas
directamente con el modelado de software. Es importante destacar que no
solamente se cuenta con la disponibilidad de acceso a estas herramientas, sino
que también podemos obtener libremente, una amplia gama documental como por
ejemplo, manuales de implementación, uso y mantenimiento; tutoriales de uso;
ejemplos prácticos; guías de desarrollo; documentación de su API; entre otros.
Adicionalmente podemos contar con expertos
desarrolladores y usuarios de todo el mundo que forman la gran comunidad de
software libre; que se encuentran constantemente mejorando estas herramientas y
que publican y generan contenido de apoyo a todas aquellas personas
relacionadas con el área de modelos de sistemas.
Sólo falta una cosa, y es el empeño que debemos
poner para emprendernos en este mundo interesante que está estrechamente
vinculado con
A continuación presentamos un cuadro de herramientas open source de modelado de sistemas de software con UML, y sus respectivos enlaces donde usted puede obtener mayor información:
FUENTE:
http://www.cendesi.com/site/es/articles.php?lng=es&pg=13
Otro software
Software comercial de modelado UML:
- Enterprise Architect
de Sparx Systems
- Borland Together
- Corel iGrafx
- Microsoft
Visio
- PowerDesigner de Sybase
- Rational Rose de IBM
- Poseidon for UML de GentleWare
- MagicDraw UML
Valor agregado del Uso de Modelos de
Software
La base fundamental de la creación y uso de
modelos de software es que el código (de programación) y el texto
consumen gran cantidad de tiempo. Igualmente ningún equipo de desarrollo de
software desea invertir tiempo en crear documentos de texto que nadie leerá!. Lo que si deseamos como desarrolladores es captar
con precisión las partes importantes del problema y una solución concreta.
Como habíamos comentado en el artículo anterior,
los modelos de software consisten en un conjunto de diagramas o imágenes que
representan un sistema sus aspectos fundamentales. Lo que se desea conseguir
con los modelos es que sean mucho más económicos para producir y experimentar
software que con el código. Es claro que se puede usar texto para describir un
sistema (generalmente ha sido la forma tradicional), pero se puede trasmitir
más información con imágenes estandarizadas.
Todos sabemos que la mayoría de los programadores
nos adherimos a nuestros desarrollos de código; y esto aunque parece algo
sicológicamente inofensivo, para un proyecto de software puede resultar un
factor crítico en cuanto a mantenimiento y mejora de bloques o componentes de
un sistema. Podemos experimentar a menudo la difícil aceptación de un
programador para hacerle modificaciones a un código escrito por él en especial
si la escritura del código es el rol principal del puesto de trabajo que ocupa.
Inversamente, los programadores no se adhieren a
los modelos, en incluso se sienten más identificados con el desarrollo del
proyecto de software en su totalidad, y eso influye intensamente en el
desempeño global del desarrollo de su proyecto.
Por otro lado con respecto a los usuarios finales
o aquellos relacionados directamente con el producto final de un proyecto de
software, existe una mayor relación e interacción de ellos con el diseño del
mismo. Evidentemente podríamos imaginar la aceptación de un centenar de líneas
de código o texto de un sistema a un usuario final, con respecto a la
aceptación de gráficos, esquemas o diagramas realizados bajo un modelo
estandarizado como lo es UML.
Con modelos basados en UML, un usuario final puede realizar una mayor colaboración con respecto al diseño del sistema, que con largos documentos descriptivos.
6.) Caso Practico. Aplicar el
diagrama de casos de uso a una problemática presentada en su empresa.
Actualmente en la empresa donde laboramos es usado como sistema de negocios la aplicación SAP (Solutión Aplicatión and Product) donde una de las problemáticas es el tiempo que demora los procesos para autorizar la creación de un identificador en el sistemas SAP que por lo general tarda en 2 y 3 días.
El proceso se ejecuta de la siguiente manera: Un empleado de la empresa que ingrese a realizar sus labores en el sistema necesita un identificador en el Sistema SAP, por tal motivo debe realizar una solicitud de creación de cuenta SAP la cual consiste en llenar una planilla con todos sus datos personales, cargo, supervisor, etc. Esta planilla es enviada a un delegado el cual verifica la solicitud si todos los datos están correctos envía la solicitud al administrador funcional de la aplicación SAP revisa y aprueba esa solicitud para luego enviarla a los administradores de seguridad SAP quienes ejecutar la creación del indicador.
Conclusiones:
UML no es un
método de desarrollo. No
te va a decir cómo pasar del análisis al diseño y de este al código. No son una
serie de pasos que te llevan a producir código a partir de unas
especificaciones.
UML al no ser
un método de desarrollo es independiente del ciclo de desarrollo que vayas a
seguir, puede encajar en un tradicional ciclo en cascada, o en un evolutivo
ciclo en espiral o incluso en los métodos ágiles de desarrollo.
Por lo tanto UML está diseñado para su uso con software orientado a objetos, y tiene un uso limitado en otro tipo de cuestiones de programación. Donde tenemos que los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso.
Es importante resaltar que los diagramas de casos de uso no están pensados para representar el diseño y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicación con los futuros usuarios del sistema, y con el cliente, y resultan especialmente útiles para determinar las características necesarias que tendrá el sistema. En otras palabras, los diagramas de casos de uso describen qué es lo que debe hacer el sistema, pero no cómo.
Infografias:
http://www.ingenierosoftware.com/analisisydiseno/uml.php
http://es.wikipedia.org/wiki/UML
http://www.cendesi.com/site/es/articles.php?lng=es&pg=13
página web de OMG, http://www.omg.org.
http://www.osmosislatina.com/lenguajes/uml/casos.htm