UML - Analisis de Sistemas

LENGUAJE UNIFICADO DE

MODELADOMODELO DEL NEGOCIO Y FACTIBILIDADES

DISEÑO DE SISTEMAS

Ing. José Bustamante Romero

Agenda

• OMG

• Definición de UML

• Historia de UML

• Modelamiento con UML

• Definición de conceptos

• Diagramas de UML

• Fuentes de consultas y links

Object Management Group (OMG)

• Es un consorcio internacional que promueve el desarrollo de software orientado por objetos.

• El objetivo del OMG es proveer un marco de arquitectura común para permitir la interacción de objetos en plataformas heterogéneas y distribuidas.

• Fue fundado en 1989.

• Inicialmente estuvo conformado por 8 compañías: 3Com Corpotation, American Airlines, Canon Inc., Data General, Hewlett-Packard, Philips TelecommunicationsN.V., SunMicrosystemsy Unisys Corporation.

• El OMG no realiza trabajos de desarrollo e implementación, más bien se basa en la tecnología existente ofrecida por sus miembros.

UML -Unified Modeling Language

¿Cómo se creó UML?

• Socios de la compañía Rational Software, Herramienta case Rational Rose.

• UML es el lenguaje estándar para visualizar, especificar, construir y documentar los artefactos de una aplicación de software ó sistema.

¿Por qué Lenguaje unificado de modelado?

• OMT -ObjectModeling Technique(James Rumbaugh) especialmente bueno para análisis de datos de Sistemas de

Información

entre otros, usa extensiones de los diagramas Entidad Relación

• Método-Booch(GradyBooch)• especialmente útil para sistemas concurrentes y de tiempo real

• fuerte relación con lenguajes de programación

• OOSE -Object-OrientedSoftware Engineering(IvanJacobson)• desarrollo guiado por los use cases(casos de uso)

• buen soporte de Ingeniería de Requisitos e Ingeniería de Información

• Modelado y simulación de sistemas de telecomunicaciones

UML unifica estos conceptos e introduce otros nuevos

Evolución de UML:

Fuente: http://www.dsic.upv.es/~uml/curso.ppt

http://www.dsic.upv.es/~uml/curso.ppt

¿Qué es UML?

• UML, prescribe un conjunto de notaciones y diagramas

estándar para modelar sistemas orientados a objeto y

describe la semántica esencial de lo que estos diagramas

y símbolos significan.

• UML es una notación, destinado a los sistemas de

modelado que utilizan conceptos orientados a objetos.

• Los principales factores que motivaron la creación de

UML fueron:

• La necesidad de modelar sistemas

• Las tendencias en la industria de software

• Unificar los distintos lenguajes y métodos existentes

• Innovar los modelos para adaptarse a la arquitectura distribuida

UML no es:

• Un lenguaje de programación visual, sino un lenguaje

de modelación visual.

• Una herramienta o deposito de especificación, sino un

lenguaje de modelación de especificación.

• Un proceso, sino que habilita procesos.

• Fundamentalmente, UML está relacionado con la captura,

comunicación y nivelación (disgregación en niveles) de

conocimientos.

UML, características:

• Divide cada proyecto en un número de diagramas que

representan las distintas vistas del proyecto y juntos

representan la arquitectura del mismo.

• Permite describir un sistema en diferentes niveles de

abstracción, simplificando la complejidad sin perder

información, para que los usuarios y desarrolladores

comprendan las características de la aplicación.

• Se quiere convertir en un lenguaje estándar con el que

sea posible modelar todos los componentes del

desarrollo de una aplicación, sin embargo no pretende

definir un modelo de desarrollo sino únicamente un

lenguaje de modelado.

Modelo

El proceso de desarrollo de software se inicia con la

construcción de un modelo. Dicho modelo representa la

especificación precisa de las necesidades del usuario

trasladadas a los requerimientos.

Un modelo es la interpretación simplificada de la

realidad.

Estructuralmente destaca la organización del sistema y a

nivel de comportamiento destaca la dinámica del sistema.

¿Por qué construir un Modelo?

1. Construimos modelos para comprender mejor el

sistema que estamos desarrollando

2. Cuatro utilidades de los modelos:

Visualizar cómo es o queremos que sea el sistema

Especificar la estructura y comportamiento del sistema

Proporcionan plantillas que guían la construcción del sistema

Documentan las decisiones

3. “Equivalen a los planos de una casa”

Principios del Modelado:

• La elección de los modelos tiene una profunda influencia

sobre cómo se acomete el problema y se moldea la

solución.

• Todo modelo puede expresarse a diferentes niveles de

detalle y usarse en diferentes momentos del ciclo de vida.

• Todo modelo debe estar ligado a la realidad.

• Un único modelo no es suficiente. Cualquier sistema no

trivial se aborda mejor a través de un pequeño conjunto

de modelos casi independientes, que muestran distintos

aspectos.

Modelo, características:

• Abstracto:

• Enfatiza los elementos importantes y oculta los irrelevantes

• Comprensible:

• Fácil de comprender por los observadores

• Preciso:

• Representa de forma fiel el sistema que modela

• Predictivo:

• Se pueden usar para deducir conclusiones sobre el sistema que se

esta modelando

• Barato:

• Mucho más barato y sencillo de construir es el sistema que se

modela, luego se encontrara evidencia del desarrollo

¿Cómo se usa un modelo?

• Para detectar errores u omisiones en el diseño antes de

comprometer recursos para la implementación

Analizar y experimentar

Investigar y comparar soluciones alternativas

Minimizar riesgos

• Para comunicarse con los “Stakeholders”

Clientes, usuarios, implementadores, encargados de pruebas,

documentadores, etc.

• Para guiar la implementación (construcción y

codificación)

Proceso

• Un buen proceso debe permitir a los equipos y clientes

trabajar juntos para construir sistemas complejos con

pocos defectos en menor tiempo con mayor confiabilidad

y previsibilidad para identificar y para reducir riesgos.

¿Cómo utilizar UML?

• Lo primero que se debe hacer para comenzar a desarrollar un proyecto con UML, es seleccionar una metodología de desarrollo que defina la naturaleza concreta del proceso a seguir.

• El modelo a definir en base al proceso elegido, se divide en realidad en varios tipos de modelo o vistas, cada una centrada en un aspecto o punto de vista del sistema. En general, independientemente del proceso que se emplee, se puede encontrar las siguientes vistas:

Vista de diseño Vista de implementación

Vista de procesos Vista de despliegue

Vista de Casos de Uso

...continua, ¿Cómo utilizar UML?

• Vista de Casos de Uso. Engloba los Casos de Uso que

describen el comportamiento del sistema como lo verían los

usuarios finales y desarrolladores. No especifica la

organización del sistema.

• Vista de Diseño. Engloba las clases e interfaces que

conforman el vocabulario del problema y su solución. Da

soporte a los requisitos funcionales del sistema, es decir los

servicios que proporciona a los usuarios finales.

Con UML los aspectos estáticos de estas dos vistas se pueden

concretar con los diagramas de clases y de objetos; los

aspectos dinámicos con los diagramas de iteración (secuencia

y colaboración), diagramas de estados y de actividades.


• Vista de Procesos. Engloba los hilos y procesos que forman

los mecanismos de sincronización y concurrencia del sistema.

Da soporte al funcionamiento, capacidad de crecimiento y

rendimiento del sistema.

• Vista de Despliegue. Engloba los nodos que forman la

topología hardware sobre el que se ejecuta el sistema. Da

soporte a la distribución, entrega e instalación de las partes

que conforman el sistema físico.

Con UML los aspectos estáticos de estas dos vistas se pueden

concretar con los diagramas de clases y de objetos; los

aspectos dinámicos con los diagramas de iteración (secuencia

y colaboración), diagramas de estados y de actividades.


• Vista de Implementación. Engloba los componentes y

archivos empleados para hacer posible el sistema físico.

Da soporte a la gestión de configuraciones de las

distintas versiones del sistema, a partir de componentes y

archivos.

Con UML los aspectos estáticos de estas dos vistas se

pueden concretar con los diagramas de clases y de

objetos; los aspectos dinámicos con los diagramas de

iteración (secuencia y colaboración), diagramas de estados

y de actividades.

LENGUAJE DE

MODELAMIENTO: UML

Lenguaje de modelamiento: UML

UML tiene tres bloques básico de construcción: elementos,

relaciones y diagramas.

1. Bloques básicos de

construcción de UML.

2. Reglas que dictan cómo

se pueden combinar

esos bloques.

3. Y algunos mecanismos

comunes que se aplican

a través de UML.

elementos

relaciones

diagramas

Lenguaje de modelamiento: UML

1. Elementos: Unidades básicas de construcción, cuatro tipo:

EstructuralesDe

comportamiento

De agrupación De anotación

Elementos en UML

Partes dinámicas de los

modelos, representan

comportamientos en el

tiempo y espacio.

Partes explicativas de

los modelos.

Partes organizativas

de los modelos.

Partes estáticas de los

modelos, representan

aspectos conceptuales o

materiales

…continua, Lenguaje de modelamiento: UML

1.1 Elementos estructurales:

• Una interfaz es una colección de

operaciones que especifican un servicio de

una clase o un componente. Describe el

comportamiento visible de ese elemento.

• Una clase es una descripción de un conjunto

de objetos que comparten los mismos

atributos, operaciones, relaciones y

semántica.



• Un caso de uso es una descripción de un

conjunto de secuencias de acciones de un

sistema y que produce un resultado

observable de interés para un actor particular.

• Una colaboración define una interacción y es

una sociedad de roles y otros elementos que

colaboran para proporcionar un

comportamiento cooperativo.



• Un componente, parte física y reemplazable

de un sistema, que agrupa un conjunto de

interfaces, archivos de código fuente, clases,

colaboraciones y proporciona la

implementación de dichos elementos.

• Un nodo, elemento físico que existe en

tiempo de ejecución y representa un recurso

computacional con capacidad de

procesamiento.


1.2 Elementos de comportamiento:

• Interacción, Comprende un conjunto de

mensajes que se intercambian entre un

conjunto de objetos, para cumplir un objetivo

especifico.

• Maquina de estado, Especifica la secuencia

de estados por los que pasa un objeto o una

interacción, en respuesta.


1.3 Elementos de agrupación:

• Paquete, se emplea para organizar

elementos en grupos.

1.4 Elementos de notación:

• Una nota es un elemento explicativo de los

modelos UML. Sirve para hacer claridad

sobre elementos del modelo.


II. Relaciones: Abstracciones (relación) que actúan de unión entre los elementos.

• Una dependencia es una relación semántica entre dos elementos, en la cual un cambio a un elemento (elemento independiente) puede afectar la semántica del otro elemento (elemento dependiente).

• Es una relación estructural que resume un conjunto de enlaces que son conexiones entre objetos.

• Una asociación es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. La agregación es un tipo especial de asociación, que representa una relación estructural entre un todo y sus partes.


• Una generalización es una relación en la cual

los objetos del elemento especializado (el

hijo) pueden sustituir a los objetos del

elemento general (el padre). De esta forma,

el hijo comparte la estructura y el

comportamiento del padre.

• Una realización especifica que una clase

implementara un conjunto de métodos

especificados por una interfaz.

III. Diagramas

En OMG UML 2.0 se definen una serie de diagramas adicionales a los establecidos en OMG UML 1.x. El conjunto de diagramas se encuentra organizado en torno a dos categorías: diagramas estructurales (representados en verdes) y diagramas dinámicos o de comportamiento (representados en celeste). Los diferentes diagramas son indicados en la figura siguiente:

III. Diagramas, continua…

Jerarquía de Diagramas

1. Diagramas de estructura enfatizan en los elementos

que deben existir en el sistema modelado

2. Diagramas de comportamiento enfatizan en lo que

debe suceder en el sistema modelado

3. Diagramas de Interacción, un subtipo de diagramas

de comportamiento, que enfatiza sobre el flujo de

control y de datos entre los elementos del sistema

modelado

III. Diagramas, continua…

Diagrama de Casos de Uso

Permiten realizar la especificación del alcance funcional

del producto software que se construye y de los actores,

entes que interactúan con el producto de software, que

requieren los diferentes casos de usos.

Los casos de usos pueden relacionarse entre sí a través

de asociaciones que permiten, entre otras cosas, refinar el

Modelo de Casos de Usos a través de las asociaciones de:

• Generalización

• Extends

• Includ

Enfatizan el qué en lugar del cómo.

...continua, Diagrama de Casos de Uso

Generalización

• Asociación estereotipada como

“generalization”. Permite

establecer una jerarquía de

herencia al nivel de los casos de

uso, donde el caso de uso

derivado adquiere toda la

especificación del caso de uso

base e incorporar nuevos

requerimientos a la

especificación.


Extensión

Asociación estereotipada

como: extend. Permite

incorporar el flujo de eventos

de un caso de uso pequeño

dentro de un caso de uso base

de la aplicación bajo la

ocurrencia de una determinada

condición, cuando la misma

evalúa verdadero.


Inclusión

Asociación estereotipada como: incluye. Permite incorporar

el flujo de eventos de un caso de uso pequeño dentro de

un caso de uso base de la aplicación.

Diagrama de Clases

• Muestra una colección de elementos del modelo estático, tales como clases y tipos, sus contenidos y sus relaciones.

• Un modelo conceptual o modelo del dominio muestra gráficamente las clases, los atributos y las asociaciones.

Diagrama de Objetos

Los diagramas de

objetos son análogos a

los de clases, con la

particularidad de que en

lugar de encontrar

clases, encontramos

instancias de éstas.

Son útiles para explicar

partes pequeñas del

modelo en las que hay

relaciones complejas.

Diagrama de Objetos –Diagrama de Clases (relación):

• Los objetos se vinculan por enlaces, que son instancias

de las relaciones entre las clases de objetos del dominio.

...continua, Diagrama de Actividades

• Los diagramas de actividades muestran como las actividades fluyen y las dependencias entre ellas. Muestran los procesos de alto nivel de la organización.

...continua, Diagrama de Actividades

• Ejemplo: “swim lines=pasillos”

Diagrama de Secuencia

Modela la secuencia lógica, a través del tiempo, de los mensajes entre las instancias.

En el siguiente diagrama se puede observar que el registro del préstamo solo se efectúa si el usuario satisface la regla de negocio que establece que el video se encuentre disponible.

Diagrama de Comunicación

Muestra la distribución estática de los objetos, sus interrelaciones y el flujo (envían y reciben) de mensajes entre ellos. Son conocidos también como diagramas de colaboración.

Diagrama de Secuencia y de Comunicación (colaboración)

Los diagramas de secuencia y de colaboración son Isomorfos.

Un diagrama de secuencia se puede transformar mecánicamente en un diagrama de comunicación. Un diagrama de comunicación se puede transformar mecánicamente en un diagrama de secuencia.

Diagrama de Componentes

• El diagrama de componente

muestra interfaces y

dependencias entre los

componentes del software, los

componentes de código de

fuente, código binario y

ejecutables.

• Muestran la organización y

dependencias de un conjunto de

componentes. Cubren la vista de

implementación estática de un

sistema.

Diagrama de Despliegue o distribución

• Estos diagramas muestran la distribución y relación entre los diferentes elementos de hardware llamados “nodos” (arquitectura del sistema); por ejemplo: cpu, dispositivos de I/O, routers, etc.

• Los diagramas de despliegue sirven para modelar la configuración del hardware del sistema, mostrando qué nodos lo componen.

Diagrama de Paquetes

• Los paquetes ofrecen un mecanismo general para la

organización de los modelos/subsistemas agrupando

elementos de modelado.

• Se representan gráficamente como:

...continua, Diagrama de Paquetes

• Cada paquete corresponde a un submodelo

(subsistema)del modelo(sistema)

• Un paquete puede contener otros paquetes, sin límite de

anidamiento pero cada elemento pertenece a (está

definido en) sólo un paquete

• Una clase de un paquete puede aparecer en otro paquete

por la importación a través de una relación de

dependencia entre paquetes

UML – en resumen

Referencias

• Zambrano G. 2009. Construcción de Software Orientado a Objetos. Universidad de San Martín de Porras. Facultad de Ingeniería de Computación y Sistemas.

• Sánchez J. 2003. Proceso Unificado de Desarrollo de Software. Metodologías de Desarrollo Software. Universidad de Las Palmas de Gran Canaria

• Kendall K., Kendall J. 2005. Análisis y Diseño de Sistemas. Ed. 6. Pearson Educación, México.

• TUTORIAL: http://www.cs.utsa.edu/~kdo/roseTutorial/

• http://www.sparxsystems.com.au/resources/uml2_tutorial/

• Alfredo Weitzenfeld. “Ingenieria de software orientado a objetos con UML, Java e Internet. Ed Thomson, Mexico. 2005.

UML - Analisis de Sistemas

Engineering

Transcript of UML - Analisis de Sistemas