Guia 5 DS Poo

SERVICIO NACIONAL DE APRENDIZAJE SENA
SISTEMA INTEGRADO DE GESTIÓN

Guía de Aprendizaje programa tecnológico ADSI
GUÍA 5 DE APRENDIZAJE
Desarrollo de Software.
Diagrama de clases.
NORMA DE COMPETENCIA
220501033
Diseñar el sistema de acuerdo con los requerimientos del cliente.
RESULTADO DE APRENDIZAJE
220501033 02
Diseñar la arquitectura del software, mediante la interpretación de las clases, objetos y
mecanismos de colaboración, utilizando herramientas tecnológicas de diseño, de
acuerdo con las tendencias de las tecnologías de la información y la comunicación.
DURACIÓN
16 HORAS
FECHA DE ENTREGA
NOVIEMBRE 30 DE 2017
1. Presentación
En la anterior guía 4 de desarrollo de software se estudió el paradigma orientado a

objetos, que es una clase y un objeto, a las características fundamentales del POO, a
construir un modelo conceptual y a llevar esto a código.
Se terminó la guía 4 con un ejercicio donde a partir de un enunciado o situación

problémica se identificaba los objetos que participan en esa situación particular. Esto
implica además de definir los atributos y métodos de los objetos, identificar las
relaciones que existen entre los objetos.
El ejercicio antes descrito debe ser aplicado en el proyecto de cada grupo de manera
que puedan con solvencia:
1) Los requerimientos funcionales

2) Los objetos que definen el mundo del problema
3) Los requerimientos no funcionales
4) Los atributos que son parte de los objetos
5) La codificación de los métodos de los objetos
Página 1 de 19
SERVICIO NACIONAL DE APRENDIZAJE SENA Versión: 02
GUÍA DE APRENDIZAJE
Fecha: 30/09/2013
Proceso Gestión de la Formación Profesional Integral Código: F004-P006-GFPI
Procedimiento Ejecución de la Formación Profesional Integral
6) Las relaciones existentes entre objetos y

7) La estructura básica necesaria de las clases.
En la presente guía realizamos las tareas propuestas por el Ingeniero Villalobos en su

libro de programación fundamental. De esta manera se espera que el aprendiz
aplique los conocimientos a casos y que esto lo prepare para desarrollar el mismo
ejercicio para su proyecto.
2. Profundización.
2.1 Actividades de transferencia del conocimiento. (validación)
2.1.1 Análisis del problema

La primera etapa en todo proceso de construcción de software consiste en tratar de
entender el problema que tiene el cliente, y expresar toda la información que él
suministre, de manera tal que cualquier otra persona del equipo de desarrollo pueda
entender sin dificultad lo que espera el cliente de la solución. Esta etapa se denomina
análisis y la salida de esta etapa la llamamos la especificación del problema.
Considere el caso de un ingeniero civil que se enfrenta al problema de construir una

carretera. Lo primero que éste debe hacer es tratar de entender y especificar el
problema que le plantean. Para eso debe tratar de identificar al menos tres aspectos
del problema: (1) los requerimientos del usuario (entre qué puntos quiere el cliente la
carretera, cuántos carriles debe tener, para qué tipo de tráfico debe ser la carretera),
(2) el mundo en el que debe resolverse el problema (el tipo de terreno, la cantidad de
lluvia, la temperatura), y (3) las restricciones y condiciones que plantea el cliente (el
presupuesto máximo, que las pendientes no sobrepasen el 5%). Sería una pérdida
de tiempo y de recursos para el ingeniero civil, intentar construir la carretera si no ha
entendido y definido claramente los tres puntos antes mencionados. Y más que
tiempo y recursos, habrá perdido algo muy importante en una profesión de servicio
como es la ingeniería, que es la confianza del cliente.
En general, todos los problemas se pueden dividir en estos tres aspectos. Por una
parte, se debe identificar lo que el cliente espera de la solución. Esto se denomina un
requerimiento funcional. En el caso de la programación, un requerimiento funcional
hace referencia a un servicio que el programa debe proveer al usuario. El segundo
aspecto que conforma un problema es el mundo o contexto en el que ocurre el
problema. Si alguien va a escribir un programa para una empresa, no le basta con
entender la funcionalidad que éste debe tener, sino que debe entender algunas cosas
de la estructura y funcionamiento de la empresa. Por ejemplo, si hay un
requerimiento funcional de calcular el salario de un empleado, la descripción del
problema debe incluir las normas de la empresa para calcular un salario. El tercer
Página 2 de 19
Fecha: 30/09/2013
aspecto que hay que considerar al definir un problema son los requerimientos no
funcionales, que corresponden a las restricciones o condiciones que impone el cliente
al programa que se le va a construir.
Fíjese que estos últimos se utilizan para limitar las soluciones posibles. En el caso del
programa de una empresa, una restricción podría ser el tiempo de entrega del
programa, o la cantidad de usuarios simultáneos que lo deben poder utilizar.
EJEMPLO
Objetivo: Identificar los aspectos que hacen parte de un problema.
El problema: Una empresa de aviación quiere construir un programa que le permita

buscar una ruta para ir de una ciudad a otra, usando únicamente los vuelos de los
que dispone la empresa. Se quiere utilizar este programa desde todas las agencias
de viaje del país.
Especificación del problema:
Evidencias:
TAREA 1:
Objetivo: Identificar los aspectos que forman parte de un problema.
El problema: un banco quiere crear un programa para manejar sus cajeros automáticos. Dicho
programa sólo debe permitir retirar dinero y consultar el saldo de una cuenta. Identifique y discuta
Página 3 de 19
Fecha: 30/09/2013
los aspectos que constituyen el problema. Si el enunciado no es explícito con respecto a algún
punto, intente imaginar la manera de completarlo.
Especificación del problema
Cliente
Usuario
Requerimiento Funcional
Mundo del problema
Requerimiento NO Funcional
2.2.2 Casos de estudio

Se presentan tres casos que se utilizaran durante la guía.
Caso de Estudio Nº 1: Un Empleado

Para este caso de estudio vamos a considerar un programa que administra la
información de un empleado.
El empleado tiene un nombre, un apellido, un género (masculino o femenino), una

fecha de nacimiento y una imagen asociada (su foto). Además, tiene una fecha de
ingreso a la empresa en la que trabaja y un salario básico asignado.
Desde el programa se debe poder realizar las siguientes operaciones: (1) calcular la
edad actual del empleado, (2) calcular la antigüedad en la empresa, (3) calcular las
prestaciones a las que tiene derecho en la empresa, (4) cambiar el salario del
empleado, y (5) cambiar el empleado.
Página 4 de 19
Fecha: 30/09/2013
Caso de Estudio Nº 2: Un Simulador Bancario

Una de las actividades más comunes en el mundo financiero es la realización de
simulaciones que permitan a los clientes saber el rendimiento de sus productos a
través del tiempo, contemplando diferentes escenarios y posibles situaciones que se
presenten.
Se quiere crear un programa que haga la simulación en el tiempo de la cuenta

bancaria de un cliente. Un cliente tiene un nombre y un número de cédula, el cual
identifica la cuenta. Una cuenta, por su parte, está constituida por tres productos
financieros básicos: (1) una cuenta de ahorros, (2) una cuenta corriente y (3) un
certificado de depósito a término (CDT). Estos productos son independientes y tienen
comportamientos particulares.
El saldo total de la cuenta es la suma de lo que el cliente tiene en cada uno de dichos
productos. En la cuenta corriente, el cliente puede depositar o retirar dinero. Su
principal característica es que no recibe ningún interés por el dinero que se encuentre
allí depositado. En la cuenta de ahorros, el cliente recibe un interés mensual del 0,6%
sobre el saldo. Cuando el cliente abre un CDT, define la cantidad de dinero que
quiere invertir y negocia con el banco el interés mensual que va a recibir. A diferencia
de la cuenta corriente o la cuenta de ahorros, en un CDT no se puede consignar ni
retirar dinero.
La única operación posible es cerrarlo, en cuyo caso, el dinero y sus intereses pasan
a la cuenta corriente. Se quiere que el programa permita a una persona simular el
manejo de sus productos bancarios, dándole las facilidades de: (1) hacer las
Página 5 de 19
Fecha: 30/09/2013
operaciones necesarias sobre los productos que conforman la cuenta, y (2) avanzar
mes por mes en el tiempo, para que el cliente pueda ver el resultado de sus
movimientos bancarios y el rendimiento de sus inversiones.
- Con el botón marcado como "Avanzar mes" el usuario puede avanzar un mes
en la simulación y ver los resultados de sus inversiones.
- Con los seis botones de la parte derecha de la ventana, el usuario puede
simular el manejo que va a hacer de los productos que forman parte de su
cuenta bancaria.
- En la parte media de la ventana, aparecen el saldo que tiene en cada producto
y el interés que está ganando en cada caso.
Caso de Estudio Nº 3: Un Triángulo

En este caso se quiere construir un programa que permita manejar un triángulo. Esta
figura geométrica está definida por tres puntos, cada uno de los cuales tiene dos
coordenadas X, Y. Un triángulo tiene además un color para las líneas y un color de
relleno. Un color por su parte, está definido por tres valores numéricos entre 0 y 255
(estándar RGB por Red-Green-Blue). El primer valor numérico define la intensidad en
rojo, el segundo en verde y el tercero en azul. Más información sobre esta manera de
representar los colores la puede encontrar por Internet. ¿Cuál es el código RGB del
color negro? ¿Y del color blanco? El programa debe permitir: (1) visualizar el
triángulo en la pantalla, (2) calcular el perímetro del triángulo, (3) calcular el área del
triángulo, (4) calcular la altura del triángulo, (5) cambiar el color del triángulo y (6)
cambiar las líneas del triángulo.
Página 6 de 19
Fecha: 30/09/2013
- Con los tres botones de la izquierda, el usuario puede cambiar los puntos que
definen el triángulo, el color de las líneas y el color del fondo.
- En la zona marcada como "Medidas en pixeles", el usuario puede ver el
perímetro, el área y la altura del triángulo (en píxeles).
- En la parte derecha aparece dibujado el triángulo descrito por sus tres puntos.
2.2.3 Comprensión y Especificación del Problema

Se quiere responder las siguientes preguntas: ¿cómo especificar un requerimiento
funcional?, ¿cómo saber si algo es un requerimiento funcional?, ¿cómo describir el
mundo del problema?
Requerimientos Funcionales
Un requerimiento funcional es una operación que el programa que se va a construir
debe proveer al usuario, y que está directamente relacionada con el problema que se
quiere resolver. Un requerimiento funcional se describe a través de cuatro elementos:
- Un identificador y un nombre.
- Un resumen de la operación.
- Las entradas (datos) que debe dar el usuario para que el programa pueda
realizar la operación.
- El resultado esperado de la operación. Hay tres tipos posibles de resultado en
un requerimiento funcional: (1) una modificación de un valor en el mundo del
problema, (2) el cálculo de un valor, o (3) una mezcla de los dos anteriores.
EJEMPLO
Objetivo: Ilustrar la manera de documentar los requerimientos funcionales de un
problema.
Solución: En este ejemplo se documenta uno de los requerimientos funcionales del
Página 7 de 19
Fecha: 30/09/2013
caso de estudio del empleado. Para esto se describen los cuatro elementos que lo
componen.
Para determinar si algo es o no un requerimiento funcional, es conveniente hacerse

tres preguntas:
- ¿Poder realizar esta operación es una de las razones por las cuales el cliente
necesita construir un programa? Esto descarta todas las opciones que están
relacionadas con el manejo de la interfaz ("poder cambiar el tamaño de la
ventana", por ejemplo) y todos los requerimientos no funcionales, que no
corresponden a operaciones sino a restricciones.
Página 8 de 19
Fecha: 30/09/2013
- ¿La operación no es ambigua? La idea es descartar que haya más de una

interpretación posible de la operación.
- ¿La operación tiene un comienzo y un fin? Hay que descartar las operaciones
que implican una responsabilidad continua (por ejemplo, "mantener
actualizada la información del empleado") y tratar de buscar operaciones
puntuales que correspondan a acciones que puedan ser hechas por el usuario.
Evidencias:
TAREA 2:
Objetivo: Crear habilidad en la identificación y especificación de requerimientos funcionales. Para
el caso de estudio 2, un simulador bancario, identifique y especifique tres requerimientos
funcionales.
Requerimiento Funcional 1
Nombre
Resumen
Entradas
Resultado
Nombre
Resumen
Entradas
Resultado
Página 9 de 19
Fecha: 30/09/2013
Nombre
Resumen
Entradas
Resultado
TAREA 3
Objetivo: Crear habilidad en la identificación y especificación de requerimientos funcionales.
Para el caso de estudio 3, un programa para manejar un triángulo, identifique y especifique tres
requerimientos funcionales.
Nombre
Resumen
Entradas
Resultado
Página 10 de 19
Fecha: 30/09/2013
Nombre
Resumen
Entradas
Resultado
Nombre
Resumen
Entradas
Resultado
El Modelo del Mundo del Problema

En este segundo componente del análisis, el objetivo es entender el mundo en el que
ocurre el problema y recopilar toda la información necesaria para que el programador
pueda escribir el programa. Suponga por ejemplo que existe un requerimiento de
calcular los días de vacaciones a los que tiene derecho el empleado. Si durante la
etapa de análisis no se recoge la información de la empresa que hace referencia a la
manera de calcular el número de días de vacaciones a los cuales un empleado tiene
derecho, cuando el programador trate de resolver el problema se va a dar cuenta de
que no tiene toda la información que necesita. Ya no nos vamos a concentrar en las
opciones que el cliente quiere que tenga el programa, sino nos vamos a concentrar
en entender cómo es el mundo en el que ocurre el problema.
En el caso de estudio del empleado, el objetivo de esta parte sería entender y
Página 11 de 19
Fecha: 30/09/2013
especificar los aspectos relevantes de la empresa. Como salida de esta actividad, se

debe producir lo que se denomina un modelo del mundo del problema, en el cual
hayamos identificado todos los elementos del mundo que participan en el problema,
con sus principales características y relaciones.
Este modelo será utilizado en la etapa de diseño para definir los elementos básicos
del programa. Esta actividad está basada en un proceso de "observación" del mundo
del problema, puesto que los elementos que allí aparecen ya existen y nuestro
objetivo no es opinar sobre ellos (o proponer cambiarlos), sino simplemente
identificarlos y describirlos para que esta información sea utilizada más adelante.
En la figura de abajo se resumen las cuatro actividades que debe realizar el

programador para construir el modelo del mundo. En la primera, se identifica lo que
denominamos las entidades del mundo, en la segunda se documentan las
características de cada una de ellas, en la tercera se definen las relaciones que
existen entre las distintas entidades y, finalmente, se documenta la información
adicional (reglas, restricciones, etc.) que se tenga sobre las entidades.
Para expresar el modelo del mundo utilizaremos la sintaxis definida en el diagrama

de clases del lenguaje de modelos UML (Unified Modeling Language). Dicho lenguaje
es un estándar definido por una organización llamada OMG (Object Management
Group) y utilizado por una gran cantidad de empresas en el mundo para expresar sus
modelos.
Identificar las Entidades

Esta primera actividad tiene como objetivo identificar los elementos del mundo que
intervienen en el problema. Dichos elementos pueden ser concretos (una persona, un
vehículo) o abstractos (una cuenta bancaria). Por ahora únicamente queremos
identificar estos elementos y asociarles un nombre significativo. Una primera pista
para localizarlos es buscar los sustantivos del enunciado del problema. Esto sirve en
el caso de problemas pequeños, pero no es generalizable a problemas de mayor
dimensión.
Para el primer caso de estudio, hay dos entidades en el mundo del problema: la clase
Empleado y la clase Fecha. Esta última se emplea para representar el concepto de
fecha de nacimiento y fecha de ingreso a la empresa. Si lee con detenimiento el
enunciado del caso, se podrá dar cuenta de que éstos son los únicos elementos del
mundo del problema que se mencionan. Lo demás corresponde a características de
dichas entidades (el nombre, el apellido, etc.) o a requerimientos funcionales.
EJEMPLO
Objetivo: Ilustrar la manera de identificar las entidades (llamadas también clases) del
Página 12 de 19
Fecha: 30/09/2013
mundo del problema.

En este ejemplo se identifican las entidades que forman parte del mundo del
problema para el caso 2 de este nivel: un simulador bancario.
TAREA 4:
Objetivo: Identificar las entidades del mundo para el caso de estudio 3: un programa que maneje
un triángulo.
Lea el enunciado del caso y trate de guiarse por los sustantivos para identificar las entidades del
mundo del problema.
Página 13 de 19
Fecha: 30/09/2013
SOLUCIÓN
ENTIDAD (OBJETO) Descripción
Punto de reflexión: ¿Qué pasa si no identificamos bien las entidades del mundo?
Punto de reflexión: ¿Cómo decidir si se trata efectivamente de una entidad y no sólo de una
característica de una entidad ya identificada?
Modelar las Características

Una vez que se han identificado las entidades del mundo del problema, el siguiente
paso es identificar y modelar sus características. A cada característica que vayamos
encontrando, le debemos asociar (1) un nombre significativo y (2) una descripción del
conjunto de valores que dicha característica puede tomar.
En programación orientada a objetos, las características se denominan atributos y, al

igual que las clases, serán elementos fundamentales tanto en el diseño como en la
implementación. El nombre de un atributo debe ser una cadena de caracteres no
vacía, que empiece con una letra y que no contenga espacios en blanco.
En el lenguaje UML, una clase se dibuja como un cuadrado con tres zonas (ver
ejemplo 5): la primera de ellas con el nombre de la clase y, la segunda, con los
atributos de la misma. El uso de la tercera zona la veremos más adelante, en la etapa
de diseño.
EJEMPLO
Objetivo: Mostrar la manera de identificar y modelar los atributos de una clase.
Página 14 de 19
Fecha: 30/09/2013
En este ejemplo se identifican las características de las clases Empleado y Fecha

para el caso de estudio del empleado.
Clase: Empleado
Página 15 de 19
Fecha: 30/09/2013
Clase: Fecha
Con las tres características anteriores queda completamente definida una fecha. Esa
es la pregunta que nos debemos hacer cuando estamos en esta etapa: ¿es
necesaria más información para describir la entidad que estamos representando? Si
encontramos una característica cuyos valores posibles no son simples, como
números, cadenas de caracteres, o una lista de valores, nos debemos preguntar si
dicha característica no es más bien otra entidad que no identificamos en la etapa
anterior. Si es el caso, simplemente la debemos agregar.
Es importante que antes de agregar un atributo a una clase, verifiquemos que dicha
Página 16 de 19
Fecha: 30/09/2013
característica forma parte del problema que se quiere resolver. Podríamos pensar,
por ejemplo, que la ciudad en la que nació el empleado es uno de sus atributos.
¿Cómo saber si lo debemos o no agregar? La respuesta es que hay que mirar los
requerimientos funcionales y ver si dicha característica es utilizada o referenciada
desde alguno de ellos.
TAREA 5:
Para cada una de las cuatro entidades identificadas en el caso de estudio del simulador bancario,
identifique los atributos, sus valores posibles, y escriba la clase en UML. No incluya las relaciones
que puedan existir entre las clases, ya que eso lo haremos en la siguiente etapa del análisis. Por
ahora trate de identificar las características de las entidades que son importantes para los
requerimientos funcionales.
SOLUCIÓN
Clase: SimuladorBancario
ATRIBUTO VALORES POSIBLES
Diagrama UML:
Clase: CuentaCorriente
Página 17 de 19
Fecha: 30/09/2013
Diagrama UML:
Clase: CuentaAhorros
Diagrama UML:
Clase: CDT
Página 18 de 19
Fecha: 30/09/2013
Diagrama UML:
Las Relaciones entre las Entidades
3. BIBLIOGRAFÍA

Página 19 de 19

Guia 5 DS Poo

Cargado por

Copyright:

Formatos disponibles

Guia 5 DS Poo

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guia 5 DS Poo

Cargado por

Copyright:

Formatos disponibles

SERVICIO NACIONAL DE APRENDIZAJE SENA

SISTEMA INTEGRADO DE GESTIÓN

En la anterior guía 4 de desarrollo de software se estudió el paradigma orientado a

Se terminó la guía 4 con un ejercicio donde a partir de un enunciado o situación

1) Los requerimientos funcionales

6) Las relaciones existentes entre objetos y

En la presente guía realizamos las tareas propuestas por el Ingeniero Villalobos en su

2.1 Actividades de transferencia del conocimiento. (validación)

2.1.1 Análisis del problema

Considere el caso de un ingeniero civil que se enfrenta al problema de construir una

El problema: Una empresa de aviación quiere construir un programa que le permita

Especificación del problema:

Mundo del problema

2.2.2 Casos de estudio

Caso de Estudio Nº 1: Un Empleado

El empleado tiene un nombre, un apellido, un género (masculino o femenino), una

Caso de Estudio Nº 2: Un Simulador Bancario

Se quiere crear un programa que haga la simulación en el tiempo de la cuenta

Caso de Estudio Nº 3: Un Triángulo

2.2.3 Comprensión y Especificación del Problema

Para determinar si algo es o no un requerimiento funcional, es conveniente hacerse

- ¿La operación no es ambigua? La idea es descartar que haya más de una

El Modelo del Mundo del Problema

especificar los aspectos relevantes de la empresa. Como salida de esta actividad, se

En la figura de abajo se resumen las cuatro actividades que debe realizar el

Para expresar el modelo del mundo utilizaremos la sintaxis definida en el diagrama

Identificar las Entidades

mundo del problema.

ENTIDAD (OBJETO) Descripción

Modelar las Características

En programación orientada a objetos, las características se denominan atributos y, al

En este ejemplo se identifican las características de las clases Empleado y Fecha

Las Relaciones entre las Entidades

También podría gustarte