13-MODELAMIENTO DE SOFTWARE

El modelado del comportamiento es uno de los principios fundamentales de todos los métodos de análisis de requisitos dentro de la Ingeniería de requisitos. El modelo de comportamiento indica la forma en la que responderá el software a eventos o estímulos externos. Identifique, ¿cuál de los siguientes no corresponden a los pasos que deben seguirse en el modelado de comportamiento?. Evaluar todos los casos de uso para entender por completo la secuencia de interacción dentro del sistema. El diagrama de flujo de datos (DFD) es una técnica que representa el flujo de la información y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida; ya que adopta un punto de vista del tipo entrada-proceso-salida para el sistema. Identificar los eventos que conducen la secuencia de interacción y que entienden el modo en el que éstos se relacionan con objetos específicos. Crear una secuencia para cada caso de uso y construir un diagrama de estado para el sistema. Revisar el modelo de comportamiento para verificar la exactitud y consistencia.

El modelo de análisis es la primera representación técnica de un sistema. Utiliza una mezcla de formatos en texto y diagramas para representar los requisitos del software, las funciones y el comportamiento. El modelo de análisis describe la estructura del sistema o aplicación que está modelando. Consta de diagramas de clase y de diagramas de secuencia que describe la implementación lógica de los requisitos funcionales identificados en el modelo de caso de uso. Además, identifica las clases principales del sistema y contiene un conjunto de realizaciones de casos de uso que describen cómo se construirá el sistema. El modelo de análisis se apoya en cuatro elementos fundamentales y estos son: Clase, Responsabilidad, Colaborador, Descripción. Caso de Uso, Flujo de Información, Modelo Estático, Diagrama de Tiempo estimado en Carril. Basados en Escenarios, Orientados al flujo, Basados en Clases, Basados en el comportamiento. Entidad, Frontera, Controlador Agregación.

Requisito funcional es una descripción del servicio que debe ofrecer el software(sistema). Describe un sistema de software o su componente. Puede ser un cálculo, manipulación de datos, proceso comercial, interacción del usuario o cualquier otra funcionalidad específica que defina qué función probablemente realizará el sistema. En la Ingeniería de Requisitos, los requisitos funcionales pueden ser: Requisito que especifica los criterios que se pueden emplear para juzgar el funcionamiento de un sistema en condiciones particulares, en lugar de comportamientos específicos. Cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que se supone, un sistema debe cumplir. Imponer restricciones sobre cómo lo hará el sistema. Elaborar una característica de rendimiento del sistema. Todos los requisitos que no describen información a guardar, ni funciones a realizar, sino características de funcionamiento. Es así que suelen denominarse atributos de calidad de un sistema.

El caso de uso en la Ingeniería de Software es una técnica para la captura de requisitos potenciales de un nuevo sistema o la actualización de un software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. ¿Cuáles son los componentes del diagrama de casos de uso?. Actor, Caso de uso y la relación (o asociación). Caso de Uso, Clases y Atributos. Dependencia (relación de uso y Generalización/especialización (relaciones de herencia). Diagrama de paquetes, Diagrama de actividades, Diagrama de Despliegue.

El diagrama de casos de uso muestra de forma gráfica las características del software (sus funcionalidades) incluyendo: los casos de uso, los roles que los usuarios desempeñan en estos casos de uso. A estos roles se les denomina “Actores”. La interrelación entre los elementos. ¿Qué describe la relación (o asociación) como componente de un diagrama de Casos de uso?. Representa a una persona o grupo de personas que desempeñan un papel en la interacción con el software. Representa una funcionalidad que cumple uno o varios requisitos. Puede ser “cualquier elemento” externo que interactúe con el software para lograr determinados objetivos, como por ejemplo otros sistemas. La interacción entre dos casos de uso o de un actor con un caso de uso.

Los Diagramas estáticos o también llamados estructurales se encargan de definir qué elementos (entidades, objetos, áreas, clases, departamentos, componentes etc.) deben de estar definidas dentro del sistema u organización a desarrollar el correspondiente modelado. Se denomina Modelado Estático en Ingeniería de Software por que muestra todas las relaciones posibles a lo largo del tiempo, no las que corresponden a un cierto momento. ¿Cuáles diagramas le dan una perspectiva estática (Modelado estático) de un sistema de software?. Diagramas de clases, Diagramas de objetos, Diagramas de componentes y Diagramas de distribución. Diagramas de estado, Diagramas de interacción (secuencia, comunicación, tiempo y visión de conjunto) y Diagramas de actividad. Diagramas de Flujo de Datos, Diagrama de comunicación. Diagrama de GUI, Diagrama de Clases, Diagrama de Secuencia.

El diagrama de clases en UML es una herramienta para comunicar el diseño de un programa orientado a objetos, permitiendo modelar las relaciones entre las entidades El diagrama de clases estándar está compuesto por las siguientes partes: Sección superior: Contiene el nombre de la clase o de un objeto. Sección central: Contiene los atributos de la clase. Sección inferior: Incluye operaciones de clases (métodos o funciones). Flujos de Objetos y Objeto Nodo Inicial Nodo Final. Acciones Restricciones de Acción Flujo de Control. Estado Inicio del Flujo Fin del Flujo Transición.

Los diagramas dinámicos o conocidos como Diagramas de interacción en UML se utilizan para ver los aspectos dinámicos del sistema y constan de instancias de estos bloques y mensajes enviados entre ellos. ¿Cuáles diagramas le dan una perspectiva dinámica (Modelado dinámico) de un sistema de software?. Diagramas de casos de uso Diagramas de secuencia Diagramas de estados Diagramas de actividades. Estado Inicio del Flujo Fin del Flujo Transición. Diagramas de clases Diagramas de objetos Diagramas de componentes Diagramas de distribución. Diagrama Entidad – Relación Diagrama de Flujo de Datos.

El Diagrama de Secuencia en UML o conocidos también como diagramas de eventos o escenarios de eventos, son un tipo de diagramas de interacción donde se describe ¿cómo? y ¿en qué orden? un grupo de objetos funcionan en conjunto. Los desarrolladores de software, así como los profesionales de negocios usan estos diagramas para comprender los requisitos de un sistema nuevo documentar un proceso existente. ¿Que representan las Líneas de vida en un Diagrama de Secuencia en UML?. Representa la ejecución de un procedimiento o el funcionamiento de una actividad en un flujo de trabajo. Es el proceso en el que una subclase o clase derivada recibe la funcionalidad de una superclase o clase principal. Representa el curso del tiempo de un proceso. Indica cuál estado de actividad sigue a otro.

El sistema de biblioteca del barrio “Las colinas” actualmente funciona manualmente y se desean modelar sus procesos para llevarlo mediante un sistema automático. Es así que, para proceder al préstamo, el bibliotecario o encargado de la biblioteca atiende al usuario (o persona) que solicita algún préstamo (libro o revista). Lo que hace primero es llenar los datos del usuario en una hoja de Excel, y de allí empieza a comprobar en su sistema de archivos de Excel si el usuario adeuda algo. En el caso de no deber nada en biblioteca solo entonces procede a llenar los datos de la solicitud de préstamo y así genera el préstamo correspondiente. Se requiere el Diagrama de actividades para un sistema de Biblioteca. ¿Identifique cuál de ellos podría ser el diagrama de actividades que se aproxima a la respuesta más probable a este problema?. A. B. C. D.

En los diagramas de clases se pueden representar los siguientes tipos de relaciones: asociación, agregación, composición y generalización. Indique la opción que describe la relación de generalización. Es un tipo de asociación que indica que una clase (componente) es parte de otra clase (compuesto o contenedor). Los componentes pueden ser agregados a varios compuestos. La destrucción del compuesto no conlleva la destrucción de los componentes. Es una relación entre dos clases de modo que una, la subclase o clase hija, se considera como forma especializada de la otra, la superclase o clase padre. Es un tipo de asociación que indica que una clase (componente) es una parte especializada de otra clase (compuesto o contenedor). La destrucción del compuesto conlleva la destrucción de los componentes. Tipo de relación que expresa una relación entre dos clases mediante un acoplamiento débil. Las clases asociadas siguen siendo relativamente independientes una de otra. Se trata de una relación no muy fuerte, es decir que no se exige dependencia existencial ni encapsulamiento. Suele implementarse como variables de instancia de una clase en otra.

Las relaciones de asociación, agregación, composición y generalización se pueden representar en los diagramas de clases. ¿Cuál de las siguientes opciones describe la relación de composición?. Es un tipo de asociación que indica que una clase (componente) es parte de otra clase (compuesto o contenedor). Los componentes pueden ser agregados a varios compuestos. La destrucción del compuesto no conlleva la destrucción de los componentes. Es una relación entre dos clases de modo que una, la subclase o clase hija, se considera como forma especializada de la otra, la superclase o clase padre. Es un tipo de asociación que indica que una clase (componente) es una parte especializada de otra clase (contenedor). La destrucción del contenedor conlleva la destrucción de los componentes. Tipo de relación que expresa una relación entre dos clases mediante un acoplamiento débil. Las clases asociadas siguen siendo relativamente independientes una de otra. Se trata de una relación no muy fuerte, es decir que no se exige dependencia existencial ni encapsulamiento. Suele implementarse como variables de instancia de una clase en otra.