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 - hello@prezzo.com
→
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 - hello@prezzo.com
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 Construccionde SW
comparado Industriade Const.
Planteamiento
Herramientas
Procesos
Metodos
Arquitectura

5 Tecnicaso 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 Robustez
Modelado El sistema con
tres tipos de objetos
Analisis
diseño
Iimplementación
Descripciones de
entorno
Los diagramas de
interacción
Gráficos de transición de
estado
Un modelo de objeto
Implementación
Có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 Tecnicasde 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

Primera Etapa
Modelo de Requerimientos
Un modelo de requerimientos es creado para especificar toda la
funcionalidad del sistema. Consiste en tres partes.
Modelo de Casode 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 deUso
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
inherits
Cliente 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 Analisis
Aquí 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 cliente
Paquete alarma
e impresora

III MODELO DE DISEÑO
O llamado Modelo de Plan

← →
Modelo Diseño
Diseño
Modelo de Diseño
Adapta 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
Crear
Iniciar
Item()
activar
nuevo Item
Panel cliente
Receptor de
items
Borde 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

← →
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á.
Traceabilidad
Comunicació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

← →
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 sistema
Ayuda a la localización de faltas y la traceabilidad ayuda al movimiento dentro del Modelo
Del 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 empleado
3. 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

← →
Comparativaconlas metodologías contemporáneasa 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.

← →
Comparativaconlas metodologías contemporáneasa Jacobson
Comparativa con las metodologías contemporáneas a Jacobson
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 los
usuarios 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 del
sistema.
 La notación que el método utiliza es bastante diferente.
 Esta metodología favorece el desarrollo del equipo.

OOSE

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à OOSE

Similaire à OOSE (20)

Plus de Daniel Cam Urquizo

Plus de Daniel Cam Urquizo (13)

OOSE