Proceso de Desarrollo OO
Analisis v.s. Diseño
• El Análisis pone énfasis en una
investigación del problema y los requisitos, en vez de ponerlo en la solución.
– Es adecuado clasificarlo como análisis de requisitos o análisis de los objetos del dominio.
– Se resume en la frase “hacer lo correcto”. – Se resume en la frase “hacer lo correcto”.
• El diseño pone énfasis en una solución conceptual que satisface los requisitos en vez de ponerlo en la implementación.
– Es adecuado clasificarlo como diseño de objetos.
Análisis
• Puede incluir una descripción de los procesos del dominio relacionados representados como
casos de uso, diagramas de CU, diagramas de
secuencia del sistema y contratos de operación.
Análisis
• Texto de los Casos de Uso.
• Diagramas de Casos de Uso.
• Diagramas de Secuencia del Sistema.
Sistema.
Texto y Diagramas de Casos de Uso y el UP
• La identificación de casos de uso, su
descripción textual, y su representación en diagramas de CU es una labor que
comienza durante la fase de inicio en el UP.
• Durante esta fase se intenta identificar la • Durante esta fase se intenta identificar la
mayoría de casos de uso, actores y sus relaciones utilizando la guía EBP (Cap. 6 Larman) mediante talleres de requisitos. • Durante esta fase únicamente se escribe
Texto y Diagramas de Casos de Uso y el UP
• Cabe señalar que cerca del final de la primera iteración de la fase de elaboración tiene lugar otro
taller de requisitos durante el que quizás el 30% de los CU se escriben en detalle.
– Esto se repite hasta estabilizar los aspectos de alto riesgo significativos para la arquitectura.
– Esto puede requerir varias iteraciones de entre 3 y 4 semanas cada una:
– Esto puede requerir varias iteraciones de entre 3 y 4 semanas cada una:
• Iteración 1 – 30% de CU escritos en detalle. • Iteración 2 – 50% ‘’
• Iteración 3 – 70% ‘’ • Iteración 4 – 90% ‘’
• El trabajo en CU termina en la fase de
construcción en la que se termina de especificar
Texto y Diagramas de Casos de Uso
• Una guía de construcción de estos artefactos puede encontrarse en el capítulo 6 del libro de texto, en
donde los aspectos mas importantes son los siguientes:
son los siguientes:
– Los CU deben indicar como el sistema proporciona valor observable al usuario, como cumple sus objetivos y no ser
Texto y Diagramas de Casos de Uso
Texto y Diagramas de Casos de Uso
• Existen diferentes tipos de formalidad:
– Breve – Informal – Completo
• Se comienza en formato breve o informal • Se comienza en formato breve o informal
con la finalidad de llegar al formato completo.
• Para el formato completo se utiliza el
Texto y Diagramas de Casos de Uso
• Se utiliza la guía EBP
(Elementary Businnes Process)
– EBP = Una tarea realizada por – EBP = Una tarea realizada por
una persona en un lugar, en un instante, como respuesta a un evento del negocio, que añade valor cuantificable para el
Texto y Diagramas de Casos de Uso
• Los casos de uso se nombran comenzando por un verbo. • Se identifican los actores
principales en base a sus objetivos y otros actores principales en base a sus objetivos y otros actores
secundarios que por lo común son otros sistemas informáticos • Para los diagramas se sugiere
Texto y Diagramas de Casos de Uso
• La importancia del trabajo de los casos de uso es escribir texto, no diagramas o centrarse en las
relaciones entre los casos de uso. Si alguna organización dedica muchas alguna organización dedica muchas horas (o peor, días) trabajando en los diagramas de casos de uso y debatiendo las relaciones en los casos de uso, en lugar de centrarse en escribir texto, se ha
Análisis
• Texto de los Casos de Uso. • Diagramas de Casos de Uso. • Diagramas de Secuencia del
Sistema. Sistema.
Diagramas de Secuencia del Sistema y el UP
• Los DSS no se incentivan
normalmente en la fase de inicio.
• La mayoría de los DSS se crean • La mayoría de los DSS se crean
Diagramas de Secuencia del Sistema y el UP
• No es necesario crear DSS para todos los escenarios de los CU –al menos no a la vez. Sino que se crean sólo para algunos
escenarios seleccionados de la iteración actual.
• Debería hacerse un DSS para el escenario principal de éxito del CU, y los escenarios alternativos complejos o frecuentes.
Análisis
• Texto de los Casos de Uso. • Diagramas de Casos de Uso. • Diagramas de Secuencia del
Sistema. Sistema.
• Contratos de Operación.
Modelo de Dominio y el UP
• Los modelos de dominio no se incentivan fuertemente en la fase de inicio, puesto que el
propósito del inicio no es llevar propósito del inicio no es llevar a cabo un estudio serio, sino
Modelo de Dominio y el UP
• El modelo de dominio se creasobre todo durante “las
iteraciones” de la elaboración, cuando la necesidad más
importante es entender los importante es entender los conceptos relevantes y
Modelo de Dominio
• Un modelo de dominio muestra a los modeladores clases conceptuales significativas en el dominio del
problema.
• El modelo de dominio se representa con la notación de los diagramas de clases, pero estas no incluyen
Modelo de Dominio
• La cuestión importante es
distinguir entre la perspectiva del analista que mira los
conceptos del mundo real y los conceptos del mundo real y los diseñadores de software que especifican componentes
Estrategias para identificar clases conceptuales
• Para tener una primera versión del modelo conceptual se
recomienda primero identificar clases conceptuales:
• Dos estrategias para esto: • Dos estrategias para esto:
– Utilizar una lista de categorías de clases conceptuales.
Identificación de frases nominales.
• Tomar los nombres y frases nominales y considerarlos
clases conceptuales o atributos candidatos.
¿Clases Conceptuales o Atributos?
• ¿Debería ser la tienda atributo de venta o una clase
¿Clases Conceptuales o Atributos?
• Una tienda no se considera numero o texto –El termino sugiere una
entidad legal, una organización y algo que ocupa espacio-. Por tanto tienda debe ser un concepto.
Modelo de Dominio: Añadir Asociaciones
• Resulta útil identificar aquellas asociaciones entre clases
conceptuales que son
necesarias para satisfacer los requisitos de información de requisitos de información de los escenarios actuales que se están desarrollando y que
Modelo de Dominio: Añadir Asociaciones
• Una asociación es una relación entre tipos que indican alguna conexión significativa e
Modelo de Dominio: Añadir Asociaciones
• Una asociación se representa como una línea entre clases con un nombre de asociación.
• La asociación es bidireccional. • La asociación es bidireccional. • Los extremos de la asociación
podrían contener una
Modelo de Dominio: Añadir Asociaciones
Análisis
• Texto de los Casos de Uso. • Diagramas de Casos de Uso. • Diagramas de Secuencia del
Sistema. Sistema.
• Contratos de Operación.
Contratos de Operación y el UP
• Un contrato con pre- y
postcondicones es un estilo
bien conocido para especificar operaciones en UML.
operaciones en UML.
• Los contratos de especificación de operaciones a nivel sistema forman parte del Modelo de
Contratos de Operación y el UP
• Los contratos no se justifican durante la fase de inicio ya que son demasiado detallados. • Si es que se utiliza, los contratos se
escribirán durante la fase de elaboración, cuando se escriben la mayoría de los casos cuando se escriben la mayoría de los casos de uso.
Contratos de Operación
• Los contratos son una herramienta excelente para el análisis de
requisitos que describen los cambios de estado que requiere una
operación del sistema (en función de operación del sistema (en función de los objetos del Modelo del Dominio) sin tener que describir como se va a
Contratos de Operación
• Es normal que durante la creación de contratos de operación se
descubra la necesidad de registrar nuevas clases conceptuales,
atributos o asociaciones en el atributos o asociaciones en el Modelo del Dominio.
• No se limite a la definición anterior del Modelo del Dominio;
