Ingeniería de Requerimientos

LABORATORIO N° 12

Diseño orientado a objetos

CODIGO DEL CURSO:

Alumno(s) Nota

Huanca Huarachi Bladimir

Grupo A
Ciclo lll
Fecha de entrega 14/06/2018

DISEÑO DE SOFTWARE E INTEGRACIÓN DE SISTEMAS

PROGRAMA DE FORMACIÓN REGULAR
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 1 de 17

I.- OBJETIVOS:

 Aplicar el diseño orientado a objetos.

II.- SEGURIDAD:
Advertencia:
En este laboratorio está prohibida la manipulación del
hardware, conexiones eléctricas o de red; así como la
ingestión de alimentos o bebidas.

III.- NORMAS EMPLEADAS:

 No aplica

IV.- RECURSOS:

 En este laboratorio cada alumno trabajará con un equipo con Windows 10.

V.- METODOLOGÍA PARA EL DESARROLLO DE LA TAREA:

 El desarrollo del laboratorio es INDIVIDUAL.

VI.- MARCO TEÓRICO:

ANALISIS Y DISEÑO ORIENTADO A OBJETOS

El análisis y diseño orientado a objetos (ADOO) es un enfoque de la ingeniería de software que modela un sistema
como un grupo de objetos que interactúan entre sí. Este enfoque representa un domino absoluto en términos de
conceptos compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional. Todo sistema
de información requiere de artefactos o componentes (clases) para llevar a cabo tareas; es de gran importancia
dentro de la ingeniería de software tener un buen “análisis y diseño” para un mejor desarrollo, que conlleva a que
tan “escalabre” sea un sistema de información.

En este método de análisis y diseño se crea un conjunto de modelos utilizando la notación acordada como, por
ejemplo, el lenguaje unificado de modelado (UML).

ADOO aplica técnicas de modelado de objetos para analizar los requerimientos para un contexto (por ejemplo, un
sistema de negocio, un conjunto de módulos de software) y para diseñar una solución para mejorar los procesos
involucrados.

No está restringido al diseño de programas de computadora, sino que cubre sistemas enteros de distinto tipo. Las
metodologías de análisis y diseño más modernas son “casos de uso” guiados a través de requerimientos, diseño,
implementación, pruebas, y despliegue.

El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estándar usado en análisis y diseño
orientado a objetos.

El diseño orientado a objetos (DOO) es una fase de la metodología orientada a objetos para el desarrollo de software.
Su uso induce a desarrolladores y programadores a pensar en términos de objetos, en vez de procedimientos,
cuando planifican el código.

Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La “interfaz del objeto”, esto
es, las formas de interactuar con el objeto, también se definen en esta etapa. Un programa orientado a objetos se
caracteriza por la interacción de esos objetos.

El diseño orientado a objetos es la disciplina que define los objetos y sus interacciones para resolver un problema
de negocio que fue identificado y documentado durante el análisis orientado a objetos (AOO).
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 2 de 17

ARQUITECTURA TRADICIONAL

 Estructuras de datos globales y pasivas

 Algoritmos que manipulan esa estructura de datos
 Serios problemas de acoplamiento

ARQUITECTURA ORIENTADA A OBJETOS

 Conjunto cooperante de objetos encapsulados que interactúa por medio del envío de mensajes.

 Un objeto es responsable de preservar la integridad de su representación (usualmente manteniendo algún

invariante).

 La representación se oculta a otros objetos.

 Los componentes de un sistema encapsulan los datos y las operaciones que se deben realizar para
manipular los datos. La comunicación y la coordinación entre componentes se consiguen a través del paso
de mensajes. La representación de los datos y sus operaciones primitivas son encapsuladas en un tipo de
datos abstracto u objeto.
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 3 de 17

 Entre sus características se tiene:

o Los componentes son los objetos, o instancias de tipos de datos abstractos.

o Estos objetos son de un tipo de componente denominado “manager”, porque es responsable de
preservar la integridad de un recurso.
o Los objetos interactúan a través de invocaciones a procedimientos y funciones.

 Entre sus ventajas se tiene:

o Como un objeto oculta su representación a sus clientes, es posible cambiar su implementación sin
modificar los clientes: modificabilidad.
o La integración de un conjunto de rutinas de acceso con los datos que manipulan permite a los
diseñadores descomponer los problemas en colecciones de agentes que interactúan.

 Entre sus desventajas se tiene:

o Para que un objeto interactúe con otro (mediante la invocación a un procedimiento) debe conocer
la identidad del otro objeto. Luego, cuando la identidad de un objeto cambie es necesario modificar
todas las invocaciones a tal objeto.
o Se pueden presentar efectos laterales: si los objetos A y C usan al objeto B, entonces los efectos
de C en B lucen como efectos laterales no esperados en A, y viceversa.

MODELOS DEL DISEÑO ORIENTADO A OBJETOS

El modelo del diseño puede verse en dos dimensiones distintas, como se ilustra en la figura siguiente:

Figura 1. Dimensiones del modelo de diseño

La dimensión del proceso indica la evolución del modelo de diseño conforme se ejecutan las tareas de éste como
parte del proceso del Software. La dimensión de la abstracción representa el nivel de detalle a medida que cada
elemento del modelo de análisis se transforma en un equivalente de diseño y luego se mejora en forma iterativa.

La línea punteada indica la frontera entre los modelos de análisis y de diseño. En ciertos casos, es posible hacer
una distinción entre ambos modelos. En otros, el modelo de análisis se mezcla poco a poco con el de diseño y la
distinción es menos obvia.

Los modelos de diseño pueden ser estáticos y dinámicos:

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 4 de 17

 Estáticos: Estructura de subsistemas y/o clases, y sus relaciones. Se describe la estructura estática (de
datos), de los objetos del sistema (identidad, atributos y operaciones) y también sus relaciones. El modelo
de objetos contiene diagramas de objetos. Un diagrama de objetos es un grafo cuyos nodos son clases
de objetos y cuyos arcos son relaciones entre las clases. El diagrama contiene clases de objetos
organizados en jerarquías que comparten una estructura y comportamiento comunes y que están asociadas
a otras clases. Estas clases definen los atributos que lleva cada instancia de objeto y las operaciones que
efectúa o sufre cada uno. En cada instancia de la clase se guardan los valores de esos atributos.

o Diagrama de objetos: En UML, diagrama que muestra una vista completa o parcial de los objetos
de un sistema en un instante de ejecución específico. Es un gráfico de instancias, incluyendo objetos
y datos, de un diagrama de clases; muestra una “foto” del estado de un sistema en un punto de
tiempo determinado. Por tanto, comparten virtualmente los mismos símbolos de notación que los
diagramas de clases. Se generan en las disciplinas de arquitectura y diseño. Se utilizan para mostrar
estructuras de datos y las interacciones que existen entre objetos en tiempo de ejecución.

Figura 2. Diagrama de objetos vs. Diagrama de clases

Un diagrama de objetos se enfoca en los atributos de un conjunto de objetos y cómo estos objetos
se relacionan entre sí.

Figura 3. Diagrama de objetos de una clase Bank

Hay muchos casos en los que un desarrollador le resultaría útiles los diagramas de objetos. Dichos
casos incluyen:

- Revisión de una iteración específica de un sistema general.

- Obtención de una vista de nivel alto del sistema que desarrollarás.
- Prueba de un diagrama de clases que se creó para la estructura general del sistema, por
medio de diagramas de objetos para casos de uso específicos.

Los elementos de un diagrama de objetos son:

- Objetos
- Títulos de clases
- Atributos de clases
- Enlaces
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 5 de 17

Figura 4. Diagrama de objetos corporativo

 Dinámicos: Se describen las estructuras que muestra la interacción entre objetos. Ejemplos de UML:
diagramas de secuencia, diagramas de estado. Describen los aspectos de comportamiento (de control) de
un sistema que cambian con el tiempo. El modelo dinámico se utiliza para especificar e implementar los
aspectos del control del sistema. Los modelos dinámicos contienen diagramas de estados. Un diagrama
de estados es un grafo cuyos nodos son estados y cuyos arcos son transiciones entre estados causadas
por sucesos o eventos. Se especifican en este modelo la temporización y secuencia de operaciones
(sucesos que marcan los cambios, secuencias de sucesos, estados que definen el contexto para los
sucesos), y la organización de sucesos y de estados. El modelo dinámico captura el control, aquel aspecto
de un sistema que describe las secuencias de operaciones que se producen sin tener en cuenta lo que
hagan las operaciones, aquello a lo que afecten o la forma en la que estén implementadas. Las acciones
de los diagramas de estado se corresponden con funciones procedentes del modelo funcional; los sucesos
de un diagrama de estado pasan a ser operaciones que se aplican a objetos dentro del modelo de objetos.

o Diagramas de estado: Muestran una máquina de estado. Son útiles para modelar la vida de un
objeto. Muestran el flujo de control entre estados (en qué estados posibles puede estar “cierto algo”
y cómo se producen los cambios entre dichos estados). P. ej.: De la pregunta “¿en qué estado (de
ánimo) se encuentra usted y cómo cambia su estado de ánimo?”, se tiene el siguiente diagrama de
estados:

Figura 5. Ejemplo 1 de diagrama de estados

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 6 de 17

Un estado es una condición o situación en la vida de un objeto durante la cual satisface una condición,
realiza alguna actividad o espera algún evento.

Un evento es la especificación de un acontecimiento significativo que ocupa un lugar en el tiempo y en el

espacio. Es la aparición de un estímulo que puede (o no) activar una transición de estado.

Una transición es una relación entre dos estados que indica que un objeto que esté en el primer estado
realizará ciertas acciones y entrará en el segundo estado cuando ocurra un evento especificado y se
satisfagan unas condiciones especificadas.

Figura 6. Extensión ejemplo 1 Diagrama de Estados

Figura 7. Ejemplo 2 Diagrama de Estados

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 7 de 17

Figura 8. Ejemplo 3 Diagrama de Estados

Figura 9. Ejemplo 4 Diagrama de Estados

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 8 de 17

Figura 10. Extensión Ejemplo 4

Figura 11. Extensión Ejemplo 4

o Diagrama de casos de uso: Es una forma de diagrama de comportamiento UML mejorado. Los
diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras que los
conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de
casos de uso. El diagrama de casos de uso puede representar uno o varios casos de uso. Hay que
tener en cuenta que cada caso de uso representa una funcionalidad del Software que se va a
construir.

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema
en desarrollo, además de la forma, tipo y orden en cómo los elementos interactúan (operaciones o
casos de uso).

Los elementos de un diagrama de casos de uso son:

- Caso de uso
- Actor
- Comunicación
- Entorno del sistema
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 9 de 17

Figura 12. Componentes de Diagrama de Casos de Uso

Figura 13. Ejemplo 1 Diagrama de Casos de Uso

Cada caso de uso se describe utilizando plantillas en lenguaje natural:

Caso de uso
Actores
Resumen
Pre-condiciones
Post-condiciones
Incluye
Extiende
Hereda de
Flujo de eventos
Actor Sistema
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 10 de 17

Como ejemplo:

Caso de uso Reservar libro

Actores Socio
Resumen El socio puede solicitar la reserva de un libro
para su posterior préstamo, a partir de una
fecha determinada
Pre-condiciones El socio no tiene ninguna reserva
Post-condiciones El socio tiene una reserva y el libro tiene una
nueva reserva a partir de una fecha
Incluye
Extiende
Hereda de
Flujo de eventos
Actor Sistema
Evento 1. El socio Evento 2. El sistema comprueba que el socio
solicita la reserva no tiene reserva.
(código, libro, fecha). Evento 3. El sistema comprueba que el libro
está libre para la fecha solicitada.
Evento 4. El sistema solicita confirmación de
Evento 5. El socio la reserva.
confirma la reserva

Evento 6. El sistema realiza la reserva.

Las relaciones entre casos de uso son:

- Inclusión
- Extensión
- Herencia

Las relaciones entre los actores son:

- Herencia

Relaciones entre casos de uso – Inclusión: Un caso de uso A incluye a un caso de uso B, si una
instancia de A puede realizar todos los eventos que aparecen descritos en B.

Figura 14. Relación de Inclusión

Siempre que se ejecute “Baja Socio”, se ejecutará “Buscar Socio”.

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 11 de 17

Relaciones entre casos de uso – Extensión: Un caso de uso B extiende a un caso de uso A, si
en la descripción de A figura una condición cuyo cumplimiento origina la ejecución de todos los
eventos que aparecen descritos en B.

Figura 15. Relación de Extensión

Relaciones entre casos de uso – Herencia: Un caso de uso B especializa a un caso de uso A, si
el flujo de eventos de B es un refinamiento de flujo de eventos de A.

Figura 16. Relación de Herencia

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 12 de 17

Relaciones entre actores:

Actor antecesor

Actores
descendientes

Figura 17. Relación de Herencia entre Actores

Como ejemplo se tiene el siguiente:

Figura 18. Diagrama de Casos de Uso

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 13 de 17

VII.- PROCEDIMIENTO:

De acuerdo al marco teórico alcanzado, considerar el siguiente caso a resolver:

“Un sistema de ventas de productos diversos, el cual emite boletas de pago o facturas, según requerimiento del
cliente, por producto(s) vendido(s). La venta únicamente puede ser efectuada por un cajero, quien registra los
datos principales del cliente y de los productos que se están vendiendo. Los productos deben ser buscados por su
categoría, para luego ser agregados al comprobante de pago.
De acuerdo a la cantidad de productos que ha comprado el cliente, se determinará si tiene alcance a un descuento
en su próxima compra, estableciéndose las fechas de inicio y fin de tal descuento. Para ello, un encargado de
Post-Venta revisará las cantidades compradas por los clientes a la fecha, determinará el descuento y lo comunicará
al cliente, vía correo electrónico.
El sistema debe tener la capacidad de emitir reportes de ventas efectuadas en un tiempo determinado, los cuales
se entregarán al gerente de ventas.”
 Registrar Datos del Cliente
 Registrar Datos del Producto
 Conceder Descuento
 Comunicar Descuento
 Emitir Reportes

El informe debe contener:

 Plantillas de casos de uso (de acuerdo a los requerimientos funcionales)
Caso de uso Registrar datos del cliente
Actores Cajero
Resumen El cliente deberá ingresar sus datos para que
el cajero pueda registrarlos
Pre-condiciones El cliente no obtiene descuentos aun
Post-condiciones El cajero registrara los datos del cliente
Incluye
Extiende
Hereda de
Flujo de eventos
Actor Sistema
Evento 1. El cajero pide Evento 2. El sistema guardara esos datos del
que ingrese los datos cliente
del sistema

Evento 5. El cajero
procederá ahora con los
productos
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 14 de 17

Caso de uso Registrar datos del producto

Actores Cajero
Resumen El cajero también registrara los datos del
producto
Pre-condiciones Los productos aun no tendrán descuento
Post-condiciones
Incluye
Extiende
Hereda de
Flujo de eventos
Actor Sistema
Evento 1. El cajero Evento 2. El sistema almacenara los datos del
registrara los datos del producto junto con los del cliente en el BD
producto que se está
vendiendo
Evento 2. El cajero
agregara los datos al
comprobante de pago

Caso de uso Generar Reportes

Actores Sistema
Resumen Se podrá hacer reportes de las ventas
efectuadas
Pre-condiciones
Post-condiciones Estos reportes lo hara el sistema
Incluye
Extiende
Hereda de
Flujo de eventos
Actor Sistema
Evento 1. El sistema Evento 2. Estos reportes serán entregados al
generara los reportes gerente de ventas
de las ventas
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 15 de 17

 Diagramas de casos de uso

 Diagrama de clases (considerando todos los tipos de relación que se puedan establecer)

 Diagrama de objetos (de acuerdo a las clases000000000 indicadas en el diagrama)

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 16 de 17

 Diagrama de estados (de acuerdo a los cambios de estado que se puedan producir en el sistema)

El informe se presentará a muy tardar el día jueves 14-06-2018, a las 23.50 horas, adjuntándolo en la plataforma
Canvas.
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 17 de 17

OBSERVACIONES Y CONCLUSIONES
- Cuando terminamos el análisis tenemos ya una comprensión mayor del problema
- Sabemos cuales son las abstracciones claves, y empezamos a estudiar como se desenvuelve la aplicación
en el tiempo.
- También expresan los requerimientos funcionales que los usuarios comunicaron al sistema durante la
redacción del pliego de condiciones.
- Comprobar que el sistema cumple dichos requisitos en el momento de la entrega.
- Determinar las fronteras del sistema.
- Escribir la documentación del sistema.
- Confeccionar juegos de test.