1. • ¿ Qué es un Objeto ?
Un objeto es una entidad física o abstracta que tiene un
comportamiento antes ciertos estímulos, tanto externos
como de otros objetos específicos que se encuentran
dentro del sistema.
• Cada objeto es un elemento con
características propias. La definición de un
tipo de objetos se llama CLASE.
• Hay Clases de las cuales no se derivan
objetos sin otras clases y se llaman clases
abstractas.
CLASES Y OBJETOS

2. • ¿ Qué se puede considerar como objeto ?
• -Persona -Equipo Hardware -Materiales
• -Información -Software -Procesos
• -Procedimientos
• Objeto Físico:Horno
• Operaciones asociadas:
Encendido/Apagado/Cargado/Descargado.
• Objeto Abstracto:Cola
• Operaciones:
Agregar/Eliminar/Verificar vacía/
Verificar si llena/Primero cola/Siguiente cola/

3. • Identidad de un objeto
Cada objeto tiene su propia identidad que lo distingue de los
demás objetos. En otras palabras, dos objetos distintos no son
iguales aunque todos los valores de sus atributos sean
idénticos.
• Tipos de objetos
• 1.- Objetos reales
• 1.1 Objeto físico: Son objetos extremamente
perceptibles
ejemplo(vista, olfato,gusto,oído)
• 1.2 Objetos psíquicos: Son internamente perceptibles.
Ejemplo: dolor,
sentimiento, imágenes.
• 2.- Objeto ideales no son perceptibles.
• 2.1 Relaciones o asociaciones entre objetos
• 2.2 Pensamientos
• 2.3 Matemáticos, lógicos semiótico

4. • Clasificación:
• El proceso de clasificación es el enfoque central de la orientación por
objeto y concierne a la agrupación de objetos con propiedades (estructuras
de datos o atributos) y comportamiento (operaciones) similares dentro de
una clase.
• Una clase es la abstracción que describe propiedades importantes
para una aplicación.
• Cada clase describe una posibilidad infinita de un conjunto individual de
objetos. Cada objeto que pertenezca a una clase es llamado instancia de
la clase.
• La instanciación es lo inverso a la clasificación y concierne a la
generación de los distintos objetos de una clase. La distinción entre una
clase y sus instancias es similar a la distinción entre una definición de tipo
y la declaración de una variable en un lenguaje de programación
convencional. Sin embargo, la mayoría de los sistemas orientados por
objeto crean dinámicamente instancias por envío de mensajes "Nuevo" y
"Crear" una clase.

5. Modelan la vista estática del sistema
Elementos básicos:
Clases
Relaciones
Objeto: Representación de una entidad discreta (real o abstracta)
- Estado: Definido por valores de propiedades y relaciones
- Comportamiento: Operaciones que puede realizar el objeto
- Identidad: Unicidad independientemente de su estado
Clase: Conjunto de objetos con las mismas propiedades, operaciones,
relaciones y semántica
Relaciones
- Asociación: Conexión bidireccional entre clases
- Agregación: Relación especial. Relación Todo-Parte
- Herencia: Relación entre superclases y subclases
Multiplicidad: Número de objetos con el que se puede combinar un obj.
Atributos asociación: Propiedad de una asociación
Clases asociación: Asociaciones convertidas a clases
Diagramas de clases
Asociación Generalización Agregación
Nombre Clase
atributo
operacion

6. Notación para representar una clase.
Una clase se representa por una caja la cual puede tener 3 regiones.
• La primera región contiene el nombre de la clase.
• La segunda región contiene la lista de atributos, cada nombre de
atributo puede estar seguido por detalles opcionales tales como tipo
de atributo y valores por defectos.
• La tercera región contiene los nombres de las operaciones. Cada
nombre de operación puede ser seguido por detalles opcionales tales
como listas de argumentos y tipos de resultados. Los atributos y
operaciones puede o no mostrarse; esto depende del nivel de detalle
deseado.
Aplicando
abstracción
Objetos polígonos
Clase polígono
Atributos
Vértices
Color del borde
Color de relleno
Operaciones
Dibujar
Borrar
Mover

7. • Polimorfismo
Polimorfismo significa que la misma
operación puede comportarse diferentemente
sobre distintas clases. Por ejemplo, la
operación "mover" ejemplo puede
comportarse diferentemente sobre una clase
llamada Ventana y una clase llamada
Piezas_ajedrez.
Universal
Ad Hoc
Paramétrico
Inclusión
Overloading
Coerción
Polimorfismo
Clasificación de Polimorfismo

8. • Herencia
• La herencia consiste en el compartir atributos y
métodos entre clases basándose en una relación
jerárquica.
• Una clase puede definirse ampliamente y redefinirse
sucesivamente en subclases más refinadas.
• Cada subclase que se incorpora, hereda todas las
propiedades de su superclase y adiciona sus propias y
únicas propiedades.

9. Conceptos básicos de la OxO
• Tipos de Herencia: Simple y Múltiple.
• Simple.
Nombre
Persona
Empleado Estudiante
Secretaría
Director
Año de experiencia
Idiomas
Dependencia
Cargo
Denominación
Carrera
Edad
Dirección
Sexo
Profesión
Dependencia

10. Vehículos
Vehículos Terrestres Vehículos Acuáticos
Carros
Vehículos
Anfibios
Bote
• Herencia Múltiple: Una clase puede heredar rasgos de más de
una superclase. Una clase con más de una superclase es
llamada clase junta. Un rasgo de una clase ancestro que se
encuentra más de una vez a lo largo de una ruta solo se hereda
una vez.

11. 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).
PARA VISUALIZAR
 Símbolos con semántica bien definida.
 UML transciende al lenguaje de programación.
 Modelo explícito, que facilita la comunicación.

12. PARA ESPECIFICAR
• Especificar es equivalente a construir modelos que cumplan las condiciones de
no ambigüedad y completitud.
• UML cubre la especificación del análisis, diseño e implementación de un
sistema software.
PARA CONSTRUIR
Modelo
UML
Ingeniería Directa
Ingeniería Inversa
CÓDIGO
Es posible
hacer
corresponder
con los
lenguajes de
programación
(Java, C#,
B.Datos, etc.).
PARA DOCUMENTAR
cubre la documentación de un sistema:
–Requisitos -Arquitectura -Diseño -Código fuente
–Planificación -Pruebas -Prototipos -Versiones

13. UML “aglutina” enfoques OO
UML
Rumbaugh
Jacobson
Meyer
Harel
Wirfs-Brock
Fusion
Embly
Gamma et. al.
Shlaer-Mellor
Odell
Booch
Pre- and Post-conditions
State Charts
Responsabilities
Operation descriptions,
message numbering
Singleton classes
Frameworks, patterns,
notes
Object life cycles
Nov ‘97 UML aprobado por el OMG
1998
1999
2000
UML 1.2
UML 1.3
UML 1.4
2001 UML 2.0
Revisiones
menores
Historia de UML

14. Modelos y Diagramas
 Un proceso de desarrollo de software debe ofrecer un conjunto de
modelos que permitan expresar el producto desde cada una de las
perspectivas de interés
 El código fuente del sistema es el modelo más detallado del sistema (y
además es ejecutable). Sin embargo, se requieren otros modelos ...
 Cada modelo es completo desde su punto de vista del sistema, sin
embargo, existen relaciones de trazabilidad entre los diferentes
modelos
Modelo: captura una vista de un sistema del mundo real. Es una
abstracción de dicho sistema, considerando un cierto
propósito.
Diagrama: representación gráfica de una colección de elementos
de modelado, a menudo dibujada como un grafo con vértices
conectados por arcos.

15. Vista de Diseño
Vista de
Procesos
Vista de
Despliegue
Vista de
Implementación
Vista de los
Casos de Uso
Organización de Modelos

16. Diagramas de UML
Use Case
Diagrams
Use Case
Diagrams
Diagramas de
Casos de Uso
Scenario
Diagrams
Scenario
Diagrams
Diagramas de
Colaboración
State
Diagrams
State
Diagrams
Diagramas de
Componentes
Component
DiagramsComponent
DiagramsDiagramas de
Distribución
State
Diagrams
State
Diagrams
Diagramas de
Objetos
Scenario
Diagrams
Scenario
Diagrams
Diagramas de
Estados
Use Case
Diagrams
Use Case
Diagrams
Diagramas de
Secuencia
State
Diagrams
State
Diagrams
Diagramas de
Clases
Diagramas de
Actividad
Modelo

17. Relación Vistas - Diagramas
Vista de casos de uso Diagramas de casos de uso
Diagramas de actividades
Vista de diseño Diagramas de clases
Diagramas de interacción
Diagramas de estados
Vista de procesos Diagramas de clase
Diagramas de interacción
Vista de implementación Diagramas de componentes
Vista de despliegue Diagrama de despliegue

18. Casos de Usos
• 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.
Elementos básicos:
Actores
Casos de uso
Relaciones
Actores
Modelan diferentes papeles que pueden representar los usuarios
o sistemas que interactúan con el sistema a desarrollar
Casos de uso
Representan todo lo que el usuario puede realizar con el sistema
Relaciones
Permiten asociar los elementos anteriores

19. Casos de Usos

20. Casos de Usos
-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.
- Casos de uso: Secuencia de transacciones que se realizan en un
diálogo determinado entre un actor y el sistema.
El conjunto de todos los casos de uso relacionados con el
sistema especifica todas las formas de utilización del sistema
Incluyen:
Descripción de la secuencia básica (comportamiento normal)
Secuencias alternativas = Variantes Sec. básica (p.e. errores)
Herramientas, Diagramas de interacción (Diagramas de colaboración, de
secuencia)

21. Casos de Usos
-Relaciones:
-Comunica (comunicates) Entre un actor y un caso de uso, denota
la participación del actor en el caso de uso determinado.
-Usa (uses): Relación entre dos casos de uso, denota la inclusión
del comportamiento de un escenario en otro. Se utiliza cuando se
repite un caso de uso en dos o más casos de uso separados.
Frecuentemente no hay actor asociado con el caso de uso común.
-Extiende (extends): Relación entre dos casos, denota cuando un
caso de uso es una especialización de otro. Se usa cuando se
describe una variación sobre el normal comportamiento.
Tipos de relaciones:
Generalización entre actores
Generalización entre casos de uso
Relación de asociación entre actores y casos de uso
Relación de extensión
Relación de inclusión
Identifican la comunicación entre actores, casos de uso y actores con
casos de uso.

22. Relación de extensión: Factoriza un caso de uso en nuevos casos de uso
que extienden o amplían su comportamiento
A B
extend A extiende a B
A puede conllevar B
Relación de inclusión: Expresa que un caso de uso incluye
comportamiento de otros casos de uso como parte de su propio
comportamiento
A B
include A usa a B
A siempre ejecuta B
Generalización entre actores:
Organización de actores mediante descripciones abstractas
compartidas por otras descripciones de actores más específicos
Generalización entre casos de uso:
Casos de uso más específicos heredarían la descripción de
casos de uso más genéricos, añadiendo una descripción complementaria
Relación de asociación entre actores y casos de uso:
Comunicación existente entre ambos

24. Uso de cajero automático:
1) para retiro
- dinero disponible en cuenta
no autorización de cantidad
autorización de cantidad
- dinero insuficiente
- no hay dinero
2) para consulta
3) para deposito
4) para transferencia entre cuentas

25. Ejemplo: Uso de cajero automático
TRANSFERENCIA
CONSULTA
DEPOSITO
RETIRO
dispara/ inicia
retiro disponible c/ autorizacion
n o hay dineroretiro disponible s/ autorizacion
dinero insuficiente
dispara/inicia
Cliente

26. Ejemplo: Uso de cajero automático
retiro disponible c/ autorizaciretiro disponible c/ autorizacióónn
identificacion validacion
clave
acceso cuentas
operacion
validacion
montoautorizacion
entrega dinero
< usa >
< usa >
< extiende >< usa >
< usa >
< usa >
< extiende >
< extiende >
clientecliente
Gestion
< usa >
< usa >
< dispara >

27. Diagrama de casos de uso
Realizar llamada
telefónica
Recibir llamada
telefónica
Usar
Agenda
Realizar llamada
de conferencia
Recibir llamada
adicional
Teléfono móvil
«extend»
«extend»
Usuario
Red
telefónica

28. Coordinador
Modificar
<<Inicia>>
Buscar B.D
Modificar B.D
Mensaje Error
Cambiar Contraseña
<<Extiende>>
<<Usa>>
<<Extiende>>
<<Extiende>>
Caso de Uso: Modificar –
SIE.
Actores: Coordinador .
Propósito: Poder realizar una
modificación en SIE.
Resumen: El Coordinador
desea realizar una
Modificación, en el sistema la
única modificación es el
cambio de contraseña, se
realiza mediante la
colocación de la contraseña
anterior.
Acción de los Actores Respuesta del Sistema
1.- El Coordinador pide una
Modificación al sistema, (Véase la
sección Cambiar Contraseña).
3.- El Coordinador Ingresa la
contraseña vieja y la contraseña
nueva.
2.- Pide Ingresar la contraseña vieja y la
contraseña nueva.
4.- Verifica la contraseña vieja y sí la
nueva esta escrita bien.
5.- Actualiza la base de datos.

29. Caso de uso: actualiza cuentas del sistema de contabilidad.

30. CASO DE USO
REALIZAR FACTURA.
-El usuario solicita la creación de la nueva factura.
-El sistema solicita el pedido de la venta.
-El usuario proporciona los datos para identificar el
pedido
- El sistema muestra los datos del pedido
- El usuario actualiza los datos de productos y
cantidades
-El sistema pregunta por el tipo de pago.
-El usuario introduce el tipo de pago.
-El sistema solicita la confirmación de los datos.
-El usuario confirma.
-El sistema registra la factura e imprime una copia
de esta.