Colaborativo3 Teorico Grupo-34

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos
Proyecto de Investigacin Terico

SISTEMA DE CONTROL PARA FERRETERIA
Presentado por:
Grupo 301403_34
JHON JAIRO PONTN - COD 16.891.891

VICTOR MANUEL AVILA- COD 14.795.644
BRYAM MAURICIO RIOS
AGUSTIN FRANCISCO MONTAO DE LA CRUZ- COD 16.510.542
LUIS FELIPE CRUZ
Tutor:
Cesar Orlando Jimnez Angarita
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

ESCUELA DE CIENCIAS BASICAS TECNOLOGIA E INGENIERIA
PROGRAMA INGENIERIA DE SISTEMAS
COLOMBIA
CEAD PALMIRA
Pgina
FECHA PRESENTACION
NOVIEMBRE 2015
Tabla de Contenidos
Captulo 1 Introduccin
Captulo 2 Objetivos
2.1 Objetivos Generales
2.2 Objetivos Especficos
Captulo 3 Justificacin
3.1
Justificacin Metodolgica
3.2
Justificacin Prctica
3.3
Justificacin Innovativa
3.4
Justificacin Profesional
Captulo 4 Metodologa
4.1
Tipo de Metodologa
4.2
Metodologa de Investigacin
Captulo 5 Marco Conceptual y Terico
5.1 Marco Conceptual
5.2 Marco Terico (Programacin Orientada a Objetos en Java)
5.2.1 Introduccin a Java
5.2.2 Programacin bsica
5.2.3 Programacin Avanzada
5.2.4 UML y Java
5.2.5 Aplicaciones y Applets
5.2.6 Interfaces Grficas del Usuario
Captulo 6 Modelo de Requisitos
6.1. Descripcin del Problema
6.2. Modelo de Caso de Uso
6.3. Modelo de Interfaces
6.4. Actores y Caso de Uso
6.5. Modelo de Dominio del Problema
Captulo 7 Modelo de Anlisis
7.1. Arquitectura de Clases
7.2. Identificacin de Clases segn Estereotipos
7.3. Clases segn Casos de Uso
7.4. Diagramas de Secuencia
7.5. Casos de Uso para el Sistema
Pgina

7.6. Diccionario de Clases
Captulo 8 Modelo de Diseo
8.1. Estrategias de Diseo
8.2. Diseo de Objetos
8.3. Diseo de Sistema
8.4. Revisin del Diseo
8.5. Diagrama de Secuencia del Diseo
Captulo 9: Modelo de Implementacin
9.1. Programacin en Java de su proyecto de Investigacin
9.2. Diagrama de Clases de su proyecto de Investigacin
Captulo 10: Modelo de Pruebas
10.1.
10.2.
10.3.
10.4.
Definicin de Conceptos de su proyecto de Investigacin

Tipos de Pruebas de su proyecto de Investigacin
Proceso de Pruebas de su proyecto de Investigacin
Pruebas del Sistema de su proyecto de investigacin
Captulo 11 Conclusiones
Captulo 12 Recomendaciones
Captulo 13 Bibliogrficas
Pgina
1. INTRODUCCIN
En este trabajo se busca disear el sistema de inventarios para una ferretera, en esta
unidad se trabaja bsicamente el modelo de requisitos y el modelo de anlisis para
posteriormente continuar con la bsqueda de la solucin.
El punto de partida es la
descripcin del problema que da dueo del negocio y
seguidamente se asignan los actores y los casos de uso que se van a necesitar en el
desarrollo final.
Pgina
Captulo 6 Modelo de Requisitos
6.1 Descripcin del problema:( La descripcin del problema es un resumen preliminar de

necesidades que sirve como punto de partida para comprender los requisitos del sistema. Aqu se
trata de simular una descripcin preparada por un cliente, la cual debe evolucionar por medio del
modelo de requisitos, con objeto de lograr la especificacin final del sistema a desarrollarse. La
descripcin del problema debe ser una especificacin de necesidades y no una propuesta de
solucin)
La siguiente es la descripcin del problema del cliente de la ferretera don Arturo:

l quiere manejar el sistema de inventario de su negocio. Para ello solicit que
creen una aplicacin que muestre en una pantalla los productos de su negocio
(inventario). Don Arturo tambin quiere que se ingresen productos que acaba de
comprar y que quede registrado en el sistema. Dentro de las peticiones que dio don
Arturo est que se genere una factura de venta donde quede registrado el cdigo
Pgina

del producto y los datos del cliente que realiza la compra (en caso de un posible
reclamo del cliente, o por garanta).
Don Arturo tambin solicit a manera de opcin que los pagos se pudieran realizar
por medio de tarjeta de crdito o dbito.
En resumen:
El sistema debe tener claves de acceso (vendedor-administrador)
Muestre una interfaz grfica con las opciones de:
-Venta (Facturacin)
-Compra (crear producto de proveedores)
-Inventario (Consultas de productos, existencia, cdigo, etc.)
La formas de pago pueden ser efectivo o tarjeta dbito o tarjeta crdito.
Pgina
6.2 Modelo de casos de uso:(El actor y el caso de uso son las entidades bsicas del
modelo de casos de uso, Por tanto, para comprender los casos de uso de un sistema primero es
necesario saber quines son sus usuarios. El actor y el caso de uso son las entidades bsicas del
modelo de casos de uso)
Para el sistema de la ferretera los actores seran:
El vendedor
El administrador
Base de datos clientes
Base de datos productos
Base de datos proveedores
Pgina

6.3 Modelo de interfaces: (El modelo de interfaces describe la presentacin de
informacin entre los actores y el sistema. Se especifica en detalle cmo se vern
las interfaces de usuario al ejecutar cada uno de los casos de uso).
Las siguientes son las interfaces graficas que tendr el programa para cada uno
de los mdulos que se disearan en la solucin del proyecto
Pgina
Pgina
Pgina
10
Pgina
11
Pgina
12

6.4 Actores y casos de uso para el sistema de base de datos adquisicin de
productos en ferretera:
Pgina
13
6.5 Modelo del Dominio del Problema

Diagrama de clases con asociaciones para el sistema de inventario y ventas
en ferretera
Captulo 7 Modelo de
7.1. Arquitectura de
Anlisis
Clases
7.2. Identificacin de Clases segn Estereotipos

Borde:
Pgina
14
Entidad:
Control:
Pgina
15
7.3. Clases segn Casos de Uso

Registrar usuario:
Registrar Cliente:
Registrar Proveedor:
Registrar producto:
Pgina
16
7.4. Diagramas de Secuencia

Registro de Usuario:
Pgina
17
Captulo 8 Modelo de Diseo
8.1. Estrategias de Diseo
Para continuar con el proceso de diseo del proyecto es fundamental decidir qu

clase de arquitectura se va a tomar, la robustez, reus y extensibilidad del sistema.
8.1.1 Arquitectura
El trmino arquitectura se expuso anteriormente
como arquitectura de clases
dentro del sistema pudiendo hacer cambios en la funcionalidad asignada a cada clase.
Esta funcionalidad asignada a cada clase se conoce como la inteligencia de cada
clase dentro del sistema, pudiendo ser unas ms inteligentes que otras dependiendo
Pgina
18

del control que tengan sobre las otras clases, las colecciones de objetos tales como
listas o arreglos no son consideradas como inteligentes, el manejador de interface
requiere mayor inteligencia ya que debe administrar la interaccin con el usuario porque
maneja eventos y pantallas, pero an mas es ms inteligente es el controlador o
manejador por administrar los manejadores de borde y relacionar su funcionalidad con
el sistema.
Para que tenga un buen enfoque se debe escoger una arquitectura que no sea
definitiva sino ms bien que sea integral ya que en caso de haber un error se pueda
corregir fcil y no ocasione traumatismos a todos los objetos del proyecto.
Por tal razn se escogera el tercer enfoque el cual busca encontrar un balance
entre el enfoque 1 se minimiza al mximo el nmero de clases, y el segundo enfoque
que busca distribuir la inteligencia del sistema lo ms homogneamente posible.
Se concluye entonces la escogencia de clase basada en el segundo enfoque.
ROBUSTEZ:
Debemos escoger medidas o instrucciones para evitar fallos o errores, en lo posible
utilizar lenguajes de programacin que solidifiquen este punto utilizando por ejemplo el
manejo de excepciones.
-por tal razn se proteger el sistema de parmetros insertados por el usuario,
cualquier parmetro incorrecto que haga el usuario el sistema lo proteger.
-el sistema no se optimizar si no funciona correctamente.
-El sistema debe incluir estructuras de datos de tamao variable sin lmites
predefinidos.
Pgina
19

-El encapsulamiento es fundamental para la robustez del sistema ocultar
informacin interna, atributos, implementacin de mtodos de una clase permite en un
caso dado cambiarla sin problemas o inconvenientes.
REUSO:
Es fundamental en nuestro sistema en cuanto ms podamos reutilizar el cdigo
ser mejor la robustez del sistema, por ejemplo la herencia hace que se reutilice el
reus, pero si se hace un mal uso de las herencias harn que los programas se
mantengan y extiendan.
EXTENSIBILIDAD: Se debe encapsular las clases para ocultar la estructura interna
de las otras clases, se har distincin entre operaciones pblicas y privadas.
Pgina
20
8.2. Diseo de Objetos

8.2.1 Tarjetas de Clases
Pgina
21
8.2.2
Responsabilidades
8.2.3 Colaboraciones
8.3. Diseo de Sistema
Se deben tener las

siguientes pautas:
Seleccin
del lenguaje
de
programacin
a utilizarse,
estructurados
orientados a objetos
Pgina
22

-Incorporacin
de bibliotecas, como por ejemplo, interfaces grficas (GUI),
bibliotecas numricas y de estructuras de datos.

Incorporacin
de una base de datos de tipo relacionales, relacionales
extendidas u orientadas a objetos.

-Incorporacin de archivos, en sus diferentes formatos.
-Consideraciones de
procesamiento,
como
concurrencia,
paralelismo,
distribucin y tiempo real.
8.3.1 Lenguajes de programacin
Un lenguaje orientado
a objetos hace que la escritura, mantenimiento
extensin de los programas sea ms fcil y segura, ya que ejecuta tareas que un
programador
de
un
lenguaje
no
orientado
a objetos
tendra
que
hacer
manualmente.
Encapsulamiento
mediante
0 visibilidad
modificadores
responsabilidades pblicas,
privados, y protected
de
de los mtodos
tipo public
prvate
en
tanto
como
el caso
de
los atributos
contratos
en el caso de responsabilidades
en el caso de responsabilidades
y atributos
y atributos privados
Pgina
23

definidos a nivel de una superclase, y que se necesiten acceder a nivel de sus
subclases.
.... Protocolos correspondientes a tipos primitivos existentes en Java, como int,
float, boolean, y objetos con tipos predefinidos
en Java,
como
String,
Vector.
De manera general, la implementacin
se basar en definiciones y manejos
estndares de Java.
8.3.2 Interfaces graficas

El diseo se basar en el prototipo grfico descrito anteriormente en el
captulo 5, donde se cre un solo marco de ventana (frame), el cual muestra las
diferentes pantallas en diferentes momentos, todas dentro del mismo marco.
Bsicamente se tendr una clase controladora nica de la ventana, la clase
Interface Usuario definida antes.
-
Pgina
24
8.3.3 BASES DE DATOS:

MODELO RELACIONAL:
MODELO RELACIONAL EXTENDIDO:
MODELO ORIENTADO A OBJETOS:
Pgina
25
la administracin de los depsitos de datos permanentes, que son los que dan
un apoyo importante en los siguientes aspectos:
Recuperacin de cada: proteccin ante fallas de hardware y errores de usuarios.
-Mltiples usuarios: acceso concurrente para diversos usuarios.
-Mltiples aplicaciones: acceso concurrente de lectura y escritura de datos,
facilitando la comunicaci6n entre las diferentes aplicaciones.
-Seguridad: proteccin contra acceso no autorizado de lectura 0 escritura.
-Integridad: reglas que se deben satisfacer para controlar la calidad de los
datos ms all del control particular de la aplicacin.
-Extensibilidad: mecanismos que permiten extender la arquitectura de la base de
datos sin interrumpir su ejecucin.
-Distribucin de datos: distribucin de los datos en diferentes lugares,
organizaciones y plataformas de hardware.
Durante el diseo de la base de datos se debe traducir el modelo del dominio
del problema a un modelo de tablas.
Ejemplo de tabla diseo de clase registro usuario
Pgina
26
d
ireccin
c
lave
f
erretera
n
ombre
7
777
a
pellido
a
gustin
c
iudad
m
ontao
p
as
C
ali
t
elfono
C
olombia
F
ax
1
23
e
ostal
1
12
mail
gustinmo
ntano7ho
tmail.co
m
45
Diseo tabla registro tarjeta

Dato
Nombre
Numero
Tipo
Fecha
ferretera
Agustin
16510542
visa
221015
montao
Ejemplo: Diagrama que muestra la relacin entre las tablas registr usuario y
registr tarjeta
Pgina
27
Pgina
28
Pgina
29
Pgina
30
Pgina
31
Pgina
32
8.4. Revisin del Diseo
Al hacer la revisin del diseo se determina que el planteamiento de la solucin es

una correcta aplicacin para el desarrollo del problema, por lo que se determina que el
diseo cumple con los requisitos necesarios
Pgina
33

.5. Diagrama de Secuencia del Diseo
Pgina
34

Captulo 9: Modelo de Implementacin
9.1. Programacin en Java de su proyecto de Investigacin
Implementacin de la interfaz Usuario a partir de la biblioteca java.awt

import java.awt.*;
Creacin de ventana:
Public class InterfazUsuario<extend>
Implements windowlistener, ActionListener
Prvate Manejador manejador;
Prvate Pantalla pantalla;
Public void window Closed(window Event Event){}

public void windowDeiconified(window Event Event){}
public
public
public
public
public
void windowIconified(window Event Event){}

void windowActivated(window Event Event){}
void windowDeactivated(window Event Event){}
void windowOpened(window Event Event){}
void windowClosing(window Event Event){
System.exit(0);
Pgina
35
Mtodo para manejar la ventana:

public void actionPerformed(ActionEvent Event)
event.getActionCommand()
if(manejador != null)
manejador.manejarEvento(event.getActionCommand());
public void desplegarPantalla(pantalla p)

if(Pantalla != null)
Pantalla.Borrarpantalla();
if(p != null)
Panatalla=p;
if(Pantalla != null)
Pantalla.Desplegarpantalla();
show()
public InterfazUsuario(Manejador m);
setSize(800,600);
setBackground(color.lightGray);
addwindowListener(this);
manejador = m;
Ingreso a Modulo Ventas
protected void crearPantallaQ {
panel = new Panel();
panel.setLayout(new GridLayout(3,l));
panel.add(new Label("FERRETERIA DON ARTURO",
}
Label.CENTER));
panel.add(new Label("VENTAS", Label.CENTER));
panel es.addElement(panel);
panel.add(new Label("Usuario:", Label.LEFT));
texto = new TextField(20);
texto.setName("Usuario");
textos.addElement(texto);
panel.add(texto);
paneles.addElement(panel);
Pgina
36

panel.add(new Label("Contrasea:"));
texto = new TextField(20);
texto.setName("Contrasea");
texto.setEchoChar('#');
textos.addElement(texto);
panel.add(texto);
paneles.addElement(panel);
Mtodo para administrar base de datos clientes:

public abstract class InterfaceRegistro
public abstract
public abstract
public abstract
public abstract
pass);
public abstract
boolean
boolean
boolean
boolean
crearRegistro(Datos reg);
actualizarRegistro(Datos reg);
eliminarRegistro(Datos reg);
validarRegistro(Datos reg,String log,String
boolean obtenerRegistro(Datos reg,String log);
Creacion de Cliente:
public InterfaceArchivoRegistroQ {
}
archivoRegistro = new VectorQ;
reg = new RegistroUsuarioQ ;
regname = getClassName(reg);
ar = new ArchivoRegistro(path,reg,regname);
archi voRegi stro.addElement(ar);
regname = getClassName(reg);
ar = new ArchivoRegistro(path,regname);
archivoRegistro.addElement(ar);
Pgina
37
9.2. Diagrama de Clases de su proyecto de Investigacin
Pgina
38
Captulo 10: Modelo de Pruebas
Modelo de pruebas: las pruebas finales deben tener como objetivo la certificacin final de la
calidad del producto y no la bsqueda de errores. Detectarlos al final del desarrollo es
bastante problemtico, dado que ello requiere regresar a etapas anteriores para resolverlos.
Se considera que "evitar defectos" es ms importante que "removerlos"
10.1 Definicin de conceptos:
Las siguientes definiciones pueden ser utilizadas para precisar ciertos conceptos conocidos
de manera informal como "bugs":
1 Una falla (failure) ocurre cuando un programa no se comporta de manera adecuada. La
falla es una propiedad (estadstica) de un sistema en ejecucin.
Una falta (fault) tiene lugar en el cdigo del programa. La existencia de una falta en el
programa puede ocasionar una falla (failure) en el sistema. No puede haber una falta si el
programa no puede foliar (fail).
Pgina
39

Un error es una accin humana que provoca que un software contenga una falta. Un error
puede significar la existencia de una falta en el programa, lo cual hace que el sistema falle.
10.2 Tipos de pruebas:
Los tipos de pruebas se dividen de manera general en pruebas de verificacin y validacin.
En el primer caso se revisa si el resultado corresponde a la especificacin del sistema, es
decir, si se est construyendo el sistema de manera correcta, algo que por si solo no
garantiza la satisfaccin de los clientes. En el segundo caso, se revisa si el resultado es
realmente lo que el cliente quera, en otras palabras, si se est construyendo el sistema
correcto, de manera que tanto la especificacin como el resultado lo sean.
10.2.1 Tcnicas de pruebas:

Las tcnicas utilizadas para realizar las pruebas son muy variadas, pero se pueden destacar
las siguientes:
Prueba de regresin. Tiene como propsito verificar el sistema luego, de haberle
introducido cambios, por ejemplo despus de corregir una falta, de manera que se
mantenga la funcionalidad especificada originalmente.
Prueba de operacin. Su objetivo es verificar el sistema en operacin por un largo periodo
bajo condiciones normales de uso. Este tipo de prueba mide la confiabilidad (reliability) del
sistema.
Prueba de escala completa. Trata de verificar el sistema en su carga mxima mediante la
asignacin de los parmetros a su valor lmite y la interconexin del sistema con un mximo
de equipos y usuarios simultneos. Su mxima expresin es la prueba de estrs (stressing),
que significa que se prueba el sistema en los lmites extremos para determinar su nivel de
Pgina
40

tolerancia y si ocurre algn tipo de falla. Prueba de rendimiento (performance) o de
capacidad. Tiene como propsito medir la capacidad de procesamiento del sistema bajo
diferentes cargas, incluyendo espacio de almacenamiento y utilizacin de la unidad de
Prueba basada en requisitos o prueba de casos de uso. Intenta llevar a cabo pruebas
basadas directamente en la especificacin de requisitos. Pueden utilizarse los mismos casos
de uso originales como casos de prueba. Tambin pueden ser utilizadas para verificar las
especificaciones de rendimiento o de escala completa. Se trata de verificar que el sistema
final cumple con las especificaciones funcionales descritas por los casos de uso originales.
Pruebas ergonmicas. Tienen como propsito probar los aspectos ergonmicos del sistema,
en otras palabras, las interfaces hombre-mquina en el caso de que estas existan. Por
ejemplo, se prueba si las interfaces son congruentes con los casos de uso a los cuales
corresponden, o entre diferentes casos de uso, si los mens son lgicos y legibles, si los
mensajes del sistema son visibles, si se puede entender los mensajes de falla, etctera.
Prueba de documentacin de usuario. Tiene como propsito probar la documentacin de
usuario, incluyendo el manual de este y la documentacin de mantenimiento y servicio. Se
prueba que los manuales y el comportamiento del sistema sean congruentes entre s, que
sean legibles, con una buena redaccin y, en general, que sean comprensibles. Prueba de
aceptacin o de validacin. Pretende lograr una revisin final por parte de la organizacin
que solicito el sistema, lo cual, a menudo, significa validacin del sistema. El sistema se
prueba en su ambiente real por un periodo extenso. Cuando se termina la prueba, se toma
la decisin de aceptar o no el producto. Este tipo de prueba es a veces conocida como
prueba alfa. Si no existe un cliente particular que haya solicitado el sistema, por ejemplo en
el caso de un producto de software de venta al pblico, a menudo se hace una prueba beta,
lo cual implica que antes de enviarlo al pblico en general, el producto es probado por
clientes seleccionados que utilizan el sistema y reportan las fallas experimentadas.
Pgina
41
10.3 Proceso de pruebas

El proceso de pruebas son acciones de proceso de desarrollo de software, incluyendo
estrategias, actividades y mtodos, que debern ser implementados de manera concurrente
con el proceso de desarrollo de software. Principalmente, las actividades de pruebas cobijan
los siguientes aspectos:
Planeacin, construccin y ejecucin. Por lo general, se mantiene una bitcora de prueba
(test log) durante todo el proceso de pruebas.
10.3.1 Estrategia de prueba

Se destacan el orden en que se van a llevar a cabo, la particin de equivalencias de Pruebas
que se van a aplicar y la posibilidad de automatizarlas.
Orden de pruebas. Tiene como propsito definir en qu momento y en qu orden se

aplicaran las pruebas.
Alcance de pruebas. Tiene como propsito identificar el tipo, nmero y casos de pruebas
que se aplicaran para revisar los diferentes aspectos del sistema.
Automatizacin de pruebas. Tiene como propsito reducir el esfuerzo y costo de las

pruebas mediante la automatizacion del proceso o aspectos del programa.
Pgina
42

10.3.2 Planeacin de la prueba
La planeacin de la prueba inicia con el establecimiento de las estrategias de pruebas, en
donde se observa si estas se harn automtica o manualmente y si existen programas y
datos de prueba que puedan ser usados, posiblemente modificados o desarrollados de nueva
cuenta.
10.3.3 Construccin de la prueba
Una vez planificadas las pruebas, estas deben ser diseadas a un nivel funcional donde se
describa cada prueba y su propsito de manera general y detallada. Se debe describir
exactamente como se deber ejecutar el caso de prueba, de manera que personas no
familiarizadas con la aplicacin, o incluso el sistema, puedan ejecutar el caso.
10.3.4 Ejecucin de la prueba

Durante esta etapa se utiliza la especificacin del diseo de prueba y los reportes de esta. La
estrategia es aplicar de manera paralela el mayor caso de pruebas posible. Se ejecutan las
pruebas automticas y manuales de manera correspondiente y se indican los resultados
esperados.
10.4 Pruebas del Sistema de Reservaciones de Vuelos
En lo que respecta al Sistema de inventario para ferretera desarrollado en este trabajo, nos
limitaremos a verificarlo de acuerdo con la prueba de requisitos o casos de uso. Como
objetivo de la prueba revisaremos que la funcionalidad implementada corresponda a los
casos de uso especificados durante el modelo de requisitos. A continuacin revisaremos los
casos de usos principales, bsicos y de extensin, los cuales fueron descritos durante el
diseo Registrar Usuario y Registrar Tarjeta..
Pgina
43

10.4.1 Registrar Usuario
Se prueba la secuencia ms importante de los casos de uso Registrar Usuario: Crear
Registro
Usuario,
Actualizar
Registro
Usuario
Eliminar
Registro
Usuario.
EJEMPLOS:
Pgina
44
Pgina
45

11 Conclusiones
Bsicamente antes de emprender un proyecto en programacin ya sea web o de

escritorio se requiere tener una descripcin del problema a solucionar.
Por tanto teniendo en cuenta las necesidades de nuestro cliente se deben definir los
actores y los casos de uso que va a necesitar el sistema a desarrollar.
Todo programa bsicamente consta de unas entradas, unos procesos que se realizan
sobre dichas entradas y tendr una salida como por ejemplo un mensaje en pantalla.
Los diagramas de casos de uso sirven para especificar la comunicacin y el

comportamiento de un sistema mediante su interaccin con los usuarios y/u otros
sistemas.
Los actores son llamados a los usuarios que interactan con el sistema ya sean internos
o externos, estos pueden ser personas, dispositivos, hardware u otro sistema que este
interactuando con l sistema.
Pgina
46
12 Recomendaciones:
La interpretacin de la gua de la bibliografa a consultar sobre el sistema de vuelos se ha

dificultado para entender la metodologa para desarrollar este trabajo.
Pgina
47

13: Referencias Bibliogrficas
1. Weitzenfeld, Alfredo. Ingeniera de Software Orientada a Objetos con UML, Java e
internet. Mxico City: Cengage Learning, 2005. Gale Virtual Reference Library.
"Desarrollo de Software Orientado a Objetos." Ingeniera de Software Orientada a
Objetos con UML, Java e Internet. Alfredo Weitzenfeld. Mexico City: Cengage
Learning, 2005. [193]. Gale Virtual Reference Library. Web. 8 July 2014.
2. 1. Jacobson, I., Christensen, M., Jonsson, P., Overhand, G., "Object-Oriented

Software
3. Engineering: A Use Case Driven Approach, Addison-Wesley, 1992.

http://www.rational.com.
4. 2. http://www.sabre.com
5. 3. http://www.galileo.com
6. 4. http://www.worldspan.com
7. 5. http://www.amadeus.com
8. 6. http://www.travelocity.com
9. 7. http://www.expedia.co
Pgina
48

Colaborativo3 Teorico Grupo-34

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Colaborativo3 Teorico Grupo-34

Загружено:

Авторское право:

Доступные форматы

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Proyecto de Investigacin Terico

JHON JAIRO PONTN - COD 16.891.891

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Definicin de Conceptos de su proyecto de Investigacin

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

descripcin del problema que da dueo del negocio y

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Captulo 6 Modelo de Requisitos

6.1 Descripcin del problema:( La descripcin del problema es un resumen preliminar de

La siguiente es la descripcin del problema del cliente de la ferretera don Arturo:

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

El sistema debe tener claves de acceso (vendedor-administrador)

Muestre una interfaz grfica con las opciones de:

La formas de pago pueden ser efectivo o tarjeta dbito o tarjeta crdito.

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Para el sistema de la ferretera los actores seran:

Base de datos clientes

Base de datos productos

Base de datos proveedores

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

6.5 Modelo del Dominio del Problema

7.2. Identificacin de Clases segn Estereotipos

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

7.3. Clases segn Casos de Uso

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

7.4. Diagramas de Secuencia

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Captulo 8 Modelo de Diseo

8.1. Estrategias de Diseo

Para continuar con el proceso de diseo del proyecto es fundamental decidir qu

como arquitectura de clases

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

8.2. Diseo de Objetos

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

8.3. Diseo de Sistema

Se deben tener las

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

de bibliotecas, como por ejemplo, interfaces grficas (GUI),

bibliotecas numricas y de estructuras de datos.

de una base de datos de tipo relacionales, relacionales

extendidas u orientadas a objetos.

distribucin y tiempo real.

8.3.1 Lenguajes de programacin

a objetos hace que la escritura, mantenimiento

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

De manera general, la implementacin

se basar en definiciones y manejos

8.3.2 Interfaces graficas

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

8.3.3 BASES DE DATOS:

Proyecto de Investigacin Curso Acadmico de Programacin Orientada a Objetos

Ejemplo de tabla diseo de clase registro usuario