informaworld

Informaworld es una biblioteca virtual, ya que ahi se puede encontrar información y conocimientos que le permitan a sus clientes realizar su trabajo de manera eficiente.
Se puede buscar y ojear las revistas, libros y obras de referencia de manera gratutita.
Para leer el texto integral hace falta abonarse a la revista, libro u obra de referencia. Se requiere una suscripción para acceder al Abstract Database. Cuando se encuentra un articulo que se quiera leer se puede comprar y se descarga inmediatamente.
Informa plc es el proveedor líder de información especializada académica y científica, profesionales y comerciales:

• Todas las revistas de Taylor & Francis, Routledge y Psicología de prensa
• Más de 180 revistas de Salud Informa
• Selección de enciclopedias (la antigua colección enciclopedia Dekker) de Taylor & Francis Informa y Salud
• Todos los Taylor & Francis resumen las bases de datos
• Más de 10.000 libros electrónicos de Taylor & Francis, Routledge y Salud Informa

SOCIEDAD DE LA INFORMACION

SOCIEDAD DE LA INFORMACION

En esta parte de la pagina se muestra toda la sociedad de cambio de la informacion en cual como la tecnologia se vuelve en algo cotidiano y muy util y de facil acceso a la informacion de los usuarios, pero a la vez la dificultad de acceder a un informacion fiable puesto que existe una cantidad de informacion inagotable, y a la vez distorcionada, puesto que cuando uno busca una informacion a veces ocurre que encuentra cosas que no tienen nada de relacion con lo buscado, todos formamos parte de la sociedad de la informacion, ya que todos interactuamos en este mundo cambiante, buscando informacion, colocando informacion, procesando informacion, en forma casi constante.

LA WEB 2.0

En esta parte nos muestra todas aquellas utilidades y servicios de Internet que se sustentan
en una base de datos, la cual puede ser modicada por los usuarios del servicio, ya sea en su contenido, bien en la forma de presentarlos, o en contenido y forma simultaneamente.
Nos muestra como AdSense que es un sistema de publicidad ideado por Google.
en el cual los webmasters pueden unirse a este sistema para activar textos e imagenes publicitarias en sus paginas web. Estos anuncios estan administrados por Google y generan
ingresos basandose en los clicks de los visitantes de la pagina y en las visualizaciones de la misma.

InformaWorld

¿Que es informaworld?

Informaworld es el punto de partida para su investigación. Contiene artículos publicados en las mejores revistas, elibros y obras de referencia, buscar en informaworld garantiza buenos resultados.

www.informaworld.com 19.nov.2008 10:54 am

resumen de UML

Capítulo I

¿Por qué modelamos?
Para captar los aspectos más importantes de lo que estamos modelando, desde cierto punto de vista que simplifica u omite el resto. Un modelo de sistemas se software está construido en un lenguaje modelado como UML el modelo tiene semántica y notación y puede adoptarse varios formatos que incluyen texto y grafico.

Importancia de modelar

Su importancia se basa en captar o enumerar los requisitos y el dominio del conocimiento de forma que todos los implicados puedan entenderlo y estar de acuerdo con ellos; para pensar el diseño de un sistema; para capturar decisiones de diseño en una forma mutable a partir de los requisitos; para generar productos aprovechables para el trabajo.

Niveles de un modelo
Ø Guías de procesos de pensamiento.
Ø Especificaciones abstractas de la estructura esencial de un sistema.
Ø Especificaciones completas de un sistema final.
Ø Descripciones completas o parciales de sistemas.
¿Qué hay en un modelo?
La información semántica (semántica) y prestación visual (notación).
El aspecto semántico capta el significado de una aplicación como una red de construcciones como clases asociaciones, estados, casos de uso y mensajes.
El aspecto visual es irrelevante para las herramientas que procesan modelos.
¿Cuál es el significado de un modelo?
Es un generador de potenciales y de sistemas. Todas las configuraciones consistentes deberían ser posibles. Se debe 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

Hay cuatro tipos básicos de modelaje: la elección de que modelos crear tiene una profunda influencia sobre cómo se acomete un problema y como se va dar la solución, todo modelo puede ser expresado a diferentes modelos de precisión, los mejores modelos están ligados a la realidad y un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos independientes.

Modelo orientado a objetos
El principal bloque de construcción de todos los sistemas software es el objeto o clase. Proporciona la base fundamental para ensamblar sistemas a partir de componentes usando tecnologías como Java, Veans o COM.
Perspectiva General de UML:Visión general de UML:
UML es un lenguaje para:
Ø Visualizar.
Ø Especificar.
Ø Construir.
Ø Documentar.
Bloques de construcción de UML:
Ø Elementos
Ø Relaciones
Ø Diagramas
Ciclos de Vida del desarrollo de Software
Ø Dirigido por los casos de uso.
Ø Centrado en la arquitectura.
Ø Iterativo e incremental.
Objetivos de UML
Ø El más importante, UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores.
Ø No pretende ser un método de desarrollo completo.
Ø Pretende trabajar correctamente con todos.
Ø Ser lo más simple posible manteniendo la capacidad de modelar cualquier tipo de sistema que necesite construir.
Áreas conceptuales de UML
Ø Estructura estática.
Ø Comportamiento dinámico.
Ø Construcción de implementación.
Ø Organización del modelo.
Ø Mecanismos de extensión.
Capítulo II
Conceptos de UMLClases y ObjetosUna clase es un descriptor de un conjunto de objetos que comparten los mismos atributos, operaciones, métodos, relaciones y comportamientos, una clase consta de un nombre de una lista de atributos y una lista de operaciones. Un objetivo que es un valor de una variable debe tener una clase compatible con el tipo declarado para esa variable..DiagramasSon representaciones graficas de un conjunto de elementos. Y pueden ser:Diagramas Estructurales
Ø Diagramas de clases.
Ø Diagramas de objetos.
Ø Diagramas de componentes.
Ø Diagramas de despliegue.
Diagramas de Comportamiento
Ø Diagramas de casos de uso.
Ø Diagramas de secuencia.
Ø Diagramas de colaboración.
Ø Diagramas de estados.
Ø Diagramas de actividades
Vistas de UML
Una vista es un subconjunto de UML que modela construcciones que representan un aspecto de un sistema. Una o dos clases de diagramas proporcionan una notación visual para los conceptos de cada vista.
Vista Estática: Modela los conceptos del dominio de la aplicación, así como los conceptos internos inventados como parte de la implementación.
Vista de los Casos de Uso: Modela la funcionalidad del sistema según actúen los usuarios externos llamados actores.
Vista de Interacción: Describe secuencias de intercambio de mensajes entre los roles que implementan los comportamientos de un sistema.
Ø Diagrama de secuencia: Muestra un conjunto de mensajes, dispuestos en una secuencia temporal.
Ø Diagrama de colaboración: Modela los objetos y los enlaces significativos dentro de una interacción.
Vista de la Maquina de Estados: Modela las posibles historias de vida de un objeto de una clase.
Vista de Actividades: Es una variante de una máquina de estados, que muestra las actividades implicadas en la ejecución de un cálculo.
Vistas de Implementación: Proporciona una oportunidad de establecer correspondencias entre las clases y los componentes de implementación y nodos.Vista de Gestión del Modelo: Modela la organización del modelo en sí mismo.Relaciones
Ø Dependencia: Declara que un cambio en la especificación de un elemento puede afectar a otro elemento que lo utiliza.
Ø Generalización: Relación entre un elemento general y un caso más específico de ese elemento.
Ø Asociación: Relación estructural que específica que los objetos de un elemento están conectados con los objetos de otro.
Capítulo III
Casos de usos
Es una descripción de un conjunto de secuencias de acción, incluyendo variantes, que ejecute un sistema para producir un resultado observable de valor para un actor, gráficamente un caso de uso se representa como una elipse.
Casos de usos y actores
Un actor representa un conjunto coherente de roles que los usuarios de los casos que uso juegan al interactuar con estos. Normalmente representa a un sistema, persona o dispositivo de hardware.
Casos de uso y flujo de evento
El comportamiento de un caso de uso se puede especificar describiendo un flujo de eventos de forma textual o suficientemente claro para que para que alguien ajeno al sistema los entienda fácilmente.
Casos de uso y escenarios
El flujo principal separar por los flujos alternativos, porque un caso de uso describe un conjunto de secuencias, no una única secuencia y sería imposible expresar todo los detalles de un caso de uso trivial.
Caso de uso y colaboraciones
El objetivo de la arquitectura de un sistema es encontrar el conjunto mínimo de colaboraciones bien estructuradas que satisfacen el flujo de eventos.
Organización de los casos de uso
La organización de los casos de uso considerando la extracción de comportamientos comunes y la distinción de variantes y es muy importante para la creación de un conjunto de casos de uso del sistema que sea sencillo equilibrado y comprensible.
Modelación de los casos de usos
Modelación del comportamiento: se utilizan para el modelado del comportamiento de un elemento, ya sea un sistema completo, un subsistema o una clase.
Modelación del contexto de un sistema: en UML ase puede modelar al contexto de un sistema con un diagrama de caso de uso destacando los actores en torno al sistema.
Modelos de los requisitos de un sistema: un requisito es una característica de diseño, una propiedad o un comportamiento de un sistema.Ingeniera directa e inversa: es el proceso de trasformar un modelo en código a través de un lenguaje de implementación.

UML

ROBERT ALEXANDER HANCCO ROMERO

UML

El modelo capta los aspectos importantes de lo que estamos modelando y simplifica el resto.

NIVELES DE LOS MODELOS

La cantidad de detalle del modelo debe adaptarse a los siguientes propósitos:

-Guías al proceso de pensamiento.-Especificaciones abstractas de la estructura esencial de un sistema.

-Especificaciones completa de un sistema final.

-Ejemplos de sistemas típicos o posibles.

-Descripciones completas o parciales de un sistema.

¿CUÁL ES EL SIGNIFICADO DE UN MODELO?

Es un generador de potenciales configuraciones de sistemas, también es una descripción de la estructura genérica y del significado de un sistema.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.

SECCIÓN 2:PERSPECTIVA GENERAL DE UML:

Es un lenguaje para visualizar. Detrás de cada símbolo de la notación de

UML hay una semántica bien definida. De esta manera, un desarrollador puede escribir un modelo en UML, y otro desarrollador, o incluso otra herramienta puede interpretar esa herramienta sin ambigüedad.

CICLO DE VIDA DEL DESARROLLO DE SOFTWARE

-Dirigido por los casos de uso significa que los casos de uso se utilizan como un artefacto básico para establecer el comportamiento deseado del sistema, para verificar y validar la arquitectura del sistema, para las pruebas y para la comunicación entre las personas involucradas en el proyecto.

-Centrado en la arquitectura significa que la arquitectura del sistema se utiliza como un artefacto básico para conceptuar, construir, gestionar y hacer evolucionar el sistema en desarrollo.

-Un proceso iterativo es aquel que involucra la gestión de un flujo de ejecutables del sistema.

HISTORIA DE UML

LOS MÉTODOS DE DESARROLLO ORIENTADO A OBJETOS

Emergieron en los años 70 y fueron difundidos en los 80. Alcanzaron cierta penetración en le área de los grandes sistemas.El primer lenguaje que es generalmente reconocido como orientado a objetos es Simula 67, desarrollado en 1967. El movimiento de orientación de objetos se hizo popular en los 80’s.Aparecieron muchos libros cuyos temas estaban enfocados en el modelaje orientado a objetos.

¿QUÉ SIGNIFICA UNIFICADO?-A través de los métodos históricos y notaciones.-A través de los dominios de aplicación.-A través de los lenguajes de implementación y plataformas.-A través de procesos de desarrollo.-A través de los conceptos internos.

OBJETIVOS DE UML

-UML es un lenguaje de propósito general que pueden utilizar todos los programadores.-basado en el común acuerdo.-Pretende abordar los problemas actuales de desarrollo de software.-UML pretende trabajar correctamente con todos.

-UML incluye todos los conceptos que consideramos necesarios para utilizar un proceso moderno iterativo.-Ser tan simple como fuera posible.

CLASES Y OBJETOSUna clase es un descriptor de un conjunto de objetos que comparten los mismos atributos, operaciones, métodos, relaciones y comportamiento. Un objeto es el valor de una variable.

DIAGRAMAS DE UML

Es una representación gráfica de un conjunto de elementos, se utilizan para visualizar un sistema desde diferentes perspectivas.

DIAGRAMAS ESTRUCTURALES

-Diagramas de clases.-Diagramas de objetos.-Diagramas de componentes.-Diagramas de despliegue.DIAGRAMAS DE COMPORTAMIENTO

-Diagramas de casos de uso-Diagramas de secuencia.-Diagramas de colaboración.

-Diagramas de estados.

-Diagramas de actividades.

VISTA DE LOS CASOS DE USO

Modela la funcionalidad del sistema según actúen los usuarios externos llamados actores.RELACIONESSe da entre los objetos.

DEPENDENCIARelación de uso que declara que un cambio en la especificación de un elemento puede afectar a otro elemento que lo utiliza.

GENERALIZACIÓNRelación entre un elemento general y un caso más específico de ese elemento.ASOCIACIÓNRelación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro.

CAPÍTULO 3:

NOMBRES

Cada caso debe tener un nombre que lo distinga de otros casos de uso. Es una cadena de texto.

CASOS DE USO Y ACTORES

Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso juegan al interactuar con éstos.

CASOS DE USO Y FLUJO DE EVENTOS

El comportamiento de un caso de uso se puede especificar describiendo un flujo de eventos de forma textual, lo suficientemente claro para que alguien ajeno al sistema lo atienda fácilmente.CASOS DE USO Y COLABORACIONES

Un caso de uso debe implementarse al fin y al cabo, y esto se hace creando una sociedad de clases y otros elementos que colaborarán para llevar a cabo el comportamiento del caso de uso.

ORGANIZACIÓN DE CASOS DE USO

Pueden organizarse agrupándolos en paquetes. También pueden agruparse especificando relaciones de generalización, inclusión y extensión entre ellos.

CONTENIDOS

Un diagrama de casos de uso contiene.-Casos de uso.-Actores.-Relaciones de dependencia, generalización y asociación.

USOS COMUNES-Para modelar el contexto de un sistema.-Para modelar los requisitos de un sistema.

OBJETIVOS DEL USUARIO E INTERACIONES CON EL SISTEMA

Los verdaderos objetivos del usuario se describirán con términos como “garantizar el formateo consistente de un documento” y “hacer que el formato de un documento sea igual que el de otro”. Las interacciones con el sistema permiten decir que los casos de uso incluirán cosas como: “define estilo”, “cambia estilo” y “mueva un estilo de un documento a otro”.

CUANDO EMPLEAR CASOS DE USO

La captura de los casos de uso es una de las tareas principales durante la fase de elaboración; de hecho es lo primero que se debe hacer, aunque ese usa en otras fases también.

MODELADO DE LOS REQUISISTOS DE UN SISTEMA

-Establecer el contexto del sistema.

-Considerar el comportamiento de cada actor.

-Nombrar esos comportamientos comunes como casos de uso.

-Factorizar el comportamiento común en nuevos casos de uso que puedan ser utilizados por otros.-Modelar los casos de uso, actores y relaciones en un diagrama de casos de uso.

-Adornar esos casos de uso con notas que enuncien los requisitos no funcionales.

INGENIERÍA DIRECTA E INVERSA

La ingeniería directa es el proceso de transformar un modelo en código a través de una correspondencia con un lenguaje de implementación.La ingeniería inversa es el proceso de transformar código en un modelo a través de una correspondencia a partir de un lenguaje de implementación específico.

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

 

Sociedad de la Información y Gestión del Cambio

Vivimos en una sociedad de la información donde la competencia, las tecnologías de información y comunicación, y el mercado en general, imponen cada vez más presión sobre la productivdad y la eficiencia en la administración de las organizaciones y las personas que las conforman. Se hace inevitable que las empresas comprendan el significado de vivir en una sociedad de la información y se vean inmersas en la misma, ya sea para reaccionar frente a los cambio en el entorno, para dar soluciones tecnológicas prontas y para introducir nuevas estrategias de crecimiento. Frente a esto se hace necesaria la capacidad de poder gestionar el cambio, asimilando y utilizando las nuevas tecnologías, haciendo un correcto uso de la exhuberante cantidad de información disponible, creando procesos de mejora de calidad, reestructuraciones y acomodaciones a las nuevas circunstancias de la globalización.

UML

¿Por qué modelamos?

El modelo capta los aspectos mas importantes de lo que estamos modelando desde cierto punto de vista ,y simplifica y omite el resto.un modelo de sistema de software organiza la información en varias vistas estructura estatica maquinas de estado,interacciones ,requisitos.

Niveles de modelo

Especificaciones abstractas de la estructura esencial de un sistema
Especificaciones completas de un sistema final
Descripciones completas o parciales de un sistema

¿Qué hay en un modelo?

Los modelos tienen dos aspectos importantes
Información semántica(semántica)
Presentacion visual(notacion)

¿Cuál es el significado de un modelo?

Es un generador de potencias configuraciones de sistemas tinen diferentes aspectos como:

· Abstracción frente a detalle
· Especificación frente a implementacion
· Descripción frente a instancia
· Variación en la interpretación

Principios del modelado

1. la eleccion de que modelos crear tiene una profunda influencia sobre como se acomete uyn problema y como se dara forma a una solucion
2. todo modelo puede ser expresado a diferentes modelos de precision
3. los mejores modelos estan ligados a la realidad
4. un unico modelo no es suficiente . Cualquier sistema no trivial se aborda mejor a traves de un pequeño conjunto demodelos casi independientes

Vision general del UML

· Visualizar
· Especificar
· Construir
· Documentar
Relaciones con el UML

· Dependencia
· Asociación
· Generalización
· Realización

Historia del UML

Fue desarrollado para ayudar y simplificar y consolidar un gran numero de métodos de desarrollo orientado a objetos que había surgido.

Objetivos del UML

El primero y el mas importante .Es que el UML es un modelo de lenguaje de pueden usar todos los modeladores .mantener
La capacidad de modelar toda la gama de sistemas que se necesita construir.

Diagramas estructurales

Diagrama de clase
Diagrama de objetos
Diagrama de componentes
Diagrama de despliegue

Diagramas de comportamiento

Diagrama de casos de uso
Diagrama de secuencia
Diagrama de colaboracion
Diagrama de estado
Diagramas de actividades

Relaciones

Al modelar un sistema no solo hay que identificar no solo hay que identificar los elementos que conforman el vocabulario del sistema sino tambien hay que modelar como se relacionan estos elementos entre si

Dependencia

En una relacion de uso que declara que un cambio es la especificación de un elemento puede Afectar a otro elemento que la utiliza pero no necesariamente a la inversa.

Generalización

Es la relacion de un elemento general(superclase o padre) y un caso mas especifico de ese elemento (subclase o hijo) . la generalización significa que los objetos hijos se pueden emplear en cualquier lugar en donde puede aparecer el padre, pero no a la inversa.

Asociación

Es una relacion estructural que especifica que los objetos de un elemento estan relacionados con el otro.Dada una asociación entre dos clases se puede navegar desde un objeto de una clase hasta el objeto de la otra o viceversa .


Casos de uso

Los casos de uso son un fenómeno interesante ,es una descripción de un conjunto de secuencias de acciones incluyendo variantes que ejecutan un sistema para producir un resultado observable de valor para el usuario.graficamente el caso de uso se usa con elipses.

Nombres; cada caso debe tener una distinción de significados puede constar de un texto con cualquier numero de letras u signos .

Casos de uso y flujo de eventos

Un caso de uso describe lo que hace un sistema pero no especifica como lo hace el comportamiento de un caso de uso se puede especificar describiendo un caso de flujos y eventos de forma textual ,suficiente claro para que alguien ajeno al sistema lo pueda entender fácilmente ,

Caso de uso y escenario

Conforme a la mejora de especificaron de sistema se pueden especificar gráficamente mediante digramas de especificación
Normalmente se usa un diagrama de secuencia para especificar el flujo principal de un caso de uso y se usan variaciones de ese diagrma para especificar los flujos esepcionales del caso de uso.

Caso de uso y colaboraciones

Captura el comportamiento esperado del sistema que se esta desarrollando sin tener que especificar como se implementa ese comportamiento.Esta separacion es importante porque el analisis de un sistema no deberia estar influenciado mientras sea posible mediante cuestiones de implementacion que especifican como se lleva el comportamiento.

Organización de caso de uso

Se pueden organizar tambien por:
Generalización
Inclusión
Extencion

Propiedades comunes

Es un tipo especial de diagrama se distinguen por su contenido particular