oose

Barreto Valderrama Lizbeth

Cam Urquizo Daniel

Castañeda Gallardo Carlos

Gutierrez Romero Fabio

OOSE (Object-oriented Software Engineering)

→

← →

Index.

Introducción

Prezzo - 42 Wallaby Way, Sydney - prezzo.com - [email protected]

→

Planteamiento→

Etapas de OOSE→

Ejemplo→

Conclusiones→

OOSE

Breve Introduccion a OOSE

← →

INTRODUCCION

Con la aparición de la

orientación a objetos se vio la

necesidad de crear metodologia

eficaces ´para modelas estos

nuevos sistemas.(OMT, Booch,

OSEE).

OOSE. Fue desarrollado por Ivar

Jacobson (02-09-1939). Sueco.

Ingeniero Electronico (Instituto

de la Tecnologia de Chalmers en

Gotemburgo - 1968). Clave en el

desarrollo de UML, junto a

James Rumbaung (Object-

Modeling Technique) y Grady

Booch (método de Boch). (RUP)

Objectory AB primera

herramienta de OOSE. Esta se

Fusionó con Rational y las

herramientas de OOSE fueron

remplazadas por Rational. Con

el desarrollo de UML y Met.

RUP, OSEE se estaba

convirtiendo en obsoleto.

OSEE 1992 (Utilizar Use Case

para describir el Sistema) OOSE

es el primero en utilizar el

concepto de casos de uso para

definir los paradigmas de diseño

de software.


Analisis Diseño Implementacion Pruebas

← →Prezzo - 42 Wallaby Way, Sydney - prezzo.com - [email protected]

Soportan los aspectos de la empresa,

como act. Arquitectura, métodos y

procesos.

Permite escalamiento de métodos.

(aplicado forma interactiva y en partes).

Estable Explicita los procedimientos etapa

por etapa.

Una buena estructura del sist. es facil de

entender, cambiar, test y mantem.

(importantes y forman base del método).

Diseño y Construccion de SW comparado Industria de Const.

Planteamiento

Herramientas

Procesos

Metodos

Arquitectura



5 Tecnicas o Etapas Planteadas por Jacobson

Planteamiento

Analisis

Analisis

Modelo requerimientos

Modelo de analisis

Construccion

Modelo de diseño

Implementacion

Prueba Prueba


← →

El análisis de

requerimientos.Modelado de casos de uso

Diseño de interfaz de

usuario

Un modelo de dominio

Análisis de RobustezModelado El sistema con

tres tipos de objetos

Analisis

diseñoIimplementación

Descripciones de

entorno

Los diagramas de

interacción

Gráficos de transición de

estado

Un modelo de objeto

ImplementaciónCódigo Fuente

Cosntrucción

Prueba de la unidad

Las pruebas de

integración

Las pruebas del

sistema

Pruebas


Etapas de OOSE Analisis Diseño Implementacion Pruebas

← →

Limita Sistema y esp el

comportamiento. (Use

Case, descrp. GUI,

problem domian model).

Modelado Requerimientos

Plantemiento de las 5 Tecnicas de OOSE

Producir una estructura

ideal, robusta y

modificable de un objeto.

Modelado Análisis

Refina los objetos.

Mateniendo una

ambiente de

implementacion.

(diagram interacction,

diagram transition state).

Modelado Diseño


Planteamiento

Codigo Fuente de los

Objetos especificados

en Modelo Diseño.

Modelado Impl.Comprobar y verificar la

funcionalidad del

Sistema.

Modelo Prueba


I Modelo de Requerimientos


Primera Etapa

Modelo de Requerimientos

Un modelo de requerimientos es creado para especificar toda la funcionalidad del sistema. Consiste en tres partes.

Modelo de Caso de Uso

Idealización de un

persona externa (Rol) u

otro sist. Que interactua

con otro, subsistema,

clase.

Actor

Es una unidad o tarea de

funcionalidad.

… Asociaciones,

escenarios(mas general).

Caso de Uso

Representan las funciones que un sistema puede ejecutar.



Primera Etapa About Portfolio Data Contact

Análisis de Requerimientos




Descripción de Interfaces

Es importante que los usuarios estén envueltos en las descripciones de las interfaces

detalladas.

Modelo de Dominio de Objeto

Se define los conceptos con los que el sistema debe trabajar, muestra las instancias de

objetos, clases y relación de asociaciones.




Modelo de Dominio de Objeto

inherits

inheritsCliente Base

0...N

Contiene

Cliente individual

Grupo Cliente

Cliente

II MODELO DE ANALISIS

Llamado tambien Analisis de Estructura

← →

Analisis

OBJECT-ORIENTED SOFTWARE ENGINEERING

Analisis

Modelo de AnalisisAquí se define la

estructura lógica del sistema independiente

de la aplicación.

El modelo de análisis es la

estructura más estable y mantenible

del sistema

Es el modelo producto de un análisis robustez

Especifica los objetos lógicos, su relación y

agrupacion

← →

Objetivos


• Reconocer los objetos que forman parte del Sistema • Proporciona una prueba de completitud a los casos de uso, antes de pasar al

diseño• Reconocer asociaciones y estructuras de objetos• Asignar atributos a los objetos• Asociar un objeto a sus atributos• Dividir el sistema en subsistemas (para preparar más adelante los paquetes).

Analisis

← →

Elementos


Consiste en operar diferentes entidades, realiza proceso y retorna resultado a un objeto

• Transporta la acción del

actor a los eventos del

sistema

• Cada actor puede tener su

conjunto de interfaces

Analisis

OBJETO DE CONTROL

← →

Elementos


• Modelan información

perdurable

• Modelo que captura datos

• Por lo general actúan como

controladores o

coordinadores del proceso

que se realice en los casos

de uso

Analisis

OBJETO DE ENTIDAD

← →

Elementos


Representar a las entidades

que gestionan las

transacciones entre el

sistema y los actores en el

mundo exterior.

• Describe la comunicación

bidireccional entre el

sistema y sus usuarios,

estos pueden ser los

sistemas humanos u otros

Analisis

OBJETO DE INTERFAZ

← →

Ejemplo diagrama


Analisis

Interface

Control Cliente

Cliente Cliente Base

Agregar Cliente

Operador

← →

Elementos


• Agrupan objetos en

niveles

• Reducen complejidad

de estructura

• La división es por

funcionalidad y

acoplamiento

Analisis

Subsistema

Receptor items

Panel de cliente Impresora

Dispositivo alarma

Paquete clientePaquete alarma

e impresora

III MODELO DE DISEÑO

O llamado Modelo de Plan

← →

Modelo Diseño


Diseño

Modelo de DiseñoAdapta el sistema al

ambiente de implementación que

será utilizado

Refinar el Modelo de Análisis tomando en

cuenta las características de implementación

Describe detalles de clases de diseño

Encontramos diagramas de

interacción y de estado de transición

← →

Subfases


Diseño

Determinación de características de

entorno de ejecución

• (DBMS, las características del lenguaje de programación, distribución consideraciones)

Definición de bloques

• Cada objeto en el modelo de análisis se asigna un bloque

• Añaden bloques de implementación

• Definición de interfaces y semánticas

Especificación de de interacción entre objetos y

comportamiento

• Diagrama de interacción

• Diagrama de estado de transición

← →

Diagrama de bloques


• Cada objeto de análisis simplemente se transforma en un bloque

• La división es por

funcionalidad y

acoplamiento

• Son llamado diagramas

de clases

Diseño

VentaCliente

← →

Diagrama de interacción:


• Describe lo que el uso incluye por lo que se refiere a comunicar los objetos

• Se dibujo para c/u de los casos de uso

• Se visualiza la interacción de envio y recibimiento de estimulo entre bloques

Diseño

CrearIniciar

Item()

activar

nuevo Item

Panel clienteReceptor de

itemsBorde sistema

← →

Grafo de transición de estado


• se utiliza para describir el comportamiento de cada bloque.

• Se usan para describir conducta del objeto por lo que se refiere a que pueden recibirse los estímulos y qué estímulos pueden causar

• Usa notación SDL

Diseño

Venta

IV Modelo de Implementación

← →

Modelo de Implementación

En esta etapa es cuando se procede a la ejecución del código fuente que ha sido seleccionado.Es la codificación del sistema tanto en el desarrollo de las Bases de Datos como las distintas Aplicaciones con las que contará.

TraceabilidadComunicación

entre clases

Leng. de Prog.

Clases Robustas

← →

Modelo de Implementación

Elaboración de los: Diagrama de Clases, Diagrama de Secuencias, Modelo Físico , Matriz de Funciones, Tranzabilidad de Casos de Uso

Programas Codificados y versionados en SVN, Pruebas de pares, manual de usuario, Línea Base en SVN

Diseño de la Aplicación

Construcción

V Modelo de Prueba

← →

Modelo de Prueba

En esta etapa se procede a probar tantos las aplicaciones como el funcionamiento de las Clases y la robustez del sistema.Se empieza por los niveles mas bajos del sistema :

- Modulos deObjetos y Bloques- El Desarrollo de la Aplicación.

← →

Modelo de Prueba

La comprobación de esta etapa es el Modelo de Requisito, ya que si se cuemplen todos los Requisitos allí especificados, para la aprobación. Aquí nuevamente la robustez del sistemaAyuda a la localización de faltas y la traceabilidad ayuda al movimiento dentro del ModeloDel Plan ( a donde la falta será corregida).

Rol de los Casos de Uso en el Testing

Aplicación del Método de Análisis Orientado a Objetos

← →

Caso de Estudio : Biblioteca

BIBLIOTECA

Circulación

Dirección

Usuario

Procesos Técnicos

← →

Biblioteca – Modelo de Requirimientos

Actor Casos de Uso

Personal de Procesos Técnicos

Registrar Usuario

Registrar Documento

Registrar Pago de Multas

Registrar Días Festivos

Dirección

Registrar Reglamento

Cancelación Automática Reser.

Generar Reporte Mens. Multas

Cierre de semestre

Usuario

Consulta por autor

Consulta por título

Consulta por reservas

Consulta de préstamos

Personal de Circulación Préstamo, reserva, liquidación

← →


Caso de Uso : Reservas

1. El empleado de circulación digita la opción para la realización de la reserva.2. La pantalla anterior aparece ante el empleado3. El empleado digita el código del empleado que va a realizar la reserva.4. Los campos nombre,estado,nro. de préstamos vencidos y nro. de multas

aparecen automáticamente en la pantalla y no son modificables.5. El empleado digita el número de indización, el volumen y la fecha.6. Aparecen automáticamente en la pantalla los campos título y categoría, estos

no son modificables.7. Si el usuario desea reservar otro libro, el empleado repite los pasos 5 y 6.8. Cuando no haya más libros para reservar, entonces el empleado Acepta la

transición.

← →


Caso de Uso : Reservas

← →

Biblioteca – Modelo de Análisis


Biblioteca – Modelo de Diseño

← →

Biblioteca – Modelo de Aplicación - Pruebas

OOSE

Comparativa con las

metodologías contemporáneas

a Jacobson

← →

Comparativa con las metodologías contemporáneas a Jacobson


METODOLOGIAS

Ingeniería de software

orientado a objetos OOSE

Técnica de modelado de

objetos OMT

Metodología Booch

DESARROLLADOR

Desarrollada por Ivar Jacobson. Desarrollada por James

Rumbaugh.

Desarrollada por Grady

Booch.

FUNCIONALIDAD

El modelo de caso de uso sirve

como modelo central.

Describe el análisis y diseño

orientado a objetos, que

incorporan tanto

comportamiento

como estructuras de datos.

La realización de modelos es

muy importante para la

construcción de sistemas

complejos.

ENFOQUE

El modelo de caso de uso es la

base en la etapa de análisis,

construcción y prueba.

La esencia del desarrollo es la

identificación y organización de

conceptos en el dominio del

problema.

La parte más importante en

el análisis y diseño

orientado a objetos es

la identificación de clases y

objetos.

← →



MODELOS

Presenta cinco técnicas para

modelar un sistema:

Modelo de requerimientos,

análisis, diseño, implementación

y prueba.

El sistema es descrito a partir

de tres modelos

diferentes: un modelo de

objetos, un modelo dinámico,

y un modelo funcional.

Propone cuatro modelos de

desarrollo orientado a

objetos: estructura física y

lógica y su

semántica estática y

dinámica.

FUNCIONALIDAD

MODELOS

Estos modelos capturan el

concepto inicial de todos los

requerimientos

funcionales y usar sus

perspectivas

Cada modelo describe un

aspecto del sistema pero

contiene referencias a los

demás

Modelos, por eso no son

totalmente independientes.

Los aspectos metodológicos

fueron incorporados en

varias metodologías y

procesos, siendo la principal

el Proceso Racional

Unificado (RUP).

FUERZA

Método fuerte para producir

requisitos orientados al usuario y

orientada a objetos modelo de

análisis.

Método fuerte para la

producción de modelo de

objetos de estructura estática

del sistema.

Método fuerte para la

producción

orientada a objetos

detallados

modelos de diseño.

DEBILIDAD

No trate la programación

orientada a objetos al mismo

nivel que otros métodos.

No se puede expresar

plenamente los requisitos.

Centrarse exclusivamente

en el

diseño y no en análisis.

← →

Conclusiones

Este es el método más completo.

Tiene características favorables para los sistemas que requieren la participación de losusuarios y los expertos.

Los casos de uso conducen a lo largo del desarrollo del sistema.

Tiende a asegurar un sistema es consistente y coherente.

El uso de este tipo de objetos facilita las actualizaciones y el mantenimiento futuro delsistema.

La notación que el método utiliza es bastante diferente.

Esta metodología favorece el desarrollo del equipo.

Gracias

oose

Software

wallaby way

unidadlas pruebas

modelado de casos

modelado anlisisrefina

modelado impl

modelado diseoprezzo

anlisis de requerimientos

diagram interacction