Artefactos
Artefactos Descripción
Modelo de Casos de Uso
Es un modelo de las funciones deseadas del sistema y su ambiente, y sirve como un convenio entre el cliente y los diseñadores. El modelo de casos de uso se usa como una entrada esencial a las actividades en el análisis, plan, y prueba.
Paquete de casos de uso
Es una colección de casos del uso, actores, relaciones, diagramas, y otros paquetes; se usa para estructurar el modelo de casos de uso dividiéndolo en partes menores.
Caso de Uso Define un conjunto de instancias del caso de uso dónde cada instancia es una sucesión de acciones que un sistema realiza y que rinde un resultado de valor observable a un actor particular.
Actor El modelo de casos de uso describe lo que hace el sistema para cada tipo de usuario. Cada uno de estos se representan mediante unos o más actores. También se representan mediante un actor cada sistema externo con el que interactúa el sistema. Por tanto, los actores representan terceros fuera del sistema que colaboran con el mismo. Una vez que hemos identificado todos los actores, tenemos identificado el entorno externo al sistema.
Descripción de la arquitectura.
Contiene una vista de la arquitectura del modelo de casos de uso, que representan los casos de uso significativos para la
(Vista del modelo de casos de uso).
arquitectura. La vista de la arquitectura de modelo de casos de uso debería incluir los casos de uso que describan alguna funcionalidad importante y crítica, o que impliquen algún requisito importante que deba desarrollarse pronto dentro del ciclo de vida del software. Esta vista de la arquitectura se utiliza como entrada cuando se priorizan los casos de uso para su desarrollo (análisis, diseño, implementación) dentro de cada iteración.
Descripción de la arquitectura del software.
Proporciona una apreciación global arquitectónica comprensiva del sistema, usando diferentes vistas arquitectónicas para delinear aspectos diferentes del sistema. Glosario Define términos importantes usados en el proyecto. Es muy
útil para alcanzar un consenso entre los desarrolladores relativo a la definición de los diversos conceptos y nociones, y para reducir el riesgo de confusiones. Se puede obtener a partir de un modelo de negocio o de un modelo del dominio, pero debido a que es menos formal (no incluye clases ni relaciones explícitas), es más fácil de mantener y más intuitivo para utilizarlo con terceras personas externas, como usuarios y clientes. Se centra más en el sistema que se va a construir, en lugar de en su contexto.
Prototipo de interfaz de usuario
Nos ayuda a comprender y especificar las interacciones entre actores humanos y el sistema durante la captura de requisitos. No sólo nos ayuda a desarrollar una interfaz gráfica mejor, sino también a comprender mejor los casos de uso. Para especificar la interfaz de usuario también pueden utilizarse otros artefactos, como los modelos de interfaz gráfica y los esquemas de pantallas.
Modelo de análisis. Un modelo de objeto que describe la realización de los casos de uso, sirve como una abstracción del artefacto "Modelo de
Diseño". Contiene los resultados del análisis de casos de uso, instancias del artefacto: "Clase de análisis". Dentro del modelo de análisis los casos de uso se describen mediante clases de análisis y sus objetos. Esto se representa mediante colaboraciones dentro del caso de uso que llamamos “realizaciones de caso de uso –análisis”.
Clase de análisis Las clases del análisis representan un modelo conceptual temprano para "las cosas en el sistema que tienen responsabilidades y comportamientos". Se centra en los requisitos funcionales y deja a un lado los no funcionales, esto hace que una clase de análisis sea más evidente en el contexto del dominio, más “conceptual”. Definen atributos pero de un nivel bastante alto. Siempre encajan dentro de uno de los tres estereotipos siguientes: de interfaz, de control y de entidad. Las de entidad encapsulan un fenómeno importante del dominio del problema, las clases de interfaz encapsulan interfaces de comunicación importantes, las clases de control que encapsulan secuencias con una amplia cobertura (o sea, aquellas que coordinan realizaciones de casos de uso significativas). Usar estos estereotipos hace la arquitectura mucho más robusta.
Realización de caso de uso-análisis.
Es una colaboración dentro del modelo de análisis que describe cómo se lleva a cabo y se ejecuta un caso de uso determinado en términos de las clases del análisis y se de sus objetos del análisis en interacción. Posee una descripción textual del flujo de sucesos, diagramas de clases que muestran sus clases de análisis participantes, y diagramas de interacción que muestra la realización de un flujo o escenario particular del caso de uso en términos de interacciones de
funcionales pudiendo posponer el tratamiento de los requisitos no funcionales hasta el diseño e implementación. Paquete del análisis Proporcionan un medio para organizar los artefactos del
modelo de análisis en piezas manejables. Puede contar con clases de análisis, realizaciones de casos de uso, y otros paquetes del análisis. Lo paquetes del análisis deberían ser cohesivos (es decir, sus contenidos deberían estar fuertemente relacionados), y deberían ser débilmente acoplados (es decir, sus dependencias unos de otros deberían minimizarse)
Descripción de la arquitectura (vista del modelo de análisis)
Proporciona una vista de la arquitectura desde el modelo de análisis. Los siguientes artefactos normalmente se consideran significativos para la arquitectura:
_ la descomposición del modelo de análisis en paquetes y sus dependencias
_ Las clases fundamentales del análisis como: las de interfaz, de control, de entidad y clases de análisis que son generales y centrales
_.Las realizaciones de los casos de uso.
Modelo del diseño Es un modelo de objetos que describe la realización física de los casos de uso centrándose en cómo los requisitos funcionales y no funcionales junto a otras restricciones del entorno de implementación tienen impacto en el sistema a considerar. Sirve como una abstracción del modelo de implementación y su código fuente, se usa como la entrada esencial a las actividades en la implementación y prueba. Clase de diseño Una clase es una descripción de un conjunto de objetos que
comparten las mismas responsabilidades, relaciones, funcionamientos, atributos, y semántica. Una clase de diseño es la parte fundamental de un enfoque de diseño orientado a objetos. Los métodos de la clase de diseño tienen
correspondencia directa con los métodos de la implementación.
Realización de caso de uso-diseño
Es una colaboración en el modelo de diseño que describe cómo se realiza el caso de uso, y cómo se ejecuta en términos de clases de diseño y objetos. Proporciona una traza directa de una realización de caso de uso-análisis. Tiene una descripción del flujo de eventos textual, diagramas de clases de diseño, diagramas de interacción que muestran la realización de un escenario concreto de un caso de uso (los diagramas pueden mostrar además subsistemas y sus interfaces). Puede posponer el manejo de algún requisito para la implementación.
Subsistema de diseño. Son una forma d e organizar los artefactos del modelo de diseño en piezas más manejables. Pueden contar con clases de diseño, realizaciones de casos de uso, interfaces y otros subsistemas, puede proporcionar interfaces que representan la funcionalidad que exportan en términos de operaciones. Deberían ser cohesivos (sus contenidos encontrarse fuertemente relacionados) y débilmente acoplados las dependencias entre unos y otros o entre sus interfaces deben ser mínimas.
Interfaz Define un comportamiento ofrecido por un elemento de modelo clasificador (específicamente, una clase, subsistema o componente). Cada interfaz debe proporcionar un único y bien-definido juego de funcionamientos.
Descripción de la arquitectura (Vista del modelo de diseño).
Contiene una vista de la arquitectura desde el modelo de diseño. Suelen ser significativos para la arquitectura los siguientes artefactos del modelo de diseño:
_Clases de diseño fundamentales como las que poseen traza directa con clases de análisis significativas, clases activas, y clases generales y centrales que representan mecanismos de diseño genéricos.
_Realizaciones de casos de uso que describan una funcionalidad crítica a desarrollar pronto dentro del ciclo de vida del software.
Modelo de despliegue. Es un modelo de objetos que muestra la configuración de los nodos en tiempo de ejecución, los enlaces de comunicación entre ellos, y las instancias de componente y objetos que residen en ellos.
Descripción de la arquitectura (Vista del
modelo de despliegue).
Contiene una vista de la arquitectura desde el modelo de despliegue. Debido a su importancia , deberían mostrarse todos los aspectos del modelo de despliegue en la vista arquitectónica, incluyendo la ubicación de los componentes en cada nodo
Modelo de implementación.
Describe cómo los elementos del modelo de diseño, como las clases, se implementan en términos de componentes, como ficheros de código fuente, ejecutables, etc. Describe también se organizan los componentes de acuerdo con los mecanismos de estructuración y modularización disponibles en el entorno de implementación y en el lenguaje o lenguajes de programación usados, y como dependen los componentes unos de otros.
Componente Es el empaquetamiento físico de los elementos de un modelo, como son las clases en el modelo de diseño. Algunos estereotipos de componentes son los siguientes: <<executable>> programa que puede ser ejecutable en un nodo, <<file>> un fichero que contiene código fuente o datos, <<library>> Librería estática o dinámica, <<table>> e una
tabla de base de datos, <<document>> es un documento. Subsistema de
implementación
Proporciona una forma de organizar los artefactos del modelo de implementación en trozos más manejables. Puede estar formado por componentes, interfaces y otros subsistemas. Además puede implementar -y así proporcionar- las interfaces que representan la funcionalidad que exportan en forma de operaciones. Deberían seguir la traza uno a uno (isomórficamente) de sus subsistemas de diseño correspondientes.
Descripción de la arquitectura (Vista del
modelo de implementación)
Describe la arquitectura desde la vista del modelo de implementación. Los siguientes artefactos son usualmente considerados significativos arquitectónicamente:
_La descomposición del modelo de implementación en subsistemas, sus interfaces y las dependencias entre ellos. _Componentes claves, como los componentes que siguen la traza de las clases de diseño significativas arquitectónicamente, los componentes ejecutables y los componentes que son generales , centrales , que implementan mecanismos de diseño genéricos de los que dependen muchos otros componentes.
Plan de integración de construcciones
Describe la secuencia de construcciones necesarias en una iteración. Más concretamente describe lo siguiente para cada construcción:
_ La lista de funcionalidad que se espera que sea implementada en dicha construcción. Consiste en una lista de casos de uso o escenarios o parte de ellos, y puede también referirse a otros requisitos adicionales.
_Las partes del modelo de implementación afectadas por la construcción. Esto es una lista de subsistemas y componentes
construcción.
Modelo de pruebas. Describe cómo se prueban los componentes ejecutables (como las construcciones) en el modelo de implementación con pruebas de integración y de sistema. Puede describir además como han de ser probados aspectos específicos del sistema, por ejemplo: si la interfaz de usuario es utilizable y consistente o si el manual de usuario del sistema cumple con su cometido.
Caso de prueba. Especifica una forma de probar el sistema, incluyendo la entrada o resultado con la que se ha de probar y las condiciones bajo las que ha de probarse. Los siguientes son casos de prueba comunes: caso de prueba para un caso de uso o escenario específico, caso de prueba para una realización de caso de uso-diseño o para un escenario específico de la realización.
Procedimiento de prueba.
Especifica cómo realizar uno o varios casos de prueba o partes de estos. Por ejemplo, un procedimiento de prueba puede ser una instrucción para un individuo sobre cómo realizar un caso de prueba manualmente, o puede ser sobre cómo interaccionar manualmente con una herramienta de automatización de pruebas para crear componentes ejecutables de prueba.
Componente de prueba.
Automatiza uno o varios procedimientos de prueba o partes de ellos. Pueden ser desarrollados utilizando un lenguaje de guiones o un lenguaje de programación, o pueden ser grabados con una herramienta de automatización de pruebas. Se emplean para probar los componentes del modelo de implementación proporcionando entradas de prueba, controlando y monitorizando la ejecución, y/o informando de resultados de prueba.
Plan de prueba Describe las estrategias, recursos y planificación de la prueba. Incluye la definición del tipo de pruebas a realzar para cada iteración y sus objetivos, el nivel de cobertura de prueba y de código necesario y el porcentaje de pruebas que deberían ejecutarse con un resultado específico.
Defecto Una anomalía del sistema. Puede ser utilizado para localizar cualquier cosa que los desarrolladores necesitan registrar como síntoma de un problema que se requiere controlar y resolver.
Evaluación de Prueba. Es una evaluación de los resultados de los esfuerzos de prueba, tales como la cobertura del caso de prueba, la cobertura de código y el estado de los defectos.
Modelo del Dominio Un modelo del dominio captura los tipos más importantes de objetos en el contexto del sistema. Los objetos del dominio representan las “cosas” que existen o los eventos que suceden en el entorno en el que trabaja el sistema. Este modelo se realiza en reuniones organizadas por los analistas del dominio. Su objetivo es comprender y describir las clases más importantes del contexto del sistema.
Modelo del negocio Es una técnica para comprender los procesos de negocio de la organización. Está soportado en UML por 2 tipos de modelos: modelo de casos de uso del negocio y modelo de objetos del negocio. Un modelo de casos de uso del negocio describe los procesos de negocio de una empresa en términos de casos de uso del negocio y actores del negocio que se corresponden con los procesos del negocio y los clientes, respectivamente. Un modelo de objetos del negocio está compuesto por trabajadores, entidades y unidades de trabajo que juntos realizan los casos de uso del negocio.
pueden asociarse a ningún caso de uso concreto, en cambio pueden tener impacto en varios casos de uso o en ninguno. Algunos ejemplos son el rendimiento, las interfaces y los requisitos de diseño físico, así como las restricciones arquitectónicas, de diseño y de implementación. Los requisitos de interfaz especifican la interfaz con un elemento externo con el cual debe interactuar el sistema, o que establece restricciones condicionantes en formatos, tiempos, u otros factores de relevancia en dicha interacción. Un requisito físico especifica una característica física que debe poseer un sistema, como su material, forma, tamaño o peso. Por ejemplo, puede usarse este tipo de requisito para representar requisitos de hardware como configuraciones físicas de red requeridas. Las restricciones de diseño limitan el diseño del sistema como lo hacen las de extensibilidad y mantenibilidad, o las relativas a reutilización de sistemas heredados o partes esenciales de los mismos. Las restricciones de implementación limitan la codificación, ejemplo : los estándares requeridos, normas de codificación, lenguajes de programación, políticas de integridad de la base de datos, limitaciones de recursos, y entornos operativos
Lista de Características
Una breve descripción general o una especificación de requisitos detallada que incluye las características generales que se requieren para un sistema.
Disciplina: Requerimientos.
Actividad Propósito y descripción. Artefactos
actores y casos de uso
interactuar con el sistema.
_Definir el alcance del sistema—lo que se manejará por el sistema y lo que se manejará fuera del sistema.
_Esbozar la funcionalidad del sistema.
_Capturar y definir un glosario de términos comunes esenciales para la creación de descripciones detalladas de las funcionalidades del sistema (o sea, los casos de uso).
negocio (o modelo del dominio),Requisitos adicionales, Lista de características. Salida: _Modelo de casos de uso (esbozado). _Glosario. Priorizar casos de uso
_ Definir el conjunto de escenarios y casos del uso que serán analizados en la iteración actual. _Definir el conjunto de escenarios y casos de uso que representan alguna funcionalidad significativa y central.
_Definir el conjunto de escenarios y casos de uso que tienen una cobertura arquitectónica sustancial o que enfatizan o ilustran un punto específico y/o delicado de la arquitectura.
Entrada: _Modelo de casos de uso(esbozado). _Requisitos adicionales. _Glosario. Salida: _Descripción de la arquitectura (vista del modelo de casos de uso).
Detallar caso de uso
_Describir uno o más flujo de eventos del caso del uso en el detalle suficiente para permitir el comienzo del desarrollo en este.
_Describir la especificación de caso de uso para la comprensión y satisfacción del cliente.
Entrada:
_modelo de casos de uso (esbozado), Requisitos
adicionales, Glosario Salida: Caso de uso (detallado).
Prototipar la interfaz
_Crear un diseño de la interfaz de usuario que se apoye sobre el razonamiento, y el
Entrada:
requerimientos funcionales planteados o sea que permita al usuario llevar a cabo los casos de uso de manera eficiente.
(Descrito),Requisitos adicionales, Glosario Salida: _Prototipo de interfaz de usuario Estructurar el modelo de casos de uso.
_Extraer el comportamiento en casos de uso que necesitan ser considerados como casos de uso abstractos. Ejemplos de tal conducta son el comportamiento común, comportamiento opcional, comportamiento excepcional, y comportamiento que será desarrollado en próximas iteraciones.
_Búsqueda de nuevos actores abstractos que definen "roles" o "papeles" compartido por varios actores.
_Extraer descripciones de funcionalidad (de casos de uso) adicionales u opcionales que pueden extender descripciones (de casos de uso) más específicas. Entrada: _ Modelo de casos de uso (esbozado). _requisitos adicionales. _ Caso de uso (descrito). _Glosario Salida: Modelo de casos de uso (estructurado). Disciplina: Análisis.
Actividad Propósito y descripción. Artefactos
Análisis de la arquitectura.
_ Esbozar el modelo de análisis y la arquitectura mediante la identificación de paquetes del análisis, clases de análisis evidentes, y requisitos especiales comunes (requisitos que aparecen en el análisis como ejemplo están las limitaciones o restricciones sobre:
Entrada:
_Modelo de casos de uso _Requisitos adicionales. _Modelo del negocio(o del dominio)
_Descripción de la arquitectura (Vista del modelo de casos de uso).
persistencia, distribución y concurrencia, características de seguridad, gestión de transacciones, tolerancia a fallos, etc.)
Salida:
_Paquete de análisis (esbozo).
_clase del análisis.
_ Descripción de la arquitectura (Vista del modelo de análisis)
Analizar un caso de uso.
_Identificar las clases del análisis cuyos objetos son necesarios para llevar a cabo el flujo de sucesos del caso de uso.
_Distribuir el comportamiento del caso de uso entre los objetos del análisis que interactúan.
_Capturar requisitos especiales sobre la realización del caso de uso.
Entrada:
_Modelo de casos de uso _Requisitos adicionales. _Modelo del negocio(o del dominio)
_Descripción de la arquitectura (Vista del modelo de análisis). Salida: _Realización de caso de uso –análisis _Clase de análisis. Analizar una clase.
_Identificar y mantener las responsabilidades de una clase del análisis, basadas en su papel en las realizaciones de caso de uso.
_Identificar y mantener atributos y relaciones de la clase del análisis.