Analisis y diseño de sistemas

1. Grupo 04

2. FLUJO DE TRABAJO
El flujo de trabajo en el análisis, incluyendo a los trabajadores
participantes y sus actividades.

3. ACTIVIDAD: ANÁLISIS DE LA ARQUITECTURA
El propósito es esbozar el modelo de
análisis mediante la identificación de
paquetes del análisis, clases del
análisis evidentes, y requisitos
comunes.

4. Las entradas y los resultados del análisis arquitectónico.

5. La identificación de paquetes de servicio
se suele hacer cuando el trabajo de
análisis está avanzado.
Para identificar paquetes de servicio
debemos:
• Identificar un paquete de servicio
por cada servicio opcional.
• Identificar un paquete de servicio
por cada servicio que podría hacerse
opcional.

6. Deberían definirse dependencias entre
los paquetes del análisis si sus
contenidos están relacionados.
El objetivo es conseguir paquetes que
sean relativamente independientes y
débilmente acoplados pero que posean
una cohesión interna alta.

7. Pueden identificarse una lista de clases entidad candidatas basado en
las clases del dominio o las entidades del negocio.
Un requisito especial es un requisito que aparece durante el análisis .
Como ejemplos podemos citar restricciones sobre:
• Persistencia.
• Distribución y concurrencia.
• Características de seguridad.
• Tolerancia a fallos.
• Gestión de transacciones.

8. Las entradas y los resultados del análisis de un caso de uso.

9. Podemos utilizar las siguientes guías para identificar clases:
• Identificar clases entidad a partir de considerarse que
información debe utilizarse y manipularse para realizar
el caso de uso.
• Identificar una clase de interfaz para cada actor
humano, y dejar que esta clase represente la ventana
principal de la interfaz de usuario.
• Identificar una clase de interfaz primitiva para cada
clase de entidad que hayamos encontrado
anteriormente.
• Identificar una clase de interfaz central para cada actor
que sea un sistema externo.

10. Se utiliza un diagrama de colaboración para
describir como interactúan los objetos
encontrados para realizar el caso de uso.
Podemos observar lo siguiente:
• Un caso de uso se inicia mediante un
mensaje proveniente de una instancia de
un actor.
• Cada clase identificada en el paso anterior
debe tener una instancia en esta
colaboración.
• Los enlaces del diagrama son instancias
de las asociaciones entre clases del
análisis.

11. En este paso recogeremos
todos los requisitos sobre
una realización de caso de
uso que se identifican en el
análisis.

12. Identificar y mantener las responsabilidades de una
clase del análisis, basadas en su papel de realizaciones
de caso de uso.
Identificar y mantener los atributos y relaciones de la clase
análisis.
Capturar requisitos especiales sobre la realización de la clase
análisis.

14. Los objetos Factura se crean durante el caso de uso Enviar Factura al Comprador. El vendedor lleva a cabo
este caso de uso para solicitar al comprador que pague un pedido (un pedido que fue creado durante los
casos de uso Solicitar Bienes y Servicios). Durante este caso de uso, la factura se pasa al comprador, que
puede decidir pagarla después.
El pago se lleva a cabo en el caso de uso Pagar Factura, donde el objeto Planificador de Pagos
planifica el pago de un objeto Factura. Más adelante se paga la factura, y el objeto Factura se cierra.
Obsérvese, sin embargo, que la misma instancia de factura participa en ambos casos de Uso,
Enviar Factura al Comprador y Pagar Factura.

15. El Planificador de pagos tiene las siguientes responsabilidades:
• Crear una solicitud de pago.
• Hacer el seguimiento de los pagos que se han planificado y enviar una notificación cuando se
ha efectuado o cancelado el pago.
• Iniciar la transferencia de dinero en la fecha debida.
• Notificar una factura cuando se ha planificado para su pago y cuando se ha pagado (es
decir,cerrado).

16. Un atributo especifica una propiedad de una clase de análisis,
y normalmente es necesaria para las responsabilidades de su
clase(como se trató en el paso anterior)

17. Los objetos del análisis interactúan unos con otros mediante
enlaces en los diagramas de colaboración. Estos enlaces
suelen ser instancias de asociaciones entre sus
correspondientes.

18. Las generalizaciones deberían utilizarse durante el análisis
para extraer comportamiento compartido y común entre
varias clases del análisis diferentes.

19. Las características del requisito de persistencia de la clase Factura podrían definirse de la
siguiente manera:
• Rango de tamaño: 2 a 24 Kbytes por objeto.
• Volumen: hasta 100.000.
• Frecuencia de actualización:
— Creación/borrado: 1.000 al día.
— Actualización: 30 actualizaciones a la hora.
— Lectura: 1 acceso a la hora.