El Modelado De Sistemas Software 1a135g

Falta el primero Paradigmas de programación El modelado de sistemas es una técnica para tratar con la complejidad inherente a estos sistemas. El uso de modelos ayuda al ingeniero de software a "visualizar" el sistema a construir. Además, los modelos de un nivel de abstracción mayor pueden utilizarse para la comunicación con el cliente. Por último, las herramientas de modelado y las de Ingeniería de Software Automatizada. pueden ayudar a verificar la corrección del modelo.

Punto 2. El Lenguaje de Modelado Unificado (UML) Una exigencia de la gran mayoría de instituciones dentro de su Plan Informático estratégico, es que los desarrollos de software bajo una arquitectura en Capas, se formalicen con un lenguaje estándar y unificado. Es decir, se requiere que cada una de las partes que comprende el desarrollo de todo software de diseño orientado a objetos, se visualice, especifique y documente con lenguaje común. Se necesitaba un lenguaje que fuese gráfico, a fin de especificar y documentar un sistema de software, de un modo estándar 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 notación estándar y semánticas esenciales para el modelado de un sistema orientado a objetos. Cabe preguntarse ¿Cuáles son las características 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 diagramación de casos de uso, permitir definir la visión estática con diagramas de clases y diagramas de objeto, permitir la definición de la visión dinámica, tales como los diagramas de secuencia, la actividad, de los estados, de colaboración y el despliegue de componentes que forman el sistema.

Lo fundamental de una herramienta UML es la capacidad de diagramación, y los diferentes tipos de diagramas que soporta la herramienta. Sus esquemas de apoyo de diseño, documentación, construcción e implantación de sistema. Así mismo, su flexibilidad para itir cambios no previstos durante el diseño o el rediseño. En resumen, la herramienta ideal, es aquella que ite diseño desde inicio a fin, diseño inverso (o rediseño) y diseño 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 serán los mismos diagramas para el sistema de control del aeropuerto que para la página 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 lógica de un sistema complejo. Incluye, opcionalmente, el flujo de datos. el nivel de abstracción suele ser bastante alto, pero pueden realizarse diagramas de actividad exploratorios cuando la lógica que se trata es compleja. Diagrama de Estados (State Machine Diagram): Describe los estados de un objeto así como la transición 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 abstracción que sea) es la base del lenguaje de modelado y representación. Diagrama de Comunicación (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 Colaboración. La cuestión tiene que ser realmente complicada para tener que utilizar estos diagramas. Diagrama de Interacción (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 lógica, 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 través del tiempo en respuesta a eventos externos.

Nota: Los últimos cuatro diagramas también se clasifican como Diagramas de Interacción, dado enfatizan la interacción entre los objetos. Sin embargo no deja de ser un aspecto del comportamiento. Los que describen la estructura, la forma, la organizaicón, ...







 



Diagrama de Clases (Class Diagram): Muestra una colección de clases, sus tipos, sus contenidos y sus relaciones. Importantísimo 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 interacción 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 públicas. Diagrama de Despliegue (Deployment Diagram): Muestra la arquitectura de ejecución de un sistema. Incluye nodos, entornos de hardware y software. Diagrama de Objetos (Object Diagram): Describe los objetos y sus relaciones en algún 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 típo de lenguaje, pero eso reduce la cantidad de personas que pueden leer (entender) el desarrollo. No debe confundirse el lenguaje de modelado con la metodología del proceso de desarrollo. El lenguaje de modelado, es el conjunto de símbolos y reglas que utilizamos para comunicarnos; la metodología del proceso de desarrollo es una guía de actividades que pueden seguirse en el ciclo de vida de un proyecto de desarrollo de software. De hecho la metodología incluye un lenguaje. Si yo fuese la única persona que desarrolla software en este mundo, no haría falta lenguaje dado que no tendría 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 razón es que se utilizan dibujos (en general todos los podemos entender), símbolos unificados en todos los idiomas (como por ejemplo los símbolos matemáticos), etc. UML, es unificado porque en algún momento los grandes escritores de lenguajes de modelado se pusieron de acuerdo en "unificar" todo lo que ellos hacián. Es mejor ser el dueño de un porcentaje de algo y no del cien por ciento de nada. A partir de ese acuerdo, tanto los autores como muchísimas personas ganaron bastante (y lo siguen haciendo) con este tema. Sin embargo, es un hecho que el software como ingeniería necesita de reglas claras y este aporte fortalece a la industria.

Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución. Símbolos 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 asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.

Tipos de DiagraMAS

Grandes clásicos conocidos por todos, los diagramas de clases, distan mucho de ser los únicos definidos en el lenguaje. De hecho en la versión UML 2 existen trece (13) diagramas concretos y varias categorías de diagramas abstractos, creados como toda clase abstracta, para articular la presentación 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 señalar que existen dos grandes grupos: estructurales y de comportamiento; esto conforme a lo dicho sobre la presentación de modelos en UML. Los diagramas estructurales presentan elementos estáticos del modelo, tales como clases, paquetes o componentes; en tanto que los diagramas de comportamiento muestran la conducta en tiempo de ejecución 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 señalados en un color distinto: los diagramas de estructura compuesta, de tiempo y de resumen de interacción. Se han resaltado dado que son nuevos dentro del UML por lo que resultan ser de los menos conocidos. También aspiro a tener una descripción de ellos en los días 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 difícilmente, la construcción de una serie de diagramas puede ser explicitamente ordenada por un método de desarrollo. Algunos sistemas simples serán bien documentados con pocos diagramas, en tanto que algunos sistemas grandes bien podrían beneficiarse de un conjunto mayor. Entonces que valga la advertencia: no hacemos diagramas porque un método 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 declaración objetable. ENFOQUE ORIOENTADO A OBJETOS

En el enfoque Orientado a Objetos, las propiedades del objeto son claves. Los principios del modelo OO son: abstracción, encapsulación, modularidad y jerarquía, fundamentalmente, y en menor grado tipificación (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. 

   



Abstracción. Es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros. Encapsulación. En el proceso de ocultar todos los detalles de un objetoque no contribuyen a sus características esenciales. Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes. Jerarquía o herencia. Es el orden de las abstracciones organizado por niveles. Tipificación. Es la definición 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 través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado).