Unified Modeling Language (UML) Unified Modeling Language (UML) Lenguaje Unificado de Modelado ConceptosBásicos.

Presentación del tema: "Unified Modeling Language (UML) Unified Modeling Language (UML) Lenguaje Unificado de Modelado ConceptosBásicos."— Transcripción de la presentación:

1 Unified Modeling Language (UML) Unified Modeling Language (UML) Lenguaje Unificado de Modelado ConceptosBásicos

2 Modelado  Un empresa que puede desarrollar este software de forma predecible y puntual con un uso eficiente y efectivo de recursos, tanto humanos como materiales, tiene un negocio sostenible*. * El Lenguaje Unificado de Modelado. G. Booch, J. Rumbaugh, I. Jacobson. Addison Wesley, 1999  Una empresa de software con éxito es aquella que produce de una manera consistente software de calidad que satisface las necesidades de los usuarios.

3 Modelado Un modelo es una simplificación de la realidad. Como tal, la ingeniería de software debe basarse en el modelado como una parte central de toda la actividades que conducen a la producción de software de calidad. Podemos definir el proceso como “El conjunto de actividades del desarrollo de software y las relaciones entre ellas''. Estas actividades varían según la organización y el tipo de sistema, pero en general la gestión del proceso exige el disponer de un modelo. Construimos modelos para comunicar la arquitectura y el comportamiento deseado en nuestro sistema. Construimos modelos para visualizar y controlar la arquitectura del sistema y para comprender mejor el sistema que estamos construyendo, muchas veces descubriendo posibilidades de simplificación y reutilización.

4 Construimos modelos porque: Los modelos nos ayudan a visualizar cómo es o como queremos que sea un sistema. Los modelos nos permiten especificar la estructura o el comportamiento de un sistema. Los modelos nos proporcionan plantillas que nos guían en la construcción de un sistema. Lo modelos documentan las decisiones que hemos adoptado. Construimos modelos de sistemas complejos porque no podemos comprender el sistema en su totalidad. En general los modelos nos ayudan a organizar, visualizar, comprender y crear sistemas complejos.

5 Modelos y Diagramas  Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completa- mente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle.  Diagrama: una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos. OMG UML 1.4 Specification

6 Diseño funcional y diseño O. O. En la visión tradicional del desarrollo del software (perspectiva algorítmica) el bloque principal de construcción de todo el software es el procedimiento o función. Esta visión conduce a los desarrolladores a centrarse en cuestiones de control y de descomposición de algoritmos grandes en otros más pequeños. Este enfoque produce sistemas frágiles y se ha comprobado que a medida que los sistemas crecen y cambian, su mantenimiento resulta muy complejo. En la orientación a objetos el bloque de construcción es el objeto o clase. Un objeto es “algo” extraído del vocabulario del problema o del vocabulario de la solución. Todo objeto tiene identidad (puede distinguirse de otros objetos), estado (generalmente hay datos asociados a él) y comportamiento (se le puede hacer “cosas” y el puede hacer “cosas”). Tomando un enfoque orientado a objetos vemos el sistema como una colección de objetos, en vez de como una descripción de funciones.

7 Diseño orientado a objetos Hasta los años 70 la estrategia de diseño software más utilizada se basaba en descomponer el diseño en componentes funcionales con la información del sistema almacenada en un área compartida de datos (diseño funcional). Sin embargo David Parnas (1972) sugirió una estrategia alternativa a principios de los 70, el diseño orientado a objetos. Su idea era encapsular cada una de las variables globales de la aplicación en un único módulo junto con sus operaciones asociadas, mediante las cuales se podía tener acceso a esas variables.

8 Diseño orientado a objetos El diseño orientado a objetos propone una estrategia de diseño basada en la ocultación de información, que ve el sistema software como un conjunto de objetos que interaccionan entre sí con su propio estado privado, en vez de un conjunto de funciones que comparten un estado global. Es ampliamente aceptado que los diseños y desarrollos orientados a objetos son más fáciles de mantener ya que los objetos se pueden entender y modificar como entidades autónomas. Así, el cambiar la implementación de un objeto añadiendo servicios no debería afectar a otros objetos del sistema. Además, con frecuencia existe una correspondencia clara entre las entidades del mundo real y los objetos que las controlan en el sistema, lo que mejora el entendimiento y por tanto el mantenimiento del diseño. Los objetos son componentes reusables porque son encapsulaciones independientes del estado y de las operaciones. Basándonos en esto, los diseños se pueden desarrollar utilizando objetos que han sido creados en diseños anteriores, reduciendo costos de diseño, programación y validación.

9 Historia de UML La notación UML se deriva de y unifica, las tres metodologías de análisis y diseño O.O. más extendidas: Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones. Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-Modeling Technique). Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodología de casos de uso (use case). El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacobson y su compañía Objectory se incorporaron a Rational en su unificación, aportando el método OOSE. UML es el primer método en publicar un meta-modelo en su propia notación, incluyendo la notación para la mayoría de la información de requisitos, análisis y diseño.

10 Historia de UML Nov ‘97 UML aprobado por el OMG 1998 1999 2000 UML 1.2 UML 1.3 UML 1.4 2005? UML 2.0 Revisiones menores UML 1.5 2003

11 ¡UML!  UML es un lenguaje estándar para escribir planos de software.  Puede visualizar, especificar, construir y documentar los componentes de un sistema OO que involucre una gran cantidad de software.  UML es apropiado para modelar desde sistemas de información en empresas hasta aplicaciones web. Es un lenguaje muy expresivo que cubre todas las vistas necesarias para desarrollar y desplegar sistemas.

12 Donde utilizamos UML Está pensado para sistemas con gran cantidad de software:  Sistemas de información de empresas  Banco y servicios financieros  Telecomunicaciones, transporte  Defensa/industria aeroespacial  Electrónica médica  Ámbito científico  También se pueden modelar workflows en un sistema jurídico, diseño de hardware, etc.

13 Un modelo conceptual de UML Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje. Esto requiere aprender tres elementos principales:  Bloques básicos de construcción de UML:  Reglas que dictan cómo se pueden combinar esos bloques.  Y algunos mecanismos comunes que se aplican a través de UML. relaciones

14 Elementos en UML Estos elementos son lo bloques básicos de construcción orientados a objetos de UML. Se utilizan para escribir modelos bien formados.

15 Elementos Estructurales  Clase: Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). En UML, una clase es representada por un rectángulo que posee tres divisiones:

16 Elementos Estructurales Donde: Superior: Contiene el nombre de la Clase Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public). Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

17 Elementos Estructurales Una Cuenta que posee como característica:  Saldo Puede realizar las operaciones de:  Depositar  Retirar  Consultar Saldo Cuenta (-) saldo (+) depositar(monto: int) boolean (+) retirar(monto: int) boolean (+) consultar(monto: int) boolean

18 Elementos Estructurales  Atributos: Los atributos o características de una Clase pueden ser de tres tipos. Estos definen el grado de comunicación y visibilidad de ellos con el entorno.  public (+): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.  private (-): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos pueden acceder a él).  protected (#): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accedido por métodos de la clase además de las subclases que se deriven.

19 Elementos Estructurales  Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:  public (+): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.  private (-): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden acceder).  protected (#, ): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accedido por métodos de la clase además de métodos de las subclases que se deriven.

20 Objetos: Un objeto es una instancia de alguna clase. Elementos Estructurales

21 Actores: Un actor es "algo" o "alguien" que puede interactuar con el sistema que se está desarrollando. Es un elemento externo al sistema. Elementos Estructurales

22 Casos de uso: Un caso de uso es una descripción de un conjunto de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de interés para un actor particular. Elementos Estructurales

23 Interfaz: Es una colección de operaciones que especifica un servicio de una clase o componente. Por lo tanto, una interfaz describe el comportamiento visible externamente de ese elemento. Una interfaz puede representar el comportamiento completo de una clase o componente, o sólo una parte de este comportamiento. Una interfaz define un conjunto de especificaciones de operaciones (o sea, sus signaturas), pero nunca sus implementaciones. Una interfaz raramente se encuentra aislada, más bien, suele estar conectada a la clase o componente que la realiza. Elementos Estructurales

24 Colaboración: Define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Por lo tanto las colaboraciones tienen dimensión tanto estructural como de comportamiento. Una clase dada puede participar en varias colaboraciones. Elementos Estructurales

25 Componentes: Un componente es una parte física de un sistema que ofrece un conjunto de interfaces y proporciona la implementación de dicho conjunto. En un sistema, se pueden encontrar diferentes tipos de componentes de despliegue, tales como componentes COM+, JavaBeans, así como componentes que sean artefactos del proceso de desarrollo, tales como archivos de código fuente. Un componente representa típicamente el empaquetamiento físico de diferentes elementos lógicos, como clases interfaces y colaboraciones. Elementos Estructurales

26 Nodo: Es un elemento físico que existe en tiempo de ejecución, representando un recurso computacional que, por lo general, dispone de algo de memoria y con frecuencia capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo y puede también migrar de un nodo a otro. Elementos Estructurales

27 Resumen de elementos

28 Elementos en UML Estos elementos son lo bloques básicos de construcción orientados a objetos de UML. Se utilizan para escribir modelos bien formados.

29 Elementos de comportamiento Interacción: Es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular, para alcanzar un propósito específico. Una interacción involucra muchos otros elementos, incluyendo mensajes, secuencias de acción y enlaces. conducir Los elementos de comportamiento son las partes dinámicas de los modelos UML Representación de los elementos de comportamiento

30 Elementos en UML Estos elementos son lo bloques básicos de construcción orientados a objetos de UML. Se utilizan para escribir modelos bien formados.

31 Elementos de agrupación  Son las partes organizativas de los modelos UML.  Hay un elemento de agrupación principal, los paquetes. Un paquete es un mecanismo de propósito general para organizar elementos en grupos.  Los elementos estructurales, los elementos de comportamiento, e incluso otros elementos de agrupación pueden incluirse en un paquete.  Al contrario de los componentes (que existen en tiempo de ejecución), un paquete es puramente conceptual (sólo existe en tiempo de desarrollo). utilidades Representación de un paquete

32 Elementos en UML Estos elementos son lo bloques básicos de construcción orientados a objetos de UML. Se utilizan para escribir modelos bien formados.

33 Elementos de anotación  Son las partes explicativas de los modelos UML.  Hay un tipo principal llamado Nota. Una nota es simplemente un símbolo para mostrar restricciones y comentarios junto a un elemento o una colección de elementos.  Las notas se utilizan para adornar los diagramas con restricciones o comentarios que se expresan mejor en texto informal o formal. Representación de una nota