INTRODUCCION 

 

 POR QUE MODELAMOS 

 

 Un modelo es un sistema software esta construida en un lenguaje de modelado,como UML El modelo tiene semanticay notacion y puede adoptar varios formatos que incluyen texto y graficos el modelo pretende ser mas fasil de usar para ciertos propositos que el sistema final .tambien un modelo es una representacion de algo en el mismo u otro medio , un modelo se expresa en un medio adecuado para el trabajo 

 

LA IMPORTANCIA DE MODELAR

 

los modelos se usan para barios propositos:

 

 - para captar  y enumerar exhaustibamente los requisitos  y el dominio de conocimient0 para         que todos los implicados  puedan entenderlos  y estar deacuerdo con ellos.

- para pensar del diseño de un sistema .

- para capturar decisiones del diseño  en una forma mutable a partir de los requisitos 

- para generar productos aprovechables para el trabajo .

- para organizar , encontrar,filtrar, recuperar, examinar y corregir la informacion en grandes          sistemas.

- para explotar economicamente multiples soluciones.

- para domesticar los sitemas complejos.

 

NIVELES DE LOS MODELOS

 

los modelos adquieren  diversas formas para diferentes propositos , y aparecen en diversos niveles de abstraccion . la cantidad de detalle del modelo debe adaptarse a uno de los siguientes 

propositos :

 

- Guias al proceso de pensamiento.

- Especificaciones abstractas de la estructura esencial de un sistema .
- Especificaciones completas de un sistema final.

- Ejemplos de sistemas tipicos o posibles.

- Descripciones completas o parciales de sistemas.

 

¿ QUE HAY EN UN MODELO?

 

semantica y presentacion 

los modelos tienen dos aspectos importantes:

 

informacion semantica y prestacion visual .

 

el aspecto semantico capta el significado de una aplicacion como una red de construcciones logicas  por ejemplo clases , asociaciones , estados , casos de uso y mensajes . los elementos semanticas del modelo llevan el significado del modelo , es desir,transportar la semántica. Los elementos semanticos del modelo de complejidades utilizan para la generacion del codigo, la comprobación de la validez

 

cual es el significado de un modelo

 

un modelo es un generador  de potenciales configuraciones de sistemas; son sus extenciones , o valores idealmente todas las configuraciones consistentes con el modelo  deberian ser posibles. A veces, sin embargo, no es posible representar todas las restricciones dentro  de un modelo. Un modelo  es siempre una abstracción a un cierto nivel, captura los aspectos esenciales de un sistema y omite algunos de los detalles. En los modelos hay que considerar los siguientes aspectos :

 

-          Abstracción frente a detalle

-          Especificación frente a implementación

-          Descripción frente a instancia

-          Variaciones en la interpretación

 

PRINCIPIOS DEL MODELADO

 

El uso del modelado tiene una historia interesante en todas las disciplinas de ingenieria. Esa experiencia sugiere cuatro principios basicos de modelado.

 

Primero: la eleccion de que modelos crear tiene una profunda influencia sobre como se acomete un problema y como se da forma a una solucion.

 

Segundo: todo modelo puede ser expresado a diferentes niveles de precision.

 

Tercero: los mejores modelos estan ligados a la realidad

 

Cuarto: un unico modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a travez de un pequeño conjunto de modelos casi independientes.

 

MODELADO ORIENTADO A OBJETOS

 

En el software hay varias formas de enfocar un modelo .las dos formas mas comunes son respectivamente algorítmica.

 

Visualizar , especificar , costruir y documentar sistemas orientados a objetos es exactamente el proposito del lenguaje unificado de modelado (UML)

PERSPECTIVA GENERAL DE UML

 

UML es un lenguaje para:

 

-          visualizar

-          especificar

-          construir

-          documentar

los artefactos de un sistema  con gran cantidad de software

 

UN MODELO CONCEPTUAL DE UML

 

Para comprender UML se necesita adquirir un modelo conseptual del lenguaje, y esto requiere aprender tres elementos principales : los bloques basicos de construccion de UML, las reglas que dictan como se puende combinar estos bloques basicos y algunos mecanismos comunes que se aplican a traves de UML.

BLOQUE DE CONSTRUCCION DE UML

El vocabulario de UML incluye tres clases de bloques de construccion

• Elementos
• Relaciones
• Diagramas

 

ELEMENTOS DE UML

• Elementos estructurales
• Elementos de comportamiento
• Elementos de agrupación
• Elementos de notacion

 

Estos son los bloques basicos de construccion orientados a Objetos de UML. Se utilizan para escribir modelos bien formados

ELEMENTOS ESTRUTURALES

Son los nombres de los modelos UML en su mayoria son las partes estaticas de un modelo y representan cosas, son conceptuales o materiales. En total hay siete tipos de elementos estructurales

Primero una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica.

Segundo un interfaz es una colección de operaciones que especifican un servicio de una clase o componente. Define un conjunto de especificaciones y operaciones

Tercero Una colaboración y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamietos de sus elementos por lo tanto la colaboración tiene dimension tanto estructural como de comportamiento

Cuarto Un caso de Uso es una descripción de un conjunto de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de interes para un actor en particular.

Quinto una clase activa es una clase en la cual sus objetos tienen uno o mas procesos o hilos. De ejecución y por lo tanto que pueden dar origen a actividades de control.

Sexto un componente es una parte fisica y reeplasable de un sistema que conforma un conjunto de interfaces y proporciona la implementacion de dicho conjunto

Septimo Un nodo es un elemento fisico que existe en tiempo de ejecución y representa un recurso computacional que por lo general dispone de algo de memoria y con frecuencia capacidad de procesamiento

ELEMENTOS DE COMPORTAMIENTO

Son las partes dinamicas de los modelos UML estos son verbos de un modelo y representan comportamiento en el tiempo y en el espacio

CAPITULO2

CONCEPTOS DE UML

Una clase es un descriptor de un conjunto de objetos que comparten los mismos atributos, operaciones comportamientos entre otros. Una clase representa un concepto dentro del sistema que se esta modelando.

Una clase es la descripción con nombre tanto de la estructura de datos como del comportamiento de un conjunto de objetos, esta se utiliza para declarar variables. Un objeto que es el valor de una variable debe tener una clase compatible con el tipo declarado para esa variable. Una clase también se utiliza  para instanciar objetos.

En UML una clase es un tipo de clasificador. Los clasificadores son elemento similares a las clases pero su expresión mas clara es la clase.

DIAGRAMAS

Un diagrama es una representación grafica de un conjunto de elementos, que la mayoría de las veces se dibuja como un grafo conexo de nodos y arcos. Los diagramas se utilizan para visualizar un sistema desde diferentes perspectivas.

Los buenos diagramas hacen compresible y accesible el sistema. La elección del conjunto adecuado de diagramas para modelar un sistema obliga a plantearse las cuestiones apropiadas sobre el sistema y ayuda a clarificar las implicaciones de las decisiones

Normalmente las partes estaticas de un sistema se representaran mediante uno de los cuatro diagramas siguientes

·         Diagrama de clases

·         Diagrama de Objetos

·         Diagrama de componentes

·         Diagrama de despliegue

A menudo se emplearan cinco diagramas adicionales para ver las partes dinamicas de un sistema

·         Diagramas de casos de uso

·         Diagramas de secuencia

·         Diagramas de colaboración

·         Diagramas de estados

·         Diagramas de actividades

Cada diagrama debe tener un nombre único en su contexto.

 

DIAGRAMAS ESTRUCTURALES

 

Los cuatro diagramas estructurales de UML existen para visualizar especificar construir y documentar los aspectos estáticos de un sistema

 

DIAGRAMAS DE CLASE

 

Un diagrama de clase presenta un conjunto de clases interfaces y colaboraciones y las relaciones entre ellas. Son los mas comunes en el modelado de sistemas orientado a objetos, estos se utilizan para describir la vista de diseño estatica de un sistema

DIAGRAMA DE OBJETOS

 

Representa un conjunto de objetos y sus relaciones. Se utilizan para descirbir estructuras de datos instantáneas de las instancias de los elementos encontrados en los diagramas de clases; Cubren la vista de diseño estatica o la vista de procesos estatica de un sistema pero desde la perspectiva de casos reales o prototípicos.

 

DIAGRAMAS DE COMPONENTES

 

Muestra un conjunto de componentes y sus relaciones, se utilizan para describir la vista de implementación estatica de un sistema

 

DIAGRAMAS DE DESPLIEGUE

 

UN diagrama de despliegue muestra un conjunto de nodos y sus relaciones, se utilizan para describir la vista estatica de una arquitectura y se relacionan con los diagramas de componentes.

 

DIAGRAMAS DE COMPORTAMIENTO

 

Los cinco diagramas de comportamiento de UML se emplean para visualizar especificar construir y documentar los aspectos dianmicos de un sistema

 

DIAGRAMAS DE CASO DE USO

Un diagrama de casos de usos representa u conjunto de casos de uso y actores y sus relaciones Se utilizan para describir la vista de casos de uso estatica de un sitema y som importantes para organizar y modelar el comportamiento de un sistema

DIAGRAMAS DE SECUENCIA

Es un diagrama de interaccion que resalta la ordenación temporal de los mensajes. Presenta un conjunto de objetos y los mensajes enviados y recibidos por ellos se utilizan para descibir la vista dinamica de un sistema

DIAGRAMAS DE COLABORACION

Es un diagrama de interaccion que reslata la organización estructural de los objetos que envía y reciben mensajes. Muestra un conjunto de objetos enlaces entre ellos y mensajes enviados y recibidos por los mismos.

DIAGRAMAS DE ESTADOS

Representa una maquina de estados constituida por estados transiciones, eventos, y actividades, modelan el comportamiento de un interfaz, una clase o una colaboración.

DIAGRAMAS DE ACTIVIDADES

Muestra el flujo de actividades de un sistema. Una actividad muestra un conjunto de actividades, el flujo secuencial o ramificado de actividades y los objetos que actúan y sobre los que actúan

VISTAS DE UML

Una vista es simplemente un subconjunto de UML  que modela construcciones que representa un aspecto de un sistema. Una o dos clases de diagramas proporcionan una notación visual para los conceptos de cada vista. Las vistas se pueden dividir en tres areas: clasificaion estructural, comportamiento dinamico y gestión del modelo.

VISTA ESTATICA

La vista estatica modela los conceptos del dominio de la aplicación asi como los conceptos internos inventados como parte de la implementación. Es estatica porque no describe el comportamiento del sistema dependiente del tiempo, que se describe en otras vistas.

Los componentes principales de la vista estatica son las clases y sus relaciones.

Las clases se dibujan como rectángulos, las listasde los atributos y de operaciones se muestran en compartimientos separados.

Las relaciones entre clases se dbujan  como líneas que conectan restangulos de clases. Las diversas clases de relaciones se diferencian por la textura de la línea y por los adornos en las líneas de sus extremos

VISTAS DE LOS CASOS DE USO

Esta vista modela la funcinalidad del sistema según actúen los usuarios exernos llamados actores. Un caso de uso es una unidad coherente de funcionalidad, expresadacomo transición entre los actores y el sistema.

VISTAS DE INTERACCION

Describe secuencias de intercambios de mensajes entre los roles que implementa el comportamiento de un sistema. Un rol de clasificador o simplemente rol, es la descripción de un objeto, que desempeña un determinado papel dentro de una interaccion distinto de los otros objetos de la  misma clase

EL DIAGRAMA DE SECUENCIA

Muestra un conjunto de mensajes dispuestos en una secuencia temporal, Cada rol en la secuencia se muestra como una línea vertical que representa el rol durante cierto plazo de tiempo, con la interaccion completa. Los mensajes se muestran como flechas.

Un uso de un doagrama de secuencia es mostrar la secuencia del comportamiento de un caso de uso.

EL DIAGRAMA DE COLABORACION

Modela los objetos y los enlaces significativos dentro de una interaccion. Los objetos y los enlaces son significativos solamente en el contexto proporcionado por la interaccion.

Un uso de un diagrama de colaboracio es mostrar la implementación de una operación. La colaboración muestra parámetros y las variables locales de la operación

Tanto los diagramas de secuencia como los diagramas de colaboración muesran interaccion pero acentúan aspectos diferentes. Un diagra de secuencia muestra secuencias  en el tiempo como dimensión geométrica, y un diagrama de colaboración muestra las relaciones entre roles geométricamente y relaciona los mensajes con las relaciones pero las secuencias temporales están menos claras porque vienen dadas por los números de secuencia.

VISTA DE LA MAQUINA DE ESTADOS

Una maquina de estados modela las posibles historias de vida de un objeto de una clase. Contiene los estados concectados por transiciones. Cada estado modela un periodo de tiempo durante la vida de un objeto en el que satisface ciertas condiciones.

Las maquinas de estado se pueden utilizar para describir interfaces de usuario controladores de un dispositivo y otros subsistemas reactivos.

VISTAS DE ACTIVIDADES

Es una variante de una maquina de estados que muestra las actividades implicadas en la ejecución de un calculo un estado de actividad representa una actividad. Un grafo de actividades descibe grupoes secuenciales y concurrentes de actividades

Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel de la ejecución de un sistema sin profundizar en los detalles nternos de los mensajes lo que requereria un diagrama de colaboración

VISTA DE IMPLEMENTACION

Las vistas anteriores modelan los concepto de la aplicación desde un punto de vista lógico. Esta vista proporciona una oportunidad de establecer correspondiecias entre las clases y los componentes de implementacion y nodos

La vista de implementación modela los componentes de un sistema asi como las dependencias entre los componentes, para poder determinar el impacto de un cambio propuesto.

RELACIONES

Al realizar abstracciones uno se da cuenta que muy pocas clases se encuentra aisladas, en ves de ello la mayoría colaboran con otras de varias maneras. Por lo tanto al modelar un sistema no solo hay que identificar los elemento que conformaam el vocabulario del sistema también hay que modelar como se relacionan estos elementos entre si

DEPENDENCIAS

Una dependencia es una relación de uso que se declara que un cambio en la especficacion de un elemento puede afectar a otro elemento que la utiliza pero no necesariamente a la inversa

GENERALIZACION

Es una relaco entre un elemento general y un caso mas especificp de ese elemento La generalización se llama a veces relación  “ es un tipo de “ la generalización significa que los objetos hijos pueden emplear cualquier lugar donde pueda aparecer el padre pero no a la inversa

ASOCIACION

Una asociación es una relación estructural que especifica que los objetos de un elemento están conectados con los onjetos de otro. Dada una asocacion entre dos clases se puede navegar desde un objeto de una clases hasta un objeto de la otra clase y viceversa

CAPITULO 3

INTRODUCCION

Los casos de uso son u fenómeno interesante, durante mucho tiempo  tanto en el desarrollo orientao a objetos como en el tradicional, las personas se auxiliaban de escenarios típicos que le ayudaba a comprender los requeriemitnos.

TERMINOS Y CONCEPTOS

Un caso de uso es una descripción de un conjuntode secuencias de acciones incluyendo variantes que ejecutan un sisema para producir un resultado observable de valor para un actor

NOMBRES

Cada caso de uso debe tener un nombre que lo distinga de otros casos de uso un nobre es una cadena de texto. Ese nombre solo se llama nombre simple. El nombre  de un  caso de uso puede constar de tecto con cualquier numero de letras, números y la mayoría de los sigos de puntuación.

CASOS DE USO Y ACTORES

Un actor representa un conjunto coherente de roles que los usuarios de llos casos de uso juegan al interactuar con estos. Normalmente un actor representa un rol que es jugado por na persona un dspositivo hadtware o incluso otro sistema al ineractuar con nuestro sistema.

Los mecanismo de extensibilidad de UML se pueden utilizar para estereotipar un actor con el fin de proporcionar un icono diferente que pofresca una señal mas apropiada a los abjetivos que se persiguen

Los actores solo se pueden conectar a los caso de uso a través de asociaciones

CASOS DE USO Y FLUJO DE EVENTOS

Un caso de uso describe que hace un sistema( o un subsstema, una clas o un interfaz)pero no especifica como lo hace. Cuando se modela, es importante tener clara la separación de objetivos entre las vistas externa e intena

El flujo de eventos de un cao se puede especificar de muchas formas incluyendo texto estructurado informal, texto estructurado formal y pseudocódigo.

CASOS DE USO Y ESCENARIOS

Normalmente primero se describe el flujo de eventos de un caso de uso mediante texto. Sin embargo, Conforme se mejora la comprensión de los requisitos del sistema estos flujos se pueden especificar gráficamente mediante diagramas de interaccion.

Normalmente se usa un diagrama de secuencia para especificar el flujo principal de un caso de uso

Conviene separa el flujo principal de los alternativos porque un cas de uso describe un conjunto de secuncias no una única secuencia y seria imposible expresar todos los detalles de un caso de uno no trivial en una única secuencia

CASOS DE USO Y COLABRACIONES

Un caso de uso captura el comportamiento esperado del sistema que se esta desarrollando sin tener que especificar como se implementa ese comporamiento. Esta separación es importante porque el análisis de un sistema no debería estar influenciado mientras sea posible po cuestiones de iplementacion

El objetivo de la arquitectura de un sistema es encontrar el conjunto minimo de colaboraciones bien estructuradas que satisfacen el flujo de eventos especificando todos los casos del sistema

ORGANIZACIÓN DE CASOS DE USO

Los casos de uso pueden organizarse agrupándolos en paquetes de la misma manera que se organizan las clases. Tambien pueden organizarse especicando relaciones de generalización inclusión y extencion entre ellos. Estas relaciones se utilizan para factorizar el comportamiento común y para factorizar variantes.

Una relación de inclusión entre casos de uso significa que un caso de uso base incorpora expicitametne el comportamiento de otro caso de uso en el lugar especificado en el caso base. El caso de uso incluido nunca se ecuentra aislado sino que es istanciado solo como parte de algún cas de uso base mas amplio que lo incluye.

OTRAS CARACTERISTICAS

Los casos de uso tabien son clasificadores de forma que pueden tener operaciones y atributos que se pueden representar igual que en las clases.

PROPIEDADES COMUNES

Un diagrama de uso es un tipo especial de diagramay cmparte las propiedades comunes al resto de los diagramas. Lo que distingue a un diagrama de casos de uso de los otros tipos de diagramas es su contenido particular:

CONTENIDO

·         Casos de uso

·         Actores

·         Relaciones de dependencia, generalización y asociación

Al igual que los demás diagramas los diagramas de casos de uso pueden contener notas y restricciones

Los diagramas de uso también pueden contener paquetes que se emplean para agrupar elementos del modelo en partes mayores

USOS COMUNES

Los diagramas de asos de uso se usan para modelar la cista de casos de uso estatico deun sistema esta vista cubre princippalmenteel comportamiento del sitema

Cuando se modela la vista de caso de uso estatico de un sitema normalmente se empleara los diagramas de caso de uso de la siguiente forma

·         Modelar contexto de un sistema

·         Modelar requisitos de un sistema

CUANDO EMPLEAR CASOS DE USO

Siempre ya que es una herramienta escencial para la captura de los requerimeintos, la planificación p el control de proyectos iterativos