Commencez. C'est gratuit
ou s'inscrire avec votre adresse courriel
Rocket clouds
Capitulo 6 par Mind Map: Capitulo 6

1. Análisis de los requerimientos

1.1. Tipos de Modelos

1.1.1. Basados en el escenario

1.1.1.1. casos de uso

1.1.1.2. historias de usuario

1.1.2. De datos

1.1.3. Orientados a clases

1.1.3.1. diagramas de clase

1.1.3.2. diagramas de colaboración

1.1.4. Orientados al flujo

1.1.4.1. DFD

1.1.4.2. modelos de datos

1.1.5. De comportamiento

1.1.5.1. diagramas de estado

1.1.5.2. diagramas de secuencia

2. Conceptos de modelados de datos

2.1. Objetos de Datos

2.1.1. Un objeto de datos es una representación de información compuesta que debe ser entendida por el software

2.1.2. Información compuesta quiere decir algo que tiene varias propiedades o atributos diferentes

2.1.3. Un objeto de datos contiene sólo datos, por lo que podemos decir que el objeto de datos puede representarse en forma de tabla.

2.2. Atributos de los Datos

2.2.1. Los atributos de los datos definen las propiedades de un objeto de datos y tienen una de tres diferentes características.

2.2.1.1. Se usan para:

2.2.1.1.1. 1) Nombrar una instancia del objeto de datos

2.2.1.1.2. 2) Describir la instancia

2.2.1.1.3. 3) Hacer referencia a otra instancia en otra tabla

2.2.2. El atributo identificador se convierte en una “llave” cuando se desea encontrar una instancia del objeto de datos

2.3. Relaciones

2.3.1. Los objetos de datos están conectados entre sí de diferentes maneras.

2.3.2. Ejemplo

2.3.2.1. Considere dos objetos de datos, persona y auto. 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.

2.3.2.1.1. Se establece un conjunto de parejas objeto/relación que definan las relaciones relevantes.

3. Creación de un caso preliminar de uso

3.1. Contrato para el comportamiento

3.2. Define la forma en la que un actor utiliza un sistema basado en computadora para alcanzar algún objetivo

3.3. En esencia, un caso de uso capta las interacciones que ocurren entre los productores y consumidores de la información y el sistema en sí

3.4. ¿Sobre qué escribir?

3.4.1. Las dos primeras tareas de la ingeniería de requerimientos concepción e indagación dan la información que se necesita para comenzar a escribir casos de uso.

3.5. Las reuniones para recabar los requerimientos, el DEC, y otros mecanismos para obtenerlos

3.5.1. Se utilizan para identificar a los participantes, definir el alcance del problema, especificar los objetivos operativos generales, establecer prioridades

3.6. En general, los casos de uso se escriben primero en forma de narración informal. Si se requiere más formalidad, se reescribe el mismo caso con el empleo de un formato estructurado,

4. Modelado clase-responsabilidad-colaborador (CRC)

4.1. Responsabilidades

4.1.1. 1. La inteligencia del sistema debe estar distribuida entre las clases para enfrentar mejor las necesidades del problema.

4.1.2. 2. Cada responsabilidad debe enunciarse del modo más general posible.

4.1.3. 3. La información y el comportamiento relacionado con ella deben residir dentro de la misma clase.

4.1.4. 4. La información sobre una cosa debe localizarse con una sola clase, y no distribuirse a través de muchas.

4.1.5. 5. Cuando sea apropiado, las responsabilidades deben compartirse entre clases relacionadas.

4.2. Colaboraciones

4.2.1. Usa sus propias operaciones para manipular sus propios atributos, con lo que satisface una responsabilidad particular

4.2.2. Colabora con otras clases

4.2.3. Las colaboraciones representan solicitudes que hace un cliente a un servidor para cumplir con sus responsabilidades.

4.3. Enfoques en un modelo de desarrollo CRC completo

4.3.1. 1. Se da a todos los participantes que intervienen en la revisión un subconjunto del modelo de tarjetas índice CRC.

4.3.2. 2. Todos los escenarios de casos de uso (y los diagramas correspondientes) deben organizarse en dos categorías.

4.3.3. 3. El líder de la revisión lee el caso de uso en forma deliberada.

4.3.4. 4. Cuando se pasa la ficha, se pide al poseedor de la tarjeta sensor que describa las responsabilidades anotadas en la tarjeta.

4.3.5. 5. Si las responsabilidades y colaboraciones anotadas en las tarjetas índice no se acomodan al caso de uso, éstas se modifican.

4.4. Clases

4.4.1. De entidad

4.4.1.1. Cambien llamada clases modelo o de negocio.

4.4.1.2. se extraen directamente del enunciado del problema.

4.4.1.3. Es común en una clase representen cosas almacenadas en bases de datos.

4.4.2. De frontera

4.4.2.1. Se utilizan para crear interfaz.

4.4.2.2. El usuario mira e interactua con el.

4.4.2.3. diseñan responsabilidad de administrar la forma en la que se le presenta a los usuarios los objetos.

4.4.3. De controlador

4.4.3.1. Administra una "unidad de trabajo".

4.4.3.2. Están diseñadas para administrar.

4.4.3.3. Creación o actualización de entidades del objeto.

4.4.3.4. Obtienen información de los objetos.

4.4.3.5. Comunicación entre conjunto de objetos.

4.4.3.6. Validación de datos comunicados entre objetos.

5. Mejora de un caso de uso preliminar

5.1. Es esencial describir interacciones alternativas. Después se evalúa cada paso en el escenario primario

5.1.1. ¿El actor puede emprender otra acción en este punto?

5.1.2. ¿Es posible que el actor encuentre alguna condición de error en este punto? Si así fuera, ¿cuál podría ser?

5.1.3. En este punto, ¿es posible que el actor encuentre otro comportamiento En ese caso, ¿cuál sería?

5.2. Una excepción describe una situación (ya sea condición de falla o alternativa elegida por el actor) que ocasiona que el sistema presente un comportamiento algo distinto

5.2.1. Recomienda el uso de una sesión de “lluvia de ideas” para obtener un conjunto razonablemente complejo de excepciones para cada caso de uso

5.2.2. ¿Existen casos en los que ocurra alguna “función de validación” durante este caso de uso? Esto implica que la función de validación es invocada y podría ocurrir una potencial condición de error.

5.2.3. ¿El mal desempeño del sistema da como resultado acciones inesperadas o impropias? Por ejemplo, una interfaz con base en web responde con demasiada lentitud

5.2.4. ¿Hay casos en los que una función (o actor) de soporte falle en responder de manera apropiada? Por ejemplo, una acción de usuario espera una respuesta pero la función que ha de responder se cae.

6. Filosofia y Objetivos

6.1. 1. Describir lo que requiere el cliente

6.2. 2. Establecer una base para la creación del diseño software

6.3. 3. Definir un conjunto de requerimientos que puedan validarse una vez construido el software.

7. Reglas básicas del análisis

7.1. 1. El modelo debe centrarse en los requerimientos que sean visibles dentro del problema o dentro del dominio del negocio. El nivel de abstracción debe ser relativamente elevado. “No se empantane en los detalles” [Arl02] que traten de explicar cómo funciona el sistema.

7.2. 2. Cada elemento del modelo de requerimientos debe agregarse al entendimiento general de los requerimientos del software y dar una visión del dominio de la información, de la función y del comportamiento del sistema.

7.3. 3. Hay que retrasar las consideraciones de la infraestructura y otros modelos no funcionales hasta llegar a la etapa del diseño. Es decir, quizá se requiera una base de datos, pero las clases necesarias para implementarla, las funciones requeridas para acceder a ella y el comportamiento que tendrá cuando se use sólo deben considerarse después de que se haya terminado el análisis del dominio del problema.

7.4. 4. Debe minimizarse el acoplamiento a través del sistema. Es importante representar las relaciones entre las clases y funciones. Sin embargo, si el nivel de “interconectividad” es extremadamente alto, deben hacerse esfuerzos para reducirlo.

7.5. 5. Es seguro que el modelo de requerimientos agrega valor para todos los participantes. Cada actor tiene su propio uso para el modelo. Por ejemplo, los participantes de negocios deben usar el modelo para validar los requerimientos; los diseñadores deben usarlo como pase para el diseño; el personal de aseguramiento de la calidad lo debe emplear como ayuda para planear las pruebas de aceptación.

7.6. 6. Mantener el modelo tan sencillo como se pueda. No genere diagramas adicionales si no agregan nueva información. No utilice notación compleja si basta una sencilla lista.

8. Escritura de un caso de uso formal

8.1. 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.

8.2. La precondición describe lo que se sabe que es verdadero antes de que inicie el caso de uso.

8.3. El disparador (o trigger) identifica el evento o condición que “hace que comience el caso de uso”

8.4. El escenario enlista las acciones específicas que requiere el actor, y las respuestas apropiadas del sistema.

8.5. Las excepciones identifican las situaciones detectadas cuando se mejora el caso de uso preliminar

8.6. La representación con diagramas facilita la comprensión, en particular cuando el escenario es complejo

9. Modelado Basado en Clases

9.1. 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.

9.2. Los elementos de un modelo basado en clases incluyen:

9.2.1. Las clases y los objetos

9.2.2. Atributos

9.2.3. Operaciones

9.2.4. Modelos clase-responsabilidad-colaborador (CRC)

9.2.5. Diagramas de colaboración

9.2.6. Paquetes

9.3. Identificación de las clases de análisis

9.3.1. 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. Si la clase (sustantivo) se requiere para implementar una solución, entonces forma parte del espacio de solución; de otro modo, si sólo es necesaria para describir la solución, es parte del espacio del problema.

9.3.2. Las clases de análisis se manifiestan en uno de los modos siguientes:

9.3.2.1. Entidades externas

9.3.2.1.1. s (por ejemplo, otros sistemas, dispositivos y personas) que producen o consumen la información que usará un sistema basado en computadora.

9.3.2.2. Cosas

9.3.2.2.1. (reportes, pantallas, cartas, señales, etc.) que forman parte del dominio de información para el problema.

9.3.2.3. Ocurrencias o eventos

9.3.2.3.1. (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.

9.3.2.4. Roles

9.3.2.4.1. (gerente, ingeniero, vendedor, etc.) que desempeñan las personas que interactúan con el sistema.

9.3.2.5. Unidades organizacionales

9.3.2.5.1. (división, grupo, equipo, etc.) que son relevantes para una aplicación

9.3.2.6. Lugares

9.3.2.6.1. (piso de manufactura o plataforma de carga) que establecen el contexto del problema y la función general del sistema.

9.3.2.7. Estructuras

9.3.2.7.1. (sensores, vehículos de cuatro ruedas, computadoras, etc.) que definen una clase de objetos o clases relacionadas de éstos.

9.3.3. Características de selección

9.3.3.1. Información retenida

9.3.3.1.1. La clase potencial sera útil solo si se debe recordar información sobre ella.

9.3.3.2. Servicios necesarios

9.3.3.2.1. La clase potencial debe tener un conjunto de operaciones identificables

9.3.3.3. Atributos multiples

9.3.3.3.1. La atención debe estar en la información "principal"

9.3.3.4. Atributos comunes

9.3.3.4.1. Se define un conjunto de atributos y se aplican a todas las instancias

9.3.3.5. Operaciones comunes

9.3.3.5.1. Se define un conjunto de operaciones y se aplican a todas las instancias

9.3.3.6. Requerimientos escenciales

9.3.3.6.1. Entidades externas que aparezcan en el espacio del problema y que produzcan o consuman información.

9.4. Especificación de atributos

9.4.1. Describen una clase que ha sido seleccionada para incluirse en el modelo de requerimientos.

9.4.2. Son los atributos que definen la clase.

9.4.3. Para desarrollar un conjunto de atributos significativos para una clase de análisis, debe estudiarse cada caso de uso y seleccionarse aquellas "cosas" que pertenezcan "razonablemente" a la clase.

9.5. Definición de las operaciones

9.5.1. Definen el comportamiento de un objeto.

9.5.2. Cuatro categorias.

9.5.2.1. Operaciones que manipulan datos.

9.5.2.2. Operaciones que realizan un cálculo.

9.5.2.3. Operaciones que preguntan sobre el estado de un objeto.

9.5.2.4. Operaciones que vigilan a un objeto.

9.5.3. Una operación debe tener "conocimiento" de la naturaleza de los atributos y de las asociaciones de la clase.

10. Asociaciones y dependencias

10.1. En muchos casos, dos clases de análisis se relacionan de cierto modo con otra, en forma muy parecida a como dos objetos de datos se relacionan entre sí.

10.2. En UML, estas relaciones se llaman asociaciones.

11. MODELOS UML QUE PROPORCIONAN EL CASO DE USO

11.1. Desarrollo de un diagrama de actividades

11.2. 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.

11.3. Un diagrama de actividades es similar a uno de flujo

11.3.1. 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

11.4. Diagramas de canal (swimlane)

11.4.1. 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

11.4.2. Al mismo tiempo, indica qué actor (si hubiera muchos involucrados en un caso específico de uso) o clase de análisis es responsable de la acción descrita por un rectángulo de actividad.

11.4.3. Son tres las clases de análisis

11.4.3.1. Propietario

11.4.3.2. Cámara

11.4.3.3. Interfaz

12. Paquetes de Anàlisis

12.1. Una parte importante del modelado del análisis es la categorización.

12.2. Se clasifican distintos elementos del modelo de análisis (por ejemplo, casos de uso y clases de análisis) de manera que se agrupen en un paquete "llamado paquete de análisis" al que se da un nombre representativo.

13. Análisis del dominio

14. Modelo de análisis de dominio

14.1. Taxonomías de clases

14.2. Estándares de reutilización

14.3. Modelos Funcionales

14.4. Lenguajes del dominio

15. Fuentes de conocimiento del dominio

15.1. Bibliografía Técnica

15.2. Aplicaciones existentes

15.3. Encuestas a clientes

15.4. Consejo de expertos

15.5. Requerimientos actuales y futuros