Notas uml

Notas sobre el libro UML

Capítulo 1

Hay que comenzar con la pregunta ¿Qué es un modelo?

Es una descripción analógica para ayudar a visualizar algo que no se puede observar directamente y que se realiza con un propósito determinado y se destina a un público especifico ejemplo: como los mapas de la ciudad, o del metro, un plano de instalaciones sanitarias etc.

Se dijo que es una descripción analógica para ayudar a visualizar algo que se puede observar directamente, y que se realiza con un propósito determinado y se destina a un público especifico. Ejemplo:

• DESCRIPCION ANALOGICA. Es una representación simplificada, pues solo es eso, una representación plasmada en papel, no es el producto final.
• NO PUEDE SER OBSERVADO DIRECTAMENTE.  El ejemplo de las instalaciones del sanitario, es un concepto abstracto, ya que no se pueden ver, a menos que se destruyan las paredes para poder visualizar la instalación, al igual que no podemos ver por donde corren las vías del suburbano, el dibujo de un dragón, es solo eso un dibujo ya que el dragón no existe.
• Se realiza con un propósito determinado. El propósito o la perspectiva es lo que determina la finalidad de
• Destinado a un determinado público.

La finalidad última de un modelo es la comunicación de algo.

Precisamente por esta necesidad de comunicar y porque, además se destina a un determinado público, con cierto propósito, un modelo es, en definitiva, una ABSTRACCION.

Modelos de software.

La definición es la misma, por lo tanto, tienen los mismos elementos:

El software nunca puede ser observado directamente porque es intangible e invisible.

El software es en sí un modelo de la realidad, un modelo de software es el modelo de un modelo.

¿Por qué el software necesita modelos?

El modelo más detallado de un producto de software es el código fuente.

• El software es invisible e intangible, solo podemos ver su comportamiento.
• El software es modificable, ya que es percibida por los ajenos a la industria.
• El software se desarrolla por proyectos, no como la producción en masa de la industria manufacturera, por lo tanto, podemos decir que es original
• El software es substancialmente complejo, interactúan cientos o miles de partes entre sí, y que pueden ir cambiando a lo largo de su vida.
• El desarrollo del software es inherentemente complejo, es decir si el producto es complejo el proyecto será complejo tanto en desarrollo y administración.

¿Qué es UML?

Es una notación de modelado visual, que utiliza diagramas para mostrar distintos aspectos de un sistema.

UML se define como “unificado”.

OMG (Object Management Group) es un consorcio de empresas de desarrollo de estándares. En el 2000, UML ya se había convertido en el estándar de facto para modelización de software orientado a objetos. UML es un lenguaje de visualización, especificación y documentación de software, basado en trece tipos de diagramas, cada uno con sus objetivos, destinatarios y contexto de uso.

El lenguaje aparte de ser una herramienta de comunicación formal, contiene una serie de construcciones, sintaxis y semántica definidas.

La sintaxis es la descripción de cómo deben realizarse esos diagramas y la semántica define el significado de cada diagrama y elementos de los mismos.

UML es extensible, ya que los creadores de la notación, llegan a afirmar que en más del 80% de los sistemas se pueden modelar con el 20% de las construcciones de UML

UML se puede clasificar como:

• Como herramienta de comunicación entre humanos.
• Como herramienta de desarrollo.

UML se utilizan para la comunicación por lo tanto no debemos sobrecargarlo vi detalles innecesarios, sino colocar solamente elementos centrales al objetivo de comunicación. La documentación debe ser más útil que abundante.

Una metodología MDD (Model Driven Develpment) Desarrollo guiado por modelos, es una herramienta de desarrollo que podríamos decir que es la más extrema porque parte del modelo que surge del análisis.

Es importante destacar el enfoque, si necesitamos colocar el máximo detalle posible en nuestros diagramas. Algunos autores “los diagramas son el código”.

Existen herramientas que permiten almacenar la documentación de un proyecto Que garantizan la trazabilidad entre elementos, el almacenamiento en un repositorio versionado Y que generan ciertos artefactos intermedios Que incluyen algo de código.

Que no es UML.

UML No es una metodología o proceso, Hay una tendencia a confundir dada la semejanza de nombre con el proceso unificado, o UP.

Lo cierto es que UP Suele estar basado en UML, UML no necesita de UP En lo más mínimo.  UML es una notación que aplica a cualquier método de desarrollo Con la única condición que incluso pueden relativizarse de que se use para modelar una aplicación orientada a objetos.

UML no es Ni se encuentra asociando el proceso en particular tampoco se desvincule exclusivamente a ninguna herramienta Es una notación de modelado de software con la cualidad de llevarse bien con la orientación a objetos.

UML Tiene algunas limitaciones, no puede usarse para modelar cualquier aspecto de un producto de software No hay un diagrama para modelar interfaces de usuario Y no hay ninguna construcción para especificar requisitos no funcionales entre otras falencias.

UML Admite extensiones para atacarlo los déficits para atacar los antes mencionados.

UML Sergio en el marco del paradigma orientado a objetos

OPEN-SOURCE (código abierto).

Existe un lenguaje derivado de XML llamado XMI que es la forma tan única para especificar un modelo UML, esto permite el intercambio de modelos, no todas las herramientas trabajan con el formato XMI.

Los diagramas se hacen con una perspectiva conceptual, los diagramas “conceptuales” su modelo independiente de la computación usualmente son modelos que buscan establecer un vocabulario y unas relaciones entre conceptos del dominio del problema.

perspectiva de especificación. Especificar el producto sin entrar en detalles. Seles denominan modelos independientes de la plataforma de incluyen los detalles innecesarios para especificar el problema que se resolverá, dependan, uno, de la plataforma de software.

Respectiva implementación. Es como se construirá la aplicación suelen tener el mayor nivel de detalle estos modelos serán específicos de la plataforma, y muy relacionados con las definiciones de diseño.

Perspectiva del producto. El código fuente. La perspectiva de implementación de la más utilizada de diseñadores y programadores.

Modelo de UML 2.2

Los modelos estáticos estructurales sirven para modelar el conjunto de objetos, clases, relaciones y sus agrupaciones, presentes en un sistema.

Existen cuestiones Dinámicas o de comportamiento. Que definen como evolucionan esos objetos a lo largo del tiempo, y cuáles son las causas de esa evolución.

UML sirve para definir ambos tipos de modelos. “unificados”.

UML trabaja con 13 tipos de diagramas.

• Diagrama de caso de uso.
• Diagrama de objeto.
• Diagrama de clases
• Diagrama de paquetes
• Diagrama de componentes
• Diagrama de despliegue
• Diagrama de estructuras compuestas

Y los diagramas de comportamiento o dinámicos son.

• Diagrama de secuencia
• Diagrama de comunicación (o de colaboración)
• Diagrama de máquina de estados o de estados
• Diagrama de actividades
• Diagrama de visión global de la interacción
• Diagrama de tiempos

Muchos autores consideran el diagrama de casos de uso común modelo de comportamiento, Los diagramas que casos de uso de UML sólo representan una dicta estática de las interacciones de usuarios con el sistema.

Extensiones a UML.

Un perfil de UML Es un conjunto de extensiones que especializan UML para su uso en un dominio o contexto particular.

Los perfiles pueden aplicarse de a varios en forma simultánea. Por ejemplo, podemos modelar una aplicación utilizan dólares perfiles de lenguaje ella java y de especificación de desempeño de ejecución.

En la introducción de perfiles, se utiliza los estereotipos de UML, Que son expresiones encerradas entre paréntesis angulares dobles.

Capítulo 2 Disciplinas y Metodología

Disciplinas Operativas:

• Captura y validación de requisitos.
• Análisis
• Diseño
• Construcción
• Pruebas
• Despliegue

Disciplinas de Soporte

• Administración de proyectos
• Gestión de cambios
• Administración de la configuración
• Gestión de los recursos humanos
• Gestión del ambiente de trabajo
• Gestión de la calidad

Denominamos captura y validación de requisitos para la actividad mediante la cual se determina qué es lo que quiere nuestro cliente.

Habitualmente es una actividad es mucha participación de clientes y usuarios.

El análisis se define como la actividad que determina el qué del desarrollo, porque en ella definimos el sistema que vamos a construir. Difiere de la actividad entendida en que trabajamos sobre ABSTRACCION desde software y con menor contacto con los dientes y con los usuarios.

...