Tecnologas de la informacin y comunicacin

Tecnologas de la informacin y comunicacin

Tecnologas de la Informacin y ComunicacinINVESTIGACIN

Universidad Tecnolgica del Sureste de Veracruz

Tecnologas de la Informacin y Comunicacin

INVESTIGACIONModelado de procesos de negocio

Realizar una investigacin acerca de:- Modelado del dominio.- Diagramas de casos de uso.- Diagramas de componentes.- Diagramas de colaboracin.- Diagramas de objetos.

PRESENTANEneida Isabel Domnguez Ramos

CUATRIMESTRE Y GRUPO Sptimo 701

NOMBRE DEL DOCENTEMC. Eunice Morales Reyes

Cd. Nanchital, Ver., Lunes 03 de Diciembre del 2012

Modelado del Dominio

Un Modelo de Dominio es una representacin visual de clases conceptuales o de objetos reales en un dominio de inters [MO95]. Un Modelo de Dominio consiste en un conjunto de diagramas de clases, sin definicin de operaciones.

Entrada:Descripcin del problema,Casos de Uso

Salida:Un conjunto de diagramas de clases

El modelo de dominio proporciona una perspectiva conceptual Objetos del dominio o clases conceptuales Asociaciones entre clases conceptuales Atributos de las clases conceptualesLa informacin que contienen tambin puede ser expresada en forma de texto plano.

ObjetosUn objeto es una cosa con identidad nica en un dominio de problema.Carlos Prez, USB, Venezuela son objetosTodos los objetos tienen una identidad y son distinguibles.Los objetos se distinguen por su existencia inherente y no por las propiedades descriptivas que puedan tenerDos manzanas con el mismo color, forma y textura siguen siendo manzanas individuales.

Clases y objetosUna clase describe un grupo de objetos con las mismas propiedades, comportamientos y relaciones posibles. Un objeto es una instancia de una clase. Persona, Universidad y Pas son clases.Los objetos de un dominio son el foco del modelado.Por qu clases conceptuales? El poder de la abstraccin. El nivel de abstraccin es un asunto de juicio y est relacionado con la aplicacin.La descripcin de un cliente de un futuro sistema puede tener una combinacin de clases y objetos.

Clases y clases conceptualesEl modelo de dominio es una visualizacin de elementos de un dominio de inters en el mundo real.

Los modelos de dominio no deben mostrar clases de software.

Como crear un modelo de dominio?Pasos:1. Hallar las clases conceptuales.2. Dibujar las clases conceptuales como clases de un diagrama de clases UML.3. Aadir asociaciones y atributos.

Hallar las clases conceptuales

Tres estrategias:Reusar o modificar modelos existentesExisten modelos de dominio y de datos publicados y bien elaborados para dominios comunes: inventario, finanzas, salud, etc. Fowler, Analysis patterns Hay, Data Model Patterns Silverston, Data Model Resource Book Usar una lista de categoras. Identificar sustantivos/frases nominales

Diagrama de casos de usos

Secuencia de transacciones desarrolladas por un sistema en respuesta a un evento iniciado por un actor Sirven para especificar la funcionalidad y el comportamiento de un sistema Un diagrama de caso de uso muestra las relaciones entre actores y casos de uso dentro del sistema Un caso de uso es una unidad coherente de una funcionalidad provista por el sistema (o una clase) Un actor es un rol de un objeto/s. Un objeto fsico pueda tener varios roles -> varios actores Relacin de Caso de Uso: comunica, extiende y usa.

Medio de comunicacin entre usuarios finales, expertos del dominio y desarrolladores sin entrar en detalles. Representa un requisito funcional. Definen el que (y no el como). Se pueden describir con texto (estructurado o no) y luego con diagramas de interaccin.Un diagrama para el flujo principal y variaciones para los flujo flujos s excepcionales.Cada secuencia es un escenario (principal o secundario).Los escenarios con a los casos de uso lo que las instancias son a las clases. Se organizan en paquetes.

El mtodo de Punto de Caso de Uso (UCP Use Case Point) Est basado en los tradicionales Puntos Funcin. Es un mtodo originado de la tesis de master de Gustav Karner (Karner, 1993). Desarrollada mientras trabajaba en Objectory AB, bajo supervisin de Ivar Jacobson (creador de los casos de uso).

Interaccin de usuarios con componentes del sistema Actores Entidad externa que interacta con el software Promueve la simulacin de eventos Pueden ser personas, clases, herramientas de SW, etc. Diagrama de Casos de Uso Grafo de actores y casos de uso Focaliza en que acciones, mtodos, funciones, etc. Son utilizadas por que actor. Vista de caja negra de componentes del sistema Derivado de entrevistas del usuario y/o modelo de negocio

Ventajas Se deben revisar los aspectos clave de los requerimientos para calcular un recuento de Puntos Caso de Uso sin ajustar (UUCP Unadjusted Use Case Points). Estudiar los factores tcnicos y el entorno para crear los factores de ajuste. Ajustar los factores para llegar a obtener los Puntos Caso de Uso ajustados (UCP), que posteriormente se transformarn en una estimacin de esfuerzo (horas-hombre).

En la Figura 1 se pueden observar los pasos bsicos del mtodo de estimacin Puntos Caso de Uso (UCP).

Casos de uso & Actores Un escenario es una instancia de un caso de uso. El actor es un rol rol, no un individuo el bibliotecario puede tener varios roles. El actor debe ser un beneficiario del caso de uso

Clculo de los Puntos Caso de Uso sin ajustar (UUCP)Para realizar el clculo de los Puntos Caso de Uso sin ajustar, se tienen que realizar los tres pasos definidos a continuacin. Clasificar cada interaccin entre actor y caso de uso segn su complejidad y asignarle un peso. Calcular la complejidad de cada caso de uso segn el nmero de transacciones o pasos del mismo. Calcular los Puntos Caso de Uso no ajustados (UUCP Unadjusted Use Case Points):

Clculo de los Puntos Caso de Uso sin ajustar (UUCP)1.-Clasificar cada interaccin entre actor y caso de uso segn su complejidad y asignarle un peso: Para clasificar la complejidad de los actores se debe determinar la forma en la que cada actor interacta con el sistema que se va a desarrollar. En concreto, los actores se clasifican en 3 categoras diferentes, simple, medio y complejo.

1.-Clasificar cada interaccin entre actor y caso de uso segn su complejidad y asignarle un peso: Un actor simple representa otro sistema con una API definida. un actor medio es otro sistema que interacta a travs de un protocolo como por ejemplo TCP/IP o es una persona interactuando a travs de una interfaz por lnea de comandos. un actor complejo interacta a travs de una interfaz grfica.

Una vez clasificado cada actor segn su tipo de interaccin, se le asigna el peso correspondiente asociado a dicha interaccin.En la Tabla 1, se presenta un resumen del procedimiento de clasificacin de los actores.

Tabla 1. Clasificacin de los Actores

Clculo de los Puntos Caso de Uso sin ajustar (UUCP)Para realizar el clculo de la complejidad de un caso de uso se debe determinar el nmero de transacciones, incluyendo los caminos alternativos. Una transaccin es un conjunto de actividades atmicas, donde se ejecutan todas ellas o ninguna. En este contexto, cada caso de uso se debe clasificar en una de las siguientes categoras: simple, medio o complejo.

En concreto, un caso de uso simple tiene 3 o menos transacciones, un caso de uso medio de 4 a 7 transacciones, y un caso de uno complejo ms de 7 transacciones.Una vez clasificado cada caso de uso, segn el nmero de transacciones, se le asigna el peso asociado a dicho nmero de transacciones.

En la Tabla 2 se presenta un resumen del procedimiento de clasificacin de los casos de uso.

Tabla 2. Clasificacin de los Casos de Uso

3.-Calcular los Puntos Caso de Uso no ajustados (UUCP )Los UUCP se calculan sumando la dificultad de las interacciones y la complejidad de los casos de uso.Es decir, sumando el total de los pesos de los actores (clasificados en el paso 1) y el total de los pesos para los casos de uso (clasificados en el paso 2).

Clculo de los factores tcnicos (TCF)Para ajustar los UUCP (Puntos Caso de Uso no ajustados) calculados en los pasos anteriores, se deben tener en cuenta factores de ajuste, tanto factores tcnicos, como factores de entorno.En el caso de los factores tcnicos (TCF), a cada factor se le asigna un valor entre 0 y 5, dependiendo de su influencia en el proyecto. Asignar un valor 0 significa que el factor es irrelevante para el proyecto, un valor 3 es promedio y un valor 5 significa que el factor es esencial.

Una vez que todos los factores tcnicos tienen asignado el valor de la influencia, se procede al clculo de los resultados de cada factor, es decir, se realiza una multiplicacin entre la influencia del factor y su peso asociado.Cuando se han calculado los resultados de cada uno de los factores tcnicos, se aplica la expresin descrita a continuacin, donde el sumatorio se corresponde a la suma de los resultados de los factores tcnicos.

TCF= 0,6 + (0,01 * Sumatorio)

Clculo de los factores tcnicos (TCF)

Clculo de los factores de entorno (EF)Factores de entorno:Para ello, a cada factor de entorno definido en la Tabla 4 (R1) se le asigna un valor entre 0 y 5 dependiendo de su influencia en el proyecto.Asignar un valor 0 significa que el factor es irrelevante para el proyecto, un valor 3 es promedio y un valor 5 significa que el factor es esencial.

Clculo de los factores tcnicos (TCF)Una vez que todos los factores de entorno tienen asignado el valor de la influencia. Se procede al clculo de los resultados de cada factor, es decir, se realiza una multiplicacin entre la influencia del factor y su peso asociado, ver en la Tabla 4 la columna Resultado.

En la Tabla 4 se presenta un resumen del procedimiento del clculo de los factores de entorno, siendo R1 los factores concretos.

Clculo de los Puntos de Caso de Uso ajustados (UCP)Finalmente, para obtener los Puntos Caso de Uso ajustados (UCP) se utilizan los datos obtenidos en los pasos anteriores, Puntos Caso de Uso fno ajustados (UUCP) y factores de ajuste (TCF y EF), haciendo uso de la expresin que se presentan a continuacin.UCP = UUCP * TCF * EFSe debe tener en cuenta que a travs del clculo de esta expresin obtenemos una estimacin del tamao y no del esfuerzo.

Estimacin del esfuerzoComo ocurre en otros mtodos de estimacin, una vez obtenido el tamao, se puede obtener el esfuerzo. Para ello, se utiliza la siguiente expresin:Esfuerzo = UCP * Factor de Productividad

Clculo de los Puntos de Caso de Uso ajustados (UCP)El mtodo originario propone usar un factor de ajuste (Factor de Productividad) .Similar al que se usa en el mtodo de Puntos Funcin clsico, si bien Karner propone concretamente 20 personas hora por cada Punto Caso de Uso (UCP).

Diagramas de Componentes

Los diagramas de componentes describen los elementos fsicos del sistema y sus relaciones y Muestran las opciones de realizacin incluyendo cdigo fuente, binario y ejecutable.Los componentes representan todos los tipos de elementos software que entran en la fabricacin de aplicaciones informticas, Pueden ser simples archivos, paquetes, bibliotecas cargadas dinmicamente, etc.

La representacin grfica es la siguiente:

UML define cinco estereotipos estndar que se aplican a los componentes:

Executable: Especifica un componente que se puede ejecutar en un nodo. Library: Especifica una biblioteca de objetos esttica o dinmica. Table: Especifica un componente que representa una tabla de una base de datos. File: Especifica un componente que representa un documento que contiene cdigo fuente o datos. Document: Especifica un componente que representa un documento.

Dependencias entre ComponentesLas relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente se refiere a los servicios ofrecidos por otro componente

Subsistemas Los distintos componentes pueden agruparse en paquetes segn un criterio lgico y con vistas a simplificar la implementacin Son paquetes estereotipados en

Los subsistemas organizan la vista de realizacin de un sistema Cada subsistema puede contener componentes y otros subsistemas La descomposicin en subsistemas no es necesariamente una descomposicin funcional La relacin entre paquetes y clases en el nivel lgico es el que existe entre subsistemas y componentes en el nivel fsico Paquetes (Categoras) y clases en el nivel lgico. Paquetes (Subsistemas) y componentes en el nivel fsico

El Modelo de Componentes

Este artculo describe cmo modelar los componentes de software y hardware en UML. El modelo de componentes ilustra los componentes de software que se usarn para construir el sistema. Se pueden construir a partir del modelo de clases y escribir desde cero para el nuevo sistema o se pueden importar de otros proyectos y de productos de terceros. Los componentes son agregaciones de alto nivel de las piezas de software ms pequeas y proveen un enfoque de construccin de bloques de caja negra para la elaboracin de software.

Introduccin al UML

El Lenguaje Unificado de Modelado (UML) es, tal como su nombre lo indica, un lenguaje de modelado y no un mtodo o un proceso. El UML est compuesto por una notacin muy especfica y por las reglas semnticas relacionadas para la construccin de sistemas de software. El UML en s mismo no prescribe ni aconseja cmo usar esta notacin en el proceso de desarrollo o como parte de una metodologa de diseo orientada a objetos.

El UML soporta un conjunto rico en elementos de notacin grficos. Describe la notacin para clases, componentes, nodos, actividades, flujos de trabajo, casos de uso, objetos, estados y cmo modelar la relacin entre esos elementos. El UML tambin soporta la idea de extensiones personalizadas a travs elementos estereotipados.

El UML provee beneficios significativos para los ingenieros de software y las organizaciones al ayudarles a construir modelos rigurosos, trazables y mantenibles, que soporten el ciclo de vida de desarrollo de software completo.En los libros mencionados en la seccin de lectura recomendada se puede encontrar ms informacin sobre el UML y de los documentos de especificacin del UML que se pueden encontrar en las pginas de recursos de UML del OMG (Object Management Group).

La Notacin de Componentes

Un componente puede ser algo como un control Actives; tanto un componente de la interfaz de usuario como un servidor de reglas de negocio. Los componentes se representan grficamente como muestra la figura siguiente:

El Diagrama de Componentes

El diagrama de componentes muestra la relacin entre componentes de software, sus dependencias, su comunicacin su ubicacin y otras condiciones.

Interfaces

Los componentes tambin pueden exponer las interfaces. Estas son los puntos visibles de entrada o los servicios que un componente est ofreciendo y dejando disponibles a otros componentes de software y clases. Tpicamente, un componente est compuesto por numerosas clases y paquetes de clases internos. Tambin se puede crear a partir de una coleccin de componentes ms pequeos.

Los componentes y los NodosUn diagrama de despliegue muestra el despliegue fsico del sistema en un ambiente de produccin (o de prueba). Muestra dnde se ubican los componentes, en qu servidores, mquinas o hardware. Puede representar los enlaces de redes, el ancho de banda de la LAN, etc.

Requisitos

Los componentes pueden tener requisitos adjuntos para indicar sus obligaciones contractuales; esto es, qu servicios proveen en el modelo. Los requisitos ayudan a documentar el comportamiento funcional de los elementos de software.

RestriccionesLos componentes pueden restricciones asignadas que indican el entorno en el que operan. Las pre-condiciones especifican lo que debe ser verdadero antes de que un componente pueda realizar alguna funcin; las post-condiciones indican lo que debe ser verdadero despus de que un componente haya realizado algn trabajo y los invariantes especifican lo que debe permanecer verdadero durante la vida del componente.Un EjemploEl ejemplo siguiente muestra cmo se pueden relacionar los componentes para proveer una vista conceptual/lgica de la construccin de un sistema. Este ejemplo representa los elementos del servidor y la seguridad de una tienda de libros en lnea. Se incluyen elementos tales como el servidor WEB, el firewall, las pginas ASP, etc.

Los Componentes de ServidorEste diagrama ilustra la organizacin de los componentes del lado del servidor principal que se requerir construir para una tienda de libros en lnea. Estos componentes son una mezcla de los tems construidos a medida y adquiridos que se ensamblarn para proveer la funcionalidad requerida.

Los Componentes de Seguridad

El diagrama de componentes de la seguridad muestra cmo trabaja en conjunto el software de seguridad, tal como la Autoridad Certificadora (Certificate Authority), el navegador (Browser), el servidor WEB y otros elementos del modelo para asegurar la provisin de la seguridad en el sistema propuesto.

Diagrama de colaboracinEn los contratos de colaboracin se incluye una primera conjetura ptima sobre las poscondiciones referentes al inicio de las operaciones del sistema: inicio, introducirProducto, terminarVenta y efectuarPago. Los contratos no muestran una solucin de cmo los objetos de software van a cumplir con ellas.Los diagramas de colaboracin destacan la organizacin estructural de objetos que envan y reciben mensajes.

Actividades y dependenciasLos diagramas de interaccin se realizan en la fase de diseo de un ciclo de desarrollo. Para preparar tenemos primero debemos generar los siguientes artefactos: Un modelo conceptual: a partir de este modelo el diseador podr definir las clases del software correspondientes a los conceptos. Los objetos de las clases participan en las interacciones que se describen grficamente en los diagramas. Contratos de la operacin del sistema: a partir de ellos el diseador identifica las responsabilidades y las poscondiciones que han de llenar los diagramas de interaccin.

Ciclo de desarrollo

Perfeccionamiento del planSincronizacin de artefactosAnlisisDiseo

ConstruccinPruebaa. en paralelo con los diagramas de interaccin.b. orden variable1. Definir los casos reales de uso. 4. Definir los diagramas de interaccin.2. Definir los reportes, la interfaz del usuario, y las storyboards.5. Definir los diagramas de clases de diseo. a3. Perfeccionar la arquitectura del sistema. b6. Definir el esquema de la base de datos.

Actividades de la fase de diseo dentro de un ciclo de desarrolloCasos de uso: - expandidos- esenciales Diagramas de casos de usoModelo conceptualGlosarioDiagramas de secuencia del sistemaContratos de operacinDiagramas de estadoCasos de uso:- realesDiagramas de interaccinDiagramas de clase de diseoDiagramas de paquete de arquitecturaEsquema de base de datosVentanas y reportesMtodosDefiniciones de clase y de interfazSQLCasos de prueba

Sintaxis secuencia / colaboracin Los diagramas de colaboracin describen las interacciones entre los objetos en un formato de grafo red.

Notacin bsica de los diagramas de colaboracin

Representacin grfica de las clases y de las instancias:El UML ha adoptado un mtodo simple y uniforme de describir visualmente las instancias para distinguirlas de los tipos: Con cada tipo de elemento del UML (clase, actor, ), una instancia utiliza el mismo smbolo grfico usado para representar el tipo, pero se subraya el texto.

Venta:Ventas1: Ventaclaseinstanciainstanciacon nombre

Por tanto, para incluir la instancia de una clase en un diagrama de interaccin, se recurre al smbolo grfico usual de la casilla de la clase, solo el nombre se subraya.En un diagrama de colaboracin, al nombre de la clase siempre se le antepone dos puntos.Finalmente, un nombre de distancia sirve para identificarla de modo inequvoco.

Representacin grfica de los vnculosEl vnculo es una trayectoria de conexin entre dos instancias; indica alguna forma de navegacin y visibilidad que es posible entre las instancias. En un lenguaje ms formal, el vnculo es una instancia de una asociacin. Si vemos dos instancias en una relacin de cliente/servidor, una trayectoria de navegacin del cliente al servidor significa que los mensajes pueden enviarse del primero al segundo. As, existe un vnculo entre TPDV y una Ventana, a lo largo del cual pueden fluir los mensajes; por ejemplo, el mensaje agregarPago.

Representacin grfica de los mensajesLos mensajes entre objetos pueden representarse por medio de una flecha con un nombre y situada sobre una lnea del vnculo. A travs de ste puede fluir un nmero indefinido de mensajes. Se agrega un nmero de secuencia que indique el orden consecutivo de los mensajes en la serie de control.

Representacin grfica de los parmetrosLos parmetros de un mensaje pueden anotarse dentro de parntesis del nombre del mensaje. Es opcional incluir o no el tipo de parmetro en cuestin.

Representacin grfica del mensaje de devolver valorPueden incluir un valor de retorno anteponindole al mensaje un nombre de variable de esa instruccin y un operador de asignacin. Es opciones mostrar el tipo de valor retorno.

Sintaxis de los mensajesEl lenguaje UML cuenta con una sintaxis estndar para los mensajes:retorno: mensaje(parmetro : tipoParmetro ) : tipoRetorno

Es legal servirse de otra sintaxis como la de Java o la de Smalltalk. Recomendamos emplear la sintaxis estndar de UML a fin de que los diagramas de colaboracin sigan siendo un lenguaje relativamente independiente.

Representacin grfica de los mensajes al emisor o a estoPuede enviarse un mensaje de un objeto a s mismo.Esto lo muestra grficamente un vnculo consigo mismo, donde el mensaje fluye a lo largo del vnculo.

Representacin grfica de la iteracinLa iteracin se indica posponiendo un asterisco(*) al nmero de secuencia.Ese smbolo significa que, dentro de un ciclo, el mensaje va a ser enviado repetidamente al receptor.

Tambin es posible incluir una clusula de iteracin que indique los valores de recurrencia.

Si se expresa ms de un mensaje que ocurre dentro de la misma clusula de iteracin (por ejemplo, una serie de mensajes en un ciclo for), se repetir la clusula con cada mensaje.

En los pasos siguientes se denotara la construccin del diagrama de colaboracin Para elaborar un diagrama de colaboracin se debe aplicar las siguientes normas.1. Elaborar un diagrama por cada operacin del sistema durante el ciclo actual de desarrollo.2. Si el diagrama se torna complejo, dividir en diagramas mas pequeos.3. Disear un sistema de objetos interactivos que realicen las tareas, usando como punto de partida las responsabilidades del contrato de operacin, las poscondiciones y la descripcin de casos de uso. Aplicar el GRASP y otros patrones para desarrollar un buen diseo.

La relacin entre los artefactos incluye lo siguiente: Los casos de uso indican los eventos del sistema que se muestran explcitamente en los diagramas de su secuencia. En los contratos se describe la mejor conjetura inicial sobre las operaciones del sistema. Las operaciones del sistema representa mensajes y stos originan diagramas que explican grficamente cmo los objetos interactan para llevar a cabo las funciones requeridas.

Diagrama de objetosLos diagramas de objetos de UModel 2013 representan un nico ejemplo de una clase y se utilizan para ilustrar un punto de datos en su aplicacin.Los diagramas de objetos UML utilizan una notacin similar a los diagramas de clases y se utilizan para ilustrar una instancia de una clase en un momento dado. Imagine que desea dibujar un diagrama de objetos para ilustrar un ejemplo real de una clase y de sus relaciones. Los diagramas de objetos pueden ayudar a explicar las clases y su herencia. A veces se dibujan durante el proceso de planificacin de clases o para ayudar a partes interesadas para quienes los diagramas de clases sean demasiado abstractos.

Un objeto tambin se puede entender como la descripcin de un individuo que forme parte de un grupo, mientras que las clases describen las caractersticas compartidas por el grupo. As pues "CuentaCorriente" puede definirse como una clase UML en UModel 2013 y "Cuenta corriente de John en Agency Bank" se ilustrara como un diagrama de objetos.

Cuando cree un objeto nuevo, llamado especificacin de instancia en la barra de herramientas y en los mens de UModel, podr asignar una clase ya existente al objeto. UModel 2013 inserta automticamente en el objeto instancias de las propiedades pertinentes desde la clase y el usuario puede insertar valores de muestras para el objeto. En el ejemplo que aparece a continuacin se cre un objeto nuevo basado en una clase llamada StockTradingAccount. El diseador del modelo an no asign un valor a las propiedades balance, id ni SecretTradingPassword.

Puesto que los diagramas de objetos utilizan notaciones muy similares a los diagramas de clases, la barra de herramientas de diagramas de objetos usa algunos de los iconos de la barra de herramientas de diagramas de clases. Para editar los atributos y valores de un objeto puede utilizar la barra de herramientas, el cuadro de dilogo de propiedades o editar estos datos directamente en el diagrama.

La barra de herramientas de diseo ofrece gran cantidad de opciones de alineacin que estarn disponibles cuando seleccione varios elementos.

.En UML, un objeto se representa por un rectngulo con un nombre subrayado. Objeto = Identidad + Estado + Comportamiento El estado est representado por los valores de los atributos. Un atributo toma un valor en un dominio concreto.

Caractersticas alrededor de un objeto:Estado:El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes, el comportamiento agrupa las competencias de un objeto y describe las acciones y reacciones de ese objeto. Las operaciones de un objeto son consecuencia de un estmulo externo representado como mensaje enviado desde otro objeto. Persistencia:La persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo, podremos despus reconstruirlo, es decir, cogerlo de memoria secundaria para utilizarlo en la ejecucin (materializacin del objeto). Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual debera ser transparente, un objeto existe desde su creacin hasta que se destruya. Comunicacin:Un sistema informtico puede verse como un conjunto de objetos autnomos y concurrentes que trabajan de manera coordinada en la consecucin de un fin especfico. El comportamiento global se basa pues en la comunicacin entre los objetos que la componen.

Referencias Bibliogrficas

www.omg.org/uml/ Meta-links www.celigent.com/uml/ y www.cetus-links.org/oo_uml.html Pierre-Alain Muller Instant UML Martin Fowler, UML Destilled (UML Gota a Gota) Terry Quatrani, Visual Modeling ..., un caso de estudio modelo_de_componentes-1.pdf M2tema12.pdf http://www.ub.edu.ar/catedras/ingenieria/ing_software/ubftecwwwdfd/calidadsw/criterios.htm http://trevinca.ei.uvigo.es/~ebalonso/asignaturas/esx/guiones/esxClase26.pdf http://www.altova.com/es/umodel/object-diagrams.html

Pgina 36