4.1 QUE ES EL ANLISIS Y DISEO DE SISTEMAS ?

GUIA REPASO Fundamentos INGENIERIA DE SOFTWARE, ANALISIS Y DISEO O-O Y EL UML

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.

Definiciones de Ingeniera de Software Segn la definicin del IEEE, citada por [Lewis 1994] "software es la suma total de los programas de computadora, procedimientos, reglas, la documentacin asociada y los datos que pertenecen a un sistema de cmputo". Segn el mismo autor, "un producto de software es un producto diseado para un usuario". Adems Ingeniera segn [Bohem 1987] es la aplicacin de la ciencia y las matemticas mediante lo cual las propiedades de la materia y las fuentes de energa de la naturaleza se hacen tiles al hombre en estructuras, mquinas, productos, sistemas y procesos. En este contexto, la Ingeniera de Software (SE del ingls Software Engineering) es un enfoque sistemtico del desarrollo, operacin, mantenimiento y retiro del software", que en palabras ms llanas, se considera que "la Ingeniera de Software es la rama de la ingeniera que aplica los principios de la ciencia de la computacin y las matemticas para lograr soluciones costo-efectivas (eficaces en costo o econmicas) a los problemas de desarrollo de software", es decir, "permite elaborar consistentemente productos correctos, utilizables y costo-efectivos" [Cota 1994].Bajo la perspectiva anterior, La Ingeniera de Software se podra definir como el establecimiento y aplicacin de principios de la Ingeniera para obtener software. Teniendo en cuenta factores tan importantes como el costo econmico, la fiabilidad del sistema y un funcionamiento seguro y eficiente que satisfaga las necesidades del usuario.

Elementos de la Ingeniera de Software

La Ingeniera de software abarca cuatro elementos clave:

1. Mtodos o tcnicas: Indican cmo construir tcnicamente el software, y abarca una serie de tareas que incluyen la planificacin y estimacin de proyectos, el anlisis de requisitos, el diseo de estructuras de datos, programas y procedimientos, la codificacin, las pruebas y el mantenimiento. Los mtodos introducen frecuentemente una notacin especfica para la tarea en cuestin y una serie de criterios de calidad.

2. Herramientas: Son instrumentos o sistemas automatizados para realizar algo de la mejor manera posible. Esta manera ptima puede significar que la herramienta produce resultados ms exactos, ms eficientes, ms productivos, o que refuerza la calidad del producto resultante. Proporcionan un soporte automtico o semiautomtico para todas las fases del desarrollo y sistemas que integran las herramientas de cada fase de manera que sirven para todo el proceso. Estas herramientas se denominan CASE (Computer Aided Software Engineering).

Son instrumentos o sistemas automatizados con la intencin de proveer soporte a las actividades de produccin de software.

Las herramientas CASE en general se pueden clasificar en:

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.

Fase Generales contempladas en los mtodos o tcnicas de un proyecto en la Ingeniera de Software

En el desarrollo de un proyecto en cualquiera de los dos paradigmas orientado a objeto o estructurado intervienen diferentes etapas que se interrelacionan y complementan para con la finalidad de alcanzar los objetivos iniciales. Estas etapas pueden variar dependiendo del paradigma o modelo seleccionado; pero las principales fases de un proyecto son el anlisis de requerimiento, la especificacin, el diseo, el desarrollo e implementacin, y por ltimo el mantenimiento.

Anlisis y Requerimientos: Todo sistema ha de tener un perodo de definicin, en el cual se 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.

Objetivos de la ingeniera de software

En la construccin y desarrollo de proyectos informticos como se menciono anteriormente existen paradigmas que tienen procedimientos con mtodos o tcnicas y herramientas sobre los que se apoya la ingeniera de software, para alcanzar objetivos como lo siguiente: 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.Objetivos de los proyectos de informticosPara que los objetivos se cumplan las empresas emprenden proyectos por las siguientes razones: "Las cinco CCapacidad

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.

ComunicacinLa 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 precios2- 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

Reingeniera del Software

La reingeniera del software es la tecnologa que surge de aplicar las tcnicas de Inteligencia Artificial y matemtica sofisticada al anlisis automatizado y modificacin del cdigo fuente de programas, para abreviarlo y hacerlo ms eficiente.

Actualmente la creacin y modificacin de programas de computadora es una tarea principalmente manual, y una tarea difcil e imprevisible. Los programas grandes suelen ser ms complejos y ms difciles de depurar.

Aunque la tecnologa todava est en su infancia, la reingeniera del software est empezando a tomar algunas tareas de programacin, particularmente las tareas menos creativas, ms repetitivas y las automatiza. Estos programas de reingeniera, escritos en idiomas especialmente diseados, operan en el cdigo fuente de los programas y realizan una variedad de anlisis y modificaciones

Por qu aplicar reingeniera del software

Cuando una aplicacin ha servido para las necesidades del negocio de una compaa durante varios aos, se vuelve inestable debido a las correcciones, adaptaciones y mejoras que se realizaron. Esto deriva en que cada vez que se intenta efectuar un cambio se produzcan efectos colaterales graves e inesperados. Por esta razn es conveniente utilizar la reingeniera del software.

Modelo de procesos de Reingeniera del Software

Puesto que la reingeniera es una suma de tareas que requieren por lo general mucho tiempo, stas se dividen en procesos separados que se llevan a cabo secuencialmente. Los procesos fundamentales de la reingeniera del software son los siguientes:

Anlisis de inventario Se realiza un inventario de todas las aplicaciones disponibles Se ordena esta informacin de acuerdo a su antigedad, importancia en el negocio, mantenibilidad actual y otros criterios.

Reestructuracin de documentos 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 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 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 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 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.

Cuando utilizar Ingeniera InversaEs necesario cuando se tiene un listado de cdigo no estructurado y no documentado y se desea obtener la documentacin completa del programa.

ReestructuracinLa reestructuracin del software modifica el cdigo fuente y/o los datos en un intento de hacerlo adecuado para futuros cambios. Tiende a centrarse en los detalles de diseos de mdulos y en estructuras de datos locales definidas dentro de los mdulos. La reestructuracin brinda algunos beneficios:

Se obtienen programas de mayor calidad, mejor documentacin y menos complejidad.

Reduce la frustracin entre ingenieros que deban trabajar con el programa, mejorando la productividad y facilitando el aprendizaje.

Reduce el esfuerzo requerido para llevar a cabo el mantenimiento.

Hace que el software sea ms sencillo de comprobar y de depurar.

http://orbita.stamedia.com/walternieto/Reing/software.htm

Ms sobre la Reingeniera e Ingeniera inversa

Los conceptos de reingeniera e ingeniera inversa estn ligados al desarrollo de software a gran escala, donde una mejora en proceso de este desarrollo supone un aumento en la competitividad de la empresa.

Aunque hay que tener en cuenta que esta mejora es, en general a largo plazo (normalmente de uno a dos aos) ambas actividades, estn orientadas a automatizar el mantenimiento de aplicaciones. Esta es una tarea que consume gran cantidad de recursos, por lo que cualquier reduccin en el tiempo y recursos empleados en ella supone una importante mejora en la productividad del proceso. Este es el principal objetivo de la reingeniera. Se trata, de analizar el cdigo o el diseo actual y modificarlo con la ayuda de herramientas automticas para traducirlos a cdigos ms estructurados, y ms eficientes.

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.Procedimientos del paradigma basado en el anlisis y diseo estructurado

El paradigma basado en el anlisis (Diagnostico y obtencin de requerimiento) y diseo (Establecimiento de los requerimientos) estructurado se fundamenta en la programacin estructurada o modular y modelar la realidad contemplada en cuatro elementos bsicos: Entidad; Flujo de Datos; Procesos y Almacenes de Datos como se muestra en la Figura No 1. Donde cada elemento modelado puede fcilmente ser un actor del producto final de Software. Es as como las entidades pueden ser usuarios o dispositivos de hardware; los flujos de datos son los reportes, formas, datos magnticos que se intercambian; los procesos son mdulos de software o procedimientos manuales-automticos y los Almacenes de datos son archivos convencionales o estructuras de una base de datos o sencillamente carpetas. Figura No.1 Elementos Bsicos del paradigma anlisis y diseo estructuradoSmbolosSignificadoEjemplo

ENTIDADUsuario o dispositivos H/S

FLUJO DE DATOSFormas; Reportes; Datos Magnticos

PROCESOMdulos de Software o procedimientos Automticos- Manuales

ALMACEN DE DATOSArchivos convencionales o estructuras de una base de datos o sencillamente carpetas.

Procedimientos ms comunes del paradigma estructurado Los procedimientos ms comunes del paradigma estructurado de la ingeniera de software involucran los mtodos o tcnicas siguientes: CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS, ANLISIS ESTRUCTURADO, PROTOTIPO DE SISTEMAS. Estudiados en la ctedra Anlisis y Diseo I, para lo cual existe la respectiva documentacin.Paradigma de la ingeniera de Software basado en el anlisis y diseo orientado a objetos En este modelo de la Ingeniera de Software se fundamenta en la programacin orientada a objetos, en donde se estudian los objetos en un ambiente, as como los eventos que interactan con dichos objeto.Para entender este paradigma del anlisis y diseo orientado a objetos, se deben estudiar los conceptos siguientes: Objeto

Clase

Mensaje

Encapsulacin

Herencia

Polimorfismo InterfazObjeto 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).

ClaseLos 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 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 Choferes

ModeloBMW 2000NombreJuan Prez

Nmero de serie#7834827RDGFNm. de licen762312798

Tipo de motor6 cilindrosFecha nac.21-02-1957

Encender motor

Atributos Objetos

Fig. No. 2 MensajesInterfazUna 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 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 3Herencia 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. 4Es 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)Automvil

Modelo

Nmero de serie

Tipo de motor

Camin (hereda Automviles)

Modelo

Nmero de serie

Tipo de motor

Capacidad de carga

Refrigeracin

PolimorfismoComo 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 sUML. LENGUAJE UNIFICADO DE MODELADOEl Lenguaje Unificado de Modelado (UML) es una tcnica del paradigma orientado a objeto para la especificacin de sistemas en todas sus fases. Esta ha sido desarrollado por los ms importantes autores en materia de Anlisis y Diseo de Sistemas y ha sido usada con xito en sistemas hechos para toda clase de industrias alrededor del mundo: Salud, Bancos, Comunicaciones, Aeronutica, Finanzas y otros

UML fue creado por los autores de las metodologas ms prominentes de los ltimos 20 aos: James Rumbaugh, autor de OMT (Object Modeling Technique), Ivar Jacobson, autor de OOSE (Object Oriented Software Engineering) y Grady Booch, autor del Mtodo Booch.

El proyecto de UML fue auspiciado por Rational Software Corporation y arranc oficialmente enoctubre de 1994. La versin 0.8 se liber en octubre de 1995 y para enero de 1997 seliber la versin 1.0 con la colaboracin de Digital Equipment Corporation, Hewlett-Packard, I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments y Unisys. De sta colaboracin result un lenguaje de modelado bien definido, expresivo, poderoso y aplicable a un amplio espectro de dominios de problema. UML 1.0 fue ofrecido al Object Management Group (OMG) en enero de 1997 como respuesta a su requerimiento de una propuesta para un lenguaje estndar de modelado.

Entre enero y julio de 1997, el grupo original de organizaciones colaboradoras fue expandido para incluir al resto del OMG, incluyendo Andersen Consulting, Ericsson, ObjecTime Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Softwarey Taskon. Se cre una fuerza de tarea semntica encabezada por MCI Systemhouse y administrada por Rational para formalizar la especificacin de UML y para integrar en UML otros esfuerzos de estandarizacin. Una versin revisada de UML (1.1) fue ofrecida a la OMG para estandarizacin en julio de 1997, esta versin fue aceptada por la Fuerza de Tarea de Anlisis y Diseo (ADTF) del OMG y por el OMG Architecture Board y entonces fue presentada a votacin a todos los miembros del OMG. UML 1.1 fue adoptada como estndar por el OMG el 14 de noviembre de 1997. Para la redaccin de este documento existe la Versin UML 2.0 adoptada en Junio del 2003. Para que sirve UML?

UML sirve para hacer modelos que permitan:

Visualizar como es un sistema o como queremos que sea. 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 >) 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).

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.

Diferentes tipos de diagramas: de clases, de casos de uso, de Interaccin, de componentes, de distribucin, de paquetes, de transicin de estados, etc. Cada diagrama est diseado para enfocar un aspecto en particular de un sistema. Por ejemplo, un diagrama de clases ilustra la estructura esttica de un sistema. En un modelo de anlisis muestra los conceptos de negocios del sistema, sus relaciones, sus datos (atributos) y operaciones. Qu fases de un ciclo de desarrollo soporta UML?

UML puede ser usado extensivamente en: Recopilacin de requerimientos, Anlisis de aplicaciones, Diseo de sistemas, en pruebas, en implementacin, en reingeniera y prcticamente en cualquier actividad de desarrollo que sea susceptible de ser modelada.

As por ejemplo, un diagrama de clases, en anlisis contendr relaciones entre los conceptos de un negocio (venta, compra, vendedor, etc.), mientras que en diseo contendr elementos tecnolgicos como ventana, botn, buffer, controlador, conexin, etc. En implementacin podr representar tablas, estructuras de datos, archivos, o clases programadas en un lenguaje orientado a objetos.

Cada diagrama puede ser usado con nfasis distinto en cada fase de desarrollo. Un diagrama cualquiera en una fase de anlisis tendr un nfasis lgico y mientras ms se acerque al diseo y la implementacin mayor ser su nfasis fsico y tecnolgico.

Cabe aclarar que aunque UML es orientado a objetos preferentemente, es til en cualquier modelo tecnolgico ya que es independiente de lenguajes de programacin o tecnologa determinada.

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.

Beneficios de esta TecnologaUna vez que se ha implantado esta tecnologa en la organizacin (y que se ha superado la curva de aprendizaje) tendremos:

Mejores tiempos totales de desarrollo (de 50% o ms). En la mayora de organizaciones hoy en da el tiempo que pasa desde que un proyecto arranca hasta que se estabiliza es ms del doble de lo planeado originalmente. Con el uso de UML las fases de anlisis y diseo consumirn mayor tiempo, pero el tiempo de construccin, implantacin y estabilizacin se reducen drsticamente debido a que no hay correcciones mayores en las fases de mayor impacto de un proyecto.

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.

Mejor soporte a la planeacin y al control de proyectos. Al existir entregables definidos y estandarizados en las distintas fases de un proyecto y al ser stos revisables y certificables por gente distinta del autor, tenemos que los planes de trabajo pueden ser fcilmente creados y corroborados en avance. Lo que permite tomar decisiones a tiempo.

Mayor independencia del personal de desarrollo. Al tener documentadas las aplicaciones en un lenguaje estndar, podemos mover al personal de una aplicacin a otra sin correr altos riesgos y sin depender del conocimiento personal de las aplicaciones.

Mayor soporte al cambio organizacional, comercial y tecnolgico. Un modelo permite cuantificar el impacto de un cambio antes de hacerlo y permite ensayar distintos enfoques de solucin. Con UML un cambio se puede hacer primero en papel.

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.

Servicios necesarios para implantar esta tecnologa. Aunque vara un poco de organizacin a organizacin los servicios de apoyo necesarios para la implantacin de esta tecnologa, podemos mencionar los siguientes:

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. El desarrollo de proyectos pilotos de Desarrollo, Documentacin o Reingeniera deben ser apoyados por uno o ms expertos en el uso de UML que aseguren que el equipo adquiere el conocimiento prctico del uso de UML y agilicen su uso.

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.

CASE. Una herramienta automatizada facilitar el uso de UML y proporcionar un mecanismo de control de documentacin. Con interfaces hacia distintas herramientas de desarrollo, reducir el tiempo de implementacin y con mdulos de ingeniera reversa facilitar procesos de mantenimiento, reingeniera afinacin de aplicaciones.

Bloques bsicos de construccin de UML

Los bloques bsicos de construccin de UML son tres, los elementos, las relaciones y los diagramas.

Los elementos son abstracciones que actan como unidades bsicas de construccin. Hay cuatro tipos, los estructurales, los de comportamiento, los de agrupacin y los de notacin. En cuanto a los elementos estructurales son las partes estticas de los modelos y representan aspectos conceptuales o materiales. Los elementos de comportamiento son las partes dinmicas de los modelos y representan comportamientos en el tiempo y en el espacio. Los elementos de agrupacin son las partes organizativas de UML, establecen las divisiones en que se puede fraccionar un modelo. Slo hay un elemento de agrupacin, el paquete, que se emplea para organizar otros elementos en grupos. Los elementos de notacin son las partes explicativas de UML, comentarios que pueden describir textualmente cualquier aspecto de un modelo. Slo hay un elemento de notacin principal, la nota.

Las relaciones son abstracciones que actan como unin entre los distintos elementos. Hay cuatro tipos, la dependencia, la asociacin, la generalizacin y la realizacin.

Los diagramas son la disposicin de un conjunto de elementos, que representan el sistema modelado desde diferentes perspectivas. UML tiene nueve diagramas fundamentales, agrupados en dos grandes grupos, uno para modelar la estructura esttica del sistema y otro para modelar el comportamiento dinmico. Los diagramas estticos son: el de clases, de objetos, de componentes y de despliegue. Los diagramas de comportamiento son: el de Casos de Uso, de secuencia, de colaboracin, de estados y de actividades.

Elementos del UML (Unidades bsicas de construccin)Elementos de construccin en UML

E

L

E

M

E

N

T

O

S

E

S

T

R

U

C

T

U

R

A

L

E

S

ClaseDescribe un conjunto de objetos que comparten los mismos atributos, mtodos, relaciones y semntica. Las clases implementan una o ms interfaces.

Clase activaSe 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

InterfazAgrupacin 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.

ColaboracinDefine una interaccin entre elementos que cooperan para proporcionar un comportamiento mayor que la suma de los comportamientos de sus elementos.

Caso de usoDescribe 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.

ComponenteParte 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.

NodoElemento fsico que existe en tiempo de ejecucin y representa un recurso computacional con capacidad de procesar.

Elementos

de

comportamientoInteraccinComprende un conjunto de mensajes que se intercambian entre un conjunto de objetos, para cumplir un objetivo especifico.

Mquinas

de

estadosEspecifica la secuencia de estados por los que pasa un objeto o una interaccin, en respuesta a eventos.

Elementos

de

agrupacinPaqueteSe emplea para organizar otros elementos en grupos.

Elementos de construccin en UML (Continuacin)Elementos

de

notacin

NotaPartes explicativa de UML, que puede describir textualmente cualquier aspecto del modelo

Relaciones (Unin entre los distintos elementos)Elementos de relacin en UML

DependenciaEs una relacin entre dos elementos, tal que un cambio en uno puede afectar al otro.

AsociacinEs una relacin estructural que resume un conjunto de enlaces que son conexiones entre objetos.

GeneralizacinEs una relacin en la que el elemento generalizado puede ser substituido por cualquiera de los elementos hijos, ya que comparten su estructura y comportamiento.

RealizacinEs una relacin que implica que la parte realizante cumple con una serie de especificaciones propuestas por la clase realizada (interfaces).

Diagramas (Disposicin de un conjunto de elementos, que representan el sistema modelado desde diferentes perspectivas)Diagramas UMLModelanEstructuraClasesMuestra un conjunto de clases, interfaces y colaboraciones, as como sus relaciones, cubriendo la vista de diseo esttica del sistema.

ObjetosAnlogo 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.

ComponentesMuestra 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.

DespliegueMuestra 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.

Diagramas UML Continuacin M

O

D

E

L

A

N

C

O

M

P

O

R

T

A

M

I

E

N

T

O

Casos de UsoMuestra un conjunto de casos de uso, los actores implicados y sus relaciones. Son diagramas fundamentales en el modelado y organizacin del sistema.

SecuenciaSon 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).

Colaboracin

EstadosMuestra 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.

ActividadesTipo especial de diagrama de estados que muestra el flujo de actividades dentro de un sistema.

Diagrama de Clases y Diagrama de Objetos

Los diagramas de clases muestran un resumen del sistema en trminos de sus clases y las relaciones entre ellas. Son diagramas estticos que muestran qu es lo que interacta, pero no cmo interacta o qu pasa cuando ocurre la interaccin.

El siguiente diagrama (Fig. No. 7) modela los pedidos de un cliente a una tienda de venta por catlogo. La clase principal es Pedido, asociada a un cliente, una forma de pago y un conjunto de artculos.

La clase Pago es abstracta, en UML los nombres de clases abstractas se representan en Itlica. Las clases abstractas actan a modo de interfaz, proporcionando nicamente un listado de mtodos a ser realizados por las clases que las implementan o realizan. Pago es una superclase especializada, y a la vez realizada, por sus formas ms comunes Credito y Efectivo. Un Pedido tiene una nica forma de pago, expresada por su multiplicidad, 1, mientras que una forma de pago puede estar presente en uno o ms pedidos, como sugiere su multiplicidad, 1..*.

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.

MultiplicidadSignificado

1Una nica instancia

N / *N instancias

0..N / 0..*Entre ninguna y N instancias

1..N / 1..*Entre una y N instancias

0..1Ninguna o una instancia

N..MEntre 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, 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 , 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)Relaciones entre clases

Existen cuatros relaciones diferentes entre clases, Dependencias, Generalizacin, Asociacin y Agragacin. En las relaciones se habla de una clase destino y de una clase origen. El origen es desde la que se realiza la accin de relacionar. Es decir desde la que parte la flecha, el destino es la que recibe la flecha. Las relaciones se pueden modificar con estereotipos o con restricciones. 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 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).Fig. No 10Agregacin:

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).

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.

Fig. No. 12Diagrama 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)

Fig. No. 13: Diagrama de Componentes

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.

Fig. No. 14 Componente WindowsEn 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.

Fig. No. 15 Componente Windows con interface 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.

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 fuenteEn 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 despliegueEn 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)

Fig. No. 18 Diagrama de DespliegueUn 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 IndependientesLos diagramas de despliegue sirven para modelar la configuracin hardware con su software del sistema, mostrando qu nodos lo componen. (Ver Fig. No 20)

Fig. No. 20: Diagrama de Despliegue

Diagrama de Casos de Uso

Los diagramas de Casos de Uso describen lo que hace un sistema desde el punto de vista de un observador externo, enfatizando el qu ms que el cmo. Plantean escenarios, es decir, lo que pasa cuando alguien interacta con el sistema, proporcionando un resumen para una tarea u objetivo. El siguiente Caso de Uso describe como Carlos va a desayunar (este es su objetivo), para lo que se plantea el escenario de preparar su caf y el pan tostado (Ver Fig. No. 21).

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)

Fig. No. 22: Diagrama Casos de Uso nivel 2 ACarlos 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 BCarlos 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 concreta un paso ms all el tipo de relacin existente entre dos Casos de Uso. Encontramos dos estereotipos (Requiere) y (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.

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.

Diagrama de Secuencia y Diagrama de Colaboracin

Los diagramas de secuencia describen como los objetos del sistema colaboran. Se trata de un diagrama de interaccin que detalla como las operaciones se llevan a cabo, qu mensajes son enviados y cuando, organizado todo en torno al tiempo. El tiempo avanza hacia abajo en el diagrama. Los objetos involucrados en la operacin se listan de izquierda a derecha de acuerdo a su orden de participacin dentro de la secuencia de mensajes.

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.

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.

SmboloSignificado

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.

Figura 25: Diagrama de Colaboracin

Diagrama de Estados y Diagrama de Actividades

Los diagramas de estados muestran los posibles estados en que puede encontrarse un objeto y las transiciones que pueden causar un cambio de estado. El estado de un objeto depende de la actividad que est llevando a cabo o de alguna condicin.

Las transiciones son las lneas que unen los diferentes estados. En ellas se representa la condicin que provoca el cambio, seguida de la accin oportuna separada por /. En un estado en que el objeto esta pendiente de algn tipo de validacin que dependa de un proceso en curso, no es necesario evento externo alguno para que se produzca la transicin, ya que sta ocurrir cuando termine el proceso, en funcin del resultado de ste. En estos casos es conveniente, por claridad, incluir la condicin que de la que depende la transicin (entre corchetes).

Los estados inicial, a partir del que se entra en la mquina de estados, y final, que indica que la mquina de estados termina, no tienen otro significado adicional, son elementos ornamentales y se representan mediante un circulo negro y un circulo negro resaltado respectivamente.

Los estados de un diagrama de estados pueden anidarse, de forma que los estados relacionados pueden ser agrupados en un estado compuesto. Esto puede ser necesario cuando una actividad involucra sub-actividades asncronas o concurrentes.

Figura 26: Mquina de Estados, estados simples

Figura 27: Mquina de Estados, estados compuestos

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.

Figura 28: Diagrama de Actividades

Cmo utilizar UML

UML es simplemente un lenguaje de modelado. Define un conjunto de elementos y relaciones entre ellos, que se emplean en la definicin de modelos. UML es tpicamente usado como parte de un proceso de desarrollo, con la ayuda de una herramienta CASE (Computer Aided Software Engineering), para definir requerimientos, interacciones y elementos del software que se est desarrollando. UML es independiente de cualquier proceso particular, no est ligado a ningn ciclo de vida de desarrollo del software concreto, no obstante se obtienen mayores beneficios si se selecciona un proceso que est dirigido por Casos de Uso, se centre en la arquitectura y sea incremental.

La arquitectura de un sistema es el conjunto de decisiones significativas que se toma en torno a su organizacin, la seleccin de elementos estructurales, la definicin de las interfaces entre estos elementos, su comportamiento, su divisin en subsistemas, qu elementos son estticos y cuales dinmicos. La arquitectura tambin incluye el uso que se le va a dar al sistema, la funcionalidad, el rendimiento, la capacidad de adaptacin, la reutilizacin, la capacidad de ser comprendido, las restricciones econmicas, las temporales, los compromisos entre alternativas y los aspectos estticos.

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 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.

3. 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.

4. 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.

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.

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.htmRational Inc. UML Resource Center. http://www.rational.com/umlBernd Bruegge, Allen H. Dutoit (2001) Ingeniera de Software Orientado a Objeto. Prentice HallBooch 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, Addison-Wesley, 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.orghttp://www.uml.orgLewis 1994Lewis G. 1994. "What is Software Engineering?" DataPro (4015). Feb 1994. pp. 1-10.

Cota 1994Cota A. 1994 "Ingeniera de Software". Soluciones Avanzadas. Julio de 1994. pp. 5-13.

Boehm,B. 1997 "lmproving Sofware Productivity", IEEE Computers, Septiembre 1987.

UNIDAD I

INTRODUCCION AL ANALISIS Y DISEO O-O Y EL UML

Tabla de Contenido1Definiciones de Ingeniera de Software

1Elementos de la Ingeniera de Software

2Fase Generales contempladas en los mtodos o tcnicas de un proyecto en la Ingeniera de Software

2Objetivos de la ingeniera de software

3Objetivos de los proyectos de informticos

3Capacidad

3Costo

4Control

4Comunicacin

5Competitividad

6Reingeniera del Software

6Por qu aplicar reingeniera del software

6Modelo de procesos de Reingeniera del Software

7Cuando utilizar Ingeniera Inversa

7Ms sobre la Reingeniera e Ingeniera inversa

8Procedimientos del paradigma basado en el anlisis y diseo estructurado

9Procedimientos ms comunes del paradigma estructurado

9Paradigma de la ingeniera de Software basado en el anlisis y diseo orientado a objetos

10Objeto

10Clase

11Mensaje

11Interfaz

12Encapsulacin

12Herencia

13Polimorfismo

13UML. LENGUAJE UNIFICADO DE MODELADO

14Para que sirve UML?

15En qu consiste UML?

15Qu fases de un ciclo de desarrollo soporta UML?

15UML Metodologa?

16Beneficios de esta Tecnologa

16Servicios necesarios para implantar esta tecnologa.

17Bloques bsicos de construccin de UML

18Elementos del UML (Unidades bsicas de construccin)

19Relaciones (Unin entre los distintos elementos)

19Diagramas (Disposicin de un conjunto de elementos, que representan el sistema modelado desde diferentes perspectivas)

20Diagrama de Clases y Diagrama de Objetos

22Relaciones entre clases

23Dependencias.

23Generalizacin.

23Asociacin.

24Agregacin:

25Diagrama de objetos

26Diagrama de Componentes

27Ejecutables.

28Cdigo fuente.

29Diagramas de despliegue

30Diagrama de Casos de Uso

32Diagrama de Secuencia y Diagrama de Colaboracin

34Diagrama de Estados y Diagrama de Actividades

36Cmo utilizar UML

39Referencias

REPUBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR DE EDUCACIN SUPERIORUNIVERSIDAD POLITECNICA DE MARACAIBO

MARACAIBO EDO. ZULIA

DEPARTAMENTO DE INFORMATICA.Unidad Curricular INGENIERA DEL SOFTWARE IIGUIA DE REPASOFUNDAMENTOS INGENIERIA DE SOFTWARE

ANALISIS Y DISEO O-O Y EL UML

PROFESOR: ALFONSO R. GALEA BRACHOACTIVIDADES Y PREGUNTAS A REALIZAR PARA LA UNIDAD I INTRODUCCION AL ANALISIS Y DISEO O-O Y EL UML

Lea y coloque (V) en caso de ser Verdadero y (F) en caso de ser Falso (Si es Falso explique Porque). Las siguientes afirmaciones.

Software son los programas de computadora sin los procedimientos, reglas y documentacin asociada ni los datos que pertenecen a un sistema de cmputo". ( )

Ingeniera es la aplicacin de la ciencia y las matemticas mediante lo cual las propiedades de la materia y las fuentes de energa de la naturaleza se hacen tiles al hombre en estructuras, mquinas, productos, sistemas y procesos.( )

La Ingeniera de Software se podra definir como el establecimiento y aplicacin de principios de la Ingeniera para obtener software. Teniendo en cuenta factores tan importantes como el costo econmico, la fiabilidad del sistema y un funcionamiento seguro y eficiente que satisfaga las necesidades del usuario.( )

Procedimientos: indican cmo construir tcnicamente el software, y abarca una serie de tareas que incluyen la planificacin y estimacin de proyectos, el anlisis de requisitos, el diseo de estructuras de datos, programas y procedimientos, la codificacin, las pruebas y el mantenimiento. Los mtodos introducen frecuentemente una notacin especfica para la tarea en cuestin y una serie de criterios de calidad. ( )

Paradigmas: Son instrumentos o sistemas automatizados para realizar algo de la mejor manera posible. Esta manera ptima puede significar que la herramienta produce resultados ms exactos, ms eficientes, ms productivos, o que refuerza la calidad del producto resultante. Proporcionan un soporte automtico o semiautomtico para todas las fases del desarrollo y sistemas que integran las herramientas de cada fase de manera que sirven para to