Falta el primero Paradigmas de programacin El modelado de sistemas es una tcnica para tratar con la complejidad inherente a

estos sistemas. El uso de modelos ayuda al ingeniero de software a "visualizar" el sistema a construir. Adems, los modelos de un nivel de abstraccin mayor pueden utilizarse para la comunicacin con el cliente. Por ltimo, las herramientas de modelado y las de Ingeniera de Software Automatizada. pueden ayudar a verificar la correccin del modelo.

Punto 2. El Lenguaje de Modelado Unificado (UML) Una exigencia de la gran mayora de instituciones dentro de su Plan Informtico estratgico, es que los desarrollos de software bajo una arquitectura en Capas, se formalicen con un lenguaje estndar y unificado. Es decir, se requiere que cada una de las partes que comprende el desarrollo de todo software de diseo orientado a objetos, se visualice, especifique y documente con lenguaje comn. Se necesitaba un lenguaje que fuese grfico, a fin de especificar y documentar un sistema de software, de un modo estndar incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema. Este lenguaje unificado que cumple con estos requerimientos, es ciertamente UML, el cual cuenta con una notacin estndar y semnticas esenciales para el modelado de un sistema orientado a objetos. Cabe preguntarse Cules son las caractersticas que debe tener una herramienta UML? La herramienta UML debe apoyar todos los diagramas de los nueve que componen UML. La herramienta debe soportar la diagramacin de casos de uso, permitir definir la visin esttica con diagramas de clases y diagramas de objeto, permitir la definicin de la visin dinmica, tales como los diagramas de secuencia, la actividad, de los estados, de colaboracin y el despliegue de componentes que forman el sistema.

Lo fundamental de una herramienta UML es la capacidad de diagramacin, y los diferentes tipos de diagramas que soporta la herramienta. Sus esquemas de apoyo de diseo, documentacin, construccin e implantacin de sistema. As mismo, su flexibilidad para admitir cambios no previstos durante el diseo o el rediseo. En resumen, la herramienta ideal, es aquella que admite diseo desde inicio a fin, diseo inverso (o rediseo) y diseo vise-versa, con esquemas amplios para documentar detalladamente los procesos.

Punto 3

El lenguaje de modelado unificado (UML - Unified Modeling Language) facilita varios tipos de diagramas, los que nos permiten describir los requisitos, funcionalidad, y otros conceptos relativos a un proyecto de desarrollo de software. Los mismos autores de este lenguaje dicen: con el 20% de UML se puede describir el 80% de un proyecto desarrollo. Efectivamente, como desarrolador se tiene que tener la capacidad para seleccionar los diagramas adecuados que describan el proyecto. Indudablemente no sern los mismos diagramas para el sistema de control del aeropuerto que para la pgina web de mis perros. Por otro lado, no debe olvidarse que realizar uno de estos diagramas insume tiempo. Mas all que el o los diagramas deben realizarse correctamente, el desarrollador debe considerar cuanto tiempo inverte en estas actividades. Indudablemente hay que hacer algunos (una buena cantidad), pero nunca debe olvidarse que lo contratan para desarrollar un software, no para hacer dibujitos. Estos diagramas se pueden organizar en dos grupos: Los que describen el comportamiento del negocio, del sistema, de un aspecto en particular, ...

Diagrama de Actividad (Activity Diagram): Representa los procesos de negocio o la lgica de un sistema complejo. Incluye, opcionalmente, el flujo de datos. el nivel de abstraccin suele ser bastante alto, pero pueden realizarse diagramas de actividad exploratorios cuando la lgica que se trata es compleja. Diagrama de Estados (State Machine Diagram): Describe los estados de un objeto as como la transicin entre estados. Muy til para los desarrolladores. Diagrama de Casos de Uso (Use Case Diagram): Muestra casos de uso individuales, actores y las relaciones entre ellos. El Proceso Unificado dice est dirigido por los casos de uso, esto significa que este diagrama (en el nivel de abstraccin que sea) es la base del lenguaje de modelado y representacin. Diagrama de Comunicacin (Communication Diagram): Muestra las relaciones entre instancias de las clases y el flujo de mensajes entre ellas, antes (UML 1.0) se llamaba Diagrama de Colaboracin. La cuestin tiene que ser realmente complicada para tener que utilizar estos diagramas. Diagrama de Interaccin (Interaction Overview Diagram): Es una variante del Diagrama de Actividad, muestra un panorama general del flujo de control dentro del sistema o proceso de negocio. Diagrama de Secuencia (Sequence Diagram): Muestra la secuencia de la lgica, el rden en que se suceden los mensajes. Importante, especialmente cuando se trabaja en ambientes altamente compartidos. Diagrama de Tiempo (Timing Diagram): Muestra el cambio de estado de un objeto a travs del tiempo en respuesta a eventos externos.

Nota: Los ltimos cuatro diagramas tambin se clasifican como Diagramas de Interaccin, dado enfatizan la interaccin entre los objetos. Sin embargo no deja de ser un aspecto del comportamiento. Los que describen la estructura, la forma, la organizaicn, ...

Diagrama de Clases (Class Diagram): Muestra una coleccin de clases, sus tipos, sus contenidos y sus relaciones. Importantsimo representa el modelo de datos, y en consecuencia su persistencia en alguna forma de almacenamiento. Diagrama de Estructura (Composite Structure Diagram): Muestra la estructura interna de ua clase, componente o caso de uso. Especialmente debe indicar los puntos de interaccin con otras partes del sistema. Diagrama de Componentes (Component Diagram): Describe los elementos que componen un sistema. Debe detallar los elementos o componentes, las interacciones y realaciones as cmo las interfaces pblicas. Diagrama de Despliegue (Deployment Diagram): Muestra la arquitectura de ejecucin de un sistema. Incluye nodos, entornos de hardware y software. Diagrama de Objetos (Object Diagram): Describe los objetos y sus relaciones en algn monento. Generalmente se usa en casos especiales para diagramas de clase o de comunicaciones. Diagrama de Paquetes (Package Diagram): Describe como los elementos del modelo se organizan en "paquetes", debe indicar la dependencia entre paquetes.

UML es ha establecido como el estandar en la industria de desarrollo de software. Es cierto que puede utilizarse otro tpo de lenguaje, pero eso reduce la cantidad de personas que pueden leer (entender) el desarrollo. No debe confundirse el lenguaje de modelado con la metodologa del proceso de desarrollo. El lenguaje de modelado, es el conjunto de smbolos y reglas que utilizamos para comunicarnos; la metodologa del proceso de desarrollo es una gua de actividades que pueden seguirse en el ciclo de vida de un proyecto de desarrollo de software. De hecho la metodologa incluye un lenguaje. Si yo fuese la nica persona que desarrolla software en este mundo, no hara falta lenguaje dado que no tendra que comunicarme con nadie, que locura. As como el entrenador de elefantes tiene unas 25 ordenes para comunicarse con estos animalitos, los desarrolladores de software necesitamos una forma para comunicarnos. Esta forma tiene que superar la barrera de los idiomas, por esa razn es que se utilizan dibujos (en general todos los podemos entender), smbolos unificados en todos los idiomas (como por ejemplo los smbolos matemticos), etc. UML, es unificado porque en algn momento los grandes escritores de lenguajes de modelado se pusieron de acuerdo en "unificar" todo lo que ellos hacin. Es mejor ser el dueo de un porcentaje de algo y no del cien por ciento de nada. A partir de ese acuerdo, tanto los autores como muchsimas personas ganaron bastante (y lo siguen haciendo) con este tema. Sin embargo, es un hecho que el software como ingeniera necesita de reglas claras y este aporte fortalece a la industria.

Diagramas: Los diagramas son las grficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinacin para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboracin, de actividad, de componentes y de distribucin. Smbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociacin, dependencia y generalizacin. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbologa.

Tipos de DiagraMAS

Grandes clsicos conocidos por todos, los diagramas de clases, distan mucho de ser los nicos definidos en el lenguaje. De hecho en la versin UML 2 existen trece (13) diagramas concretos y varias categoras de diagramas abstractos, creados como toda clase abstracta, para articular la presentacin de los diagramas. La siguiente figura UML muestra los tipos de diagramas:

Fig. 1 Tipos de diagramas en UML2 En su momento detallar cada uno de los tipos de diagramas, lo importante por ahora es sealar que existen dos grandes grupos: estructurales y de comportamiento; esto conforme a lo dicho sobre la presentacin de modelos en UML. Los diagramas estructurales presentan elementos estticos del modelo, tales como clases, paquetes o componentes; en tanto que los diagramas de comportamiento muestran la conducta en tiempo de ejecucin del sistema, tanto visto como un todo como de las instancias u objetos que lo integran. Por otra parte, en la figura se ve que hay tres tipos de diagramas sealados en un color distinto: los diagramas de estructura compuesta, de tiempo y de resumen de interaccin. Se han resaltado dado que son nuevos dentro del UML por lo que resultan ser de los menos conocidos. Tambin aspiro a tener una descripcin de ellos en los das por venir. Hay que tener en cuenta, que cada diagrama sirve para documentar un aspecto distinto del sistema; el criterio para usarlos es el de tener algo que decir, una historia sobre nuestro sistema que debe ser contada; el tipo de diagrama que utilizaremos ser el que nos d mayor poder expresivo y solo muy difcilmente, la construccin de una serie de diagramas puede ser explicitamente ordenada por un mtodo de desarrollo. Algunos sistemas simples sern bien documentados con pocos diagramas, en tanto que algunos sistemas grandes bien podran beneficiarse de un conjunto mayor. Entonces que valga la advertencia: no hacemos diagramas porque un mtodo nos lo ordene, hacemos diagramas para contar algo importante de nuestro modelo, por lo que indicar que en un sistema haya que hacer tantos de tal o cual diagrama es una declaracin objetable.
ENFOQUE ORIOENTADO A OBJETOS

En el enfoque Orientado a Objetos, las propiedades del objeto son claves. Los
principios del modelo OO son: abstraccin, encapsulacin, modularidad y jerarqua, fundamentalmente, y en menor grado tipificacin (typing), concurrencia, persistencia. [Booch 1986] dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO.

Abstraccin. Es una descripcin simplificada o especificacin de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros. Encapsulacin. En el proceso de ocultar todos los detalles de un objetoque no contribuyen a sus caractersticas esenciales. Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes. Jerarqua o herencia. Es el orden de las abstracciones organizado por niveles. Tipificacin. Es la definicin precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida. Concurrencia. Es la propiedad que distingue un objeto que est activo de uno que no lo est.

Persistencia. Es la propiedad de un objeto a travs de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo despus de que su creador ha dejado de existir) y/o el espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue creado).