Colaborativo3 Teorico Grupo-34

7/23/2019 Colaborativo3 Teorico Grupo-34

http://slidepdf.com/reader/full/colaborativo3-teorico-grupo-34 1/48

Proyecto de Investigación Curso Académico de Programación Orientada a Objetos

Proyecto de Investigación Teórico

SISTEMA DE CONTROL PARA FERRETERIA

Presentado por:r!po "#$%#"&"%

JHON JAIRO PONTÓN - COD 16.891.891

VICTOR MANUEL AVILA- COD 14.795.644

BRYAM MAURICIO RIOS

AGUSTIN RANCISCO MONTA!O DE LA CRU"- COD 16.51#.54$

LUIS ELIPE CRU"

T!tor:Cesar Or'ando (i)*ne+ Angarita

,NI-ERSIDAD NACIONAL A.IERTA / A DISTANCIA

ESC,ELA DE CIENCIAS .ASICAS TECNOLOIA E INENIERIAPRORAMA INENIERIA DE SISTEMAS

COLOM.IA

CEAD PALMIRA

Página 1




FEC0A PRESENTACIONNO-IEM.RE 1#$2

Ta3'a de Contenidos

Cap4t!'o $ Introd!cción

Cap4t!'o 1 O35etivos2.1 Objetivos Generales2.2 Objetivos Específicos

Cap4t!'o " (!sti6icación3.1 Justificación Metodológica

3.2 Justificación Prctica3.3 Justificación !nnovativa3." Justificación Profesional

Cap4t!'o % Metodo'og4a".1 #ipo de Metodología".2 Metodología de !nvestigación

Cap4t!'o 2 Marco Concept!a' y Teórico$.1 Marco %onceptual$.2 Marco #eórico &Progra'ación Orientada a Objetos en Java($.2.1 !ntroducción a Java

$.2.2 Progra'ación bsica$.2.3 Progra'ación )van*ada$.2." +M, - Java$.2.$ )plicaciones - )pplets$.2. !nterfaces Grficas del +suario

Cap4t!'o 7 Mode'o de Re8!isitos.1. /escripción del Proble'a.2. Modelo de %aso de +so.3. Modelo de !nterfaces.". )ctores - %aso de +so.$. Modelo de /o'inio del Proble'a

Cap4t!'o 9 Mode'o de An'isis0.1. )ruitectura de %lases0.2. !dentificación de %lases segn Estereotipos0.3. %lases segn %asos de +so0.". /iagra'as de ecuencia0.$. %asos de +so para el iste'a

Página 2




0.. /iccionario de %lases

Cap4t!'o ; Mode'o de Dise<o4.1. Estrategias de /ise5o4.2. /ise5o de Objetos4.3. /ise5o de iste'a

4.". 6evisión del /ise5o4.$. /iagra'a de ecuencia del /ise5o

Cap4t!'o =: Mode'o de I)p'e)entación

7.1. Progra'ación en Java de su pro-ecto de !nvestigación7.2. /iagra'a de %lases de su pro-ecto de !nvestigación

Cap4t!'o $#: Mode'o de Pr!e3as

18.1. /efinición de %onceptos de su pro-ecto de !nvestigación18.2. #ipos de Pruebas de su pro-ecto de !nvestigación

18.3. Proceso de Pruebas de su pro-ecto de !nvestigación18.". Pruebas del iste'a de su pro-ecto de investigación

Cap4t!'o $$ Conc'!siones

Cap4t!'o $1 Reco)endaciones

Cap4t!'o $" .i3'iogr6icas

Página 3




1. INTRODUCCIÓN

En este trabajo se busca diseñar el sistema de inventarios para una ferretería, en esta

unidad se trabaja básicamente el modelo de requisitos y el modelo de análisis para

posteriormente continuar con la búsqueda de la solución.

El punto de partida es la descripción del problema que da dueño del negocio y

seguidamente se asignan los actores y los casos de uso que se van a necesitar en el

desarrollo final.

Página 4




C%&'()*+ 6 M+,*+ , R)/0/(+0

6. D02/&/3 ,* &2+*%!" #a descripción del problema es un resumen preliminar de

necesidades que sirve como punto de partida para comprender los requisitos del sistema. $quí se

trata de simular una descripción preparada por un cliente, la cual debe evolucionar por medio del

modelo de requisitos, con objeto de lograr la especificación final del sistema a desarrollarse. #a

descripción del problema debe ser una especificación de necesidades y no una propuesta de

solución%

#a siguiente es la descripción del problema del cliente de la ferretería don $rturo!

&l quiere manejar el sistema de inventario de su negocio. 'ara ello solicitó que

creen una aplicación que muestre en una pantalla los productos de su negocio

"inventario%. (on $rturo tambi)n quiere que se ingresen productos que acaba de

comprar y que quede registrado en el sistema. (entro de las peticiones que dio don

$rturo está que se genere una factura de venta donde quede registrado el código

Página 5




del producto y los datos del cliente que reali*a la compra "en caso de un posible

reclamo del cliente, o por garantía%.

(on $rturo tambi)n solicitó a manera de opción que los pagos se pudieran reali*ar por medio de tarjeta de cr)dito o d)bito.

E 20)

• El sistema debe tener claves de acceso "vendedor+administrador%

•

uestre una interfa* gráfica con las opciones de!

+-enta "acturación%

+/ompra "crear producto de proveedores%

+0nventario "/onsultas de productos, e1istencia, código, etc.%

• #a formas de pago pueden ser efectivo o tarjeta d)bito o tarjeta cr)dito.

Página 6




6.2 M+,*+ , %0+0 , )0+!"El actor y el caso de uso son las entidades básicas del

modelo de casos de uso, 'or tanto, para comprender los casos de uso de un sistema primero es

necesario saber qui)nes son sus usuarios. El actor y el caso de uso son las entidades básicas del

modelo de casos de uso%

'ara el sistema de la ferretería los actores serían!

• El vendedor

• El administrador

• 3ase de datos clientes

• 3ase de datos productos

• 3ase de datos proveedores

Página 7




6.4 M+,*+ , /(2%0! "El modelo de interfaces describe la presentación de

información entre los actores y el sistema. 5e especifica en detalle cómo se verán

las interfaces de usuario al ejecutar cada uno de los casos de uso%.

#as siguientes son las interfaces graficas que tendrá el programa para cada uno

de los módulos que se diseñaran en la solución del proyecto

Página 8




Página 9




Página 10




Página 11




Página 12




6.4 A(+20 %0+0 , )0+ &%2% * 0/0(% , %0 , ,%(+0 %,)/0//3 ,

&2+,)(+0 22(2'%!

Página 13




6.5 M+,*+ ,* D+//+ ,* P2+*%

D/%:2%% , *%00 + %0+/%/+0 &%2% * 0/0(% , /;(%2/+ ;(%0

22(2'%

C%&'()*+ 7 M+,*+ , A<*/0/0

7.1. A2)/(()2% , C*%00

7.$. I,(//%/3 , C*%00 0:= E0(2+(/&+0

B+2,

Página 14




E(/,%,

C+(2+*

Página 15




7.>. C*%00 0:= C%0+0 , U0+

R:/0(2%2 )0)%2/+

R:/0(2%2 C*/(

R:/0(2%2 P2+;,+2

R:/0(2%2 &2+,)(+

Página 16




7.4. D/%:2%%0 , S)/%

R:/0(2+ , U0)%2/+

Página 17




/apítulo odelo de (iseño

.. Estrategias de (iseño

'ara continuar con el proceso de diseño del proyecto es fundamental decidir qu)

clase de arquitectura se va a tomar, la robuste*, reusó y e1tensibilidad del sistema.

.. $rquitectura

El t)rmino arquitectura se e1puso anteriormente como arquitectura de clases

dentro del sistema pudiendo 7acer cambios en la funcionalidad asignada a cada clase.

Esta funcionalidad asignada a cada clase se conoce como 8la inteligencia9 de cada

clase dentro del sistema, pudiendo ser unas más inteligentes que otras dependiendo

Página 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 interacción con el usuario porque

maneja eventos y pantallas, pero aún mas es más inteligente es el controlador o

manejador por administrar los manejadores de borde y relacionar su funcionalidad con

el sistema.

'ara que tenga un buen enfoque se debe escoger una arquitectura que no sea

definitiva sino más bien que sea integral ya que en caso de 7aber un error se pueda

corregir fácil y no ocasione traumatismos a todos los objetos del proyecto.

'or tal ra*ón se escogería el tercer enfoque el cual busca encontrar un balance

entre el enfoque se minimi*a al má1imo el número de clases, y el segundo enfoque

que busca distribuir la inteligencia del sistema lo más 7omog)neamente posible.

5e concluye entonces la escogencia de clase basada en el segundo enfoque.

:;3<5=E>!

(ebemos escoger medidas o instrucciones para evitar fallos o errores, en lo posible

utili*ar lenguajes de programación que solidifiquen este punto utili*ando por ejemplo el

manejo de e1cepciones.

+por tal ra*ón se protegerá el sistema de parámetros insertados por el usuario,

cualquier parámetro incorrecto que 7aga el usuario el sistema lo protegerá.

+el sistema no se optimi*ará si no funciona correctamente.

+El sistema debe incluir estructuras de datos de tamaño variable sin límites

predefinidos.

Página 19




+El encapsulamiento es fundamental para la robuste* del sistema ocultar

información interna, atributos, implementación de m)todos de una clase permite en un

caso dado cambiarla sin problemas o inconvenientes.

:E<5;!

Es fundamental en nuestro sistema en cuanto más podamos reutili*ar el código

será mejor la robuste* del sistema, por ejemplo la 7erencia 7ace que se reutilice el

reusó, pero si se 7ace un mal uso de las 7erencias 7arán que los programas se

mantengan y e1tiendan.

E?=E@5030#0($(! 5e debe encapsular las clases para ocultar la estructura interna

de las otras clases, se 7ará distinción entre operaciones públicas y privadas.

Página 20




.2. (iseño de ;bjetos

.2. =arjetas de /lases

Página 21




.2.2:esponsabilidades

.2.4 /olaboraciones

.4. (iseño de 5istema

5e deben tener las

siguientes pautas!

5elección del lenguaje de programación a utili*arse, estructurados u

orientados a objetos

Página 22




+0ncorporación de bibliotecas, como por ejemplo, interfaces gráficas "A<0%,

bibliotecas num)ricas y de estructuras de datos.

0ncorporación de una base de datos de tipo relacionales, relacionales

e1tendidas u orientadas a objetos.

+0ncorporación de arc7ivos, en sus diferentes formatos.

+/onsideraciones de procesamiento, como concurrencia, paralelismo,

distribución y tiempo real.

8.3.1 Lenguajes de programación

<n lenguaje orientado a objetos 7ace que la escritura, mantenimiento y

e1tensión de los programas sea más fácil y segura, ya que ejecuta tareas que un

programador de un lenguaje no orientado a objetos tendría que 7acer

manualmente.

Encapsulamiento B visibilidad de los m)todos tanto como los atributos

mediante modificadores de tipo public en el caso de contratos y

responsabilidades públicas, prívate en el caso de responsabilidades y atributos

privados, y protected en el caso de responsabilidades y atributos privados

Página 23




definidos a nivel de una superclase, y que se necesiten acceder a nivel de sus

subclases.

.... 'rotocolos correspondientes a tipos primitivos e1istentes en Cava, como int,

float, boolean, y objetos con tipos predefinidos en Cava, como String,

Vector.

(e manera general, la implementación se basará en definiciones y manejos

estándares de Cava.

8.3. !nterfaces graficas

El diseño se basará en el prototipo gráfico descrito anteriormente en elcapítulo D, donde se creó un solo marco de ventana "frame%, el cual muestra lasdiferentes pantallas en diferentes momentos, todas dentro del mismo marco.

3ásicamente se tendrá una clase controladora única de la ventana, la clase!nterface "suario definida antes.

+

Página 24




8.3.3 BASES DE DATOS:

MODELO RELACIONAL:

MODELO RELACIONAL EXTENDIDO:

MODELO ORIENTADO A OBJETOS:

Página 25




la administración de los depósitos de datos permanentes, que son los que danun apoyo importante en los siguientes aspectos!

:ecuperación de caída! protección ante fallas de 7ardare y errores de usuarios.

+últiples usuarios! acceso concurrente para diversos usuarios.

+últiples aplicaciones! acceso concurrente de lectura y escritura de datos,facilitando la comunicaci6n entre las diferentes aplicaciones.

+5eguridad! protección contra acceso no autori*ado de lectura B escritura.

+0ntegridad! reglas que se deben satisfacer para controlar la calidad de losdatos más allá del control particular de la aplicación.

+E1tensibilidad! mecanismos que permiten e1tender la arquitectura de la base dedatos sin interrumpir su ejecución.

+(istribución de datos! distribución de los datos en diferentes lugares,organi*aciones y plataformas de 7ardare.

(urante el diseño de la base de datos se debe traducir el modelo del dominiodel problema a un modelo de tablas.

Ejemplo de tabla diseño de clase registro usuario

Página 26




d

irección

c

lave

n

o!re

a

"ellido

c

i#dad

"

a$%

&

el'(ono

)

a*

e

ail

"

o%&al

(

erre&er$a

+

+++

a

,#%&in

on&a-o

C

ali

C

olo!ia

/3

/

A

,#%&ino

n&ano+0o

&ail.co

+

12

(iseño tabla registro tarjeta

(ato @ombre @umero =ipo ec7a

ferretería $gustin

montaño

6DBDF2 visa 22BD

Ejemplo! (iagrama que muestra la relación entre las tablas registró usuario y

registró tarjeta

Página 27




Página 28




Página 29




Página 30




Página 31




Página 32




.F. :evisión del (iseño

$l 7acer la revisión del diseño se determina que el planteamiento de la solución es

una correcta aplicación para el desarrollo del problema, por lo que se determina que el

diseño cumple con los requisitos necesarios

Página 33




.D. (iagrama de 5ecuencia del (iseño

Página 34




Cap4t!'o =: Mode'o de I)p'e)entación

=>$> Progra)ación en (ava de s! proyecto de Investigación

I)p'e)entación de 'a inter6a+ ,s!ario a partir de 'a 3i3'ioteca 5ava>a?t

i'port java.a9t.:;

Creación de ventana:

Public class !nterfa*+suario<e=tend>!'ple'ents 9indo9listener? )ction,istener

Prívate Manejador 'anejador;Prívate Pantalla pantalla;

Public void 9indo9 %losed&9indo9 Event Event(@Apublic void 9indo9/eiconified&9indo9 Event Event(@A

public void 9indo9!conified&9indo9 Event Event(@A

public void 9indo9)ctivated&9indo9 Event Event(@Apublic void 9indo9/eactivated&9indo9 Event Event(@Apublic void 9indo9Opened&9indo9 Event Event(@Apublic void 9indo9%losing&9indo9 Event Event(@

-ste'.e=it&8(;A

Página 35




M*todo para )ane5ar 'a ventanaB

public void actionPerfor'ed&)ctionEvent Event(

event.get)ction%o''and&(

if&'anejador CD null('anejador.'anejarEvento&event.get)ction%o''and&((;

public void desplegarPantalla&pantalla p(

if&Pantalla CD null(Pantalla.orrarpantalla&(;

if&p CD null(PanatallaDp;

if&Pantalla CD null(Pantalla./esplegarpantalla&(;

sFo9&(

public !nterfa*+suario&Manejador '(;

seti*e&488?88(;setacground&color.ligFtGra-(;

add9indo9,istener&tFis(;'anejador D ';

Ingreso a Mod!'o -entasprotected void crearPantallaH @panel D ne9 Panel&(;panel.set,a-out&ne9 Grid,a-out&3?l((;panel.add&ne9 ,abel&IE66E#E6!) /OK )6#+6OI?A,abel.%EK#E6((;panel.add&ne9 ,abel&ILEK#)I? ,abel.%EK#E6((;panel es.addEle'ent&panel(;

panel D ne9 Panel&(;panel.add&ne9 ,abel&I+suarioBI? ,abel.,E#((;te=to D ne9 #e=tield&28(;te=to.setKa'e&I+suarioI(;te=tos.addEle'ent&te=to(;panel.add&te=to(;paneles.addEle'ent&panel(;

Página 36




panel D ne9 Panel&(;panel.add&ne9 ,abel&I%ontrase5aBI((;te=to D ne9 #e=tield&28(;te=to.setKa'e&I%ontrase5aI(;te=to.setEcFo%Far&N(;te=tos.addEle'ent&te=to(;

panel.add&te=to(;paneles.addEle'ent&panel(;

M*todo para ad)inistrar 3ase de datos c'ientes:

public abstract class !nterface6egistro

public abstract boolean crear6egistro&/atos reg(;public abstract boolean actuali*ar6egistro&/atos reg(;

public abstract boolean eli'inar6egistro&/atos reg(;public abstract boolean validar6egistro&/atos reg?tring log?tringpass(;public abstract boolean obtener6egistro&/atos reg?tring log(;

Creacion de C'iente:

public !nterface)rcFivo6egistroH @AarcFivo6egistro D ne9 LectorH;reg D ne9 6egistro+suarioH ;

regna'e D get%lassKa'e&reg(;ar D ne9 )rcFivo6egistro&patF?reg?regna'e(;arcFi vo6egi stro.addEle'ent&ar(;regna'e D get%lassKa'e&reg(;ar D ne9 )rcFivo6egistro&patF?regna'e(;arcFivo6egistro.addEle'ent&ar(;

Página 37




=>1> Diagra)a de C'ases de s! proyecto de Investigación

Página 38




Cap4t!'o $#: Mode'o de Pr!e3as

Modelo de pruebasB las pruebas finales deben tener co'o objetivo la certificación final de la

calidad del producto - no la bsueda de errores. /etectarlos al final del desarrollo es

bastante proble'tico? dado ue ello reuiere regresar a etapas anteriores para resolverlos.

e considera ue Ievitar defectosI es 's i'portante ue Ire'overlosI

$#>$ De6inición de conceptos:

,as siguientes definiciones pueden ser utili*adas para precisar ciertos conceptos conocidos

de 'anera infor'al co'o IbugsIB

1 +na falla &failure( ocurre cuando un progra'a no se co'porta de 'anera adecuada. ,a

falla es una propiedad &estadística( de un siste'a en ejecución.

+na falta &fault( tiene lugar en el código del progra'a. ,a e=istencia de una falta en el

progra'a puede ocasionar una falla &failure( en el siste'a. Ko puede Faber una falta si el

progra'a no puede foliar &fail(.

Página 39




+n error es una acción Fu'ana ue provoca ue un soft9are contenga una falta. +n error

puede significar la e=istencia de una falta en el progra'a? lo cual Face ue el siste'a falle.

1#>1 Tipos de pr!e3asB

,os tipos de pruebas se dividen de 'anera general en pruebas de verificación - validación.

En el pri'er caso se revisa si el resultado corresponde a la especificación del siste'a? es

decir? si se est constru-endo el siste'a de 'anera correcta? algo ue por si solo no

garanti*a la satisfacción de los clientes. En el segundo caso? se revisa si el resultado es

real'ente lo ue el cliente uería? en otras palabras? si se est constru-endo el siste'a

correcto? de 'anera ue tanto la especificación co'o el resultado lo sean.

$#>1>$ T*cnicas de pr!e3as:

,as tcnicas utili*adas para reali*ar las pruebas son 'u- variadas? pero se pueden destacar

las siguientesB

Pr!e3a de regresión> #iene co'o propósito verificar el siste'a luego? de Faberle

introducido ca'bios? por eje'plo despus de corregir una falta? de 'anera ue se

'antenga la funcionalidad especificada original'ente.

Pr!e3a de operación> u objetivo es verificar el siste'a en operación por un largo periodo

bajo condiciones nor'ales de uso. Este tipo de prueba 'ide la confiabilidad &reliabilit-( del

siste'a.

Pr!e3a de esca'a co)p'eta> #rata de verificar el siste'a en su carga '=i'a 'ediante la

asignación de los par'etros a su valor lí'ite - la intercone=ión del siste'a con un '=i'o

de euipos - usuarios si'ultneos. u '=i'a e=presión es la prueba de estrs &stressing(?

ue significa ue se prueba el siste'a en los lí'ites e=tre'os para deter'inar su nivel de

Página 40




tolerancia - si ocurre algn tipo de falla. Prueba de rendi'iento &perfor'ance( o de

capacidad. #iene co'o propósito 'edir la capacidad de procesa'iento del siste'a bajo

diferentes cargas? inclu-endo espacio de al'acena'iento - utili*ación de la unidad de

Pr!e3a 3asada en re8!isitos o pr!e3a de casos de !so> !ntenta llevar a cabo pruebas

basadas directa'ente en la especificación de reuisitos. Pueden utili*arse los 'is'os casos

de uso originales co'o casos de prueba. #a'bin pueden ser utili*adas para verificar las

especificaciones de rendi'iento o de escala co'pleta. e trata de verificar ue el siste'a

final cu'ple con las especificaciones funcionales descritas por los casos de uso originales.

Pruebas ergonó'icas. #ienen co'o propósito probar los aspectos ergonó'icos del siste'a?

en otras palabras? las interfaces Fo'bre'uina en el caso de ue estas e=istan. Por

eje'plo? se prueba si las interfaces son congruentes con los casos de uso a los cuales

corresponden? o entre diferentes casos de uso? si los 'ens son lógicos - legibles? si los

'ensajes del siste'a son visibles? si se puede entender los 'ensajes de falla? etctera.

Prueba de docu'entación de usuario. #iene co'o propósito probar la docu'entación de

usuario? inclu-endo el 'anual de este - la docu'entación de 'anteni'iento - servicio. e

prueba ue los 'anuales - el co'porta'iento del siste'a sean congruentes entre sí? ue

sean legibles? con una buena redacción -? en general? ue sean co'prensibles. Prueba de

aceptación o de validación. Pretende lograr una revisión final por parte de la organi*ación

ue solicito el siste'a? lo cual? a 'enudo? significa validación del siste'a. El siste'a se

prueba en su a'biente real por un periodo e=tenso. %uando se ter'ina la prueba? se to'a

la decisión de aceptar o no el producto. Este tipo de prueba es a veces conocida co'o

prueba alfa. i no e=iste un cliente particular ue Fa-a solicitado el siste'a? por eje'plo en

el caso de un producto de soft9are de venta al pblico? a 'enudo se Face una prueba beta?

lo cual i'plica ue antes de enviarlo al pblico en general? el producto es probado por

clientes seleccionados ue utili*an el siste'a - reportan las fallas e=peri'entadas.

Página 41




$#>" Proceso de pr!e3as

El proceso de pruebas son acciones de proceso de desarrollo de soft9are? inclu-endo

estrategias? actividades - 'todos? ue debern ser i'ple'entados de 'anera concurrente

con el proceso de desarrollo de soft9are. Principal'ente? las actividades de pruebas cobijan

los siguientes aspectosB

Planeación? construcción - ejecución. Por lo general? se 'antiene una bitácora de prueba

(test log) durante todo el proceso de pruebas.

$#>">$ Estrategia de pr!e3a

e destacan el orden en ue se van a llevar a cabo? la partición de euivalencias de Pruebas

ue se van a aplicar - la posibilidad de auto'ati*arlas.

Orden de pr!e3as> #iene co'o propósito definir en u 'o'ento - en u orden se

aplicaran las pruebas.

A'cance de pr!e3as> #iene co'o propósito identificar el tipo? n'ero - casos de pruebas

ue se aplicaran para revisar los diferentes aspectos del siste'a.

A!to)ati+ación de pr!e3as> #iene co'o propósito reducir el esfuer*o - costo de las

pruebas 'ediante la automatizacion del proceso o aspectos del progra'a.

Página 42




$#>">1 P'aneación de 'a pr!e3a

,a planeación de la prueba inicia con el estableci'iento de las estrategias de pruebas? en

donde se observa si estas se Farn auto'tica o 'anual'ente - si e=isten progra'as -

datos de prueba ue puedan ser usados? posible'ente 'odificados o desarrollados de nueva

cuenta.

$#>">" Constr!cción de 'a pr!e3a

+na ve* planificadas las pruebas? estas deben ser dise5adas a un nivel funcional donde se

describa cada prueba - su propósito de 'anera general - detallada. e debe describir

e=acta'ente co'o se deber ejecutar el caso de prueba? de 'anera ue personas no

fa'iliari*adas con la aplicación? o incluso el siste'a? puedan ejecutar el caso.

$#>">% E5ec!ción de 'a pr!e3a

/urante esta etapa se utili*a la especificación del dise5o de prueba - los reportes de esta. ,a

estrategia es aplicar de 'anera paralela el 'a-or caso de pruebas posible. e ejecutan laspruebas auto'ticas - 'anuales de 'anera correspondiente - se indican los resultados

esperados.

$#>% Pr!e3as de' Siste)a de Reservaciones de -!e'os

En lo ue respecta al Sistema de inventario para ferretería desarrollado en este trabajo? nos

li'itare'os a verificarlo de acuerdo con la prueba de reuisitos o casos de uso. %o'o

objetivo de la prueba revisare'os ue la funcionalidad i'ple'entada corresponda a los

casos de uso especificados durante el 'odelo de reuisitos. ) continuación revisare'os los

casos de usos principales? bsicos - de e=tensión? los cuales fueron descritos durante el

dise5o Registrar Usuario - Registrar Tarjeta..

Página 43




$#>%>$ Registrar ,s!ario

e prueba la secuencia 's i'portante de los casos de uso Registrar Usuario: %rear

6egistro +suario? )ctuali*ar 6egistro +suario - Eli'inar 6egistro +suario.

EJEMPLOS:

Página 44




Página 45




11 C+*)0/+0

• 3ásicamente antes de emprender un proyecto en programación ya sea eb o deescritorio se requiere tener una descripción del problema a solucionar.

• 'or tanto teniendo en cuenta las necesidades de nuestro cliente se deben definir losactores y los casos de uso que va a necesitar el sistema a desarrollar.

• =odo programa básicamente consta de unas entradas, unos procesos que se reali*ansobre dic7as entradas y tendrá una salida como por ejemplo un mensaje en pantalla.

• #os diagramas de casos de uso sirven para especificar la comunicación y elcomportamiento de un sistema mediante su interacción con los usuarios yGu otrossistemas.

• #os actores son llamados a los usuarios que interactúan con el sistema ya sean internoso e1ternos, estos pueden ser personas, dispositivos, 7ardare u otro sistema que esteinteractuando con )l sistema.

Página 46




1$ R+,%/+0

,a interpretación de la guía de la bibliografía a consultar sobre el siste'a de vuelos se Fa

dificultado para entender la 'etodología para desarrollar este trabajo.

Página 47




1> R2/%0 B/*/+:2</%0

1. Qeit*enfeld? )lfredo. !ngeniería de oft9are Orientada a Objetos con +M,? Java einternet. M=ico %it-B %engage ,earning? 288$. Gale Lirtual 6eference ,ibrar-.I/esarrollo de oft9are Orientado a Objetos.I !ngeniería de oft9are Orientada a

Objetos con +M,? Java e !nternet. )lfredo Qeit*enfeld. Me=ico %it-B %engage,earning? 288$. R173S. Gale Lirtual 6eference ,ibrar-. Qeb. 4 Jul- 281".

/. 1. Jacobson? !.? %Fristensen? M.? Jonsson? P.? OverFand? G.? IObjectOriented

oft9are

3. EngineeringB ) +se %ase /riven )pproacF? )ddisonQesle-? 1772.

FttpBTT999.rational.co'.

1. 2. FttpBTT999.sabre.co'

2. 3. FttpBTT999.galileo.co'

. ". FttpBTT999.9orldspan.co'

+. $. FttpBTT999.a'adeus.co'

8. . FttpBTT999.travelocit-.co'

4. 0. FttpBTT999.e=pedia.co

http://www.expedia.co/

http://www.expedia.co/

Colaborativo3 Teorico Grupo-34

Documents

Transcript of Colaborativo3 Teorico Grupo-34