CURSO: PROGRAMACIÓN ORIENTADA A OBJETOS

UNIDAD 1: FASE 2 - ESPECIFICACIÓN, DISEÑO Y ARQUITECTURA

PRESENTADO POR
JHULIE ANDREA BORDA CRUZ
CAMILO HERNANDO MORA 
MARIA ALEJANDRA ROA
HEIDY JULIANA SANCHEZ
WILMER HUMBERTO AGUILERA

PRESENTADO A:
FRANKLIN LIZCANO CELIS

GRUPO: 301403_35

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA - UNAD

FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA
FUSAGASUGÁ
2018
 TABLA DE CONTENIDO

TABLA DE CONTENIDO..............................................................................................................2
INTRODUCCIÓN............................................................................................................................3
OBJETIVOS.....................................................................................................................................4
Objetivo general...........................................................................................................................4
Objetivos específicos....................................................................................................................4
PROYECTO B.................................................................................................................................5
DESARROLLO................................................................................................................................7
1. DIAGRAMA DE CASOS DE USO.........................................................................................7
MODELO DE CLASES...............................................................................................................9
MODELO ENTIDAD RELACIÓN..........................................................................................12
MODELO DE ACTIVIDADES................................................................................................13
 Diagrama General del Proyecto....................................................................................13
 Diagrama de Reparaciones............................................................................................14
CONCEPTO DE HERENCIA MEDIANTE EL MODELO ENTIDAD-RELACIÓN........................................15
CONCLUSIONES..........................................................................................................................17
BIBLIOGRAFÍA............................................................................................................................18
 INTRODUCCIÓN

El siguiente trabajo contiene el diseño del proyecto seleccionado por el grupo colaborativo
en la fase 1, correspondiente al sistema de Clínica de Calzaditos.

Este trabajo proporciona una visión general sobre cómo será el proceso de desarrollo del
proyecto propuesto, conformado por el diagrama de casos de usos mediante el cual se
plasma el comportamiento de los actores en los diferentes entornos relacionados con el
proceso de registro, informes y consulta.

También se representa el modelo de clases, mediante el cual se visualizan las relaciones

entre las clases que involucran el sistema; así mismo se plasma el diagrama de actividades
que es el que muestra el proceso a través de una serie de acciones y el diagrama Entidad-
Relación, mediante el cual se realiza el modelado de datos quien permite representar las
entidades más relevantes del proyecto.
 OBJETIVOS

Objetivo general

Diseñar y especificar la arquitectura del proyecto de sistema automatizado de Reparaciones

de calzado

Objetivos específicos

 Diseñar el diagrama de casos de uso.

 Elaborar modelo de clases del problema
 Especificar el diagrama de actividades.
 Realizar diagrama de entidad relación.
 PROYECTO B

En el sector Norte, Juan López tiene una pequeña empresa encargada de la reparación de
calzado, esta empresa tiene por nombre “Clínica Calzaditos”. Como sus trabajos son de
calidad cada vez más son los usuarios que hacen uso de este servicio y por la misma razón,
Clínica Calzaditos requiere registrar los clientes al igual que sus ventas. Actualmente
Clínica Calzaditos solo cuenta con seis clientes (Véase figura 1). De igual manera se debe
tener en cuenta otros roles de usuario (Véase figura 2).

Figura 1. Clientes Clínica Calzaditos

Fecha de
Identificación Nombre Completo Teléfono Dirección
nacimiento
109845678 Carlos Medina 12/02/1980 6441934 Cra 21 15-02

3214567 Zulia Vega 15/03/1985 7245678 AV 115 25-40

36789065 Alexander Otálora 30/11/1983 6543213 Cra 24 Nro 38-18

1099765 Lucia Acuña 26/06/1988 6789054 Cra 25 Nro 45-125

2567890 Taliana Vargas 04/12/1978 6789032 Diag 25 Nro 12-45

16789045 Elizabeth Rincón 17/08/1999 7896543 Cra 25 Nro 76-25

Figura 2 Otros roles de usuarios

Identificación Nombre Completo Edad Teléfono Dirección Rol

109845678 Carlos Medina 28 6441934 Cra 21 15-02 Cajero

2874963 Andrés Cortes 25 5555555 Cra 34 17-80 Empleado

Para lograr un buen funcionamiento de la Clínica Calzaditos, se requiere el desarrollo de
una aplicación que realice los siguientes procesos:
Registro de reparaciones: El modulo debe permitir el ingreso de las reparaciones de
calzado permitiendo registrar el tipo de calzado, el arreglo y el valor. En caso de requerir
modificación del registro, el sistema debe permitir hacerlo.
Registro de Clientes: En este módulo debe permitir registrar el nombre, fecha de
nacimiento, dirección y el teléfono celular de cada cliente.
Informe de las reparaciones: En este módulo debe permitir obtener el informe de las
reparaciones, incluyendo los datos básicos del cliente.
Consulta de Clientes: En este módulo debe permitir consultar información relacionada con
los clientes y los saldos pendientes por reparaciones.
Finalmente, al ejecutar la aplicación, esta debe solicitar un password y Login para
garantizar la seguridad de la aplicación y el acceso solo a personal autorizado. Los
estudiantes deben tener en cuenta que no se permite en el password los siguientes
caracteres: #,!,¡,?,^,¿,|,° por lo que es obligatorio hacer uso de los bloques de excepciones
en Java para evitar estos caracteres.
Para el desarrollo de este proyecto se debe utilizar el paradigma orientado a objetos (clases,
herencia, polimorfismo, encapsulamiento, etc.), así mismo se debe utilizar la base de datos
MYSQL como base de datos predeterminada. El código de la aplicación debe ser
comentado en su totalidad y todos los estudiantes deben registrar las tareas que cada uno de
ellos realiza en el foro correspondiente a cada fase, con el fin de evidenciar su
participación.
Al finalizar el proyecto en la Fase 5 uno de los integrantes del grupo debe comprimir en
una carpeta el archivo ejecutable, y éste será el mismo que ejecutará el docente al momento
de la calificación.
 DESARROLLO

1. DIAGRAMA DE CASOS DE USO

Identificamos a los actores que interactúan con el sistema

Sistema Registro, consulta,

informe de reparación de
---------------- calzado -------------
Cajero Empleado

Base de Datos
ACTORES
Los Actores que se identifican para la interacción dentro de los sistemas son:
 Empleado: El empleado puede Registrar los clientes, al igual que las ventas.
 Cajero: Puede generar el informe de las reparaciones, incluyendo los datos básicos
de los clientes.
PROCESO DE REGISTRO DE REPARACIONES DE CALZADO
El empleado es el principal encargado de realizar el proceso de registrar los clientes y
registrar las solicitudes de reparaciones de calzado que solicitan los clientes. El empleado le
permitirá ingresar al sistema mediante un login o password. Después de iniciar sesión el
sistema le permitirá interactuar para realizar el registro, consulta de los clientes como así
mismo el registro y consulta del pedido de reparación de los clientes.

Login Ingresar datos

0 1 <<include>> <<extend>> 0
0Empleado
Base de

Datos
 Registrar cliente Almacenar datos
CONSULTAR INFORMACIÓN RELACIONADO A LOS CLIENTES
Para este proceso el empleado puede acceder al sistema y realizar la consulta de los clientes
en el módulo de consultar información, al igual que consultar los saldos pendientes por
reparaciones. Toda esta información la otorga la base de datos.

1 0..*
identificación Datos Cliente

0 1
<<include>> <<include>>
Empleado
Base de

Datos
Realiza consulta

CONSULTAR SALDOS PENDIENTES POR REPARACIONES

Por medio de un login o contraseña, el empleado podrá seleccionar consultar reparaciones
pendientes y de esta manera revisar los que se encuentran almacenados en la base de datos.

1
identificación Saldos pendientes

0 1
<<include>> <<include>>
Empleado
Base de

Datos
Realiza consulta
PROCESO DE INFORME DE REPARACIONES
En el presente proceso el empleado como el cajero podrá realizar el informe sobre las
reparaciones de los calzados que se encuentran en un estado entregado al igual los saldos
que se encuentran pendientes en el sistema o los que no se encuentra. Dicha información
estará brindada por la base de datos.

0
Saldos pendientes
1
<<include>>
1
<<include>> <<include>>
Empleado Login <<include>> 0 Base de

1 Generar Informe Mostrar Información Datos

0
<<include>>
Cajero
<<include>>

Solicitudes Reparaciones
entregados

MODELO DE CLASES

En este caso vamos a simular el comportamiento que tendrían los diferentes integrantes de
la clínica calzaditos; tanto los empleados como los clientes Para simular este
comportamiento vamos a definir las 4 clases que van a representaran a objetos, De cada uno
de ellos vamos a necesitar algunos datos que reflejaremos en los atributos y una serie de
acciones que reflejaremos en sus métodos. Estos atributos y métodos los mostramos en el
siguiente diagrama de clases
Sistema de Registro
Primera clase (cliente): donde como atributo tenemos el No. De identificación. Nombre
completo, fecha de nacimiento, teléfono y dirección. Para ello realizara operaciones como
registrar, guardar, editar información y consultar datos.
Cliente
Id cliente: Integer
NombreCompleto_cliente
fechaNac_Cliente
teléfono_cliente
dirección_cliente
Registrar()
Guardar()
Editar()
Consultar()

Segunda clase (empleados): Sus atributos son identificación, nombre completo, edad,
teléfono, dirección y rol. Donde como operación tiene registrar, guardar, editar y consultar.
Empleados
Id_empleado: Integer
NombreCompleto_empleado
Edad_empleado
teléfono_empleado
dirección_empleado
rol_empleado
Registrar()
Guardar()
Editar()
Consultar()
Tercera clase (reparaciones): Sus atributos son tipo de calzado, arreglo, observaciones.
Reparaciones
Tipocalzado_reparaciones:string
Arrego_reparaciones:string
Precio_reparaciones: string
Entregado_reparaciones:string
Pendiente_reparaciones:string

Registrar()
Guardar()
Editar()
Consultar()
Cuarta clase (informe): sus atributos son fecha, No. Factura, identificación cliente,
nombre completo cliente, fecha nacimiento cliente, teléfono del cliente, dirección del
cliente, tipo de calzado, arreglo, precio, entregado, pendiente, donde tiene como operación
consular. Toda esta información de encuentra consignada en la base de datos.
Informe
Fecha
NoFactura
Identificacióncliente
Nombrecompleto
Fechanacimiento
Teléfono
Direccióncliente
Tipocalzado
Precio
Entregado
Pendiente
Consultar()
El modelo completo de las clases queda
Cliente Reparaciones
Id_empleado: Integer Tipocalzado_reparaciones:string
NombreCompleto_empleado Arrego_reparaciones:string
Edad_empleado Precio_reparaciones: string
teléfono_empleado 1 Entregado_reparaciones:string
dirección_empleado Pendiente_reparaciones:string
rol_empleado Registrar()
Registrar() Guardar()
Guardar() Editar()
Editar() Consultar()
Consultar() 1

Empleados Informe
Id_empleado: Integer Fecha
NombreCompleto_empleado NoFactura
Edad_empleado Identificacióncliente
teléfono_empleado Nombrecompleto
dirección_empleado Fechanacimiento
rol_empleado Teléfono
Registrar() Direccióncliente
Guardar() Tipocalzado
Editar() Precio
Consultar() Entregado
Pendiente
Consultar()
MODELO ENTIDAD RELACIÓN
MODELO DE ACTIVIDADES
 Diagrama General del Proyecto
 Diagrama de Reparaciones
CONCEPTO DE HERENCIA MEDIANTE EL MODELO
ENTIDAD-RELACIÓN

La Herencia es uno de los 4 pilares de la programación orientada a objetos ( POO) junto con
la Abstracción, Encapsulación y Polimorfismo. Al principio cuesta un poco entender estos
conceptos característicos del paradigma de la POO 
Una entidad agrupa un conjunto de ocurrencias de entidad del mismo tipo. En muchos
casos, estas ocurrencias se pueden agrupar a su vez en otros subconjuntos que tienen un
significado propio para los propósitos de la Base de Datos y, por tanto, deberían
representarse de forma explícita. Súper tipo/Subtipo.
Para la clínica calzaditos existe la entidad empleados y un súper tipo cajero, de este se
desprende la generación de informes y el subtipo seria saldos pendientes y solicitud de
reparaciones entregadas y por último se muestra la información general.

1) La extensión de un subtipo es un subconjunto de la extensión del súper tipo

 Una instancia de subtipo también es instancia del supertipo y es la misma instancia

pero con un papel especifico distinto
 Una instancia no puede existir solo por ser miembro del subtipo , también debe ser
miembro del supertipo
La herencia nos permite definir una clase como extensión de otra:  de esta manera decimos “la
clase 1.1 tiene todas las características de la clase 1 y además sus características
particulares”. Todo lo que es común a ambas clases queda comprendido en la clase
“superior”, mientras lo que es específico, queda restringido a las clases “inferiores”. En
nuestro Proyecto definiríamos una clase denominada EMPLEADOS de forma que la clase
PRODUCTO tuviera todas las propiedades de la clase Empleados más algunas propiedades
y métodos específicos. Lo mismo ocurriría con la clase REPARACION y otras que
pudieran “heredar” de Empleados Podríamos seguir creando clases con herencia en un
número indefinido: tantas como queramos. En el API de Java, hay cientos de clases que
heredan de clases jerárquicamente superiores como la clase Object. En un proyecto propio,
podremos tener varias clases que hereden de una clase común.
 CONCLUSIONES

 Los diagramas de caso de uso permiten documentar el comportamiento de un

sistema desde la perspectiva de los actores que intervienen en él. Con lo cual
podemos llegar a definir los requisitos funcionales del sistema de una manera clara
y concisa.

 Los diagramas de actividades muestran las actividades que se deben realizar en un

caso de uso. Sin embargo, es importante no confundirlos con los diagramas de flujo
(generalmente relacionados con el desarrollo de software). El diagrama de actividad
permite en conjunto con el diagrama de casos, realizar un modelo simplificado del
sistema para que los desarrolladores puedan analizar la interacción del sistema con
los diferentes actores que tendrán alguna relación con él. A diferencia del diagrama
de flujo que brinda al programador una descripción lógica del proceso mientras
construye el código del programa.

 Los diagramas realizados en este trabajo nos van a permitir definir de manera clara
y sencilla las especificaciones, el diseño y la arquitectura de la solución que vamos
a diseñar en la siguiente fase del proyecto.
 BIBLIOGRAFÍA

Weitzenfeld, A. (2005). Modelo de Análisis. In Ingeniería de Software Orientada a Objetos

con UML, Java e Internet (p. [253]). Mexico City: Cengage Learning. Recuperado de:
http://bibliotecavirtual.unad.edu.co:2081/ps/retrieve.do?
resultListType=RELATED_DOCUMENT&searchType=BasicSearchForm&userGroupNa
me=unad&inPS=true&contentSegment=&prodId=GVRL&isETOC=true&currentPosition=
&docId=GALE|CX30043000

Jimenez Angarita, C. (20, 12,2016). Fase 1 Introducción a la Programación Orientada a

Objetos. [Archivo de video]. Recuperado de: http://hdl.handle.net/10596/10088

Jimenez Angarita, C. (20, 12,2016). Fase 2 Introducción al Lenguaje de Programación

Orientada a Objeto en Java Practico. [Archivo de video]. Recuperado de:
http://hdl.handle.net/10596/10087

Jimenez Angarita, C. (2016). Fase 3 Modelo de Requisitos y Modelo de Análisis Orientado

a Objetos Teórico. [Archivo de video]. Recuperado de:
http://hdl.handle.net/10596/10086