miércoles, 15 de abril de 2009

Diseño UML

Diseño UML


Datos:

Nombre: Luis Antonio Ramírez Aranguren.
Edad: 19 años.
Dirección: Cr 3b # 32a45.
Teléfono: 245-89-29, 566-94-95 o 3124995570.
Ocupación: Aprendiz Sena



Expectativas:

Las expectativas que tengo frente al programa ADSI es lograr mis logros o metas trazadas antes de haber entrado a esta especialidad, las cuales tienen énfasis en lograr construir mi empresa de software y poder especializarme en Francia ya que por medio de lo que aprenda de los maestros en cada modulo será la base de mi evolución como empresario.

Que es UML?

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.
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. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Su Uso:
  1. Mejora nuestro nivel de comunicacion formal.

  2. Abordamos la complejidad con una documentacion minimalista.

  3. Desarrollamos procesos/productos con mayor fiabilidad y calidad.

Su contenido:

Dispone de:

  • Repertorio de unidades (Clases, Acciones, Objetos, Estados, Casos d eUso).

  • Gramática que define las reglas de combinación pra formar iotras unidades más complejas (diagramas, modelos).

  • Una determinada escala de abstracción y granularidad.

Ventaja Clave:

Con un número clavereducido de elementos UML y sus reglas de combinación, es posible construir y comunicar estructuras y funcionalidad muy complejas.

La contrapartida sería una especificación textual con centenares de páginas muy difícil de mantener ante nuevos cambios.


Lo usamos para:

  1. Definir un problema que afecta a una organización (análisis).
  2. Plantear una solución de diseño (abstracción).
  3. Modelar procesos de negocio (optimización de flujos de trabajo).

  4. Construir un producto de software (concreción de una abstracción).

  5. Certificar la coherencia, completitud y usabilidad del producto (calidad).
  6. Evaluar la arquitectura de una organización (conocimiento).

Metodología:

  1. Qué aspectos esenciales hay que modelar (desde un esbozo a un plano detallado).

  2. Qué diagrama es el más apropiado para representar una vista del modelo (estructura y/o función).

  3. En qué proceso de proyecto (Análisis, Diseño, Implementación, Testing, etc.), hay que realizar un determinado diagrama, y quién participará en su elaboración (Roles de proyecto).
  4. Qué escala de abstracción y qué nivel de dedicación hay que aplicar a un diagrama en cada fase de proyecto (desde el estudio preliminar en adelante).

  5. Cómo definimos un modelo a través de distintas vistas de arquitectura: estructura, procesos y Casos de Uso.

  6. Cómo delimitamos el alcance de un proyecto en tiempo, coste, procesos y producto resultante.

Unidades básicas de UML:

  • Estructura:

Define básicamente tipos de objetos (Clases) con sus atributos (qué conocen), sus responsabilidades (qué puede hacer) y su nivel de visibilidad (con quién puede relacionarse).

  • Función:

Expresan acciones y procesos como resultado de los objetos en un escenario acotado (eventos), y modelan la sucesión de estados que transcurren a lo largo del ciclo de vida de un objeto.

  • Conectores:

Definen las categorías de relación entre Clases, objetos, acciones, procesos, estados y la trazabilidad entre todas las unidades de estructura y función.

Diagramas UML existentes:

  • Diagrama de Paquetes.
  • Diagrama de Casos de Uso.
  • Diagrama de Actividad.
  • Diagrama de Secuencia.
  • Diagrama de Comunicación.
  • Diagrama de Estados.
  • Diagrama de Despliegue.
  • Diagrama de Componentes.
  • Diagrama de Objetos.
  • Diagrama de Clases.

Metodologías del desarrollo del sistema:

  1. Requerimientos. (Modelo Casos de Uso)

  2. Análisis. (Modelo Análisis)

  3. Diseño. (Modelo Diseño, Modelo Componentes)

  4. Implementación. (Modelo de Despliegue)
  5. Testing. (Modelo de Certificación).

Para qué sirve UML:

  • Sirve para representar visualmente las reglas de creación, estructua y comportamiento de un grupo relacionado de objetos y procesos.
  • Para visualizar de manera eficiente la complejidad del sistema o una organizacion en un reducido número de diagramas.
  • Para mantener más agilmente las especificaciones ante los cambios y nuevos enfoques de arquitectura.

Que un Caso de Uso?

Un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas.

Ejemplo Caso de Uso:

















Para que sirve un Caso de Uso:


Sirve para describir la funcionalidad de un sistema, no son diagramas de flujo, estan compuestos por 4 elementos: Los actores con los cuales interactua el sistema, el sistema mismo, los casos de uso o servicios que el sistema ejecutará y las relaciones entre estos elementos.

Ventajas de los Casos de Uso:

La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor (su usuario) al hacer uso del sistema.
Como técnica de extracción de requerimiento permite que el analista se centre en las necesidades del usuario, qué espera éste lograr al utilizar el sistema, evitando que la gente especializada en informática dirija la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos.
A su vez, durante la extracción (elicitation en inglés), el analista se concentra en las tareas centrales del usuario describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la priorización del requerimiento.

Desvantajas:

Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no establecen completamente los requisitos funcionales ni permiten determinar los requisitos no funcionales. Los casos de uso deben complementarse con información adicional como reglas de negocio, requisitos no funcionales, diccionario de datos que complementen los requerimientos del sistema. Sin embargo la ingeniería del funcionamiento especifica que cada caso crítico del uso debe tener un requisito no funcional centrado en el funcionamiento asociado.

Normas de aplicación:

Los casos de uso evitan típicamente la jerga técnica, prefiriendo la lengua del usuario final o del experto del campo del saber al que se va a aplicar. Los casos del uso son a menudo elaborados en colaboración por los ingenieros de requisitos y los clientes.
Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea de negocio. Desde una perspectiva tradicional de la ingeniería de software, un caso del uso describe una característica del sistema. Para la mayoría de proyectos de software, esto significa que quizás a veces es necesario especificar diez o centenares de casos de uso para definir completamente el nuevo sistema. El grado de la formalidad de un proyecto particular del software y de la etapa del proyecto influenciará el nivel del detalle requerido en cada caso de uso.
Los casos de uso pretenden ser herramientas simples para describir el comportamiento del software o de los sistemas. Un caso del uso contiene una descripción textual de todas las maneras que los actores previstos podrían trabajar con el software o el sistema. Los casos del uso no describen ninguna funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se implementará. Simplemente muestran los pasos que el actor sigue para realizar una tarea.

Un caso de uso debe:
Describir una tarea del negocio que sirva a una meta de negocio.
Tener un nivel apropiado del detalle.
Ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento.


Situaciones que pueden darse:
Un actor se comunica con un caso de uso (si se trata de un actor primario la comunicación la iniciará el actor, en cambio si es secundario, el sistema será el que inicie la comunicación).
Un caso de uso extiende otro caso de uso.
Un caso de uso usa otro caso de uso.

Símbolos del Caso de Uso:
















Ejemplo de un Caso de Uso visto desde la interfaz del usuario (Registrarse como usuario):



Direccion URL de los primeros 5 casos de uso:http://docs.google.com/Doc?id=dgvxhrnv_50ff7mzwc6

Direccion URL formato de casos de uso:

http://docs.google.com/Doc?id=dgvxhrnv_34dg5x3www