• ¿ 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

• ¿ 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/

• 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

• 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.

Modelan la vista estática del sistema

Elementos básicos:ClasesRelaciones

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ónClases asociación: Asociaciones convertidas a clases

Diagramas de clases

Asociación Generalización Agregación

Nombre Clase

atributo

operacion

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

• PolimorfismoPolimorfismo 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

• 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.

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ónCarrera

Edad Dirección Sexo

Profesión

Dependencia

Vehículos

Vehículos Terrestres Vehículos Acuáticos

CarrosVehí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.

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.

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

ModeloUML

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

UML “aglutina” enfoques OO

UML

Rumbaugh

Jacobson

Meyer

Harel

Wirfs-BrockFusion

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

19981999

2000

UML 1.2

UML 1.3

UML 1.42001 UML 2.0

Revisiones menores

Historia de UML

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.

Vista de Diseño

Vista de Procesos

Vista de Despliegue

Vista de Implementación

Vista de los Casos de Uso

Organización de Modelos

Diagramas de UML

Use CaseDiagramsUse Case

DiagramsDiagramas de Casos de Uso

ScenarioDiagramsScenario

DiagramsDiagramas deColaboración

StateDiagramsState

DiagramsDiagramas deComponentes

ComponentDiagramsComponent

DiagramsDiagramas deDistribución

StateDiagramsState

DiagramsDiagramas de Objetos

ScenarioDiagramsScenario

DiagramsDiagramas deEstados

Use CaseDiagramsUse Case

DiagramsDiagramas deSecuencia

StateDiagramsState

DiagramsDiagramas deClases

Diagramas deActividad

Modelo

Relación Vistas - Diagramas

Vista de casos de uso Diagramas de casos de usoDiagramas de actividades

Vista de diseño Diagramas de clasesDiagramas de interacciónDiagramas de estados

Vista de procesos Diagramas de claseDiagramas de interacción

Vista de implementación Diagramas de componentes

Vista de despliegue Diagrama de despliegue

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:ActoresCasos de usoRelaciones

ActoresModelan diferentes papeles que pueden representar los usuarios

o sistemas que interactúan con el sistema a desarrollar

Casos de usoRepresentan todo lo que el usuario puede realizar con el sistema

RelacionesPermiten asociar los elementos anteriores

Casos de Usos

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)

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 actoresGeneralización entre casos de usoRelación de asociación entre actores y casos de usoRelación de extensiónRelación de inclusión

Identifican la comunicación entre actores, casos de uso y actores con casos de uso.

Relación de extensión: Factoriza un caso de uso en nuevos casos de uso que extienden o amplían su comportamiento

A Bextend 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 Binclude 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

Uso de cajero automático:1) para retiro

- dinero disponible en cuentano autorización de cantidadautorización de cantidad

- dinero insuficiente- no hay dinero

2) para consulta3) para deposito4) para transferencia entre cuentas

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

Ejemplo: Uso de cajero automático

retiro disponible c/ autorizaciretiro disponible c/ autorizacióónn

identificacion validacion

claveacceso cuentas

operacion

validacion montoautorizacion

entrega dinero

< usa >

< usa >

< extiende >< usa >

< usa >

< usa >

< extiende >

< extiende >

clienteclienteGestion

< usa >

< usa >

< dispara >

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

CoordinadorModificar

<<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.

Caso de uso: actualiza cuentas del sistema de contabilidad.

CASO DE USOREALIZAR 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.