Ciclo de vida del software 1.2.2.

1
El desarrollo de software va unido a un ciclo de vida compuesto por una serie de etapas que comprenden todas las actividades, desde el momento en que surge la idea de crear un nuevo producto software, hasta aquel en que el producto deja definitivamente de ser utilizado por el ltimo de sus usuarios. como sugiere el modelo en cascada o lineal, puede implicar serios problemas

Etapas en el ciclo .Veamos, a grandes rasgos, una pequea descripcin de

etapas con que podemos contar a lo largo del ciclo de vida del software; una vez delimitadas en cierta manera las etapas, habr que ver la forma en que estas se afrontan (existen diversos modelos de ciclo de vida, y la eleccin de un cierto modelo para un determinado tipo de proyecto puede ser de vital importancia; el orden de las etapas es un factor importante, p.ej. tener una etapa de validacin al final del proyecto, talsobre la gestin de determinados proyectos; hay que tener en cuenta que retomar etapas previas es costoso, y cuanto ms tarde se haga ms costoso resultar, por tanto el hecho de contar con una etapa de validacin tarda tiene su riesgo y, por su situacin en el ciclo, un posible tiempo de reaccin mnimo en caso de tener que retornar a fases previas):
Expresin de necesidades

Esta etapa tiene como objetivo la consecucin de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecer al usuario del sistema a desarrollar (qu, y no cmo, se va a desarrollar). Dado que normalmente se trata de necesidades del cliente para el que se crear la aplicacin, el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relacin comercial, siendo que debe ser comprendido por ambas partes (puede incluso tomarse como base para el propio acuerdo comercial). EspecificacionesAhora se trata de
formalizar los requerimientos; el documento obtenido en la etapa anterior se tomar como punto de partida para esta fase. Su contenido es an insuficiente y lleno de imprecisiones que ser necesario completar y depurar. Por medio de esta etapa se obtendr un nuevo documento que definir con ms precisin el sistema requerido por el cliente (el empleo de los casos de uso, use cases, de Jacobson es una muy buena eleccin para llevar a cabo la especificacin del sistema). Lo ms normal ser que no resulte posible obtener una buena especificacin del sistema a la primera; sern necesarias sucesivas versiones del documento en que irn quedando reflejada la evolucin de las necesidades del cliente (por una parte no siempre sabe en los primeros contactos todo lo que quiere realmente, y por otra parte pueden surgir cambios externos que supongan requerimientos nuevos o modificaciones de los ya contemplados).

AnlisisEs necesario determinar que elementos intervienen en el sistema a desarrollar, as como su

estructura, relaciones, evolucin en el tiempo, detalle de sus funcionalidades, ... que van a dar una descripcin clara de qu sistema vamos a construir, qu funcionalidades va a aportar y qu comportamiento va a tener. Para ello se enfocar el sistema desde tres puntos de vista relacionados pero diferentes:

Funcional. Esttico. Dinmico.

Diseo
Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar como va a hacerlo (cmo debe ser construido el sistema?; aqu se definirn en detalle entidades y relaciones de las bases de datos, se pasar de casos de uso esenciales a su definicin como casos expandidos

reales, se seleccionar el lenguaje ms adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, libreras, configuraciones hardware, redes, etc.).
Observacin: Aunque todo debe ser tratado a su tiempo, y sera muy deseable que las decisiones correspondientes en esta etapa fueran tomadas precisamente en esta etapa, muchas veces nos vamos a encontrar con unas decisiones previamente impuestas sobre lenguaje, plataforma, etc. Unas veces se dirn justificadas en simple poltica de empresa y por mantener "compatibilidad" en lo que respecta a los dems proyectos de la propia empresa, y en otras ocasiones por rumores de que tal o cual herramienta mejorara la velocidad de desarrollo u otro aspecto de inters (en parte de los casos no sern rumores con fundamento o estudios previos realizados al efecto, sino ms bien debidos a la propia publicidad como consejera).

Implementacin
Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programacin y/o para un determinado sistema gestor de bases de datos.
Observacin: Lamentablemente en la actualidad, ao 2.000, quedan bastantes empresas en las que, tras una reunin comercialen que tan solo se ha conseguido recabar una breve lista de requerimientos, a pesar de tener que enfrentarse a proyectos grandesmedios, se pasa directamente a la etapa de implementacin; son proyectos guiados por el riesgo que supone adoptar un modelo de ciclo de vida de codificar-corregir (code and fix) donde se eliminan las fases de especificaciones, anlisis y diseo con la consiguiente prdida de control sobre la gestin del proyecto.

Pruebas El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseo y/o programacin. Es conveniente que sean planteadas al menos tanto a nivel de cada mdulo (aislado del resto), como de integracin del sistema (segn sea la naturaleza del proyecto en cuestin se podrn tener en cuenta pruebas adicionales, p.ej. de rendimiento). Validacin Esta etapa tiene como objetivo la verificacin de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase tambin es interesante contar con los use cases, generados a travs de las correspondientes fases previas, que servirn de gua para la verificacin de que el sistema cumple con lo descrito por estos). Mantenimiento y evolucin
Finalmente la aplicacin resultante se encuentra ya en fase de produccin (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondr ya pequeas operaciones tanto de correccin como de mejora de la aplicacin (p.ej. mejora del rendimiento), as como otras de mayor importancia, fruto de la propia evolucin (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto La mayora de las veces en que se desarrolla una nueva aplicacin, se piensa slamente en un ciclo de vida para su creacin, olvidando la posibilidad de que esta deba sufrir modificaciones futuras (que tendrn que producirse con casi completa seguridad para la mayor parte de los casos).

1.2.2.2 desarrollo en cascada, tambin llamado modelo en cascada, es el enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la inmediatamente anterior.Un ejemplo de una metodologa de desarrollo en cascada es: 1. 2. 3. 4. 5. 6. 7. Anlisis de requisitos Diseo del Sistema Diseo del Programa Codificacin Pruebas Implantacin Mantenimiento

De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto.

1..2.2.3desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1988, utilizado generalmente en la Ingeniera de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteracin representa un conjunto de actividades. Las actividades no estn fijadas a priori, sino que las siguientes se eligen en funcin del anlisis de riesgo,

1.2.2.4 mtodo iterativo trata de resolver un problema (como una ecuacin o un sistema de ecuaciones) mediante aproximaciones sucesivas a la solucin, empezando desde una estimacin inicial. Esta aproximacin contrasta con los mtodos directos, que tratan de resolver el problema de una sola vez (como resolver un sistema de ecuaciones Ax=b encontrando la inversa de la matriz A). Los mtodos iterativos son tiles para resolver problemas que involucran un nmero grande de variables (a veces del orden de millones), donde los mtodos directos tendran un coste prohibitivo incluso con la potencia del mejor computador disponible. Polimorfismo: describe mltiples y posibles estados de una nica propiedad. Es una de las
propiedades fundamentales de la programacin orientada a objetos

se denomina encapsulamiento al ocultamiento del estado, es decir, de los datos miembro, de un objeto de manera que slo se puede cambiar mediante las operaciones definidas para ese objeto. Cada objeto est aislado del exterior, es un mdulo natural, y la aplicacin entera se reduce a un agregado o rompecabezas de objetos. El aislamiento protege a los datos asociados a un objeto contra su modificacin por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones. Programacion Orientada a Objetos (POO): Metodo de Implementacion en el que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de alguna clase, y cuyas clases son miembros de una jerarquia de clases unidas mediante relaciones de herencia. En tales programas las clases suelen verse estaticas, mientras que los objetos suelen tener una naturaleza mucho mas dinamica, promovida por la evidencia de la ligadura dinamica y el polimorfismo. Objeto: Algo a lo cual se le puede hacer cosas. Un objeto tiene un estado, comportamiento e identidad; la estructura y comportamiento de objetos similares se definen en una clase comun. Los terminos instancia y objeto son intercambiables. Clase: Conjunto de objetos que comparten una estructura comun y un comportamiento comun. Los terminos y clase y tipo suelen ser (no siempre) equivalentes; una clase es un concepto ligeramente diferente del de un tipo, en el sentido de que enfatiza la clasificacion de estructura y comportamiento. Encapsulacin: El proceso de introducir en el mismo comportamiento los elementos de abstraccion que constituyen su estructura y comportamiento; el encapsulamiento sirve para separar el interfaz contractual de una abstraccion y su implantacion. Abstraccion: Las caracteristicas esenciales de un objeto que lo distiguen de todos los demas objetos y proporcionan asi fronteras conceptuales definidas con nitidez en relacion con la prespectiva del observador; el proceso de centrarse en las caracteristicas esenciales de un objeto. La abstraccion es uno de los elementos fundamentales del modelo de objetos. Herencia: Relacion entre clases, en la que una clase comporte la estructura y comportamiento definido en otra (herencia simple) u otras (herencia multiple) clases. La herencia define una relacion de tipo entre clases en la que una subclase hereda de una o mas superclases generalizadas, una subclase suele especializar a sus superclases aumentando o refinando la estructuras y comportamiento existentes. Polimorfismo: Un concepto de teoria de tipos, de acuerdo con el cual un nombre (como declaracion de una variable) puede denotar objetos de muchas clases diferentes que se relacionan mediante alguna superclase comun; asi todo objeto denotado por este nombre es capaz de responder a algun conjunto comun de operaciones de diferentes modos. Ligadura dinmica y estatica: Ligadura denota asociacion de un nombre (como un declaracion de un variable) con una clase; ligadura dinamica es una ligadura en la que la asociacion nombre/clase no se realiza hasta que el objeto designado por le nombre se crea en tiempo de ejecucion; ligadura estatica es una ligadura en la que la asociacion

nombre/clase se realiza cuando se declara el nombre (en tiempo de compilacion) pero antes de la creacion del objeto se designa el nombre. Mensaje: Operacion que un objeto realiza sobre otro. Los terminos mensaje, metodo o operacion suelen ser equivalentes. Metodo: Operacion sobre un objeto, definida como parte de la declaracion de una clase; todos los metodos son operaciones, pero no todas las operaciones son metodos. Los terminos mensaje, metodo o operacion suelen ser equivalentes. Comportamiento: Como actua y reacciona un objeto, en terminos de sus cambios de estado y su paso de mensajes; la actividad exteriormente visible y comprobable de un objeto. Clase abstracta: Una clase que no tiene instancias. Una clase abstracta se escribe con la intencion de que sus subclases concretas aadan elementos nuevos a sus estructura y comportamiento, normalmente implementas en operaciones abastractas. Clase base: La clase mas generalizada en una estructuras de clases. La mayoria de las aplicaciones tienen muchas de tales clases raiz. Algunos ejemplos definen una clase base primitiva, que sirve como la superclase ultima de todas las clases. Clase concreta: Clase cuya implementacion esta completa y por tanto puede estar instanciada. Clase contenedor (container): Clases que sirve como plantilla para otras clases, en las que la plantilla puede denotar colecciones homogeneas (todos los objetos de la coleccion son de la misma clase) o heterogeneas (cada uno de los objetos de la coleccion puede ser una clase diferente, aunque generalmente todos deben comportir un superlcase comun). Las clases contenedor se definen la mayoria de las veces como clases parametrizadas, en las que algun parametro designa la clase de los objetos contenidos. Clase generica: Clase que sirve como plantilla para otras clases, en las que la plantilla puede parametrizarse con otras clases objetos y/o operaciones. Un clase generica debe ser instanciada (rellenados sus parametros) antes de que puedan crearse objetos. Las clases genericas se usan tipicamente como clases contenedor. Los terminos clase generia y clase parametrizada son intercambiables. Jerarquia: Clasificacion u ordenacion de abstracciones. Las dos jerarquias mas habituales en un sistema complejo son su estructura de clases (que incluye jerarquia de tipo) y sus estructura de objetos (que incluye jerarquia de partes y de colaboracion); pueden encontrarse tambien jerarquias en las arquitecturas de modulos y procesos de un sistema complejo. Operacion: Algun trabajo que un objeto realiza sobre otro con el fin de provocar una reaccion. Todas las operaciones sobre un objeto concreto pueden encontrarse en forma de subprogramas libres y funciones miembros o metodos. Los terminos mensaje, metodo y operacion son intercambiables

caso de uso es una tcnica para la captura de requisitos potenciales de un nuevo

sistema o una actualizacin de software. Cada caso de uso proporciona uno o ms escenarios que indican cmo debera interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo especfico. Normalmente, en los casos de usos se evita el empleo de jergas tcnicas, prefiriendo en su lugar un lenguaje ms cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso. En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarn entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicacin y el comportamiento de un sistema mediante su interaccin con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relacin entre los actores y los casos de uso en un sistema. Una relacin es una conexin entre los

elementos del modelo,

Definir los

Una vez identificados los objetos, defina los atributos de la clase. Un atributo es un valor almacenado en los objetos de la clase. Aplicaciones orientadas a objetos A lo largo de la historia de la programacin, los lenguajes y las metodologas han pasado de una relativa simplicidad a una complejidad creciente. Los lenguajes de programacin orientados a objetos pretenden aportar simplicidad a la tarea de programacin de grandes aplicaciones. Cuando se crearon las primeras computadoras todava no existan los lenguajes de programacin, tal como ahora los entendemos. El lenguaje ensamblador puede considerarse como el primer lenguaje de programacin propiamente dicho. Permita al usuario un dilogo ms fluido con la mquina a travs de instrucciones que tenan relacin directa con el conjunto de operaciones que la mquina poda realizar. A partir de este momento empez la evolucin de los lenguajes de programacin. _cada uno tena su entorno definido y aunque en realidad todos los lenguajes son polivalentes (en teora, con cualquiera de ellos se puede desarrollar cualquier programa de gestin o cientfico). Pronto apareci la especializacin funcional. As, COBOL (Common Business Orientated Language) se introdujo como lenguaje mainframe para el diseo de aplicaciones

de gestin.; FORTRAN (Formula Translator) para el diseo de aplicaciones cientficas; APL (A Programming Language) para el clculo matemtico, etc. A medida que el software tomaba importancia, aparecieron los primeros problemas relacionados con la programacin. Al tiempo que aumenta el volumen de un programa, disminuye el control del mismo por parte del programador y la capacidad de este de dar mantenimiento. En un intento de solucionar estos problemas aparecen las metodologas de programacin. Una metodologa es un conjunto de reglas destinadas a simplificar las tareas de diseo, estimacin de costes, desarrollo y mantenimiento de un sistema informtico. A menudo se ven acompaadas con unas herramientas (CASE: Computer Aided Software Engeneering) que permiten la elaboracin estructurada y documentada de los sistemas informticos.

Continuacin trabajo gua.

Requisitos: conjunto de elementos y normas
de sistema a estudiar para mejorar el mismo. que convergen en la analogia

Sistema: conjunto de elementos interdependientes e inter actuantes; grupo

de unidades combinadas que forman un todo organizado. El ser humano, por ejemplo es un sistema que consta de varios rganos.

Objeto: un objeto se define como la unidad que en tiempo de ejecucin realiza

las tareas de un programa. Tambin a un nivel ms bsico se define como la instancia de una clase. Dichos objetos interactan unos con otros, en contraposicin a la visin tradicional.

Agregacin:

Ejemplo agregacin Es una abstraccin a travs de la cual las relaciones se tratan como entidades de un nivel ms alto. Se utiliza para expresar relaciones entre relaciones o entre entidades y relaciones. Se representa englobando la relacin abstrada y las entidades que participan en ella en un rectngulo. En la figura se muestra un ejemplo de agregacin en el que se representa la situacin en la que un profesor, cuando est impartiendo una clase, puede poner una incidencia ocurrida a lo largo de sta (se fue la luz, falta la configuracin de un determinado software, etc.). Operacin: Algn trabajo que un objeto realiza sobre otro con el fin de provocar una reaccin. Todas las operaciones sobre un objeto concreto pueden encontrarse en forma de subprogramas libres y funciones miembros o mtodos. Los trminos mensaje, mtodo y operacin son intercambiables.

Un usuario: es la persona que utiliza o trabaja con algn objeto o que es

destinataria de algn servicio pblico o privado, empresarial o profesional. Sin embargo, usuario segn la RAE (Real Academia Espaola) es "aquel que usa algo". Esto es algo que se opone a los conceptos de Web semntica, Web 2.0 y 3.0, trabajo colaborativo..., ya que la realidad actual prima a los ciudadanos como emisores y no slo como receptores que "usan" los medios. Es preferible, por tanto, hablar de actores, sujetos, ciudadanos, para referirse a las personas que interactan en las redes digitales., En informtica este trmino se utiliza con especial relevancia. Abstraccin: Las caractersticas esenciales de un objeto que lo distinguen de todos los de mas objetos y proporcionan a si fronteras conceptuales definidas con nitidez en relacin con la perspectiva del observador; el proceso de centrarse en las caractersticas esenciales de un objeto. La abstraccin es uno de los elementos fundamentales del modelo de objetos. Herencia: Relacin entre clases, en la que una clase comporte la estructura y comportamiento definido en otra (herencia simple) u otras (herencia mltiple) clases. La herencia define una relacin de tipo entre clases en la que una subclase hereda de una o mas superclases generalizadas, una subclase suele especializar a sus superclases aumentando o refinando la estructuras y comportamiento existentes.

Mensaje: Operacin que un objeto realiza sobre otro. Los trminos mensaje, mtodo o operacin suelen ser equivalentes

Segunda unidad
Capa: Una capa o layer consiste en una porcin de la pgina HTML, que puede ser tratada de forma independiente, como un elemento nico, y puede ser alterada de diversas formas, como, por ejemplo, puede ser movida de un lado a otro de la pgina, se puede escribir encima o debajo de ella, volverla transparente u opaca o insertar una capa dentro de otra. Tambin se pueden especificar imgenes de fondo o colores para las capas, del mismo modo que hacamos con el cuerpo (BODY) de un documento HTML.

Red privada virtual

La Red Privada Virtual (RPV), en ingls Virtual Private Network (VPN), es una tecnologa de red que permite una extensin de la red local sobre una red pblica o no controlada, como por ejemplo Internet. Ejemplos comunes son, la posibilidad de conectar dos o ms sucursales de una empresa utilizando como vnculo Internet, permitir a los miembros del equipo de soporte tcnico la conexin desde su casa al centro de cmputo, o que un usuario pueda acceder a su equipo domstico desde un sitio remoto, como por ejemplo un hotel. Todo ello utilizando la infraestructura de Internet.

Intranet:
Una Intranet es una red de ordenadores privados que utiliza tecnologa, Internet para compartir de forma segura cualquier informacin o programa del sistema operativo para evitar que cualquier usuario de Internet pueda ingresar . En la arquitecturas que el software servidor se ejecuta en una Intranet anfitriona. No es necesario que estos dos softwares, el cliente y el servidor, sean ejecutados en el mismo sistema operativo. Podra proporcionar una comunicacin privada y exitosa en una organizacin.
Funciones de la Intranet :

Tiene como funcin principal proveer lgica de negocios para aplicaciones de captura, informes y consultas con el fin de facilitar la produccin de dichos grupos de nivel de grupo de trabajo. Las redes internas corporativas son potentes herramientas que permiten divulgar informacin de la compaa a los empleados con efectividad, consiguiendo que estos estn permanentemente informados con las ltimas novedades y datos de la organizacin. Tambin es habitual su uso en universidades y otros centros de

formacin, ya que facilita la consulta de diferentes tipos de informacin y el seguimiento de la materia del curso. Tienen gran valor como repositorio documental, convirtindose en un factor determinante para conseguir el objetivo de la oficina sin papeles. Aadindoles funcionalidades como un buen buscador y una organizacin adecuada, se puede conseguir una consulta rpida y eficaz por parte de los empleados de un volumen importante de documentacin. Los beneficios de una intranet pueden ser enormes. Estando tal cantidad de informacin al alcance de los empleados y/o estudiantes ahorrarn mucho tiempo buscndola. Las Intranet tambin deberan cumplir unos requisitos de accesibilidad web permitiendo su uso a la mayor parte de las personas, independientemente de sus limitaciones fsicas o las derivadas de su entorno. Gracias a esto, promueve nuevas formas de colaboracin y acceso a los sistema. Ya no es necesario reunir a todos en una sala para discutir un proyecto. Equipos de personas alrededor del mundo pueden trabajar juntos sin tener que invertir en gastos de viaje. El resultado de esto es un aumento increible en la eficiencia acompaada de una reduccin de costos.

Extranet
Concepto Una extranet (extended intranet) es una red privada virtual que utiliza protocolos de Internet, protocolos de comunicacin y probablemente infraestructura pblica de comunicacin para compartir de forma segura parte de la informacin u operacin propia de una organizacin con proveedores, compradores, socios, clientes o cualquier otro negocio u organizacin. Se puede decir en otras palabras que una extranet es parte de la Intranet de una organizacin que se extiende a usuarios fuera de ella. Usualmente utilizando la Internet. La extranet suele tener un acceso semiprivado, para acceder a la extranet de una empresa no necesariamente el usuario ha de ser trabajador de la empresa, pero si tener un vnculo con la entidad. Es por ello que una extranet requiere o necesita un grado de seguridad, para que no pueda acceder cualquier persona. Otra caracterstica de la extranet es que se puede utilizar como una Internet de colaboracin con otras compaas.

Tercera unidad.
formato tabular:, los dgitos son escritos sobre su base y un punto y coma es
usado para indicar el punto de base. En formato numeral

Unidad4 Lenguaje de Modelado Unificado,

un diagrama de casos de uso es una especie de diagrama de comportamiento. El Lenguaje de Modelado Unificado define una notacin grfica para representar casos de uso llamada modelo de casos de uso. UML no define estndares para que el formato escrito describa los casos de uso, y as mucha gente no entiende que esta notacin grfica define la naturaleza de un caso de uso; sin embargo una notacin grfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos estn relacionados, los casos de uso son mucho ms detallados que los diagramas de casos de uso.

Diagramas de Casos de Uso UML [editar]

El estndar de Lenguaje de Modelado Unificado de OMG define una notacin grfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocacin pensando que un caso de uso es una notacin grfica (o es su descripcin). Mientras la notacin grfica y las descripciones son importantes, ellos forman parte de la documentacin de un caso de uso --un propsito para el que el actor puede usar el sistema. El valor verdadero de un caso de uso reposa en dos reas:

La descripcin escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripcin se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas. La posicin o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organizacin, un conjunto de casos de uso coherentes, consistentes promueve una imagen fcil del comportamiento del sistema, un entendimiento comn entre el cliente/propietario/usuario y el equipo de desarrollo.

Es prctica comn crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del mbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen rendimiento, temas de escalabilidad/gestin, o cumplimiento de estndares.

El diagrama de la derecha describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso estn representados por elipses y los actores estn representados por las figuras humanas. El actor Crtico de comidas puede Probar la comida, Pagar la comida, o Beber vino. Slo el actor Chef puede Preparar la comida. Podra ser que ambos Patrn y Cajero estn involucrados en el caso de uso Pagar la comida. El marco define los limites del sistema Restaurante, por ejemplo, los casos de uso se muestran como parte del sistema que est siendo modelado, los actores no. La interaccin entre actores no se ve en el diagrama de casos de uso. Si esta interaccin es esencial para una descripcin coherente del comportamiento deseado, quizs los lmites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interaccin entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa puede jugar varios papeles o roles. As el Chef y el Cajero podran ser realmente la misma persona.
Relaciones de Casos de Uso [editar]

Las tres relaciones principales entre los casos de uso son soportadas por el estndar UML, el cual describe notacin grfica para esas relaciones.

Inclusin (include o use) [editar]

Es una forma de interaccin, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es til para extraer comportamientos verdaderamente comunes desde mltiples casos de uso a una descripcin individual, desde el caso de uso que lo incluye hasta el caso de uso incluido, con la etiqueta "include". Este uso se asemeja a una expansin de una macro, donde

el comportamiento del caso incluido es colocado dentro del comportamiento del caso de uso base. No hay parmetros o valores de retorno.

Extensin (Extend) [editar]

Es otra forma de interaccin, un caso de uso dado, (la extensin) puede extender a otro. Esta relacin indica que el comportamiento del caso de uso extensin puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notacin, es una flecha de punta abierta con lnea discontinua, desde el caso de uso extensin al caso de uso extendido, con la etiqueta extend. Esto puede ser til para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensin. La extensin se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensin o inclusin. "La extensin, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensin son los ejemplos o instancias de los conceptos."

Generalizacin :
En la tercera forma de relaciones entre casos de uso, existe una relacin generalizacin/especializacin. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notacin es una lnea solida terminada en un tringulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la prctica puede ser til factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados. "Entonces la Generalizacin es la actividad de identificar elementos en comn entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonmicas entre conceptos que entonces se representan en jerarquas de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intensin y extensin." Un diagrama de clases: es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de anlisis y diseo de los sistemas, donde se crea el diseo conceptual de la informacin que se manejar en el sistema, y los componentes que se encargaran del funcionamiento y la relacin entre uno y otro.
Definiciones [editar]

Propiedades tambin llamados atributos o caractersticas, son valores que corresponden a un objeto, como color, material, cantidad, ubicacin. Generalmente se conoce como la informacin detallada del objeto. Suponiendo que el objeto es una puerta, sus propiedades seran: la marca, tamao, color y peso. Operaciones son aquellas actividades o verbos que se pueden realizar con/para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, acreditar, cargar. De la misma manera que el nombre de un atributo, el nombre de una operacin

se escribe con minsculas si consta de una sola palabra. Si el nombre contiene ms de una palabra, cada palabra ser unida a la anterior y comenzar con una letra mayscula, a excepcin de la primera palabra que comenzar en minscula. Por ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc.

Interfaz es un conjunto de operaciones y/o propiedades que permiten a un objeto comportarse de cierta manera, por lo que define los requerimientos mnimos del objeto. Herencia se define como la reutilizacin de un objeto padre ya definido para poder extender la funcionalidad en un objeto hijo. Los objetos hijos heredan todas las operaciones y/o propiedades de un objeto padre. Por ejemplo: Una persona puede subdividirse en Proveedores, Acreedores, Clientes, Accionistas, Empleados; todos comparten datos bsicos como una persona, pero adems tendr informacin adicional que depende del tipo de persona, como saldo del cliente, total de inversin del accionista, salario del empleado, etc.

Al disear una clase se debe pensar en cmo se puede identificar un objeto real, como una persona, un transporte, un documento o un paquete. Estos ejemplos de clases de objetos reales, es sobre lo que un sistema se disea. Durante el proceso del diseo de las clases se toman las propiedades que identifican como nico al objeto y otras propiedades adicionales como datos que corresponden al objeto. Con los siguientes ejemplos se definen tres objetos que se incluyen en un diagrama de clases: Ejemplo 1: Una persona tiene nmero de documento de identificacin, nombres, apellidos, fecha de nacimiento, gnero, direccin postal, posiblemente tambin tenga nmero de telfono de casa, del mvil, FAX y correo electrnico. Ejemplo 2: Un sistema informtico puede permitir administrar la cuenta bancaria de una persona, por lo que tendr un nmero de cuenta, nmero de identificacin del propietario de la cuenta, saldo actual, moneda en la que se maneja la cuenta. Ejemplo 3: Otro objeto pueden ser "Manejo de Cuenta", dnde las operaciones bancarias de una cuenta (como en el ejemplo 2) se manejarn realizando diferentes operaciones que en el diagrama de clases slo se representan como operaciones, que pueden ser:

Abrir Cerrar Depsito Retiro Acreditar Intereses

Estos ejemplos constituyen diferentes clases de objetos que tienen propiedades y/u operaciones que contienen un contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lgica de negocio, dependiendo de quin disee el sistema se pueden unir los datos con las operaciones.

El diagrama de clases incluye mucha ms informacin como la relacin entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una interfaz. Next: Diagramas de Actividades Up: Modelado de comportamiento Previous: Modelado de comportamiento Diagramas de Estado Un estado es una condicin durante la vida de un objeto, de forma que cuando dicha condicin se satisface se lleva a cabo alguna accin o se espera por un evento. El estado de un objeto se puede caracterizar por el valor de uno o varios de los atributos de su clase, adems, el estado de un objeto tambin se puede caracterizar por la existencia de un enlace con otro objeto. El diagrama de estados y transiciones engloba todos los mensajes que un objeto puede enviar o recibir. En un diagrama de estados, un escenario representa un camino dentro del diagrama. Dado que generalmente el intervalo entre dos envos de mensajes representa un estado, se pueden utilizar los diagramas de secuencia (4.2) para buscar los diferentes estados de un objeto. En todo diagrama de estados existen por lo menos dos estados especiales inicial y final: start y stop. Cada diagrama debe tener uno y slo un estado start para que el objeto se encuentre en estado consistente. Por contra, un diagrama puede tener varios estados stop. Una transicin en un diagrama de estados puede tener asociada una accin y/o una guarda, adems, una transicin puede disparar un evento. La accin ser el comportamiento que se obtiene cuando ocurre la transicin, y el evento ser el mensaje que se enva a otro objeto del sistema. Por ltimo, la guarda es una expresin boolena sobre los valores de los atributos que hace que la transicin slo se produzca si la condicin evala a true. Tanto las acciones como las guardas son comportamientos del objeto y generalmente se traducen en operaciones de alguna clase. Una transicin entre estados representa un cambio de un estado origen a un estado sucesor destino que podra ser el mismo que el estado origen, dicho cambio de estado puede ir acompa nado de alguna accin. Las acciones se asocian a las transiciones y se considera que ocurren de forma rpida y no interrumpible. Por contra, las actividades se asocian a los estados pudiendo consumir ms tiempo, dicha actividad puede verse interrumpida por la ocurrencia de algn evento. Existen dos formas de transicionar en un diagrama de estados: automticamente y no automticamente. Se produce una transicin automtica cuando se acaba la actividad del estado origen (no hay un evento asociado con la transicin). Se produce una transicin no automtica cuando existe un evento que puede pertenecer a otro objeto o incluso estar fuera del sistema. Los diagramas de estados muestran el comportamiento de los objetos, es decir, el conjunto de estados por los cuales pasa un objeto durante su vida, junto con los

cambios que permiten pasar de un estado a otro. Un ejemplo para el caso de la mqina de caf son los estados posibles de la clase MaquinaCafe (figura 5.1).

Figura: Ejemplo de diagrama de estados de la Mquina de Caf

Un estado identifica un perodo de tiempo (no instantneo) en la vida del objeto durante el cual est esperando alguna operacin, tiene cierto comportamiento caracterstico o puede recibir cierto tipo de estmulos. En notacin UML, un estado se representa mediante un rectngulo con los bordes redondeados, que puede tener tres compartimentos: uno para el nombre, otro para el valor caracterstico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do, respectivamente). En el caso de la figura 5.1, se tienen cuatro estados (Lista, IntroduciendoMonedas, SeleccionandoAzucaryProducto, SirviendoProducto), en los cuales se desarrollan ciertas acciones al entrar, por ejemplo, al entrar al estado IntroduciendoMonedas se debe realizar la accion MostrarDineroActual. Los estados iniciales y finales se representan mediante los smbolos de la figura 5.2.

Figura 5.2: Estado final

Otros conceptos relacionados con los diagramas de estados son:

Eventos Un evento es una ocurrencia que puede causar la transicin de un estado a otro de un objeto. Esta ocurrencia puede ser: o Condicin que toma el valor de verdadero o falso. o Recepcin de una se nal de otro objeto en el modelo. o Recepcin de un mensaje . o Paso de cierto perodo de tiempo, despus de entrar al estado o de cierta hora y fecha particular. El nombre de un evento tiene alcance dentro del paquete en el cual est definido, no es local a la clase que lo nombra. En el caso del ejemplo de la figura 5.1, encontramos en varias transiciones el evento userInput, que recibe como parmetro un objeto Button indicando el botn que ha sido presionado por el usuario de la mquina de caf.

Envo de mensajes Adems de mostrar la transicin de estados por medio de eventos, puede representarse el momento en el cual se envan mensajes a otros objetos. Para ello se utiliza una lnea punteada dirigida al diagrama de estados del objeto receptor del mensaje. Si tomamos como ejemplo un control remoto que puede enviar rdenes de encender o apagar al televisor o a la videograbadora se puede obtener un diagrama de estados como el de la figura 5.3

Figura: Ejemplo de envo de mensajes

En la figura observamos un diagrama de estados para cada uno de los tres aparatos, algunas de las transiciones del control remoto causan el envo de mensajes togglePower a los otros aparatos (televisin y videograbadora).

Transicin simple Una transicin simple es una relacin entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones cuando un evento ocurre y si ciertas condiciones son satisfechas. Se representa como una lnea slida entre dos estados, que puede venir acompa nada de un texto con el siguiente formato:
event-signature [guard-condition] action-expression send-clause

Donde event-signature es la descripcin del evento que da lugar a la transicin; guard-condition son las condiciones adicionales al evento necesarias para que la transicin ocurra; action-expression es un mensaje al objeto o a otro objeto que se ejecuta como resultado de la transicin y el cambio de estado; y send-clause son acciones adicionales que se ejecutan con el cambio de estado, por ejemplo, el envo de eventos a otros paquetes o clases. En el caso del ejemplo inicial de la mqina de caf se tiene una transicin entre los estados IntroduciendoMoneda y SeleccionadoAzucaryProducto que tiene una transicin con el siguiente detalle:

userInput(Button) | [TodoOk=true] / MostrarNivelAzucar, MostrarProducto

El evento que dispara el cambio de estado es userInput(Button). Se requiere como condicin adicional que no se haya detectado ningn fallo (TodoOk = true) y se ejecuta MostrarNivelAzucar y MostrarProducto.

Transicin interna Es una transicin que permanece en el mismo estado, en vez de involucrar dos estados distintos. Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el compartimento de acciones del estado. Supongamos el estado de una interfaz pidiendo password al usuario. En este caso puede tenerse una transicin interna que muestre una ayuda al usuario. Esta transicin se muestra en el diagrama de la figura 5.4 con la cadena ``help / display help'' dentro del cuerpo del estado.

Figura: Ejemplo de transicin interna

Subestados Un estado puede

descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior (superestado). Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior. Un ejemplo es el estado marcando de un telfono (figura 5.5), que puede descomponerse en los subestados Inicio y marcado parcial. Figura 5.5: Ejemplo de subestados

Transicin compleja Una transicin compleja relaciona tres o ms estados en una transicin de mltiples fuentes y/o mltiples destinos. Representa la

subdivisin en hilos del control del objeto o una sincronizacin. Se representa como una lnea vertical de la cual salen o entran varias lneas de transicin de estado. En el ejemplo de la figura 5.6 se muestra una transicin a dos hilos concurrentes que luego se sincronizan. Figura: Ejemplo de transicin compleja

Transicin a estados anidados Una transicin hacia un estado complejo, descrito mediante estados anidados, significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera, a cualquier nivel de profundidad. En la figura 5.1 se encuentran los dos casos nombrados: desde el estado inicial se pasa al estado BuenFuncionamiento (a su estado inicial) y de este estado salen transiciones hacia MalFuncionamiento y hacia el estado final, dichas transiciones deben comprenderse como transiciones de cada uno de los estados internos hacia los estados externos.

Los diagramas de estado resultan adecuados para describir el comportamiento de un objeto a travs de diferentes casos de uso, sin embargo, no resultan del todo adecuados para describir el comportamiento que incluye a una serie de objetos colaborando entre s. Por lo tanto, resulta til combinar los diagramas de estado con otras tcnicas. Por ejemplo, los diagramas de interaccin (4.1) son idneos para la descripcin del comportamiento de varios objetos en un nico caso de uso, y los diagramas de actividades (5.2) muestran de forma adecuada la secuencia general de acciones en diferentes objetos y casos de uso. No nos debemos plantear el dise nar diagramas de estados para todas las clases en el sistema, sino slo para aquellas que exhiban un comportamiento interesante de

de estados nos ayude a entender dicho comportamiento.

forma que la elaboracin del diagrama Next: Diagramas de Actividades Up: Modelado de comportamiento Previous: Modelado de comportamiento

Ana Fernandez Vilas 2001-03-20

Diagrama de secuencia
De Wikipedia, la enciclopedia libre

Saltar a navegacin, bsqueda El diagrama de secuencia es uno de los diagramas ms efectivos para modelar interaccin entre objetos en un sistema. Un diagrama de secuencia muestra la interaccin de un conjunto de objetos en una aplicacin a travs del tiempo y se modela para cada mtodo de la clase. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementacin del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos. Tpicamente uno examina la descripcin de un caso de uso para determinar qu objetos son necesarios para la implementacin del escenario. Si tienes modelada la descripcin de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qu objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con lneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Ejemplo de Diagrama de Secuencia Existen dos tipos de mensajes: sncronos y asncronos. Los mensajes sncronos se corresponden con llamadas a mtodos del objeto que recibe el mensaje. El objeto que enva el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asncronos terminan inmediatamente, y crean un nuevo hilo de ejecucin dentro de la secuencia. Se representan con flechas con la cabeza abierta.

Tambin se representa la respuesta a un mensaje con una flecha discontinua.

Los mensajes se dibujan cronolgicamente desde la parte superior del diagrama a la parte inferior; la distribucin horizontal de los objetos es arbitraria. Durante el anlisis inicial, el modelador tpicamente coloca el nombre 'business' de un mensaje en la lnea del mensaje. Ms tarde, durante el diseo, el nombre 'business' es reemplazado con el nombre del mtodo que est siendo llamado por un objeto en el otro. El mtodo llamado, o invocado, pertenece a la definicin de la clase instanciada por el objeto en la recepcin final del mensaje. 4.2.3.5

Diagramas de Colaboracin
Un diagrama de colaboracin es una forma alternativa al diagrama de secuencia de mostrar un escenario. Este tipo de diagrama muestra las interacciones entre objetos organizadas entorno a los objetos y los enlaces entre ellos. Los diagramas de secuencia proporcionan una forma de ver el escenario en un orden temporal - qu pasa primero, qu pasa despus -. Los clientes entienden fcilmente este tipo de diagramas, por lo que resultan tiles en las primeras fases de anlisis. Por contra los diagramas de colaboracin proporcionan la representacin principal de un escenario, ya que las colaboraciones se organizan entorno a los enlaces de unos objetos con otros. Este tipo de diagramas se utilizan ms frecuentemente en la fase de dise no, es decir, cuando estamos dise nando la implementacin de las relaciones. Se toma como ejemplo el caso de uso PedirProducto (fig. 4.4) ya descrito como diagrama de secuencia.

Figura: Ejemplo diagrama de colaboracin

A diferencia de otras notaciones que muestran tanto el estado y el comportamiento de la clase en el diagrama de clases, UML separa el comportamiento de las clases en los diagramas de colaboracin. Los diagramas de clase de UML no incluyen flujo de mensajes entre clases, es por sto que los diagramas de colaboracin se deben crear en paralelo con los diagramas de clases. Aunque se puede indicar el orden del flujo de mensajes en un diagrama de colaboracin numerando los mensajes, no se suele hacer, ya que para este propsito son mejores los diagramas de secuencia. A continuacin se enumeran los conceptos fundamentales de un diagrama de colaboracin:

Objeto: Se representa con un rectngulo que contiene el nombre y la clase del objeto en un formato nombreObjeto : nombreClase. Enlaces: Un enlace es una instancia de una asociacin en un diagrama de clases. Se representa como una lnea continua que une a dos objetos, acompa nada por un nmero que indica el orden dentro de la interaccin. Pueden darse varios niveles de subndices para indicar anidamiento de operaciones. Se pueden utilizar estereotipos para indicar si el objeto que recibe el mensaje es un atributo, un parmetro de un mensaje anterior, si es un objeto local o global. Flujo de mensajes: Expresa el envo de un mensaje. Se representa mediante una flecha dirigida cerca de un enlace. Marcadores de creacin y destruccin de objetos: Puede mostrarse en la grfica qu objetos son creados y destruidos, agregando una restriccin con la palabra new o delete respectivamente. Objeto compuesto: Es una representacin alternativa de un objeto y sus atributos. En esta representacin se muestran los objetos contenidos dentro del rectngulo que representa al objeto que los contiene. Un ejemplo es el objeto Window (figura 4.5). Figura 4.5: Ejemplo de objeto compuesto

Patrn de dise no: Un diagrama de colaboracin puede especificar un contrato entre objetos, parte esencial para la descripcin de un patrn de dise no. Este diagrama contiene todos los elementos citados de un diagrama de colaboracin, dejando libres posiblemente los tipos exactos de algunos objetos o con nombres genricos para los mensajes. Una ``instanciacin'' del patrn se representa como una elipse unida mediante flechas punteadas a los objetos o clases que participan realmente en el patrn. Estas flechas pueden tener roles, indicando cul es el

papel de cada elemento dentro del patrn. Por ejemplo, una instanciacin del patrn Observer se representa en la figura 4.6.

Figura: Diagrama de Colaboracin que describe un patrn

Contexto: Un contexto es una vista de uno o ms elementos dentro del modelo que colaboran en el desarrollo de una accin. Se usa para separar los dems elementos en el modelo de este problema en particular y darle nfasis. Puede mostrar slo los detalles relevantes de las clases u objetos que contiene, para Figura 4.7: Ejemplo de un contexto

resaltar su utilidad. Un ejemplo es la definicin del tipo CashRegister (figura 4.7).

Se representa como un contexto un tipo CashRegister y se muestran los detalles relevantes de Product, Item y Sale para este tipo. Las relaciones de las clases con otras no visibles dentro del contexto pueden omitirse o conectarse al borde del contexto.

Objeto activo: Un objeto activo es el que contiene su propio flujo de control, a diferencia de un objeto pasivo que encapsula datos y slo reacciona al enviarle mensajes. Un objeto activo se representa con un rectngulo de bordes gruesos. Puede contener otros objetos pasivos o activos. Se presenta un ejemplo en la figura 4.8 en el contexto de una produccin en lnea robotizada. Se tiene un ente Factory Manager, un ente robot y un ente oven, tres objetos activos que interactan para desarrollar su tarea. Figura 4.8: Ejemplo de objetos activos

Los mensajes entre objetos pasivos se denotan mediante una flecha completa, mientras que los mensajes entre objetos activos se denotan con una media flecha. Los hilos de ejecucin se denotan con las letras A y B antes del nmero de orden del mensaje. La sincronizacin entre hilos se muestra mediante un ``/'' y el nuevo nmero de orden. Por ejemplo en A2, B2 / 2: completed (job).

4.2.3.6 Diagramas de Actividades

Un diagrama de actividades puede considerarse como un caso especial de un diagrama de estados en el cual casi todos los estados son estados accin (identifican una accin que se ejecuta al estar en l) y casi todas las transiciones evolucionan al trmino de dicha accin (ejecutada en el estado anterior). Un diagrama de actividades puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto. Permiten representar transiciones internas al margen de las transiciones o eventos externos. En la figura 5.7 se presenta un ejemplo de diagrama de actividades para un mensaje de un objeto. La interpretacin de un diagrama de actividades depende de la perspectiva considerada: en un diagrama conceptual, la actividad es alguna tarea que debe ser realizada; en un diagrama de especificacin o de implementacin, la actividad es un mtodo de una clase. Generalmente se suelen utilizar para modelar los pasos de un algoritmo.

Figura 5.7: Ejemplo de diagrama de actividades

Un estado de accin representa un estado con accin interna, con por lo menos una transicin que identifica la culminacin de la accin (por medio de un evento implcito). No deben tener transiciones internas ni transiciones basadas en eventos, ya que si fuera este el caso, se representara con un diagrama de estados. Los estados de accin se representan por un rect'angulo con bordes redondeados, y permiten modelar un paso dentro de un algoritmo. Las flechas dirigidas entre estados de accin representan transiciones con evento implcito que, en el caso de decisiones, pueden tener una condicin o guarda asociada (que al igual que en los diagramas de estado eval'ua a true o a false). Las decisiones se representan mediante una transicin m'ultiple que sale de un estado y donde cada camino tiene una etiqueta distinta. Se representa mediante un rombo al cual llega la transicin del estado origen y del cual salen las m'ultiples transiciones de los estados destino. Un ejemplo se muestra en la figura 5.7 cuando no hay caf y se toma una decisin entre hay cola o no hay cola. En un diagrama de actividades tambin pueden existir barras de sincronizacin (synchronization bar), como la que sigue a [found cofee] en la figura 5.7, a las que se encuentran asociadas varios caminos salientes. Cada camino saliente se dirige a una actividad (Put Coffee in Filter, Add Water to Reservoir y Get Cups), realiz'andose dichas actividades en paralelo. Esto quiere decir que el orden en que se realicen dichas actividades es irrelevante, siendo v'alido cualquier orden entre ellas. Dado que el diagrama de actividades permite expresar el orden en que se realizan las cosas, resulta adecuado para el modelado de organizaciones (business modeling) y el de programas concurrentes (permiten representa gr'aficamente los hilos de ejecucin). Como la mayora de las tcnicas de modelado de comportamiento, los diagramas de actividades tienen sus puntos fuertes y sus puntos dbiles, de forma que es necesario utilizarlos en combinacin con otras tcnicas. Su principal aportacin al modelado del comportamiento es que soportan el comportamiento paralelo, lo que resulta adecuado para el modelado de flujo de trabajo ( workflow) y programacin multihilo (multi-thread). Por contra, su principal desventaja es que no muestran de una forma clara los enlaces existentes entre las acciones y los objetos, siendo mucho m'as apropiado para ello los diagramas de interaccin. En general resulta adecuado utilizar diagramas de actividades para:

An'alisis de casos de uso: Durante el an'alisis de los casos de uso no estamos interesados en asociar acciones a objetos, sino en entender qu acciones se necesitan llevar a cabo y cuales son las dependencias en el comportamiento. Comprensin del flujo de trabajo a lo largo de diferentes casos de uso. Modelado de aplicaciones multihilo.

Por contra, resultan en general del todo inadecuados a la hora de mostrar la colaboracin entre objetos y la evolucin del comportamiento de los objetos durante su tiempo de vida.

4.2.3.7 D i a g r a m a d e P a q u e t e U M L 2

Diagrama de Paquetes Los diagramas de paquetes se usan para reflejar la organizacin de paquetes y sus elementos. Cuando se us para representaciones, los diagramas de paquete de los elementos de clase se usan para proveer una visualizacin de los espacios de nombres. Los usos ms comunes para los diagramas de paquete son para organizar diagramas de casos de uso y diagramas de clase, a pesar de que el uso de los diagramas de paque es limitado a estos elementos UML. El siguiente es un ejemplo de un diagrama del paquete.

Los elementos contenidos en un paquete comparten el mismo espacio de nombre, el hecho de compartir espacios de nombres requiere que los elementos contenidos en un espacio de nombre especfico tengan nom nicos.

Los paquetes se pueden construir para representar relaciones tanto fsicas como lgicas. Cuando se elige in las clases a los paquetes especficos, es til asignar las clases con la misma jerarqua de herencia a los paqu las clases que estn relacionadas a travs de la composicin y las clases que colaboran que tambin tienen fuerte argumento para ser incluidas en el mismo paquete

Los paquetes se representan en UML 2.0 como carpetas y contienen los elementos que comparten un espac nombre; todos los elementos dentro de un paquete deben tener un identificador nico. El paquete debe mos el nombre del paquete y puede opcionalmente mostrar los elementos dentro del paquete en compartimiento extras.

Combinacin de paquetes Cuando un conector merge se usa en un paquete, la fuente de la combinacin importa los contenidos importados y anidados del destino. Si existe un elemento dentro del origen y el destino, las definiciones de

elemento origen se expandirn para incluir las definiciones del elemento contenidas en el destino. Todos lo elementos agregados o actualizados por una combinacin se notan por una relacin de generalizacin desd origen hasta el destino.

Importacin de Paquetes El conector import indica que los elementos dentro del paquete destino, que en este ejemplo es una sola se importarn al paquete origen. El espacio de nombre del paquete origen ganar acceso a la Clase/s de De el espacio de nombre del destino no est afectado.

Conectores Anidados El conector anidado entre el paquete destino y los paquetes de origen reflejan lo que muestran los contenid del paquete.

4.2.3.10 Diagramas de Comunicaciones (formalmente Diagrama de Colaboraciones)

Superior Previo Prximo

Diagrama de Ejemplo ..| ..Elementos/Conectores ..| ..Temas Relacionados ..| ..Espe

Un diagrama de Comunicaciones muestra las interacciones entre los elementos en tiempo de ejecucin e diagrama de Secuencia. No obstante, los diagramas de Comunicacin se usan para visualizar relaciones i diagramas de Secuencia son ms efectivos para visualizar procesamiento a lo largo del tiempo.

Los diagramas de Comunicaciones emplean asociaciones ordenadas y etiquetadas para ilustrar el procesa numeracin para indicar el orden y el anidamiento del procesamiento. Un esquema de numeracin podra etc. Comienza un nuevo segmento de nmeros para una nueva capa de procesamiento, y sera equivalente mtodo.

Diagrama de Ejemplo El ejemplo de abajo ilustra un diagrama de Comunicaciones entre instancias de objetos cooperantes. Ten de mensajes para capturar flujos relacionados.

Elementos y Conectores de la Caja de Herramientas Consejo: Haga clic sobre los elementos y conectores de abajo para ms informacin. Elementos de los Diagramas de Comunicaciones Conectores de los Diagramas de Comunicaciones