Sistemas II
De Computacion
El desarrollo de software en sus inicios era considerado como un elemento añadido, en donde no existían metodologías claras de desarrollo, con decir que las personas u organizaciones que desarrollaban eran los usuarios del mismo, luego de tareas sumamente cansadas por parte de los programadores se lograba obtener los productos pero que eran muy medida y no podían ser comercializados o distribuidos. Actualmente esa idea de desarrollo ha cambiado luego de haber pasado por algunas etapas y se tienen metodologías que nos apoyan en el desarrollo, para ir a ya a algo mas lejos que es la Ingeniería del Software que hoy en día esta reconocida como una disciplina que ofrece métodos y técnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo. La presente materia se enfoca en el estudio del proceso unificado de desarrollo de software, cada una de sus disciplinas iniciando con el capítulo I en donde da una introducción al proceso de desarrollo, sus características y fases. El capítulo II, damos una vista a la problemática de la captura de requisitos, que son los modelos de negocio y domino. Desde el capítulo III, se inicia el estudio de los flujos de trabajo como son captura de requisitos, análisis, diseño e implementación. Los flujos siguientes no se abarcan en esta guía pero situaciones de tiempo de estudio pero deberían conocerlos y revisarlos Comprender la importancia de la Auditoría Informática en el entorno tecnológico actual de las organizaciones y las oportunidades de desarrollo profesional para los conocedores de las tecnologías de la información.
Tabla de contenidos
|
[editar] Objetivos Generales
-
Proveer al estudiante las herramientas necesarias para que pueda desarrollar un producto de software utilizando una metodología de desarrollo de software.
- Comprender la importancia de contar con metodologías para la construcción de productos de software.
[editar] Objetivos Especificos
- Conocer que es el proceso unificado de desarrollo de software
- Aplicar las fases del proceso de desarrollo unificado
- Entender la problemática de la captura de requisitos para ser aplicada en proyectos reales.
- Entender la necesidad de capturar los requisitos como caso de uso.
- Conocer cada uno de los trabajadores y artefactos involucrados en la captura de requisitos como casos de uso.
- Conocer que elementos comprende el flujo de análisis.
- Saber aplicar cada uno de los flujos de trabajo a los proyectos reales
- Relacionar cada uno de los elementos del análisis con los componentes UML.
- Comprender el flujo de trabajo presente en el flujo del diseño.
- Describir el papel de cada uno de los trabajadores necesarios que intervienen en el flujo de diseño.
- Describir las actividades que deben desarrollarse para el flujo de diseño.
- Describir cada uno de los artefactos resultantes de las actividades que se realizan en el flujo de diseño.
- Comprender el flujo de trabajo presente en el flujo de la implementación.
- Describir el papel de cada uno de los trabajadores necesarios que intervienen en el flujo de implementación.
- Describir las actividades que deben desarrollarse para el flujo de implementación.
- Describir cada uno de los artefactos resultantes de las actividades que se realizan en el flujo de implementación.
- Conocer que es el proceso unificado de desarrollo de software
- Aplicar las fases del proceso de desarrollo unificado
- Entender la problemática de la captura de requisitos para ser aplicada en proyectos reales.
- Entender la necesidad de capturar los requisitos como caso de uso.
- Conocer cada uno de los trabajadores y artefactos involucrados en la captura de requisitos como casos de uso.
- Conocer que elementos comprende el flujo de análisis.
- Saber aplicar cada uno de los flujos de trabajo a los proyectos reales
- Relacionar cada uno de los elementos del análisis con los componentes UML.
- Comprender el flujo de trabajo presente en el flujo del diseño.
- Describir el papel de cada uno de los trabajadores necesarios que intervienen en el flujo de diseño.
- Describir las actividades que deben desarrollarse para el flujo de diseño.
- Describir cada uno de los artefactos resultantes de las actividades que se realizan en el flujo de diseño.
- Comprender el flujo de trabajo presente en el flujo de la implementación.
- Describir el papel de cada uno de los trabajadores necesarios que intervienen en el flujo de implementación.
- Describir las actividades que deben desarrollarse para el flujo de implementación.
- Describir cada uno de los artefactos resultantes de las actividades que se realizan en el flujo de implementación.
[editar] Bibliografía
Texto Básico:
[BJR2000] BOOCH Grady, JACOBSON Ivar, RUMBAUGH James. EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE. Addison Wesley. Madrid. 2000. 438 p.
Bibliografía complementaria:
- [BRA2000] BRAUDE Eric. INGENIERÍA DE SOFTWARE, Una perspectiva orientada a objetos. AlfaOmega. México DF. 2003. 515 p.
-
[LAR1999] LARMAN Craig. UML y Patrones, Introducción al análisis y diseño orientado a objetos. PRENTICE HALL. México. 1999. 536 p.
- Es un libro importante por su contenido, fácil y amigable, y por practicidad se convierte en una importante fuente de consulta.
-
[ROD1993] RODRIGUEZ Cuadrado Alfredo, MÁRQUEZ Serrano Antonio. TÉCNICAS DE ORGANIZACIÓN Y ANÁLISIS DE SISTEMAS, Organización de los servicios informáticos. McGrawHill. Madrid. 1993. 361 p.
Este texto es muy útil debido a que es muy práctico y fácil de utilizar, presenta un muy buen trabajo en lo que se refiere al análisis de las organizaciones y al estudio de ciclos de vida de desarrollo de sistemas.
-
[RUM1996] RUMBAUGH James y otros. MODELADO Y DISEÑO ORIENTADO A OBJETOS, Metodología OMT. PRENTICE HALL. 1996. 643 p.
En lo relacionado al análisis y diseño orientado a objetos, es recomendable este libro, mismo que trata de una manera muy comprensible los temas relacionados con el pensamiento orientado a objetos.
- [FOW1999] FOWLER Martin, UML GOTA A GOTA. Addison Wesley. 1999. 224 p.
Este libro es muy práctico si ya se conoce un poco la metodología orientada a objetos, presenta un acercamiento muy bueno a lo que es UML y como material de consulta rápido es muy bueno.
[BOO1999] BOOCH Grady, JACOBSON Ivar, RUMBAUGH James. EL LENGUAJE UNIFICADO DE MODELADO. Addison Wesley. 1999. 464 p.
Los creadores de UML, han unido sus esfuerzos para crear un libro completo sobre UML, una muy buena herramienta para personas que ya tienen experiencia en el análisis y diseño de sistemas, se profundiza en el modelo y ha servido de mucha ayudad para complementar muchos temas relacionados con esta guía.
Referencias Internet: Una de las páginas en Internet más importante relacionada con este es:
- www.rational.com
Es la página de RATIONAL SOFTWARE, la empresa fundada por los creadores del UML, en ella encontrará muchos recursos y herramientas de mucha importancia así como soporte para su trabajo con UML.
- www.omg.com
Es el sitio de Object Management Group, es un equipo dedicado a la investigación y a los estándares de la tecnología orientada a objetos
- www.javadevelopersjournal.com
Esta página es la oficial de la revista Java Developers Journal, que tiene mucha información sobre las últimas tendencias del desarrollo con Java.
- www.dcc.uchile.cl/~psalinas/uml/introduccion.html
En esta dirección encontrará un tutorial de UML bastante completo y totalmente en español.
En esta dirección encontrará información sobre captura de requisitos, análisis y diseño orientados a objetos con ejemplos prácticos desarrollados a través de UML.
[editar] Desarrollo del Aprendizaje
[editar] Capitulo1: Introducción al proceso unificado de desarrollo
[editar] Datos Generales:
| Texto Base | [BJR2000] |
| Capítulo | 1. El proceso Unificado, 2. Las cuatro “P” en el desarrollo de software |
| Páginas | 4 - 29 |
| Horas de estudio empleadas para el desarrollo del contenido | 8 horas |
[editar] Propositos:
El desarrollo de software es un proceso complejo, que nos causa muchos dolores de cabeza, es por eso que se debe optar por metodologías que nos permitan organizar los procesos y llegar a la culminación de los proyectos a de una manera mas adecuada. En el presente capítulo se pretende dar una visión general del proceso unificado de desarrollo (RUP)
[editar] Conceptos Claves:
- Metodología de Desarrollo.-
Una metodología se constituye en una ordenación de los procesos para poder realizar proyectos de desarrollo, metodologías existen muchas dependiendo de las necesidades, características de los proyectos, tipo de organización de los grupos de desarrollo
- RUP.-
Proceso Unificado de Desarrollo, y es el motivo de estudio en esta materia, es decir es una metodología de desarrollo, la cual esta compuesta por algunas fases y flujos.
- Fases de Desarrollo.-
Una fase se constituye en un hito mayor a cumplir la cual tiene varias iteraciones, y cada una de estas se encuentra relacionada con otra fase. En las fases de desarrollan los flujos los cuales, los cuales pueden realizarse en paralelo.
[editar] Esquema de Estudio:
A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que cada estudiante estima que necesita tutoría y realizar anotaciones personales.
| Tema a revisar | Descripción del Contenido a revisar | Actividades Recomendadas | Planificación Personal del estudio (fecha) | ¿Requiero Tutorial? | Anotaciones |
|---|---|---|---|---|---|
| 1.1 Características del proceso unificado de desarrollo | En el presente capítulo se pretende identificar los elementos principales del computador.
Diferenciar que la arquitectura de la organización. | Elabore un cuadro sinóptico de las características del proceso unificado de desarrollo.
Piense en un ejemplo que le permita comprender por que el proceso tiene esas características y cuales serian las ventajas de tenerlas. | |||
| 1.2. Fases dentro del ciclo de vida | Las fases del ciclo de vida son cuatro en este tema se presentan las fases con cada uno de los productos, y los objetivos de cada una de las fases | Revise el gráfico de la fig. 1.5 del libro base y realice un análisis de los flujos que se realizan en cada una de estas fases.
Entienda los productos que se entregan en cada una de las fases y busque la relación secuencial que existe en la entrega de los productos en de acuerdo a cada una de las fases |
Introducción al proceso unificado de desarrollo
El desarrollo de software es un proceso complejo, que nos causa muchos dolores de cabeza, es por eso que se debe optar por metodologías que nos permitan organizar los procesos y llegar a la culminación de los proyectos a de una manera mas adecuada. La figura 1.1 muestra los orígenes del proceso unificado de desarrollo de software, revise bibliografía adicional para profundizar en el tema.
Tenga claro que es el proceso unificado de desarrollo de software, así mismo como las características de este, que a continuación se describen:
Características del proceso unificado de desarrollo
Dirigido por casos de uso:
El objetivo de los sistemas es de brindar servicios a los usuarios como a otros sistemas, un caso de uso es una facilidad que el software ofrece a los usuarios. Los casos de uso reemplazan la antigua especificación funcional tradicional y constituyen la guía fundamental establecida para las actividades a realizar durante todo el proceso de desarrollo incluyendo el diseño, la implementación y las pruebas del sistema.
Analice e interprete el gráfico de la figura 1.1
Céntrese en comprender, casos de uso, sistema y usuario.
Centrado en arquitectura: La arquitectura involucra los elementos más significativos del sistema y está influenciada entre otros por plataformas software, sistemas operativos, manejadores de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados y requerimientos no funcionales. Los casos de uso guían el desarrollo de la arquitectura y la arquitectura se realimenta en los casos de uso, los dos juntos permiten conceptualizar, gestionar y desarrollar adecuadamente el software.
Para hacer más manejable un proyecto se recomienda dividirlo en ciclos. Para cada ciclo se establecen fases de referencia, cada una de las cuales debe ser considerada como un mini proyecto cuyo núcleo fundamental está constituido por una o más iteraciones de las actividades principales básicas de cualquier proceso de desarrollo.
Desarrollo basado en componentes: La creación de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces bien definidas, que posteriormente serán ensamblados para generar el sistema. Esta característica en un proceso de desarrollo permite que el sistema se vaya creando a medida que se obtienen o que se desarrollan y maduran sus componentes. Un componente es una parte del sistema física y proporciona la implementación de un conjunto de interfaces.
| Profundice, componente, interfaces. |
Fases dentro del ciclo de vida
| Profundice, componente, interfaces. |
El ciclo de vida de desarrollo de software con el uso del proceso unificado tiene las fases que se muestran en la figura 1.2, además de que en cada una de las fases se realizan ciertas actividades que son llamadas disciplinas tanto primarias y secundarias.
1.3.1. Inicio: Antes de iniciar un proyecto se debe dar respuesta a varias interrogantes como por ejemplo:
- ¿Cuál es el objetivo?
- ¿Es factible?
- ¿Se lo construye o se lo compra?
- ¿Cuánto a costar?
Generalmente esta fase no debe durar más de una semana y tiene como principal objetivo clarificar el panorama de lo que se desea realizar, esto no quiere decir que tenga que obtenerse resultados precisos de requisitos del sistema, si no más bien tener un alcance global. Entonces los objetivos principales son:
- Establecer oportunidad y alcance del proyecto
- Encontrar los casos de uso críticos del sistema, describir en detalle algunos de ellos
- Definir una arquitectura candidata para los escenarios principales
- Estimar el costo en recursos y tiempo de todo el proyecto
- Definir los criterios de éxito
- Identificar los riesgos
En esta fase se establecen los cimientos de la arquitectura, desarrollando un plan del proyecto y eliminando los mayores riegos, a partir de esta fase se inicia con la de construcción la cual es costosa y arriesgada, por que trabajar adecuadamente en esta fase es muy importante, los objetivos principales son:
- Analizar el dominio del problema
- Establecer una arquitectura de base sólida
- Desarrollar un plan del proyecto
- Eliminar los elementos de mayor riesgo para el desarrollo exitoso
Se desarrolla el producto de software, obteniendo una versión operacional del producto generalmente llamada versión beta. Los objetivos principales son:
- Minimizar los costos de desarrollo mediante la optimización de recursos y evitando rehacer trabajos.
- Conseguir una calidad adecuada tan rápido como sea práctico
- Obtener las versiones fundamentales alfa, beta y otras
En esta fase principalmente se tiene que pasar el software a los usuarios finales, para que lo que se deberá tener una versión estable del producto. Los objetivos principales son:
- Obtener autosuficiencia por parte de los usuarios
- Concordancia en los logros del producto de parte de las personas involucradas
- Lograr el consenso cuanto antes para liberar el producto al mercado
Productos a entregarse en cada una de las fases
| FASES | PRODUCTOS |
|---|---|
| Inicio | 1. Alcance del Sistema
2. Lista de Características 3. Modelo del Dominio o Modelo del Negocio (1ª. versión) 4. Modelo de Casos de Uso, Modelo de Análisis y Modelo de Diseño (1ª. versión) 5. Requerimientos Suplementarios (1ª. Versión) 6. Arquitectura Inicial (propuesta) 7. Lista Inicial de Riesgos (riesgos críticos más importantes) y Lista Priorizada de los Casos de Uso 8. Prototipo para Validación de Conceptos (prototipo de descarte) 9. Entorno de Desarrollo Configurado (proceso y herramientas) (configuración inicial) 10. Plan Inicial del Proyecto 11. Caso Inicial del Negocio (1ª. versión) (contexto del negocio y criterios de éxito) (costo, tiempos, calidad, utilidades) |
| Elaboración |
1. Contexto del Sistema (Modelo del Dominio o Modelo del Negocio preferiblemente completo) 2. Captura del 80% de los Requerimientos Funcionales:
4. Lista Actualizada de Riesgos (críticos y significativos) y Riesgos Críticos Mitigados 5. Plan del Proyecto para las fases de Construcción y Transición 6. Entorno de Desarrollo Adecuado (proceso y herramientas) 7. Caso del Negocio Completo (y “Contrato” o declaración del negocio) |
| Construcción |
1. Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e Implementación) 2. Arquitectura Íntegra (mantenida y mínimamente actualizada) 3. Riesgos Presentados Mitigados 4. Plan del Proyecto para la fase de Transición 5. Manual Inicial de Usuario (con suficiente detalle) 6. Prototipo Operacional – beta 7. Caso del Negocio Actualizado |
| Transición |
1. Prototipo Operacional 2. Documentos Legales 3. Caso del Negocio Completo 4. Línea de Base del Producto completa y corregida que incluye todos los modelos del sistema 5. Descripción de la Arquitectura completa y corregida 6. Manuales para Usuario Final, Operador y Administrador del Sistema, y Materiales para Entrenamiento |
[editar] Capitulo2:Problemática de la captura de requisitos
[editar] Datos Generales:
| Texto Base | [BJR2000] |
| Capítulo | 6. Captura de requisitos: de la visión a los requisitos |
| Páginas | 105-123 |
| Horas de estudio empleadas para el desarrollo del contenido | 10 horas |
http://www.utpl.edu.ec/ecc/wiki/skins/common/images/button_hr.png
[editar] Propositos:
En el presente cap´´itulo se da la visión general de la problemática que se tiene al realizar la captura de requisitos, de ahí que se hace notar la importancia de llegar a un acuerdo con los interesados para tener información confiable y aprobaciones necesarias para construir lo que requiere el cliente y no mal interpretar los requerimientos.
[editar] Conceptos Claves:
- Captura de Requisitos.-
Proceso de averiguar lo que se desea construir, es decir obetenr información de los interesados para llegar a tener la información correcta y no ambigua, estos requerimientos debe estar libre de interpretaciones diversas.
- Modelo de Dominio.-
Un modelo de dominio captura los tipos de objetos mas importantes en el contexto o delimitacion del sistema, estos son representados por diagramas de clase
- Modelo de Negocio.-
-
Los modelos de negocio describen como están los procesos en el lugar en donde se desea colocar el sistema, se representan mediante casos de uso de negocio y también pueden ser representados por diagramas de referencia cruzadas.
- Requisitos Funcionales.-
Los requisitos funcionales son aquellos que se implementan como funcionalidades del sistema y nacen de la captura de requisitos en donde cada uno de los usuarios indica que es lo que quiere que haga el sistema.
- Requisitos no Funcionales.-
Los requisitos no funcionales especifican propiedades del sistema que no pueden ser implementados como una funcionalidad, es decir aquí se especifica rendimiento, fiabilidad, mantenimiento, etc.
[editar] Esquema de Estudio:
A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que cada estudiante estima que necesita tutoría y realizar anotaciones personales.
| Tema a revisar | Descripción del Contenido a revisar | Actividades Recomendadas | Planificación Personal del estudio (fecha) | ¿Requiero Tutorial? | Anotaciones |
|---|---|---|---|---|---|
| 2. Problemática de la captura de requisitos | Introducción general de os problemas que se encuentran en la captura de requisitos | Revise el tema 6.1, 6.2 del libro base
Revise la bibliografía adicional que se encuentra al final del captulo. Realice un listado de elementos que hacen que la captura de requisitos sea complicada. Piense en un ejemplo de requisito que tienda a dar ambigüedad en su definición. | |||
| 1.2. Fases dentro del ciclo de vida | Este tema indica que se debe realizar para llegar a capturar lo requisitos como un aspecto inicial | Enumere los pasos que se realizan para capturar los requisitos.
Elabore un cuadro en el cual se coloquen los requisitos funcionales y no funcionales. Comprenda que es la enumeración de requisitos candidato, y que atributos se pueden utilizar como parte de cada requisito. | |||
| 2.2. Modelo de Domino | Descripción de los modelos de dominio y forma de representación | Comprenda que es un modelo de dominio
Revise que es un diagrama de clase en UML. Realice un ejemplo de modelo de dominio en base a un problema planteado por usted | |||
| 2.3. Modelo de Negocio | Los modelos de negocio son fundamentales para clarificar el panorama de lo que se desea desarrollar, asi com para identificar aspectos clave que podrian causar problemas. | Comprenda que es un modelos de negocio
Como se representan los modelos de negocio Relialice un modelo de negocio, como caso de uso y como diagrama de referencias cruzadas. |
Problemática de la captura de Requisitos
Uno de los elementos fundamentales en el desarrollo de aplicaciones es la captura de requisitos, ya que de ahí se parte para lograr alcanzar lo que se persigue con el producto, ahora por que es complicada la obtención de los requisitos, cuando nos ponemos en contacto con las personas conocedoras del negocio y que son las que nos proveen de la información o de requerimientos se tiene que tener mucho cuidado con las malas interpretaciones ya que el cliente nos puede esta solicitando algo y nosotros podemos entender otra cosa o viceversa. De ahí que la captura de requisitos se vuelve un proceso complicado por:
- Se crea código para otras personas
- Los usuarios son una fuente imperfecta para la recolección de requisitos.
- Los usuarios no conocen los requisitos y/o les cuesta especificarlos de manera precisa
- Los requisitos cambian
- Las condiciones en las que se especifican los requisitos varían
- Existen usuarios diferentes que aportan criterios diversos.
El gráfico de la siguiente página, muestra los distintos puntos de vista que se tienen en un proyecto.
Si analizamos el gráfico, podemos entender que cada uno de los involucrados en el proyecto tienen una visión diferente de lo que se pretende construir, es por esto la importancia de la unificación de criterios para llegar al desarrollo del sistema correcto. Imagínese usted que desea realizar la construcción de la casa de sus sueños y no existiera un análisis previo, puede ser que al final le entreguen una casa con cuatro paredes.
¿Como plantearía ustedes el requerimiento del ejemplo anterior de manera ambigua, y como lo haría para llegar a obtener lo que necesita?
Visión general de la captura de requisitos
Para poder evitar la diversidad de criterios en los requisitos se recomienda realizar las siguientes tareas:
| Tarea | Artefactos (Productos) |
|---|---|
| Enumerar requisitos candidatos | Lista de características. |
| Entender el contexto del sistema | Modelo de negocio o de dominio. |
| Capturar requisitos funcionales | Modelo de casos de uso. |
| Capturar requisitos no funcionales | Requisitos suplementarios o casos individuales. |
Modelos de Dominio
Un modelo de dominio captura los tipos de objetos mas importantes en el contexto del sistema, estos objetos representan las cosas que existen o los eventos que suceden en el entorno en el que trabaja el sistema y pueden obtenerse a partir de la especificación de requisitos o mediante entrevistas con los expertos del domino, a continuación se presenta un ejemplo de modelo de dominio. El siguiente es un modelo de dominio.
Modelos de Negocio
Los modelos de negocio pretenden dar la perspectiva de cómo se mueven los procesos en la institución o lugar en donde se pretende establecer una solución de software, es decir conocer el flujo de negocio, a parte de lo que el libro base indica sobre la representación de modelos, se lo puede hacer de manera que sea mas familiar para el usuario como sin los diagramas de proceso de negocio. Los diagramas de proceso del negocio, son representaciones de los procesos que se dan en la organización y que son de interés para el sistema. Para su representación se utiliza un tipo de diagramas de Microsoft Visio que se conoce como diagramas de flujo de funciones cruzadas. Básicamente en éste tipo de diagrama se trata de representar relación existente entre un proceso y las unidades funcionales (como pueden ser los departamentos o personas) responsables del proceso en cuestión. Es un diagrama de flujo extendido, en donde además de las operaciones, se detalla las personas que intervienen en un proceso. Es necesario entonces, que el analista se convierta en un “experto” de los procesos que se desarrollan, conociendo cada uno de los participantes, su flujo, sus operaciones, resultados esperados, el analista debería estar en la capacidad de responder a todo tipo de preguntas sobre el proceso, especialmente aquellas que empiezan por “que pasaría si…” una vez cubiertas todas estas preguntas podemos entonces empezar a construir un diagrama de proceso del negocio. Para la elaboración de este tipo de diagramas es necesario realizar entrevistas con cada uno de los participantes de un proceso, ya que ellos nos proporcionan una visión global del mismo, nunca debemos conformarnos con la información proporcionada por un tipo de usuario, ya que esta es subjetiva y limitada. Recuerde siempre trabajar con todos los participantes del proceso. Existen formas horizontales y verticales para diagramas de flujo de funciones cruzadas, pero las podemos utilizar de manera indistinta, lo único que debe tener presente es que las bandas representan a las unidades funcionales (departamentos o personas) y las formas que representan los pasos del proceso se colocan en bandas que corresponden a las unidades funcionales responsables de dichos pasos. Se elaboran dos versiones de los diagramas, la primera versión es una representación del estado actual del proceso, es decir tal cual se encuentra implementado el proceso; la segunda versión es una propuesta que incluye mejoras en el proceso, las mejoras pueden incluir o no el uso del sistema que se construirá. Una vez que se posee las dos versiones de cada uno de los diagramas, se procede a presentarlos a los interesados y especialistas en el proceso; organizando una reunión en donde se hace una exposición de los procesos actuales y propuestos; pudiendo entonces, obtener del usuario (especialista del proceso) una retroalimentación sobre lo correcto o no del diagrama del proceso actual y sus sugerencias sobre el diagrama del proceso propuesto. Una vez aprobados los diagramas, especialmente el diagrama con las mejoras propuestas, podemos empezar a obtener los diagramas de casos de uso de manera sencilla, las bandas funcionales representan a los actores y uno o más operaciones relacionadas representan un caso de uso.
[editar] Capitulo3: Captura de requisitos como casos de uso
[editar] Datos Generales:
| Texto Base | [BJR2000] |
| Capítulo | 7. Captura de requisitos como casos de uso |
| Páginas | 125-163 |
| Horas de estudio empleadas para el desarrollo del contenido | 12 horas |
[editar] Propositos:
En este capítulo se revisa la notación utilizada en el proceso de desarrollo, así como también los flujos de trabajo, artefactos y trabajadores involucrados en la captura de requisitos como casos de uso, la captura de requisitos es una de los flujos en donde se inicia a obtener una descripción mas detallada de los requisitos.
[editar] Conceptos Claves:
- Trabajador.-
- Define el comportamiento y habilidades de un individuo
- Artefactos.-
Es un término general para cualquier tipo de descripción o información creada, producida, cambiada o utilizada por los trabajadores durante su trabajo con el sistema.
- Actividades.-
- Es una unidad de trabajo que se asigna a un trabajador
- Flujos de Trabajo.-
Es una secuencia de actividades que produce un resultado valioso.
- Analista de sistemas.-
El analista de sistemas conduce y coordina la captura de requisitos y el modelado de casos de uso, contorneando las funcionalidades del sistema y delimitando al mismo. Ejemplo: identifica qué actores existen y qué casos de uso requieren cuando interactúan con el sistema.
Adicionalmente construye el glosario para conseguir un acuerdo en los términos comunes y conceptos.
- Especificador de casos de uso.-
- Cuya responsabilidad es las descripciones detalladas de uno o más casos de uso.
- Diseñador de interfaz de usuario.-
- Dan forma visual a las interfaces de usuario, mediante prototipos.
- Arquitecto.-
Es responsable de la arquitectura del software, que incluye las decisiones técnicas claves que guían el diseño total e implementación para el proyecto.
- Modelos de casos de uso.-
Es un modelo que representa las funciones deseadas del sistema y su entorno, sirve como un contrato entre el usuario y los desarrolladores. El modelo de casos de uso es empleado como entrada esencial para actividades como análisis, diseño y pruebas.
- Actor.-
Es un conjunto coherente de roles que los usuarios del sistema pueden desempeñar cuando interactúan con éste. La instancia de un actor puede ser desempeñada por un individuo o por un sistema externo.
- Glosario.-
- Definición de términos importantes usados durante todo el proyecto.
- Caso de uso.-
Es una secuencia de acciones ejecutadas por el sistema que produce un resultado observable de valor para un tipo particular de actor
- Prototipo de interfaz de usuario.-
- Es un ejemplo de una interfaz de usuario que nos ayuda a comprender de una mejor manera los casos de uso.
- Descripción de la arquitectura.-
Contiene una vista de la arquitectura del modelo de casos de uso, que representa los casos de uso significativos para la arquitectura.
[editar] Esquema de Estudio:
A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que cada estudiante estima que necesita tutoría y realizar anotaciones personales.
| Tema a revisar | Descripción del Contenido a revisar | Actividades Recomendadas | Planificación Personal del estudio (fecha) | ¿Requiero Tutorial? | Anotaciones |
|---|---|---|---|---|---|
| 3.1. | Objetivos de la Captura de requisitos | Comprenda los objetivos de la captura de requisitos como casos de uso, así como la notación utilizada en el proceso de desarrollo. | |||
| 3.2. | Trabajadores y Artefactos implicados | Realice un cuadro en el cual coloque todos los trabajadores y artefactos de la captura de requisitos, luego escriba una descripción de cada uno de ellos. | |||
| 3.3. | Flujos de Trabajo | Comprenda que es un flujo de trabajo.
Analice los flujos de trabajo de la captura de requisitos:
Realice un cuadro sinóptico, en el cual por cada flujo de trabajo, se especifique las actividades y por cada una de ellas los trabajadores y artefactos implicados. |
Captura de requisitos como casos de uso.
Un proceso de desarrollo de software define quién está haciendo qué, cuándo, y cómo. Un caso de uso especifica una secuencia de acciones, incluyendo variante que el sistema pueda realizar y que ofrece un resultado observable o tangible parea un determinado usuario. En el libro base [BJR2000] se utiliza una notación gráfica para cada una de las partes del proceso de desarrollo de software, que se resumen a continuación:
La notación que se presenta debe ser dominada por, ya que en todos los capítulos siguientes se utilizaran
Objetivos de la captura de requisitos
La captura de requisitos, a través de casos de uso, tiene por objetivos:
- Establecer y mantener un acuerdo con los clientes y otros interesados en lo que debe hacer el sistema.
- Proveer a los desarrolladores del sistema una mejor comprensión de los requerimientos.
- Definir los límites del sistema.
- Proporciona una base para planear el contenido técnico de las iteraciones.
- Proporciona una base para estimar costes y tiempos de desarrollo del sistema.
- Definir interfaces de usuario para el sistema, centrándose en las necesidades y metas de los usuarios.
Para alcanzar estos objetivos es importante, antes que nada, entender la definición y alcance del problema que estamos tratando de resolver con el sistema.
Trabajadores y artefactos implicados
Cada uno de los trabajadores y artefactos implicados durante la captura de los requisitos mediante casos de uso se resumen en el siguiente cuadro.
| Trabajadores | Descripción |
|---|---|
| Analista de sistemas | El analista de sistemas conduce y coordina la captura de requisitos y el modelado de casos de uso, contorneando las funcionalidades del sistema y delimitando al mismo. Ejemplo: identifica qué actores existen y qué casos de uso requieren cuando interactúan con el sistema.
Adicionalmente construye el glosario para conseguir un acuerdo en los términos comunes y conceptos. |
| Especificador de casos de uso | Cuya responsabilidad es las descripciones detalladas de uno o más casos de uso. |
| Diseñador de interfaz de usuario | Dan forma visual a las interfaces de usuario, mediante prototipos. |
| Arquitecto | Es responsable de la arquitectura del software, que incluye las decisiones técnicas claves que guían el diseño total e implementación para el proyecto. |
Muchos de los trabajadores mostrados pueden representados por una misma persona o grupo de persona, recuerde que el proceso de desarrollo unificado puede adaptarse a las necesidades de las organizaciones y si una organización no cuenta con el personal necesario para cubrir cada uno de los roles, pues una persona puede asumir más de un rol.
La siguiente tabla resume los artefactos que se producen durante ésta fase de captura de requisitos.
| Artefactos | Descripción |
|---|---|
| Modelos de casos de uso | Es un modelo que representa las funciones deseadas del sistema y su entorno, sirve como un contrato entre el usuario y los desarrolladores. El modelo de casos de uso es empleado como entrada esencial para actividades como análisis, diseño y pruebas. |
| Actor | Es un conjunto coherente de roles que los usuarios del sistema pueden desempeñar cuando interactúan con éste. La instancia de un actor puede ser desempeñada por un individuo o por un sistema externo. |
| Glosario | Definición de términos importantes usados durante todo el proyecto. |
| Caso de uso | Es una secuencia de acciones ejecutadas por el sistema que produce un resultado observable de valor para un tipo particular de actor. |
| Prototipo de interfaz de usuario | Es un ejemplo de una interfaz de usuario que nos ayuda a comprender de una mejor manera los casos de uso. |
| Descripción de la arquitectura | Contiene una vista de la arquitectura del modelo de casos de uso, que representa los casos de uso significativos para la arquitectura |
Los flujos de trabajo son una secuencia de actividades que están ordenadas, así que una actividad produce una salida que sirve de entrada a la siguiente actividad. Pero recuerde que el flujo de trabajo representa el flujo lógico, en el mundo real no es necesario trabajar mediante actividades en secuencia. De hecho, podemos trabajar por múltiples vías que producen un resultado final equivalente.
Encontrar actores y casos de uso
La identificación de casos de uso es importante para:
- * Delimitar el sistema de su entorno.
- * Esbozar quién y qué (actores) interactúan con el sistema, y qué funcionalidades (casos de uso) se espera del sistema.
- * Capturar y definir un glosario de términos comunes esenciales para la creación de descripciones detalladas de las funcionalidades del sistema (es decir, de los casos de uso).
Esta actividad consta de cuatro pasos, que no tienen por qué ser ejecutados en ningún orden en particular y a menudo se hacen simultáneamente. Estos pasos son:
- * Encontrar los actores
- * Encontrar los casos de uso.
- * Describir brevemente cada caso de uso.
- * Describir el modelo de casos de uso completo, paso que incluye la preparación de un glosario de términos.
Encontrar los actores
Cuando se posee un modelo de negocio del cual partir, se puede asignar un actor a cada trabajador del negocio y un actor a cada cliente del negocio.
Se deben identificar los actores que representan sistemas externos, actores para el mantenimiento y operación del sistema.
Dos criterios útiles a la hora de elegir los actores son:
- * Identificar al menos un usuario que puede representar al actor candidato.
- * Dos actores son diferentes cuando tienen distintos roles frente al sistema.
El analista de sistemas da nombre a los actores y describe brevemente los papeles de cada actor y para qué utiliza el sistema el actor.
Identificar aquellos casos de uso que son necesarios desarrollar en las primeras iteraciones y cuáles se pueden dejar para más tarde. Esto no implica, que los casos de uso de menor prioridad no se implementaran, únicamente señala un orden de implementación.
Detallar un caso de uso
El propósito de de detallar un caso de uso es describir su flujo de sucesos en detalle, incluyendo cómo comienza, termina e interactúan con los actores.
Implica un trabajo directo con los usuarios del sistema.
En el libro base se trabaja con los diseños lógicos y diseños físicos para la construcción de un prototipo de la interfaz de usuario, pero en base a la experiencia podemos trabajar directamente con el diseño físico del prototipo, es indudable que el diseño físico tiene el implícito el diseño lógico, caso contrario no sería útil para el usuario y lo desecharía inmediatamente. Tomando el ejemplo del libro base, observamos que Factura tiene tres atributos: fecha de vencimiento, cantidad a pagar, cuenta destino; estos elementos del diseño lógico; si construimos una interfaz (diseño físico) que no contenga dichos atributos, dicha interfaz será rechazada por el usuario. Es por eso que el diseño físico debe incluir al diseño lógico. Recuerde que los prototipos de interfaz de usuario deben ser discutidos con los usuarios y son ellos quienes los aprueban, desechan o sugieren mejoras. Es aconsejable que se construya los prototipos en papel, utilizando herramientas como Microsoft Visio con sus diagramas de Interfaz de usuario. Esto nos permite construir prototipos de un manera rápida y con gran similitud con los elementos que el usuario está acostumbrado a ver (ventanas, botones, cuadros de texto, etc.)
Estructurar el modelo de casos de uso
Existen tres conceptos que debemos tener presente cuando elaboremos los modelos de casos de uso: generalización, extensión e inclusión.
Ejemplo de un proyecto de desarrollo
Es necesario poner en práctica todos y cada uno de los conceptos que se han y se irán exponiendo en esta guía, para lo cual se ha seleccionado un proyecto denominado “Videoclub automático” que a continuación se describe. El sistema a desarrollar es un sistema software que hay que incorporar dentro de un dispensador automático de películas que trabaje 24 horas. Este videoclub tiene las facilidades usuales como sacar películas, devolverlas, etc., y también otras como que se puede reservar una película notificando al usuario que ya esta disponible mediante un mensaje SMS o enviar recordatorio a los clientes que no han devuelto películas vía SMS. El pago ha de hacerse con tarjeta de crédito. El videoclub reporta a la central de la empresa vía Internet. Cuando un cliente alquila un vídeo el sistema debe comunicarse con el banco para registrar la validación y operación de la tarjeta de crédito, una vez hecha las transacciones con el banco el sistema imprime un recibo que es entregado al usuario. Otras actividades son las de dar de alta y de baja a un vídeo cuando se adquieren nuevos videos es necesario ingresarlos al sistema y ponerlos disponibles en el dispensador, el caso contrario cuando una video no tiene acogida o lleva algún tiempo disponible (generalmente 3 meses) debe darse de baja para lo cual se debe cambiar el estado del video a no disponible y retirar del dispensador el video. De acuerdo a lo que se describió en las páginas anteriores para la captura de requisitos son necesarias realizar las siguientes actividades, aplicadas al ejemplo del proyecto.
A. Encontrar actores y casos de uso
Identificar actores
| Actores del sistema de Videoclub | |
|---|---|
| Usuario | Un usuario es la persona que utilizará el sistema para buscar películas, solicitarlas, pagarlas y obtenerlas del dispensador. |
| Operario | Un operario es la persona que realizará las tareas de mantenimiento del dispensador de películas, es decir, sustituirá viejas películas por nuevas. Para ello utilizará el sistema para dar de alta y baja las películas |
| Banco | El banco representa a la entidad externa con la que el sistema debe contactar para admitir y realizar los pagos con tarjeta de los clientes. |
| Dispensador | El dispensador representa al dispositivo mecánico donde están almacenadas las películas que el sistema debe controlar para dar la película alquilada al cliente o que éste la pueda devolver. |
| Operador telefónico | El operador telefónico representa la entidad externa con la que el sistema debe contactar para enviar mensajes SMS a los clientes. |
| Sistema contable | El sistema contable representa el sistema informático externo de la empresa con el que el sistema videoclub debe contactar para notificar los pagos realizados en cada momento. |
b. Identificar casos de uso
| Algunos casos de uso: | |
|---|---|
| Alquilar película | El usuario utiliza este caso de uso para mirar qué películas hay, seleccionar una, pagarla y retirarla del dispensador. Debe obtener un recibo |
| Devolver película | El usuario inicia este caso de cuando devuelve la película. Recibe una notificación confirmándole la devolución. Si ha tenido retraso deberá abonar una penalización. |
| Dar de Alta | El operario inicia este caso cuando introduce una nueva película en el dispensador. |
| Dar de baja | El operario inicia este caso cuando retira una película del dispensador. |
| Mandar recordatorio | El operador telefónico representa la entidad externa con la que el sistema debe contactar para enviar mensajes SMS a los clientes. |
c. Describir modelo de casos de uso
B. Detallar los casos de uso
a. Diseñar diagramas de estado por cada caso de uso
Se presenta el caso de uso Alquilar película con su camino básico y caminos alternos. Recuerde que es necesario realizar diagramas de estado por cada caso de uso: alquilar película, devolver película, alta película, baja película y mandar recordatorio.
b. Descripción textual de casos de uso
Precondición:
El usuario ha pulsado en el videoclub “Alquilar Película”
Flujo de Eventos
Camino básico:
-
1. El usuario inicia el caso de uso buscando en la pantalla la película que más le gusta. El sistema le muestra la información de cada película, por orden alfabético, así como si está prestada, reservada o disponible.
2. El usuario selecciona una película en la pantalla. El sistema le pide los datos de su tarjeta de crédito y gestiona el pago con la entidad bancaria adecuada.
3. El banco emite una verificación y el pago es aceptado. El sistema ordena al dispensador que proporcione la película elegida y que le genere un recibo. Asimismo notifica al sistema contable la transacción bancaria realizada. Finalmente actualiza los datos históricos del usuario y marca la película como alquilada y no disponible si no hay más copias.
Caminos alternativos
1. En 2 puede que el pago no sea aceptado por el banco o que el usuario haya alcanzado el tope de sus alquileres por día. Hay que notificárselo al usuario y terminar.
2. En 1 puede que la película esté alquilada y el usuario quiera reservarla. En este caso hay que emitir una notificación de
reserva.
Poscondición
El caso acaba cuando el usuario tiene la película y un recibo, o sin película y una notificación de pago rechazado, o sin película pero con la reserva hecha, o sin película por que no le gustara ninguna.
Atributos del Caso de uso
Película: prestada, reservada o disponible.
Cliente (Usuario): datos tarjeta de crédito, número de películas alquiladas.
Información a mostrar:
Sobre películas, sobre petición de datos, sobre resultado del alquiler realizado.
C. Definir prototipo de interfaz
Como se puede observar en el ejemplo la actividad de detallar un caso de uso, con sus correspondientes sub-actividades, debe realizarse por cada caso de uso. Como una tarea adicional optativa, le propongo que complete la actividad de detallar los casos de uso faltantes, tomando como ejemplo el caso de uso realizado.
[editar] Capitulo 4 : Análisis
[editar] Datos Generales:
| Texto Base | [BJR2000] |
| Capítulo | 8 Análisis |
| Páginas | 166-204 |
| Horas de estudio empleadas para el desarrollo del contenido | 12 horas |
[editar] Propositos:
En este capítulo se continua el estudio de los flujos del proceso unificado, en este caso el análisis, el objetivo principal es entender las funciones de cada uno de los actores involucrados en el proceso, así como los flujos que este capítulo se tratan
[editar] Conceptos Claves:
- Arquitecto.-
Es responsable de la integridad del modelo de análisis, garantizando que éste sea correcto, consistente y legible como un todo.
- Ingeniero de Casos de Uso.-
Es responsable de la integridad de una o más realizaciones de caso de uso, garantizando que cumplen los requisitos que recaen sobre ellos.
- Ingeniero de Componentes.-
Define y mantiene las responsabilidades, atributos, relaciones y requisitos especiales de una o varias clases de análisis, asegurando que cada clase del análisis cumple los requisitos que se esperan de ella de acuerdo a las realizaciones de cada caso de uso en las que participa. También mantiene la integridad de uno o varios paquetes del análisis, garantizando que sus contenidos (clases y relaciones) son correctos.
- Modelo de Analisis.-
Es un modelo de objetos conceptual. Se representa mediante un sistema de análisis que denota el paquete de más alto nivel del modelado.
- Clase de Analisis.-
Representa una abstracción de una o varias clases y/o subsistemas del diseño del sistema. Encajan en uno de los siguientes estereotipos básicos: de interfaz (ventanas, formularios, paneles, sensores, etc.), de control (coordinación, secuencia, transacciones y control de otros objetos, lógica de negocios) o entidad (información de vida larga, persistente). Cada estereotipo tiene su propio símbolo dentro del UML
- Realizacion de caso de uso-analisis.-
Señala como se lleva a cabo y ejecuta un caso de uso determinado en términos de las clases de análisis y de los objetos del análisis en interacción.
- Paquete del análisis.-
Medio para organizar los artefactos del modelo de análisis en piezas manejables. Puede constar de clases de análisis, de realizaciones de casos de uso, y de otros paquetes del análisis. Dentro de un paquete sus contenidos deben estar fuertemente relacionados y débilmente acoplados.
- Descripción de la arquitectura.-
Vista de la arquitectura de un sistema, abarcando las clases, paquetes y realizaciones de casos de uso del análisis; vista que fundamentalmente aborda el refinamiento y estructuración de los requisitos del sistema. La estructura de esta vista se preserva en la medida de lo posible cuando se diseña e implementa la arquitectura del sistema.
[editar] Esquema de Estudio:
A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que cada estudiante estima que necesita tutoría y realizar anotaciones personales.
| Tema a revisar | Descripción del Contenido a revisar | Actividades Recomendadas | Planificación Personal del estudio (fecha) | ¿Requiero Tutorial? | Anotaciones |
|---|---|---|---|---|---|
| 4.1 | Objetivos del Analisis | Entender los objetivos de lo que se pretende realizar en cualquier actividad es fundamental, apóyese en la documentación adicional al final de este capítulo para comprender los objetivos del análisis | |||
| 4.2. | Trabajadores y Artefactos implicados | Luego de la lectura del capítulo, proceda a realizar un cuadro en el cual tenga cada uno de los trabajadores y los artefactos con una descripción de cada uno de estos | |||
| 4.3. | Flujos de Trabajo | Comprenda los flujos de trabajo del análisis
Los flujos de trabajo contienen actividades y estas son realizadas por uno o varios trabajadores. |
ANALISIS
En el análisis trabajamos con conceptos, dando una representación mas precisa de los requisitos utilizando lenguaje de los desarrolladores. Durante esta fase se estudian los requisitos refinándolos y estructurándolos, el objetivo es conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y que ayude a estructurar el sistema.
Objetivos
El análisis tiene por objetivos:
- Conseguir una comprensión más precisa de los requisitos, expresado en términos de los desarrolladores.
- Producir una vista interna del sistema.
- Trasladar requisitos en especificaciones de implementación.
- Transformar los casos de uso en clases, estructurados en paquetes.
Trabajadores y artefactos implicados
Los trabajadores, que intervienen en el flujo de análisis, y sus funciones se resumen en el siguiente cuadro:
| Trabajadores | Descripción |
|---|---|
| Arquitecto | Es responsable de la integridad del modelo de análisis, garantizando que éste sea correcto, consistente y legible como un todo. |
| Ingerniero de casos de Uso | Es responsable de la integridad de una o más realizaciones de caso de uso, garantizando que cumplen los requisitos que recaen sobre ellos. |
| Ingeniero de Componentes | Define y mantiene las responsabilidades, atributos, relaciones y requisitos especiales de una o varias clases de análisis, asegurando que cada clase del análisis cumple los requisitos que se esperan de ella de acuerdo a las realizaciones de cada caso de uso en las que participa. También mantiene la integridad de uno o varios paquetes del análisis, garantizando que sus contenidos (clases y relaciones) son correctos. |
| Artefactos | Descripción |
|---|---|
| Modelo se Análisis | Es un modelo de objetos conceptual. Se representa mediante un sistema de análisis que denota el paquete de más alto nivel del modelado. |
| Clases de Análisis | Representa una abstracción de una o varias clases y/o subsistemas del diseño del sistema. Encajan en uno de los siguientes estereotipos básicos: de interfaz (ventanas, formularios, paneles, sensores, etc.), de control (coordinación, secuencia, transacciones y control de otros objetos, lógica de negocios) o entidad (información de vida larga, persistente). Cada estereotipo tiene su propio símbolo dentro del UML |
| Realización de caso de uso-análisis | Señala como se lleva a cabo y ejecuta un caso de uso determinado en términos de las clases de análisis y de los objetos del análisis en interacción. |
| Paquete del análisis | Medio para organizar los artefactos del modelo de análisis en piezas manejables. Puede constar de clases de análisis, de realizaciones de casos de uso, y de otros paquetes del análisis. Dentro de un paquete sus contenidos deben estar fuertemente relacionados y débilmente acoplados. |
| Descripción de la arquitectura | Vista de la arquitectura de un sistema, abarcando las clases, paquetes y realizaciones de casos de uso del análisis; vista que fundamentalmente aborda el refinamiento y estructuración de los requisitos del sistema. La estructura de esta vista se preserva en la medida de lo posible cuando se diseña e implementa la arquitectura del sistema. |
Flujo de trabajo
Análisis de la arquitectura
Tiene la finalidad de 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.
- Identificación de paquetes de análisis
- Identificación de clases de entidades obvias
- Identificación de requisitos especiales comunes
Analizar un caso de uso
Se analiza un caso de uso para:
- Identificar las clases del análisis cuyos objetos son necesarios para llevar a cabo un caso de uso.
- Distribuir el comportamiento del caso de uso entre los objetos del análisis que interactúan.
- Capturara requisitos especiales.
En el texto base se encuentran descritos los objetivos que se persigue cuando se analiza un paquete. Tenga presente que los elementos que conforman un paquete deben ser fuerte relacionados, pero débilmente acoplados.
Ejemplo de un proyecto de desarrollo
Continuando con el desarrollo del proyecto “Sistema Videoclub” se ejemplificará las actividades correspondientes al flujo de análisis, centrando su atención en las actividades de: analizar los casos de uso (identificar clases y describir interacciones) y analizar cada clase de análisis (identificar responsabilidades, atributos y relaciones)
Analizar los casos de uso
Identificar clases
Clases entidad: Información que se manipula en la realización del caso de uso. Ejemplo: Clases entidad del caso de uso alquilar película: ficha película y ficha cliente. Clases interfaz: Identificar una clase interfaz por cada: 1) Actor humano. Si dicho actor tiene ya una clase interfaz habría que estudiar la posibilidad de reutilizarla para minimizar el número de ventanas con las que interactúa el actor. 2) Clase entidad encontrada que represente información con la que el usuario humano va interactuar. 3) Sistema externo, y hacer que esta clase interfaz sea el canal de comunicación con él. Ejemplo: I. Usuario; I. Banco; I. Películas; I. Sistema contable; I. Dispensador. Nota los nombres de las interfaces tienen como prefijo la letra I señalando que se trata de una interfaz. Clases control: Identificar una clase de control responsable de la coordinación del caso de uso. Una clase de control puede actuar para varios casos de uso y se puede encapsular en una clase interfaz, especialmente si el actor maneja gran parte del control.
Describir interacciones
La descripción de las interacciones se la realiza a través del diagrama de colaboración
Analizar cada clase de análisis
Identificar responsabilidades
Responsabilidades de la clase Gestor
La responsabilidad de esta clase en el Caso de Uso “Alquilar Película” es Ordenar Película, que implica: Solicitar Datos de Pago mediante la tarjeta de crédito.
Ordenar al banco el pago y su verificación.
Ordenar al dispensador la entrega al usuario de la película y del recibo.
Actualizar la información sobre el cliente.
Actualizar la información sobre las películas.
Actualizar el balance de la empresa.
Otras responsabilidades provenientes de otros casos de uso:
Gestionar el envío de recordatorios
Gestionar la devolución de la película
Gestionar la carga y descarga de películas.
Identificar atributos
El nombre de un atributo debería ser un sustantivo. Los tipos de los atributos deben ser conceptuales y, a ser posible, no restringidos por el entorno de programación. Hay que reutilizar los tipos ya existentes.
Una instancia de un atributo no puede ser compartida por varios objetos de análisis.
Si el número de atributos hace que una clase sea difícil de entender, será mejor crear clases que los separen.
Los atributos de las clases entidad deber obvios.
Los atributos de clases interfaz que interactúan con actores humanos a menudo son componentes gráficos que el actor debe manipular.
Los atributos de clase interfaz que interactúan con actores que son sistemas externos, a menudo representan propiedades del protocolo o interfaz de comunicación. Las clases de control no suelen tener atributos, salvo para representar valores que deben mantenerse durante la ejecución de un caso de uso.
Ejemplo: Atributos de la clase Ficha Cliente:
NúmeroPelículasAlquiladas
NombreApellidosCliente
DatosTarjetaCrédito
Identificar relaciones
Identificar asociaciones, agregaciones y generalizaciones.
De igual manera que se planteó en el capítulo anterior, le propongo que complete el trabajo analizando los casos de uso faltantes y tomando como base el ejemplo desarrollado.
[editar] Capitulo 5 : Diseño
[editar] Datos Generales:
| Texto Base | [BJR2000] |
| Capítulo | 9 Diseño |
| Páginas | 205-253 |
| Horas de estudio empleadas para el desarrollo del contenido | 12 horas |
[editar] Propositos:
El diseño es la fase previa a la implementación, por lo tanto en este capítulo se pretende llegar a comprender los flujos de trabajo asociados a esta, asi como los actores, flujos.
[editar] Conceptos Claves:
- Arquitecto.-
En este flujo es responsable de la integridad de los modelos de diseño y de despliegue, garantizando que los modelos son correctos, consistentes y legibles en su totalidad.
- Ingeniero de Casos de Uso.-
Responsable de la integridad de una o más realizaciones de casos de uso-diseño, garantizando que se cumplan los requisitos que se esperan de ellos.
- Ingeniero de Componentes.-
Define y mantiene las operaciones, métodos atributos, relaciones y requisitos de implementación de una o más clases de diseño. Puede también mantener la integridad de uno o más subsistemas, garantizando que sus contenidos (clases y relaciones) son correctos.
- Modelo de Analisis.-
Modelo de objetos UML que contiene el diseño de la aplicación, describiendo la realización física de los casos de uso: como afectan los requisitos funcionales, no funcionales y otras restricciones técnicas.
- Realizacion de caso de uso-analisis.-
Es una colaboración en el modelo de diseño que describe como se realiza un caso de uso en término de clases y objetos de diseño
- Subsistema de Diseño.-
Permite organizar lo artefactos del sistema en piezas más manejables. Pudiendo constar de: clases de diseño, realización de caso de uso, interfaces.
- Interfaz.-
Se utilizan para especificar las operaciones que proporcionan las clases y subsistema de diseño. Separando la especificación de la funcionalidad en término de operaciones de sus implementaciones en términos de métodos.
- Descripción de la Arquitectura (Diseño).-
Muestra los artefactos relevantes para la arquitectura de la aplicación: descomposición en subsistemas (sus interfaces y dependencias entre ellos), clases de diseño fundamentales, realización de casos de uso-diseño que describan alguna funcionalidad crítica.
- Modelo de Despliegue.-
- Representa una correspondencia entre la arquitectura del hardware y la arquitectura del software.
- Descripción de la Arquitectura (Despliegue).-
- Muestra los artefactos relevantes del modelo de despliegue para su arquitectura.
[editar] Esquema de Estudio:
A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que cada estudiante estima que necesita tutoría y realizar anotaciones personales.
| Tema a revisar | Descripción del Contenido a revisar | Actividades Recomendadas | Planificación Personal del estudio (fecha) | ¿Requiero Tutorial? | Anotaciones |
|---|---|---|---|---|---|
| 5.1. | Objetivos del Diseño | En este flujo también es fundamental comprender los objetiivos | |||
| 5.2 | Trabajadores y Artefactos implicados en el Diseño | Luego de la lectura del capítulo, proceda a realizar un cuadro en el cual tenga cada uno de los trabajadores y los artefactos con una descripción de cada uno de estos | |||
| 5.3 | Flujos de Trabajo | Comprenda los flujos de trabajo del diseño
Los flujos de trabajo contienen actividades y estas son realizadas por uno o varios trabajadores. |
DISEÑO ORIENTADO A OBJETOS
Una vez elaborado el modelo conceptual (modelo de análisis) es necesario construir un modelo físico (modelo de diseño) en donde se modela los requisitos funcionales, no funcionales y otras restricciones. Su entrada esencial es el modelo de análisis (una comprensión detallada de los requisitos). Recuerde revisar la tabla 9.1 del libro guía para una comparativa entre el modelo de análisis y el modelo de diseño. El diseño es el centro de la atención final de la fase de elaboración e iteraciones iniciales de la fase de construcción. El modelo de diseño está muy cercano al de implementación permitiendo guardar y mantener el modelo de diseño a través del ciclo de vida completo.
Objetivos
El diseño tiene por objetivos:
- - Profundizar en los requisitos no funcionales y en las restricciones técnicas.
- - Crear una entrada apropiada para la implementación.
- - Descomponer los trabajos de implementación en partes más manejables, que permitan concurrencia y puedan ser desarrolladas por diferentes equipos de desarrollo.
- - Capturar las interfaces en los subsistemas.
Se resumen mediante tablas los trabajadores y artefactos presentes en el flujo de diseño:
| Trabajadores | Descripción |
|---|---|
| Arquitecto | En este flujo es responsable de la integridad de los modelos de diseño y de despliegue, garantizando que los modelos son correctos, consistentes y legibles en su totalidad. |
| Ingeniero de casos de uso | Responsable de la integridad de una o más realizaciones de casos de uso-diseño, garantizando que se cumplan los requisitos que se esperan de ellos. |
| Ingeniero de componentes | Define y mantiene las operaciones, métodos atributos, relaciones y requisitos de implementación de una o más clases de diseño. Puede también mantener la integridad de uno o más subsistemas, garantizando que sus contenidos (clases y relaciones) son correctos. |
| Artefactos | Descripción |
|---|---|
| Modelo de análisis | Modelo de objetos UML que contiene el diseño de la aplicación, describiendo la realización física de los casos de uso: como afectan los requisitos funcionales, no funcionales y otras restricciones técnicas. |
| Clase del diseño | Características:
Sintaxis de un lenguaje de programación Visibilidad de atributos y operaciones. Traducción de las relaciones Métodos por seudo código Estereotipo que se correspondan con construcciones del lenguaje de programación Puede realizar interfaces si tiene sentido en el lenguaje de programación. |
| Realización de caso de uso-diseño | Es una colaboración en el modelo de diseño que describe como se realiza un caso de uso en término de clases y objetos de diseño. Contiene:
Diagrama de clases de realización Diagramas de interacción (clases, subsistemas, interfaces) Flujo de sucesos diseño. Requisitos de implementación. |
| Subsistema del Diseño | Permite organizar lo artefactos del sistema en piezas más manejables. Pudiendo constar de: clases de diseño, realización de caso de uso, interfaces.
Un subsistema debe cumplir con las siguientes características: debe ser cohesivo, y deben tener bajo acoplamiento. |
| Interfaz | Se utilizan para especificar las operaciones que proporcionan las clases y subsistema de diseño. Separando la especificación de la funcionalidad en término de operaciones de sus implementaciones en términos de métodos. |
| Descripción de la arquitectura (vista del modelo de diseño) | Muestra los artefactos relevantes para la arquitectura de la aplicación: descomposición en subsistemas (sus interfaces y dependencias entre ellos), clases de diseño fundamentales, realización de casos de uso-diseño que describan alguna funcionalidad crítica. |
| Modelo de Despliegue | Representa una correspondencia entre la arquitectura del hardware y la arquitectura del software.
Describe la distribución física del sistema en nodos de cómputo (recurso de cómputo: un procesador o algo similar). Cada nodo puede tener relaciones que representan medios de comunicación entre ellos. La funcionalidad de un nodo se determina por los componentes que se le asignan. |
| Descripción de la arquitectura (vista del modelo de despliegue) | Muestra los artefactos relevantes del modelo de despliegue para su arquitectura. |
Flujo de trabajo
Diseño de la arquitectura
Identificar nodos y configuración, subsistemas, clases.
Siempre se debe considerar distintas posibilidades de reutilización de partes de sistemas parecidos o de productos software generales.
Diseño de un caso de uso
Se identifican las clases del diseño que se necesitan para realizar el caso de uso. Las clases de diseño se representan mediante un diagrama de clases asociado.
Diseño de una clase
El propósito de está actividad es crear clases que cumplan su papel en las realizaciones de los casos de uso y los requisitos no funcionales. Tomando en cuenta los siguientes aspectos: sus operaciones, sus atributos, relaciones en las que participa, sus métodos, estados impuestos, sus dependencias con cualquier mecanismo de diseño de diseño genérico, los requisitos relevantes a su implementación y la correcta realización de cualquier interfaz requerida.
Mantenimiento de los contenidos de los subsistemas
Diseñar un subsistema tiene por objetivos: garantizar independencia entre los subsistemas, garantizar que los subsistemas proporcionen las interfaces correctas y que los subsistemas ofrecen una realización correcta de las operaciones tal y como se definen en las interfaces que proporcionan.
Ejemplo de un proyecto de desarrollo
Siguiendo el desarrollo de nuestro proyecto llegamos a la parte final del mismo, referente a los temas tratados en esta guía, que cubre básicamente el análisis y diseño orientado a objetos. Veamos como se puede realizar cada uno de las actividades que el flujo de diseño trae consigo.
A. Diseñar la arquitectura.
i. Identificar nodos y configuraciones
Modelo de Despliegue
- ¿Todos los actores del caso de uso interactuarán con el sistema en el mismo sitio físico?
- ¿Qué requerimientos de computación necesito en cada nodo?
- ¿Qué tipo de conexiones o red existe entre los nodos?
- ¿Qué protocolos manejan?
- ¿Cuáles son sus características?
- ¿Tengo requisitos del tipo Copias Redundantes para caso de fallos? ¿Copia de seguridad de BBDD?
ii. Clases relevantes
B. Diseñar casos de uso
i. Identificar clases de diseño
Identificar clases de diseño que permitan implementar las clases de análisis (tener en cuenta el modelo de despliegue).
Estudiar los requisitos especiales (de rendimiento, de memoria, de diseño) de las clases de análisis, e identificar clases de diseño necesarias.
Ejemplos:
Requisito especial sobre las clases de análisis Ficha de Película y Ficha de Cliente del caso de uso Alquilar película.
Ficha de película y ficha de cliente que se generalizaron en el análisis a la clase ficha deben poder manejarse de una manera organizada y eficiente, por lo que es necesario crear Clases de Diseños que manejen Listas de cada tipo de Ficha.
Requisito especial sobre la clase de análisis I. Usuario. I. Usuario debe ser una clase activa ya que debe estar lista para responder a cualquier petición del usuario en cualquier momento (como cancelar un alquilar mientras se procesa o salir del sistema mientras éste busca la información de una película) Unificación de las clases de análisis I. Usuario e I. Películas. I. Películas se absorbe en la clase de diseño I. Usuario con objeto de reunir en una sola clase todas las interfaces gráficas.
| Clase de análisis | Clase de diseño | Requisito de Diseño |
|---|---|---|
| I. Usuario | I. Usuario | Activa |
| Gestor | Gestor | |
| I. Películas | Absorbida en I. Usuario | |
| Lista Fichas Clientes | Incluida para manejar clientes | |
| Lista Fichas Películas | Incluida para manejar Películas | |
| Ficha Película | Ficha Película | |
| Ficha Cliente | Ficha Cliente | |
| I. Dispensador | I. Dispensador | |
| I. Sistema Contable (1) | I. SC. Local | Del modelo de despliegue |
| I. Sistema Contable (2) | I. SC. Central | Del Modelo de despliegue. Activa |
| I. Banco | I. Banco |
ii. Interacciones entre objetos.
Diagrama de secuencia:Incorpora instancias de los actores participantes, objetos de diseño y la transmisión de mensajes entre ellos.
C. Diseñar clases de diseño
i. Identificar Operaciones
- Identificando los mensajes a los que debe responder en el Diagrama de Secuencia.
- Analizando las responsabilidades de la clase de análisis de la que deriva. A menudo implican una o varias operaciones
- Contemplando los requisitos especiales de la clase de análisis de la que deriva, por ejemplo el acceso a un gestor de BBDD.
- Añadir la visibilidad de cada operación.
- Usar la sintaxis del lenguaje de implementación a utilizar.
Las operaciones de la clase de diseño necesitan soportar todos los roles que la clase desempeña en las diferentes realizaciones de casos de uso.
ii. Identificar atributos
Los atributos deben ser los requeridos para realizar sus operaciones.
Hay que tener en cuenta los atributos obtenidos en la fase de análisis.
Los tipos de atributos se restringen a los tipos disponibles en el lenguaje de programación a usar.
Hay que reutilizar tipos de atributos.
Si una clase de diseño resulta compleja por culpa de sus atributos, se pueden agrupar atributos den clases independientes.
iii. Identificar relaciones
Identificar asociaciones, agregaciones y generalizaciones
Estudiar el diagrama de secuencias y ver qué asociaciones o agregaciones son necesarias.
Agrupar objetos en agregaciones para mandarles mensajes a todos ellos.
Estudiar asociaciones creadas en la fase de análisis.
Si el lenguaje de programación no soporta el mecanismo de generalización o herencia se deben emplear los mecanismos de asociación y agregación.
En la operación devolverPelicula() se ha estimado que es mejor que exista esta agregación entre las clases Ficha Película y Ficha cliente, para evitar el tener que recorrer las dos listas buscando primero la película y después al cliente.
iv. Describir estados de los objetos: Diagrama de estados de la clase FichaCliente
Le propongo que trate de completar con los restantes casos de uso el flujo de diseño, esto como una actividad complementaria optativa.
[editar] Capitulo 6 : Implementación
[editar] Datos Generales:
| Texto Base | [BJR2000] |
| Capítulo | 10 Implementación |
| Páginas | 255-279 |
| Horas de estudio empleadas para el desarrollo del contenido | 12 horas |
[editar] Propositos:
Luego de que se tiene realizado el diseño el siguiente paso es la implementación, esta es a nivel de código fuente, scripts, ejecutables y otros. Cabe indicar que la implementación se realiza ya en los lenguajes de programación especificados para esto se debe contar con los especialistas para la escritura de código.
[editar] Conceptos Claves:
* Arquitecto.-
Responsable de la integridad del modelo de implementación y debe asegurar de que el modelo es correcto, completo y legible.
* Integrador de Sistemas.-
Planifica la secuencia de construcciones necesarias en cada iteración y la integración de cada construcción cuando sus partes han sido implementadas
* Ingeniero de Componentes.-
Define y mantiene el código fuente de uno o varios componentes, garantizando que cada componente implementa la funcionalidad correcta
* Modelo de Implementacion.-
Se implementa en términos de componentes, indicando como se organizan y las dependencias de unos con otros
* Subsistema de Implementacion.-
- Es la forma de organizar los artefactos del modelo en pedazos manejables
- Interfaz.-
Si en un componente se implementa una interfaz debe implementar correctamente todas la operaciones de estas.
- Descripción de la Arquitectura.-
- Contiene una visión de la arquitectura del modelo de implementación.
[editar] Esquema de Estudio:
A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que cada estudiante estima que necesita tutoría y realizar anotaciones personales.
| Tema a revisar | Descripción del Contenido a revisar | Actividades Recomendadas | Planificación Personal del estudio (fecha) | ¿Requiero Tutorial? | Anotaciones |
|---|---|---|---|---|---|
| 6.1. | Objetivos del Diseño | En este flujo también es fundamental comprender los objetivos | |||
| 6.2. | Trabajadores y Artefactos implicados en la Implementación | Luego de la lectura del capítulo, proceda a realizar un cuadro en el cual tenga cada uno de los trabajadores y los artefactos con una descripción de cada uno de estos | |||
| 6.3. | Flujos de Trabajo | Comprenda los flujos de trabajo de la implementación
Los flujos de trabajo contienen actividades y estas son realizadas por uno o varios trabajadores. |
Implementación
Luego de que se tiene realizado el diseño el siguiente paso es la implementación, esta es a nivel de código fuente, scripts, ejecutables y otros. Cabe indicar que la implementación se realiza ya en los lenguajes de programación especificados para esto se debe contar con los especialistas para la escritura de código.
Objetivos
- Planificar las iteraciones se sistema necesarias
- Distribuir el sistema asignando componentes ejecutables a nodos en el diagrama de despliegue.
- Implementar las clases y subsistemas encontrados durante el diseño
- Probar los componentes individualmente, integrarlos
Trabajadores y Artefactos Implicados
| Trabajadores | Descripción |
|---|---|
| Arquitecto | Responsable de la integridad del modelo de implementación y debe asegurar de que el modelo es correcto, completo y legible |
| Integrador de Sistemas | Planifica la secuencia de construcciones necesarias en cada iteración y la integración de cada construcción cuando sus partes han sido implementadas |
| Ingeniero de Componentes | Define y mantiene el código fuente de uno o varios componentes, garantizando que cada componente implementa la funcionalidad correcta |
| Modelo de Implementación | Se implementa en términos de componentes, indicando como se organizan y las dependencias de unos con otros |
| Componente |
|
| Subsistema de implementación | Es la forma de organizar los artefactos del modelo en pedazos manejables |
| Interfaz | Si en un componente se implementa una interfaz debe implementar correctamente todas la operaciones de estas. |
| Descripción de Arquitectura | Contiene una visión de la arquitectura del modelo de implementación |
| Plan de Integración de construcciones | Describe la secuencia de construcciones necesarias en una iteración |
Flujos de Trabajo
Implementación de la Arquitectura
Revise como se realizan los diagramas de componentes en UML, como se realiza o como se hace deploy de estos componentes en cada uno de los nodos o servidores
Integrar el sistema
Para poder hacer integración se debe realizar una planificación previa, recuerde que si no lo hace la integración resultara muy complicada.
Implementar un Subsistema
Tenga en cuenta la vinculación entre el modelo de diseño y el de implementación, la idea de implementar un subsistema es la de poder hacer que los requisitos se estén cumpliendo, es decir se está construyendo lo que se diseño.
Implementar una Clase
En las clase implementamos las operaciones, estas clase resultan de el modelo de diseño, revise como en una herramienta case que se tenga un modelo de diseño se puede obtener la plantilla de las clases.
Realizar Prueba de Unidad
Estas son elaboradas por el desarrollador y pueden ser de caja negra y caja blanca.
