viernes, 19 de febrero de 2016

1.2 Lenguaje de modelado unificado: diagrama de clases.

El Lenguaje de Modelado Unificado (UML:UNIFIED MODELING LANGUAGE) es la sucesión de una serie de métodos de análisis y diseño orientadas a objetos que aparecen a fines de los 80's y principios de los 90s.UML es llamado un lenguaje de modelado, no un método. Los métodos consisten de ambos de un lenguaje de modelado y de un proceso. El UML , fusiona los conceptos de la orientación a objetos aportados por Booch, OMT y OOSE (Booch, G. et al., 1999). UML incrementa la capacidad de lo que se puede hacer con otros métodos de análisis y diseño orientados a objetos. Los autores de UML apuntaron también al modelado de sistemas distribuidos y concurrentes para asegurar que el lenguaje maneje adecuadamente estos dominios.
El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos para expresar un diseño. El proceso indica los pasos que se deben seguir para llegar a un diseño.
La estandarización de un lenguaje de modelado es invaluable, ya que es la parte principal del proceso de comunicación que requieren todos los agentes involucrados en un proyecto informático. Si se quiere discutir un diseño con alguien más, ambos deben conocer el lenguaje de modelado y no así el proceso que se siguió para obtenerlo.
Imagen UML
Una de las metas principales de UML es avanzar en el estado de la integración institucional proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr un intercambio exitoso de modelos de información entre herramientas, se requirió definir a UML una semántica y una notación.
La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notación del diagrama de clases define como se representan los elementos y conceptos como son: una clase, una asociación y una multiplicidad. ¿Y qué significa exactamente una asociación o multiplicidad en una clase? Un metamodelo es la manera de definir esto (un diagrama, usualmente de clases, que define la notación).
Para que un proveedor diga que cumple con UML debe cubrir con la semántica y con la notación.
Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo esta definición una herramienta que solo dibuje, no puede cumplir con la notación de UML.
El lenguaje está dotado de múltiples herramientas para lograr la especificación determinante del modelo, pero en nuestro caso se trabaja en forma simplificada sobre: 
  1.  Modelamiento de Clases
  2.  Casos de uso
  3.  Diagrama de Interacción.
  4. Los diagramas de clases de UML forman la vista lógica.
  5. Los diagramas de interacción de UML constituyen la vista de proceso.
  6. La vista de desarrollo captura el software en su entorno de desarrollo.
  7. Los diagramas de despliegue integran la vista física .
  8. Los escenarios: el modelo de casos de uso.

Los diagramas de clases son una potente herramienta de diseño ayudando a los desarrolladores a planificar y establecer la arquitectura y estructura del sistema y subsistema antes de escribir el ningún código esto permite asegurar que el sistema este bien diseñado desde el principio. Además estos diagramas de clases son usadas prácticamente en la totalidad de sistema en que se utilizan UML para su modelado.
Los diagramas de clase también muestran los atributos y operaciones de una clase y las restricciones a que se ven sujetos, según la forma en que se conecten los objetos. En mi punto de vista los diagramas de clases muestran o ayudan a implementar mejor las ideas en un programa, dirigido por atributos y aspectos importantes en ello, el diagrama tiene que estar perfectamente elaborado para evitar errores en la realización del programa.
El UML es idóneo para modelar el alcance de proyectos informáticos o de ingeniería de negocios (y, muy probablemente, también para modelar cualquier proyecto que pueda desglosarse en guiones de uso, o mediante técnicas tipo story board).
En el siguiente diagrama UML de procesos de negocio se pueden apreciar los subprocesos del área de conocimiento de manejo de alcances del PMBOK.
Esta área de conocimientos incluye los procesos necesarios para asegurar que el proyecto incluya todo el trabajo requerido, y sólo el trabajo requerido, para completar el proyecto satisfactoriamente.
En el subprocesos de definición del alcance se pueden emplear artefactos de UML, tales como el modelado de procesos, los casos de uso y el modelado de requisitos.
MODELADO DE REQUISITOS CON CASOS DE USO
Los casos de uso son los artefactos de UML para modelar los requisitos (o “requerimientos”) funcionales del sistema.
Diagrama de casos de uso
Es el diagrama de UML donde se muestra gráficamente el comportamiento del sistema y los actores que interactúan con el sistema. Pongamos como ejemplo, un modelado elemental de requisitos funcionales para un cajero automático:

1.1 Elementos del modelo de objetos: clases, objetos, abstracción, modularidad, encapsulamiento, herencia y polimorfismo.

Clases:
Una clase es una plantilla que encapsula los datos y las abstracciones de datos
necesarios para describir el contenido y comportamiento de alguna entidad del
mundo real. Es una descripción generalizada (patrón o plantilla) que describe una

colección de objetos similares.
Descripción de los datos (atributos) y de las operaciones que describen el comportamiento de un cierto conjunto de elementos homogéneos.
° Resultado del proceso de abstracción.
° “Molde” de infinitos objetos con ciertas características para crear en el dominio de la             computadora un reflejo del mundo real.

Objetos:
Un objeto es una instancia de una clase específica: los objetos heredan los atributos
y operaciones de una clase (su clase padre). Todos los objetos de una clase tienen
el mismo conjunto de atributos y el mismo número de operaciones. Difieren

solamente en los valores de sus atributos respectivos.

Para modelar una clase y un objeto se utiliza un lenguaje de modelado llamado

UML (Lenguaje Unificado de Modelado).



Abstracción: 
Definición: “Proceso mental de extracción de las características esenciales (requisitos o funciones) de algo, ignorando los detalles superfluos”.

Motivo: No es posible manejar todos los aspectos de un sistema, al mismo tiempo un individuo puede comprender 7 ± 2 detalles a la vez.
° Fundamentalmente subjetiva (dependiendo del interés del observador).
° Punto de vista del “cliente” (usuario).
° Implementación en OO --> Clases Ejemplos:
° Autobús visto por un mecánico y un pasajero.
° Persona en un historial clínico y en la universidad.
° Radio como emisora o como aparato.

 Modularidad:
Definición: “Proceso de descomposición de un sistema en un conjunto de piezas poco acopladas (independientes) y cohesivas (con significado propio): módulos”.

Mediante la modularidad, se propone al programador dividir su aplicación en varios módulos diferentes (ya sea en forma de clases, paquetes o bibliotecas), cada uno de ellos con un sentido propio. Esta fragmentación disminuye el grado de dificultad del problema al que da respuesta el programa, pues se afronta el problema como un conjunto de problemas de menor dificultad, además de facilitar la comprensión del programa.

Encapsulamiento:
El encapsulamiento consiste en unir en la Clase las características y comportamientos, esto es, las variables y métodos. Es tener todo esto es una sola entidad. En los lenguajes estructurados esto era imposible. Es evidente que el encapsulamiento se logra gracias a la abstracción y el ocultamiento que veremos a continuación.

La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que tendremos a las Clases como cajas negras donde sólo se conoce el comportamiento pero no los detalles internos, y esto es conveniente porque nos interesará será conocer qué hace la Clase pero no será necesario saber cómo lo hace.

Definición: “Proceso por el que se ocultan los detalles del soporte de las características esenciales de una abstracción (cómo se realizan las funciones)”


Herencia:
° Es la transmisión de la vista pública (métodos públicos) y de la vista privada (atributos,         métodos privados y definición de los métodos) de una clase a otra.
° Forma de estructurar tipos/clases según su comportamiento mediante la creación de una     jerarquía de clasificación.



La herencia es uno de los conceptos más cruciales en la POO (Programación Orientada a Objetos). La herencia básicamente consiste en que una clase puede heredar sus variables y métodos a varias subclases (la clase que hereda es llamada superclase o clase padre). Esto significa que una subclase, aparte de los atributos y métodos propios, tiene incorporados los atributos y métodos heredados de la superclase. De esta manera se crea una jerarquía de herencia. Por ejemplo, imaginemos que estamos haciendo el análisis de un Sistema para una tienda que vende y repara equipos celulares.


Imagen Herencia



Polimorfismo:
Es el principio por el cual una misma operación es resuelta de diferente forma según el objeto que recibe el mensaje.
° Posibilidad que tienen distintos objetos de actuar de una manera diferente (desencadenar   operaciones distintas) en respuesta a un mismo mensaje (una misma llamada a función).




En programación orientada a objetos el polimorfismo se refiere a la posibilidad de enviar un mensaje a un grupo de objetos cuya naturaleza puede ser heterogénea. El único requisito que deben cumplir los objetos que se utilizan de manera polimórfica es saber responder al mensaje que se les envía.
La apariencia del código puede ser muy diferente dependiendo del lenguaje que se utilice, más allá de las obvias diferencias sintácticas.
La esencia del polimorfismo no atañe a la clase o prototipo de la que provienen los objetos. Aun así, en los lenguajes basados en clases, es habitual (y en algunos tal vez sea el único modo) que dichos objetos pertenezcan a subclases pertenecientes a una misma jerarquía. Entonces, el polimorfismo debe verse como una forma flexible de usar un grupo de objetos (como si fueran sólo uno). Podría decirse que el polimorfismo en esencia refiere al comportamiento de los objetos, no a su pertenencia a una jerarquía de clases (o a sus tipos de datos).