Importancia de UML

Wilmer Barrios | domingo, junio 21, 2009 | | |
Porque es importante UML ?

Hoy en día, UML ("Unified Modeling Language") esta consolidado como el lenguaje estándar en el análisis y diseño de sistemas de computo. Mediante UML es posible establecer la serie de requerimientos y estructuras necesarias para plasmar un sistema de software previo al proceso intensivo de escribir código.

En otros términos, así como en la construcción de un edificio se realizan planos previo a su construcción, en Software se deben realizar diseños en UML previa codificación de un sistema, ahora bien, aunque UML es un lenguaje, éste posee más características visuales que programáticas, mismas que facilitan a integrantes de un equipo multidisciplinario participar e intercomunicarse fácilmente, estos integrantes siendo los analistas, diseñadores, especialistas de área y desde luego los programadores.
Complejidad / Objetos

Entre más complejo es el sistema que se desea crear más beneficios presenta el uso de UML ("Unified Modeling Language"), las razones de esto son evidentes, sin embargo, existen dos puntos claves : El primero se debe a que mediante un plano/visión global resulta más fácil detectar las dependencias y dificultades implícitas del sistema, y la segunda razón radica en que los cambios en una etapa inicial (Análisis) resultan más fáciles de realizar que en una etapa final de un sistema como lo seria la fase intensiva de codificación.

Puesto que UML es empleado en el análisis para sistemas de mediana-alta complejidad, era de esperarse que su base radica en otro paradigma empleado en diseños de sistemas de alto nivel que es la orientación a objetos, por lo que para trabajar en UML puede ser considerado un pre-requisito tener experiencia en un lenguaje orientado a objetos.

Hoy en día, entre los lenguajes orientados a objetos más utilizados se encuentran Java y C#, además de otros más antiguos como C++ y SmallTalk, aunque el programar en todos estos lenguajes requiere experiencia previa sobre la sintaxis y bloques específicos, el paradigma empleado en todos ellos es el mismo : Objetos.

Lo anterior permite que un análisis en UML sea realizado independiente del lenguaje en el que finalmente sea implementando el Sistema (Java,C#,C++,SmallTalk), misma característica que permite a personal no familiarizado en lenguajes de programación participen en el análisis y diseño de un sistema.

Conceptos / Diagramas

Entre los conceptos fundamentales de orientación a objetos se encuentran los siguientes :

*

Un modelo es una abstracción del problema que se intenta resolver.
*

Un dominio es el mundo de donde proviene el problema .
*

Un modelo consiste de objetos que interactúan entre sí enviándose mensajes.
*

Cada objeto posee características propias (atributos) y operaciones que puede realizar (métodos); las valores asignados a un objeto en determinado momento determinan su estado.
*

Una clase es un molde para describir un objeto que agrupa características (atributos) y comportamientos (métodos).
*

Los objetos son instancias de Clases.

A continuación se enumeran los 9 diagramas que forman la base de UML, y dictan la manera en que es diseñado un sistema :

*

Uso-Caso
*

Clases
*

Objetos
*

Secuencia
*

Colaboración



*

De Estado (Statechart)
*

Actividad
*

Componentes
*

Ejecución (Deployment)

El uso y diseño de estos diagramas es tema del resto de esta guia para UML.



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 limites 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 <> 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 <> que origina del uso-caso base hacia el uso caso de extensión.

Ilustración

Diagrama Uso Caso




Diagrama de actividad

Definición y Usos

Un diagrama de Actividad demuestra la serie de actividades que deben ser realizadas en un uso-caso, así como las distintas rutas que pueden irse desencadenando en el uso-caso.

Es importante recalcar que aunque un diagrama de actividad es muy similar en definición a un diagrama de flujo (tipicamente asociado en el diseño de Software), estos no son lo mismo. Un diagrama de actividad es utilizado en conjunción de un diagrama uso-caso para auxiliar a los miembros del equipo de desarrollo a entender como es utilizado el sistema y como reacciona en determinados eventos.Lo anterior, en contraste con un diagrama de flujo que ayuda a un programador a desarrollar codigo a través de una descripción lógica de un proceso. Se pudiera considerar que un diagrama de actividad describe el problema, mientras un diagrama de flujo describe la solución.

En la siguiente sección se describen los diversos elementos que componen un diagrama de Actividad.

Composición

  • Inicio: El inicio de un diagrama de actividad es representado por un círculo de color negro sólido.

  • Actividad : Una actividad representa la acción que será realizada por el sistema la cual es representada dentro de un ovalo.

  • Transición: Una transición ocurre cuando se lleva acabo el cambio de una actividad a otra, la transición es representada simplemente por una linea con una flecha en su terminación para indicar dirección.

  • Ramificación (Branch) : Una ramificación ocurre cuando existe la posiblidad que ocurra más de una transición (resultado) al terminar determinada actividad.Este elemento es representado a través de un rombo.

  • Unión (Merge) : Una unión ocurre al fusionar dos o más transiciones en una sola transición o actividad.Este elemento también es representado a través de un rombo.

  • Expresiones Resguardadas (Guard Expressions) : Una expresió resguardada es utilizada para indicar una descripción explicita acerca de una transición. Este tipo de expresión es reprsentada mediante corchetes ([...] y es colocada sobre la linea de transición.

  • Fork : Un fork representa una necesidad de ramificar una transición en más de una posibilidad. Aunque similar a una ramificación (Branch) la diferencia radica en que un fork representa más de una ramificación obligada, esto es, la actividad debe proceder por ambos o más caminos, mientras que una ramificación (Branch) representa una transición u otra para la actividad (como una condicional). Un fork es representado por una linea negra solida, perpendicualar a las lineas de transición .

  • Join : Una join ocurre al fusionar dos o más transiciones provenientes de un fork, y es empleado para dichas transiciones en una sola,tal y como ocurria antes de un fork .Un fork es representado por una linea negra solida, perpendicualar a las lineas de transición .

  • Fin : El fin de un diagrama de actividad es representado por un círculo, con otro circulo concentrico de color negro sólido.

  • Canales (Swimlanes) : En determinadas ocasiones ocurre que un diagrama de actividad se expanda a lo largo de más de un entidad o actor, cuando esto ocurre el diagrama de actividad es particionada en canales (swimlines), donde cada canal representa la entidad o actor que esta llevando acabo la actividad.


Diagramas de Clases : Definición y Usos

Un diagrama de Clases representa las clases que serán utilizadas dentro del sistema y las relaciones que existen entre ellas.

Los diagramas de Clases por definición son estáticos, esto es, representan que partes interactúan entre sí, no lo que ocurre cuando.

Ilustración

Diagrama de Clases


Share this article
 
Copyright © 2015 MyBiosWeb
Distributed By My Blogger Themes | Template Design By BTDesigner