jueves, 25 de febrero de 2016
miércoles, 24 de febrero de 2016
1.2 Lenguaje de modelado unificado: Diagrama de clases.
Lenguaje Unificado de Modelado
Es el lenguaje de modelado de sistemas de software más
conocido y utilizado en la actualidad. Es un lenguaje gráfico para visualizar,
especificar, construir y documentar un sistema. UML ofrece un estándar para
describir un "plano" del sistema (modelo), incluyendo aspectos
conceptuales tales como procesos de negocio y funciones del sistema, y aspectos
concretos como expresiones de lenguajes de programación, esquemas de bases de
datos y componentes reutilizables.
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.
Los diagramas de clases: se utilizan para mostrar la
estructura estática del sistema modelado pueden contener clases, interfaces,
paquetes, relaciones e incluso instancias, como objetos o enlaces. 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.
El diagrama de clase describe los tipos de objetos que hay en el sistema
y las diversas clases de relaciones estáticas que existen entre ellos. Hay dos
tipos principales de relaciones estáticas: Asociaciones (por ejemplo, un diente
puede rentar diversas videocintas).Subtipos (una enfermera es un tipo de
persona). 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.
El lenguaje unificado de modelado (UML)
En todas las disciplinas de la Ingeniería se hace evidente la importancia
de los modelos ya que describen el aspecto y la conducta de "algo".
Ese "algo" puede existir, estar en un estado de desarrollo o
estar, todavía, en un estado de planeación. Es en este momento cuando los
diseñadores del modelo deben investigar los requerimientos del producto
terminado y dichos requerimientos pueden incluir áreas tales como
funcionalidad, performance y confiabilidad. Además, a menudo,
el modelo es dividido en un número de vistas, cada una de las cuales describe
un aspecto específico del producto o sistema en construcción.
El modelado sirve no solamente para los grandes sistemas, aun en
aplicaciones de pequeño tamaño se obtienen beneficios de modelado, sin embargo
es un hecho que entre más grande y más complejo es el sistema, más importante
es el papel de que juega el modelado por una simple razón: "El hombre hace
modelos de sistemas complejos porque no puede entenderlos en su
totalidad".
UML es una técnica para la especificación sistemas en todas sus fases.
Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño
antecesores y, precisamente, los padres de UML son Grady Booch, autor del
método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de
los métodos OOSE y Objectory. La versión 1.0 de UML fue liberada en Enero de
1997 y ha sido utilizado con éxito en sistemas construidos para toda clase de
industrias alrededor del mundo: hospitales, bancos, comunicaciones,
aeronáutica, finanzas, etc.
Los principales beneficios de UML son:
*Mejores tiempos totales de desarrollo (de 50 % o más).
*Modelar sistemas (y no sólo de software) utilizando conceptos orientados
a objetos.
*Establecer conceptos y artefactos ejecutables.
*Encaminar el desarrollo del escalamiento en sistemas complejos de misión
crítica.
*Crear un lenguaje de modelado utilizado tanto por humanos como por
máquinas.
*Mejor soporte a la planeación y al control de proyectos.
*Alta reutilización y minimización de costos.
UML, ¿Método o Lenguaje de Modelado?
UML es un lenguaje para hacer modelos y es independiente de los métodos
de análisis y diseño. Existen diferencias importantes entre un método y un
lenguaje de modelado. Un método es una manera explícita de
estructurar el pensamiento y las acciones de cada individuo. Además, el método
le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo;
mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos
contienen modelos y esos modelos son utilizados para describir algo y comunicar
los resultados del uso del método.
Un modelo es expresado en un lenguaje de modelado. Un
lenguaje de modelado consiste de vistas, diagramas, elementos de modelo los
símbolos utilizados en los modelos y un conjunto de mecanismos generales o
reglas que indican cómo utilizar los elementos. Las reglas son sintácticas,
semánticas y pragmáticas.
Vistas: Las vistas muestran diferentes aspectos del sistema
modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en
un número de diagramas y todos esos diagramas juntos muestran una
"fotografía" completa del sistema. Las vistas también ligan el
lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las
diferentes vistas que UML tiene son:
*Vista Use-Case: Una vista que muestra la funcionalidad del sistema como
la perciben los actores externos.
*Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del
sistema, en términos de la estructura estática y la conducta dinámica del
sistema.
*Vista de Componentes: Muestra la organización de los componentes de
código.
*Vista Concurrente: Muestra la concurrencia en el sistema, direccionando
los problemas con la comunicación y sincronización que están presentes en un
sistema concurrente.
*Vista de Distribución: muestra la distribución del sistema en la
arquitectura física con computadoras y dispositivos llamados nodos.
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.
Reglas o Mecanismos generales: Proveen comentarios extras,
información o semántica acerca del elemento de modelo; además proveen
mecanismos de extensión para adaptar o extender UML a un método o proceso
específico, organización o usuario.
FASES DEL DESARROLLO DE UN SISTEMA
Las fases del desarrollo de sistemas que soporta UML son: Análisis
de requerimientos, Análisis, Diseño, Programación y Pruebas.
Análisis de Requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del
cliente. A través del modelado de casos de uso, los actores externos que tienen
interés en el sistema son modelados con la funcionalidad que ellos requieren
del sistema (los casos de uso). Los actores y los casos de uso son modelados
con relaciones y tienen asociaciones entre ellos o éstas son divididas en
jerarquías. Los actores y casos de uso son descritos en un diagrama use-case.
Cada use-case es descrito en texto y especifica los requerimientos del cliente:
lo que él (o ella) espera del sistema sin considerar la funcionalidad que se
implementará. Un análisis de requerimientos puede ser realizado también para
procesos de negocios, no solamente para sistemas de software.
Análisis
La fase de análisis abarca las abstracciones primarias (clases y objetos)
y mecanismos que están presentes en el dominio del problema. Las clases que se
modelan son identificadas, con sus relaciones y descritas en un diagrama de
clases. Las colaboraciones entre las clases para ejecutar los casos de uso
también se consideran en esta fase a través de los modelos dinámicos en UML. Es
importante notar que sólo se consideran clases que están en el dominio del
problema (conceptos del mundo real) y todavía no se consideran clases que
definen detalles y soluciones en el sistema de software, tales como clases para
interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.
Diseño
En la fase de diseño, el resultado del análisis es expandido a una
solución técnica. Se agregan nuevas clases que proveen de la infraestructura
técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos
en una base de datos, comunicaciones con otros sistemas, etc. Las clases de
dominio del problema del análisis son agregadas en esta fase. El diseño resulta
en especificaciones detalladas para la fase de programación.
Programación
En esta fase las clases del diseño son convertidas a código en un
lenguaje de programación orientado a objetos. Cuando se crean los modelos de
análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos
modelos a código.
Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de
integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de
unidades se realizan a clases individuales o a un grupo de clases y son
típicamente ejecutadas por el programador. Las pruebas de integración integran
componentes y clases en orden para verificar que se ejecutan como se
especificó. Las pruebas de sistema ven al sistema como una "caja
negra" y validan que el sistema tenga la funcionalidad final que le
usuario final espera. Las pruebas de aceptación conducidas por el cliente
verifican que el sistema satisface los requerimientos y son similares a las
pruebas de sistema
1.1 Elementos del modelo de objetos:clases, objetos, abstracción, modularidad,encapsulamiento, herencia y polimorfismo.
Objeto
La
idea de objeto es similar a la del mundo real, un objeto puede ser una silla,
una mesa. Tu perro es un objeto.
Los
objetos tienen dos características: Un estado y un comportamiento. Fíjate que
por ejemplo tu perro tiene un estado: nombre, color, raza, altura, etc. y un
comportamiento: ladrar, cavar pozo, llorar, dormir, comer, etc.
Entonces
podemos definir a un objeto en POO, como un conjunto de datos y funciones
relacionadas. A las funciones de los objetos, tales como acelerar en el caso
del auto, de aquí en más las llamaremos métodos, a los datos los llamaremos
atributos.
Los
objetos en programación, son modelados observando objetos del mundo real, por
ejemplo, implementamos el objeto "perro" dentro de nuestro programa
definiendo los atributos y métodos del objeto perro real.
Clase
Una
clase es algo abstracto que define la "forma" del objeto, se podría
hablar de la clase como el molde de los objetos.
En
el mundo real existen objetos del mismo tipo, por ejemplo, tu bicicleta es solo
una más de todas las bicicletas del mundo. Entonces diríamos que tu bicicleta
es una instancia de la clase "Bicicleta". Todas las bicicletas tienen
los atributos: color, cantidad de cambios, dueño y métodos: acelerar, frenar,
pasar cambio, volver cambio.
Las
fábricas de bicicletas utilizan moldes para producir sus productos en serie, de
la misma forma en POO utilizaremos la clase bicicleta (molde) para producir sus
instancias (objetos).
Los
objetos son instancias de clases.
Ejemplo:
Podríamos tener la clase Perro, una instancia de esta clase podría ser el
objeto perro llamado "Chicho". La clase Perro especificaría que todos
los perros tendrían un nombre, color de pelo, una altura. Mientras que la
instancia "Chicho" contendrá valores específicos para cada uno de
estos atributos.
Podemos
definir a una clase como una plantilla que define variables y métodos comunes
para todos los objetos de cierto tipo.
Abstracción
La
abstracción consiste en aislar un elemento de su contexto o del resto de los
elementos que lo acompañan. En programación, el término se refiere al énfasis
en el "¿qué hace?" más que en el "¿cómo lo hace?"
(característica de caja negra). El común denominador en la evolución de los
lenguajes de programación, desde los clásicos o imperativos hasta los
orientados a objetos, ha sido el nivel de abstracción del que cada uno de ellos
hace uso.
Los
lenguajes de programación son las herramientas mediante las cuales los
diseñadores de lenguajes pueden implementar los modelos abstractos. La
abstracción ofrecida por los lenguajes de programación se puede dividir en dos
categorías: abstracción de datos (pertenecientes a los datos) y abstracción de
control (perteneciente a las estructuras de control).
Los
diferentes paradigmas de programación han aumentado su nivel de abstracción,
comenzando desde los lenguajes de máquina, lo más próximo al ordenador y más
lejano a la comprensión humana; pasando por los lenguajes de comandos, los
imperativos, la orientación a objetos (OO), la Programación Orientada a
Aspectos (POA); u otros paradigmas como la programación declarativa, etc.
Modularidad
En
programación modular, y más específicamente en programación orientada a
objetos, se denomina Modularidad a la propiedad que permite subdividir una
aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales
debe ser tan independiente como sea posible de la aplicación en sí y de las
restantes partes.
Estos
módulos que se puedan compilar por separado, pero que tienen conexiones con
otros módulos. Al igual que la encapsulación, los lenguajes soportan la
Modularidad de diversas formas.
Según
Bertrand Meyer "El acto de particionar un programa en componentes
individuales para reducir su complejidad en algún grado. . .. A pesar de
particionar un programa es útil por esta razón, una justificación más poderosa
para particionar un programa es que crea una serie de límites bien definidos y
documentados en el programa. Estos límites, o interfaces, son muy valiosos en
la comprensión del programa.
Encapsulamiento
En
programación modular, y más específicamente en programación orientada a
objetos, se denomina encapsulamiento al ocultamiento del estado, es decir, de
los datos miembro, de un objeto de manera que sólo se puede cambiar mediante
las operaciones definidas para ese objeto.
Cada
objeto está aislado del exterior, es un módulo natural, y la aplicación entera
se reduce a un agregado o rompecabezas de objetos. El aislamiento protege a los
datos asociados a un objeto contra su modificación por quien no tenga derecho a
acceder a ellos, eliminando efectos secundarios e interacciones.
Herencia
La
herencia es, después de la agregación o composición, el mecanismo más utilizado
para alcanzar algunos de los objetivos más preciados en el desarrollo de
software como lo son la reutilización y la extensibilidad. A través de ella los
diseñadores pueden crear nuevas clases partiendo de una clase o de una
jerarquía de clases preexistente (ya comprobadas y verificadas) evitando con
ello el rediseño, la modificación y verificación de la parte ya implementada.
La herencia facilita la creación de objetos a partir de otros ya existentes e
implica que una subclase obtiene todo el comportamiento (métodos) y
eventualmente los atributos (variables) de su superclase
Polimorfismo
En
programación orientada a objetos el polimorfismo se refiere a la capacidad para
que varias clases derivadas de una antecesora utilicen un mismo método de forma
diferente.
Por
ejemplo, podemos crear dos clases distintas: Pez y Ave que heredan de la
superclase Animal. La clase Animal tiene el método abstracto mover que se
implementa de forma distinta en cada una de las subclases (peces y aves se
mueven de forma distinta).
Como
se mencionó anteriormente, el concepto de polimorfismo se puede aplicar tanto a
funciones como a tipos de datos. Así nacen los conceptos de funciones
polimórficas y tipos polimórficos. Las primeras son aquellas funciones que
pueden evaluarse o ser aplicadas a diferentes tipos de datos de forma
indistinta; los tipos polimórficos, por su parte, son aquellos tipos de datos
que contienen al menos un elemento cuyo tipo no está especificado.
Suscribirse a:
Entradas (Atom)