Programacion inicio

Dirección General de Servicios de Cómputo Académico (DGSCA)

Diplomado de Administración de Bases de Datos

Modelado Orientado a Objetos con UML

L.I. Laura Abreu

L.A. Nubia Fernández

Enero, 2009

Objetivos del módulo

Comprender los principios del paradigma orientado a objetos (OO) Conocer la notación básica de UML para modelar una base de datos, dentro del contexto del análisis y diseño OO.Conocer las características de los Sistemas Manejadores de Bases de Datos Orientadas a Objetos y Objeto-Relacionales.

Temario

Introducción

Metodologías Orientadas a Objetos

Bases de Datos Orientadas a Objetos

INTRODUCCIÓN

Introducción

– Software.– Hardware.– Personas.– Documentación.– Procesos.– Bases de Datos (información).

Elementos de un sistema de información

IntroducciónCaracterísticas del software

– Intangible.– Complejo.– No se gasta pero llega a ser obsoleto.– Es la parte más importante de los sistemas e inclusive la

más costosa.– La industria del software está en constante crecimiento.– Ciclos muy cortos.– Los sistemas legados deben ser mantenidos por otras

personas.– Diseño y arquitectura inadecuados.– No existe documentación o no se encuentra actualizada.

Introducción

La información es uno de los activos más importantes de las organizaciones.La información es útil si está debidamente estructurada y disponible.– debe ser completa,

veraz, oportuna….

Archivosplanos

BDJerárquicas

BDRedes

BDRelacionales

BDOObjetos

BDObjeto-

Relacionales

Bases de datos

METODOLOGÍAS ORIENTADAS A OBJETOS

Paradigma Orientado a Objetos

¿Qué es el paradigma OO?

Es una filosofía para el desarrollo de sistemas basado en el modelado del mundo real a través de la identificación de objetosSurgió inicialmente como un enfoque para la programación pero se ha extendido a todo el ciclo de desarrollo de sistemas.

ParadigmaForma o patrón de pensamiento.Establece reglas y límites.Es una forma de resolver un problema.

ObjetoEs una cosa tangible o conceptual.Un elemento que tiene características y comportamiento.

Principios y conceptos

Objeto.Clase.Abstracción.Mensajes.Firma y protocolo.

Persistencia.Jerarquía.Encapsulamiento.Herencia.

Paradigma OO

– De manera informal, un objeto representa una entidad, ya sea:

Física

Conceptual

o de software

¿Qué es un objeto?

Trailer

Proceso Químico

Lista Ligada

Paradigma OOEjemplos de objetos cotidianos

Un objeto representa un elemento identificable con ciertas caracUn objeto representa un elemento identificable con ciertas caracterteríísticas sticas (atributos) y que puede realizar un conjunto de acciones (operac(atributos) y que puede realizar un conjunto de acciones (operaciones).iones).

Paradigma OO

– Es un concepto, abstracción o cosa con límites bien definidos y significado para una aplicación.

– Un objeto es algo que tiene:Estado.Comportamiento.Identidad.

– Un objeto es una instancia de una clase.

Objeto

Paradigma OOEjemplos de Objetos

automovilmodelo = Mondeomarca = Fordplacas = 564JKNserieMotor = 676565BJN1año = 2002

encender()verificar()cargarGasolina()afinar()cambiarPropietario()vender()

Mari G.

Juan H.

Susy L.

Paradigma OOConceptos

Clase– Es una descripción de un grupo de objetos con

propiedades comunes (atributos), comportamiento común (operaciones) y relaciones comunes con otros objetos.

– Una clase es una definición abstracta de un objeto.

– Sirve como una plantilla para crear objetos.

Paradigma OO¿Cuántas clases hay?

Paradigma OOEjemplos de Clases

medioTransporte

terrestre acuatico aereo

automovilmodelomarcaplacas

encender()verificar()cargarGasolina()afinar()cambiarPropietario()vender()


Abstracción– Permite omitir las

propiedades y acciones de un objeto y dejar sólo aquellas que nos interesan para una situación en particular.


Mensaje

– Es la petición de un servicio.

– Para que los objetos de un sistema trabajen en conjunto, un objeto (cliente) envía a otro una llamada para realizar una operación y el objeto receptor (proveedor) ejecutará la operación.

– El mensaje posee un emisor, un receptor y una acción.

torreControl avion

mensajesolicitaPermisoAt

errizar


Firma y protocolo

– El nombre, tipos de parámetros y tipo del resultado de una operación se denomina firma (signature).

– El conjunto de firmas de todas las operaciones de un objeto se denomina protocolo.

PeriodoLaboral_iHorasTrabajadas : int_iHorasExtra : int_fSueldoNormal : float_fCompensacion : float

PeriodoLaboral()PeriodoLaboral(iHorasTrabajadas : int, iHorasExtra : int, fSueldoNormal : float, fCompensacion : float)setHorasTrabajadas(iHorasTrabajadas : int)setHorasExtra(iHorasExtra : int)setSueldoNormal(fSueldoNormal : float)setCompensacion(fCompensacion : float)getHorasTrabajadas() : intgetHorasExtra() : intgetSueldoNormal() : floatgetCompensacion() : float


Persistencia

– Conservación de la información en algún medio con la posibilidad de recuperarla en cualquier momento.

– Permite que los objetos existan fuera del programa en ejecución.


Jerarquía– Un sistema se compone de subsistemas (más pequeños)

relacionados que tienen a su vez propios subsistemas, y así sucesivamente.

medioTransporte

automovil

derby

De partes(Agregación)

De tipos(Generalización/Especialización)

“es un”

“es un”

computadoraPersonal

teclado“es parte de” cpu monitor

procesador memoria“es parte de”


Encapsulamiento– En general, el encapsulamiento hace referencia a cualquier tipo

de ocultamiento.– Propiedad que permite asegurar que el contenido de la

información de un objeto está oculta al mundo exterior; protege los datos.

– La implementación es oculta del usuario.– Toda la información (atributos y métodos) son almacenados

dentro del objeto. La información puede ser manipulada a través de operaciones.

Estructura

Comportamiento


Herencia– Las clases son organizadas jerárquicamente.– Relación para reusar clases existentes y así definir nuevas. – Las clases hijas conservan la estructura y comportamiento

de las clases padre.– La clase general es llamada superclase; la especialización

subclase.

Paradigma OO

Herencia

Conceptos

Paradigma OOVentajas

– Reutilización.– Desarrollo más rápido.– Mayor calidad.– Facilidad de mantenimiento.– Modularidad.– Costo reducido.– Escalabilidad.– Mejores estructuras de información.– Incremento en adaptabilidad.– Desarrollo más flexible.– Librerías comerciales disponibles.


Lenguaje de Modelado Unificado

Introducción

– Es una representación de algo real.– Un modelo capta los aspectos importantes de lo

que estamos representando, desde cierto punto de vista, y simplifica u omite el resto.

– Los modelos pueden ser físicos, gráficos, matemáticos...

¿Qué es un modelo?

Introducción¿Por qué modelar?

– Es difícil comprender el todo.– Permite dividir un problema complejo en

problemas menores.– Visualizar un sistema desde varias perspectivas.– Entender y dimensionar el problema.– Comprender y probar la solución.

Introducción

– Abstraer las características, componentes y estructura de algo por construir.

– Detectar fallas, inconsistencias y prever cambios.– Documentación del proyecto.– Es menos costoso construir un modelo que un

sistema.– Comunicación entre el equipo de desarrollo y con

los usuarios.

¿Por qué modelar?(2)

Introducción

– Análisis Estructurado (Yourdon).

– Metodología Jackson.

– Técnicas de Diseño y Análisis Estructurado (SADT).

– UML (Orientación a objetos).

– ....

¿Con qué modelamos el software?(si es que lo modelamos)

El Lenguaje de Modelado Unificado (UML) es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software.

– Lenguaje. Mediante la notación permite expresar y comunicar conocimiento.

– Unificado. Integra lo mejor de varios autores, notaciones y técnicas.

– Modelado. Permite representar de manera abstracta aspectos reales.

UML

Autores

FusionOperation descriptions,Message numbering

UML

MeyerBefore and after

conditions

HarelState charts

Wirfs-BrockResponsibilities

EmbleySingleton classes, High-level view

OdellClassification

Shlaer - MellorObject Lifecycles

Gamma, et.alFrameworks, patterns,

notes

BoochJacobsonRumbaugh

UML

UML

– Fue desarrollado en un esfuerzo para simplificar y consolidar las notaciones de desarrollo orientado a objetos que habían surgido principalmente de Booch, Rumbaugh, y Jacobson.

– En 1996 surge la versión 1.0.– En 1997 surge el OMG* y adopta los estándares

relacionados.– La versión más reciente de UML es la 2.0.

*Object Management Group

UMLBeneficios de UML

– Es un estándar en la industria de construcción de software.

– Permite modelar y documentar la arquitectura de una aplicación.

– Facilita la comunicación con otros.– Existen herramientas en el mercado para modelar

y generar código a partir de UML.

Diagramas de UML

RequerimientosCasos de Uso

Modelo estático(Diagramas Estructurales)

ClasesComponentes

Despliegue

Modelo Dinámico(Diagramas de Comportamiento)

SecuenciaColaboración

EstadosActividad

Diagramas de UML

: ObjetoAcceso

: SaludDominio

:ObjetoNegocio

: SaludDominio

<<comunicación>>

Application Server (Windows NT)

Data Server (UNIX)TCP/IP

{Objeto Contenido}

{Nodo}

{Conexión}

addStudent

Initializedo: Initialize courseobject

Unassigneddo: Assign professor to course

Openentry: Register astudent

Closeddo: Report course is full

Canceleddo: Send cancellation notices

addStudent/numStudents = 0

cancelCourse

RegistrationCompletedo: Generate classroster

cancelCourse[ numStudents = 10 ]

cancelCourse

[date = end]

registration closed[ numStudents < 3 ]

Name1

Name2

Name1 Name2

MyProcess.exe

Reviewmodel

Consolidatemodel

Defineentity

Defineboundary

Definecontrol

Defineinteractions

Defineassociations

Defineattributes

Definenontrivialbehavior

Defineparticipating

Defineuse cases

objects

objects objectsobjects

John : Alumno

forma de registro

forma horarioclases disponibles

1: introducir id

2: validar id

3: introducir semestre actual

4: crear nuevo horario5: desplegar

6: obtener cursos

Modelo estático Modelo dinámico

Requerimientos


Requerimientos- Casos de uso- Diagramas de Actividad

¿Qué es un requerimiento?

– De manera general, un requerimiento es una condición o característica que debe satisfacerse.

– En el contexto de desarrollo de software, un requerimiento es una característica identificable expresada en términos de funcionalidad o desempeño que un sistema debe poseer para lograr su objetivo.

Niveles de requerimientos

Necesidades del Negocio

Características del Sistema

Requerimientos de Software

Dominio del Problema

Dominio de la Solución

Tipos de requerimientos

– Requerimientos funcionalesDescriben lo que el sistema debe hacer, es decir especifican acciones que el sistema debe ser capaz de realizar (funcionalidad).

– Requerimientos no funcionalesDescriben atributos del sistema o atributos del ambiente del sistema, por ejemplo:

– Facilidad de uso, Confiabilidad, Desempeño, De diseño, De interfaz, Legales, de Seguridad.

Fuentes de requerimientos

– Conversaciones con el cliente/usuario.– Dominio del problema.– Literatura relevante del dominio.– Entrevistas con expertos.– Conocimiento personal del dominio.– Sistemas legados.– Experiencia de sistemas anteriores.

Historia de un proyecto

Casos de Uso

– Los Casos de Uso nos permiten modelar y especificar los requerimientos funcionales de un sistema.

– Un Caso de Uso es uno de los servicios que ofrece un sistema a un Actor.

Un diagrama de Casos de Uso modela las posibles formas en que un sistema puede ser

usado.

Casos de UsoElementos

– Un Actor representa cualquier cosa que interactué con el sistema.

– Un Caso de Uso es una interacción típica entre un usuario (Actor) y un sistema.

– Las asociaciones y dependencias permiten representar interacciones entre un actor y un caso de uso o entre casos de uso.

Actor

Caso de Uso

«include»

«extend»

Casos de UsoActores

– Los Actores no son parte del sistema; representan los roles que puedenjugar los usuarios del sistema.

– Un Actor puede intercambiarinformación activamente con el sistema.

– Un Actor puede ser un receptor pasivo de información.

– Un Actor puede ser una persona, unamáquina u otro sistema.

– Cada Actor participa en uno o másCasos de Uso.

Actor

Casos de UsoCasos de Uso

Caso de Uso

– Un Caso de Uso es una unidadcoherente de funcionalidad.

– Un Caso de Uso especifica unasecuencia de acciones, incluyendovariantes, que el sistema puede llevara cabo, y que producen un resultadoobservable de valor para un actor.

– Es una toma instantánea de algún aspecto del sistema.

– Los Casos de Uso en conjunto representan toda la funcionalidad del sistema.

Casos de UsoEjemplo

Cuentahabiente

Banco

Proveedor de Telefonia

Retiro deefectivo

Consulta desaldo

Abono detiempo aire

Alimentaciónde efectivo

Consulta debitácora

Pago deservicios

Relación “include”– La relación include ocurre cuando se tiene una porción de

comportamiento que es similar en más de un caso y no se quiere duplicar la descripción de tal conducta.

– Uses o include permite incluir la misma funcionalidad en dos o más Caso de Uso separados sin necesidad de repetir los detalles.

CuentahabienteAutenticación

Retiro deefectivo

Consulta desaldo

Abono detiempo aire

Pago deservicios

Efectivoinsuficiente

«include»

«include»

«include»

«include»

«extend»

Casos de Uso

Relación “extend”– Se utiliza la relación extend cuando se tiene un Caso de Uso que

es similar a otro, pero que hace un poco más.

– Extend describe una variación de la conducta normal.

Proveedor de Telefonia

Cuentahabiente

Retiro deefectivo

Consulta desaldo

Abono detiempo aire

Pago deservicios

Autenticación

Efectivoinsuficiente

Aprobacióndel abono

Generacomprobante

«include»

«include»

«include»

«extend»

«extend»

«extend»

Casos de Uso

Especificación de Casos de Uso

Casos de Uso

Los Casos de Uso pueden especificarse utilizando:

- Narrativa simple - Secuencias- Conversación entre el actor y el sistema

Ejemplo de “Recuperar contraseña”:

Casos de UsoEspecificación de Casos de Uso

El usuario indica que desea “Recuperar contraseña”. Elsistema despliega la pregunta secreta elegida por el usuario al momento de registrarse y el usuario ingresa la respuesta. El sistema verifica que la respuesta sea coincidente y envía la nueva contraseña al correo electrónico del usuario. La contraseña es generada automáticamente por el sistema de forma aleatoria, la cual está formada como sigue:

2 números + 2 letras mayúsculas + 2 números + 1 caracterespecial

Por ejemplo: “87JU65+”

Casos de UsoNarrativa Simple

1. El usuario indica que desea “Recuperar contraseña”.2. El sistema despliega la pregunta secreta elegida por el usuario al momento de registrarse.3. El usuario ingresa la respuesta.4. El sistema verifica que la respuesta sea coincidente.5. Si es coincidente, el sistema envía la nueva contraseña al correo electrónico del usuario, la cual estáformada por:

2 números + 2 letras mayúsculas + 2 números + 1 caracter especial

Por ejemplo: “87JU65+”

Casos de Uso

Secuencia

Acciones de Usuario Responsabilidades del Sistema

Indica “Recuperar contraseña.

Despliega la pregunta secreta elegida por el usuario.

Ingresa la respuesta. Verifica que la respuesta sea coincidente.

Si es coincidente, el sistema envía la nueva contraseña al correo electrónico del usuario, la cual estáformada por:2 números + 2 letras mayúsculas + 2 números + 1 caracter especialPor ejemplo: “87JU65+”

Casos de UsoConversación

- Los casos de uso deben escribirse utilizando el lenguaje del cliente.

- El nombre debe denotar una acción (verbo), como infinitivo o como sustantivo, por ejemplo: Generar informes ó Generación de informes.

- Redactar en presente y en voz activa (no pasiva).- Cada caso de uso debe estructurarse para que forme una

especificación de funcionalidad completa e intuitiva. No deberían estructurarse sólo casos de uso pequeños y no intuitivos para reducir redundancias; debe llegarse a un equilibrio entre comprensibilidad y mantenibilidad.

- Describir claramente la información que se intercambia entre un actor y el caso de uso

Casos de UsoConsideraciones

- Las especificaciones de requerimientos no deben considerar aspectos propios de la implementación ni tecnicismos. No describe los detalles de la interfaz de usuario, describe las acciones. Sin embargo los diseñadores y probadores necesitan un mayor detalle por lo que es altamente recomendable enfatizarlo siguiente:

- Entradas y salidas de información- Restricciones y validaciones- Detalle de los algoritmos- Características de los datos (obligatoriedad, longitud, tipo)

- También pueden incluirse “Notas técnicas” dentro del Caso de Uso, identificadas de tal manera que no se confundan con la especificación base ya que son irrelevantes para el usuario.

Casos de UsoConsideraciones

- Pueden utilizarse los diagramas de estado para describir los estados de algún objeto de negocio derivado de los casos de uso y las transiciones entre estos.

- Pueden utilizarse los diagramas de actividad para describir las secuencias de acción de un caso de uso, los flujos de trabajo asociados a un caso de uso, o la secuencia de varios casos de uso del sistema.

- Pueden utilizarse los diagramas de secuencia para describir la interacción entre el actor y el caso de uso.

Diagramas complementarios

Casos de Uso

- Un escenario es una instancia de un caso de uso.- Es una ruta que muestra una combinación particular de

condiciones en un caso de uso.- Un Caso de Prueba es un conjunto de entradas de

prueba, condiciones de ejecución y resultados esperados desarrollados para probar un camino concreto a través de un Caso de Uso

- Escenarios primarios.- Flujo normal. La forma en la que debe trabajar

normalmente el sistema.- Escenarios secundarios.- Excepciones del escenario primario.

Casos de UsoEscenarios

Programacion inicio

Documents

Transcript of Programacion inicio