¿QUÉ ES UML?
UML es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y unas reglas para permitir una comunicación. En este caso, este lenguaje se centra en la representación gráfica de un sistema.
Este lenguaje nos indica cómo crear y leer los modelos, pero no dice cómo crearlos. Esto último es el objetivo de las metodologías de desarrollo. Las objetivos de UML son muchos, pero se pueden sintetizar sus funciones:
• Visualizar: UML permite expresar de una forma gráfica un sistema de forma que otro lo puede entender.
• Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción.
Un Diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. UML ofrece una amplia variedad de diagramas para visualizar el sistema desde varias perspectivas.
A continuación se verán una serie de elementos notacionales pero sin entrar en detalle en la esencia de lo que es el concepto de cada cosa (que se da por supuesto), sino solo en la forma de dibujarlo en UML.
- Nombre: Si aparece en cursiva la clase es abstracta.
- Atributos: Pueden mostrar mucha información.
- Tipo: Atributo:Tipo
- Valor predeterminado: Atributo:Tipo=Valor ó Atributo=Valor
- Restricciones: Las restricciones se pueden poner como se ha visto en el gráfico, pero UML cuenta con un método aún más formal que es el lenguaje OCL.
- Alcance: Un atributo puede ser público(+), protegido(#) o privado(-).
- Ámbito: Hay dos tipos
- Instancia: Cada objeto tiene su propio valor.
- Archivador: Solo hay un valor en todas las instancias de una clase (como las variables static en Java). Estos atributos aparecen subrayados.
Toda esta información es opcional, de hecho la mayoría de las veces se pone sólo el nombre del atributo.
- Métodos: Al igual que los atributos también pueden especificar su alcance o ámbito. Además pueden indicar el tipo de los argumentos que reciben y el tipo del valor devuelto. Tanto si tienen parámetros como si no deben llevar un paréntesis abierto y otro cerrado al final del nombre.
- Responsabilidades: Es una descripción de lo que hace la clase en su conjunto. Está información casi nunca está en los diagramas.
La información que se ha puesto en la figura de ejemplo es mucho más de la que se suele mostrar, una clase puede representarse con un simple rectángulo con su nombre.
Además se puede omitir parte de la información de un apartado. Los puntos suspensivos que hay en el ejemplo al final de las secciones de atributos y métodos indican que la clase está abreviada, o lo que es lo mismo, faltan atributos y métodos. Sólo se pone lo necesario para expresar la idea del diagrama.
Los estereotipos son una forma de introducir nuevos términos sobre el vocabulario propio de un dominio. Los paquetes son agrupaciones de clases relacionadas de alguna forma entre sí. Las notas son un texto explicativo de algún elemento
Los objetos son instancias de clases (sus atributos tienen valores específicos) y, se representan poniendo el nombre de la instancia a la izquierda, dos puntos y el nombre de la clase de la que deriva a la derecha.
Las clases no están aisladas, entre ellas pueden relacionarse de muchas maneras. La representación básica de las relaciones es una línea (con otros elementos adicionales como flechas, rombos, texto, etc.) entre las clases relacionadas.
Es una relación conceptual, que no es inherente a la naturaleza de las clases, sino al papel que juegan en el modelo y especifica que las instancias de una clase están conectadas con las de otra. No es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro. La relación tiene un nombre que indica en que consiste y su dirección, indicada con un triángulo relleno. Se puede indicar además (de forma opcional) cual es el papel (rol) que representa cada una de las partes en la relación.
Es posible que dos clases estén relacionadas entre sí por más de una relación en ambos sentidos o que una clase esté relacionada con muchas. Se dice que una relación es reflexiva cuando una clase está asociada consigo misma. Es posible que una instancia de una clase pueda estar relacionada con un número variable de instancias de otra. La notación para expresar esa multiplicidad es flexible:
- Números concretos. Un número exacto: A. Por ejemplo: 5 (significa exactamente 5).
- Intervalos. Entre A y B, ambos incluidos: A..B. Por ejemplo: 2..6 (es entre 2 y 6).
- Asterisco. El símbolo * significa muchos. Si está en un intervalo se pone en el extremo superior. A..* se lee: A o más. Por ejemplo: 3..* (es 3 o más). Si el * está solo significa que puede ser un número cualquiera, cero incluido.
- Combinación de los elementos anteriores: Por ejemplo: 1..4,6,9..* (que significa entre 1 y 4, ó 6, ó 9 ó más de 9, es decir, los valores 0, 5, 7 u 8 no estarían permitidos); 2,4,6 (es los valores 2, 4 ó 6 y ninguno más).
- Un alumno puede estar matriculado como mínimo en una asignatura (si no está en ninguna no es alumno) y como máximo en 11.
- En una asignatura se pueden matricular un número ilimitado de alumnos pero tiene que haber al menos uno o de lo contrario la asignatura no existe.
- Un alumno puede estar haciendo o no el proyecto fin de carrera. En caso afirmativo tendrá un profesor asignado como coordinador.
- Existen asignaturas que tienen prácticas y algunas de ellas son entre varios. Un alumno puede estar asociado con un número variable de compañero para hacerlas, puede ser que con nadie, uno, dos,..
Navegabilidad
Es una propiedad del rol. Indica la posibilidad de ir desde el objeto fuente al objeto destino. Significa visibilidad, o sea que generalmente se ``ven'' los atributos. Por defecto la navegabilidad es bidireccional, pero a veces no será posible viajar en ambas direcciones.
Cuando se tiene una relación uno a muchos existe el problema de la búsqueda, es decir, localizar la instancia correcta en el lado ``muchos''. Para reducir el número de instancias a uno se utiliza un atributo de la relación.
Es un tipo de relación del tipo todo/parte. Sirve para modelar elementos que se relacionan utilizando expresiones como: ``es parte de'', ``tiene un'', ``consta de'', etc. Todo lo que se ha dicho antes acerca de la multiplicidad es válido aquí.
Composición
Es un tipo de agregación donde cada componente pertenece a un todo y sólo a uno (en el ejemplo anterior no se cumple esto, por ejemplo, la antigua Unión Soviética tenía una parte europea y una parte asiática).
Indica que una subclase o clase secundaria hereda los métodos y atributos definidos en una superclase o clase principal. La superclase es más genérica que la subclase. Este tipo de conexión se lee como ``es un tipo de''. En UML se utiliza el término generalización en vez de herencia, pero es lo mismo.
Es un tipo de relación en la que una clase usa a la otra. Por ejemplo: Una interfaz de un programa de dibujo tiene varios objetos en la pantalla. La clase Pantalla tiene el métodoDibujarObjetoGrafico(o:OG) y dibujará una recta, un punto, etc en función de lo que sea ese objeto.
Son un conjunto de operaciones que especifican parte de la funcionalidad proporcionada por una clase. Una interfaz es como una clase pero sin atributos. En una como una clase con el estereotipo interfaz y en otra abreviada, sin mostrar los métodos. Entre los interfaces también existe herencia. Una clase puede implementar varios interfaces, y un interfaz puede ser implementado por más de una clase. Todos los métodos de un interfaz son públicos.
Es el diagrama más importante en UML. Es un modelo estático del sistema que contiene los siguientes elementos:
- Clases
- Interfaces
- Colaboraciones: Conjunto de clases, interfaces y demás que exhiben un comportamiento.
- Relaciones de dependencia, colaboración y asociación.
Se puede utilizar para modelizar tres cosas:
- Los elementos del sistema.
- Colaboraciones.
- Esquema lógico de bases de datos.
Veamos el modelado con diagrama de clases con el ejemplo de una estructura documental. Un objeto documental es, por ejemplo, un ejemplar de ``La divina comedia'' o la ``enciclopedia Espasa'', que está compuesto por varios volúmenes. Cada libro tiene una portada y un texto que se pueden ver. Los libros se pueden consultar, abrir, etc; tienen título, autor y un número de páginas. Cada ejemplar puede haber sido editado por una editorial en una fecha determinada. Un libro puede haber sido traducido a varios idiomas y ser citado en algunos diccionarios, los cuales a su vez pueden ser de un único tipo: multivolumen, que están compuestos (como es lógico) por varios volúmenes. Los tipos de libros que existen son: con anexo o hipermedia. Los de tipo hipermedia pueden tener sonido o enlaces.
Es un diagrama que contiene objetos y enlaces entre ellos. Pueden también agruparse en paquetes y se puede mostrar las clases si se considera oportuno para mostrar los objetos que vienen de una clase concreta. Sirve para tomar una instantánea del sistema en un momento dado del funcionamiento. También es un modelo estático porque no representa la evolución a través del tiempo, sino un momento concreto.
- Se pone el objeto en un rectángulo.
- El nombre es opcional pero se debe poner la clase a la que pertenece precedida por dos puntos, todo ello subrayado: NombreObjeto:Clase
- Puede tener variables con su valor.
- Al igual que las clases los objetos pueden estereotiparse.
- Los objetos pueden estar relacionados por enlaces, que son instancias de las asociaciones definidas en el diagrama de clases.
Los casos de uso son una descripción de una interacción con el sistema por parte de algo externo al sistema que se llama actor. Por ejemplo: un usuario pulsa el botón de llamada de un ascensor. El nombre del caso de uso se pone en la elipse. Un caso de uso es un patrón o comportamiento que exhibe el sistema. Los casos de uso representan requisitos funcionales. Los casos de uso se escriben desde el punto de vista del actor, que es el usuario o sistema externo que interactúa con el sistema.
Relaciones que nos podemos encontrar en los casos de uso.
- Include: Es el concepto de subrutina. Si por ejemplo tenemos dos casos de uso A y B que tienen una serie de pasos en común se ponen esos pasos en un tercer caso de uso C y A y B lo incluyen para usarlo.
- Extends: Significa que un caso de uso B es igual al A al cual extiende añadiendo algunos pasos.
- Comunicates: Comunica un actor con un caso de uso o con otro actor.
Hay que modelar la relación que tiene el sistema con los elementos externos. Los pasos a seguir son:
- Identificar los actores que interactúan con el sistema.
- Organizar los actores.
- Especificar las vías de comunicación con el sistema.
Esto significa incorporar los casos de uso necesarios, tanto los que son visibles externamente como los que no. Para ello las actividades a seguir son:
- Establecer su contexto.
- Identificar las necesidades de los elementos del contexto.
- Nombrar esas necesidades y darles nombre de casos de uso.
- Identificar que casos de uso pueden ser especializaciones de otros y buscar especializaciones comunes para los casos de uso ya encontrados. Los casos de uso se verán con detalle más adelante.
Diagrama de estados
Un sistema evoluciona en el tiempo pasando por una serie de estados. Parte de un estado inicial y llega a un estado final. Un estado tiene:
- Nombre.
- Variables.
- Actividades, que pueden ser de dos tipos:
Y constan de las siguientes partes:
- Signature: Nombre y lista de parámetros.
- Guard condition: Expresión lógica que habilita o no la transición.
- Acción: Acción interna a ser ejecutada.
- Mensaje: Evento enviado a otro objeto (o a varios).
Las transiciones entre estados pueden tener parámetros. Cada transición tiene un evento asociado. Cuando se terminan las actividades de un estado hay una transición.
Por ejemplo, supongamos que tenemos un ascensor que cuando está en el sótano (área restringida a la que sólo se puede acceder con llave) sube a los pocos segundos para evitar que si alguien se ha colado pueda acceder a las viviendas. Por otra parte el ascensor puede estar subiendo, bajando o parado. Cuando se está bajando al sótano se considera como un estado especial y el hecho de estar en el sótano también.
Muestra los objetos y los mensajes intercambiados entre ellos teniendo en cuenta la temporalidad con la que ocurren. Pueden mostrarse también los componentes porque son objetos reutilizables y los casos de uso porque se muestran como objetos que implementan el caso de uso. Sirven para documentar el diseño y validar los casos de uso. Gracias a estos diagramas se puede ver cuales don los cuellos de botella del sistema observando el tiempo que consume el método invocado. Los conceptos a tener en cuenta son:
- Línea de vida de un objeto: Es una representación de la actividad del objeto durante el tiempo que dura el escenario. El tiempo transcurre de arriba abajo. Se representa con una cabecera con un rectángulo con el nombre del objeto y una línea vertical de puntos por debajo. Durante el tiempo en el cual el objeto tiene un método funcionando la línea de puntos se convierte en un rectángulo como se muestra en el ejemplo.
- Activación: Es el proceso por el que un objeto pasa a tener un método en ejecución. Esto puede ocurrir o bien porque otro objeto ha invocado alguno de sus métodos o porque lo ha invocado el mismo (self-delegation). Cuando un objeto activa a otro siguen en actividad.
- Mensaje: Un mensaje es un objeto que invoca el método de otro. La notación es una flecha horizontal desde la línea de vida de un objeto hasta otro.
- Tiempos de transición: Es el tiempo que hay entre un mensaje y otro.
- Condicionales: Si se desea representar una alternativa o threads. El mensaje sólo se envía si la condición es verdadera.
- Iteración: Se pone el símbolo * previo a la condición. Se repite la acción mientras la condición es verdadera.
- Creación y destrucción de un objeto: La creación de un objeto se representa con un mensaje de creación sobre un rectángulo. La destrucción se representa con un aspa al final de su línea de vida.
- Métodos recursivos: Se representan poniendo un rectángulo superpuesto al que está activo en el momento.
Diagrama de secuencias. Métodos recursivos y destrucción de objetos |
Las boundary classes, o clases de frontera, sirven para capturar y documentar los requisitos de interfaz. Muestran la interacción con el usuario o con un sistema externo. Las clases de entidad son las inherentes al modelo del dominio y las de control son las que gestionan el caso de uso asociado al diagrama de secuencias.
Reglas a seguir:
- La primera columna debe corresponder al actor que inicia el caso de uso.
- La segunda columna debe ser un objeto de frontera, que se comunica con el actor.
- La tercera columna debe ser un objeto de control que gestiona el caso de uso.
- Los objetos de control son creados por el objeto de frontera que inicia el caso de uso.
- Los objetos de frontera son creados por objetos de control.
- Los objetos de entidad son accedidos por objetos de control y frontera.
- Los objetos de entidad nunca tienen acceso a los objetos de frontera o control. De esta forma estos objetos pueden ser reutilizados en varios casos de uso distintos.
Diagrama de actividades
Son un caso especial de los diagramas de estados. Modela el comportamiento del sistema y la participación de las clases en ese comportamiento. Describen el comportamiento interno de una clase en vez del comportamiento en función de los eventos. Para construirlos se puede seguir la siguiente estrategia:
- Identificar una clase que participa en el comportamiento cuyas actividades de proceso deban ser especificadas.
- Identificar las distintas actividades que se van a modelar.
- Identificar: estados, flujos y objetos.
Este diagrama es útil para modelar el flujo de trabajo de un negocio a alto nivel, como lo son:
- Punto inicial. Se representa por un círculo negro.
- Punto final. Es una diana.
- Actividades. Son rectángulos con bordes redondeados.
- Transiciones. Son el paso de una actividad a otra. Se representan con flechas.
- Actividades concurrentes. Se representan por sus correspondientes actividades y una barra negra de la cual parten las flechas que las inician.
- Bifurcaciones: Se representan con un rombo o sencillamente con dos flechas que salen de una actividad a otras dos. En cualquier caso, la condición se indica en cada uno de los ramales entre corchetes.
- Indicaciones: Se pueden enviar o recibir. El envío se representa con un rectángulo acabado en flecha. El que las recibe con una figura complementaria de la anterior. Una indicación modela el envío y recepción de eventos.
Modelan la vista estática del sistema. Ilustran la organización y las dependencias entre componentes software. Un componente puede ser: código fuente, un programa ejecutable, tablas, o cualquier otro tipo de documento que forme parte del sistema. No tienen que estar presentes todos los componentes, suele mostrarse una parte. Un componente puede implementar una interfaz.
El estándar de UML define cinco estereotipos: executable, library, table, file y document.
Para modelarlos los pasos a seguir son:
- Identificar los componentes, particiones del sistema, cuales son factibles de ser reutilizadas, agruparlas por nodos y realizar un diagrama por cada nodo que se quiera modelar.
- Identificar cada componente con su estereotipo correspondiente (executable, library, etc).
- Relacionar los componentes entre sí.
Podemos usar estos diagramas para expresar las dependencias que existen entre los módulos para formar librerías o programas ejecutables.
Dibuja las interacciones entre objetos organizadas a través de los objetos y los enlaces que hay entre ellos. Este diagrama es otra forma de ver la secuencia de eventos. Es lo mismo que los diagramas de secuencia (se puede generar de un modo automático un tipo de diagrama a partir del otro).
Refleja la organización del hardware. El elemento principal de este diagrama es el nodo. Hay dos tipos: los nodos con capacidad de ejecutar componentes y los que no pueden ejecutar. La información que hay en un nodo es: nombre del nodo y componentes del nodo (se puede poner sólo sus nombres o un diagrama de componentes). Los nodos a su vez pueden estar físicamente conectados con otros, lo que se representa con una línea que los une. La utilidad principal de este tipo de diagramas es la modelización de una red.
Componentes de una herramienta case
De una forma esquemática podemos decir que una herramienta CASE se compone de los siguientes elementos:
Repositorio (diccionario) donde se almacenan los elementos definidos o creados por la herramienta, y cuya gestión se realiza mediante el apoyo de un Sistema de Gestión de Base de Datos (SGBD) o de un sistema de gestión de ficheros.
Meta modelo (no siempre visible), que constituye el marco para la definición de las técnicas y metodologías soportadas por la herramienta.
Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez, alimentar otros sistemas. Este elemento proporciona así un medio de comunicación con otras herramientas.
Comprobación de errores, facilidades que permiten llevar a cabo un análisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta.
Interfaz de usuario, que constará de editores de texto y herramientas de diseño gráfico que permitan, mediante la utilización de un sistema de ventanas, iconos y menús, con la ayuda del ratón, definir los diagramas, matrices, etc. que incluyen las distintas metodologías.
Estructura general de una herramienta case
La estructura CASE se basa en la siguiente terminología:
CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases finales o superiores del ciclo de vida del desarrollo de sistemas como la planificación de sistemas, el análisis de sistemas y el diseño de sistemas.
CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida como el diseño detallado de sistemas, la implantación de sistemas y el soporte de sistemas.
CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen actividades como la gestión de proyectos y la estimación.
Estado Actual
En las últimas décadas se ha trabajado en el área de desarrollo de sistemas para encontrar técnicas que permitan incrementar la productividad y el control de calidad en cualquier proceso de elaboración de software, y hoy en día la tecnología CASE (Computer Aided Software Engineering) reemplaza al papel y al lápiz por el ordenador para transformar la actividad de desarrollar software en un proceso automatizado.
La tecnología CASE supone la –informatización de la informática—es decir –la automatización del desarrollo del software--, contribuyendo así a elevar la productividad y la calidad de en el desarrollo de los sistemas de información de forma análoga a lo que suponen las técnicas CAD/CAM en el área de fabricación.
En este nuevo enfoque que persigue mejorar la calidad del software e incrementar la productividad en el proceso de desarrollo del mismo, se plantean los siguientes objetivos:
Permitir la aplicación práctica de metodologías, lo que resulta muy difícil sin emplear herramientas.
Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.
Simplificar el mantenimiento del software.
Mejorar y estandarizar la documentación.
Aumentar la portabilidad de las aplicaciones.
Facilitar la reutilización de componentes de software
Permitir un desarrollo y un refinamiento (visual) de las aplicaciones, mediante la utilización de controles gráficos (piezas de código reutilizables).
Integración de las herramientas case en el futuro
Las herramientas CASE evolucionan hacia tres tipos de integración:
La integración de datos permite disponer de herramientas CASE con diferentes estructuras de diccionarios locales para el intercambio de datos.
La integración de presentación confiere a todas las herramientas CASE el mismo aspecto.
La integración de herramientas permite disponer de herramientas CASE capaces de invocar a otras CASE de forma automática.
Clasificación de las herramientas case
No existe una única clasificación de herramientas CASE y, en ocasiones, es difícil incluirlas en una clase determinada. Podrían clasificarse atendiendo a:
- Las plataformas que soportan.
- Las fases del ciclo de vida del desarrollo de sistemas que cubren.
- La arquitectura de las aplicaciones que producen.
- Su funcionalidad.
CASE es una combinación de herramientas software (aplicaciones) y de metodologías de desarrollo:
1. Las herramientas permiten automatizar el proceso de desarrollo del software.
2. Las metodologías definen los procesos automatizar.
Una primera clasificación del CASE es considerando su amplitud:
TOOLKIT: es una colección de herramientas integradas que permiten automatizar un conjunto de tareas de algunas de las fases del ciclo de vida del sistema informático: Planificación estratégica, Análisis, Diseño, Generación de programas.
WORKBENCH: Son conjuntos integrados de herramientas que dan soporte a la automatización del proceso completo de desarrollo del sistema informático. Permiten cubrir el ciclo de vida completo. El producto final aportado por ellas es un sistema en código ejecutable y su documentación.
Una segunda clasificación es teniendo en cuenta las fases (y/o tareas) del ciclo de vida que automatizan:
UPPER CASE: Planificación estratégica, Requerimientos de Desarrollo Funcional de Planes Corporativos.
MIDDLE CASE: Análisis y Diseño.
LOWER CASE: Generación de código, test e implantación
Características Deseables De Una Case
Una herramienta CASE cliente / servidor provee modelo de datos, generación de código, registro del ciclo de vida de los proyectos, comunicación entre distintos ingenieros. Las principales herramientas son KnowledgeWare’s Application Development Workbench, TI’s, Information Engineering Facility (IEF), y Andersen Consulting’s Foundation for Cooperative Processing.
Deberes de una herramienta CASE Cliente / servidor:
Proporcionar topologías de aplicación flexibles. La herramienta debe proporcionar facilidades de construcción que permita separar la aplicación (en muchos puntos diferentes) entre el cliente, el servidor y más importante, entre servidores.
Proporcionar aplicaciones portátiles. La herramienta debe generar código para Windows, OS/ 2, Macintosh, Unix y todas las plataformas de servidores conocidas. Debe ser capaz, a tiempo de corrida, desplegar la versión correcta del código en la máquina apropiada.
Control de Versión. La herramienta debe reconocer las versiones de códigos que se ejecutan en los clientes y servidores, y asegurarse que sean consistentes. También, la herramienta debe ser capaz de controlar un gran número de tipos de objetos incluyendo texto, gráficos, mapas de bits, documentos complejos y objetos únicos, tales como definiciones de pantallas y de informes, archivos de objetos y datos de prueba y resultados. Debe mantener versiones de objetos con niveles arbitrarios de granularidad; por ejemplo, una única definición de datos o una agrupaciónde módulos.
Crear código compilado en el servidor. La herramienta debe ser capaz de compilar automáticamente código 4GL en el servidor para obtener el máximo performance.
Trabajar con una variedad de administradores de recurso. La herramienta debe adaptarse ella misma a los administradores de recurso que existen en varios servidores de la red; su interacción con los administradores de recurso debería ser negociable a tiempo de ejecución.
Trabajar con una variedad de software intermedios. La herramienta debe adaptar sus comunicaciones cliente / servidor al software intermedio existente. Como mínimo la herramienta debería ajustar los temporizadores basándose en, si el tráfico se está moviendo en una LAN o WAN. Soporte multiusuarios. La herramienta debe permitir que varios diseñadores trabajen en una aplicación simultáneamente. Debe gestionarse los accesos concurrentes a la base de datos por diferentes usuarios, mediante el arbitrio y bloqueos de accesos a nivel de archivo o de registro.
Seguridad. La herramienta debe proporcionar mecanismos para controlar el acceso y las modificaciones a los que contiene. La herramienta debe, al menos, mantener contraseñas y permisos de acceso en distintos niveles para cada usuario. También debe facilitar la realización automática de copias de seguridad y recuperaciones de las mismas, así como el almacenamiento de grupos de información determinados, por ejemplo, por proyecto o aplicaciones.
Desarrollo en equipo, repositorio de librerías compartidas. Debe permitir que grupos de programadores trabajen en un proyecto común; debe proveer facilidades de check-in/ check-out registrar formas, widgets, controles, campos, objetos de negocio, DLL, etc.; debe proporcionar un mecanismo para compartir las librerías entre distintos realizadores y múltiples herramientas; Gestiona y controla el acceso multiusuario a los datos y bloquea los objetos para evitar que se pierdan modificaciones inadvertidamente cuando se realizan simultáneamente.
No hay comentarios:
Publicar un comentario