1. Programación Orientada a Objetos
No es difícil aprender a programar en un
lenguaje OO, el problema es que es necesario
cierto tiempo para aprender a aprovechar las
ventajas que contiene el lenguaje OO
Los lenguajes permiten ventajas, pero no las
proporcionan
En la programación poo, la unidad básica es el
objeto, los cuales forman una jerarquía y se
comunican entre ellos con mensajes

2. OBJETOS




Un objeto es cualquier entidad tangible del
problema, esta formado por un conjunto
complejo de datos y los procedimientos que
manejan a los mismos, están insertos dentro
de una jerarquía, la identidad es única dentro
del dominio.
Los datos se conocen como propiedades y la
forma de operar con ellos métodos
Las propiedades definen las características
(estados)
Los métodos las operaciones
(comportamiento)

3. OBJETOS


RELACIONES
Permite al objeto entroncarse dentro de
la jerarquía, son punteros
MENSAJES
La forma de comunicarse con un objeto
se llama mensaje, y este ejecuta un
método

4. Clases

Equivale a la generalización de un tipo
especifico de objetos, los objetos NO
existen por si solo, existe cuando se
instancia la clase

LAS PROPIEDADES Y LOS METODOS
FORMAN LA INTERFASE DE LA CLASE

5. Metodos
Siempre es recomendable evitar las
asignaciones directas a atributos para dejar
mas solida la clase, ocultando asi el nombre y
tipo verdadero del atributo, para ello existen
dos tipos de metodos
Accesores

Se utilizan para poder acceder los atributos a través
de un metodo
Modificadores

Se utilizan para modifcar el valor del atributo

6. Metodos
Constructores

Es el metodo que inicializa los atributos con
un valor por defecto
Instancia

Pertenece a una instancia de un objeto
creado
Tipos


Procedimientos
Funciones (siempre devuelven un valor)

7. Programación Orientada a Objetos

Encapsulado





Protege los datos ante la corrupción que pueden
causar desde el exterior
Oculta los detalles de implementación
Depurar los objetos en forma individualmente
Dividir los proyectos
Abstracción


Centrarse en el problema
Reutilización

8. Programación Orientada a Objetos

Polimorfismo




Dado los mismos métodos responden en forma
diferente dependiente del objeto
Simplifica la interfaz del objeto
Reutilización
Herencia



Reduce la programación redundante
Reduce tamaño y optimiza la velocidad
Viola el encapsulamiento

9. Proceso unificado
Concepcion
Elaboracion
Constuccion
Transicion
Dirigido por casos de uso, centrado en la arquitectura,
iterativo e incremental

10. Concepción

Situacion economica del proyecto

Alcance

Analisis inicial

Viabilidad

11. Elaboración




Que se va a construir
Como se va a construir
Con que tecnología
Analisis de riesgo






Requerimientos
Tecnologicos
Experiencia
Politicos
Gerencia
Dominio

12. Constucción

Cada iteración en un miniproyecto, es un
recorrido completo por el flujo de trabajo
fundamental, reduce los riesgos
Una Iteracción es
Requisitos
Analisis
Diseño
Implementacion
Pruebas

13. Qué es UML


UML es un Lenguaje de Modelado Unificado
basado en una notación gráfica la cual permite:
especificar, construir, visualizar y documentar
los objetos de un sistema programado.
Este lenguaje es el resultado de la unificación
de los métodos de modelado orientados a
objetos de Booch, Rumbaugh (OMT: Object
Modeling Technique) y Jacobson (OOSE:
Object-Oriented Sotfware Engineering) .

14. Qué es UML


El UML modela sistema mediante el uso
de objetos que forman parte de él así
como, las relaciones estáticas o
dinámicas que existen entre ellos.
UML puede ser utilizado por cualquier
metodología de análisis y diseño
orientada por objetos para expresar los
diseños.

15. Qué es UML
Es un lenguaje unificado de modelado
Toma elementos de los métodos de
BOOCH, RUMBAUGH, JACOBSON
Es un lenguaje de modelado y no un
método

16. Qué es UML
Método : Lenguaje + Proceso
Lenguaje:Es la notación generalmente gráfica
que se valen los métodos para expresar los
diseños
Proceso: Pasos a seguir para hacer el diseño
(tratado en los libros User Guide)
Lo que tenemos que aprender es el lenguaje,
porque el proceso lo adapta cada individuo

17. Qué es UML






1.
2.
3.
4.
Diagrama de Casos de Uso
Diagrama de Clases
Diagrama de Actividades
Diagrama de Iteración
4.1. Diagrama de Secuencia
4.2. Diagrama de Colaboración

18. Qué es UML



5.
6.
Diagrama de Estados
Diagrama de Implementación
6.1. Diagrama de Componentes
6.2
Diagrama de Despliegue
Conceptos de patrones

19. Casos de uso

Un diagrama de Casos de Uso muestra la
distintas operaciones que se esperan de
una aplicación o sistema y cómo se
relaciona con su entorno (usuario u otras
aplicaciones).

Es una herramienta esencial para la
captura de requerimientos y para la
planificación y control de un proyecto
interactivo.

20. Casos de uso

Según Jacobson Es el elemento primario
de la planificación y el desarrollo de
proyectos.

Es un documento narrativo que describe la
secuencia de eventos de un actor (agente
externo) que utiliza un sistema para
completar un proceso.

Es una interacción típica entre un usuario
y un sistema informático

21. Casos de uso



Los casos de Uso Se representa en el diagrama
por una elipse que denota un requerimiento
solucionando por el sistema.
Cada caso de uso de uso es una operación
completa desarrollada por los actores y por el
sistema en un diálogo.
El conjunto de casos de uso representa la
totalidad de operaciones desarrolladas por el
sistema.

22. Casos de uso
Comunica
<<extend>>
Actor
<<use>>
Profesor
Fig. 1 Ejemplo de Diagramas de Casos de Uso.

23. Casos de uso

Actor: Es un usuario del sistema, que
necesita o usa alguno de los casos de
uso. Un usuario puede jugar más de un
rol. Un solo actor puede actuar en
muchos casos de uso; recíprocamente,
un caso de uso puede tener varios
actores. Los actores no necesitan ser
humanos pueden ser sistemas externos
que necesitan alguna información del
sistema actual.

24. Casos de uso

Especificación narrativa








Numerarlo
Ponerle un nombre
Identificar los actores
Primario: Destinado al caso de uso
Secundario: Pueden ser o no destinado al caso
de uso
Descripción
Pre Condición
Post Condición

25. Casos de uso

Curso Básico





Curso de ejecucion
Cuando se contesta que si a todas las preguntas
y esta todo bien
Forma

Narrativa

Conversaciones
No hay modelos estáticos son evolucionables
Curso Alternativo


Bifucurcasiones al curso básico
Excepciones

Mensajes de Error

26. Casos de uso

Primario


Surgen de las primeras conversaciones con
los actores
Extendido

A partir del caso primerio se comienza a
implementar el sistema, comienzan los
detalles de implementacion

27. Diagrama de Clases



Clase: representa un conjunto de
entidades
que
tienen
propiedades
comunes.
Una clase es un constructo que define la
estructura y comportamiento de una
colección
de
objeto
denominados
instancia de la clase.
En UML la clase está representada por
un rectángulo con tres divisiones
internas,
son
los
elementos
fundamentales del diagrama.

28. Diagrama de Clases
Ejemplo:
Publicación
Nombre de la clase
# Código P: Cadena [2]
Nombre de
Clase
-Ncopias: Entero
+Actor: Cadena [30]
Atributos
-MontoA: Monetario
+Fecha: Date
-Agregar ()
-Consultar ()
+Listar()
Fig.2 Representación de una clase
Método

29. Diagrama de Clases

Propiedades: Representa una propiedad de
una entidad. Cada atributo de un objeto tiene
un valor que pertenece a un dominio de valores
determinado.
Las sintaxis de una atributo es:
Visibilidad <nombre>: tipo = valor incial
Donde visibilidad es uno de los siguientes:
+ público.
# protegido.
- privado.

30. Diagrama de Clases

Metodos: El conjunto de operaciones
que describen el comportamiento de los
objetos de una clase. La sintaxis de una
operación en UML es:
Visibilidad
nombre
(lista
de
parámetros):
tipo
que
retorna
{ propiedades}

31. Diagrama de Clases

Objeto: es una instancia de una clase. Se
caracteriza por tener una identidad única, un
estado definido por un conjunto de valores de
atributos y un comportamiento representado
por sus operaciones y métodos.

Asociación (rol, multiplicidad, calificador):
representan las relaciones entre instancias de
clase. Una asociación es una línea que une dos
o más clases

32. Diagrama de Clases


Rol: Identificado como un nombre a los finales
de la línea, describe la semántica de la relación
en el sentido indicado. Cada asociación tiene
dos roles; cada rol es una dirección en la
asociación. El rol puede estar representado en
el nombre de la clase.
Multiplicidad: Describe la cardinalidad de la
relación, es decir, cuanto objetos de esa clase
pueden participar en la relación dada [ Int-2].

33. Diagrama de Clases

La multiplicidad puede ser:
1
Clase
Exactamente uno
*
Clase
Cero o más
O ..1
Clase
Cero o uno
m..n
Clase
Especificada numéricamente
Fig. 3 Tipos de Multiplicidad

34. Diagrama de secuencia

El diagrama de secuencia forma parte de
los diagramas de interacción

Describen la manera que colaboran
grupos de objetos para un cierto
comportamiento de un caso de uso. Se
describen los objetos y los mensajes que
son pasados entre ellos

35. Diagrama de secuencia

Un diagrama de secuencia muestra la
interacción de un conjunto de objetos de
una aplicación a través del tiempo. Esta
descripción es importante porque puede
dar detalle a los casos de uso,
aclarándolos al nivel de mensajes de los
objetos existentes, como también
muestra el uso de los mensajes de las
clases diseñadas en el contexto de una
operación

36. Diagrama de secuencia
Cada objeto se muestra como una caja el la
parte superior de una línea vertical
punteada, esta línea se denomina línea
de vida.
Cada mensaje se representa mediante una
flecha entre las líneas de vida de dos
objetos
Los mensajes trascurren hacia abajo

37. Diagrama de secuencia
Mensaje Común

Prepara()
Mensaje con iteración


(*Para cada artículo)
Baja Stock
Mensaje con condición
(No existe artículo)
Doy de alta(nro,nombre,familia)

38. Diagrama de secuencia
:DEPOSITO
F.T.
:USUARIO
AUTORIZADO
:TOTAL_D
ACTUALIZAR
DEPOSITO F.T.
ACTUALIZAR
TOTAL_D.
ACTUALIZAR
DEPOSITO F.T.
OK
ACTUALIZAR
TOTAL_D
OK
FIG. 3.9 Diagrama de secuencias asociadas al proceso “Actualizar Depósito”