Larma 2da edicion unidad 13 a 15

Universidad Tecnologica Nacional
Facultad Regional Tucuman

ANALISIS DE SISTEMAS
RESUMEN cap 13 al 15

Profe: Sueldo.

Integrantes:
• Tevez, Jorge.
• Olea, Ivana.
• Cajal, Fabian.

Contratos

Contratos: los contratos de las operaciones describen el comportamiento detallado del sistema en función de los cambios de estado de los objetos del Modelo de Dominio, después de la ejecuciónde una operación del sistema.

Secciones del contrato

Operación: nombre y parámetros
Referencias cruzadas: casos de uso en los que puede tener lugar esta operación.
Precondiciones: suposiciones relevantes sobre el estado del sistema o de los objetos del Modelo de dominio, antes de la ejecución de la operación.
Postcondiciones: estado de los objetos del Modelo de dominio, después de laejecución de la operación, comprende: creación y eliminación de instancias, formación o rotura de asociaciones y cambio en los atributos.

Guias: contratos

Consejos para crear contratos:
Identifique las operaciones del sistema a partir de los DSSs.
Construya un contrato para las operaciones del sistemas complejas y quizás sutiles en sus resultados, o que no están clases claras en el casode uso.
Para describir la postcondiciones utilice las siguientes categorías:
creación y eliminación de instancias
modificación de atributos
formación y rotura de asociones

Cuando usar Contratos

SI: cuando la complejidad es alta y añade valor la precisión detallada.
NO: cuando se depende mucho de la colaboración de los expertos en la materia de estudio para que los desarrolladoresentiendan qué hacer.

Ejemplo Contratos: Caso de Estudio Préstamo de Libros

Operación: NuevoPréstamo()
Referencia cruzada: Caso de Uso préstamo.
Precondición: hay un préstamo en curso.
Postcondición: se creo una instancia de Préstamo, Fecha_préstamo pasa a ser Fecha Actual, Préstamo se asoció con Libro, Socio y con Carnet.

De los requisitos al diseño en esta iteracion.
Hasta elmomento, el caso de estudio ha hecho hincapie en el estudio de los requisitos, conceptos y operaciones relacionadas con un sistema. Siguiendo las guias de UP, se investigaron solo algunos de los requisitos en la fase inicio, y se comenzo con estudio profundo en la PRIMERA ITERACION DE LA ELABORACION. Ahora vamos a cambiar el enfasis hacia el diseño de una solucion para esta iteracion.Iterativamente hacer lo correcto y hacerlo correcto.

Los requisitos y el analisis orientado a objetos se han centrado en aprender a hacer los correcto, es decir, en entender objetivos importantes, las reglas y restricciones. Por el contrario, el siguiente trabajo de diseño pondra en relieve hacerlo correcto, es decir, diseñar una solucion que satisfaga los requisitos de esta iteracion.
A lo largo de lasprimeras iteraciones de elaboracion el descubrimiento de los requisitos se estabilizara, de manera que al final de la elaboracion quizas se definan con detalle y de manera fiable el 80% de los requisitos.

¿No lleva eso semanas en hacerse?
No, no exactamente.
Despues de una discucion detallada debe paracer que el modelado anterior debe llevar semanas de esfuerzo. No es asi, cuando uno seencuentra comodo con las tecnicas de escritura de casos de uso, modelado del dominio, etc. El tiempo que emplearemos sera solo de unos pocos dias.
Otras actividades, como programacion de pruebas de conceptos, busqueda de recursos, planificacion, acondicionamiento de entorno, pocas semanas de preparaciones.

Pasar al diseño de objetos.

Durante el diseño de objetos, se desarrolla una solucionlogica. Lo escencial de esta solucion es la creacion de los DIAGRAMAS DE INTERACCION, que representan el modo en que los objetos colaboran para satisfacer los requisitos.
Junto con la elaboracion de los diagramas de interaccion, se pueden representar los DIAGRAMAS DE CLASES. (estos resumen la definicion de las clases software)
Por lo que se refiere al UP, estos artefacos forman parte del MODELO DE...