análisis y diseño orientado a los objetivos para el sistema control de

Universidad Nacional Jorge Basadre Grohmann
Facultad de Ciencias
ANÁLISIS Y DISEÑO ORIENTADO A LOS
OBJETIVOS PARA EL SISTEMA CONTROL DE
EQUIPOS DE CÓMPUTO DE LA FACULTAD DE
CIENCIAS DE LA UNJBG, APLICANDO UML
Lic. Wilder Miñano Leon
Ing. Edgard Pilco Apaza
Tacna – Perú
2003
INTRODUCCIÓN
UML, emergió en los '90 luego de la búsqueda de un lenguaje
de modelamiento que unificara a la industria, que siguió a la
"guerra de métodos" de los '70 y '80. A pesar de que UML
evolucionó primeramente de varios métodos orientados al
objeto de segunda generación (en nivel de notación), UML no
es simplemente un lenguaje para modelamiento orientado al
objeto de tercera generación. Su alcance extiende su uso
más allá de sus predecesores. Y es la experiencia,
experimentación y una gradual adopción del estándar lo que
revelará su verdadero potencial y posibilitara a las
organizaciones darse cuenta de sus beneficios.
El UML es apropiado para una gran variedad de sistemas de
modelado de sistemas de información de empresas para
aplicaciones distribuidas basadas en Web aún más para
sistemas empotrados de tiempo real. Este es un lenguaje
muy expresivo, que abarca todos los panoramas necesarios
para desarrollar y estructurar tales sistemas. Para aprender a
usar UML adecuadamente se requiere aprender tres
elementos principalmente: los bloques de construcción
básicos, las reglas que dictan como esos bloques deben ser
relacionados y algunos mecanismos que aplica todo el tiempo
el lenguaje.
UML es un proceso independiente que óptimamente debe ser
usado en un proceso que es un manejador de caso de uso,
con arquitectura central, iterativa e incremental.
I. LENGUAJE DE MODELADO UNIFICADO (UML)
1.
EL LENGUAJE DE MODELADO UNIFICADO (UML)
Es un lenguaje de modelamiento estándar para la escritura
de proyectos de software.. UML puede ser usado para:
• Dentro de un proceso de sistema intensivo, un método
es aplicado para llegar o evolucionar un sistema
• • Como un lenguaje, es usado para la comunicación. Es
decir, un medio para capturar el conocimiento
(semánticas) respecto a un tema y expresar el
conocimiento (sintaxis) resguardando el tema propósito
de la comunicación. El tema es el sistema en estudio.
• Como un lenguaje para modelamiento, se enfoca en la
comprensión de un tema a través de la formulación de
un modelo del tema (y su contexto respectivo). El
modelo abarca el conocimiento cuidando del tema, y la
apropiada aplicación de este conocimiento constituye
inteligencia.
• Cuidando la unificación, integra las mejores prácticas
de la ingeniería de la industria tecnologica y sistemas
de información pasando por todos os tipos de sistemas
(software y no - software), dominios (negocios versus
software) y los procesos de ciclo de vida.
• En cuanto a cómo se aplica para especificar sistemas,
puede ser usado para comunicar "qué" se requiere de
un sistema y "cómo" un sistema puede ser realizado.
• En cuanto a cómo se aplica para visualizar sistemas,
puede ser usado para describir visualmente un sistema
antes de ser realizado.
• En cuanto a cómo se aplica para construir sistemas,
puede ser usado para guiar la realización de un sistema
similar a los "planos".
• En cuanto a cómo se aplica para documentar sistemas,
puede ser usado para capturar conocimiento respecto a
un sistema a lo largo de todo el proceso de su ciclo de
vida.
UML no es:
• Un lenguaje de programación visual, sino un lenguaje
de modelamiento visual
• Una herramienta o deposito de especificación, sino un
lenguaje para modelamiento de especificación.
• Un proceso, sino que habilita procesos.
Fundamentalmente, UML está relacionado con la captura,
comunicación y nivelación (disgregación en niveles) de
conocimientos.
2.
EL UML ES UN LENGUAJE
Un lenguaje que proporciona un vocabulario y las reglas para
combinar las palabras de ese vocabulario para la
comunicación. Un lenguaje de modelado es un lenguaje cuyo
vocabulario y reglas se enfocan en la representación
conceptual y física de un sistema. Un lenguaje de modelado
tal como UML es así un lenguaje estándar para proyectos de
software.
El modelado permite entender un sistema. Ninguno es
suficiente. Mejor dicho, frecuentemente necesitas múltiples
modelos que son conectados a algún otro en orden para
entender hasta lo más trivial del sistema.
El vocabulario y las reglas de un lenguaje tal como UML nos
dicen como crear y leer modelos bien formados, pero no nos
dicen que modelos debes crear y cuando debes crearlos. Un
proceso bien definido te guía en decidir que componentes
producir, que actividades y que trabajadores usar para
crearlos y manejarlos y como usar esos componentes para
validar y controlar el proyecto como tal.
a)
El UML es un lenguaje para visualización
Para muchos programadores la distancia entre el
pensamiento de una implementación y convertirlo en
código es casi nulo. Tú lo piensas, tú lo codificas. De
hecho, algunos objetos son mejor descritos directamente
en código. El texto es una forma maravillosamente
mínima y directa para escribir expresiones y algoritmos.
En tal caso el programador se detiene a hacer un
modelado aunque totalmente mental. El debe esbozar
sus ideas en un pizarrón o en una servilleta si es posible.
No obstante hay muchos problemas con esto. Primero,
comunicando esos modelos conceptuales a otros es
probable un error al menos que cada uno implique
expresar el mismo lenguaje. Típicamente los proyectos y
organizaciones desarrollan sus propios lenguajes y este
es difícil de entender por una persona ajena o nueva en
el grupo. Segundo, hay algunas cosas acerca de un
sistema de software que no puedes entender al menos
que construyas modelos que trasciendan el lenguaje de
programación textual. Por ejemplo, el significado de una
jerarquía de clase puede ser deducida pero no totalmente
comprendido fijando la atención en el código para todas
las clases en la jerarquía. Tercero, si el desarrollador,
quien deja de hacer el código, nunca escribió los modelos
que estaban dentro de su cabeza, esta información podría
ser perdida para siempre.
Los modelos escritos en UML enfocan el tercer problema:
Un modelo explícito facilita la comunicación.
Algunas cosas son mejor modelados textualmente, otros
son mejor modelados gráficamente. En todos los
sistemas interesantes hay estructuras que trascienden
que pueden ser representadas en un lenguaje de
programación El UML como tal, es un lenguaje gráfico.
Este enfoca el segundo problema descrito fácilmente.
El UML es más que un gran número de símbolos gráficos.
Mejor dicho, detrás de cada símbolo de la notación de
UML hay una semántica bien definida. De esta forma, un
desarrollador puede escribir un modelo en el UML y otro
desarrollador aun con otra herramienta puede interpretar
ese modelo no ambiguamente. Este direcciona el primer
problema descrito fácilmente.
b) El UML es un lenguaje para especificación
En este contexto, especificación significa modelos de
construcción que son precisos, no ambiguos y completos.
En particular, el UML direcciona la especificación de todas
las decisiones importantes de análisis, diseño e
implementación que deben ser hechas para el desarrollo
y estructuración de un sistema de software extenso.
c)
El UML es un lenguaje para construcción
El UML no es lenguaje de programación visual, pero su
modelo puede ser directamente conectado a una variedad
de lenguajes de programación. Esto significa que es
posible mapear de un modelo de UML a un lenguaje de
programación tal como Java, C++, Visual Basic, o aún
más, a tablas en una base de datos relacional el
almacenamiento persistente de una base de datos
orientada a objetos. Las cosas que son mejor expresados
gráficamente son hechas en UML, mientras que los que
son mejor expresados textualmente en el lenguaje de
programación.
Este mapeo permite avances de ingeniería: La generación
de un código dentro de un lenguaje de programación. La
inversa también es posible. La ingeniería inversa requiere
de herramientas de soporte con intervención humana.
En resumen, UML es suficientemente expresivo y no
ambiguo para permitir la ejecución directa de los modelos
la simulación de sistemas y la instrumentación de
sistemas de ejecución.
d) El UML es un lenguaje para documentación
Una buena organización de software produce todos los
tipos de componentes para el código ejecutable. Estos
componentes incluyen (pero no están limitados):
• Requerimientos
• Arquitectura
• Diseño
• Código fuente
• Planes del proyecto
• Pruebas
• Prototipos
• Revisiones (Releases)
Dependiendo de la cultura de desarrollo, alguno de estos
componentes son más o menos formal que otros. Tales
componentes no son solo la deliberación de un proyecto,
son también indispensables para controlar, validar y
comunicar un sistema antes de su desarrollo y después
de su estructuración.
El UML proporciona direcciona la documentación de una
arquitectura de un sistema y todos sus detalles. También
proporciona un lenguaje para requerimientos y
preguntas. Finalmente, UML proporciona un lenguaje
para modelar las actividades de planeación del proyecto y
manejo de revisiones.
3.
DÓNDE PUEDE SER USADO EL UML
El UML es contemplado primeramente para sistemas de
software intensivos. Este ha sido usado efectivamente
campos como:
•
•
•
•
•
•
•
•
•
Sistemas de información de empresas
Servicios de banco y financieros.
Telecomunicaciones
Transportación
Defensa/aeroespacio
Ventas
Electrónica médico
Científicos
Servicios basados en Web
UML no está limitado a modelado de software. De hecho este
es suficiente expresivo para modelar sistemas de no
software, tal como el diseño de hardware y sistemas para
determinar la salud de un paciente.
4.
UN MODELO CONCEPTUAL DEL UML
Para entender UML necesitas formar un modelo conceptual
del lenguaje y este requiere aprender tres elementos
principalmente. Los bloques de construcción básicos, las
reglas que dictan como esos bloques pueden ser combinados
y algunos mecanismos que se aplican todo el tiempo en UML.
a)
Bloques de construcción de UML
El vocabulario de UML que comprende tres tipos de
bloques de construcción: Elementos (Cosas), Relaciones
y
Diagramas.
i. Elementos: son las abstracciones que son ciudadanas
de primera clase en un modelo, las relaciones ligan
estos elementos entre sí; el grupo de diagramas
comparte colecciones de estos elementos. Hay cuatro
tipos de Elementos en UML:
ª Elementos Estructurales:
Los Elementos estructurales, son los sustantivos de
los modelos de UML. Estos son en la mayoría partes
estáticas de un modelo, representando elementos
que o bien conceptuales o físicos. Hay siete tipos de
elementos
estructurales:
Clases,
interfaz,
Colaboración, Caso de uso, Clases activas,
Componente, nodo.
ª Elementos de comportamiento(behavioral)
Son las partes dinámicas de los modelos UML. Estos
son los verbos de un modelo que rerpesentan la
función sobre tiempo y espacio. De hecho, hay dos
tipos principales de Elementos de comportamiento
nombrados de interacción y máquina de estado.
ª Elementos de Agrupamiento
Son las partes de organización de los modelos UML.
Estos son cajas dentro de las cuales un modelo
puede ser descompuesto. Hay un tipo principal de
Elementos de agrupamiento nombrados paquetes.
ª Elementos de Anotacionales.
Son las partes explicativas de los modelos de UML.
Son los comentarios que se pueden aplicar para
describir, iluminar y remarcar algunos elementos de
un modelo. Hay un tipo principal de Elementos
anotacionales llamado nota.
ii. Relaciones: Se usan para escribir modelos bien
formados, existen cuatro tipos de relaciones en UML:
Dependencias, Asociación, Generalización, Realización.
iii. Diagramas: Es la representación gráfica de un
conjunto
de
elementos,
más
frecuentemente
representados como una gráfica conectada de
vértices(objetos) y arcos(relaciones). Los diagramas
se utilizan para visualizar un sistema desde diferentes
perspectivas. Así, un diagrama es una proyección de
un sistema. Un diagrama representa un panorama de
los elementos que integran un sistema. Los mismos
elementos pueden aparecer en todos los diagramas,
sólo en una parte de los diagramas o en
ninguno(raramente sucede). En teoría un diagrama
puede contener alguna combinación de objetos y
relaciones. UML incluye nueve tipos de diagramas:
• Diagramas de clases
• Diagramas de objetos
• Diagramas de casos de uso
• Diagramas de secuencia
• Diagramas de colaboración
• Diagramas de estado
•
•
•
Diagramas de actividad
Diagramas de componente
Diagrama de estructuración(deployment)
b) Reglas de UML
Los bloques de construcción no pueden ser modelados a
la vez en forma aleatoria. UML tiene un conjunto de
reglas que un modelo bien formado debe contemplar. Un
modelo bien formado es aquel que es semánticamente
consistente en sí mismo y en armonía con sus modelos
relacionados.
UML tiene reglas de semántica para:
• Nombres :Cómo llamar a los Elementos, relaciones
y diagramas.
• Alcance : El contexto que da un significado
específico a un nombre.
• Visibilidad. Cómo esos nombres pueden ser vistos y
usados por otros.
• Integridad: Cómo los Elementos se relacionan
adecuadamente y consistentemente con otros
• Ejecución: Qué significa correr y simular un modelo
dinámico.
Es común que un desarrollador construya no sólo
modelos que son bien formados, sino también modelos
que sean:
•
•
•
Omitidos(Elided): ciertos elementos son ocultos
para simplificar Vista.
Incompletos: Ciertos elementos pueden ser
olvidados.
Inconsistentes: La integridad de un modelo no es
garantizada.
Las reglas de UML te alientan, pero no forzan a
direccionar los aspectos más importantes de análisis,
diseño e implementación para que los modelos lleguen a
ser bien formados con respecto al tiempo.
c)
Mecanismos comunes de UML
UML cuenta con cuatro mecanismos comunes que se
aplican consistentemente todo el tiempo en el lenguaje.
• Especificaciones
•
•
•
5.
Adornos(Adornments)
Divisiones comunes
Mecanismos de extensibilidad.
ARQUITECTURA DE SOFTWARE CON UML
La visualización, especificación construcción y documentación
de un sistema de software requiere que el sistema sea
enfocado desde diferentes perspectivas. Diferentes personas
- usuarios finales, analistas, desarrolladores, integradores del
sistema, escritores técnicos y manejadores de proyectoscada uno aporta diferentes agendas a un proyecto y cada
uno ve el sistema de diferentes formas, a diferente tiempo
durante el ciclo de vida del proyecto. Una arquitectura del
sistema es quizás el artefacto que puede ser usado para
manejar los diferentes puntos y así controlar el desarrollo
iterativo e incremental de un sistema durante su ciclo de
vida.
La arquitectura es el conjunto de decisiones significativas
acerca de:
• La organización de un sistema de software
• La selección de los elementos estructurales y sus
interfaces mediante las cuales se compone el sistema.
• Sus funciones, especificada en la s colaboraciones
entre estos elementos.
• La composición de estos elementos estructural y
funcionalmente para subsistemas progresivamente más
largos.
• El estilo de arquitectura que guía esta organización: los
elementos estáticos y dinámicos sus interfaces,
colaboraciones y composiciones.
La arquitectura de software no sólo contempla la estructura y
desempeño, sino también usos, funcionalidad, desempeño,
elasticidad, reuso, compresibilidad, contratos económicos y
tecnológicos y todo lo que concierne a estética.
En la figura siguiente se ilustra como la arquitectura de un
sistema de software puede ser descrito desde cuatro puntos
de vistas, cada vista es una proyección dentro de la
organización y estructura del sistema, enfocándose en
general a aspectos de ese sistema.
•
Vista de caso de uso de un sistema enfoca los casos de
uso que describe el desempeño del sistema tal como lo
ven los usuarios finales, analistas y ensayistas. Existe
para especificar las fuerzas que comparte la
arquitectura de un sistema. En UML los aspectos
estáticos dentro de este panorama son capturados en
diagramas de caso de uso y los dinámicos en este
panorama son capturados en diagramas de iteracción,
de estado y de actividad.
•
Vista de diseño de un sistema abarca las clases,
interfaces, y colaboraciones que forman el vocabulario
del problema y su solución. Este panorama
principalmente soporta los requerimientos funcionales
del sistema, es decir, los servicios que el sistema debe
proporcionar a sus usuarios. En UML el aspecto estático
de este panorama es capturado en los diagramas de
clases y los de objeto, el aspecto dinámico de este
punto de vista son capturados en los diagramas de
iteracción, diagramas de estado y de actividad.
•
Vista de proceso de un sistema enfoca los hilos de
control y procesos que conforman los mecanismos de
concurrencia
y
sincronización.
Principalmente,
direcciona el desempeño, escalabilidad y duración del
sistema.
•
Vista de implementación de un sistema comprende los
componentes y archivos que son usados para
ensamblar y liberar el sistema físico. Este panorama
direcciona principalmente el manejo de configuración
de la liberación del sistema. con UML el aspecto
estático de este panorama es capturado en diagramas
de componentes; y el aspecto dinámico es capturado
en los diagramas de interacción de estado y actividad.
•
6.
Vista de instalación(deployment) de un sistema
comprende los nodos forman la topología de hardware
del sistema dentro de las cuales el sistema se ejecuta.
Direcciona principalmente la distribución, entrega e
instalación de las partes que lleva a cabo el sistema
físico. En UML el aspecto estático es capturado en los
diagramas de estructura y el dinámico en los
diagramas de interacción, estado y actividad.
CICLO DE VIDA DEL DESARROLLO DEL SOFTWARE
El UML es un proceso independiente, lo que significa que no
requiere un ciclo de vida de desarrollo de software particular.
Para obtener los mejores beneficios de UML se deben
considerar un proceso que es:
• Un manejado por casos de uso
• Centrado en la arquitectura (enfocada a)
• Iterativo e incremental
Manejado por caso de uso significa que los casos de uso son
usados principalmente como una herramienta para
establecer el funcionamiento deseado del sistema, para
verificación y validación de la arquitectura del sistema,
prueba y comunicación entre las personas del proyecto.
Un proceso iterativo es aquel que involucra el manejo de un
flujo de liberaciones ejecutables. Un proceso incremental es
aquel que involucra la integración continua de la arquitectura
del sistema para producir esos releases. Con cada nuevo
release se incluyen mejoras incrementales sobre el otro.
Este manejo de caso de uso, centrado en arquitectura y los
procesos iterativos incrementales pueden dividirse en fases.
Una fase es la duración de tiempo dos cálculos del proceso,
cuando un conjunto de objetivos es conocido, los artefactos
son completados y las decisiones realizadas para llevar a
cabo la próxima fase. Hay cuatro fases en el ciclo de vida del
desarrollo del software: Conceptualización (inception),
elaboración, construcción y transición.
La conceptualización es la primera fase del proceso, cuando
se tiene la idea para el desarrollo lleva al punto lo
suficientemente bien fundamentado para garantizar por
completo la fase de elaboración.
La elaboración es cuando la visión del producto y su
arquitectura son definidos. En este punto los requerimientos
del sistema son articulados, prioritizados y referenciados.
La construcción es la fase cuando el proceso de software que
lleva a cabo la arquitectura ejecutable para que este lista
para ser transportada al ambiente del usuario. Aquí también
los requerimientos del sistema y su evaluación son
constantemente reexaminados.
La transición es la fase donde el software es turnado a las
manos del usuario. Durante esta fase el sistema es
continuamente mejorado.
II.
ESTRUCTURA DE UML
1.
ELEMENTOS EN UML
a) Elementos Estructurales:
i. Clases.- Es una descripción de un conjunto de objetos
que comparten los mismos atributos, operaciones,
relaciones y semánticas. Una clase lleva a cabo una o
más interfaces.
Gráficamente, una clase es representada con un
rectángulo, usualmente incluyendo su nombre,
atributos y operaciones.
Ejemplo:
Identidad
Persona
...
Atributos
...
Nombre
Edad
Operaciones
void leerdatos(void)
void verdatos(void)
ii. Interfaz.- Es una colección de operaciones
que
especifican un servicio de una clase o componente.
Así, una interfaz describe el desempeño externamente
visible de ese objeto. Una interfaz puede representar
el funcionamiento completo de una clase o
componente o solo una parte de ese desempeño. Una
interfaz define un conjunto de especificaciones, pero
nunca un conjunto de implementaciones de operación.
Gráficamente una interfaz se representa con un círculo
junto con su nombre. Una interfaz raramente es única.
Mejor dicho, esta es típicamente agregada a las clases
o componentes que realizan la interfaz.
Ejemplo:
Nombre_Interfaz
Información Segura
iii. Colaboración.- Define una iteracción y es una
sociedad de roles y otros elementos que trabajan a la
vez para proporcionar algunas funciones cooperativas
que son mayores que la suma de todos los elementos.
Una clase dada puede participar en diversas
colaboraciones. Estas colaboraciones representan la
implementación de patrones que integran un sistema.
Gráficamente, una colaboración se representa con una
elipse líneas punteadas, usualmente incluyendo sólo
su nombre.
Ejemplo:
Nombre
Colaboración
Cadena de
Responsabilidad
iv. Caso de uso.- Es una descripción de un conjunto de
secuencias de acciones que un sistema desempeña
para permitir un resultado de valor observable para un
actor particular. Un caso de uso es usado para
estructurar
los
elementos
de
comportamiento(behavioral) de un modelo.
Gráficamente, un caso de uso se representa con una
elipse de líneas sólidas, usualmente incluyendo sólo su
nombre.
Ejemplo:
Nombre
Caso de Uso
Realizar Pedido
v. Clases activas.- Es una clase cuyos objetos
reconocen uno o más procesos o hilos y por lo tanto
pueden iniciar una actividad de control. Una clase
activa es semejante a una clase excepto que sus
objetos representan elementos cuya función es
concurrente con otros elementos.
Gráficamente una clase activa se representa
semejante a una clase pero con líneas más anchas,
usualmente incluyendo su nombre, atributos y
operaciones
Ejemplo:
Identidad Clase Activa
Manejador de Eventos
…
Atributos
Suspender( )
Activar(
)
vi. Componente.- Es un una parte física
y reemplazable
Operaciones
de un sistema que conforma y proporciona la
realización de un conjunto de interfaces. En un
sistema encontrarás diferentes tipos de componentes
que son artefactos de procesos de desarrollo, tal como
los archivos de código fuente. Un componente
típicamente representa el empaquetado físico de
diferentes elementos lógicos tal como clases,
interfaces, y colaboraciones.
Gráficamente, un componente es representado por un
rectángulo con pestañas (tabuladores), usualmente
incluyendo sólo su nombre.
Ejemplo:
Busqueda.cpp
Nombre
vii. Nodo.- Es un elemento físico que existe al tiempo de
ejecución y representa un recurso computacional,
generalmente tiene al menos una memoria y
frecuentemente capacidad de procesamiento. Un
conjunto de componentes puede residir en un nodo y
puede también emigrar de un nodo a otro.
Gráficamente un nodo es representado por un cubo
incluyendo usualmente sólo su nombre
Ejemplo:
Server
Nombre
PV
b) Elementos de comportamiento(behavioral)
i. Interacción.- Es una función que comprende un
conjunto de intercambio de mensajes entre un conjunto
de objetos con un contexto particular para lograr un
propósito específico. La función de una asociación de
objetos o de una operación individual puede ser
especificada con una interacción. Una interacción
involucra un número de otros elementos incluyendo
mensajes, secuencias de acción (la función invocada
por un mensaje), ligas (la conexión entre objetos).
Gráficamente un mensaje se representa con una línea
dirigida incluyendo sólo el nombre de su operación.
Visualizar
ii. Máquina de Estados.- Es una función que especifica
la secuencia de estados de un objeto o una interacción
dada durante su tiempo de vida en respuesta a
eventos, junto con las respuestas de esos eventos. La
función de una clase individual o una colaboración de
clases puede ser especificada con una máquina de
estados. Una máquina de estados involucra otros
elementos incluyendo estados, transiciones(el flujo de
un estado a otro), eventos y actividades.
Gráficamente un estado se representa con un
rectángulo redondeado, incluyendo usualmente su
nombre y sus subestados si hay alguno.
Ejemplo:
Nombre
c)
Esperando
Elementos de Agrupamiento
i. Paquetes.- Es un mecanismo de propósito general
para la organización de elementos en grupos. Los
Elementos estructurales, funcionales y aun los de
agrupación pueden estar situados dentro de un
paquete. A diferencia de los componentes (los cuales
existen al tiempo de ejecución) un paquete es
puramente conceptual (significa que existe durante el
tiempo de desarrollo).
Gráficamente un paquete se representa con un folder
tabulado incluyendo usualmente su nombre y en
ocasiones su contenido.
Ejemplo:
Nombre o elementos
Reglas de Negocio
d) Elementos Anotacionales
i. Notas.- Es simplemente un símbolo para representar
las limitaciones y comentarios asociados a un
elemento o una colección de elementos.
Gráficamente una nota se representa con un
rectángulo con una esquina doblada, junto con un
comentario textual o gráfico
Ejemplo:
Texto
2.
Retornar copia así
mismo
RELACIONES EN UML
a) Dependencias.- Es una relación semántica entre dos
Elementos tal que un cambio en un thing (el
independiente) puede afectar al otro(el dependiente).
Gráficamente una dependencia se representa con una
línea punteada posiblemente dirigida y ocasionalmente
incluye una etiqueta.
b) Asociación.- Es una relación estructural que describe un
conjunto de ligas. Una liga es una conexión entre
objetos.
Gráficamente una asociación es representada con una
línea sólida posiblemente dirigida, ocasionalmente incluye
una etiqueta y frecuentemente contiene otros adornos tal
como multiplicidad y nombres de roles.
0...1
Empresarios
c)
*
Empleados
Generalización.es
una
relación
especialización/generalización en la cual los objetos del
elemento especializado(el hijo) son sustituidos por
elementos del elemento generalizado(el padre). De esta
forma,
el
hijo
comparte la estructura y función del
padre.
Gráficamente una relación de generalización es
representada con una línea sólida con una flecha vacía
hacia el padre.
d) Realización.-
Es una relación semántica entre
clasificadores(classifiers) donde un clasificador especifica
un contrato que otro clasificador garantiza llevar a cabo.
Las relaciones de realización se encuentran en dos
partes: entre interfaces y las clases componentes que las
realizan y entre casos de uso y las colaboraciones que las
realizan. Gráficamente una relación de realización se
representa por un híbrido entre una relación de
generalización y una de dependencia.
3.
DIAGRAMAS EN UML
a) Diagramas de clases.- Un diagrama de clases sirve
para visualizar las relaciones entre las clases que
involucran el sistema, las cuales pueden ser asociativas,
de herencia, de uso y de contenido. Estos diagramas son
los más comunes del modelado de sistemas orientados a
objetos. Direccionan la vista de diseño estático del
sistema. Un diagrama de clases esta compuesto por los
siguientes elementos:
• Clase: atributos, métodos y visibilidad.
• Relaciones: Herencia, Composición, Agregación,
Asociación y Uso.
CLASES:
En UML, una clase es representada por un rectángulo que
posee tres divisiones:
Contiene el nombre de la
Clase
Contiene los atributos (o
variables de instancia) que
caracterizan a la Clase
(pueden
ser
private,
protected o public).
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).
Atributos: Son las características de una Clase y pueden
ser de tres tipos, los que definen el grado de
comunicación y visibilidad de ellos con el entorno, estos
son:
public (+,
): Indica que el atributo será visible
tanto dentro como fuera de la clase, es decir, es
accsesible desde todos lados.
private (-,
): Indica que el atributo sólo será
accesible desde dentro de la clase (sólo sus métodos
lo pueden accesar).
): Indica que el atributo no será
protected (#,
accesible desde fuera de la clase, pero si podrá ser
accesado por métodos de la clase además de las
subclases que se deriven.
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 accesar).
): Indica que el método no será
protected (#,
accesible desde fuera de la clase, pero si podrá ser
accesado por métodos de la clase además de
métodos de las subclases que se deriven.
RELACIONES ENTRE CLASES:
En UML, la cardinalidad de las relaciones indica el grado y
nivel de dependencia, se anotan en cada extremo de la
relación y éstas pueden ser:
• uno o muchos: 1..* (1..n)
• 0 o muchos: 0..* (0..n)
• número fijo: m (m denota el número).
Herencia (Especialización/Generalización):
Indica que una subclase hereda los métodos y atributos
especificados por una Super Clase, por ende la Subclase
además de poseer sus propios métodos y atributos,
poseerá las características y atributos visibles de la Super
Clase (public y protected).
Ejemplo:
Agregación:
Para modelar objetos complejos, no bastan los tipos de
datos básicos que proveen los lenguajes: enteros, reales
y secuencias de caracteres. Cuando se requiere
componer objetos que son instancias de clases definidas
por el desarrollador de la aplicación, tenemos dos
posibilidades:
Por Valor: Es un tipo de relación estática, en donde
el tiempo de vida del objeto incluido esta
condicionado por el tiempo de vida del que lo incluye.
Este tipo de relación es comunmente llamada
Composición (el Objeto base se construye a partir
del objeto incluido, es decir, es "parte/todo").
Por Referencia: Es un tipo de relación dinámica,
donde el tiempo de vida del objeto incluido
independiente del que lo incluye. Este tipo
relación es comunmente llamada Agregación
objeto
base
utiliza
al
incluido
para
funcionamiento).
• La composición (por Valor) se destaca por
rombo relleno.
• La agregación (por Referencia) se destaca por
rombo transparente.
• La flecha en este tipo de relación indica
navegabilidad del objeto referenciado. Cuando
existe este tipo de particularidad la flecha
elimina.
en
es
de
(el
su
un
un
la
no
se
Ejemplo:
Un
Almacen
posee Clientes y
Cuentas
(los
rombos van en el
objeto que posee
las referencias).
Cuando
se
destruye
el
Objeto Almacen
también
son
destruidos
los
objetos Cuenta
asociados,
en
cambio no son
afectados
los
objetos Cliente
asociados.
Asociación:
La relación entre clases conocida como Asociación,
permite asociar objetos que colaboran entre si. Cabe
destacar que no es una relación fuerte, es decir, el
tiempo de vida de un objeto no depende del otro.
Ejemplo:
Un cliente puede
tener
asociadas
muchas Ordenes
de Compra, en
cambio una orden
de compra solo
puede
tener
asociado
un
cliente.
Dependencia o Instanciación (uso):
Representa un tipo de relación muy particular, en la que
una clase es instanciada (su instanciación es dependiente
de otro objeto/clase). Se denota por una flecha
punteada.
El uso más particular de este tipo de relación es para
denotar la dependencia que tiene una clase de otra, como
por ejemplo una aplicación grafica que instancia una
ventana (la creación del Objeto Ventana esta
condicionado a la instanciación proveniente desde el
objeto Aplicacion):
Cabe destacar que el objeto creado (en este caso la
Ventana gráfica) no se almacena dentro del objeto que lo
crea (en este caso la Aplicación).
CASOS PARTICULARES:
Clase Abstracta:
Una clase abstracta se denota
con el nombre de la clase y de
los métodos con letra "itálica".
Esto indica que la clase
definida
no
puede
ser
instanciada
pues
posee
métodos abstractos (aún no
han sido definidos, es decir,
sin implementación). La única
forma
de
utilizarla
es
definiendo
subclases,
que
implementan
los
métodos
abstractos definidos.
Clase parametrizada:
Una clase parametrizada se
denota con un subcuadro en el
extremo superior de la clase,
en donde se especifican los
parámetros que deben ser
pasados a la clase para que
esta pueda ser instanciada. El
ejemplo más típico es el caso
de un Diccionario en donde
una llave o palabra tiene
asociado un significado, pero
en este caso las llaves y
elementos
pueden
ser
genéricos.
La
genericidad
puede venir dada de un
Template (como en el caso de
C++) o bien de alguna
estructura
predefinida
(especialización a través de
clases).
Ejemplo aplicativo:
Empresa
0..1
*
Oficina
* 0..1 Departamento
Nombre : String
*
dirección : String
telefono : Number
*
Director
Miembro
1..*
1
OficinaPrincipal
Persona
nombre : Nombre
IdEmpleado : Integer
cargo : String
ObtenerFoto : Foto()
obtenerVoz()
ObtenerInformacionDeContacto()
ObtenerRegistrosPersonales()
InformaciónDeContacto
dirección : String
Registro Personal
IdTasas
HistorialEmpleados
Salario
Iinformación
Segura
b) Diagramas
de objetos.- Muestra un conjunto de
objetos y relaciones. Representan instancias de los
objetos encontrados dentro de diagramas de clase. Estos
diagramas direccionan Vista de diseño estático o Vista de
proceso estático de un sistema tal como los diagramas de
clase pero desde la perspectiva de casos reales o
prototípicos.
Ejemplo:
C:Compañia
d1: Departamento
d2: Departamento
o1: Oficina
Nombre : “Ventas”
Nombre : “Compras”
Dirección = “Av. Sur”
Telefono = 919475
p1: Persona
Nombre : “Franco”
IdEmpleado = 254
Cargo = “Gerente”
c)
I1: InformaciónDeContacto
dirección : “Cono Sur este s/n”
Diagramas de casos de uso.- Muestra un conjunto de
casos de uso y actores (un tipo especial de clases) y sus
relaciones. El diagrama de casos de uso representa la
forma en como un Cliente (Actor) opera con el sistema en
desarrollo, además de la forma, tipo y orden en como los
elementos interactúan (operaciones o casos de uso). Un
diagrama de caso direcciona la vista de caso de uso
estática de un sistema.
Un diagrama de casos de uso consta de los siguientes
elementos:
• Actor.
• Casos de Uso.
• Relaciones de Uso, Herencia y Comunicación.
ELEMENTOS
Actor: Es un rol que un usuario juega con respecto al
sistema. Es importante destacar el uso de la palabra rol,
pues con esto se especifica que un Actor no
necesariamente representa a una persona en particular,
sino más bien la labor que realiza frente al sistema. Se
tiene los siguientes tipos de actores:
•
•
•
•
Principales: personas que usan el
sistema
Secundarios:
personas
que
mantienen
o
administran
el
sistema
Material externo: dispositivos
materiales imprescindibles que
forman parte del ámbito de la
aplicación y deben ser utilizados
Otros sistemas: sistemas con los
que el sistema interactúa
Caso de Uso: Es una operación/tarea
específica que se realiza tras una orden
de algún agente externo, sea desde una
petición de un actor o bien desde la
invocación desde otro caso de uso.
Relaciones de Uso, Herencia y Comunicación:
Asociación
Es el tipo de relación más básica que indica la
invocación desde un actor o caso de uso a otra
operación (caso de uso). Dicha relación se denota
con una flecha simple.
Dependencia o Instanciación
Es una forma muy particular de relación entre clases,
en la cual una clase depende de otra, es decir, se
instancia (se crea). Dicha relación se denota con una
flecha punteada.
Generalización
Este tipo de relación es uno de los más utilizados,
cumple una doble función dependiendo de su
estereotipo, que puede ser de Uso (<<uses>>) o de
Herencia (<<extends>>).
Este tipo de relación esta orientado exclusivamente para
casos de uso (y no para actores).
extends: Se recomienda utilizar cuando un caso de
uso es similar a otro (características).
uses: Se recomienda utilizar cuando se tiene un
conjunto de características que son similares en más
de un caso de uso y no se desea mantener copiada la
descripción de la característica.
De lo anterior cabe mencionar que tiene el mismo
paradigma en diseño y modelamiento de clases, en donde
esta la duda clásica de usar o heredar.
Ejemplo: El caso de una Máquina Recicladora:
Sistema que controla una máquina de reciclamiento de botellas,
tarros y jabas. El sistema debe controlar y/o aceptar:
• Registrar el número de ítems ingresados.
• Imprimir un recibo cuando el usuario lo solicita:
a. Describe lo depositado
b. El valor de cada item
c. Total
• El usuario/cliente presiona el botón de comienzo
• Existe un operador que desea saber lo siguiente:
a. Cuantos ítems han sido retornados en el día.
b. Al final de cada día el operador solicita un resumen
de todo lo depositado en el día.
• El operador debe además poder cambiar:
a. Información asociada a ítems.
b. Dar una alarma en el caso de que:
i.
Item se atora.
ii.
No hay más papel.
Como
una
primera
aproximación
identificamos
a los actores
que
interactúan
con
el
sistema:
Luego,
tenem
os que
un
Cliente
puede
Deposi
tar
Items
y
un
Operad
Sistema de
Máquina de
Reciclaje
or
puede
cambia
r
la
inform
ación
de un
Item o
bien
puede
Imprim
ir
un
inform
e:
Además,
podemos
notar que
un
item
puede ser
una
Botella, un
Tarro o una
Jaba.
Otro aspecto es la
impresión
de
comprobantes, que
puede
ser
realizada después
de depositar algún
item por un cliente
o bien puede ser
realizada
a
petición
de
un
operador.
Entonces, el diseño completo del diagrama Use Case es:
IV PROGRAMACIÓN ORIENTADA A OBJETOS
1. DEFINICIÓN DE BOOCH:
La POO es el método de implementación en el que los
programas se organizan como colecciones cooperativas de
objetos, cada uno de los cuales representa un ejemplar de
una clase y cuyas clases son miembros de una jerarquía de
clases unidas mediante relaciones de herencia.
Conclusiones:
• La unidad lógica de programación es el objeto.
• Los objetos tienen relaciones.
• Existen clases que agrupan conceptualmente los objetos.
• Las clases pertenecen a una jerarquía (son las clases las
que heredan y no los objetos).
Objeto:
Entidad que contiene los atributos que describen el estado de un
objeto del mundo real y las acciones que se asocian con el objeto
del mundo real.
Un objeto es designado con un nombre o un identificador.
OBJETO = DATOS + OPERACIONES
Los datos deberían estar ocultos en el objeto, y las operaciones
serían el interface del objeto con el exterior, pero estas
operaciones están encapsuladas en "cajas negras".
Notación:
Taylor
Yourdon/Coad
Nombre
Atributos
Métodos
Booch
Booch
Métodos y mensajes
Los objetos se comunican mediante llamadas a
funciones_miembro o métodos: se dice entonces que "un objeto
envía un mensaje a otro objeto".
El mensaje es la acción realizada por un objeto mediante la cual
se invoca un método.
Componentes del mensaje:
• Nombre del receptor del mensaje
• Método invocado
• Información necesaria para la ejecución del método
Resumiendo, mensaje es la activación de un objeto.
El conjunto de mensajes que puede recibir un objeto se conoce
como protocolo de un objeto.
Clases
Una clase es la descripción de un conjunto de objetos. Consta de
métodos y datos que resumen las características comunes de un
conjunto de objetos.
Muestra el comportamiento general de un grupo de objetos.
DISTINTOS OBJETOS = DISTINTAS CLASES
Un objeto se crea mediante el envío de un mensaje de
construcción a la clase.
Análogamente para la destrucción del objeto, la clase recibe un
mensaje de destrucción.
Un programa orientado a objetos se resume en 3 sucesos:
1) Creación de objetos cuando se necesitan, mediante un
mensaje de construcción a la clase.
2) Intercambio de mensajes entre objetos o entre usuario de
objeto y objeto (diferencia fundamental entre lenguajes POO
puros e híbridos).
3) Eliminar objetos cuando no se necesitan, mediante un
mensaje de destrucción a la clase.
Identificación de clases
Partiendo del enunciado de un problema:
1) Todos los nombres del enunciado son objetos a tener en
cuenta.
• Cosas tangibles ("coche")
• Roles o papeles ("empleado")
• Organizaciones ("empresa")
• Incidentes o sucesos ("liquidación")
• Interacciones o relaciones ("pedido")
2) Los atributos son las características individuales de cada
objeto, que serán extraídos de los adjetivos y complementos
del verbo que haya en el enunciado.
3) Los métodos serán los verbos del enunciado. Tipos de
método:
• Constructor
• Destructor
• Modificadores del estado
• Selectores (obtienen el estado del objeto: "visualizar")
• Mezcladores (ej. "sumar 2 números complejos")
• Cálculos o procesamientos
Herencia
Herencia es la capacidad de un objeto (clase) para utilizar las
estructuras y los métodos existentes en antepasados o
ascendientes.
Es la reutilización de código desarrollado anteriormente.
Cuando usamos herencia decimos que hacemos programación
por herencia: Definición de nuevos tipos a partir de otros con los
que comparten algún tipo de característica.
Tipos de herencia
Herencia simple: un tipo derivado se crea a partir de una única
clase base.
Figura
Rectángulo
Triángulo
Herencia múltiple: una clase tienen más de una ascendiente
inmediato.
Persona
Profesor
Investigador
Profesor
universitario
•
•
La herencia múltiple puede plantear 2 tipos de
problema:
La herencia repetida: ej.: "profesor universitario hereda
2 veces los atributos de persona"
Produce ambigüedad respecto a los atributos o los
métodos. En la clase base pueden haber atributos que
se llamen igual.
EscalaResolución-
-Escala
Sonido
Gráficos
-Resolución
Multimedia
Sólo 2 lenguajes incorporan herencia múltiple: Eiffel y
C++
Características de la herencia
• Anulación o sustitución: cuando redefino un método
heredado en la subclase, se dice que estoy anulando o
sustituyendo dicho método. Sería deseable una "herencia
selectiva": seleccionar lo que se requiere heredar es la
mejor forma de anulación.
• Sobrecarga: Propiedad que puede darse también sin
herencia. Es designar varios elementos (identificadores)
con el mismo nombre. No es anulación.
• Polimorfismo (sobrecarga con anulación) es la forma de
invocar a distintos métodos utilizando el mismo elemento
de programa.
Polimorfismo
Polimorfismo es invocar métodos distintos con el mismo mensaje
(ligadura en tiempo de ejecución).
Para ello es necesaria una jerarquía de herencia: una clase base
que contenga un método polimórfico, que es redefinido en las
clases derivadas (no anulado).
Se permite que los métodos de los hijos puedan ser invocados
mediante un mensaje que se envía al padre.
Este tipo de clase que se usa para implementar el polimorfismo
se conoce como clase abstracta.
Objetos Compuestos
Los objetos pueden contener a su vez objetos de otras clases
dentro de sí (esto es lo que da la potencia a la POO).
El contenido la mayoría de las veces no es el objeto en sí, sino
una referencia (puntero) al objeto; con la ventaja de que el
objeto contenido puede cambiar de contenido o posición sin
afectar al objeto que contiene.
El objeto contenido puede, además, estar en varios objetos a la
vez.
Al mismo tiempo que se crea un objeto, se crean los objetos que
contiene.
Lenguajes de POO
SIMULA
Se considera que SIMULA es el primer Lenguaje de
Programación Orientado a Objetos (en adelante LPOO), fue
diseñado por Kristen Nygaard y Ole Johan Dhal, del
Norwegan Computer Center (NCC). Se concibió para el
desarrollo de simulaciones de procesos industriales y científicos,
pero llegó a considerarse apto para desarrollar grandes
aplicaciones.
La
ya
•
•
•
•
•
•
versión SIMULA_67 tenía características de ALGOL_60, y
era casi un LPOO, con estas características:
Concepto de objeto (datos + operaciones)
Comunicación entre objetos (proceso de simulación)
Concepto de clase (estructura que agrupa el comportamiento
y características de varios objetos)
Concepto de herencia (heredar datos y métodos)
Fuertemente tipificado (comprobación de tipos en tiempo de
compilación)
Concepto de ligadura dinámica "polimorfismo" (tener
interfaces idénticos para activar diferentes propiedades.
Smalltalk
Más tarde surge el primer LPOO en sentido estricto:
Smalltalk_80, diseñado por Alan Kay y Adele Goldberg, de la
XEROX PARC. Además de ser considerado como primer LPOO es
el más puro (sólo tiene objetos, NO ES programación
estructurada)
Extensiones de Lenguajes Convencionales
C++ [1986]
Diseñado por Stroustrup, es un LPOO híbrido basado en C y
Smalltalk. Ha tenido mucho éxito.
Objetive C [1986]
Es una extensión de C. Hoy está en desuso. Surge para las
plataformas NeXT y fracasó junto a las máquinas NeXT.
Object Pascal [1987]
Extensión de Pascal, lo popularizó Borland con Turbo Pascal
5.5
Object COBOL [1992-3]
Extensión de COBOL, nuevo LPOO que parece haber tenido
aceptación.
Delphi [1995]
Proviene de Object Pascal, creado por Borland.
Extensiones de Lenguajes Funcionales
PROLOG++
CLOS
Common Lisp orientado a objetos
Lenguajes fuertemente tipificados
Ada_95
Ada_83 ya era casi un LPOO. Ada_95 sólo añade herencia y
ligadura dinámica.
Eiffel [1988]
Diseñado por Beltran Meyer, está aún en desarrollo.
Clasificación de Wegner de 1987
I. Lenguajes Basados en Objetos (LBO)
Son aquellos en los que la sintaxis y semántica del lenguaje
soporta la creación de objetos.
Ejemplos: Ada_83, Clipper 5.x, VisualBasic.
II. Lenguajes Basados en Clases (LBC)
Son LBO con capacidad de crear clases.
Ejemplo: CLU
III. Lenguajes Orientados a Objetos (LOO)
Son LBC con capacidad de herencia.
Ejemplos: C++, Object Pascal, etc...
Características de un LPOO
Tipificación fuerte: comprobación de tipos en tiempo de
compilación. Hay una excepción: Smalltalk.
1) Ocultación: de las características de los objetos.
2) Compilación Incremental: compilación separada.
3) Genericidad: reutilización de código.
4) Paso de mensajes.
5) Polimorfismo: basado en la ligadura dinámica.
6) Excepciones: sistema seguro.
7) Concurrencia: "el mundo real es concurrente".
8) Datos compartidos: entre varios objetos.
LPOO Puros vs. Híbridos
Ventajas
Puros
• Más potencia.
• Flexibilidad para
modificar el
lenguaje.
• Más fácil de
asimilar (enseñar).
Híbridos
• Más rápido.
• Más fácil el paso de
programación
estruc-turada a
POO.
• Implementación de
operacionesalgoritmos
fundamentales más
sencilla.
Inconvenientes
• Más lento.
• Trabaja con 2
• Implementación de
paradigmas a la
operacionesvez.
algoritmos
• Modificar el
lenguaje es difícil.
fundamentales muy
complicada.
Ada_95
Incorpora 2 nuevas características a Ada_83:
• Herencia
• Polimorfismo
Smalltalk_80
Características
• Todas las entidades que maneja Smalltalk son objetos.
• Todas las clases derivan de una clase base llamada Object.
• Existe herencia simple.
• Usa métodos y paso de mensajes.
• Tiene una tipificación débil: la comprobación de los tipos se
hace en tiempo de ejecución.
• Soporta concurrencia, pero pobre.
• Se comercializa con un conjunto de bibliotecas de clases
predefinidas, agrupadas en categorías o jerarquías (E/S,
etc...)
• Existe una versión, Smalltalk V para computadoras IBM.
• C++ y CLOS se han apoyado en características de
Smalltalk.
Eiffel
Es un lenguaje inspirado en SIMULA con características
añadidas de Smalltalk y Ada.
Se destina a aplicaciones de bases de datos e inteligencia
artificial. Por su diseño, es bueno para la ingeniería de software.
Características
• Fuertemente tipificado.
• Clases.
• Genericidad.
• Herencia múltiple.
• Ligadura dinámica y polimorfismo.
• Se ha empezado a implementar concurrencia y persistencia
de objetos.
•
Proporciona una biblioteca de clases predefinidas: Estructuras
de datos, E/S, E/S XWindow.
La memoria dinámica es gestionada por el entorno y no por el
sistema operativo: incorpora recogida automática de basura.
El entorno tiene editor, y Browser, que muestra las clases y
jerarquías.
El entorno proporciona recompilación automática.
Contrato entre proveedor y usuario de clases
Para que un método pueda ser ejecutado debe haber:
•
•
•
Una precondición
Una postcondición
Una invariante
Hay un contrato entre el proveedor (creador) de la clase y el
cliente (usuario): el proveedor asegura que la invariante se
cumple y que al finalizar la ejecución del método la postcondición
se cumplirá; pero sólo siempre y cuando la otra parte (el
usuario) cumpla la precondición.
REFERENCIAS BIBLIOGRÁFICAS
James; JACOBSON, Ivar; BOOCH, Grady: El Lenguaje
Unificado de Modelado: Manual de Referencia.
RUMBAUGH, James; JACOBSON, Ivar; BOOCH, Grady:
El Proceso Unificado de Desarrollo del Software.
LARMAN, Craig: UML y patrones: Introducción al análisis
y diseño orientado a objetos.