OBJETIVO 4

Diseo orientado a objetos

Diseo orientado a objetos es una fase de la metodologa orientada a objetos para el desarrollo de
Software. Su uso induce a los programadores a pensar en trminos de objetos, en vez de procedimientos, cuando
planifican su cdigo. Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La
'interfaz del objeto', esto es, las formas de interactuar con el objeto, tambin se definen en esta etapa. Un
programa orientado a objetos se caracteriza por la interaccin de esos objetos. El diseo orientado a objetos es
la disciplina que define los objetos y sus interacciones para resolver un problema de negocio que fue
identificado y documentado durante el anlisis orientado a objetos.
Lenguaje Unificado de Modelado (UML, por sus siglas en ingls, Unified Modeling Language)
Es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad; est
respaldado por el OMG (Object Management Group). Es un lenguaje grfico para visualizar, especificar,
construir y documentar un sistema. UML ofrece un estndar para describir un "plano" del sistema (modelo),
incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos
como expresiones de lenguajes de programacin, esquemas de bases de datos y compuestos reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir
mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para
documentar y construir. En otras palabras, es el lenguaje en el que est descrito el modelo. Se puede aplicar en
el desarrollo de software gran variedad de formas para dar soporte a una metodologa de desarrollo de software
(tal como el Proceso Unificado Racional o RUP), pero no especfica en s mismo qu metodologa o proceso
usar.
UML no puede compararse con la programacin estructurada, pues UML significa Lenguaje Unificado
de Modelado, no es programacin, solo se diagrama la realidad de una utilizacin en un requerimiento.
Mientras que, programacin estructurada, es una forma de programar como lo es la orientacin a objetos, la
programacin orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma
UML slo para lenguajes orientados a objetos. UML cuenta con varios tipos de diagramas, los cuales muestran
diferentes aspectos de las entidades representadas.
2) Diagrama UML
3) Diagrama de casos de uso
Es una forma de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado Unificado
(UML), define una notacin grfica para representar casos de uso llamada modelo de casos de uso. UML no
define estndares para que el formato escrito describa los casos de uso, y as mucha gente no entiende que esta
notacin grfica define la naturaleza de un caso de uso; sin embargo una notacin grfica puede solo dar una
vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a
menudo confundidos con los casos de uso. Mientras los dos conceptos estn relacionados, los casos de uso son
mucho ms detallados que los diagramas de casos de uso. En los conceptos se debe detallar ms de un caso de
uso para poder identificar que es lo que hace un caso de uso.

4) Elementos de un diagrama de caso de uso
Actores
Los actores representan un tipo de usuario del sistema. Se entiendo como usuario cualquier cosa externa
que interacta con el sistema. No tiene por qu ser un ser humano, puede ser otro sistema informtico o
unidades organizativas o empresas.
Siempre hay que intentar independizar los actores de la forma en que se interacta con el sistema. Por
ejemplo un teclado no es un actor en la mayor parte de los casos, slo un medio para introducir informacin al
sistema. Suele ser til mantener una lista de los usuarios reales para cada actor. Un actor en un diagrama de
casos de uso representa un rol que alguien puede estar jugando, no un individuo particular por lo tanto puede
haber personas particulares que puedan estar usando el sistema de formas diferentes en diferentes ocasiones:
socio De biblioteca y bibliotecario.
Caso de uso
Es una tarea que debe poder llevarse a cabo con el apoyo del sistema que se est desarrollando. Se
representan mediante un vulo. Cada caso de uso debe detallarse, habitualmente mediante una descripcin
textual.
Asociaciones
Hay una asociacin entre un actor y un caso de uso si el actor interacta con el sistema para llevar a
cabo el caso de uso. Un caso de uso debe especificar un comportamiento deseado, pero no imponer cmo se
llevar a cabo ese comportamiento, es decir, debe decir QU pero no CMO. Esto se realiza utilizando
escenarios.
Las tres relaciones principales entre los casos de uso son soportadas por el estndar UML, el cual
describe notacin grfica para esas relaciones. Veamos una revisin de ellas a continuacin:
<<include>> que especifica una situacin en la que un caso de uso tiene lugar dentro de otro caso de
uso
<<extends>> que especifica que en ciertas situaciones, o en algn punto (llamado punto de extensin)
un caso de uso ser extendido por otro.
Generalizacin que especifica que un caso de uso hereda las caractersticas del super caso de uso, y
puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases.
Un escenario
Es una interaccin entre el sistema y los actores, que puede ser descrito mediante una secuencia de
mensajes. Un caso de uso es una generalizacin de un escenario.
5) Documentacin de un diagrama de caso de uso
6) Diagrama de clase de anlisis de UML
Los diagramas de clases muestran las diferentes clases que componen un sistema y cmo se relacionan
unas con otras. Se dice que los diagramas de clases son diagramas estticos porque muestran las clases, junto
con sus mtodos y atributos, as como las relaciones estticas entre ellas: qu clases conocen a qu otras
clases o qu clases son parte de otras clases, pero no muestran los mtodos mediante los que se invocan entre
ellas.
Clase
Una clase define los atributos y los mtodos de una serie de objetos. Todos los objetos de esta clase
(instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada objetos tiene
el suyo propio). En ocasiones se utiliza el trmino tipo en lugar de clase, pero recuerde que no son lo mismo,
y que el trmino tipo tiene un significado ms general. En , las clases estn representadas por rectngulos, con
el nombre de la clase, y tambin pueden mostrar atributos y operaciones de la clase en otros dos
compartimentos dentro del rectngulo.
7) Diagrama de interaccin de UML (d. colaboracin, d. secuencia)
Diagramas de interaccin (vista dinmica):
Los diagramas de interaccin se utilizan para modelar los aspectos funcionales/dinmicos de un sistema,
desde un punto de vista del diseo. Es la representacin del modelo funcional de un sistema mediante
intercambio de mensajes. Los diagramas de interaccin tambin se utilizan durante el anlisis de requisitos
Diagramas de colaboracin
Los diagramas de colaboracin muestran las interacciones que ocurren entre los objetos que participan
en una situacin determinada. Esta es ms o menos la misma informacin que la mostrada por los diagramas de
secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los
diagramas de colaboracin fijan el inters en las relaciones entre los objetos y su topologa.
En los diagramas de colaboracin los mensajes enviados de un objeto a otro se representan mediante
flechas, mostrando el nombre del mensaje, los parmetros y la secuencia del mensaje. Los diagramas de
colaboracin estn indicados para mostrar una situacin o flujo programa especficos y son unos de los mejores
tipos de diagramas para demostrar o explicar rpidamente un proceso dentro de la lgica del programa.
Diagramas de secuencia
Los diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en que se invocan)
en un momento dado. Los diagramas de secuencia ponen especial nfasis en el orden y el momento en que se
envan los mensajes a los objetos.
En los diagramas de secuencia, los objetos estn representados por lneas intermitentes verticales, con el
nombre del objeto en la parte ms alta. El eje de tiempo tambin es vertical, incrementndose hacia abajo, de
forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operacin y
los parmetros.
Los mensajes pueden ser o bien sncronos, el tipo normal de llamada del mensaje donde se pasa el
control a objeto llamado hasta que el mtodo finalice, o asncronos donde se devuelve el control directamente al
objeto que realiza la llamada. Los mensajes sncronos tienen una caja vertical en un lateral del objeto invocante
que muestra el flujo del control del programa.