tarea

Modelado de los requerimientos

• Escenario, información y clases de a análisis
• En el nivel técnico, la ingeniería de software comienza con una serie de tareas de modelado que conducen a la especificación de los requerimientos y a la representación de un diseño del software que se va a elaborar. El modelo de requerimientos es un conjunto de modelos que en realidad son la primera representación técnica de un sistema.

Análisis de requerimientos

• Modelos basados en el escenario de los requerimientos
• Modelos de datos
• Modelos orientados a clases
• Modelos orientados al flujo
• Modelos de comportamiento
• Estos modelos dan al diseñador del software la información que se traduce en diseños de arquitectura, interfaz y componentes. Por último, el modelo de requerimientos brinda al desarrollador y al cliente los medios para evaluar la calidad una vez construido el software

Objetivos y filosofía general

• Durante el modelado de los requerimientos, la atención se centra en:
• ¿Qué interacción del usuario ocurre en una circunstancia particular?
• ¿Qué objetos manipula el sistema?
• ¿Qué funciones debe realizar el sistema?
• ¿Qué comportamientos tiene el sistema?
• ¿Qué interfaces se definen?
• ¿Qué restricciones son aplicables?
• El cliente quizá no esté seguro de qué es lo que requiere con precisión para ciertos aspectos del sistema. Puede ser que el desarrollador esté inseguro de que algún enfoque específico cumpla de manera apropiada la función y el desempeño.

Reglas prácticas del análisis

• Arlow y Neustadt sugieren cierto número de reglas prácticas útiles que deben seguirse cuando se crea el modelo del análisis:
• El modelo debe centrarse en los requerimientos que sean visibles dentro del problema o dentro del dominio del negocio.
• Cada elemento del modelo de requerimientos debe agregarse al entendimiento general de los requerimientos del software.
• Hay que retrasar las consideraciones de la infraestructura y otros modelos no funcionales hasta llegar a la etapa del diseño
• Debe minimizarse el acoplamiento a través del sistema. Es importante representar las relaciones entre las clases y funciones.
• Es seguro que el modelo de requerimientos agrega valor para todos los participantes.
• Mantener el modelo tan sencillo como se pueda. No genere diagramas adicionales si no agregan nueva información.

Analisis del dominio

• Se extiende desde el control electrónico de aviones hasta la banca, de los juegos de video en multimedios al software incrustado en equipos médicos. La meta del análisis del dominio es clara: encontrar o crear aquellas clases o patrones de análisis que sean aplicables en lo general, de modo que puedan volverse a usar.
• El papel del analista de dominios es descubrir y definir patrones de análisis, clases de análisis e información relacionada que pueda ser utilizada por mucha gente que trabaje en aplicaciones similares, pero que no son necesariamente las mismas.

Enfoques del modelado de requerimientos

• Son los que manipulan a los objetos de datos que se modelan en forma que se muestre cómo transforman a los datos a medida que los objetos que se corresponden con ellos fluyen por el sistema.
• Cada elemento del modelo de requerimientos presenta el problema desde diferentes puntos de vista. Los elementos basados en el escenario ilustran cómo interactúa el usuario con el sistema y la secuencia específica de actividades que ocurren cuando se utiliza el software

Escritura de un caso de uso formal

• En ocasiones, para modelar los requerimientos es suficiente con los casos de uso informales presentados. Sin embargo, cuando un caso de uso involucra una actividad crítica o cuando describe un conjunto complejo de etapas con un número significativo de excepciones, es deseable un enfoque más formal. El objetivo en contexto identifica el alcance general del caso de uso.

MODELOS UML EN EL CASO DE USO

• Hay muchas situaciones de modelado de requerimientos en las que un modelo basado en texto —incluso uno tan sencillo como un caso de uso— tal vez no brinde información en forma clara y concisa. En tales casos, es posible elegir de entre una amplia variedad de modelos UML gráficos. El diagrama de actividad UML enriquece el caso de uso al proporcionar una representación gráfica del flujo de interacción dentro de un escenario específico. Un diagrama de actividades es similar a uno de flujo, y utiliza rectángulos redondeados para denotar una función específica del sistema, flechas para representar flujo a través de éste, rombos de decisión para ilustrar una ramificación de las decisiones (cada flecha que salga del rombo se etiqueta) y líneas continuas para indicar que están ocurriendo actividades en paralelo.

Diagramas de canal (swimlane)

• El diagrama de canal de UML es una variación útil del diagrama de actividades y permite representar el flujo de actividades descritas por el caso de uso; al mismo tiempo, indica qué actor (si hubiera muchos involucrados en un caso específico de uso) o clase de análisis (se estudia más adelante, en este capítulo) es responsable de la acción descrita por un rectángulo de actividad. Las responsabilidades se representan con segmentos paralelos que dividen el diagrama en forma vertical, como los canales o carriles de una alberca. Son tres las clases de análisis: Propietario, Cámara e Interfaz, que tienen responsabilidad directa o indirecta en el contexto del diagrama de actividades representado en la figura 6.5. En relación con la figura 6.6, el diagrama de actividades se reacomodó para que las actividades asociadas con una clase de análisis particular queden dentro del canal de dicha clase. Por ejemplo, la clase Interfaz representa la interfaz de usuario como la ve el propietario. El diagrama de actividades tiene dos mensajes que son responsabilidad de la interfaz: “mensaje para que se repita la entrada” y “mensaje para otra vista”. Estos mensajes y las decisiones asociadas con ellos caen dentro del canal Interfaz. Sin embargo, las flechas van de ese canal de regreso al de Propietario, donde ocurren las acciones de éste.

CONCEPTOS DE MODELADO DE DATOS

• Si los requerimientos del software incluyen la necesidad de crear, ampliar o hacer interfaz con una base de datos, o si deben construirse y manipularse estructuras de datos complejas, el equipo del software tal vez elija crear un modelo de datos como parte del modelado general de los requerimientos. Un ingeniero o analista de software define todos los objetos de datos que se procesan dentro del sistema, la relación entre ellos y otro tipo de información que sea pertinente para las relaciones. El diagrama entidad-relación (DER) aborda dichos aspectos y representa todos los datos que se introducen, almacenan, transforman y generan dentro de una aplicación.
• Un objeto de datos es una representación de información compuesta que debe ser entendida por el software. Información compuesta quiere decir algo que tiene varias propiedades o atributos

Relaciones

• Se establece una conexión entre persona y auto porque ambos objetos están relacionados. Pero, ¿Cuál es esa relación? Para determinarlo, debe entenderse el papel de las personas (propiedad, en este caso) y los autos dentro del contexto del software que se va a elaborar.
• Se establece un conjunto de parejas objeto/relación que definan las relaciones relevantes. Por ejemplo,
• Una persona posee un auto
• Una persona es asegurada para que maneje un auto.

MODELADO BASADO EN CLASES

• El modelado basado en clases representa los objetos que manipulará el sistema, las operaciones (también llamadas métodos o servicios) que se aplicarán a los objetos para efectuar la manipulación, las relaciones (algunas de ellas jerárquicas) entre los objetos y las colaboraciones que tienen lugar entre las clases definidas. Los elementos de un modelo basado en clases incluyen las clases y los objetos, atributos, operaciones, modelos clase-responsabilidad-colaborador, diagramas de colaboración y paquetes.

IDENTIFIACACION DE LAS CLASES

• Se comienza por identificar las clases mediante el análisis de los escenarios de uso desarrollados como parte del modelo de requerimientos y la ejecución de un “análisis gramatical” sobre los casos de uso desarrollados para el sistema que se va a construir. Las clases se determinan subrayando cada sustantivo o frase que las incluya para introducirlo en una tabla simple. Deben anotarse los sinónimos.
• Entidades externas (por ejemplo, otros sistemas, dispositivos y personas) que producen o consumen la información que usará un sistema basado en computadora.
• Cosas (reportes, pantallas, cartas, señales, etc.) que forman parte del dominio de información para el problema.
• Ocurrencias o eventos (como una transferencia de propiedad o la ejecución de una serie de movimientos de un robot) que suceden dentro del contexto de la operación del sistema.
• Roles (gerente, ingeniero, vendedor, etc.) que desempeñan las personas que interactúan con el sistema.
• Unidades organizacionales (división, grupo, equipo, etc.) que son relevantes para una aplicación.
• Lugares (piso de manufactura o plataforma de carga) que establecen el contexto del problema y la función general del sistema.

Preguntas

• ¿Quienes crearon las reglas que deben seguirse cuando se crea un modelo de analisis?
• a) Arlow y Neustandt b)Arlow c)Neustandt
• ¿Quien define los patrones de analasis y clases?
• a)Firesmith b)Arlow c) Neustandt
• ¿Cuantas reglas practicas del analisis deben seguirse?
• a)5 b)6 c)8
• ¿Cuales son los modelos que representan elementos funcionales del sistema?
• a)Modelos orientados a clases b)Modelos de datos c)Modelos orientados al flujo.
• ¿Cuales son las 3 clases de analisis?
• a)Propietario, camara y vista b)propietario camara e interfaz c)camara, vista y dialogo