Vous êtes sur la page 1sur 2

FACULTAD DE ECONOMA Y ADMINISTRACIN CIONAL

NA D

D
DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION

EL
IVERSIDA

COMAHUE
AREA INGENIERIA DE SOFTWARE

UN
CATEDRA DISEO Y DESARROLLO DE SOFTWARE . .
1972

Trabajo de Campo: Gua Prctica


El trabajo de campo consiste en la continuacin del aquel trabajo elaborado para la materia Anlisis
y Diseo de Sistemas. En tal materia se conform un documento de Anlisis, la SRS que se
convierte en el proveedor de los requerimientos del cliente (usuario).

Este trabajo ser evaluado, y la nota se tendr en cuenta para establecer la nota del examen final de
la materia. Se establecern las entregas del trabajo al tutor, las cuales deben hacerse teniendo en
cuenta que se evala por cada entrega. Aspectos de presentacin y atencin a los items de
correccin sern tenidos en cuenta. Recuerde que Ud. est involucrado en un proyecto formal de
desarrollo de software. Como tal, el tratamiento de un tutor es conforme a una gestin de
proyectos.

Proceso de Desarrollo:

Definicin de un Diseo Abstracto de la Aplicacin que se ha solicitado.

Diagrama de Clases:
1. Traducir el Modelo de Dominio, que contiene las entidades de datos en un Modelo de
Dominio para la Aplicacin (entidades de Interface de Base de Datos) que se desarrolla. As
para cada atributo de las entidades del diagrama de clases se requerir una responsabilidad
para el recupero de la informacin que se almacene en tal atributo. Se debe tener en cuenta que
durante el proceso de requerimientos se podra necesitar representar situaciones por medio de
entidades de datos que luego no conformarn el modelo final de datos. As durante el
desarrollo se identifican las entidades que continan siendo significativas y se traducen a
entidades de Interface de Base de Datos. El resto de las entidades podran ser representadas de
otra manera (e.g. Interfaces de Usuario - Formularios), o bien ser descartadas por haber
restringido el rea a ser automatizada. Cmo descubrir estas entidades? Debe poder asignar
responsabilidades significativas a estas clases, sino puede entonces puede estar en presencia de
este tipo de entidades.
Convencin: los nombres de las responsabilidades de atributos propios comienzan con
Conocer. En cambio los de aquellas que representan bsquedas de informacin en otras
entidades y as describen relaciones y colaboraciones entre ellas, se notan comenzando con
Informar.
Ejemplo:

Orden Orden
fecha emisin Conocer fecha emisin
direccin Conocer direccin
Informar Items

Traduccin de Anlisis a Diseo

Item Item
descripcin Conocer descripcin
costo Conocer costo

Anlisis: Modelo de Dominio Diseo: Interfaces de Base de Datos

2. Desarrolle las entidades de Movimientos o Transacciones (Modelo de Reglas de Negocio).


Estas entidades surgen del modelo de Caso de Uso. Generalmente habr tantas transacciones
concretas como casos de uso. Algunas veces surgen ms entidades al intentar factorizar
responsabilidades comunes en superclases o en otras entidades de transacciones. Tambin
prestan utilidad los diagramas de Secuencias, Actividad y Estados, que complementan el
Modelo de Casos de Uso.
3. Al desarrollar el Modelo de Reglas de Negocio, surgir la necesidad de describir la interaccin
del usuario con la aplicacin. Como consejo, debera definir estas entidades (Formularios) a
medida que se desarrollan las de transacciones. Recuerde que toda informacin que se desea
mostrar o solicitar debe hacerse por medio de un formulario. Esto tambin vale para la
informacin que se desea imprimir (Reportes). Los formularios deberan contener el mnimo
de responsabilidades posible. No debe definirlos en funcin de algn estilo de dilogo dado
que en esta etapa de diseo no conocemos an la forma final del front-end de la aplicacin
(Interface de Usuario). Siempre que sea posible intente definir estas entidades para que sean
reusables.
4. La interaccin del usuario con la aplicacin no solo es a travs de Formularios, sino tamben
con el uso de dispositivos. Los formularios solicitan la colaboracin de entidades de
dispositivos. El modelo de diseo que se desarrolla es de caracter genrico, no contempla la
posible presencia de bibliotecas de administracin de dispositivos. Por ello debe generar la
jerarqua de Dispositivos para que el resto de las entidades pidan colaboracin.

Diagrama de Colaboraciones: Para toda entidad del Diagrama de Clases se deben describir las
colaboraciones mediante el Diagrama de Colaboraciones de Wisff-Brock. El cual a continuacin
de una responsabilidad que requiere colaboracin, se presenta una flecha y luego las entidades que
colaboran y los contratos que se requieren. Recuerde: los contratos son conjuntos disjuntos, si
necesita solo una responsabilidad de un contrato, divida el contrato. Para la entidad que necesitaba
todas las responsabilidades, ahora requerir ms de un contrato.
Adems por cada transaccin concreta se debe definir un Diagrama de Colaboraciones segn
UML. Convencin: Los nmeros de secuencia principales generalmente coinciden con la cantidad
de responsabilidades descriptas en la entidad de transaccin. En algunas ocasiones ms de una
responsabilidad se desprende de una lnea principal (e.g. dentro de un condicional - if).

Observacin: Dado que las responsabilidades de las entidades en esta forma de diseo pueden
considerarse casi sentencias (algo extensas), no necesita describirlas en un Diagrama de Clases
convencional segn UML. Puede describir un diagrama de clases con entidades conceptuales (ver
teora de patrones), es decir con solo los nombres de las entidades. Las responsabilidades y
contratos se deberan describir con los diagramas segn Wirffs-Brock. De igual manera para las
colaboraciones segn W-B.

Diseo de las Interfaces de Usuario, eligiendo un estilo de dilogo apropiado. Remodelacin de


las entidades de Formulario definidas en 3. Las interfaces se deben desarrollar en algn lenguaje
de programacin a eleccin. Tenga en cuenta que generalmente ms de una entidad de formulario
es necesaria para conformar una interface de usuario.
Ejemplo: Movimiento
Consulta Datos Empleado
Solicitar Identificacin Empleado Form_Empl_E(x)
.....
Mostrar Datos Empleado Form_Empl_S(y)

Interface de Usuario= Form_Empl_E + Form_Empl_S

Vous aimerez peut-être aussi