Documentos de Académico
Documentos de Profesional
Documentos de Cultura
El Anlisis y Diseo de Sistemas involucra diagnosticar las situaciones actuales de un sistema con la finalidad de plasmar sus mejoras en un diseo, programando, probando e implementado un Sistema de Informacin. Es as como a continuacin se describen la Ingeniera y Reingeniera de Software como disciplinas de la ciencia estrechamente vinculadas a estas actividades.
Upper CASE: Las herramientas para soportar las actividades de requerimiento y diseo. Por
ejemplo, se citan las herramientas de modelaje de DFD, ER y UML.
Lower CASE: Las herramientas para soportar las actividades como la programacin, el
depuramiento y las pruebas. \n
3. Procedimientos: Son la combinacin de las tcnicas y las herramientas que en forma conjunta dan un resultado particular. Los procedimientos indicarn qu herramientas debern utilizarse cuando se aplican determinadas tcnicas. Definen la secuencia en que se aplican los mtodos, los documentos que se requieren, los controles que aseguran la calidad y las directrices que permiten a los gestores evaluar los progresos. 4. Paradigmas: Representan un enfoque particular o filosofa para la construccin del software. No es mejor uno que otro sino que cada uno tiene ventajas y desventajas. Tambin hay situaciones donde un paradigma resulta ms apropiado que otro. Ejemplos: Anlisis y Diseo Orientado a Objetos y Anlisis y Diseo Estructurado.
ha de planificar todas las etapas del mismo, tanto de creacin como de correccin Para llevarlo a cabo tenemos diferentes oportunidades. A eleccin ser ms ptimo si analizamos bien los requerimientos y propiedades que se desean para el sistema. Especificacin: Para realizar la especificacin, en la mayora de los proyectos se utiliza UML (Unified Modeling Languaje) (Lenguaje de Modelado unificado) en el paradigma orientado a objeto, el cual es un lenguaje visual que permite plasmar en notacin orientada a objetos las necesidades o requerimientos. Y para el paradigma estructurado se utiliza Diagrama de de Fuljo de datos (DFD). Smbolos grficos que representan entidades, flujo de datos, archivos o almacenes de datos y procesos Diseo: Es la fase de diseo se determinar la arquitectura general del sistema y su comportamiento dinmico, adaptando la especificacin realizada en la etapa anterior. En esta fase, se decide que tecnologa se utilizar en el sistema aprovechando y adaptando sus ventajas. Desarrollo y trabajo en equipo: La implementacin del diseo es una fase muy extensa y requiere de un equipo de desarrolladores. La coordinacin de este equipo es muy importante si se desea finalizar el proyecto en el tiempo previsto. Mantenimiento: La fase de mantenimiento de un proyecto contiene las fases de implantacin, Prueba , depuracin y control de rendimiento, etapas que nos permiten ajustar nuestro sistema de forma que sus funcionalidades correspondan con los objetivos iniciales.
http://www.microsoft.com/spanish/MSDN/estudiantes/ingsoft/ingenieria/default.asp Para poder completar con xito un proyecto de software, se necesita tener unos controles rigurosos sobre el tiempo, las personas o los imprevistos que puedan surgir, como por ejemplo cambios en el software. Para ayudarnos en la planificacin y gestin de proyectos, debemos conocer tcnica de planificacin.
Mejorar la calidad de los productos de software Aumentar la productividad y trabajo de los ingenieros del software. Facilitar el control del proceso de desarrollo de software. Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente. Definir una disciplina que garantice la produccin y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado.
Capacidad
Las actividades de la organizacin estn influenciadas por la capacidad de sta para procesar transacciones con rapidez y eficiencia. Los sistemas de informacin mejoran esta capacidad en tres formas. * Aumentan la velocidad de procesamiento: Los sistemas basados en computadora pueden ser de ayuda para eliminar la necesidad de clculos tediosos y comparaciones repetitivas. Un sistema automatizado puede ser de gran utilidad si lo que se necesita es un procesamiento acelerado. *Aumento en el volumen: La incapacidad para mantener el ritmo de procesamiento no significa el abandono de los procedimientos existentes. Quiz stos resulten inadecuados para satisfacer las demandas actuales. En estas situaciones el analista de sistemas considera el impacto que tiene la introduccin de procesamiento computarizado, si el sistema existente es manual. Es poco probable que nicamente el aumento de la velocidad sea la respuesta. El tiempo de procesamiento por transaccin aumenta si se considera la cantidad de actividades comerciales de la empresa junto con su patrn de crecimiento. * Recuperacin ms rpida de la informacin: Las organizaciones almacenan grandes cantidades de datos, por eso, debe tenerse en cuenta donde almacenarlos y como recuperarlos cuando se los necesita. Cuando un sistema se desarrolla en forma apropiada, se puede recuperar en forma rpida la informacin.
Costo
* Vigilancia de los costos: Para determinar si la compaa evoluciona en la forma esperada, de acuerdo con lo presupuestado, se debe llevar a cabo el seguimiento de los costos de mano de obra, bienes y gastos generales.
La creciente competitividad del mercado crea la necesidad de mejores mtodos para seguir los costos y relacionarlos con la productividad individual y organizacional. * Reduccin de costos: Los diseos de sistemas ayudan a disminuir los costos, ya que toman ventaja de las capacidades de clculo automtico y de recuperacin de datos que estn incluidos en procedimientos de programas en computadora. Muchas tareas son realizadas por programas de cmputo, lo cual deja un nmero muy reducido de stas para su ejecucin manual, disminuyendo al personal.
Control
*Mayor seguridad de informacin: Algunas veces el hecho de que los datos puedan ser guardados en una forma adecuada para su lectura por medio de una mquina, es una seguridad difcil de alcanzar en un medio ambiente donde no existen computadoras. Para aumentar la seguridad, generalmente se desarrollan sistemas de informacin automatizados. El acceso a la informacin puede estar controlado por un complejo sistemas de contraseas, limitado a ciertas reas o personal, si est bien protegido, es difcil de acceder. *Menor margen de error: (mejora de la exactitud y la consistencia) Esto se puede lograr por medio del uso de procedimientos de control por lotes, tratando de que siempre se siga el mismo procedimiento. Cada paso se lleva a cabo de la misma manera, consistencia y con exactitud: por otra parte se efectan todos los pasos para cada lote de transacciones. A diferencia del ser humano, el sistema no se distrae con llamadas telefnicas, ni olvidos e interrupciones que sufre el ser humano. Si no se omiten etapas, es probable que no se produzcan errores.
Comunicacin
La falta de comunicacin es una fuente comn de dificultades que afectan tanto a cliente como a empleados. Sin embargo, los sistemas de informacin bien desarrollados amplan la comunicacin y facilitan la integracin de funciones individuales. * Interconexin: (aumento en la comunicacin) Muchas empresas aumentan sus vas de comunicacin por medio del desarrollo de redes para este fin, dichas vas abarcan todo el pas y les permiten acelerar el flujo de informacin dentro de sus oficinas y otras instalaciones que no se encuentran en la misma localidad. Una de las caractersticas ms importantes de los sistemas de informacin para oficinas es la transmisin electrnica de informacin, como por ejemplo, los mensajes y los documentos. * Integracin de reas en las empresas: Con frecuencia las actividades de las empresas abarcan varias reas de la organizacin, la informacin que surge en un rea se necesita en otra rea, por ejemplo. Los sistemas de informacin ayudan a comunicar los detalles del diseo a los diferentes grupos, mantienen las especificaciones esenciales en un sitio de fcil acceso y calculan factores tales como el estrs y el nivel de costos a partir de detalles proporcionados por otros grupos.
Competitividad
Los sistemas de informacin computacionales son un arma estratgica, capaz de cambiar la forma en que la compaa compite en el mercado, en consecuencia stos sistemas mejoran la organizacin y la ayudan a ganar "ventaja competitiva", sin embargo, si los competidores de la compaa tienen capacidades mas avanzadas para el procesamiento de informacin, entonces los sistemas de informacin pueden convertirse en una "desventaja competitiva". Una organizacin puede ganar ventaja competitiva a travs de sus sistemas de informacin de diferentes formas. * Asegurar clientes: Como los clientes son los ms importantes para una organizacin, los directivos buscan diferentes formas para conseguir nuevos clientes y mantener los que tienen. Para eso las empresas proporcionan: 1- Mejores precios 2- Servicios exclusivos. 3- Productos diferentes. La ventaja en precios se observa continuamente en la actividad comercial (s el producto es exclusivo o distinto entonces tener el liderazgo en precios bajos quizs no sea el objetivo a alcanzar). La estrategia eficaz de precios a menudo se alcanza al desarrollar sistemas de informacin por razones tales como reduccin de costos y ganancia en la exactitud. Generalmente cuando una compaa puede ofrecer servicios exclusivos y atraer clientes, es posible que los competidores no sean capaces de atraer a los clientes de la compaa. * Dejar fuera a los competidores: Pasar sobre los competidores puede ser un inconveniente si ellos se encuentran la forma para duplicar los logros de la compaa, los sistemas de informacin pueden ser la base para dejar fuera del mercado a la competencia ya sea el disuadir sus intentos por ingresar al mercado o crendoles obstculo para su entrada. *Mejores acuerdos con los proveedores: En los negocios, los proveedores tambin tienen importancia estratgica. Una manera de utilizar los sistemas de informacin para favorecer arreglos con los proveedores es ofreciendo un mejor precio. Disminuyendo los costos. *Formar bases para nuevos productos Los sistemas de informacin tambin forman la base de muchos productos y servicios nuevos. Los servicios de base de datos experimentan un crecimiento comn en todas las industrias. Productos que van desde programas personales hasta planes de construccin pueden hacerse a la medida del cliente gracias al procesamiento de informacin. Una cosa es clara, es necesario que los sistemas entren en operacin y que trabajen de manera confiable
Reestructuracin de documentos o Pueden usarse 3 opciones, dependiendo de la ms adecuada para el negocio en cuestin. Opcin 1: Puede evitarse la documentacin de programas estticos con poca probabilidad de experimentar cambios. Opcin 2: Se documenta solamente lo que se modifica, y con el tiempo se obtendr una valiosa coleccin de documentacin de cambios realizados. Opcin 3: Se documenta toda la informacin del sistema, ya que ste es fundamental para el buen desarrollo del negocio.
Ingeniera inversa o Es un proceso de recuperacin de diseo. Se extrae informacin acerca de los datos, arquitectura y diseo de procedimientos de un programa existente.
Reestructuracin del cdigo o Se analiza el cdigo fuente utilizando una herramienta de reestructuracin. Las violaciones de las estructuras de programacin estructurada se indican, y entonces se reestructura el cdigo.
Reestructuracin de datos o Se debe tener en cuenta cuando suceden por reglas de negocio u otras causas la reestructuracin de datos, ya que inevitablemente sta producir una reestructuracin de cdigo.
Ingeniera progresiva o En un mundo ideal, las aplicaciones se reconstruyen utilizando "motor de reingeniera automatizado". Se insertara el viejo programa, que lo analizara, lo reestructurara y despus regenerara mejores aspectos de calidad del software.
Dentro de la reingeniera, el proceso de pasar del cdigo a una descripcin de ms alto nivel es lo que se denomina:
Ingeniera inversa.
La reingeniera e ingeniera inversa prolongan la vida del software. Dado que es una labor estratgica, es conveniente conocer cuando conviene realizar la tarea de reingeniera para una aplicacin y cundo es ms rentable sustituirla e implementar una nueva. Las aplicaciones para el primer paso, son aquellas en la que se produce las siguientes situaciones: Fallos frecuentes, que son difciles de localizar Son poco eficientes, pero realizan la funcin esperada Dificultades en la integracin con otros sistemas Calidad pobre del software final Resistencia a introducir cambios Pocas personas capacitadas para realizar modificaciones Dificultades para realizar pruebas El mantenimiento consume muchos recursos Es necesario incluir nuevos requisitos, pero los bsicos se mantienen.
Desarrollo de software con y para reuso El desarrollo de software con reso consiste en desarrollar una aplicacin usando software ya existente. Cualquier profesional lo utiliza El desarrollo de software para reuso consiste en la construccin de un sistema con la intencin de reutilizar partes de l en futuros desarrollos. Con software a gran escala, un buen profesional con experiencia puede desarrollarlo. Estudios realizados determinan que la prctica de reutilizacin del software en un proyecto aumenta la productividad durante el desarrollo de dicho proyecto. Sin embargo, la reutilizacin del software no cubre solo el reuso de cdigos, abarca todo un amplio de posibilidades en los diferentes niveles, metodologa, ciclos de vida, planes del proyecto, especificaciones de requisitos, diseos, arquitectura software, planes de validacin, juegos de prueba y documentacin.
Smbolos
Significado ENTIDAD
Ejemplo ESTUDIANTE
Usuario o dispositivos H/S FLUJO DE DATOS Nva Informacin de estudiante Formas; Reportes; Datos Magnticos 2.1 PROCESO Crear registro de estudiante Mdulos de Software o procedimientos AutomticosManuales ALMACEN DE DATOS D3 Maestro de Estudiante
Objeto
De manera intuitiva, la tendencia general es asociar el trmino objeto con todo aquello a lo que se puede atribuir la propiedad fsica de masa, como una tostadora de pan, aunque es posible encontrar objetos de ndole no tangible, como por ejemplo una direccin postal. En el mbito de la informtica, un objeto define una representacin abstracta de las entidades del mundo, tangibles o no, con la intencin de emularlas. Existe pues, una relacin directa entre los objetos del mundo y los objetos informticos, de modo que puede emplearse el trmino objeto de manera indistinta. Los objetos tienen dos caractersticas, que son su estado y su comportamiento. El estado es una situacin en la que se encuentra el objeto, tal que cumple con alguna condicin o condiciones particulares, realiza alguna actividad o espera que suceda un acontecimiento. Una tostadora puede estar encendida y cargada de pan y, en cuanto a su comportamiento, lo normal en este estado es tostar pan. Los objetos mantienen su estado en uno o ms atributos, que son simplemente datos identificados por un nombre, y exhiben su comportamiento a travs de mtodos, que son trozos de funcionalidad asociados al objeto. En este sentido, un objeto es realmente un conjunto de atributos y mtodos. Pero un objeto slo revela su verdadera utilidad cuando es integrado en un contexto de comunicacin con otros objetos, a travs del envo de mensajes, para componer un sistema mucho mayor y demostrar un comportamiento ms complejo. Una tostadora en un armario resulta de poca utilidad, pero cuando interacta con otro objeto, como un ser humano, se convierte en una herramienta til para tostar pan. El humano intercambiara con la tostadora el mensaje tuesta el pan que tienes en la bandeja a travs de la pulsacin del botn de tostar. A partir del ejemplo anterior, es fcil deducir que el envo de mensajes es la forma en que se invocan los mtodos de un objeto y que la invocacin de mtodos es el mecanismo a travs del cual un objeto puede cambiar su estado o el de otro objeto. Los atributos y los mtodos de un objeto pueden tener un menor o mayor grado de visibilidad, desde privado hasta pblico, lo que hace que aparezca un concepto nuevo, la encapsulacin. La encapsulacin oculta los detalles del funcionamiento interno del objeto, exponiendo slo aquello que pueda ser de inters. Es as como un objeto representa un evento, lugar, cosa o persona. Por ejemplo, un automvil BMW 2000 como nmero de serie #78348227RDGF y tipo de motor 6 cilindros es un objeto con atributos (modelo, nmero de serie, tipo de motor) y comportamiento (encendido, apagado, etc).
Clase
Los objetos no son entidades que existan de modo nico. Hay muchos tipos de tostadoras e, igualmente, muchas tostadoras del mismo tipo. Se puede entender fcilmente el concepto de clase si nos permitimos emplear el trmino tipo como equivalente. As, todos los objetos que son del mismo tipo, comparten el mismo juego de atributos y mtodos (aunque cada objeto pueda tener un valor distinto asociado a cada atributo) y por tanto pertenecen a una misma clase. Las clases son como patrones que definen qu atributos y qu mtodos son comunes a todos los objetos de un mismo tipo. Cada objeto tiene sus atributos y su comportamiento, creados empleando una clase a modo de patrn. Una vez creado el objeto, pasa a ser una instancia particular de la clase a la que pertenece
10
y sus atributos tienen unos valores concretos, que podrn variar de un objeto a otro (dos objetos distintos pertenecientes a la misma clase, pueden tener exactamente los mismos valores en todos sus atributos). A estos atributos, que pueden variar de un objeto a otro, se les conoce tambin como variables de instancia. Hay atributos que, sin embargo, no varan de un objeto a otro, es decir todas las instancias de la clase a la que pertenecen, tienen el mismo valor para ese atributo. Todas las tostadoras del mismo tipo consumen los mismos Watios y sus resistencias son de los mismos Ohmios. A estos atributos se les conoce como variables de clase y son compartidos por todas y cada una de las instancias de la clase. De manera anloga al caso de los atributos, encontramos mtodos de instancia y mtodos de clase. Es as como una CLASE es una categora de objetos con caractersticas similares. Por ejemplo, la clase para el BMW podr ser Automviles, dentro de esa clase poda muchos objetos con los mismos atributos y comportamientos.
Mensaje
Como se comento anteriormente estos sirven para enviar informacin de un objeto de una clase a otro de una clase distinta. Todos los mensajes son programaciones dentro de las clases. Por ejemplo, un objeto (Juan) de la clase Choferes enva el mensaje encender motor al objeto (BMW) de la clase Automviles. (Ver Figura No. 2) Clase Automviles Modelo Nmero de serie Tipo de motor Atributos Fig. No. 2 BMW 2000 #7834827RDGF 6 cilindros Objetos Mensajes Choferes Nombre Nm. de licen Fecha nac. Encender motor Juan Prez 762312798 21-02-1957
Interfaz
Una interfaz es un mecanismo que emplean dos objetos para interactuar. En nuestro ejemplo de la tostadora, el humano emplea el botn de tostar a modo de interfaz para pasar el mensaje tuesta el pan que tienes en la bandeja. Las interfaces definen un conjunto de mtodos para establecer el protocolo en base al cual interactan dos objetos. En este sentido, existe una analoga entre interfaces y protocolos. Para que el humano pueda tostar, debe seguir el protocolo establecido por la interfaz botn de tostar, consistente en pulsar dicho botn. Las interfaces capturan las similitudes entre clases no relacionaras, sin necesidad de forzar una interrelacin y son a su vez clases.
Encapsulacin
Como se comento anteriormente esto se refiere a la propiedad que tiene los objetos de mantener el control sobre su comportamiento. Es decir, cada objeto es como una caja negra que acta en funcin de las seales externas. Esto facilita el mantenimiento de los programas, ya que cualquier
11
cambio en la programacin de un objeto, no afectar a otros mientras acte consistentemente ante los mensajes recibidos. (Ver Figura No 3 debajo mostrada) Resultados Seal externa
Fig. No 3
Herencia
Los objetos se definen en funcin de clases, es decir, tomando una clase como patrn. Se puede saber mucho acerca de un objeto sabiendo la clase a la que pertenece. Por ejemplo, con decir que la Russell Hobbs 10243 Kudos es un tipo de tostadora, inmediatamente se sabe que se trata de una mquina para tostar pan, probablemente elctrica y con por lo menos una ranura en la que insertar una rebanada de pan y un botn para activar su funcionamiento. Las clases llegan un paso ms lejos, permitiendo su definicin en funcin de otras clases, de modo que es posible establecer una jerarqua de especializacin. Una clase que se define en funcin de otra, hereda todos los atributos y mtodos de aquella y permite el aadido de nuevos o la sobre escritura de los heredados. La clase patrn se conoce con el nombre de superclase o clase padre, mientas que la que hereda se conoce como clase hija. La herencia no est limitada simplemente a padre-hija(s), la jerarqua puede ser todo lo profunda que sea necesario, hablando en trminos de nietas, biznietas, etc. De la misma manera, una clase puede heredar de varias clases a la vez. En la siguiente figura No 4 se puede ver una jerarqua de especializacin de dos niveles. La clase Animal es la raz , la clase padre en la jerarqua. Especifica que los animales comen, como caracterstica ms significativa de stos. En el primer nivel de especializacin encontramos las clases Carnvoro y Herbvoro, ambas son sendos tipos de animal y por tanto comen, slo que en el caso de los carnvoros se ha especializado el tipo de comida que comen para indicar que se trata de carne. Aparece una nueva caracterstica de este tipo de animal, que es el hecho de que los carnvoros cazan. En el caso de los herbvoros, encontramos que comen plantas y pacen. En el segundo nivel de especializacin, encontramos un animal que es a la vez Herbvoro y Carnvoro y, como cabe esperar, este nuevo tipo de animal puede hacer todo lo que pueden hacer sus ancestros, comer carne, comer plantas, cazar y pacer, no encontrando ninguna caracterstica adicional en los Omnvoros.
Fig. No. 4 Es as como la herencia se refiere a la posibilidad de crear clases a partir de otras. La clase original o padre, se conoce como clase base, y a la clase hija se le llama clase derivada. La clase derivada puede heredar todos los atributos y comportamientos de la clase base para agregar nuevos segn su clase. (Ver la Figura No.5 mostrada debajo)
12
Automvil Modelo Nmero de serie Tipo de motor Camin (hereda Automviles) Modelo Nmero de serie Tipo de motor Capacidad de carga Refrigeracin
Fig. No 5
Polimorfismo
Como se comento anteriormente, es la posibilidad de tener comportamientos alternos entre clases derivadas, como si los hijos de una misma clase se comportaran de manera distinta entre s
13
Especificar la estructura y/o comportamiento de un sistema. Hacer una plantilla que gue la construccin de los sistemas Documentar las decisiones que hemos tomado
El modelado sirve no solamente para los grandes sistemas; an en aplicaciones de pequeo tamao se obtienen beneficios de modelar, sin embargo, es un hecho que entre ms grande y ms complejo es el sistema, el modelado juega un papel ms importante. Esto se debe a una razn simple. Hacemos modelos de sistemas complejos porque no podemos entenderlos en su totalidad. Estableciendo lmites para el entendimiento de la complejidad. Por consiguiente a travs del modelado reducimos el mbito del problema de estudio al enfocar solo un aspecto a la vez. Por ejemplo, en la siguiente figura No 6 se muestra un modelo (en UML) de la distribucin fsica de los mdulos de una aplicacin de facturacin en una arquitectura cliente servidor de 3 capas:
Fig. No 6
Nomenclatura:
Cada cubo representa una computadora. Las lneas que conectan cada cubo representan conexiones entre computadoras y el nombre de la conexin (entre << y >>) representa que tipo de enlace existe. Cada computadora tiene un nombre. Un asterisco representa que existen muchas iguales. Se pueden etiquetar aspectos relevantes de cada computadora, como el sistema operativo que tienen cargado. Entre los mdulos cargados en distintas computadoras pueden existir relaciones, como el de invocacin (llamado a ejecucin). El interior de cada cubo representa mdulos de software cargados en cada computadora. Es de notarse el enorme poder de expresin que tiene este diagrama: Nos dice que el sistema tendr tres distintos mdulos de aplicacin: Soporte Ventas, Soporte Supervisor y Cierres. Habr tres distintos tipos de configuraciones de mquinas ligadas al tipo de usuario que las usar. De cada tipo de mquina existirn diversos ejemplares (esto puede ser porque cada vendedor tenga su propia mquina, al igual que un supervisor o un operador de cierres).Las mquinas clientes corren bajo Windows 95 y estn conectados a un servidor de aplicacionesa travs de una red Novell (con protocolo IPX). El servidor de aplicacin correr bajo Netware y a su vez estar conectado con un servidor de datos va TCP/IP. El servidor de datos corre bajo UNIX y tiene un manejador de base de datos SYBASE. Los mdulos de la aplicacin extraen datos va un administrador de reglas (un monitor transaccional como Tuxedo, por ejemplo).
14
Este modelo combina 2 tipos de diagramas de UML: Diagramas de distribucin y Diagramas de paquetes y es una pequea muestra del poder de expresin de UML.
En qu consiste UML?
UML consiste de:
Reglas de simbologa que aplican a cualquier tipo de modelo hecho bajo este lenguaje, por
ejemplo, el modo en que se coloca un comentario en cualquier diagrama o el modo en que se aumenta la nomenclatura existente en UML.
UML Metodologa?
Parte de las premisas en el desarrollo de UML fue que se deseaba separar los modelos de una metodologa dada. En este marco se entiende como metodologa un conjunto de pasos ordenados con entradas y salidas previamente definidas (estas entradas y salidas bien pueden ser modelos expresados en UML u otra notacin). UML es independiente de metodologas, por lo que puede ser usada (y lo es) en distintas metodologas como Fusion, Objectory, Rational Unified Process, OMT, ECM, Catalysys, etc. La independencia antes mencionada permite que las organizaciones adapten el uso de UML a la metodologa que consideren ms apropiada. UML es un lenguaje para hacer modelos.
15
Mejor calidad. El uso de UML hace indispensable la participacin del usuario en la definicin
de requerimientos y por lo tanto mejora considerablemente el apego del sistema a las necesidades de sus usuarios. El mantenimiento correctivo se reduce drsticamente (hasta un 80% con respecto a un sistema hecho sin metodologa). Algo similar ocurre en los proyectos de reingeniera.
Alto reuso. Los productos de un desarrollo pueden ser usados en otro. Se pueden crear
componentes reusables que con la difusin y administracin adecuadas minimizarn costos y errores.
Minimizacin de costos. Los puntos antes mencionados tienen un impacto econmico que
generalmente tiende a ser proporcional al tamao de la organizacin.
Consultora para la Planeacin. Cuando las reas involucradas son muchas, el impacto de la
introduccin de esta tecnologa requerir una planeacin adecuada, este proceso debe ser hecho por la organizacin y apoyado por un equipo con experiencia en la administracin de este cambio.
Capacitacin. Las tcnicas involucradas pueden ser aprendidas directamente de los libros y
manuales de UML, sin embargo el tiempo necesario puede ser prohibitivo. Un servicio de capacitacin de alta calidad generar la cultura bsica para el ptimo aprovechamiento de la tecnologa. Capacitacin en UML, Anlisis y Diseo de aplicaciones es sugerida.
Control de Calidad. Una vez que un equipo ya ha aprendido el uso de UML es sano contar
con un staff de control de calidad externo (y experto) que certifique la calidad de los productos y genere gente con ste perfil hacia el interior de la organizacin. Este servicio tambin puede ser til para controlar la calidad de los desarrollos efectuados por empresas externas.
16
17
Clase
Describe un conjunto de objetos que comparten los mismos atributos, mtodos, relaciones y semntica. Las clases implementan una o ms interfaces.
Se trata de una clase, en la que existen procesos o hilos de ejecucin concurrentes con otros elementos. Las lneas del contorno son ms gruesas que en la clase normal
Agrupacin de mtodos u operaciones que especifican un servicio de una clase o componente, describiendo su comportamiento, completo o parcial, externamente visible. UML permite emplear un crculo para representar las interfaces, aunque lo ms normal es emplear la clase con el nombre en cursiva. Define una interaccin entre elementos que cooperan para proporcionar un comportamiento mayor que la suma de los comportamientos de sus elementos.
Colaboracin
Caso de uso
Describe un conjunto de secuencias de acciones que un sistema ejecuta, para producir un resultado observable de inters. Se emplea para estructurar los aspectos de comportamiento de un modelo.
Componente
Parte fsica y por tanto reemplazable de un modelo, que agrupa un conjunto de interfaces, archivos de cdigo fuente, clases, colaboraciones y proporciona la implementacin de dichos elementos.
Nodo
Elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional con capacidad de procesar.
Interaccin
Comprende un conjunto de mensajes que se intercambian entre un conjunto de objetos, para cumplir un objetivo especifico. Especifica la secuencia de estados por los que pasa un objeto o una interaccin, en respuesta a eventos. Se emplea para organizar otros elementos en grupos.
Elementos de agrupacin
18
Elementos de notacin
Nota
Partes explicativa de UML, que puede describir textualmente cualquier aspecto del modelo
Dependencia
Asociacin
Es una relacin estructural que resume un conjunto de enlaces que son conexiones entre objetos.
Generalizacin
Es una relacin en la que el elemento generalizado puede ser substituido por cualquiera de los elementos hijos, ya que comparten su estructura y comportamiento.
Realizacin
Es una relacin que implica que la parte realizante cumple con una serie de especificaciones propuestas por la clase realizada (interfaces).
Objetos Componentes
Anlogo al diagrama de clases, muestra un conjunto de objetos y sus relaciones, pero a modo de vista instantnea de instancias de una clase en el tiempo. Muestra la organizacin y dependencias de un conjunto de componentes. Cubren la vista de implementacin esttica de un sistema. Un componente es un mdulo de cdigo, de modo que los diagramas de componentes son los anlogos fsicos a los diagramas de clases. Muestra la configuracin del hardware del sistema, los nodos de proceso y los componentes empleados por stos. Cubren la vista de despliegue esttica de una arquitectura.
Modelan Estructur a
Despliegue
19
Casos de Uso
Muestra un conjunto de casos de uso, los actores implicados y sus relaciones. Son diagramas fundamentales en el modelado y organizacin del sistema.
M O D E L A N
Secuencia
C O M P O R T A M I E N T O
Colaboracin
Son diagramas de interaccin, muestran un conjunto de objetos y sus relaciones, as como los mensajes que se intercambian entre ellos. Cubren la vista dinmica del sistema. El diagrama de secuencia resalta la ordenacin temporal de los mensajes, mientras que el de colaboracin resalta la organizacin estructural de los objetos, ambos siendo equivalentes o isomorfos. En el diagrama de colaboracin de la figura de la izquierda, se puede ver que los elementos grficos no son cajas rectangulares, como cabra esperar, y en su lugar encontramos sus versiones adornadas. Estas versiones tienen como finalidad evidenciar un rol especfico del objeto siendo modelado. En la figura encontramos de izquierda a derecha y de arriba abajo un Actor, una Interfaz, un Control (modela un comportamiento) y una Instancia (modela un objeto de dato).
Estados
Muestra una mquina de estados, con sus estados, transiciones, eventos y actividades. Cubren la vista dinmica de un sistema. Modelan comportamientos reactivos en base a eventos.
Tipo especial de diagrama de estados que muestra el flujo de actividades dentro de un sistema. Actividades
20
En cuanto a las asociaciones, observamos que algunas vienen representadas como una flecha navegable, cuya orientacin expresa el sentido en que se consultan los datos. Las asociaciones sin flecha son bi-direccionales. Las agregaciones expresan conjunto de; la relacin entre Pedido y Articulo es de conjunto. Un pedido es una agregacin de una o ms lneas de pedido, donde cada una hace alusin a un artculo concreto, as mismo una lnea de pedido puede estar presente en varios pedidos y un artculo puede no haber sido solicitado nunca.
Figura 7: Diagrama de Clases En cuanto a la multiplicidad, la siguiente tabla resume las ms comunes. Hay que tener en cuenta que la multiplicidad se expresa en el lado opuesto de la relacin y es el nmero de posibles instancias de una clase asociadas con una nica instancia de la clase en el otro extremo. Multiplicidad 1 N/* 0..N / 0..* 1..N / 1..* 0..1 N..M Significado Una nica instancia N instancias Entre ninguna y N instancias Entre una y N instancias Ninguna o una instancia Entre N y M instancias
Tabla 1: Multiplicidad en Diagramas de Clases El siguiente diagrama muestra una dependencia existente entre las clases Pedido y Fecha. Cualquier cambio en la clase dependida, Fecha, afectar la clase dependiente, Pedida. As mismo se puede observar que las clases vienen representadas por cajas en las que hay tres separaciones, o compartimentos. El primero se emplea siempre para indicar el nombre de la clase,
21
el segundo para mostrar los atributos y el tercero para los mtodos. Tanto los atributos como los mtodos vienen precedidos por un smbolo de acceso, que normalmente suele ser un + para el acceso pblico, un - para el acceso privado, (slo por otros mtodos de la clase) y un # para el acceso protegido (slo por clases hija), aunque la herramienta empleada en la elaboracin del tutorial traduce estos elementos en iconos. Los atributos tienen un tipo que puede mostrarse a continuacin de su nombre separado por :. De igual manera, los mtodos pueden devolver un elemento de un tipo determinado y recibir parmetros, expresados entre parntesis mediante el nombre del parmetro y el tipo, separados por :. Para el caso de mltiples parmetros, se separan por comas (p1:t1, p2:t2 ... pn:tn). Los parmetros que tienen un valor por defecto se expresan mediante un = y el valor, a continuacin del tipo (p1:t1=v1) y si un parmetro en la posicin i de la lista de parmetros tiene valor por defecto, todos los parmetros que le sigan, es decir que ocupen posiciones sucesivas a i en la lista, debern tener tambin un valor por defecto. Los atributos y mtodos estticos (de clase) se representan mediante un subrayado (en el caso de los mtodos se puede emplear el estereotipo <<static>>, los estereotipos se ven ms adelante).
Figura 8: Relacin de dependencia en Diagramas de Clase El siguiente diagrama muestra una auto-relacin de agregacin. Un Departamento puede estar compuesto a su vez por ms sub-departamentos, o ninguno, con la restriccin de que el mnimo nmero de personas en los sub-departamentos debe ser dos. Las restricciones son condiciones que deben ser cumplidas siempre, se expresan entre llaves {condicin }.
Figura 9: Auto-agregacin Los diagramas de objetos son anlogos a los de clases, con la particularidad de que en lugar de encontrar clases, encontramos instancias de stas. Son tiles para explicar partes pequeas del modelo en las que hay relaciones complejas. (Ver Diagrama de Objetos)
22
Dependencias.
Es una relacin de uso, es decir una clase usa a otra, que la necesita para su cometido. Se representa con una flecha discontinua va desde la clase utilizadora a la clase utilizada. Con la dependencia mostramos que un cambio en la clase utilizada puede afectar al funcionamiento de la clase utilizadora, pero no al contrario. Aunque las dependencias se pueden crear tal cual, es decir sin ningn estereotipo (palabreja que aparece al lado de la lnea que representa la dependencia) UML permite dar mas significado a las dependencias, es decir concretar mas, mediante el uso de estereotipos. Estereotipos de relacin Clase-objeto. Bind: La clase utilizada es una plantilla, y necesita de parmetros para ser utilizada, con Bind se indica que la clase se instancia con los parmetros pasndole datos reales para sus parmetros. Derive: Se utiliza al indicar relaciones entre dos atributos, indica que el valor de un atributo depende directamente del valor de otro. Es decir el atributo edad depende directamente del atributo Fecha nacimiento. Friend: Especifica una visibilidad especial sobre la clase relacionada. Es decir podr ver las interioridades de la clase destino. InstanceOF: Indica que el objeto origen es una instancia del destino. Instantiate: indica que el origen crea instancias del destino. Powertype: indica que el destino es un contenedor de objetos del origen, o de sus hijos. Refine: se utiliza para indicar que una clase es la misma que otra, pero ms refinada, es decir dos vistas de la misma clase, la destino con mayor detalle.
Generalizacin.
Pues es la herencia, donde tenemos una o varias clases padre o superclase o madre, y una clase hija o subclase. UML soporta tanto herencia simple como herencia mltiple. Aunque la representacin comn es suficiente en el 99.73% de los casos UML nos permite modificar la relacin de Generalizacin con un estereotipo y dos restricciones. Estereotipo de generalizacin. Implementation: El hijo hereda la implementacin del padre, sin publicar ni soportar sus interfaces.
Restricciones de generalizacin. Complete: La generalizacin ya no permite mas hijos. Incomplete: Podemos incorporar mas hijos a la generalizacin. Disjoint: solo puede tener un tipo en tiempo de ejecucin, una instancia del padre solo podr ser de un tipo de hijo. Overlapping: puede cambiar de tipo durante su vida, una instancia del padre puede ir cambiando de tipo entre los de sus hijos.
Asociacin.
Especifica que los objetos de una clase estn relacionados con los elementos de otra clase. Se representa mediante una lnea continua, que une las dos clases. Podemos indicar el nombre, multiplicidad en los extremos, su rol, y agregacin.
Ejemplo. En la Fig. No. 10 el diagrama se han creado cuatro clases. La clase principal es Usuario, que tiene dos clases hijas UsuarioADM y UsuarioINF. El usuario mantiene una relacin de asociacin con la clase Clave, se indica que es propietario de una clave, o de un nmero indeterminado de ellas. Se
23
le crea tambin una relacin de dependencia con la clase Perfil (Fichero), es decir las instancias de usuario contendrn como miembro una instancia de Perfil (Fichero).
Clave
UsuarioADM
UsuarioINF
Fig. No 10
Agregacin:
Para modelar objetos complejos, n bastan los tipos de datos bsicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicacin, tenemos dos posibilidades: Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relacin es comnmente llamada Composicin (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo"). Por Referencia: Es un tipo de relacin dinmica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relacin es comnmente llamada Agregacin (el objeto base utiliza al incluido para su funcionamiento).
Un Ejemplo es el siguiente:
Fig. No.11
En donde se destaca que: Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).
24
Cuando se destruye el Objeto Almacn tambin son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados. La composicin (por Valor) se destaca por un rombo relleno. La agregacin (por Referencia) se destaca por un rombo transparente.
La flecha en este tipo de relacin indica la navegabilidad del objeto referenciado. Cuando no existe este tipo de particularidad la flecha se elimina.
Diagrama de objetos
Forma parte de la vista esttica del sistema. En este diagrama se modelan las instancias de las clases del diagrama de clases. Muestra a los objetos y sus relaciones, pero en un momento concreto del sistema. Estos diagramas contienen objetos y enlaces. En los diagramas de objetos tambin se pueden incorporar clases, para mostrar la clase de la que es un objeto representado. En este diagrama se muestra un estado del diagrama de eventos. Para realizar el diagrama de objetos primero se debe decidir que situacin queremos representar del sistema. Es decir si disponemos de un sistema de mensajera, deberemos decidir que representaremos el sistema con dos mensajes entrantes, los dos para diferentes departamentos, dejando un departamento inactivo. Para el siguiente diagrama de clases (Fig. No. 12): Existe un diagrama de objetos con dos instancias de Mensaje, mas concretamente con una instancia de MensajeDIR y otra de MensajeADM, con todos sus atributos valorados. Tambin tendramos una instancia de cada una de las otras clases que deban tener instancia. Como CanalEnt, INS, Distr, y el Buzon correspondiente a la instancia de mensaje que se este instanciando. En la instancia de la clase INS se deber mostrar en su miembro Estado, que esta ocupado realizando una insercin. En un diseo no podemos encontrar con multitud de diagramas de objetos, cada uno de ellos representando diferentes estados del sistema.
D istr C n lE t aa n R cib M n je e e e sa () C a e sa () re M n je +C a re
IN S E d sta o In rta se () B zo u n
M n je IR e sa D M n je D e sa A M
M n je F e sa IN
B zo IN u n F
B zo I F u nN
B zo IN u n F
25
Fig. No. 12
Diagrama de Componentes
Los componentes son mdulos de cdigo, as que los diagramas de componentes vienen a ser los anlogos fsicos a los diagramas de clases. Muestran como est organizado un conjunto de componentes y las dependencias que existen entre ellos. (Ver Fig. No. 13)
Estos diagramas se utilizan para modelar la vista esttica de un sistema. Muestra la organizacin y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema. En el situaremos libreras, tablas archivos, ejecutables y documentos que formen parte del sistema. Uno de los usos principales es que puede servir para ver que componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.
User32.dll
Fig. No. 14 Componente Windows En la figura anterior (Fig. No. 14) se tiene un componente del sistema de Windows. En el diagrama de componentes de Windows debe salir este componente, ya que sin el sistema no funcionara.
User32.dll
26
En la Fig. No. 15 tenemos el mismo componente, pero indicamos que dispone de un interface. Al ser una Dll el interface nos da acceso a su contenido. Esto nos hace pensar que la representacin anterior es incorrecta, pero no es as solo corresponde a un nivel diferente de detalle. Como ya hemos indicado antes todo objeto UML puede ser modificado mediante estereotipos, los standards que define UML son: Executable Library Table File Document.
Aunque por suerte no estamos limitados a estas especificaciones. Que pasa si queremos modelar un proyecto de Internet donde nuestros componentes son ASP, HTML, y Scripts, y queremos marcarlo en el modelo. Pues utilizamos un estereotipo. Existen ya unos definidos WAE (Web Applications Extensin). Podemos modelar diferentes partes de nuestro sistema, y modelar diferentes entidades que no tiene nada que ver entre ellas. Ejecutables y bibliotecas. Tablas. API Cdigo fuente. Hojas HTML.
Ejecutables. El diagrama de componente nos facilita la distribucin de ejecutables a los clientes. Documenta sus necesidades y dependencias. Si disponemos de un ejecutable que solo se necesita al mismo para funcionar no necesitaremos el diagrama de componentes. Los pasos a seguir para modelar, a priori no a posteriori, son: Identificar los componentes, las particiones del sistema, cuales son factibles de ser reutilizadas. Agruparlos por nodos y realizar un diagrama por cada nodo que se quiera modelar. Identificar cada componente con su estereotipo correspondiente. Considerar las relaciones entre componentes.
Fig. No. 16 Ejemplo de Diagrama de Componentes con elementos ejecutables En la Fig. No. 16 se muestra un ejecutable que utiliza dos libreras, estas dos libreras disponen de su interface con el que ofrecen el acceso a sus servicios. Se puede ver que estas libreras son componentes que pueden ser reutilizados en otras partes del sistema.
27
Cdigo fuente.
El diagrama de componente tambin se utiliza para documentar las dependencias de los diferentes archivos de cdigo fuente. Un ejecutable, o librera es una combinacin de estos archivos, y al mostrar la dependencia entre ellos obtenemos una visin de las partes necesarias para la creacin del ejecutable o librera. Al tener documentadas las relaciones se pueden realizar cambios en el cdigo de un archivo teniendo en cuenta donde se utiliza, y que otros archivos pueden verse afectados por su modificacin.
Fig. No.17 Ejemplo de Diagrama de Componentes con archivos de cdigo fuente En la Fig.No. 17 se tiene la relacin entre los diferentes archivos de un sistema. Cada archivo Cpp utiliza su archivo .h correspondiente, y MiServicio.h utiliza NTService.h u Stdio.h.
Diagramas de despliegue
En el diagrama de despliegue se indica la situacin fsica de los componentes lgicos desarrollados. Es decir se sita el software en el hardware que lo contiene. Cada Hardware se representa como un nodo. (Ver Fig. No. 18)
28
Fig. No. 18 Diagrama de Despliegue Un nodo se representa como un cubo, un nodo es un elemento donde se ejecutan los componentes, representan el despliegue fsico de estos componentes. En la Fig. No. 18 se tienen dos nodos, el cliente y el servidor, cada uno de ellos contiene componentes. El componente del cliente utiliza un interface de uno de los componentes del servidor. Se muestra la relacin existente entre los dos Nodos. Esta relacin podramos asociarle un estereotipo para indicar que tipo de conexin disponemos entre el cliente y el servidor, as como modificar su cardinalidad, para indicar que soportamos diversos clientes. Cuando los componentes pueden residir en mas de un nodo podemos situar el componente de forma independiente, sin que pertenezca a ningn nodo, y relacionarlo con los nodos en los que se sita. (Ver Fig. No. 19)
Fig. No. 19 Diagrama de Despliegue con componentes Independientes Los diagramas de despliegue sirven para modelar la configuracin hardware con su software del sistema, mostrando qu nodos lo componen. (Ver Fig. No 20)
29
Fig. No. 21 Diagrama de Casos de Uso nivel 1 En los Casos de Uso, los Actores son papeles que determinadas personas u objetos desempean. Se representan mediante un hombre de palitos, de modo que en el ejemplo, Carlos es un Actor. Los Casos de Uso se representan por medio de valos y las lneas que unen Actores con Casos de Uso representan una asociacin de comunicacin. Por su puesto, un Caso de Uso puede ser descrito en mayor profundidad. Por ejemplo si tomamos por separado Preparar pan y Preparar cafe, podemos bajar un nivel de descripcin y llegar a los siguientes Casos de Uso. (Ver Fig. No. 22 y No. 23)
30
Fig. No. 22: Diagrama Casos de Uso nivel 2 A Carlos tuesta el pan en la tostadora, despus lo unta con mantequilla y mermelada de fresa y se lo come, posiblemente mojndolo en un caf.
Fig. No. 23: Diagrama Casos de Uso nivel 2 B Carlos calienta leche, aade caf y azcar al gusto y se lo bebe. Los Casos de Uso suelen venir delimitados por fronteras o lmites, que definen una separacin entre lo que es realmente la funcionalidad del sistema y los actores que la usan o colaboran en su desempeo. En las figuras, esta separacin viene representada por medio de la caja que encapsula los valos. Los Casos de Uso son acompaados por una explicacin textual que clarifica las posibles cadencias del lenguaje meramente grfico. De esta manera, combinando Casos de Uso y explicacin textual, se puede obtener escenarios no ambiguos, que resultan ideales en la captura de requisitos de usuario, dada su sencillez de comprensin incluso por quien no est familiarizado con UML. Los Casos de Uso se emplean tambin en la preparacin de escenarios de pruebas con que verificar el software una vez ha sido construido. El siguiente Caso de Uso (Fig. No. 24) es equivalente al primero, Desayuno, slo que en l se ha condensado la mxima cantidad posible de informacin. En l se muestra un nuevo elemento que hasta ahora no se haba mostrado, el estereotipo, que viene entre sendos smbolos angulados << y >> y concreta un paso ms all el tipo de relacin existente entre dos Casos de Uso. Encontramos dos estereotipos <<include>> (Requiere) y <<extend>> (Variacin) . El primero indica que el Caso de Uso Tostar pan requiere de Usar tostadora para poder ser llevado a cabo. Esta es una forma muy adecuada de sacar factor comn entre Casos de Uso, o incluso de fraccionar Casos de Uso muy grandes. El segundo indica que el Caso de Uso Untar pan es una variacin de Untar. Observamos tambin que Comer pan y Beber cafe son una generalizacin de Alimentarse.
31
Fig. No. 24: Diagrama Casos de Uso nivel 1 detallado Carlos va a desayunar. Para ello debe hacer dos actividades distintas, pero relacionadas. La primera consiste en tostar pan, para lo cual necesita emplear una tostadora. Una vez tostado el pan, lo unta de mantequilla y mermelada de fresa (untar pan no es muy distinto de untar otro tipo de alimentos). La segunda consiste en preparar el caf, par lo cual necesita calentar leche y aadir caf y azuzar. Terminadas ambas actividades, Carlos puede proceder a alimentarse, comiendo el pan tostado y bebiendo el caf. El orden en que realice las actividades da igual y tambin da igual si se realizan a la vez.
Figura 25: Diagrama de Secuencia Las lneas verticales o lneas de la vida representan el tiempo de vida del objeto. La vida del objeto carlos no termina en este diagrama, sin embargo la del objeto tosty s y esto viene representado mediante el aspa al final de su lnea de la vida.
32
Los rectngulos verticales son barras de activacin y representan la duracin de la ejecucin del mensaje. El mensaje Encender, posiblemente implementado mediante la introduccin del enchufe en una toma de pared, tiene una duracin escasa y similar a la de Apagar. No ocurre lo mismo con la llamada al mtodo tostar(), que dura desde la pulsacin del botn de tostar hasta que el pan es retirado de la bandeja y adems interviene la emisin de un aviso cuando el pan est lo suficientemente caliente, a fin de evitar que se queme. Como se puede observar, la accin tostar viene condicionada por la presencia de pan en la bandeja de la tostadora. En UML los corchetes [] expresan condicin y si estn precedidos de un asterisco indican interaccin mientras se cumpla la condicin. Los mensajes que son intercambiados entre los objetos de un diagrama de secuencia pueden ser sncronos o asncronos. Los mensajes asncronos son aquellos tal que el emisor puede enviar nuevos mensajes mientras el original est siendo procesado. El mensaje asncrono ocurre en el tiempo de manera independiente a otros mensajes. Los mensajes sncronos son todo lo contrario, el emisor debe esperar a que termine el tiempo de proceso del mensaje antes de que pueda emitir nuevos mensajes. UML emplea los siguientes convenios para representar el tipo de mensaje. Smbolo Significado Mensaje simple que puede ser sncrono o asncrono. Mensaje simple de vuelta (Opcional). Mensaje sncrono.
Mensaje asncrono.
Tabla de Tipos de mensaje en diagramas de interaccin Los diagramas de colaboracin son otro tipo de diagramas de interaccin, que contiene la misma informacin que los de secuencia, slo que se centran en las responsabilidades de cada objeto, en lugar de en el tiempo en que los mensajes son enviados. Cada mensaje de un diagrama de colaboracin tiene un nmero de secuencia. El primer nivel de la secuencia es 1, y los mensajes que son enviados durante la misma llamada a un mtodo se numeran 1.1, 1.2 y as sucesivamente para tantos niveles como sea necesario.
33
34
Los diagramas de actividades son bsicamente diagramas de flujo adornados, que guardan mucha similitud con los diagramas de estados. Mientras que los diagramas de estados centran su atencin en el proceso que est llevando a cabo un objeto, los diagramas de actividades muestran como las actividades fluyen y las dependencias entre ellas. Los diagramas de actividades pueden dividirse en calles que determinan qu objeto es responsable de qu actividad. Las actividades vienen unidas por transiciones, que pueden separarse en ramas en funcin del resultado de una condicin expresada entre corchetes. Cada rama muestra la condicin que debe ser satisfecha para que el flujo opte por ese camino. Igualmente, las transiciones se pueden bifurcarse en dos o ms actividades paralelas.
35
36
Un proceso incremental es aqul que consiste en sucesivas ampliaciones y mejoras de la arquitectura, a partir de una lnea bsica. Cada incremento resuelve los problemas encontrados en la versin anterior minimizando incrementalmente los riesgos ms significativos para el xito del proyecto. Lo primero que se debe hacer para comenzar a desarrollar un proyecto con UML, es seleccionar una metodologa de desarrollo que defina la naturaleza concreta del proceso a seguir. El modelo a definir en base al proceso elegido, se divide en realidad en varios tipos de modelo o vistas, cada una centrada en un aspecto o punto de vista del sistema. En general, independientemente del proceso que se emplee, se puede encontrar las siguientes vistas: Vista de Casos de Uso: Engloba los Casos de Uso que describen el comportamiento del sistema como lo veran los usuarios finales, los analistas y dems componentes del equipo de desarrollo. No especifica la organizacin del sistema. Con UML los aspectos estticos de esta vista se pueden concretar con los diagramas de Casos de Uso; los aspectos dinmicos con los diagramas de iteracin (secuencia y colaboracin), diagramas de estados y de actividades. Vista de Diseo: Engloba las clases e interfaces que conforman el vocabulario del problema y su solucin. Da soporte a los requisitos funcionales del sistema, es decir los servicios que proporciona a los usuarios finales. Con UML los aspectos estticos de esta vista se pueden concretar con los diagramas de clases y de objetos; los aspectos dinmicos con los diagramas de iteracin (secuencia y colaboracin), diagramas de estados y de actividades. Vista de Procesos: Engloba los hilos y procesos que forman los mecanismos de sincronizacin y concurrencia del sistema. Da soporte al funcionamiento, capacidad de crecimiento y rendimiento del sistema. Con UML los aspectos estticos de esta vista se pueden concretar con los diagramas de clases, de clases activas y de objetos; los aspectos dinmicos con los diagramas de iteracin (secuencia y colaboracin), diagramas de estados y de actividades. Vista de Despliegue: Engloba los nodos que forman la topologa hardware sobre el que se ejecuta el sistema. Da soporte a la distribucin, entrega e instalacin de las partes que conforman el sistema fsico. Con UML los aspectos estticos de esta vista se pueden concretar con los diagramas despliegue; los aspectos dinmicos con los diagramas de iteracin (secuencia y colaboracin), diagramas de estados y de actividades. Vista de Implementacin: Engloba los componentes y archivos empleados para hacer posible el sistema fsico. Da soporte a la gestin de configuraciones de las distintas versiones del sistema, a partir de componentes y archivos. Con UML los aspectos estticos de esta vista se pueden concretar con los diagramas de componentes; los aspectos dinmicos con los diagramas de iteracin (secuencia y colaboracin), diagramas de estados y de actividades.
Un ejemplo de proceso para la construccin de un programa, podra ser similar al siguiente, teniendo en cuenta que el proceso descrito deja muchas cosas por ampliar y puede no adaptarse a las necesidades particulares de un grupo de trabajo determinado. Se proporciona meramente como un ejemplo de cmo se puede encajar UML como soporte para el desarrollo de un proyecto: 1. Iniciar y mantener reuniones con los usuarios finales del programa, para comprender sus necesidades, el contexto en que lo usarn y todos los detalles necesarios para comprender el mbito del problema a resolver. Esta informacin ser empleada para capturar las
37
actividades y procesos involucrados y susceptibles de ser incorporados en el programa, a un nivel alto, y proporcionar la base para construir la vista de Casos de Uso. 2. Construir la vista de Casos de Uso definiendo exactamente la funcionalidad que se va a incorporar en el programa, desde el punto de vista de sus usuarios. El modelo resultante es realmente un mapeo de la informacin obtenida en el paso anterior, en el que cada nuevo Caso de Uso realiza un aspecto de la funcionalidad planteada. Refinar, en conjunto con los usuarios finales, todos los diagramas de Casos de Uso, incluyendo requisitos y restricciones, para llegar a un acuerdo comn en lo que el programa har y no har. En este punto puede ser conveniente disear escenarios de prueba que ayuden a verificar si el programa finalizado cumple con las expectativas del contrato. Partiendo del modelo de Casos de Uso se comienza a estructurar los requisitos en una arquitectura llamada lnea base. Se definen clases y relaciones entre ellas, los primeros diagramas de secuencia y colaboracin, definiendo los comportamientos de cada clase, tambin las interfaces entre los diferentes elementos de la arquitectura. Se construye aqu la vista de diseo y la vista de procesos. Construir diagramas de clases ms elaborados y refinar los comportamientos del sistema. A medida que crece el modelo se puede fraccionar en componentes software y paquetes. Aparecen nuevos requisitos que deben ser integrados. Se define la vista de despliegue, que define la arquitectura fsica del sistema, y la vista de implementacin.
3.
4.
5. Construir el sistema, repartiendo las tareas entre el equipo de programacin. 6. Buscar errores de programacin, o incluso de diseo, corregirlos e ir sacando sucesivas versiones del programa hasta llegar a una versin que cumpla con todos los requisitos especificados en el contrato con los usuarios. 7. Documentar y entregar el programa a los usuarios finales.
38
Referencias Schneider G., Winters J.P., (2001) Applying Use Cases: A Practical Guide, Addison Wesley. Booch G. et al. El lenguaje unificado de modelado, Addison-Wesley, 1999. UML version 1.4. Object Management Group. Septiembre 2001. http://www.omg.org/technology/documents/formal/uml.htm Rational Inc. UML Resource Center. http://www.rational.com/uml Bernd Bruegge, Allen H. Dutoit (2001) Ingeniera de Software Orientado a Objeto. Prentice Hall Booch G., Rumbaugh J., Jacobson I. El Lenguaje Unificado de Modelado, Addison-Wesley, Madrid, 1999. Jacobson I., Booch G., Rumbaugh J. El Proceso Unificado de Desarrollo de Software, AddisonWesley, Madrid, 2000. Pressman R.S. Ingeniera del Software. Un enfoque prctico (5 ed.) Mc Graw-Hill; New York , 2001. Rumbaugh J., Jacobson I., Booch G. El Lenguaje Unificado de Modelado. Manual de Referencia, Addison-Wesley, Madrid, 2000. Sommerville I. Ingeniera de software, 6 edicin, Prentice Hall Pearson educacin, Mxico, 2002. Stevens P., Pooley R. Utilizacin de UML en Ingeniera del Software con Objetos y Componentes, Addison-Wesley, Madrid, 2002. http://www.omg.org http://www.uml.org Lewis 1994 Cota 1994 Boehm,B. 1997 Lewis G. 1994. "What is Software Engineering?" DataPro (4015). Feb 1994. pp. 1-10. Cota A. 1994 "Ingeniera de Software". Soluciones Avanzadas. Julio de 1994. pp. 5-13. "lmproving Sofware Productivity", IEEE Computers, Septiembre 1987.
39
UML METODOLOGA ? ...............................................................................................................................................15 BENEFICIOS DE ESTA TECNOLOGA..................................................................................................................................15 SERVICIOS NECESARIOS PARA IMPLANTAR ESTA TECNOLOGA . ............................................................................................16 BLOQUES BSICOS DE CONSTRUCCIN DE UML...............................................................................................................17 Elementos del UML (Unidades bsicas de construccin)............................................................................17 Relaciones (Unin entre los distintos elementos).........................................................................................19 Diagramas (Disposicin de un conjunto de elementos, que representan el sistema modelado desde diferentes perspectivas)....................................................19
Diagrama de Clases y Diagrama de Objetos................................................................................................................... 20 Relaciones entre clases ..................................................................................................................................................... 22 Dependencias. .............................................................................................................................................................. 23 Generalizacin.............................................................................................................................................................. 23 Asociacin.................................................................................................................................................................... 23 Agregacin: ................................................................................................................................................................. 24 Diagrama de objetos......................................................................................................................................................... 25 Diagrama de Componentes ............................................................................................................................................. 26 Cdigo fuente............................................................................................................................................................... 28 Diagrama de Casos de Uso.............................................................................................................................................. 30 Diagrama de Secuencia y Diagrama de Colaboracin.................................................................................................... 32 Diagrama de Estados y Diagrama de Actividades .......................................................................................................... 34
41