TRABAJO GRUPAL
MODELADO DE SOFTWARE ⭐
Modelos de Caso de Uso
Un caso de uso es un artefacto que define una secuencia de acciones que da lugar a un resultado de valor observable. Los casos de uso proporcionan una estructura para expresar requisitos funcionales en el contexto de procesos empresariales y de sistema. Los casos de uso pueden representarse como un elemento gráfico en un diagrama y como una especificación de caso de uso en un documento textual.
Protocolos de gestión de contrato de Diseño
CARACTERISTICAS: Estos modelos llegan a proporcionar una información detallada acerca de los comportamientos del sistema. En este caso los diagramas usados dentro del caso de uso describen aquellas relaciones que hay entre los casos de uso y los actores, además, los diagramas de actividad representan el flujo de los objetos y control en cada procedimiento identificado.
Se representan procesos empresariales, así como sistemas y procesos de programación orientada a objetos. Por lo tanto, UML no es un lenguaje de programación, sino un lenguaje de modelado, es decir, un método estandarizado para representar sistemas planificados o ya existentes. En este diagrama, todos los objetos involucrados se estructuran y se relacionan entre sí.
Los modelos de caso de uso proporcionan información detallada sobre los comportamientos del sistema o la aplicación de software que se está desarrollando. Los diagramas de caso de uso describen las relaciones ente los casos de uso y los actores, y los diagramas de actividad describen el flujo de los objetos y control en cada comportamiento identificado.
USOS: Son unas herramientas simples para describir el comportamiento del software o de los sistemas. Un caso de uso contiene una descripción textual de todas las maneras que los actores previstos podrían trabajar con el software o el sistema.
EJEMPLOS DE CASO DE USO:
- Casos de uso en el sector minorista:representa las funciones internas y las interacciones de los empleados dentro de un sistema de venta al por menor.
- Casos de uso para restaurante:operaciones diarias de un restaurante son el sistema, el personal que representa a los actores y sus tareas son los casos de uso
- Casos de uso de viaje: muestra cómo los diferentes tipos de usuarios pueden interactuar con un sitio web o una aplicación de reservas de viajes.
- Casos de uso en un banco: representa diferentes tipos de transacciones como casos de uso.
- Casos de uso de una tienda de electrónica de consumo:
ilustra cómo los equipos de ventas y gestión pueden utilizar un sistema de venta al por menor para llevar a cabo tareas.
El Modelo de Diseño
Se basa sobre el modelo de análisis describiendo, en mayor detalle, la estructura del sistema y cómo será implementado el sistema.
También, se basa en el análisis y requisitos arquitectónicos del sistema. Representa los componentes de aplicación y determina su colocación correcta y uso dentro de la arquitectura general.
CARACTERISTICAS
- Los paquetes contienen los elementos de diseño del sistema, como clases de diseño, interfaces y subsistemas de diseño, que evolucionan desde las clases de análisis.
- - Cada paquete puede contener cualquier número de subpaquetes que pueden particionar aún más los elementos de diseño contenidos.
- - Estas capas arquitectónicas forman la base de una organización de segundo nivel de los elementos que describen las especificaciones y detalles de implementación del sistema.
- - Dentro de cada paquete, los diagramas de secuencia ilustran cómo interactúan los objetos en las clases, diagramas de estado de las máquinas para modelar el comportamiento dinámico en las clases, diagramas de componentes para describir la arquitectura de software del sistema y diagramas de despliegue para describir la arquitectura física del sistema
EJEMPLOS:
Modelo de diseño creado por el ingeniero de software.
Modelo del usuario: que puede ser creado por el ingeniero de software u otros ingenieros.
Percepción del usuario.
Imagen del sistema creada por los que implementan el sistema.
Elementos de diseño:
a) Diagrama de menús.
b) Diseño de cada una de las pantallas del sistema de acuerdo con el diagrama jerárquico.
c) Conteo de Puntos de función
click to edit
click to edit
Modelos de Análisis
El modelo de diseño lo que hace es basarse en el análisis dando la mayor cantidad de detalle de la estructura del sistema y de que forma va a ser implementado. Las clases ya definidas en el modelo de análisis se redefinen para de esta forma poder incluir en la construcción
En el modelo de diseño, los paquetes que contiene los elementos de diseño del sistema como pueden ser las interfaces y subsistemas de diseño las cuales evolucionan desde las clases de análisis.
Cada uno de los ya mencionados paquetes puede tener cualquier cantidad de subpaquetes lo que permite particionar los elementos de diseño contenidos.
Al inicio de este se ilustra una visión general del software, con esto nos referimos a representar a un nivel mas alto y detallado en el cual se aclara directamente el objetivo y los requerimientos del sistema
Protocolos de gestión de contrato de diseño
Los protocolos de gestión de contrato de diseño o DCPM trata de la captura y el diseño de los requisitos formales mediante el control y el cumplimiento. Existen varios métodos o protocolos de gestión de contrato de diseño los cuales nos dan diferentes niveles de gestión y el control de modelo y el sistema.
La elección de este depende del entorno de trabajo, tiempo y el control de la arquitectura necesaria para el desarrollo del software.
La decisión sobre el protocolo que se va a usar puede cambiar por una o mas circunstancias como lo son:
• La fase del ciclo de desarrollo
• La ubicación física del trabajo de desarrollo (en la empresa, subcontratado, en el exterior) y las relaciones comerciales entre los equipos involucrados
• La naturaleza del producto y el entorno normativo en el que se desarrolla el software
• El ámbito del proyecto y la duración estimada
Y estos son los protocolos más usados o típicos
• Edición visual 3GL (Modelado concreto)
• Modelos concretos generados a partir de modelos conceptuales
• Modelado mixto
• Modelado reconciliado
• Desarrollo guiado por modelos conceptuales
click to edit