METODOLOGA

ORIENTADA A OBJETOS
El desarrollo de proyectos software ha sufrido una evolucin desde
los primeros sistemas de calculo, implementados en grandes
computadores simplemente ayudados mediante unas tarjetas
perforadas donde los programadores escriban sus algoritmos de
control, hasta la revolucin de los sistemas de informacin e
Internet. Han existido dos grandes cambios desde aquellos sistemas
meramente algortmicos donde todo el esfuerzo de desarrollo se
centraba en la escritura de programas que realizaran algn tipo de
calculo. El primero de ellos es la aparicin del modelo relacional, un
modelo con fuerte base matemtica que supuso el desarrollo las
bases de datos y propici la aparicin de los grandes sistemas de
informacin.
HISTORIA DE LAS METODOLOGAS DE DESARROLLO DE
SOFTWARE
El segundo cambio es sobre los lenguajes de programacin, la
aparicin de los Lenguajes Orientados a Objetos (aunque los
primero lenguajes con caractersticas de orientacin a objetos
aparecieron en la dcada de los setenta, por ejemplo Simula 67)
supuso una revolucin en la industria software. El problema
entonces radicaba en poder sacarle partido a los lenguajes
orientados a objetos por lo que aparecieron numerosas
metodologas para el diseo orientado objetos, hubo un momento
en el que se poda decir que el concepto de orientacin a objetos
estaba de moda y todo era orientado a objetos, cuando
realmente lo que ocurra es que las grandes empresas que
proporcionaban los compiladores y lenguajes de programacin
lavaban la cara" a sus compiladores, sacaban nuevas versiones que
adoptaran alguno de los conceptos de orientacin a objetos y los
vendan como orientados a objetos.
Para poner un poco de orden, sobre todo en lo que respecta a la
modelizacin de sistemas software, aparece UML (Unified
Modeling Languaje, Lenguaje Unificado de Modelado) que
pretende unificar las tres metodologas ms difundidas (OMT,
Bootch y OOSE) e intentar que la industria software termine su
maduracin como Ingeniera . Y lo consigue en tal manera que lo
que UML proporciona son las herramientas necesarias para poder
obtener los planos del software equivalentes a los que se utilizan
en la construccin, la mecnica o la industria aeroespacial. UML
abarca todas las fases del ciclo de vida de un proyecto, soporta
diferentes maneras de visualizacin dependiendo de quin tenga
que interpretar los planos y en que fase del proyecto se encuentre.
Lo que describiremos en este curso es una introduccin al diseo
orientado a objetos y que solucin aporta UML, explicando sus
caractersticas principales.
Para producir software que cumpla su propsito hay que obtener
los requisitos del sistema, esto se consigue conociendo de una
forma disciplinada a los usuarios y hacindolos participar de
manera activa para que no queden cabos sueltos. Para conseguir
un software de calidad, que sea duradero y fcil de mantener hay
que idear una slida base arquitectnica que sea flexible al cambio.
Para desarrollar software rpida y eficientemente, minimizando el
trabajo de recodificacin y evitando crear miles de lneas de cdigo
intil hay que disponer, adems de la gente y las herramientas
necesarias, de un enfoque apropiado.
MODELADO
Para conseguir, que a la hora de desarrollar software de manera
industrial se obtenga un producto de calidad, es completamente
necesario seguir ciertas pautas y no abordar los problemas de
manera somera, con el fin de obtener un modelo que represente lo
suficientemente bien el problema que hemos de abordar. El
modelado es la espina dorsal del desarrollo software de calidad. Se
construyen modelos para poder comunicarnos con otros, para
explicar el comportamiento del sistema a desarrollar, para
comprender, nosotros mismos, mejor ese sistema, para controlar el
riesgo y en definitiva para poder atacar problemas que sin el
modelado su resolucin seria imposible, tanto desde el punto de
vista de los desarrolladores (no se pueden cumplir los plazos
estimados, no se consigue ajustar los presupuestos...) como desde
el punto de vista del cliente, el cual, si finalmente se le entrega
el producto del desarrollo, se encontrar con infinidades de
problemas, desde que no se cumplen las especificaciones hasta
fallos que dejan inutilizado el sistema.
Cuando nos referimos al desarrollo software en el mbito
industrial, no se pretende que la capacidad de modelar se
reduzca a empresas que disponen de gran numero de
empleados o empresas que han de abordar proyectos
eminentemente grandiosos, si no que nos referimos a la
capacidad de obtener un producto comercial (sea cual sea
su coste o tamao) que cumpla lo que en la industria se
suele denominar como calidad total1 y que adems
pueda reportar beneficios a corto o medio plazo, evitando,
por ejemplo, implantaciones casi eternas debido a la falta
de previsin o al haber abordado los problemas muy a la
ligera.
Por todas estas razones es inevitable el uso de modelos. Pero, qu es un
modelo?. La respuesta es bien sencilla, un modelo es una simplificacin de la
realidad. El modelo nos proporciona los planos de un sistema, desde los ms
generales, que proporcionan una visin general del sistema, hasta los ms
detallados. En un modelo se han de incluir los elementos que tengan ms
relevancia y omitir los que no son interesantes para el nivel de abstraccin que se
ha elegido. A travs del modelado conseguimos cuatro objetivos:

Los modelos nos ayudan a visualizar cmo es o 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 guan en la construccin de
un sistema.

Los modelos documentan las decisiones que hemos adoptado.
PRINCIPIOS BSICOS DEL MODELADO
Existen cuatro principios bsicos, estos principios son fruto de la
experiencia en todas las ramas de la ingeniera.

a) La eleccin de qu modelos se creen influye directamente sobre cmo
se acomete el problema. Hay que seleccionar el modelo adecuado
para cada momento y dependiendo de que modelo se elija se
obtendrn diferentes beneficios y diferentes costes. En la industria
software se ha comprobado que un modelado orientado a objetos
proporciona unas arquitecturas ms flexibles y readaptables que otros
por ejemplo orientados a la funcionalidad o a los datos.

b) Todo modelo puede ser expresado a diferentes niveles de precisin. Esto
se refiere a, que es necesario poder seleccionar el nivel de detalle que se
desea ya que en diferentes partes de un proyecto y en diferentes etapas
se tendrn unas determinadas necesidades.

PRINCIPIOS BSICOS DEL MODELADO
c) Los mejores modelos estn ligados a la realidad. Lo principal es
tener modelos que nos permitan representar la realidad lo ms
claramente posible, pero no slo esto, tenemos que saber,
exactamente cuando se apartan de la realidad para no caer en la
ocultacin de ningn detalle importante.

d) Un nico modelo no es suficiente. Cualquier sistema que no sea
trivial se afronta mejor desde pequeos modelos casi
independientes, que los podamos construir y estudiar
independientemente y que nos representen las partes ms
diferenciadas del sistema y sus interrelaciones.
ORIENTACIN A OBJETOS
La programacin estructurada tradicional se basa
fundamentalmente en la ecuacin de Wirth:

Algoritmos + Estructuras de Datos = Programas

Esta ecuacin significa que en la programacin estructurada u
orientada a procedimientos los datos y el cdigo se trata por
separado y lo nico que se realiza son funciones o procedimientos
que tratan esos datos y los van pasando de unos a otros hasta que
se obtiene el resultado que se desea.
ORIENTACIN A OBJETOS
Podemos definir objeto como el "encapsulamiento de un conjunto de operaciones
(mtodos) que pueden ser invocados externamente, y de un estado que recuerda el efecto
de los servicios". [Piattini et al., 1996].

Un objeto adems de un estado interno, presenta una interfaz para poder interactuar con
el exterior. Es por esto por lo que se dice que en la programacin orientada a objetos "se
unen datos y procesos", y no como en su predecesora, la programacin estructurada, en la
que estaban separados en forma de variables y funciones.

Un objeto consta de:
Tiempo de vida: La duracin de un objeto en un programa siempre est limitada en el
tiempo. La mayora de los objetos slo existen durante una parte de la ejecucin del
programa. Los objetos son creados mediante un mecanismo denominado instanciacin, y
cuando dejan de existir se dice que son destruidos.
Estado: Todo objeto posee un estado, definido por sus atributos. Con l se definen las
propiedades del objeto, y el estado en que se encuentra en un momento determinado de
su existencia.

Comportamiento: Todo objeto ha de presentar una interfaz, definida por sus mtodos,
para que el resto de objetos que componen los programas puedan interactuar con l.
VENTAJAS DE LA ORIENTACIN A OBJETOS
Las ventajas ms importantes de la programacin orientada a objetos son las siguientes:

Mantenibilidad (facilidad de mantenimiento). Los programas que se disean utilizando el
concepto de orientacin a objetos son ms fciles de leer y comprender y el control de la
complejidad del programa se consigue gracias a la ocultacin de la informacin que
permite dejar visibles slo los detalles ms relevantes.

Modificabilidad (facilidad para modificar los programas). Se pueden realizar aadidos o
supresiones a programas simplemente aadiendo, suprimiendo o modificando objetos.

Resusabilidad. Los objetos, si han sido correctamente diseados, se pueden usar
numerosas veces y en distintos proyectos.

Fiabilidad. Los programas orientados a objetos suelen ser ms fiables ya que se basan en
el uso de objetos ya definidos que estn ampliamente testeados.
CONCEPTOS BSICOS DE LA ORIENTACIN A
OBJETOS
Clase: Es una descripcin de un conjunto de objetos similares. Por ejemplo la clase Coches.
Una clase contiene los atributos y las operaciones sobre esos atributos que hacen que una
clase tenga la entidad que se desea.









Nombre
Cada clase tiene un nombre que la distingue de las dems. Un
nombre es una cadena de texto. Se tienen:

Nombres simples: es el simple nombre. Por ejemplo: Cliente,
pared.

Nombres compuestos: consta del nombre de la clase precedido
por el nombre del paquete en el que se encuentra. Por ejemplo:
java::awt::Rectangle

Los nombres de las clases son sustantivos o frases cortas y
empiezan con una letra mayscula.









Atributos Es una propiedad de una clase identificada con un nombre, que
describe un rango de valores. Una clase puede tener: cualquier
nmero de atributos o ningn atributo. Un atributo representa alguna
propiedad del elemento que se est modelando.







Un atributo se puede especificar ms indicando su clase y su valor
inicial por defecto.









Operaciones Una operacin es una accin que se puede solicitar a cualquier
objeto de la clase. Las operaciones son los procesos que una clase
sabe cmo realizar.










Una operacin es una abstraccin de algo que se puede hacer a
un objeto y que son compartidos por todos los objetos de la clase.
Una clase puede tener cualquier nmero de operaciones o
ninguna. Las operaciones se pueden representar mostrando slo sus
nombres.



EJEMPLOS DE CLASES
Objeto: Un objeto es una cosa, generalmente extrada del vocabulario del espacio del
problema o del espacio de la solucin. Todo objeto tiene un nombre (se le puede
identificar), un estado (generalmente hay algunos datos asociados a l) y un
comportamiento (se le pueden hacer cosas a objeto y l puede hacer cosas a otros
objetos). Un objeto de la clase Coches puede ser un Ford Mustang.










Atributo: Es una caracterstica concreta de una clase. Por
ejemplo atributos de la clase Coches pueden ser el Color, el
Numero de Puertas...

Mtodo: Es una operacin concreta de una determinada clase.
Por ejemplo de la clase Coches podramos tener un mtodo
arrancar() que lo que hace es poner en marcha el coche.

Instancia: Es una manifestacin concreta de una clase (un
objeto con valores concretos). Tambin se le suele llamar
ocurrencia. Por ejemplo una instancia de la clase Coches puede
ser: Un Ford Mustang, de color Gris con 3 puertas

CONCEPTOS BSICOS DE LA ORIENTACIN A
OBJETOS
Herencia: Es un mecanismo mediante el cual se puede crear una nueva
clase partiendo de una existente, se dice entonces que la nueva clase
hereda las caractersticas de la clase existentes aunque se le puede aadir
ms capacidades (aadiendo datos o capacidades) o modificar las que
tiene. Por ejemplo supongamos que tenemos la VehiculosDeMotor. En
esta clase tenemos los siguientes atributos: Cilindrada y Numero de
Ruedas, y el mtodo acelerar(). Mediante el mecanismo de herencia
podemos definir la clase Coches y la clase Motos. Estas dos clases heredan
los atributos Cilindrada y Numero de Ruedas de la clase VehculosDeMotor
pero a su vez tendrn atributos propios (como hemos dicho antes el
Numero de Puertas es un atributo propio de la clase Coches que no tienen
sentido en la clase Motos). Se puede decir que Coches extiende la clase
VehculosDeMotor, o que VehculosDeMotor es una generalizacin de las
clases Coches y Motos.
La idea de las clases es tener un punto de referencia y describir las
similitudes o diferencias que un objeto especfico posee con
respecto a los miembros de su propia clase.
CONCEPTOS BSICOS DE LA ORIENTACIN A
OBJETOS
Polimorfismo: Hace referencia a la posibilidad de que dos mtodos
implementen distintas acciones, aun teniendo el mismo nombre,
dependiendo del objeto que lo ejecuta o de los parmetros que
recibe. En el ejemplo anterior tenamos dos objetos que heredaban
el mtodo acelerar() de la clase VehiculosDeMotor. De hecho en
clase VehiculosDeMotor al ser general no tiene sentido que tenga
una implementacin concreta de este mtodo. Sin embargo, en las
clases Coches y Motos si que hay una implementacin clara y
distinta del mtodo acelerar(), lo podemos ver en el cdigo fuente 1
y 2. De este modo podramos tener un objeto VehculosDeMotor,
llamado vdm, en el que residiera un objeto Coche. Si realizramos la
llamada vdm.acelerar() sabra exactamente que ha de ejecutar el
mtodo Coches::acelerar().
INTRODUCCIN A UML
UML es un lenguaje estndar que sirve para escribir los planos del
software, puede utilizarse para visualizar, especificar, construir y
documentar todos los artefactos que componen un sistema con
gran cantidad de software. UML puede usarse para modelar desde
sistemas de informacin hasta aplicaciones distribuidas basadas en
Web, pasando por sistemas empotrados de tiempo real. UML es
solamente un lenguaje por lo que es slo una parte de un mtodo
de desarrollo software, es independiente del proceso aunque para
que sea optimo debe usarse en un proceso dirigido por casos de
uso, centrado en la arquitectura, iterativo e incremental.

UML es un lenguaje por que proporciona un vocabulario y las reglas
para utilizarlo, adems es un lenguaje de modelado lo que significa
que el vocabulario y las reglas se utilizan para la representacin
conceptual y fsica del sistema.
INTRODUCCIN A UML
UML es un lenguaje que nos ayuda a interpretar grandes sistemas
mediante grficos o mediante texto obteniendo modelos explcitos
que ayudan a la comunicacin durante el desarrollo ya que al ser
estndar, los modelos podrn ser interpretados por personas que no
participaron en su diseo (e incluso por herramientas) sin ninguna
ambigedad. En este contexto, UML sirve para especificar, modelos
concretos, no ambiguos y completos.

Debido a su estandarizacin y su definicin completa no ambigua, y
aunque no sea un lenguaje de programacin, UML se puede
conectar de manera directa a lenguajes de programacin como Java,
C++ o Visual Basic, esta correspondencia permite lo que se
denomina como ingeniera directa (obtener el cdigo fuente
partiendo de los modelos) pero adems es posible reconstruir un
modelo en UML partiendo de la implementacin, o sea, la
ingeniera inversa.
VISTAS GENERALES DE UML
El lenguaje UML se compone de tres elementos bsicos, los bloques
de construccin, las reglas y algunos mecanismos comunes. Estos
elementos interaccionan entre s para dar a UML el carcter de
completitud y no-ambigedad que antes comentbamos.

Los bloques de construccin se dividen en tres partes: Elementos,
que son las abstracciones de primer nivel, Relaciones, que unen a
los elementos entre s, y los Diagramas, que son agrupaciones
interesantes de elementos.

Existen cuatro tipos de elementos en UML, dependiendo del uso
que se haga de ellos: elementos estructurales, elementos de
comportamiento, elementos de agrupacin y elementos de
anotacin.
VISTAS GENERALES DE UML
Las relaciones, a su vez se dividen para abarcar las posibles
interacciones entre elementos que se nos pueden presentar a la
hora de modelar usando UML, estas son: relaciones de
dependencia, relaciones de asociacin, relaciones de generalizacin
y relaciones de realizacin.

Se utilizan diferentes diagramas dependiendo de qu, nos interese
representar en cada momento, para dar diferentes perspectivas de
un mismo problema, para ajustar el nivel de detalle..., por esta
razn UML soporta un gran numero de diagramas diferentes
aunque, en la practica, slo se utilicen un pequeo nmero de
combinaciones.
ELEMENTOS ESTRUCTURALES
Los elementos estructurales en UML, en su mayora, son las partes estticas del modelo y
representan cosas que son conceptuales o materiales.

Clases
Una clase es una descripcin de un conjunto de objetos que comparten los mismos
atributos, operaciones, relaciones y semntica. Una clase implementa una o ms
interfaces. Grficamente se representa como un rectngulo que incluye su nombre, sus
atributos y sus operaciones.
DIAGRAMA DE CLASES
Ejemplo
Piense en las cosas que le rodean. Es probable que muchas de esas cosas tengan atributos
(propiedades) y que realicen determinadas acciones. Podramos imaginar cada una de esas
acciones como un conjunto de tareas.

Tambin se encontrar con que las cosas naturalmente se albergan en categoras
(automviles, mobiliario, lavadoras). A tales categoras las llamaremos clases. Una clase
es una categora o grupo de cosas que tienen atributos y acciones similares.
Por ejemplo: cualquier cosa dentro de la clase lavadora tiene atributos como son la marca,
el modelo, el nmero de serie y la capacidad. Entre las acciones de las cosas de esta clase
se encuentran: agregar ropa, agregar detergente, activarse y sacar ropa.
Qu objetivo tiene pensar en las clases, as como sus
atributos y acciones?
Para interactuar con nuestro complejo mundo. La mayora del
software moderno simula algn aspecto. Dcadas de experiencia
sugieren que es ms sencillo desarrollar aplicaciones que simulen
algn aspecto del mundo cuando el software representa clases de
cosas reales. Los diagramas de clases facilitan las representaciones a
partir de las cuales los desarrolladores trabajan.

A su vez, los diagramas de clases colaboran en lo referente al
anlisis. Permiten al analista hablarles a los clientes en su propia
terminologa. Lo cual hace posible que los clientes indiquen
importantes detalles de los problemas que requieren.
DIAGRAMA DE OBJETOS
Un objeto es una instancia de clase (una entidad que tiene valores
especficos de los atributos y acciones). Su lavadora, por ejemplo
podra tener la marca CENTRALES, el modelo M1, el nmero de
serie GL57774 y una capacidad de 7Kg.

El smbolo con el que UML representa a un objeto es muy similar al
de una clase, pero en este caso el nombre est subrayado. El
nombre de la instancia especfica se encuentra a la izquierda de los
dos puntos( : ), y el nombre de la clase a la derecha.
Un diagrama Uso-Caso describe lo que hace un sistema desde el
punto de vista de un observador externo, debido a esto, un
diagrama de este tipo generalmente es de los ms sencillos de
interpretar en UML, ya que su razn de ser se concentra en un Que
hace el sistema, a diferencia de otros diagramas UML que intentan
dar respuesta a un Como logra su comportamiento el sistema.
Un Uso-Caso esta muy relacionado con lo que pudiera ser
considerado un escenario en el sistema, esto es, lo que ocurre
cuando alguien interacta con el sistema: "Acude un mesero a
colocar la orden, la orden es tomada por el cocinero, y
posteriormente se abona a la cuenta del cliente el cargo".
DIAGRAMA DE CASOS DE USO
Un Uso-Caso es empleado con ms frecuencia en alguna de las
siguientes etapas :

Determinacin de Requerimientos: Por lo general nuevos
requerimientos de sistema generan nuevos usos-casos, conforme es
analizado y diseado el sistema.

Comunicacin con el Cliente: Debido a la sencillez de este tipo de
diagramas, son fciles de emplear para comunicarse con el cliente
final del proyecto.

Generacin de pruebas de Sistemas: A travs de los diagramas uso-
caso se pueden generar una serie de pruebas de sistema.
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
Un caso de uso es una descripcin de las acciones de un sistema
desde el punto de vista del usuario. Para los desarrolladores del
sistema, sta es una herramienta valiosa, ya que es una tcnica de
aciertos y errores para obtener los requerimientos del sistema
desde el punto de vista del usuario. Esto es importante si la finalidad
es crear un sistema que pueda ser utilizado por la gente en general
(no slo por expertos en computacin).
A la figura correspondiente al usuario de la lavadora se le conoce
como actor. La elipse representa al caso de uso. El actor que inicia
el caso de uso puede ser una persona u otro sistema.

DIAGRAMA DE ESTADOS
En cualquier momento, un objeto se encuentra en un estado en
particular. Una persona puede ser recin nacida, infante,
adolecente, joven o adulta. Un elevador se mover hacia arriba,
estar en estado de reposo o se mover hacia abajo. Una lavadora
podr estar en la fase de remojo. Lavado enjuague, centrifugado o
apagada.
El diagrama de estados intenta capturar esa realidad que sucede
dentro de un sistema mostrndonos los diferentes estados que se
presentan con las diferentes partes que lo conforma e interactuar
con l. La notacin para un diagrama de estados es la siguiente.
DIAGRAMA SECUENCIAS
Los diagramas de clases y objetos representan la informacin
esttica. No obstante, en un sistema funcional los objetos
interactan entre s y tales interacciones suceden con el tiempo. El
diagrama de secuencias UML muestra la mecnica de la interaccin
con base en tiempos.

Continuando con el ejemplo de la lavadora, entre los componentes
de la lavadora se encuentran: una manguera de agua (para obtener
agua fresca), un tambor (donde se coloca la ropa) y un sistema de
drenaje.

Qu suceder cuando el usuario invoqeu el caso de uso lavar ropa?
En este caso por lo menos sucederan 3 operaciones AGREGAR
ROPA, AGREGAR DETERGENTE Y ACTIVAR la secuencia sera ms
o menos la siguiente
DIAGRAMA SECUENCIAS
1. El agua empezar a llenar el tambor mediante una manguera
2. El tambor permanecer inactivo durante 5 minutos
3. La manguera dejar de abastecer agua
4. El tambor girar de un lado a otro durante 15 minutos
5. El agua jabonosa saldr por el drenaje
6. Comenzar nuevamente el abastecimiento de agua
7. El tambor continuar girando
8. El abastecimiento de agua se detendr
9. El agua del enjuague saldr por el drenaje
10. El tambor girar en una sola direccin y se incrementar su
velocidad por cinco minutos
11. El tambor dejar de girar y el proceso de lavado habr finalizado

DIAGRAMA DE ACTIVIDADES
Un diagrama de Actividad demuestra la serie de actividades que
deben ser realizadas en un uso-caso, as como las distintas rutas que
pueden irse desencadenando en el uso-caso.

Es importante recalcar que aunque un diagrama de actividad es muy
similar en definicin a un diagrama de flujo (tpicamente asociado
en el diseo de Software), estos no son lo mismo. Un diagrama de
actividad es utilizado en conjuncin de un diagrama uso-caso para
auxiliar a los miembros del equipo de desarrollo a entender como es
utilizado el sistema y como reacciona en determinados eventos. Lo
anterior, en contraste con un diagrama de flujo que ayuda a un
programador a desarrollar cdigo a travs de una descripcin lgica
de un proceso. Se pudiera considerar que un diagrama de actividad
describe el problema, mientras un diagrama de flujo describe la
solucin.
DIAGRAMA DE ACTIVIDADES
Composicin

Inicio: El inicio de un diagrama de actividad es representado por un
crculo de color negro slido.

Actividad : Una actividad representa la accin que ser realizada por
el sistema la cual es representada dentro de un ovalo.

Transicin: Una transicin ocurre cuando se lleva acabo el cambio
de una actividad a otra, la transicin es representada simplemente
por una lnea con una flecha en su terminacin para indicar
direccin.
Actividades del diagrama de secuencias del 4 al 6
OTROS DIAGRAMAS
Diagrama de Colaboraciones




Diagrama de Componentes




Diagrama de Distribucin





OTROS DIAGRAMAS
Diagrama de Distribucin








POR QU TANTOS DIAGRAMAS?
Los diagramas UML le permiten examinar un sistema desde distintos
puntos de vista, es importante recalcar que en un modelo UML, no es
necesario que aparezcan todos los diagramas.

Por qu es necesario contar con diferentes perspectivas del un sistema?

Por lo general, un sistema cuenta con diversas personas implicadas las
cuales tienen enfoques particulares en diversos aspectos del sistema. Si
tenemos en cuenta el ejemplo tratado anteriormente (LAVADORA), para
disear el motor de la lavadora se tendra una perspectiva del sistema; si
se disean las formas que tendr se vera de otra forma, desde el punto de
vista de quien escribe los comandos de ejecucin tendra una perspectiva
distinta y el usuario tambin tendra una visin diferente a las anteriores.
El diseo de un sistema completo involucra todas las posibles
perspectivas, y el diagrama UML le da una forma de incorporar una
perspectiva en particular. El objetivo es satisfacer a cada persona
implicada.
TALLER
Por qu es necesario contar con diversos diagramas en el modelo
de un sistema?

Cules diagramas le dan una perspectiva esttica al sistema?

Cuales diagramas le dan una perspectiva dinmica al sistema?
(muestran el cambio progresivo).

Suponga que crear un sistema informtico que jugar ajedrez con
un usuario Cules diagramas UML seran tiles para disear el
sistema? Por qu?

Para el anterior sistema liste las preguntas (20) que formulara a un
usuario potencial y por que las hara


DIAGRAMAS DE CLASES
El diagrama de clase describe los tipos de objetos que hay en el
sistema y las diversas clases de relaciones estticas que existen entre
ellos. Hay dos tipos principales de relaciones estticas:

ASOCIACIONES (por ejemplo, un diente puede rentar diversas
videocintas).

GENERALIZACIN (una enfermera es un tipo de persona).

Los diagramas de clase tambin muestran los atributos y operaciones
de una clase y las restricciones a que se ven sujetos, segn la forma en
que se conecten o interrelacionen los objetos que se contienen en el
proyecto.
ABSTRACCIN: La abstraccin consiste en captar las caractersticas esenciales de
un objeto, as como su comportamiento. Por ejemplo analicemos a un automvil,
Qu caractersticas podemos abstraer de los automviles? O lo que es lo mismo
Qu caractersticas semejantes tienen todos los automviles? Todos tendrn
una marca, un modelo, nmero de chasis, peso, llantas, puertas, ventanas, etc. Y
en cuanto a su comportamiento todos los automviles podrn acelerar, frenar,
retroceder, etc (clases).

HERENCIA: La herencia es uno de los conceptos ms cruciales en la POO. La
herencia bsicamente consiste en que una clase puede heredar sus variables y
mtodos a varias subclases (la clase que hereda es llamada superclase o clase
padre). Esto significa que una subclase, aparte de los atributos y mtodos
propios, tiene incorporados los atributos y mtodos heredados de la superclase.
De esta manera se crea una jerarqua de herencia.

Por ejemplo, imaginemos que estamos haciendo el anlisis de un Sistema para
una tienda que vende y repara equipos celulares.

http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/

CONCEPTOS CLAVE DE APRENDIZAJE
En el grfico vemos 2 Clases ms que posiblemente necesitemos para crear nuestro
Sistema. Esas 2 Clases nuevas se construirn a partir de la Clase Celular existente.
De esa forma utilizamos el comportamiento de la SuperClase.
POLIMORFISMO
En ocasiones una operacin tiene el mismo nombre en diferentes
clases. Por ejemplo, podr abrir una puerta, una ventana, un peridico,
un regalo o una cuenta de banco, en cada uno de estos casos, realizar
una operacin diferente.
En el polimorfismo una operacin puede tener el mismo nombre en
diversas clases y puede realizar operaciones propias o funcionar de
modo distinto en cada una,
ENCAPSULAMIENTO
El encapsulamiento consiste en unir en la Clase las caractersticas y
comportamientos, esto es, las variables y mtodos. Es tener todo esto
es una sola entidad. En los lenguajes estructurados esto era imposible.

La utilidad del encapsulamiento va por la facilidad para manejar la
complejidad, ya que tendremos a las Clases como cajas negras donde
slo 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 cmo lo hace.
ENVO DE MENSAJES
Un objeto es intil si est aislado. El medio empleado para que un
objeto interacte con otro son los mensajes. Hablando en trminos un
poco ms tcnicos, los mensajes son invocaciones a los mtodos de los
objetos.

Todos los objetos trabajan en conjunto. Esto se logra mediante el envo
de mensajes entre ellos. Un objeto enva a otro un mensaje para
realizar una operacin y el objeto receptor ejecutar la operacin.

ASOCIACIONES
La relacin entre clases conocida como Asociacin, permite asociar
objetos que colaboran entre si. Cabe destacar que no es una relacin
fuerte, es decir, el tiempo de vida de un objeto no depende del otro.
Un cliente puede tener asociadas muchas Ordenes de Compra, en
cambio una orden de compra solo puede tener asociado un cliente.
ASOCIACIONES
Con Frecuencia los objetos se relacionan entre si de alguna forma. Cuando usted
enciende su televisin tendr una asociacin en una sola direccin con ella
En ocasiones, un objeto podra asociarse en ms de una forma , por
ejemplo 2 personas (Jefe y empleado) al mismo tiempo pueden ser
amigos
ASOCIACIONES
Una clase se puede asociar con ms de una clase distinta una persona puede viajar
en automvil, pero tambin puede hacerlo en autobs.
La multiplicidad o diversificacin es un importante aspecto de las asociaciones entre
objetos indica la cantidad de objetos de una clase que se relacionan con otro objeto
en particular de la clase asociada. Por ejemplo en un curso escolar, el curso se
imparte por un solo instructor, en consecuencia, el curso y el instructor estn en
asociacin 1 a 1. sin embargo en un seminario hay diversos instructores que
impartirn el curso a lo largo del semestre, por lo tanto el curso y el instructor tienen
una asociacin de 1 a N

Otros ejemplos una bicicleta rueda en 2 neumticos (1:2), un triciclo rueda en 3
(1:3), entre otros.
Una asociacin es una relacin estructural que describe una conexin fuerte entre
los objetos de las clases. Grficamente, se muestra como una lnea continua que une
las clases relacionadas entre s,
NAVEGACIN EN LAS ASOCIACIONES: Aunque las asociaciones suelen ser bidireccionales (se
pueden recorrer en ambos sentidos), en ocasiones es deseable hacerlas unidireccionales
(restringir su navegacin en un nico sentido).

Grficamente, cuando la asociacin es unidireccional, la lnea termina en una punta de flecha
que indica el sentido de la asociacin,
Class Cuenta
{
private Dinero balance;
public void ingresar (Dinero cantidad)
{
balance = balance + cantidad;
}
public void retirar (Dinero cantidad)
{
balance = balance cantidad;
}
public Dinero getSaldo ()
{
return balance;
}
}

En este ejemplo se supone
que Dinero es un tipo de
dato con el que se pueden
hacer operaciones
aritmticas y se ha aadido
una operacin adicional que
nos permite comprobar el
saldo de una cuenta,
AGREGACIN
Para entender este trmino vamos a analizar una computadora, cuenta con un
teclado, un ratn, un DVD, uno o varios discos duros, una tarjeta de video, una
impresora, entre otros elementos. Al analizar este ejemplo llegamos a la conclusin
que la computadora es una agregacin o adicin, ya que el equipo est constituido
de diversos tipos de componentes .
Una computadora es un ejemplo de agregacin: un objeto que se conforma de una
combinacin de diversos tipos de objetos.
COMPOSICIN
El punto central de la composicin es que el componente hace parte de un objeto
compuesto. Por ejemplo una camisa est compuesta de cuerpo, cuello, mangas,
botones, ojales y puos. Si se suprime la camisa el cuello ser intil.

En ocasiones, un objeto compuesto no tiene el mismo tiempo de vida que sus
propios componentes. Las hojas de un rbol puede morir antes de que el rbol. Si se
destruye al rbol, tambin las hojas morirn,

LA agregacin y la composicin son importantes dado que reflejan casos
extremadamente comunes, y ello ayuda a que cree modelos que se asemejen
considerablemente a la realidad.


En una composicin, un componente
Puede morir antes que el objeto
Compuesto. Si destruye el objeto
Compuesto, destruir tambin a los
Componentes,
TALLER
Qu es un objeto?

Cmo trabajan los objetos en conjunto?

Qu establece la multiplicidad?

Pueden asociarse dos objetos entre s en ms de una
manera?

TALLER
1. Un equipo de ftbol consiste en 11 jugadores de campo (1 portero y el resto, jugadores
de cancha que, en ocasiones, se organizan en cuatro defensas, tres mediocampistas y tres
delanteros). Los jugadores pueden usar cualquier parte de su cuerpo (excepto las manos
para introducir el baln a la portera del equipo contrario . La nica excepcin a esta regla la
tiene el portero, quien puede utilizar tambin las manos para jugar el baln, pero slo
dentro del rea de meta. El campo de juego es un rectngulo de una longitud mxima de
120m y mnima de 90 m; y con una anchura no mayor de 90m, ni menor de 45. Para
partidos internacionales, la longitud ser de 110m como mximo y 100m como mnimo; y
una anchura no superior a 75m ni inferior a 64. En cualquier caso, deber ser mayor la
longitud que la anchura. El campo de juego se dividir en dos mitades transversales de igual
tamao. El centro del campo ser marcado con un punto visible, alrededor del cual se
trazar una circunferencia de 9,15m de radio, La meta del juego es pasar el baln a los
delanteros, quienes estn mejor preparados para patear el baln a la portera. El portero (o
arquero) es la ltima lnea de defensa que intentar bloquear, con cualquier parte del
cuerpo, los tiros de sus opositores. Cada vez que evita un gol, es decir que el baln no entre
a la portera, habr salvado su meta. Cada gol equivale a un punto. Un juego dura 90
minutos, divididos en sos periodos de 45 minutos cada uno,

Si tiene alguna informacin adicional sobre la forma en la que se desarrolla ste juego
complemente el enunciado.

3. Si usted conoce ms del baloncesto agregue informacin al diagrama propuesto en clase




OTRAS RELACIONES DE LAS CLASES
AGREGACIONES: En ocasiones una clase consta de otras clases. Este es un tipo
especial de relacin conocida como agregacin o acumulacin. Los componentes
y la clase que constituyen son una asociacin que conforma un todo.

Una agregacin dentro de un diagrama de clases se representa con una lnea con
un rombo sin relleno que se colocar en el extremo de la lnea ms cercano a la
clase que simboliza el todo.

Ejemplo:


RESTRICCIONES EN LAS AGREGACIONES
En ocasiones el conjunto de componentes posibles en una
agregacin se establece dentro de una relacin O. Ejemplo en
ciertos restaurantes, una comida consta de sopa o ensalada, el
plato fuerte y el postre. Para modelar esto se utilizara una
restriccin : la palabra O dentro de llaves con una lnea
discontinua que conecte las dos lneas que conforman al todo.
COMPOSICIONES
Una composicin es un tipo muy representativo de una
agregacin. Cada componente dentro de una composicin puede
pertenecer tan solo a un todo. Los componentes de una mesa de
caf (la superficie de la mesa y las patas) establecen una
composicin. El smbolo de la composicin es el mismo de la
agregacin, excepto que el rombo est relleno
CONTEXTOS
Una composicin es un tipo muy representativo de una
agregacin. Cada componente dentro de una composicin puede
pertenecer tan solo a un todo. Los componentes de una mesa de
caf (la superficie de la mesa y las patas) establecen una
composicin. El smbolo de la composicin es el mismo de la
agregacin, excepto que el rombo est relleno
CONTEXTOS
Cuando se modele un sistema podran producirse, con frecuencia,
agrupamientos de clases, como agregaciones o composiciones. En tal
caso, deber enfocar su atencin en un agrupamiento o en otro, y el
diagrama de contexto le proporciona la caracterstica de modelaje que
quiere para tal fin, Las composiciones figuran en gran medida dentro
de los diagramas de contexto. Este es un mapa detallado de alguna
seccin de un mapa de mayores dimensiones.
La dependencia de clases es un concepto de la programacin
orientada a objetos que nos indica la relacin existente entre dos
clases. Como su nombre indica nos est diciendo que una clase
depende de otra para realizar su funcionamiento.

Cuando trabajamos con clases es una buena prctica que una clase
realice una nica funcin. De manera que las clases que deban
realizar funciones complejas estarn formadas a partir de una
asociacin de diversas pequeas clases en las que delegar cada
funcionalidad en concreto.

Este sera un ejemplo simple de una relacin de asociacin y de
delegacin entre clases:
DEPENDENCIAS DE LAS CLASES
CDIGO
package
{
public class Foro
{
private var _moderador:Zguillez;

public function Foro()
{
_moderador = new Zguillez();
}
public function moderar():void
{
_moderador.moderar();
}
}
}
Aqu vemos como la clase "Foro" est delegando
toda la funcionalidad del mtodo "moderar" al
objeto de clase "Zguillez", haciendo de esta manera
que toda la implementacin est en esa clase
dejando la clase principal ms limpia y ordenada.
Esto nos permite una mayor reutilizacin de
nuestras clases.

El problema que nos encontramos aqu es que se ha
creado una relacin de dependencia muy grande
entre estas dos clases. La clase "Foro" tiene una
referencia directa a la clase "Zguillez" y necesita
estrictamente de esa clase para funcionar.

De manera que si tuvisemos (por requisitos de la
aplicacin o por reutilizacin del cdigo) que
cambiar la implementacin de la funcin "moderar"
tendramos que reescribir la clase "Zguillez" para
cambiar su implementacin concreta o reescribir la
clase "Foro" para delegar esa funcin a la clase "Zah"
(por ejemplo). Con lo que hace estas clases poco
reutilizables.
CONTEXTOS
Cuando se modele un sistema podran producirse, con frecuencia,
agrupamientos de clases, como agregaciones o composiciones. En tal
caso, deber enfocar su atencin en un agrupamiento o en otro, y el
diagrama de contexto le proporciona la caracterstica de modelaje que
quiere para tal fin, Las composiciones figuran en gran medida dentro
de los diagramas de contexto. Este es un mapa detallado de alguna
seccin de un mapa de mayores dimensiones.
TALLER
Cree un diagrama de contexto de composicin de una
revista. Tome en cuenta la tabla de contenido, la editorial,
los artculos y las columnas. Luego, cree un diagrama de
contexto del sistema que muestre a la revista junto con el
suscriptor y el comprador en un puesto de revistas.

En la actualidad, el tipo ms popular de GUI es la interfaz
WIMP (ventanas, iconos, mens y puntero). Dibuje un
diagrama de clases de la interfaz WIMP, y haga uso de todo
el conocimiento adecuado del UML que ha adquirido hasta
ahora. Adems de las clases indicadas en las siglas, incluya
los elementos relacionados como las barras de
desplazamiento y el cursor as como cualquiera de las otras
clases necesarias.