sábado, 20 de diciembre de 2008
FELIZZZ NAVIDAD !!!!!!!!!!!
Y COMO PARA ALEGRARLES EL DIA....
JEJJEJEJ -.......
miércoles, 19 de noviembre de 2008
informaworld
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
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
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
¿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
lunes, 17 de noviembre de 2008
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
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
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