Lenguaje De Modelado Relacional

Contenido:

Sección 1 Introducción.........................................................................................2

Capítulo 1 Por qué modelamos..........................................................................3

Capitulo 2 Presentación de UML ..................................................................... 6

Capitulo 3 ¡Hola Mundo!...................................................................................18

Sección 2 Modelado estructural básico..............................................................19

Capítulo 4 Clases.............................................................................................20

Capítulo 5 Relaciones......................................................................................26

Capítulo 6 Mecanismos Comunes...............................................................….35

Capítulo 7 Diagramas...................................................................................…38

Capítulo 8 Diagramas de clases..................................................................….40

Sección 3 Modelado estructural avanzado....................................................….47

Capítulo 9 Características avanzadas de las clases........................................48

Capítulo 10 Características avanzadas de las relaciones..................................51

Capítulo 11 Interfaces, tipos y roles...................................................................54

Capítulo 12 Paquetes.........................................................................................59

Capítulo 13 Instancias........................................................................................64

Capítulo 14 Diagramas de objetos.....................................................................69

Sección 4 Modelado básico del comportamiento................................................72

Capítulo 15 Interaciones......................................................................................73

Capítulo 16 Casos de uso....................................................................................78

Capítulo 17 Diagramas de Caso de uso...............................................................82

Capítulo 18 Diagramas de interación...................................................................86

Capítulo 19 Diagramas de actividades.................................................................92

El LENGUAJE UNIFICADO DE MODELADO

SECCION 1

INTRODUCCION

CAPITULO 1

POR QUÉ MODELAMOS

Una empresa de software con éxito es aquélla que produce de una manera consistente software de calidad que satisface las necesidades de sus usuarios y la empresa; para producir software que cumpla su propósito, hay que conocer e involucrar a los usuarios de forma disciplinada con el fin de extraer los requisitos reales del sistema., hay que idear una sólida base arquitectónica que sea flexible al cambio, software rápido, eficiente, hay que tener gente apropiada y el enfoque apropiado, hay que disponer de un proceso de desarrollo sólido que pueda adaptarse a las necesidades cambiantes del problema y la tecnología.

El modelado es una parte central de todas las actividades que conducen a la producción de buen software.

 Construimos modelos para comunicar la estructura y el comportamiento del sistema.

 Construimos modelos para visualizar y controlar la arquitectura del sistema.

 Construimos modelos para comprender mejor el sistema que estamos construyendo.

 Construimos modelos para controlar el riesgo.

La importancia de modelar

El modelar es una técnica de ingeniería probada y bien aceptada; por eso los arquitectos de casas y rascacielos ayudan a los usuarios a visualizar el producto final, y no solo es parte de la industria de la construcción, sino en todos los ámbitos se utiliza el modelado.

Un modelo proporciona los planos de un sistema, y estos pueden involucrar planos detallados, así como los generales que ofrecen una visión global del sistema. Un buen modelo incluye aquellos elementos que tienen una gran influencia.

En el modelado, conseguimos cuatro objetivos:

 Ayudan a visualizar cómo es o queremos que sea un sistema

 Permite especificar la estructura o el comportamiento de un sistema

 Proporcionan plantillas que nos guían en la construcción de un sistema

 Documentan las decisiones que hemos adoptado.

1. Principios del modelado

1.- La elección de qué modelos crear tiene una profunda influencia sobre cómo se acomete un problema y cómo se da forma a una solución.

En el software, los modelos elegidos pueden afectar mucho a nuestra visión

Si construimos un sistema con la mirada de un desarrollador de bases de datos, nos centraremos en los modelos entidad-relación.

Si construimos un sistema con la mirada de un analista estructurado, se obtendrán modelos centrados en los algoritmos.

Si construimos un sistema con mirada de un desarrollador orientado a objetos, se centra en una arquitectura con un mar de clases y patrones de interacciones.

Por lo tanto cada visión del mundo conduce a un tipo de sistema diferente, con diferentes costos y beneficios.

2. Todo modelo puede ser expresado a diferentes niveles de precisión.

Con los modelos de software, a veces un pequeño y sencillo modelo ejecutable de la interfaz del usuario es exactamente lo que se necesita; otras veces, hay que bajar y enredarse con los bits, como cuando se están especificando interfaces entre sistemas o luchando con cuellos de botella en redes por ejemplo.

Un analista o un usuario final se centrará en el qué; un desarrollador se centrará en el cómo. Tanto uno como otros querrán visualizar un sistema a diferentes niveles de detalle en momentos diferentes.

3. Los mejores modelos están ligados a la realidad.

En el software, el talón de aquiles de las técnicas de análisis estructurado es el hecho de que hay una desconexión básica entre los modelos de análisis y el modelo de diseño de sistema. No poder salvar este abismo hace que el sistema concebido y el sistema construido diverjan con el paso del tiempo.

En los sistemas orientados a objetos, es posible conectar todas las vistas casi independientes de un sistema en un todo semántico.

4. 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.

Dependiendo de la naturaleza del sistema pueden ser más importantes que otros.

MODELADO ORIENTADO A OBJETOS

En el software hay varias formas de enfocar un modelo. Las dos formas más comunes son la perspectiva orientada a objetos y la perspectiva algorítmica, esta última tiene una visión conduce a los desarrolladores a centrarse en cuestiones de control y de descomposición de algoritmos grandes en otros más pequeños y es algo complejo, mientras la visión orientada o objetos el principal bloque de construcción de todos los sistemas software es objeto o clase, es decir un objeto es una cosa, generalmente extraída del vocabulario del espacio del problema o del espacio de la solución; una clase es una descripción de un conjunto de objetos similares.

Actualmente, el enfoque orientado a objetos forma parte de la tendencia principal para el desarrollo de software, simplemente porque ha demostrado ser válido en la construcción de sistemas en toda clase de dominios de problemas, abarcando todo el abanico de tamaños y complejidades. (UML)

CAPITULO 2

PRESENTACIÓN DE UML

El Lenguaje Unificado de Modelado (Unified Modeling Language, UML), es un lenguaje estándar para escribir planos de software.

UML puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software.

Visión general de UML

UML es un lenguaje para:

 Visualizar

 Especificar

 Construir

 Documentar

UML es un lenguaje

Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la representación conceptual y física de un sistema, por lo tanto es un lenguaje estándar para los planos del software.

UML es un lenguaje para visualizar

Un programador cuando esta modelando tiene que pensar en:

Primero, la comunicación de esos modelos conceptuales a otros está sujeta a errores a menos que cualquier persona implicada hable del mismo lenguaje.

Segundo, que el software no puede entender a menos que se construyan modelos que trasciendan el lenguaje de programación textual.

Tercero, si el desarrollador que escribió el código no dejó documentación sobre los modelos, esa información se perderá y será parcialmente reproducible a partir de la implementación.

En UML es algo más que un simple montón de símbolos gráficos, en cada símbolo hay una semántica definida.

...