• Author / Uploaded
• Gastón Guamán

Citation preview

MODALIDAD ABIERTA Y A DISTANCIA

Departamento de Ciencias de la Computación y Electrónica Sección Ingeniería del Software y Gestión de Tecnologías de la Información

Fundamentos de Ingeniería de Software Guía Didáctica 4 Créditos

Titulación ƒƒ Informática

Ciclo

V

Autor: Manuel Sucunuta España Marco Patricio Abad

La Universidad Católica de Loja

Asesoría virtual: www.utpl.edu.ec

Fundamentos de Ingeniería de Software Guía Didáctica Manuel Sucunuta España, Marco Patricio Abad UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

CC 4.0, CC BY-NY-SA Diagramación, diseño e impresión: EDILOJA Cía. Ltda. Telefax: 593-7-2611418 San Cayetano Alto s/n www.ediloja.com.ec [email protected] Loja-Ecuador Primera Edición ISBN físico Maquetación y diseño digital EDILOJA Cía. Ltda. Primera Edición ISBN digital -

La versión impresa y digital han sido acreditadas bajo la licencia Creative Commons 4.0, CC BY-NY-SA: Reconocimiento-No comercial-Compartir igual; la cual permite: copiar, distribuir y comunicar públicamente la obra, mientras se reconozca la autoría original, no se utilice con fines comerciales y se permiten obras derivadas, siempre que mantenga la misma licencia al ser divulgada. https://creativecommons.org/licenses/ by-nc-sa/4.0/deed.es Octubre 2017

2.

Índice

2. Índice............................................................................................................................................................. 3 3. Introducción............................................................................................................................................. 5 4. Bibliografía............................................................................................................................................... 6 4.1. Básica..................................................................................................................................................................... 6 4.2. Complementaria............................................................................................................................................... 6

5. Orientaciones generales para el estudio.............................................................................. 8 6. Proceso de enseñanza-aprendizaje para el logro de competencias................. 11 PRIMER BIMESTRE UNIDAD 1. FUNDAMENTOS DE LA INGENIERÍA DE SOFTWARE............................................... 11 1.1. Desarrollo de software profesional........................................................................................................... 11 1.2. Fallas en la ingeniería de software........................................................................................................... 13 1.3. Ética en la Ingeniería de Software............................................................................................................ 14 Autoevaluación 1 ................................................................................................................................ 15

UNIDAD 2. PROCESOS DE DESARROLLO......................................................................................... 17 2.1. Modelos de proceso de software............................................................................................................... 17 2.2. Actividades del proceso................................................................................................................................. 22 2.3. Métodos ágiles.................................................................................................................................................. 24 Autoevaluación 2 ................................................................................................................................ 26

UNIDAD 3. REPRESENTACIÓN DE MODELOS DE SOFTWARE CON UML.................................. 28 3.1. Importancia........................................................................................................................................................ 28 3.2. Modelos de contexto...................................................................................................................................... 29 3.3. Modelos de interacción.................................................................................................................................. 31 3.4. Modelos estructurales.................................................................................................................................... 33 3.5. Modelos de comportamiento..................................................................................................................... 34 Autoevaluación 3 ................................................................................................................................ 36

UNIDAD 4. REQUERIMIENTOS........................................................................................................... 38 4.1. Requerimientos funcionales y no funcionales.................................................................................... 38 4.2. El documento de requerimientos de software................................................................................... 40 4.3. Proceso de ingeniería de requerimientos.............................................................................................. 41 4.4. Adquisición y análisis de requerimientos.............................................................................................. 41 4.5. Validación de requerimientos..................................................................................................................... 42 Autoevaluación 4 ................................................................................................................................ 43

SEGUNDO BIMESTRE UNIDAD 5. ANÁLISIS............................................................................................................................ 45 5.1. Conceptos básicos............................................................................................................................................ 46 5.2. Actividades del análisis.................................................................................................................................. 50 5.3. Gestión del Análisis.......................................................................................................................................... 66

UNIDAD 6. DISEÑO ARQUITECTÓNICO............................................................................................ 71 6.1. Decisiones en el diseño arquitectónico................................................................................................... 72 6.2. Conceptos del diseño...................................................................................................................................... 73 6.3. Patrones arquitectónicos............................................................................................................................... 78 6.4. Arquitecturas de aplicación......................................................................................................................... 79 Autoevaluación 6 ................................................................................................................................ 80

UNIDAD 7. DISEÑO E IMPLEMENTACIÓN....................................................................................... 82 7.1. Diseño orientado a objetos con UML....................................................................................................... 82 7.2. Patrones de diseño........................................................................................................................................... 88 7.3. Conflictos de implementación................................................................................................................... 90 Autoevaluación 7 ................................................................................................................................ 92

UNIDAD 8. PRUEBAS DE SOFTWARE............................................................................................... 94 8.1. Conceptos relacionados a las pruebas..................................................................................................... 94 8.2. Pruebas de desarrollo..................................................................................................................................... 95 8.3. Actividades y gestión de las pruebas....................................................................................................... 99 Autoevaluación 8 ................................................................................................................................ 102

7. Solucionario.............................................................................................................................................. 104 8. Glosario........................................................................................................................................................ 112 9. Referencias bibliográficas.............................................................................................................. 114 10. Anexos........................................................................................................................................................... 115

Guía Didáctica: Fundamentos de Ingeniería de Software

PRELIMINARES

3.

Introducción

El componente académico de Fundamentos de Ingeniería de Software se imparte en el quinto ciclo de la titulación de Ingeniería en Informática, de la Universidad Técnica Particular de Loja, modalidad de estudios Abierta y a Distancia. Es un componente académico troncal de carrera y tiene una valoración de 4 créditos. Esta asignatura le ayudará a conocer las actividades relacionadas con el proceso de desarrollo y gestión de software, permitiendo que pueda adquirir destrezas y habilidades en el desarrollo de un proyecto de software. La Ingeniería de Software es uno de los ejes fundamentales de la Informática, y prepara al estudiante para el desarrollo de soluciones de nivel empresarial en lo que a soluciones de software se refiere, para ello integra los aprendizajes de la línea de programación con los de formación empresarial y agrega el concepto de ingeniería para desarrollar software profesional aplicado a empresas, en este sentido es la primera asignatura en el ámbito de la Ingeniería de Software que sienta la bases para formar profesionales con visión integral y capacidad de proponer soluciones que integren personas, procesos y software. El componente está formado por ocho unidades, distribuidas en cuatro para el primer bimestre y cuatro para el segundo bimestre. En la unidad uno, se abordan los fundamentos teóricos de la Ingeniería de Software, determinando la importancia de construir un software basado en un proceso y las responsabilidades que debe tener un analista a la hora de trabajar con información de una empresa. En la unidad dos, se analizan las actividades de un proceso de desarrollo de software estándar, así como las actividades tanto de los procesos tradicionales como de los modelos ágiles para desarrollar software. En la unidad tres, se analiza un importante tema relacionado con el modelado del sistema. Esto permitirá comprender los diferentes modelos que se desarrollarán en cada una de las unidades de la guía didáctica. En la unidad cuatro, se estudia los requerimientos como base del desarrollo y se abordan los tipos de requerimientos, técnicas de captura, documentación y validación de requerimientos, los cuales sirven de materia prima para las siguientes etapas del proceso. En la unidad cinco, se describe el proceso de análisis de requerimientos para convertirlos en un modelo de clases y modelos dinámicos factibles para ser utilizados en la etapa de diseño. En la unidad seis, se estudian los principios del diseño de aplicaciones y la definición de la arquitectura del sistema, utilizando diferentes estilos arquitectónicos que le permitan construir aplicaciones robustas que cumplen con estándares y atributos de calidad. En la unidad siete, se aborda la generación de aplicaciones a partir de modelos UML, que junto con los patrones de diseño permitirán comprender el proceso de generación de aplicaciones desde herramientas CASE. Y finalmente, en la unidad ocho se estudian los mecanismos de prueba del software utilizando diferentes técnicas y pruebas para asegurar la calidad del producto, este conocimiento es esencial para el desarrollo de software, y es la base para el estudio de la asignatura de Control de Calidad. La Universidad Católica de Loja

5

Guía Didáctica: Fundamentos de Ingeniería de Software

4.

PRELIMINARES

Bibliografía

4.1. Básica §§

Sommerville, I. (2013). Ingeniería de Software. México D.F., México: Pearson. El autor del texto con su amplia experiencia en su novena edición ofrece un texto para aquellos estudiantes de nivel universitario que empiezan y desean profundizar sobre el desarrollo del sistema software. Las exposiciones de los temas son claros y concisos, convirtiéndose en una guía importante para que el estudiante pueda aprender. Los ejemplos son lo suficientemente didácticos y apegados a la realidad que merecen ser analizados.

§§

Abad, P., y Sucunuta, M. (2017). Fundamentos de Ingeniería de Software. Loja, Ecuador: Universidad Técnica Particular de Loja. Guía elaborada para los estudiantes de la titulación de Informática de la modalidad de estudios a distancia de la UTPL, dónde se indica al estudiante los temas que debe estudiar y analizar para conocer sobre el desarrollo de sistemas. En algunos temas se amplía y ejemplifica para que se tenga un mejor dominio de la materia.

4.2. Complementaria §§

Bruegge, B., y Dutoit, A. (2010). Object-Oriented Software Engineering Using UML, Patterns, and Java. United States:Prentice Hall. El texto permite conocer tanto los principios de la ingeniería de software como las prácticas de varias herramientas, procesos y productos orientados a objetos. Se utiliza un estudio de caso para ilustrar los conceptos y temas de cada capítulo, enfatizan el aprendizaje de software orientado a objetos a través de la experiencia práctica, el lector puede aplicar las técnicas aprendidas mediante la implementación de un proyecto de software real.

§§

Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico. México D.F., México: McGraw-Hill. El texto contempla todos los procesos de desarrollo y gestión de un proyecto de software. Se analizan detenidamente cada uno de los conceptos asociados a la ingeniería de software, lo que permite al estudiante entender de forma clara el desarrollo del software.

§§

Bourque, P., y Fairley, R. (2014). Guide to the Software Engineering Body of Knowledge, Version 3.0. Recuperado de http://www.swebok.org/ La guía SWEBOK (cuerpo de conocimiento de la ingeniería de software), describe el conocimiento general que acepta la ingeniería de software. Consta de 15 áreas de conocimiento, que aporta con una descripción general de las actividades de desarrollo y gestión de requisitos.

6

MODALIDAD ABIERTA Y A DISTANCIA

PRELIMINARES

Guía Didáctica: Fundamentos de Ingeniería de Software

OCW (Recurso Educativo Abierto) §§

Blanco, C., et al. (2011). Ingeniería de Software I. Recuperado de http://ocw.unican.es/ensenanzastecnicas/ingenieria-del-software-i Recurso educativo abierto que contempla todas las actividades relacionadas con la Ingeniería de Software.

§§

Ros J., y Alvarez A. (2009). Fundamentos de Ingeniería del Software. Recuperado de http://ocw. um.es/ingenierias/fundamentos-de-ingenieria-del-software/ Recurso Educativo Abierto que cubre todo el proceso de la ingeniería del software.

La Universidad Católica de Loja

7

Guía Didáctica: Fundamentos de Ingeniería de Software

5.

PRELIMINARES

Orientaciones generales para el estudio

Estudiar a distancia es un reto que requiere esfuerzo, dedicación y sobre todo de organización, por ello debe hacer de esta actividad un trabajo continuo y sistemático, organice su tiempo de manera que pueda verdaderamente aprovechar los contenidos que se le están ofreciendo. Le sugerimos hacer vida esta frase, que, aunque le puede parecer trillada, es la que más se adapta a la realidad de las personas que estudian a distancia: “No deje para mañana lo que puede y debe hacer hoy”. Le proponemos algunas orientaciones que le servirán en su proceso de aprendizaje: Materiales Recuerde que los materiales didácticos con los que contará son: la guía y el texto básico. La guía didáctica le orientará sobre cómo y qué temas estudiar, además contiene ejemplos, ejercicios y autoevaluaciones que permitirán medir su grado de comprensión. Además, se podrá apoyar de la bibliografía complementaria. Para reforzar el proceso de aprendizaje la UTPL pone a disposición la plataforma virtual denominada Entorno Virtual de Aprendizaje (EVA), dónde se encuentran cada uno de los componentes académicos con su respectivo profesor-tutor que le guiará en el ciclo académico; al cual podrá realizar las consultas que requiera en un horario que oportunamente se publicará en la plataforma. Las tutorías las puede hacer mediante la plataforma virtual, correo electrónico o a través de la línea telefónica, aproveche estas alternativas de comunicación que la UTPL pone a su disposición. Las tareas son actividades prácticas que acompañan a cada una de las asignaturas, le permiten aplicar y reforzar los conocimientos adquiridos mediante su desarrollo, se trata de una actividad compleja, por lo que se recomienda desarrollarla desde el inicio del bimestre y avanzar de manera progresiva, conforme se detalla en el plan docente de la asignatura, esta tarea debe enviarse a través del EVA en las fechas establecidas, su valoración es de 6 puntos que se acumulan para la nota parcial. ¿Cómo estudiar? Programe un horario de estudio diario; para esta asignatura es necesario que dedique al menos una hora diaria de autoestudio. Para ayudarse en el proceso de aprendizaje utilice las técnicas de estudio que más se adapten a su manera de aprender: subrayado, resúmenes, cuadros sinópticos y trate, en lo posible, de estudiar en un horario y ambiente adecuado. Como una estrategia de aprendizaje le sugerimos realice todas las autoevaluaciones y ejercicios que se plantean en la presente guía, ya que esto le permitirá poner en práctica los conocimientos teóricos del componente académico. No olvide que, si surge alguna inquietud con respecto a estos ejercicios, puede solicitar asesoría al profesor-tutor. Toda la planificación de la asignatura para el presente período académico se encuentra detallado en el plan docente, el mismo que se ha distribuido por semanas y en cada semana las actividades que se deben desarrollar. Este plan oportunamente el profesor-tutor lo publicará en el EVA, el cual deberá revisar detenidamente para conocer todas las actividades que debe realizar.

8

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

PRELIMINARES

Apoyo Tecnológico e Interactividad Como parte del proceso de enseñanza se dispone del Entorno Virtual de Aprendizaje (EVA), de la biblioteca virtual, repositorio de documentos (OCW), entre otros, por lo que es fundamental que revise continuamente estos recursos con el fin de ponerse al tanto de los materiales de su asignatura. Preste especial interés al EVA ya que con este recurso el profesor-tutor publicará algunos casos y ejercicios que le ayudarán a reforzar los conocimientos, así como también de su participación ya sea en foros, cuestionarios y chat. Revise los REA (Recursos Educativos Abiertos), ya que el profesor tutor estará publicando presentaciones, videos, archivos, etc., que tengan relación con la asignatura. Cabe resaltar que los cuestionarios, foro, chat y tarea por cada bimestre son actividades obligatorias que tienen calificación y que deberá realizarlas en el EVA, en fechas establecidas, por ello es importante el uso de esta plataforma y el ingreso de forma periódica. Considere al EVA una herramienta fundamental y prioritaria para el desarrollo de sus actividades académicas ya que como se indicó anteriormente, el profesor-tutor dará las indicaciones pertinentes en esta plataforma. Finalmente le sugiero prepararse oportunamente para las evaluaciones parciales y presenciales que en fechas específicas se estarán desarrollando, ya que estas le permitirán medir el grado de conocimiento adquirido de la asignatura. Esperamos que todas y cada una de estas recomendaciones contribuyan al aprendizaje exitoso de este componente académico. Como ayuda gráfica a la presente guía se utilizan los siguiente focalizadores: Figura

Descripción Texto básico Acudir al texto básico a leer comprensivamente el tema que se indica.

REA Acceder al tema del REA que se indica. Son archivos en formato PDF que los puede descargar. Cuestionario Preguntas que se plantean al final de cada unidad como estrategia de aprendizaje, el estudiante debe contestar y luego comparar con las respuestas que se encuentran al final de la guía. Buscar en la web Actividad que se le plantea al estudiante para que busque en la web, se facilitará la dirección URL o los temas para que encuentre determinados recursos. Duda Son interrogantes que se plantean para aclarar los ciertos temas y dar un enfoque de análisis. No es una actividad que debe responder, sino de reflexión.

La Universidad Católica de Loja

9

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

6.

Proceso de enseñanza-aprendizaje para el logro de competencias

PRIMER BIMESTRE UNIDAD 1. FUNDAMENTOS DE LA INGENIERÍA DE SOFTWARE Iniciamos revisando los conceptos fundamentales sobre la que se sustenta la Ingeniería de Software (IS), sus características e importancia en la construcción del software. De la misma manera con el afán de justificar la importancia de la IS, se indican algunos fallos relevantes que se han dado en el tiempo a consecuencia del software. Finalmente, se resalta la importancia del rol del Ingeniero de Software en el manejo de la información de una organización, sus responsabilidades y principios para garantizar un adecuado comportamiento a nivel profesional.

1.1. Desarrollo de software profesional En la actualidad, la producción de software no se trata solamente de construir programas para solucionar un tema en concreto, sino de aplicar estrategias que permitan construir productos con un elevado nivel de calidad. Esto sin duda que se logra con la ayuda de la Ingeniería de Software. Empiece conociendo cómo surge la Ingeniería de Software, para ello revise el tema Introducción a la Ingeniería de Software del REA Ingeniería de Software I1, dispositivas de la 1 a la 8. Terminada la lectura podemos concluir que, el software de hoy en día requiere de tecnología sofisticada, más aún cuando se requiere procesar y compartir grandes cantidades de información entre usuarios y clientes. Una vez conocido el origen de la Ingeniería de Software continúe revisando el tema Desarrollo de Software Profesional, del texto básico. Ponga especial atención a las Preguntas planteadas con frecuencia sobre el software, que se indican en la figura. Finalizada la lectura del tema indicado podemos deducir las razones por las que es indispensable la construcción de software a nivel profesional, ya que en la actualidad las organizaciones no requieren de un simple programa que funcione de forma aislada, sino de soluciones integrales que contemplen las actividades que se realizan en cada uno de sus procesos. Además, es importante que establezca la diferencia entre los dos tipos de software que indica el autor en el texto básico: los Productos genéricos y los Productos personalizados. En ambos casos, la importancia radica no solamente en la satisfacción del cliente, sino también en los desarrolladores y los elementos derivados del producto software, que se reflejan en ciertos elementos conocidos como atributos, tal como se evidencia en la figura Atributos esenciales del buen software del texto básico, para determinar la calidad del software. 1 https://ocw.unican.es/course/view.php?id=169§ion=1 La Universidad Católica de Loja

11

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

En resumen, la ingeniería de Software es una actividad que permite: •

Modelado para resolver problemas de complejidad tanto del proceso como del software.

•

Resolución de problemas mediante el desarrollo de los modelos que buscan la solución aceptable.

•

Adquisición de conocimiento, debido a que los ingenieros de software recopilan datos, los organizan en información y los formalizan en conocimiento.

•

Impulsada por la lógica, para que al adquirir conocimientos y tomar decisiones sobre el sistema o su dominio de aplicación, los ingenieros de software también puedan capturar el contexto en el que se tomaron las decisiones y la justificación detrás de estas decisiones.

En cada una de estas actividades, los ingenieros de software tienen que trabajar bajo las limitaciones de personas, tiempo y presupuesto, considerando que el cambio puede ocurrir en cualquier momento.

Figura 1. Conceptos de ingeniería de software representados como un diagrama de clases UML Fuente: Bruegge, B., y Dutoit, A. (2010)

En la figura 1, se muestra los conceptos relacionados con la ingeniería de software representados mediante un diagrama UML, que consiste en lo siguiente: un proyecto de software, cuyo propósito es desarrollar un sistema de software, está compuesto de varias actividades. Cada actividad está compuesta por una serie de tareas. Una Tarea consume recursos y produce un producto-trabajo. Un Producto-Trabajo puede ser un sistema, un modelo o un documento. Los recursos son: participantes, tiempo o equipo. En el diagrama cada rectángulo representa un concepto. Las líneas entre los rectángulos representan diferentes relaciones entre los conceptos. Por ejemplo, la forma de los diamantes indica agregación: un proyecto incluye varias actividades, que incluye varias tareas. La forma del triángulo indica una relación de generalización.

12

MODALIDAD ABIERTA Y A DISTANCIA

PRIMER BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

1.2. Fallas en la ingeniería de software Los sistemas de software que se han construido a través de los años se han integrado en todos los aspectos de la sociedad, por lo que parte de nuestra vida está ligada al software. A pesar de las buenas intenciones, existe un gran número de proyectos software que no han tenido éxito, un gran porcentaje nunca se terminaron, y peor aún algunos de proyectos terminaron en desastre, causando perdida de dinero, tiempo y tragedias de pérdida de vidas (Braude y Bernestein, 2016) . El presente tema no se aborda en el texto básico, y siendo un tema importante que justifica el uso de la ingeniería de software para el desarrollo del software a continuación, se listan algunos casos de las fallas atribuidas al software que han ocasionado serios problemas. •

Error de año bisiesto

•

Fracaso del Mariner 1 (1962)

•

Sobregiro del Banco de New York (1985).

•

Accidente de un F-18 (1986).

•

Error del milenio (2000): O “Y2K”

•

Medicina: radioterapia

•

Transporte: Aerolínea American Airlines

•

Retrasado y con sobre presupuesto

•

Tiempo de entrega

Cada una de estas fallas son consecuencia de problemas en el software. Para algunos casos, los desarrolladores no anticiparon situaciones raras, por ejemplo, que una persona pueda vivir más de 100 años o los años bisiestos que afectan las fechas de vencimiento. En otros casos los desarrolladores no esperaban que los usuarios utilizaran el sistema de forma activa, por ejemplo, explotando los agujeros de seguridad en el software de red. Y en otros casos los fallos del sistema resultaron de fallas en la gestión del proyecto, por ejemplo, entrega tardía y exceso de presupuesto, entrega puntual de un sistema incorrecto o complejidad innecesaria (Bruegge y Dutoit, 2010) Afortunadamente no todos los proyectos terminan en los desastres que se indican anteriormente, pero si en fracaso. Entonces, ¿Qué hace que un proyecto de software no tenga éxito? En pocas palabras, un proyecto de software sin éxito es uno que no cumple con las expectativas del cliente. Más específicamente los resultados indeseables pueden incluir lo siguiente: •

Proyectos por encima del presupuesto

•

Excesiva planificación y/o pérdida de presencia en el mercado

•

No cumple con los requisitos del cliente

•

Menor calidad de la esperada

•

El rendimiento no satisface las expectativas

•

Demasiado difícil de utilizar

En conclusión, la aparición de errores (bugs) no es anormal, está relacionada con el comportamiento del ser humano, lo complejo del problema y la responsabilidad en aplicar mecanismos de validación. Cuando un software controla dispositivos peligrosos como control aéreo, balístico y espacial, gestiona material peligroso o controla máquinas peligrosas, el más mínimo detalle cuenta para que no se convierta en una catástrofe de grandes magnitudes.

La Universidad Católica de Loja

13

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

1.3. Ética en la Ingeniería de Software Como en todas las profesiones la ética profesional está atada a un comportamiento adecuado y más aún cuando se trata de un profesional de desarrollo de software, ya que cualquiera que sea el rol a desempeñar en el proyecto de desarrollo, va a tener acceso a información importante y exclusiva de la organización, por lo tanto, se requiere de responsabilidades que va más allá de los conocimientos técnicos con el fin de precautelar la integridad y confidencialidad de la información. Revise el apartado Ética en la ingeniería de software, del texto básico para conocer sobre la responsabilidad que tiene el equipo de desarrollo del proyecto software en una organización. Terminada la lectura se puede resaltar que: •

La Ingeniería de Software implica responsabilidades mayores que el simple uso de habilidades técnicas.

•

Los ingenieros de software deben comportarse de manera honesta y responsable para que sean respetados como profesionales.

•

El comportamiento responsable es mucho más que simplemente actuar dentro de la ley. Analice el Código de Ética y Práctica profesional de la Ingeniería de Software versión completa publicado por la ACM en la siguiente dirección: http://www.acm.org/about/se-code-s y analice detenidamente cada uno de los principios.

Con la ayuda de este código, se puede conocer el fin y la misión de un ingeniero de software para establecer el comportamiento y los valores para cada proyecto. El código de ética no tiene que ser obligatorio o seguirlo al pie de la letra, ya que tenemos diferentes ideologías, pero debemos ser conscientes que al ser profesionales tenemos que brindar nuestro conocimiento a las personas que lo requieran para mejorar o innovar las actividades relacionadas con los procesos que se desarrollan en las organizaciones. Para finalizar la presente unidad revise el tema Estudios de caso, del texto básico, para analizar los ejemplos que se utilizarán a lo largo del texto, y sobre los cuales se basa la práctica de la asignatura. Luego de revisar los casos, es posible que le queden algunas interrogantes. No se preocupe, conforme avance en el estudio de los temas, se van realizando la descripción de cada caso.

14

MODALIDAD ABIERTA Y A DISTANCIA

PRIMER BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

Autoevaluación 1

Estimado estudiante, hemos finalizado el estudio de la presente unidad, por lo que se recomienda realizar la autoevaluación que se indica a continuación con el propósito de comprobar el conocimiento adquirido. Recuerde que al final de la guía se han incluido las soluciones a estas autoevaluaciones; sin embargo, deberá revisarlas sólo después de haber obtenido sus propias respuestas, lo que le permitirá saber si los temas están o no entendidos. Lea detenidamente cada una de las preguntas y seleccione la alternativa correcta según corresponda. 1.

2.

3.

4.

5.

6.

Las actividades fundamentales de la ingeniería de software son: a.

Análisis, arquitectura, validación y mantenimiento del software

b.

Desarrollo y gestión del software

c.

Especificación, desarrollo, validación y evolución del software

Los sistemas independientes que se producen por una organización de desarrollo y se venden en el mercado a cualquier cliente, se conoce como productos de software: a.

Genéricos

b.

Personalizados

c.

A la medida

El sistema de nómina para la UTPL, es un caso de producto de software: a.

Genérico

b.

Personalizado

c.

Sin categorizar

La base de datos Oracle es un caso de producto de software: a.

Genérico

b.

Personalizado

c.

Sin categorizar

A la secuencia de actividades que conducen a la elaboración de un producto de software, se lo conoce como: a.

Ingeniería de software

b.

Proceso de software

c.

Sistema

Los clientes e ingenieros definen el software que se producirá y las restricciones en su operación, a esta actividad se conoce como: a.

Especificación

b.

Desarrollo

c.

Validación

La Universidad Católica de Loja

15

Guía Didáctica: Fundamentos de Ingeniería de Software

7.

8.

9.

10.

PRIMER BIMESTRE

A la actividad donde se diseña y codifica el software se conoce como a.

Desarrollo

b.

Validación

c.

Evolución

A la actividad donde se modifica el software para reflejar los requerimientos cambiantes del cliente y del mercado, se conoce como: a.

Desarrollo

b.

Validación

c.

Evolución

A la actividad donde se verifica el software para asegurar que esté acorde a lo que el cliente requiere, se conoce como: a.

Desarrollo

b.

Validación

c.

Evolución

A los sistemas de control de software que regulan y gestionan dispositivos de hardware, se los conoce como: a.

Aplicaciones independientes

b.

Sistemas de control embebido

c.

Sistemas para modelado y simulación

Terminada la autoevaluación verifique sus respuestas en el solucionario que se encuentra al final de la presente guía.

16

MODALIDAD ABIERTA Y A DISTANCIA

PRIMER BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

UNIDAD 2. PROCESOS DE DESARROLLO Conocidos los conceptos fundamentales de la Ingeniería de Software, en esta segunda unidad se analiza las actividades del proceso de desarrollo de software, con el objetivo de determinar la importancia del desarrollo de software sustentado en un proceso formal que permita manejar de forma coherente la complejidad y los cambios del proyecto. Es importante que determine cómo los procesos de desarrollo de software gestionan y coordinar a las personas, el producto, el proyecto y el proceso, como actividades transversales en el desarrollo de software, especialmente cuando tenemos desarrollos grandes y complejos.

2.1. Modelos de proceso de software Un ingeniero o equipo de ingenieros de software para resolver problemas reales de las organizaciones debe incorporar una estrategia de desarrollo que acompañe al proceso, métodos y herramientas; esta estrategia se llama modelo de procesos. Por lo tanto, debe seleccionar un modelo de procesos para la ingeniería de software según la naturaleza del proyecto y de la aplicación, los métodos y herramientas a utilizarse, los controles y entregas que se requieren. Es momento de revisar la Introducción del capítulo Procesos de software del texto básico para conocer ciertas particularidades relacionadas con el desarrollo del software. Utilice alguna técnica de estudio que le permita aprender sobre las actividades principales que todo proceso debe tener. Finalizada la lectura, es imprescindible que conozca las actividades del proceso de desarrollo de software, y si es necesarios vuelva a revisar, ya que estas actividades son las que comprende el desarrollo del software y que debe tenerlas siempre presente. En la figura 2, se especifican las actividades generales que todo proceso de desarrollo de software considera. Es importante recalcar que al igual que las actividades, al momento de describir un proceso software también se deben considerar los productos, roles y las precondiciones y postcondiciones.

Figura 2. Actividades del proceso software

La Universidad Católica de Loja

17

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

El proceso de desarrollo de software no es único y al no existir un proceso universal que sea efectivo para todos los contextos de proyectos de desarrollo, existe una diversidad de actividades y metodologías que hacen difícil automatizar todo un proceso de desarrollo de software. Las actividades relacionadas al proceso de desarrollo difieren de acuerdo al entorno y muchos autores recomiendan actividades puntuales, por ejemplo, en el texto básico Sommerville (2012) considera cuatro actividades: especificación, diseño e implementación, validación y evolución del software. Mientras que Pressman (2014) considera cinco actividades: comunicación, planeación, modelado, construcción y despliegue. De la misma manera Bruegge y Dutoit (2010) consideran seis actividades: obtención de requisitos, análisis, diseño del sistema, diseño de objetos, implementación y pruebas. Pero esto no quiere decir que son actividades totalmente distintas con enfoques diferentes sino más bien que cada una de estas actividades coincide en un alto porcentaje y las diferencias están en el enfoque y particularidades que cada autor desea que forme parte del proceso de desarrollo de software. Es hora de conocer los modelos más conocidos, revise el tema Modelos de proceso de software del texto básico. Es importante que determine la diferencia entre los tres modelos que indica el autor, con la finalidad de establecer ciertas ventajas que podrían tener uno respecto al otro. Terminada la lectura, claramente podría determinar las diferencias entre estos tres modelos (cascada, incremental y orientado a la reutilización) y responder a las siguientes preguntas: •

¿Son realmente diferente los modelos?

•

¿Cuál modelo es el más adecuado para el desarrollo de software?

•

¿Elegir un modelo de desarrollo dependerá del tipo de problema?

•

¿Se puede combinar los modelos?

A continuación, se analiza cada uno de estos modelos, con el objeto de profundizar en cada una de las actividades que forman parte del proceso, y especialmente argumentar de mejor manera la respuesta a las interrogantes anteriormente planteadas. 2.1.1.  El modelo en cascada Es el más básico de todos y ha servido como bloque de construcción para los demás paradigmas de ciclo de vida. Está basado en un ciclo convencional de una ingeniería y su visión es muy simple: el desarrollo de software se debe realizar siguiendo una secuencia de fases. Cada etapa tiene un conjunto de metas bien definidas y las actividades dentro de cada una contribuyen a la satisfacción de metas de esa fase. Es momento de revisar el tema El modelo en cascada del texto básico, ponga especial énfasis en cada una de las etapas del modelo, así como en las actividades. Leído el tema se podría concluir que la ventaja del modelo radica en su sencillez, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software. Sin embargo, al aplicar a un determinado contexto puede ocurrir que:

18

•

Los proyectos reales raramente siguen un flujo secuencial que propone el modelo. Siempre hay iteraciones y se crean problemas en la aplicación del paradigma.

•

Normalmente, al principio, es difícil para el cliente establecer todos los requisitos de forma explícita.

•

El cliente debe ser paciente ya que hasta que no llegue a etapas finales del proyecto no estará disponible una versión operativa del programa. Un error importante que no pueda ser detectado hasta que el programa esté funcionando, puede ser desastroso. MODALIDAD ABIERTA Y A DISTANCIA

PRIMER BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

Por lo tanto, el modelo se puede utilizar para cierto tipo de problemas, dónde los requisitos previamente ya estén establecidos y comúnmente no existan cambios. 2.1.2.  Modelo incremental El modelo incremental combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos. Este modelo aplica secuencias lineales de forma escalonada mientras transcurre el tiempo donde cada secuencia lineal produce un incremento del software. Revise el apartado Desarrollo incremental del texto básico. Analice detenidamente las actividades concurrentes del desarrollo incremental que se muestran en la figura. Terminada la lectura, podemos concluir que este modelo con respecto al modelo en cascada se caracteriza por la reducción de costos, sencillez al interactuar con el cliente y entregas más rápidas. La mayoría de los proyectos de desarrollo de software se complementan con un enfoque “Iterativo”, de ahí que muchos autores sugieren el desarrollo “iterativo e incremental”, que consiste en planificar el desarrollo en diversos bloques temporales llamados iteraciones, dónde cada iteración se puede entender como miniproyectos. En todas las iteraciones se repite un proceso de trabajo similar para proporcionar un resultado completo sobre el producto final, de manera que el cliente pueda obtener los beneficios del proyecto de forma incremental. Para ello, cada requisito se debe completar en una única iteración, el equipo debe realizar todas las tareas necesarias para completarlo (incluyendo pruebas y documentación) y que esté preparado para ser entregado al cliente con el mínimo esfuerzo necesario. De esta manera no se deja para el final del proyecto ninguna actividad arriesgada relacionada con la entrega de requisitos. En la figura 3 se muestra la secuencia de las actividades del modelo Iterativo e Incremental, dónde con cada iteración el equipo evoluciona el producto a partir de los resultados completados en las iteraciones anteriores, añadiendo nuevos objetivos/requisitos o mejorando los que ya fueron completados. Un aspecto fundamental para guiar el desarrollo iterativo e incremental es la priorización de los objetivos/ requisitos en función del valor que aportan al cliente.

Figura 3. Proceso Iterativo e Incremental Fuente: Bruegge y Dutoit, 2010.

La Universidad Católica de Loja

19

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

2.1.3.  Modelo de Ingeniería del Software orientada a la reutilización Es el proceso de creación de sistemas de software a partir de un software existente, en lugar de tener que rediseñar desde el principio. El diseño basado en reutilización busca construir un producto software integrando componentes pre-existentes. Revise detenidamente el tema Ingeniería de software orientada a la reutilización del texto básico. Analice la figura que indica las actividades que comprende éste modelo. Finalizada la lectura, se puede determinar que este modelo necesita de información del software o componente existente, es así que para desarrollar la primera actividad “Análisis de componentes”, es necesario la especificación de requerimientos del software desarrollado, es decir, el punto de partida de las actividades del modelo son los requerimientos implementados. Como se ha manifestado el modelo se puede utilizar en proyectos dónde existan componentes desarrollados que se los pueda reutilizar, consecuentemente se requiere de información que en muchas ocasiones no existe, teniendo que el equipo de desarrollo enfrentarse a las siguientes dificultades: •

En muchas empresas no existe plan de reutilización (No se considera prioritario)

•

Escasa formación del personal

•

Resistencia del personal al uso de modelos basados en reutilización

•

Pobre soporte metodológico del modelo

•

Uso de métodos que no promueven la reutilización (Estructurados)

•

Es necesario la implementación de métodos para:

•

￮￮

Desarrollo para reutilización

￮￮

Desarrollo con reutilización

Los más importante ¿Quién soporta los gastos adicionales de la reutilización? Complemente el estudio de éste tema revisando el Tema 3. Procesos de Ingeniería de Software del REA Ingeniería de Software I. El documento analiza los ciclos de vida tradicionales, el ciclo de vida orientado a objetos y las metodologías de desarrollo de software.

Luego de la lectura y análisis se podrá dar cuenta que no solamente existen los tres modelos que hemos analizado, sino que existen otros modelos para el desarrollo de software como es: RAD, Espiral, Prototipos, entre otros. De éstos modelos ¿Cuál es el más adecuado?, sin duda alguna que para responder de forma adecuada se necesitan de elementos adicionales que permitan elegir de forma coherente el modelo. A continuación, se presenta una lista de factores que afectan la elección del modelo de software (Raval y Rathod, 2013)

20

•

Naturaleza del proyecto

•

Tamaño del proyecto

•

Duración del proyecto

•

Complejidad del proyecto

•

Nivel y tipo de riesgo esperado

•

Nivel de comprensión de los requisitos de usuario

•

Nivel de comprensión del área de aplicación

•

Involucramiento del cliente

•

Experiencia de los desarrolladores

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

•

Tamaño del equipo

•

Interacción hombre-máquina

•

Disponibilidad de herramientas y tecnología

•

Versión del producto

•

Nivel de consistencia requerido

En la tabla 1, se muestra una comparativa de los modelos más comunes y que se podrían utilizar en el desarrollo del software. Tabla 1. Comparación de varios modelos de procesos con diferentes parámetros Modelo de procesos

Parámetro

Cascada

Espiral

Ágil

Nivel inicial

Nivel inicial

Cambian de forma incremental

Si

No

No

No

Alto

Medio

No

Alto

Alto

Bajo

Bajo

Alto

Bajo

Medio

Alto

A nivel inicial

No

No

No

Si

Si

I m p l e m e nt a c i ó n práctica

No

Bajo

Medio

No

Medio

Alto

Comprensibilidad

Simple

Intermedio

Intermedio

Intermedio

Difícil

Muy complejo

Precondición

Requisitos claramente definidos

El producto principal debe estar claramente definido

Idea clara del diseño rápido

Idea clara del componente a reutilizar

No

No

Usabilidad

Básica

Media

Alta

Media

Media

Alta

Prioridad del cliente

Nulo

Nulo

Intermedio

Nulo

Intermedio

Alto

Enfoque industria

Básico

Básico

Medio

Medio

Medio

Alto

Bajo

Bajo

Alto

Muy alto

Costoso

Muy costoso

Si

Si

Si

Si

No

No

No

No

Si

Si

No

Muy alto

Claridad en especificación requisitos

la de

Comentarios usuario

del

Velocidad cambiar

para

Previsibilidad Identificación riesgos

de

de

la

Costo Organización recursos Elasticidad

de

Incremental

Prototipos

Nivel inicial

Nivel Inicial

A nivel medio

No

No

Bajo

RAD

Fuente: Ravla y Rathod, 2013

La Universidad Católica de Loja

21

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

En la tabla 2, se muestra otros criterios para seleccionar el modelo para el desarrollo de software. Estos factores consideran los elementos más importantes que contribuyen al éxito o fracaso de los proyectos de software. Tabla 2. Factores para seleccionar el modelo de desarrollo Riesgo

Requerimientos

Frecuencia de cambio

Documentación

Participación del usuario

Cascada

Bajo

Completo

Mínimo

Completa

No requerido

Medio

Tardío

Incremental

Alto

Completo

Mínimo

Completa

Requerido

Alto

Temprano

Espiral

Alto

Incompleto

Alto

Completa

Requerido

Alto

Temprano

Prototipo

--

Incompleto

Alto

Bajo

Requerido

--

Temprano

RAD

--

Incompleto

Alto

Bajo

Requerido

--

Temprano

Ágil

--

Incompleto

Alto

Bajo

Requerido

--

Temprano

Costo

Tiempo de entrega

Fuente: Bruegge y Dutoit (2010)

2.2. Actividades del proceso Como se indicó en el apartado 2.1, las actividades del proceso de desarrollo de software son cuatro: especificación, diseño e implementación, validación y evolución del software, dónde cada una cumple con un objetivo importante en la construcción del software. A continuación, se analizan cada una de ellas. 2.2.1.  Especificación del software Consiste en la primera actividad para comprender qué servicios se requieren del software. Se la conoce también como Ingeniería de requisitos y consiste en actividades de desarrollo y gestión. Revise el apartado Especificación del software del texto básico y ponga especial atención a la figura dónde se indica el proceso de ingeniería de requerimientos. Terminada la lectura es importante aclarar que estas cuatro actividades: 1) Estudio de factibilidad, 2) obtención y análisis de requerimientos, 3) especificación de requerimientos y 4) validación de requerimientos, no se realizan una sola vez, sino que de acuerdo a la información o ajustes que se tengan que considerar se abordan las veces que sean necesario para definir los requerimientos de software. También es importante el uso de herramientas de gestión de requisitos ya que permiten tener un mayor control del desarrollo de los requerimientos. Más adelante en la unidad 4, se indicará la manera de especificar los requisitos funcionales y no funcionales. 2.2.2.  Diseño e Implementación del software En base a los requisitos de software definidos en la especificación se procede a diseñar la aplicación y luego a implementar. Al diseño se lo define como “el proceso de definir la arquitectura, los componentes, las interfaces y otras características de un sistema o componente” y “el resultado de ese proceso”. Desde el punto de vista de proceso, el diseño de software es la actividad del ciclo de vida de la ingeniería de software en la que se analizan los requisitos de software para producir una descripción de la estructura interna del software que servirá de base para su construcción (SWEBOK 2014).

22

MODALIDAD ABIERTA Y A DISTANCIA

PRIMER BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

Continúe el estudio revisando el apartado Diseño e implementación del software del texto básico. De igual manera ponga especial énfasis en la figura dónde se muestra las actividades que forman parte de ésta etapa. Aunque en la especificación, ya se trabaja en una arquitectura candidata es en esta etapa donde se consolida la arquitectura como uno de los componentes de diseño. En las siguientes unidades se analiza detenidamente esta etapa del desarrollo de software. 2.2.3.  Validación del software En esta etapa se realiza una actividad fundamental que consiste en verificar que lo que se ha construido es lo que el cliente ha solicitado, evidentemente no es una actividad final, sino que se realiza desde que la especificación del software. Revise el apartado Validación del software del texto básico. Ponga especial interés en las diferentes pruebas que se realizan a lo largo del desarrollo del proyecto. Luego de la lectura podemos acotar que las pruebas consisten en la verificación del software ante comportamientos esperados para un conjunto finito de casos de prueba adecuadamente seleccionados del dominio del problema. Actualmente la visión de las pruebas de software ha cambiado de forma efectiva respecto a años anteriores. Las pruebas ya no se consideran como una actividad que se inicia después de que se complete la fase de codificación, sino más bien que las pruebas de software son o deberían ser a lo largo de todo el ciclo de vida de desarrollo y mantenimiento. La planificación de las pruebas de software debería comenzar con las primeras etapas del proceso de requisitos de software y los planes y procedimientos de prueba deberían desarrollarse sistemáticamente y continuamente y refinarse a medida que avanza el desarrollo del software. Estas actividades de planificación de pruebas y diseño de pruebas proporcionan información útil para diseñadores de software y ayudan a resaltar posibles debilidades, como descuidos y contradicciones de diseño, u omisiones y ambigüedades en la documentación (SWEBOK 2014). 2.2.4.  Evolución del software También conocida como mantenimiento del software, es una actividad fundamental ya que a medida que pasa el tiempo, las aplicaciones de software deben ser sometidas a procesos de modificación que extiendan su vida útil o mejoren sus características. Corrección de errores(bugs), adaptación a nuevos entornos tecnológicos o agregado de funcionalidad son algunas de las tareas que incluye el mantenimiento del software, siendo una de las actividades que se repite periódicamente desde que empieza a utilizarse hasta su abandono definitivo. Revise el apartado Evolución del software del texto básico. Ponga especial atención a la figura dónde se indican las actividades que deben realizarse para hacer un correcto mantenimiento del software. Finalizada la lectura, podemos acotar que siempre habrá que realizar actualizaciones al software ya desarrollado, estas actualizaciones deben realizarse bajo un modelo que permita gestionar los requerimientos sin dejar de lado la calidad del producto. Estas actualizaciones denominada gestión del cambio se puede realizar mediante prototipos o entrega incremental tal como lo sugiere el autor del texto básico.

La Universidad Católica de Loja

23

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

Para conocer cómo gestionar de forma adecuada el cambio, revise el tema Cómo enfrentar el cambio del texto básico. Analice los subtemas relacionados con prototipo, entrega incremental y el modelo en espiral de Boehm. Finalizada la lectura es importante recalcar que cada modelo requiere de la definición de los requerimientos, siendo éstos fundamentales ya sea para la elaboración de los prototipos o para el desarrollo y entregas incrementales. Analice detenidamente la figura del Modelo en espiral de Boehm del proceso de software, ya que claramente se puede evidenciar el desarrollo del proyecto en base a las actividades que se indican. Todos estos modelos que hemos analizado se conocen como tradicionales y su uso depende de los factores que se han analizado. Sin embargo, también existen las metodologías de desarrollo ágil cuya finalidad siempre será crear software de una forma más rápida de lo que se venía logrando con las metodologías tradicionales. Actualmente existe una gran cantidad de metodologías ágiles, donde cada una cuenta con sus propias características únicas, que las diferencian de las demás. En la tabla 3 se incluyen algunos tipos de metodologías tradicionales y ágiles que se utilizan en la actualidad. Tabla 3. Metodologías de desarrollo tradicionales y ágiles Tradicionales Cascada Prototipos Incremental Espiral Rad (Desarrollo rápido de aplicaciones)

Ágiles XP Scrum Kanban Dynamic Systems Development Method (DSDM) Proceso Unificado Ágil (Agile Unified Process)

Fuente: Rodríguez (2017)

2.3. Métodos ágiles El desarrollo de software ágil es una de las tendencias que está de moda en el sector tecnológico, ya que representa una opción razonable a la ingeniería convencional para ciertas clases de software y ciertos tipos de proyectos de software. Revise la Unidad Desarrollo ágil del software del texto básico. Analice detenidamente los principios del desarrollo ágil, así como el desarrollo dirigido por un plan y el desarrollo ágil. Podemos concluir luego de la lectura que el desarrollo ágil consiste principalmente en trabajar con menos documentación que la que utilizan los procesos tradicionales además del uso del enfoque incremental. Frente a los pasos del tradicional método en cascada, el desarrollo ágil de software se basa en pasos comunes dentro del ciclo de vida del software. En cada interacción, el equipo de desarrollo no entrega todo el programa, sino que se van añadiendo pequeños elementos totalmente probados, sin errores, con el fin de que la solución final esté completamente operativa desde el primer momento.

24

MODALIDAD ABIERTA Y A DISTANCIA

PRIMER BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

Figura 4. Modelo tradicional versus modelos ágiles Fuente: Rodríguez (2017)

En la figura 4 se muestra la diferencia de actividades entre el modelo tradicional y el modelo ágil. Claramente se puede apreciar que en el modelo tradicional se desarrolla todo el proyecto mientras que en el ágil cada iteración es una parte del software, y cada parte se pone en marcha. En los métodos de desarrollo ágil de software, la comunicación entre todos los miembros del equipo es clave, ya que se busca eliminar las trabas habituales de reuniones, validaciones y revisiones formales por encuentros más informales y en fases tempranas e intermedias del proceso, y no sólo en la última etapa del trabajo. A continuación, se describe de forma breve tres metodologías ágiles que son bastante conocidas. •

Programación extrema (XP): Su creador es Kent Beck y se denomina extrema porque lleva a límites extremos algunos y elementos y actividades comunes de la forma tradicional de programar.

•

Scrum: Nace a principio de los años 90, está basado en el estudio de gestión de equipos desarrollado por Hirotaka Takeuchi e Ikujiro Nonaka en 1986. Este es uno de los métodos ágiles que más se utiliza y es aplicable a otros tipos de proyectos. Cuenta con una organización (Scrum Alliance) sin fines de lucros que se encarga de difundirlo.

•

Open Up: Es un proceso unificado ágil y liviano, que aplica un enfoque iterativo e incremental dentro de un ciclo de vida estructurado y contiene un conjunto mínimo de prácticas que ayuda al equipo a ser más efectivo desarrollando software. Es un modelo de desarrollo de software, es parte del Framework de modelo de proceso de Eclipse (Eclipse Process Framework), desarrollado por la fundación Eclipse.

•

KANBAN: Significa tablero visual, es un sistema de información que controla de modo armónico la fabricación de los productos necesarios en la cantidad y tiempo necesarios en cada uno de los procesos que tienen lugar tanto en el interior de la fábrica, como entre distintas empresas.

Estas metodologías, al igual que las tradicionales tienen sus desventajas, por lo que en conclusión existe cierta controversia con el uso de este tipo de metodologías, debido a que su promoción ha tendiendo a pasar por alto sus deficiencias, son las metodologías más recomendables para desarrollar software de pequeño y mediano tamaño en los que los requisitos pueden cambiar rápidamente a lo largo del proceso de desarrollo.

La Universidad Católica de Loja

25

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

Autoevaluación 2

Estimado estudiante, hemos finalizado el estudio de la presente unidad, por lo que se recomienda realizar la autoevaluación que se indica a continuación con el propósito de comprobar el conocimiento adquirido. Recuerde que al final de la guía se han incluido las soluciones a estas autoevaluaciones; sin embargo, deberá revisarlas sólo después de haber obtenido sus propias respuestas, lo que le permitirá saber si los temas están o no entendidos. Lea detenidamente cada una de las preguntas y seleccione la alternativa correcta según corresponda. 1.

2.

3.

4.

5.

26

En el modelo en Cascada, ¿En qué etapa se establecen los servicios, las restricciones y las metas del sistema? a.

Análisis y definición de requerimientos

b.

Diseño del sistema y del software

c.

Implementación y prueba de unidad

¿En qué modelo la siguiente fase no debe comenzar sino hasta que termine la fase previa? a.

Cascada

b.

Incremental

c.

Orientado a la reutilización

Diseñar una implementación inicial, exponer ésta al comentario del usuario y luego desarrollarla en sus diversas versiones hasta producir un sistema adecuado, se conoce como: a.

Cascada

b.

Incremental

c.

Orientado a la reutilización

Las actividades principales en el proceso de ingeniería de requerimientos son: a.

Especificación, análisis y diseño, Implementación y pruebas

b.

Análisis de componentes, Modificación y Diseño del sistema

c.

Estudio de factibilidad, Obtención y análisis, especificación y validación

Uno de los componentes que se puede utilizar en un proceso orientado a la reutilización es: a.

MVC

b.

Servicios web

c.

Sistemas remotos

MODALIDAD ABIERTA Y A DISTANCIA

PRIMER BIMESTRE

6.

7.

8.

9.

10.

Guía Didáctica: Fundamentos de Ingeniería de Software

En la etapa de Especificación del software, la actividad que verifica que los requerimientos sean realistas, coherentes y completos, se conoce como: a.

Pruebas unitarias

b.

Validación del software

c.

Validación de requerimientos

¿En qué actividad se establece la estructura global del sistema? a.

Diseño arquitectónico

b.

Diseño de interfaz

c.

Diseño de componentes

¿En qué actividad se diseñan las estructuras del sistema de datos? a.

Diseño de interfaz

b.

Diseño de componentes

c.

Diseño de la base datos

La etapa dónde las personas que desarrollan el sistema ponen a prueba los componentes que construye el sistema, se conoce como prueba de: a.

Desarrollo

b.

Sistema

c.

Aceptación

En el proceso de ingeniería de requerimientos, qué estrategia ayuda con la selección y validación de requerimientos del sistema: a.

Obtención

b.

Prototipo

c.

Taller

Terminada la autoevaluación verifique sus respuestas en el solucionario que se encuentra al final de la presente guía.

La Universidad Católica de Loja

27

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

UNIDAD 3. REPRESENTACIÓN DE MODELOS DE SOFTWARE CON UML En cada una de las etapas del desarrollo de software, es necesario desarrollar los diferentes modelos y para ello se requiere de un lenguaje común en el que todos los interesados del proyecto entiendan, validen y aporten en el desarrollo del software. Por este motivo en la presente unidad nos enfocaremos en el uso de UML como una alternativa para el desarrollo de los diferentes modelos en la construcción del software ya que UML es un lenguaje de modelado visual que sirve para visualizar, especificar, construir y documentar.

3.1. Importancia En proyectos que involucran a muchos participantes, con diferentes criterios técnicos y culturales, la precisión y claridad son factores críticos ya que la falta de comunicación aumenta rápidamente, por ello es necesario utilizar un lenguaje común que permita reducir esta barrera. Empiece revisando la introducción del capítulo Modelado del sistema del texto básico. Dónde se indican las diferentes perspectivas que se puede utilizar para desarrollar los diferentes modelos de desarrollo de software. Terminada la lectura, podemos acotar que para que una notación permita una comunicación exacta, debe contener una semántica bien definida, debe ser adecuada para representar un aspecto determinado de un sistema y debe ser bien comprendida entre los participantes del proyecto de tal manera que cuando una notación es usada por un gran número de participantes, hay poco espacio para la interpretación errónea y la ambigüedad (Bruegge y Dutoit, 2010). Antes de analizar los modelos desde el punto de vista de construcción de software, analice los diagramas más comunes que se pueden desarrollar con UML, y para ello se aconseja utilizar alguna herramienta UML para facilitar el desarrollo de los diagramas. Existe una gran cantidad de herramientas de modelado UML, tanto de pago como libres. Algunas son simples programas de dibujo, otras tienen capacidad para interpretar y validar el modelo, o generar código a partir de diagramas y viceversa. Algunas herramientas libres y/o gratuitas son específicas para crear diagramas UML, como es : ArgoUML (multiplataforma) o StarUML. También pueden servir las herramientas genéricas de creación de diagramas, como Dia (libre, multiplataforma) o Visio (Microsoft). En la tabla 4 se listan algunas herramientas que permiten modelado UML. Tabla 4. Herramientas para crear modelos UML Herramientas de acceso Libre StarUML Modelio UML Tool Dia BOUML GModeler TCM Umbrello Netbeans UML

28

Herramientas de Pago Enterprice architect ArgoULM Poseidon Oracle designer Power designer

MODALIDAD ABIERTA Y A DISTANCIA

PRIMER BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

El uso de la herramienta depende de las necesidades de modelado y de lo que realmente se desea desarrollar. Para iniciar podría utilizar StartUML la versión de prueba funciona muy bien en la mayoría de plataformas. Para continuar revise el Tema Lenguaje Unificado de Modelado (UML) del REA Ingeniería de Software I. Es importante que analice los conceptos y ejemplos que se indican ya que le permitirán entender de mejor manera el modelado de software. Terminada la lectura del REA está en capacidad de entender cada uno de los diagramas y qué información es lo que se puede representar a través de UML. Para profundizar en los diagramas UML podría leer el tema Modelo Objeto. Una Descripción de UML2 del REA Ingeniería de Software de la Universidad de Salamanca. Una vez analizado y comprendido UML, está en capacidad de asociar las notaciones con los modelos de desarrollo del software. Para ello vamos analizar los siguientes modelos: 1.

2.

3.

Modelos de contexto: a.

Diagramas de contexto

b.

Mapa de procesos

c.

Diagramas de actividad

Modelos de interacción: a.

Casos de uso

b.

Secuencia

Modelos estructurales: a.

4.

5.

Diagramas de clase

Modelos de comportamiento: a.

Dirigido por datos

b.

Dirigidos por un evento

Ingeniería dirigida por modelo a.

Arquitectura dirigida por modelo

3.2. Modelos de contexto Inicialmente cuando se realiza la Especificación del software, es necesario establecer las fronteras del sistema, esto permitirá determinar qué es lo que realmente cubre el desarrollo del software y qué es lo que no va se ha realizar. Revise el tema Modelos de contexto del texto básico. Observe detenidamente los ejemplos que se muestran en las figuras relacionadas con el caso que expone en el texto.

2 http://ocw.usal.es/ensenanzas-tecnicas/ingenieria-del-software La Universidad Católica de Loja

29

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

Una vez que revisado y analizado el tema, podemos acotar que éste tipo de modelado permite definir el alcance del sistema identificando las fronteras del sistema y determinar los procesos generales que se cubrirá con el desarrollo del software. El diagrama de contexto ayuda en la definición del alcance del sistema tal como se puede apreciar en la figura que representa “El contexto del MHC-PMS” del texto básico, y sirve de herramienta para que los analistas puedan interactuar con los interesados para definir qué componentes son los que se relacionan con el software a desarrollar. El nivel de detalle en éstos diagramas varía dependiendo de lo que se desea documentar, por ejemplo, se puede adicionar etiquetas que representan los flujos de información entre las diferentes entidades con las que tiene relación el sistema, tal como se muestra en la figura 5. SGA Entidad bancaria

Actualizar expediente Datos estudiante

Estudiante

Orden de pago

Documentos

Detalle del pago

Notifica el estado

SGT-UTPL Estadísitcas

Contabilidad

Factura Resolución

Parámetros para trámite

Secretaría MAD

Notifica sobre trámite

Profesor

Simbología

Flujo de datos

Sistema

Entidad externa

Figura 5. Ejemplo de un diagrama de contexto para el Sistema de Gestión de Trámites de la UTPL

Una vez establecidas las dependencias del sistema, lo primero que realizan los analistas es reconocer las actividades de forma general y determinar el o los procesos que se cubrirían con la construcción del software. Esto es precisamente lo que permite desarrollar el modelo de proceso. Observe la figura “Modelo del proceso de detención involuntaria” que se muestra en el texto básico, en el que claramente se establecen las actividades del proceso y la forma como se ejecutan. ACTIVIDAD RECOMENDADA

Imagine que le piden realizar el modelo de contexto para una tienda de venta de productos en línea, dónde cualquier cliente puede comprar mediante tarjeta de crédito. Elabore del diagrama de contexto y el mapa de proceso (alto nivel).

30

MODALIDAD ABIERTA Y A DISTANCIA

PRIMER BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

3.3. Modelos de interacción Otro de los modelos que requieren especial atención en el desarrollo del software son los modelos de interacción, ya que estos permiten definir las interacciones que va a tener el sistema con respecto otros sistemas y en si el usuario del sistema. Revise el tema Modelos de interacción del texto básico. Analice el nivel de detalle de las interacciones que contempla tanto el modelo de casos de uso como el diagrama de secuencia. Terminada la lectura de este apartado, es necesario recalcar sobre la importancia de la información que se dispone, dado que son modelos y diagramas que requieren de un nivel de detalle en cuanto a información. En lo referente a los diagramas de casos de uso son un tipo de diagrama de comportamiento que sirve para describir lo que debe hacer un sistema desde el punto de vista de quien lo va a utilizar (usuarios finales). Un modelo de casos de uso se construye mediante un proceso iterativo durante las reuniones entre los desarrolladores del sistema y los clientes conduciendo a una especificación de requisitos sobre la que todos coinciden. Cuando elabore casos de uso, considere que: •

Los casos de uso describen las interacciones más importantes con el sistema, no su funcionamiento interno.

•

Conviene mantener los casos de uso lo más simples posibles. Todos los implicados en el proyecto deben ser capaces de entender el diagrama de casos de uso. Si se complica demasiado, pierde su utilidad.

•

Hay que tener en cuenta que el diagrama de casos de uso se elabora durante la fase de especificación de requisitos y que éstos son cambiantes por naturaleza. Por ello no conviene ahondar demasiado en detalles ni descomponer cada caso en sub-casos, ya que si estos cambian habremos malgastado el tiempo.

En cualquier caso, es preferible acompañar al diagrama de una buena descripción narrativa del caso de uso, tal como se indica en la figura “Descripción tabular del caso de uso Transferencia de datos”, del texto básico. A continuación, se presenta un ejemplo de un diagrama de caso de uso a partir de una descripción. En la unidad 5 de la presente guía se presenta la estrategia para extraer los casos de uso a partir de las descripciones. La máquina de café Supongamos que se requiere desarrollar el control de una máquina de entrega de café automática. La máquina debe permitir a una persona introducir dinero, escoger uno de los productos de acuerdo a su precio, escoger un nivel de azúcar y entregar el producto y las vueltas. El usuario puede en cualquier momento antes de escoger el azúcar cancelar la operación, mediante un botón existente para este objetivo

En la figura 6, se define el diagrama de caso de uso para el ejemplo de la máquina de café. Existe un actor llamado Cliente y 5 casos de uso. Uno de ellos “Devolver dinero” como “include” con el objeto de reutilizar.

La Universidad Católica de Loja

31

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

Figura 6. Ejemplo de un diagrama de Casos de Uso para el sistema de la máquina de café

ACTIVIDAD RECOMENDADA

A continuación, se presentan dos casos, en los cuales debe elaborar el diagrama de casos de uso. Lea detenidamente cada caso e identifique el actor y luego los casos de uso de acuerdo a la interacción con el sistema. Caso 1: Tienda en Internet Queremos modelar el sistema de pago en una tienda web. El cliente debe identificarse mediante su dirección de correo. Si es un nuevo cliente se le debe registrar en el sistema previamente, pidiéndole los datos personales. Una vez identificado al cliente, éste podrá elegir el medio de pago: por transferencia bancaria o con tarjeta de crédito. Según el medio de pago se le solicitarán unos datos u otros. El cliente también deberá elegir el método de envío. Finalmente, se le mostrarán todos los datos del pedido para pedirle que confirme. Caso 2: Usuarios y administradores Queremos modelar un sistema en el que hay usuarios. Los usuarios pueden iniciar sesión, modificar su contraseña, recuperar su contraseña y cerrar sesión. Los administradores tienen los mismos permisos que los usuarios, pero, además pueden registrar usuarios e instalar programas. Continuando con los modelos de interacción tenemos el diagrama de secuencia que es un gráfico bidimensional donde el eje vertical representa el tiempo, el eje horizontal muestra objetos del sistema y la interacción entre los objetos se representa mediante flechas que van de unos objetos a otros, ordenadas cronológicamente de arriba abajo. Tal como se puede observar en los ejemplos del texto básico, en el apartado Diagramas de secuencia. Los diagramas de secuencia se utilizan cuando queremos expresar la relación entre objetos, enfatizando el orden en que lo hacen y qué tipo de mensajes se envían entre sí. Adicional a los ejemplos del texto básico a continuación se presentan un ejemplo

32

MODALIDAD ABIERTA Y A DISTANCIA

PRIMER BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

Llamada telefónica El siguiente ejemplo modela un sistema de propaganda telefónica. Consiste en una máquina que va llamando a números de teléfono. Cuando el abonado descuelga, una voz robotizada lee la propaganda y, después, cuelga.

En la figura 7 se muestra el diagrama de secuencia para el caso de la llamada telefónica, se define el vendedor, la empresa telefónica y abonado. Se identifica la secuencia de métodos que se ejecutan.

Figura 7. Ejemplo de un diagrama de secuencia para el caso de la llamada telefónica

En conclusión, los modelos de interacción como su nombre lo indica permiten describir la interacción del usuario con los elementos del sistema, esto permitirá sin duda, determinar tanto requisitos funcionales y no funcionales, que los analizaremos en la siguiente unidad.

3.4. Modelos estructurales El modelo estructural permite describir las relaciones estáticas existentes entre los diferentes objetos de un sistema. Así como un arquitecto desarrolla los planos de un edificio antes de su construcción, a la hora de desarrollar software, debemos modelar correctamente el sistema previamente al desarrollo. La principal forma de emplear el modelado estructural es mediante los diagramas de clase. Una clase es una descripción de un conjunto de objetos con las mismas propiedades (atributos) y el mismo comportamiento (operaciones). Revise el tema Modelos estructurales del texto básico y analice detenidamente los ejemplos del diagrama de clases con sus respectivos conceptos. Una vez terminada la lectura posiblemente le resulte conocidos los conceptos relacionados con el modelo de clases, ya que la aprendido en programación orientada a objetos (POO) no difiere al momento de crear los diagramas utilizando UML. Adicional a los ejemplos que indican en el texto básico, en la figura 8, se presenta un ejemplo que recoge conceptos relacionados con el modelado como es: generalización, interfaces y clase abstracta. La Universidad Católica de Loja

33

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

Figura 8. Ejemplo de un diagrama de clases

3.5. Modelos de comportamiento Estos modelos se utilizan para describir el comportamiento del sistema en su totalidad. Entre los modelos de comportamiento existentes se distinguen dos: los modelos dirigidos por datos y los modelos dirigidos por eventos. Revise el tema Modelos de comportamiento del texto básico. Analice y determine la diferencia entre el modelado dirigido por datos y dirigido por eventos. Finalizada la lectura, se puede determinar que para el modelado dirigido por datos es necesario el uso de los diagramas de actividad, en el que se representan las actividades y los objetos. Alternativamente se pueden utilizar diagramas de secuencia cuyos mensajes sólo se envían de izquierda a derecha para representar el procesamiento secuencial de los datos en el sistema. En cuanto al modelado dirigido por eventos, podemos acotar que es un comportamiento dinámico y que está determinado por situaciones que ocurren interna o externamente. Es fundamental el concepto de evento, que es la especificación de un acontecimiento significativo, ubicado en el tiempo y en el espacio. Para más de talles de éste tipo de modelado y profundizar en el concepto de evento, le sugiero revisar el documento desarrollado por Francisco Ruiz, profesor de la universidad de Cantabria y que se encuentra de forma libre en la web. La dirección es: https://www.ctr.unican.es/ asignaturas/Is1/is1-t12-trans.pdf. Para finalizar el presente tema, pongo a consideración el siguiente ejemplo.

34

MODALIDAD ABIERTA Y A DISTANCIA

PRIMER BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

Ejemplo: máquina de café En la figura 9, se muestra el diagrama de actividad que modela las acciones básicas de una máquina capaz de servir cafés, capuchinos y cortados, e ilustra los elementos principales del diagrama de actividad: acciones, ramificaciones y sincronización: Primero se selecciona la bebida y se recibe el pago. Entonces se inician 3 acciones concurrentemente (barra de sincronización): •

Visualizar “Sirviendo café” en la pantalla de la máquina

•

Servir café, capuchino o cortado en función de la selección (rombo de ramificación). Las condiciones se representan en las flechas que salen del rombo, se ponen entre corchetes [ ] y en UML se denominan condiciones de guarda. El rombo de más abajo sirve para reagrupar las ramificaciones.

•

Devolver el cambio.

La barra de sincronización donde concurren las acciones de visualizar, servir bebida y devolver cambio significa que todas las acciones deben acabar antes de continuar con la siguiente (visualizar “Recoja su café”).

Figura 9. Diagrama de actividad. Máquina de café. Fuente: Martín, J., y López L. (2014)

La Universidad Católica de Loja

35

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

Autoevaluación 3

Estimado estudiante, hemos finalizado el estudio de la presente unidad, por lo que se recomienda realizar la autoevaluación que se indica a continuación con el propósito de comprobar el conocimiento adquirido. Recuerde que al final de la guía se han incluido las soluciones a estas autoevaluaciones; sin embargo, deberá revisarlas sólo después de haber obtenido sus propias respuestas, lo que le permitirá saber si los temas están o no entendidos. Lea detenidamente cada una de las preguntas y seleccione la alternativa correcta según corresponda 1.

2.

3.

4.

5.

6.

36

Los modelos que permiten representar el sistema existente en la etapa de ingeniería de requerimientos, permite: a.

Aclarar lo que hace el sistema existente

b.

Ayudar a explicar el sistema propuesto

c.

Determinar los requerimientos

En el modelado, una perspectiva externa consiste en modelar: a.

La interacción del sistema

b.

El contexto o entorno del sistema

c.

La organización de un sistema

En el modelado, una perspectiva estructural consiste en modelar: a.

La interacción del sistema

b.

El contexto o entorno del sistema

c.

La organización de un sistema

Cuando se desea adicionar detalle a los requerimientos de usuario, es conveniente desarrollar: a.

Casos de uso

b.

Diagrama de contexto

c.

Políticas de negocio

Un mapa de procesos permite mostrar: a.

El tipo de información y productos que se intercambian entre clientes externos

b.

Una secuencia de pasos, entradas y salidas necesarias para manejar un proceso de negocio

c.

El sistema en su entorno

Un modelo de caso de uso, es considerado un modelo de: a.

Contexto

b.

Interacción

c.

Estructural

MODALIDAD ABIERTA Y A DISTANCIA

PRIMER BIMESTRE

7.

8.

9.

10.

Guía Didáctica: Fundamentos de Ingeniería de Software

El diagrama que permite modelar interacciones entre componentes del sistema, aunque también pueden incluirse agentes externos, se conoce como: a.

Secuencia

b.

Casos de uso

c.

Contexto

El diagrama de clase es considerado un modelo: a.

Contexto

b.

Interacción

c.

Estructural

¿Qué concepto representa el siguiente diagrama UML?

a.

Agregación

b.

Composición

c.

Generalización

Los diagramas de actividad, son un tipo de modelo de: a.

Comportamiento

b.

Interacción

c.

Contexto

Terminada la autoevaluación verifique sus respuestas en el solucionario que se encuentra al final de la presente guía.

La Universidad Católica de Loja

37

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

UNIDAD 4. REQUERIMIENTOS Una vez conocidos los conceptos preliminares de la Ingeniería de software y la importancia del modelado de desarrollo del software, empezamos a partir de esta unidad hasta el final de la guía a describir las actividades del proceso de desarrollo de software. El objetivo de la presente unidad es la especificación de requerimientos de software, mediante un proceso formal conocido como Ingeniería de Requerimientos, cuyas actividades consisten en obtener información, luego analizarla con la ayuda de modelos y finalmente especificar los requerimientos clasificados en funcionales y no funcionales.

4.1. Requerimientos funcionales y no funcionales A la hora de construir software, pocos son realmente aquellos proyectos que culminan con éxito, es decir aquellos que terminan dentro del plazo establecido, con el presupuesto asignado y sobre todo con los requisitos especificados. Una buena parte de proyectos fracasados radica en los problemas que se tiene a la hora de definir los requerimientos de sistema, especialmente cuando los proyectos son complejos. Entre los problemas más comunes que se tiene a la hora de construir software, desde el contexto del usuario, tenemos: •

No saben lo que quieren

•

Un sistema cuenta con muchos usuarios y ninguno tiene una visión de conjunto

•

No saben cómo hacer más eficiente la operación en su conjunto

•

No saben qué partes de su trabajo pueden transformarse en software

•

No saben detallar lo que saben de forma precisa

Se requiere que los requerimientos sean definidos apropiadamente y no contengan errores. No detectar estos errores incrementará los costes (tiempo, dinero) de forma exponencial. En la figura 10 se puede observar cómo los errores que se generan en la etapa de especificación de requerimientos se extienden y afecta las demás etapas del desarrollo de software.

Figura 10. Acumulación de errores. Fuente: Braude y Bernstein (2016)

38

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

Ante esta situación surge la Ingeniería de Requisitos (IR), que trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora de forma sistemática y repetible. Empecemos la unidad revisando la Introducción del capítulo Ingeniería de Requerimientos y luego el tema Requerimientos funcionales y no funcionales del texto básico. Analice detenidamente la figura para diferenciar entre requerimientos de usuario y requerimientos de sistema. Finalizada la lectura, podemos acotar que los requerimientos de usuario son más generales mientras que los requerimientos del sistema son más específicos. Pongamos como ejemplo el caso del “Sistema de gestión académica de la UTPL (SGA-UTPL)”, desde el punto de vista del Estudiante tenemos los requerimientos que se indican en la tabla 5. Tabla 5. Ejemplos de requerimientos de usuario y sistema Requerimientos de usuario

Requerimientos de sistema

1. El SGA-UTPL permitirá al estudiante consultar su expediente académico a través del dispositivo móvil previo método de autentificación.

2. El sistema debe solicitar al estudiante un usuario y una clave para autenticar su ingreso. 3. El sistema genera un reporte con todas las asignaturas que el estudiante se ha matriculado, no se consideran las asignaturas actuales que aún está cursando. 4. El estudiante dispondrá de la posibilidad de descargar el expediente académico en un formato de archivo PDF.

5. El SGA-UTPL permitirá al estudiante realizar su matrícula de acuerdo a la oferta académica y a la disponibilidad de cupos y paralelos en cada uno de los componentes académicos

6. El sistema permitirá al estudiante escoger las asignaturas ofertadas. 7. El sistema permitirá escoger el horario y paralelo por cada asignatura ofertada. 8. El sistema deberá informar al estudiante sobre la restricción para cursar alguna asignatura. 9. El sistema no mostrará las asignaturas que el estudiante ya tiene aprobadas. 10. El sistema deberá informar la cantidad de créditos en los cuales el estudiante se está matriculando.

Como se puede observar, son definiciones en lenguaje natural que se atribuye a necesidades puntuales desde el punto de vista del estudiante y lo que esto conlleva a definir especificaciones más concretas llamados requerimientos de sistema que es algo más específico y más cercano de lo que se diseñará. Tal como se indica en el texto básico, con frecuencia los requerimientos del sistema se clasifican como requerimientos funcionales y no funcionales. Los requerimientos funcionales expresan la naturaleza del funcionamiento del sistema, mientras que los requerimientos no funcionales expresan restricciones sobre el espacio de posibles soluciones. En concreto los requerimientos funcionales definen “qué debe” hacer el sistema, en cambio que los requerimientos no funcionales definen “cómo debe” ser el sistema. La distinción entre requerimientos funcionales y no funcionales no siempre resulta evidente. Por ejemplo, Podríamos decir que en un principio la seguridad se puede interpretar como un requerimiento no funcional, no obstante, su elaboración puede conducir a nuevos La Universidad Católica de Loja

39

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

requerimientos funcionales, como es, la necesidad de autenticar a los usuarios del sistema. Por lo tanto, más allá de si decidimos incluir este tipo de requisitos en una u otra sección, lo importante es identificarlos correctamente. Para complementar el estudio revise el tema Requisitos, del REA Ingeniería de Software I, dónde se analizan los requisitos funcionales y no funcionales, así como el proceso para especificar requisitos.

4.2. El documento de requerimientos de software La especificación de requerimientos, requiere que cada requisito sea debidamente documentado y para ello existen plantillas que han sido desarrolladas de acuerdo al modelo o metodología, siempre basados en un estándar. Revise el tema El documento de requerimientos de software del texto básico. Analice la figura dónde se indican los apartados que debería tener el documento. Dependiendo de la forma que se desee documentar los requisitos, existen plantillas para documentar requisitos de usuario y otra plantilla para los requisitos de software, pero para ciertos casos se puede utilizar una misma plantilla. La mayoría de plantillas para documentar la especificación de requisitos de software (ERS), se basan en el estándar IEEE-830. En el anexo 1, se presenta una de las múltiples plantillas para documentar requerimientos de software. Especificación de requisitos. Puede consultar en la web, ejemplos de especificación de requerimientos de software que utilizan diferentes plantillas, algunas con sugerencias de ciertas metodologías. Tomando como referencia la plantilla que se indica en el anexo 1, la especificación de requisitos consiste en escribir los requisitos de forma coherente, clara y concisa, considerando una serie de atributos. Para conocer sobre la forma de escribir los requerimientos revise el tema Especificación de requerimientos del texto básico. Ponga atención a la figura donde se indican las formas de escribir una especificación de requisitos de sistema. Finalizada la lectura, podemos acotar que la “mejor forma” de escribir requisitos no existe. Lo más utilizado es el lenguaje natural. Cada requisito expresado en una frase corta (“el sistema hará́ ...”, “el usuario deberá…”, etc.) o lenguaje natural complementado con diagramas y/o notaciones formales, que depende de quien lee o quien escribe los requisitos. En el documento de la ERS en la sección que corresponde se debe escribir los requisitos a un nivel de detalle suficiente como para permitir a los diseñadores diseñar un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo requisito aquí especificado describirá comportamientos externos del sistema, perceptibles por parte de los usuarios, operadores y otros sistemas. Esta es la sección más larga e importante de la ERS. Deberán aplicarse los siguientes principios (Raval y Rathod 2013):

40

•

El documento debería ser perfectamente legible por personas de muy distintas formaciones e intereses.

•

Deberán referenciarse aquellos documentos relevantes que poseen alguna influencia sobre los requisitos.

MODALIDAD ABIERTA Y A DISTANCIA

PRIMER BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

•

Todo requisito deberá ser unívocamente identificable mediante algún código o sistema de numeración adecuado.

•

Lo ideal, aunque en la práctica no siempre realizable, es que los requisitos posean las siguientes características: Corrección, no ambiguos, completos, consistentes, clasificados, verificables, modificables y trazables.

4.3. Proceso de ingeniería de requerimientos Para definir requerimientos se debe seguir un proceso que permita cada vez ir obteniendo la mayor cantidad de información que contribuyan a la definición de los requerimientos. Revise el tema Procesos de ingeniería de requerimientos del texto básico. Analice detenidamente la figura de la vista en espiral, dónde se indica cómo el proceso de ingeniería de requisitos permite llegar a especificar los requisitos de sistema. Finalizada la lectura podemos considerar que el proceso de ingeniería de requerimientos consiste en el desarrollo de un conjunto de actividades que se desarrollan de forma iterativa y que están estrechamente relacionadas. Estas actividades dependen del proceso y metodología escogido para el desarrollo del proyecto. El autor del texto básico sugiere las siguientes: •

•

Adquisición y análisis de requerimientos 1.

Descubrimiento de requerimientos

2.

Clasificación y organización de requerimientos

3.

Priorización y negociación de requerimientos

4.

Especificación de requerimientos

Validación de requerimientos

A continuación, vamos a estudiar y analizar cada una de estas actividades.

4.4. Adquisición y análisis de requerimientos Desde el punto de vista de la IR, la adquisición u obtención permite en recopilar a través de diferentes estrategias las necesidades de parte de los interesados. El análisis consiste en utilizar apropiadamente las técnicas que permitan representar la información recopilada, para que a su vez pueda ser revisada y validada para continuar con la especificación. Revise el tema Adquisición y análisis de requerimientos del texto básico. Ponga especial interés en la figura dónde se indican las actividades que considera este autor para la adquisición y análisis de requerimientos. Terminada la lectura, identificamos claramente las actividades que se relacionan a la obtención de información y las que se relacionan con el análisis de esa información. Es importante aclarar que otros autores no apegados a una metodología en particular sugieren actividades estándares que consiste en: obtención, análisis, especificación y validación. Mientras que las actividades de gestión están relacionadas con la gestión del cambio de los requerimientos (Gottesdiener 2005).

La Universidad Católica de Loja

41

Guía Didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

El descubrimiento de información consiste en recopilar información, para lo cual pueden existir varias fuentes, como es: las personas (que se las conoce como interesados), la documentación existente o información externa a la organización (regulaciones gubernamentales, entre otras). Es función del analista establecer la mejor estrategia para recopilar información. Entre las estrategias más comunes tenemos: •

Entrevista

•

Observación directa

•

Cuestionario

•

Talleres

•

Análisis de la documentación, entre otros.

Con la información recopilada se realiza el análisis, y para ello se utilizan estrategias de modelado que ayudan a entender los procesos de la organización. Entre las estrategias de análisis más comunes tenemos: •

Diagrama de contexto

•

Mapa de proceso

•

Escenarios

•

Casos de uso

•

Prototipos, entre otros.

Tanto las técnicas de obtención, como los modelos de análisis se utilizan cuantas veces sea necesario conforme se descubra la información.

4.5. Validación de requerimientos Es necesario realizar la validación de los requerimientos previamente antes de comenzar con el desarrollo del software. Por lo tanto, los documentos de requisitos están sujetos a procedimientos de validación y verificación. Los requisitos pueden ser validados para asegurar que el ingeniero de software haya entendido los requisitos. También es importante verificar que un documento de requisitos se ajusta a los estándares de la compañía y que es comprensible, consistente y completo. Revise el literal Validación de requerimientos, del texto básico. Analice detenidamente las comprobaciones que deben realizarse al documento de requerimientos. Finalizada la lectura podemos acotar que diferentes interesados que incluyen a representantes del cliente y desarrollador deben revisar el o los documentos de requerimientos. Lo normal es programar el momento adecuado para validar los requisitos, con el fin de cumplir con el objetivo de detectar cualquier problema antes de que los recursos se comprometan a desarrollar los requisitos. La validación de requisitos se refiere al proceso de examinar el documento de requisitos para asegurarse de que define el software adecuado (es decir, el software que los usuarios esperan).

42

MODALIDAD ABIERTA Y A DISTANCIA

PRIMER BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

Autoevaluación 4

Estimado estudiante, hemos finalizado el estudio de la presente unidad, por lo que se recomienda realizar la autoevaluación que se indica a continuación con el propósito de comprobar el conocimiento adquirido. Recuerde que al final de la guía se han incluido las soluciones a estas autoevaluaciones; sin embargo, deberá revisarlas sólo después de haber obtenido sus propias respuestas, lo que le permitirá saber si los temas están o no entendidos. Lea detenidamente cada una de las preguntas y seleccione la alternativa correcta según corresponda 1.

2.

3.

4.

5.

Cuando se han definido requisitos que no reflejan las necesidades reales de los clientes, se debe a: a.

Documentos mal redactados

b.

La metodología de desarrollo no es la apropiada

c.

No se ha recolectado la información necesaria

Cuando el equipo de desarrollo se asegura que el software satisface los requisitos especificados, se conoce como: a.

Validación

b.

Verificación

c.

Requerimiento

Los requerimientos no funcionales se los puede clasificar en: a.

Usuario y sistema

b.

Producto y organización

c.

Producto, organización y externos

A las especificaciones de los servicios y restricciones que el sistema debe considerar, se conoce como requerimiento: a.

Funcional de usuario

b.

Funcional de sistema

c.

No funcionales

Aquellos requerimientos que especifican o restringen el comportamiento del software, se conocen como requerimientos de: a.

Producto

b.

Organización

c.

Externos

La Universidad Católica de Loja

43

Guía Didáctica: Fundamentos de Ingeniería de Software

6.

7.

8.

9.

10.

PRIMER BIMESTRE

El enunciado “El sistema debe ser capaz de operar adecuadamente con hasta 100.000 usuarios con sesiones concurrentes”, es un ejemplo de requerimiento de: a.

Producto

b.

Organización

c.

Externos

La prueba de software se gestionará con la ayuda de una herramienta de testing. Este caso se considera un requerimiento de: a.

Producto

b.

Organización

c.

Externos

Las páginas web a ser desarrolladas deben cumplir con la ley de tratamiento en condiciones de igualdad para personas con discapacidad, es un caso de requerimiento: a.

Producto

b.

Organización

c.

Externos

Al proceso de interactuar con el sistema, se conoce como: a.

Descubrimiento de requerimientos

b.

Priorización de requerimientos

c.

Clasificación de requerimientos

La técnica de validación de requerimientos, que permite mostrar un modelo ejecutable del sistema en cuestión a los usuarios finales y clientes, se conoce como: a.

Revisión de requerimientos

b.

Creación de prototipos

c.

Generación de casos de prueba

Terminada la autoevaluación verifique sus respuestas en el solucionario que se encuentra al final de la presente guía.

44

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE UNIDAD 5. ANÁLISIS Una vez identificados y validados los requerimientos del sistema, se abordará el problema de cómo crear modelos para describir el dominio de la aplicación, utilizando un enfoque orientado a objetos, en este se especifica el comportamiento del sistema y las formas de interacción con los usuarios. Para ello se trabajará con el texto indicado en la bibliografía complementaria Object Oriented Software Engineering, Bruegge, B. y Dutoit, H. (2010). En la figura 11, se muestra una vista general del proceso, el cual tiene como punto de partida la captura de requerimientos y con ello se desarrollan las actividades que especifican los requerimientos funcionales y el modelo funcional; estas descripciones sustentan el modelo de análisis, el cual incluye dos componentes esenciales que son: el modelo dinámico y el modelo de objetos del análisis.

Figura 11. Actividades de análisis. Fuente Bruegge, B., y Dutoit, A. (2010)

La Universidad Católica de Loja

45

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

El modelo de análisis está conformado por tres modelos individuales, cada uno de los cuales refleja aspectos diferentes del sistema, que serán usados posteriormente en la etapa de diseño. Estos modelos son: •

El Modelo funcional, que comprende los casos de uso y escenarios.

•

El Modelo de objetos del análisis, representado por los diagramas de clases y objetos.

•

El Modelo dinámico, representado por la máquina de estados y los diagramas de secuencia

Estimado estudiante, se le recuerda que si no comprende alguno de estos conceptos, tales como casos de uso, clases, objetos, máquinas de estados, etc. debe revisar nuevamente la unidad 3 de la guía didáctica o revisar bibliografía complementaria en formato PDF como https://www.utdallas.edu/~chung/Fujitsu/UML_2.0/Rumbaugh--UML_2.0_Reference_CD.pdf , de los autores Rumbaugh, Jacobson, y Booch (2005), donde se explica claramente el esquema y funcionamiento de UML.

5.1. Conceptos básicos Para comprender el modelo de análisis, es necesario revisar algunos conceptos que configuran su estructura y funcionamiento. 5.1.1.  Modelo de objetos del análisis. Hace énfasis en la representación del sistema que se construirá desde el punto de vista del usuario, el modelo de objetos del análisis representa los conceptos individuales que son manipulados por el sistema incluyendo las relaciones con otros objetos. Los objetos del análisis representan mediante diagramas UML los conceptos que son visibles para el usuario, entre ellos se tiene: clases, atributos y operaciones. En la figura 12. se muestran dos conceptos referidos a un dominio de una biblioteca, en ellos tenemos la clase Libro, asociada a la clase Autor, cada una con sus respectivos atributos y operaciones.

Libro -titulo -subtitulo -anio_edicion -editorial +actualizarFicha() +buscar()

*

*

Autor -apellido -nombre

Figura 12. Ejemplo de diagrama UML

5.1.2.  Modelo dinámico Es un modelo que se enfoca en modelar el comportamiento del sistema; su representación es a través de diagramas de secuencia, los cuales muestran las interacciones entre un grupo de objetos durante una ejecución particular de un caso de uso y, por otro lado, tenemos las máquinas de estados que se usan para representan el comportamiento de un objeto particular.

46

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

El modelo dinámico sirve para asignar responsabilidades a clases individuales y, durante el proceso, para identificar nuevas clases, asociaciones, y atributos que deberán añadirse al modelo de objetos del análisis. No olvide que estos modelos representan conceptos a nivel de usuario, no son componentes reales del software, por tanto, no se debe incluir clases relacionadas con bases de datos, subsistemas, gestor de sesiones, red; sin embargo, estas deben verse como abstracciones de alto nivel de aquellas que se usarán posteriormente en el diseño. 5.1.3.  Objetos entidad, frontera y control De acuerdo a Rumbaugh, Jacobson, y Booch (2005), el modelo de análisis es en una abstracción de clases o subsistemas del diseño, la cual cumple con las siguientes características: •

Las clases del análisis se enfocan en la representación de los requerimientos funcionales; los no funcionales se consideran como requerimientos especiales y no se tienen en cuenta hasta el diseño e implementación del sistema. Por tanto, estas clases son más conceptuales, es decir son más evidentes en del dominio del problema.

•

No es usual que las clases del análisis ofrezcan una interface en término de operaciones, pero su comportamiento se define mediante la asignación de responsabilidades expresadas a alto nivel y de manera menos formal.

•

En lo referente a los atributos, estas clases definen aspectos más conceptuales y son reconocibles en el dominio del problema, a diferencia de las clases del diseño, en las cuales su especificación es cercana a lo que se representa en los lenguajes de programación.

Además, establece que las clases del análisis siempre encajan en uno de tres estereotipos, que se especifican a continuación: •

Objetos entidad, se utilizan para modelar información cuyo tiempo de vida es extenso y por lo general es persistente, estas clases se usan para modelar información o un concepto del mundo real, sobre el cual el sistema necesita dar seguimiento.

•

Objetos interface, se usan para modelar la interacción entre el sistema y los actores. Esta interacción a menudo implica recibir, presentar información y peticiones desde y hacia los usuarios y los sistemas externos. Los objetos interface usualmente representan abstracciones de: ventanas, formularios, paneles, interfaces de comunicaciones, interfaces de impresoras, sensores, terminales, y API. No obstante, estas clases deben mantenerse a un nivel conceptual, es decir, se especifica lo que se obtiene con la interacción, sin decir cómo se ejecuta físicamente.

•

Objetos de control, representan coordinación, secuencia, transacciones y control de objetos, se usan para encapsular el control de un caso de uso en concreto; también se incluye la representación de derivaciones y cálculos complejos tales como la lógica del negocio, que no puede asociarse con ninguna información concreta de larga duración, almacenada por el sistema.

Para modelar los aspectos dinámicos del sistema, se usan clases de control, debido a su capacidad para gestionar las acciones y los flujos de control principales, y asignando tareas a los objetos entidad e interface.

La Universidad Católica de Loja

47

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

La notación UML para estos tres tipos de objetos, ofrece dos posibilidades, las cuales se muestran en la figura 13. Alternativa 1:

Cuenta

Interfaz Del cajero

Retirada De efectivo

Alternativa 2:



Cuenta

Interfaz del cajero

Retirada de efectivo

Figura 13. Estereotipos para representar objetos entidad, control e interface. Fuente: Rumbaugh, J., Jacobson, y I., Booch, G., (2005).

Note que los nombres de los estereotipos en la alternativa 2, se han colocado en idioma inglés, debido a que es el nombre estándar de los mismos. Para ilustrar estos conceptos, analice el ejercicio siguiente, el cual, por simplicidad, se referirá a un elemento muy conocido en el mundo real, evitando la necesidad de hacer un proceso de especificación muy detallado. Se trata de modelar el funcionamiento de un cajero automático (ATM), que es un dispositivo (sistema) que permite a los clientes de un banco realizar varios tipos de transacciones como: retirar fondos, transferir fondos, pagar servicios básicos, consultar saldos. Para ello el sistema cuenta con un lector de tarjetas, que una vez insertada por parte del cliente, activa una consola que solicita el ingreso de la contraseña y la operación que desea realizar, con esta información el sistema se conecta al sistema de cuentas del banco y si la transacción es permitida con los datos dados, informa al ATM que la operación se puede ejecutar y lo habilita para continuar con el proceso. En base al enunciado, identifique los objetos que forman parte de este sistema y catalóguelos como entidad, control e interface. Antes de revisar los resultados, tómese unos minutos para analizar el planteamiento, luego elabore una lista de objetos que logra identificar y clasifíquelos de acuerdo a los estereotipos indicados, finalmente, represéntelos gráficamente utilizando ambas alternativas de representación. Si ya terminó de resolverlo, revise la siguiente solución figura 14. 1.

Lista de objetos identificados: Cliente, cuenta, transacción, consola, impresora, lector de tarjeta, tarjeta, servicio básico, caja.

2.

Clasificación: Teniendo en cuenta las definiciones estudiadas, se puede clasificar a los objetos de la siguiente manera: Entidad: cliente, cuenta, tarjeta, servicio básico. Interface: impresora, consola, caja Control: transacción.

48

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

3.

Representación utilizando …. Alternativa 1



cliente

impresora

transacción



cuenta

consola



tarjeta

caja

Servicio_basico

Alternativa 2

cliente

cuenta

impresora

transacción

consola

tarjeta caja Servicio_basico

Figura 14. Representación de objetos entidad, interface y control utilizando dos notaciones alternativas.

5.1.4.  Generalización y especialización Por definición, la relación de herencia, permite organizar conceptos en jerarquías, el elemento en la parte superior de la jerarquía es el concepto más general y el elemento al final de la jerarquía es el más especializado, y entre los cuales, puede haber varios niveles intermedios. Por ejemplo, si se considera en el ejercicio anterior a la clase transacción, puede referirse con ella, a todos los tipos de transacciones permitidas en el sistema del cajero, como retirar dinero, pagar servicios básicos, transferir fondos; y cuando nos referimos a retirar dinero, corresponde a la transacción de obtener dinero del cajero. La herencia puede tener origen en dos enfoques, el primero se conoce como generalización, que identifica conceptos abstractos, partiendo de conceptos de bajo nivel. Por ejemplo, considere el caso de las operaciones para un sistema bancario, en el que se identifica que se realizan diferentes operaciones como depósitos, retiros, transferencias, pagos; y reconoce algunas características comunes entre estas operaciones como: fecha, cuenta, monto, etc. Podría abstraer una clase denominada Transacción, la cual describirá todas las características comunes entre las clases indicadas. Por otro lado, la especialización es una actividad de modelado que partiendo de conceptos generales o de alto nivel, identifica conceptos más específicos en la subclase. Retomando nuestro ejemplo para la clase transacción, se puede identificar de manera específica a la transacción “pagar servicios básicos”, La Universidad Católica de Loja

49

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

que realiza un movimiento entre cuentas, que por lado debita un valor de la cuenta, y lo acredita al pago por servicios básicos. Esta transacción se diferencia de otras transacciones que también hacen movimiento de dinero, porque tiene un comportamiento diferente. En la figura 15, se muestra un ejemplo de una jerarquía de clases, obtenida a partir de la clase transacción, en ella se evidencian los diferentes tipos de transacciones que puede atender el cajero automático, observe que el criterio para obtener las subclases o clases hijas puede variar en función de los atributos en común y el propósito del sistema. Transacción

Efectivo

Retiro ahorro

Avance efectivo

Electrónica

Retiro corriente

Cuentas propias

Transferencia

Servicios Básicos

Cuentas internas

Otros bancos

Compras

Figura 15: Ejemplo de una jerarquía de herencia para la clase transacción.

5.2. Actividades del análisis Una vez que ha revisado algunos de los conceptos más importantes de la etapa de análisis, vamos a explicar las actividades que permitirán transformar los casos de uso y escenarios en un modelo de análisis. Según Bruegge, y Dutoit, A. (2010), las actividades del análisis son las siguientes: •

Identificar objetos entidad

•

Identificar objetos interfaz

•

Identificar objetos de control

•

Mapear casos de uso a objetos mediante diagramas de secuencia.

•

Modelar interacciones entre objetos, mediante tarjetas CRC

•

Identificar asociaciones

•

Identificar agregaciones

•

Identificar atributos

•

Modelar el comportamiento dependiente del estado de objetos individuales.

•

Modelar relaciones de herencia.

•

Revisar el modelo de análisis.

Dada la complejidad que podría asociarse a cada una de estas actividades, utilizaremos un ejemplo que permita ilustrar el proceso, y nos servirá a lo largo de las Unidades 5,6 y 7 de la presente guía. El presente ejemplo corresponde a un Sistema de reporte de emergencias y la asignación de recursos correspondientes, por ende, se inicia con una especificación del caso de estudio. Este ejemplo es tomado de Bruegge y Dutoit (2010), y se ha traducido al español para facilitar su comprensión y, para

50

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

nominar actores, casos de uso y relaciones, se ha convenido no usar espacios e incorporar mayúsculas para distinguir entre palabras tal como indican los lineamientos dados por Bruegge y Dutoit, (2010). Por ejemplo, para el actor Oficial de Campo se utiliza OficialdeCampo. A continuación, se describe el sistema: AMIGO, un sistema de información distribuido utilizado para la gestión de accidentes de tránsito, incluye actores, como OficialdeCampo, que representa a la policía y a los oficiales de bomberos, quienes responden a un incidente, y Despachador, que es el oficial de policía responsable de contestar las llamadas al 911 y enviar recursos para atender un incidente reportado. El sistema AMIGO apoya a ambos actores al hacer un seguimiento de incidentes, recursos y planes de tareas. También tiene acceso a múltiples bases de datos, como una base de datos de materiales peligrosos y procedimientos para operaciones de emergencia. Los agentes OficialdeCampo y Despachador operan a través de diferentes interfaces: OficialdeCampo, accede a AMIGO a través de un asistente personal móvil, Despachador accede a través de una estación de trabajo. En la tabla 6 se incluye un escenario para el caso planteado. En el texto básico, apartado 4.5.3 Escenarios, encontrará información adicional acerca de lo que son y cómo se describen. En resumen, un escenario es una descripción narrativa y paso a paso de una secuencia de eventos que se dan en una ejecución particular del sistema que se está modelando. La ventaja que tiene la descripción del escenario es que permite a los analistas describir una situación real, y revisarla con usuarios y clientes. Estos escenarios se usan además como base para plantear los casos de uso. Para el caso planteado luego de analizar varios escenarios, se puede abstraer un caso de uso denominado ReportarEmergencia, el mismo que debería contener un flujo de eventos para reportar diferentes tipos de incidentes. Tabla 6. Escenario incendio en bodega para el sistema AMIGO. Nombre escenario:

IncendioenBodega

Actores participantes:

bob, alice: OficialdeCampo

Flujo de eventos:

1. Bob, conduciendo a través de la vía principal en su patrullero, observa humo proveniente de una bodega. Su compañera, Alice, activa la función ”ReportarEmergencia” en su laptop del sistema FRIEND 2. Alice ingresa la dirección del edificio, una breve descripción de su ubicación (Ej. Esquina noroeste), y un nivel de emergencia. Además de una unidad de incendios, solicita algunos paramédicos en la escena, dado que el área está relativamente ocupada. Ella confirma sus entradas y espera confirmación 3. John, el Despachador, es alertado sobre la emergencia mediante un beep en su terminal. El revisa la información enviada por Alice y confirma el reporte. Luego asigna una unidad de incendios y dos unidades de paramédicos al lugar del Incidente además del tiempo estimado de arribo (TEA) a Alice. 4. Alice recibe la confirmación y el TEA

Fuente: Adaptado de Bruegge, B., y Dutoit, A. (2010)

A continuación, en base al escenario descrito, en la tabla 6, se describe el caso de uso ReportarEmergencia, el cual, debe servir para reportar todos los tipos de incidentes del sistema AMIGO

La Universidad Católica de Loja

51

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Tabla 7. Especificación de caso de uso ReportarEmergencia, sistema AMIGO Nombre escenario:

ReportarEmergencia

Condición de entrada:

1. El OficialdeCampo, activa la función “ReportarEmergencia” en su terminal.

Flujo de eventos:

2. AMIGO responde presentando al oficial un formulario de datos. El formulario incluye un menú para el tipo de emergencia (emergencia general, fuego, transporte), una ubicación, descripción del incidente, solicitud de recursos, y un campo para materiales peligrosos. 3. El OficialdeCampo completa el formulario especificando mínimamente el tipo de emergencia y la descripción de los campos. El OficialdeCampo puede además describir las posibles respuestas a la emergencia y solicitar recursos específicos. Una vez que el formulario se completa, el OficialdeCampo envía el formulario presionando el botón “EnviarReporte”, con lo cual el Despachador es notificado. 4. El Despachador revisa la información enviada por el OficialdeCampo y crea un Incidente en la base de datos invocando al caso de uso AbrirIncidente. Toda la información contenida en el formulario del OficialdeCampo se incluye de manera automática en el incidente. El despachador selecciona una respuesta asignando recursos al incidente (con el caso de uso AsignarRecursos) y confirmando el reporte de emergencia enviando un FRIENDgram al OficialdeCampo

Condición de salida

5. El OficialdeCampo recibe confirmación de selecciona la respuesta.

Fuente: Adaptado de Bruegge, B., y Dutoit, A. (2010)

5.2.1.  Identificar objetos entidad Los objetos participantes forman las bases de un modelo de análisis, estos se identifican examinando cada caso de uso e identificando objetos candidatos. Para ello se debe trabajar en base a heurísticas como la de Abbot (1983), que de manera intuitiva, ayudan a identificar los elementos necesarios del modelo de clases, tales como objetos, atributos y asociaciones a partir de la especificación de requerimientos, como se muestra en la tabla 8. Tabla 8. Heurísticas de Abbot para el mapeo de partes del diálogo hacia modelos de componentes. Parte del texto

Componente del modelo

Ejemplo

Nombre propio

Instancia

Alice

Nombre común

Clase

Oficial de campo

Verbo de acción

Operación

Crea, emite, selecciona

Verbo ser

Herencia

Es una clase de, es uno de

Verbo tener

Agregación

Tiene, consta de, incluye

Verbo modal

Restricciones

Debe ser

Adjetivo

Atributo

Descripción de incidente

Fuente: Adaptado de Bruegge, B., y Dutoit, A. (2010)

El análisis del lenguaje natural tiene la ventaja de que se enfoca en los términos del usuario, no obstante, también se presentan limitaciones, como la imprecisión del lenguaje y, por tanto, la calidad depende del estilo de redacción del analista. Los desarrolladores pueden resolver esas limitaciones reescribiendo

52

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

y clarificando la especificación de requerimientos, de modo que identifiquen y estandaricen objetos y términos. Otra limitante del lenguaje natural es que existen más sustantivos que clases relevantes, muchos de ellos corresponden a atributos o sinónimos de otros, esto hace que la tarea de identificar clases en especificaciones de software muy grandes consuma mucho tiempo. Por consiguiente, la lista de heurísticas de Abbot trabaja bien para generar una lista de objetos candidatos a partir de descripciones cortas, tales como el flujo de eventos de un escenario o un caso de uso. Como complemento a la heurística de Abbot, se puede usar la heurística para identificar objetos entidad propuesta en Bruegge, B. & Duttoit, A. (2010), que se describe a continuación: Heurística para identificar objetos entidad: Se considerarán objetos entidad a los siguientes casos: •

Términos que los desarrolladores o usuarios necesitan para comprender el caso de uso.

•

Sustantivos recurrentes en los casos de uso.

•

Entidades del mundo real que el sistema necesita mantener.

•

Actividades del mundo real que el sistema necesita conservar

•

Fuentes de datos

La identificación de objetos entidad, debe contener un nombre en los términos que usan los usuarios y especialistas del negocio, agregando una breve descripción y listando algunos atributos que, de los objetos; esto permitirá a los desarrolladores tener mayor claridad respecto del dominio del problema. Recuerde que los objetos entidad son todos aquellos elementos que pertenecen al dominio del problema y que el sistema necesita tener control. Aplicando las heurísticas mencionadas, sobre el problema que estamos trabajando como ejemplo se puede identificar a los objetos entidad que se muestran en la tabla 9: Tabla 9. Objetos entidad para el caso de uso ReportarEmergencia Objeto

Descripción

Despachador

El oficial de policía que gestiona los Incidentes. Un Despachador abre, documenta y cierra incidentes como respuesta a ReportedeEmergencia y otras comunicaciones con OficialdeCampo. Los Despachadores son identificados por un número de placa.

ReportedeEmergencia

Reporte inicial acerca de un Incidente, desde un OficialdeCampo hacia el Desapachador. Un ReportedeEmergencia está compuesto de un nivel de emergencia, un tipo de emergencia (fuego, accidente de carretera, otros), una ubicación, y una descripción.

OficialdeCampo

Policía u bombero en servicio. Un OficialdeCampo puede ser asignado como mucho a un Incidente a la vez. Los OficialesdeCampo se identifican por número de placa.

Incidente

Es la situación que requiere atención del OficialdeCampo. Un Incidente puede ser reportado en el sistema por parte del OficialdeCampo o cualquier agente externo al sistema. Un incidente está compuesto de una descripción, una respuesta, un estado (abierto, cerrado, documentado), una ubicación, y un número de OficialesdeCampo.

Fuente: Adaptado de Bruegge, B., y Dutoit, A. (2010)

La Universidad Católica de Loja

53

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Tenga en cuenta que existen elementos en la descripción que no se toman en consideración, como por ejemplo el formulario, el cual existe temporalmente como elemento para guardar información, pero no necesitamos mantener al mismo, simplemente sirve de instrumento para interactuar y almacenar la información del Incidente. 5.2.2.  Identificar objetos interface Como se había indicado anteriormente, los objetos interface (boundary) representan el mecanismo de comunicación del sistema con actores humanos o con otros sistemas, por lo tanto, se trata de identificar a todos los objetos que permitirían esta interacción, para ello, recolectan la información desde el actor y la trasladan a un formulario que puede ser utilizado tanto por objetos entidad, como por objetos de control. Los objetos interface, no necesitan demasiados detalles de cómo se implementarán, pero si es importante que especifiquen cómo deberá ser la interacción. Para identificar objetos Interface utilizaremos la siguiente heurística, propuesta por Bruegge y Dutoit (2010) Para identificar objetos interface, considere lo siguiente: •

Identifique controles de la interface que el usuario necesitará para iniciar el caso de uso, por ejemplo BotondeReportedeEmergencia.

•

Identifique formularios que se necesitaría el usuario para ingresar información al sistema. Por ejemplo FormularioReporteEmergencia.

•

Identifique avisos y mensajes que el sistema utiliza para responder al usuario.

•

Cuando múltiples actores están involucrados en un caso de uso, identifique terminales de actor (ej. TerminalDespachador) para referirse a la interface en consideración.

•

No modele aspectos visuales de la interface con objetos de interfaz de usuario.

•

Siempre utilice términos de usuario final para describir interfaces; no utilice términos del dominio de la solución o de la implementación.

Aplicando estas heurísticas al caso de uso ReportarEmergencia, obtenemos los objetos que se indican en la tabla 10. Los cuales de acuerdo a la descripción representan entidades propias de una interfaz del sistema que permitiría al usuario cumplir con sus funciones. Además, se considera ciertos objetos tipo interfaz para presentar los mensajes, esto debido a que como veremos más adelante los objetos entidad o control no pueden interactuar directamente con el actor, y por lo tanto cualquier mensaje o notificación debe llegar a un objeto de tipo notificación, que es con el usuario (actor) puede interactuar.

54

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Tabla 10. Objetos interface para el caso de uso ReportarEmergencia Objeto

Descripción

AvisoConfirmacion

Aviso utilizado para presentar la confirmación del Despachador a OficialdeCampo.

EstacionDespachador

Computador utilizado por Despachador

BotonReporteEmergencia

Botón utilizado por OficialdeCampo para iniciar el caso de uso ReportarEmergencia

FormularioReporteEmergencia

Formulario para la entrada de ReporteEmergencia. Este formulario se presenta al OficialdeCampo en la EstacionOficialdeCampo cuando se selecciona la función FormularioReporteEmergencia, este formulario contiene campos para especificar todos los atributos de un reporte de emergencia y un botón para enviar el formulario completo.

EstaciónOficialdeCampo

Computador portátil o dispositivo móvil utilizado por OficialdeCampo.

FormularioIncidente

Formulario utilizado para la creación de Incidentes, este formulario se presenta al Despachador en la EstacionDespachador cuando se recibe un Reporte.

Fuente: Adaptado de Bruegge, B., y Dutoit, A. (2010)

Hasta ahora se ha cubierto dos aspectos de las actividades del análisis, el primero la identificación de objetos entidad y segundo los objetos interface, lo siguiente, es identificar los objetos de control, cuyo objetivo es describir el orden en que se ejecutarían las interacciones, y para ello se utilizará como insumo los casos de uso. 5.2.3.  Identificar objetos de control Los objetos de control son responsables de coordinar las acciones entre los objetos entidad e interfaz, y no tienen una contraparte en el mundo real, usualmente se da una relación cercana entre objetos de control y casos de uso, el objeto de control se crea al inicio del caso de uso y desparece a su final. Estos objetos son los responsables de recolectar la información proveniente de los objetos interfaz. Para identificar objetos de control, Bruegge y Dutoit (2010) proponen la siguiente heurística: •

Identifique un objeto de control por cada caso de uso.

•

Identifique un objeto de control por actor en el caso de uso.

•

La línea de vida de un objeto de control, debe cubrir la extensión del caso de uso o la extensión de la sesión de usuario. Si es difícil identificar el inicio y el final de la activación de un objeto de control, el caso de uso correspondiente probablemente no tiene bien definidas las condiciones de entrada y de salida.

Continuando con el ejercicio, se identifican los objetos de control a partir del caso de uso ReportarEmergencia, estableciendo un objeto de control por cada actor: ReportarEmergenciaControl para el OficialdeCampo y GestionarEmergenciaControl para el Despachador, como se muestra en tabla 11. Esta decisión de modelar con dos objetos de control parte del conocimiento de que EstacionOficialdeCampo y EstaciónDespachador en realidad son dos subsistemas comunicándose a través de un enlace asíncrono. Esta decisión se pudo haber pospuesto hasta etapas futuras del modelo, no obstante, al hacerlo durante La Universidad Católica de Loja

55

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

el análisis se tendría la ventaja de que los desarrolladores podrían poner atención a un comportamiento excepcional como la perdida de comunicación entre ambas estaciones de trabajo, antes de llegar al diseño. Tabla 11. Objetos de control para el caso de uso ReportarEmergencia Objeto

Descripción

ReportarEmergenciaControl

Gestiona la función de reportes ReportarEmergencia en la EstacionOficialdeCampo. Este objeto se crea cuando el OficialdeCampo selecciona el botón “Reportar emergencia”. Luego crea un FormularioReportarEmergencia y lo presenta al OficialdeCampo. Después de enviar el formulario presentar el formulario, este objeto recopila la información del formulario, crea un ReporteEmergency y lo envía al Despachador. A continuación, el objeto de control espera una confirmación para volver desde la EstaciónDespachador. Cuando se da la confirmación,el objeto ControlReportarEmergencia crea un AvisoConfirmación y lo muestra al OficialdeCampo.

GestionarEmergenciaControl

Administra la función ReportarEmergencia en la EstacionDespachador. Este objeto es creado cuando se recibe un ReporteEmergencia. Luego crea un FormularioIncidente y lo muestra al Despachador. Una vez que el Despachador a creado un Incidente, asigna Recursos, y envía una confirmación a EstacionOficialdeCampo.

Fuente: Adaptado de Bruegge, B., y Dutoit, A. (2010)

5.2.4.  Mapeo de casos de uso a objetos mediante diagramas de secuencia Una vez identificados los objetos, se dibuja los diagramas de secuencia, estos se utilizan para representar el comportamiento de los objetos durante la ejecución de uno de los escenarios de un caso de uso, y a pesar de ser modelos no tan adecuados para comunicarse con el usuario, son mucho más precisos que los casos de uso para explicar el comportamiento del sistema, y permiten a los desarrolladores descubrir nuevos objetos, o aclarar aspectos confusos en la especificación de requerimientos. Deberá dibujar un diagrama de secuencia por cada escenario relevante que se identifique en un caso de uso, se debe desarrollar un diagrama de secuencia por cada escenario. Para dibujar diagramas de secuencia, se debe tener en cuenta las consideraciones de la heurística siguiente, propuesta en Bruegge y Dutoit, (2010).

56

•

La primera columna corresponde al actor que inicia el caso de uso.

•

La segunda columna debe ser el objeto de control que usa el actor para iniciar el caso de uso.

•

La tercera columna debe ser el objeto de control que gestiona el resto del caso de uso.

•

Los objetos de control son creados por objetos interfaz que inician los casos de uso.

•

Los objetos interfaz son creados por los objetos de control.

•

Los objetos entidad son accedidos por objetos interfaz y por objetos de control.

•

Los objetos entidad nunca acceden a los objetos interfaz objetos de control

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

Para comprender como se construyen los diagramas de secuencia, aplique heurística al caso de uso ReportarEmergencia de la tabla 7. Lo primero de que se debe hacer es representar es al actor que inicia el caso de uso, luego se agrega el objeto interface que usará el actor para iniciar el caso de uso, en este caso se trata de BotonReportarEmergencia; en la siguiente columna colocamos al objeto de control que recibe la activación desde el objeto interface, en este caso se trata del objeto ReportarEmergenciaControl, a partir se detalla la secuencia de interacciones del escenario; luego se identifica los objetos que se necesita agregar de acuerdo a heurística. En el ejemplo ReportarEmergenciaControl, crea al objeto interface FormularioReportarEmergencia, y luego de algunos mensajes al objeto ReporteEmergencia. El resultado se puede apreciar en la figura 16. Tenga en cuenta algunos aspectos importantes del modelo, como por ejemplo ningún objeto le responde nada al actor, pero el si se comunica con los objetos interfaz: BotonReportarEmergencia y FormularioReportarEmergencia; además un objeto de control puede destruir un objeto interfaz cuando ya no se lo requiere, como en el caso del FormularioReportarEmergencia que es destruido por ReportarEmergenciaControl. Durante el proceso de elaboración de diagramas de secuencia, también podemos encontrar nuevos objetos que no descubrimos durante el proceso anterior, como es el caso del objeto tipo entidad Confirmacion, esto implica necesariamente una actualización del caso de uso, el cual debería quedar como se muestra en la tabla 12. El desarrollo de diagramas de secuencia no solo permite representar el orden de las interacciones, sino que también ayuda a distribuir el comportamiento de los casos de uso mediante la asignación de responsabilidades a cada uno de los objetos, cada mensaje que llega a un objeto se convierte en una operación, las cuales a su vez pueden ser compartidas por cualquier caso de uso en el que participa el objeto, por tanto también se debe tener en cuenta que si un objeto se comparte en más de un caso de uso, la especificación es la misma en todos ellos.

La Universidad Católica de Loja

57

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Figura 16: Diagrama de secuencia para escenario del caso de uso ReportarEmergencia. Fuente: Bruegge, B., y Dutoit, A. (2010)

58

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

En la etapa de análisis, los diagramas de secuencia sirven para descubrir nuevos objetos participantes, así como también comportamiento omitido en los pasos anteriores, esto ocurre debido a que los diagramas de secuencia se enfocan en el comportamiento de alto nivel, y no en aspectos como el rendimiento. El trabajo de los desarrolladores es describir funcionalidades importantes o problemáticas, por lo que no resulta muy útil desarrollar diagramas de secuencia para partes del sistema simples o que están bien definidas, el uso de diagramas de secuencia en su correcta medida, ayudaría a no pasar por alto decisiones importantes. Tabla 12. Modificación del caso de uso ReportarEmergencia, del sistema AMIGO, como consecuencia del descubrimiento del nuevo objeto, lo cual además evidencia que la descripción original estaba incompleta. Nombre escenario:

ReportarEmergencia

Condición de entrada:

1. El OficialdeCampo, activa la función “ReportarEmergencia” en su terminal.

Flujo de eventos:

2. AMIGO responde presentando al oficial un formulario de datos. El formulario incluye un menú para el tipo de emergencia (emergencia general, fuego, transporte), una ubicación, descripción del incidente, solicitud de recursos, y un campo para materiales peligrosos. 3. El OficialdeCampo completa el formulario especificando mínimamente el tipo de emergencia y la descripción de los campos. El OficialdeCampo puede además describir las posibles respuestas a la emergencia y solicitar recursos específicos. Una vez que el formulario se completa, el OficialdeCampo envía el formulario presionando el botón “EnviarReporte”, con lo cual el Despachador es notificado. 4. El Despachador revisa la información enviada por el OficialdeCampo y crea un Incidente en la base de datos invocando al caso de uso AbrirIncidente. Toda la información contenida en el formulario de OficialdeCampo se incluye de manera automática en el incidente. El despachador selecciona una respuesta asignando recursos al incidente (con el caso de uso AsignarRecursos) y confirmando el reporte de emergencia enviando un FRIENDgram al OficialdeCampo. La Confirmacion indica al OficialdeCampo que el ReporteEmergencia fue recibido, un Incidente fue creado, y se asignaron recursos al incidente. La confirmación incluye los recursos y su tiempo estimado de llegada.

Condición de salida

5. El OficialdeCampo recibe confirmación de selecciona la respuesta.

Fuente: Adaptado de Bruegge, B., y Dutoit, A. (2010)

5.2.5.  Tarjetas CRC CRC, son las iniciales de Class, Responsibilities, and Collaborator, y se constituyen en una técnica alternativa para identificar interacciones entre objetos, se pueden utilizar con los equipos de trabajo durante sesiones de modelado en las que se invita tanto a desarrolladores como a expertos en el negocio. Las tarjetas CRC, tienen la estructura que se muestra en la figura 17, y se elaboran haciendo un recorrido por los escenarios de los casos de uso durante el cual se identifica las clases participantes. Se debe usar una tarjeta por cada clase, las responsabilidades se asignan a la clase conforme se desdobla cada escenario y los participantes negocian las responsabilidades de cada objeto; la columna de colaboradores se va llenando conforme se identifican las dependencias con otras tarjetas.

La Universidad Católica de Loja

59

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Nombre de la clase Responsabilidades - R1 - R2 - R3

Colaboradores - C1 - C2 - C3

Figura 17. Formato tarjetas CRC Fuente: Bruegge, B., y Dutoit, A. (2010)

Las tarjetas se modifican cada que se identifican nuevas versiones, estas nunca se desechan debido a que pueden ser reusadas cuando surgen nuevas ideas. En la figura 18, se puede apreciar un ejemplo de tarjeta CRC para la clase ReportedeEmergenciaControl. ReporteEmergenciaControl Responsabilidades Recoge la información de oficial de campo. Controla la secuencia de formularios durante el reporte de una emergencia.

Colaboradores FormularioReporteEmergencia ReporteEmergencia AvisoConfirmacion

Figura 18. Tarjetas CRC para la clase ReportedeEmergenciaControl Fuente: Bruegge, B., y Dutoit, A. (2010)

Como se mencionó anteriormente, las tarjetas CRC son una alternativa a los diagramas de secuencia, sin embargo, son más convenientes cuando se hace trabajo en equipo, y los diagramas de secuencia cuando se trabaja individualmente. 5.2.6.  Identificación de asociaciones Las asociaciones muestran las relaciones entre dos o más clases, por ejemplo, en un sistema académico tendríamos una lista de clases como: asignatura, docente, estudiante, matricula, podríamos identificar asociaciones entre ellas: docente dicta asignatura, estudiante obtiene matrícula. Para identificar asociaciones, es necesario tener en cuenta la heurística de Abbot, complementada con la establecida por Bruegge y Dutoit (2010), ello facilitará la tarea de identificar asociaciones.

60

•

Examine los verbos.

•

Nombre asociaciones y roles de manera precisa.

•

Utilice calificadores tan frecuentemente como le sea posible, de modo que pueda identificar namespaces y atributos clave.

•

Elimine cualquier asociación que pueda ser derivada de otras.

•

No se preocupe por la multiplicidad hasta que el conjunto de asociaciones se estabilice.

•

Demasiadas asociaciones, pueden hacer el modelo ilegible.

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

Vale resaltar la importancia de tener un número pequeño de asociaciones, de modo que sea fácil su lectura y comprensión, si no sucede esto los desarrolladores deben evaluar el modelo identificar todas las asociaciones que podrían resultar redundantes, conviene tener presente que mientras menos asociaciones se coloquen es mejor, siempre y cuando no se pierda información. La identificación de asociaciones ofrece a los desarrolladores dos ventajas, primero la posibilidad de clarificar el modelo de análisis haciendo explícitas las relaciones entre objetos y en segundo lugar permite descubrir casos límite o que podrían considerarse excepcionales, por ejemplo, podría preguntarse, ¿sólo un OficialdeCampo reporta una emergencia?, o ¿es posible que más de uno lo haga?, o ¿puede haber reportes de emergencia anónimos? Las asociaciones tienen las siguientes propiedades: •

Nombre, Es un atributo opcional y necesariamente único en todo el modelo, es una palabra o frase corta que describe la forma como se asocian las dos clases.

•

Rol, Es una palabra, normalmente un sustantivo que identifica la función de cada clase con respecto a la asociación.

•

Multiplicidad, Se coloca en cada extremo de la asociación y sirve para describir el número de instancias de la clase que se asocian con una instancia de la otra clase.

Ejemplo:

Figura 19: Ejemplo de asociación Fuente: Bruegge, B., y Dutoit, A. (2010)

En el ejemplo de la figura 19, se puede apreciar la asociación escribe, que relaciona a 1 instancia de la clase OficialdeCampo con 1 instancia de la clase ReporteEmergencia, es decir la multiplicidad es 1 a 1, además se puede apreciar los roles, que son los textos que se encuentran al lado de cada clase. Cuando se describe un modelo de clases, los nombres de las asociaciones no son obligatorios, y se pueden omitir usando los nombres de los roles o si la relación es lo suficientemente clara, se la omite. Cuando se modela asociaciones, también conviene tener presente las redundancias que se pueden dar, como por ejemplo en la figura 20, la asociación reporta es redundante, ya que está claramente establecido que OficialdeCampo escribe un ReporteEmergencia, lo cual lanza un Incidente.

Figura 20. Ejemplo de asociación redundante. Fuente: Bruegge, B., y Dutoit, A. (2010) La Universidad Católica de Loja

61

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

5.2.7.  Identificación de agregaciones Las agregaciones son un tipo especial de asociaciones que denotan la relación Todo-Parte, existen dos tipos: la agregación de composición y la agregación compartida, la diferencia entre las dos es que la composición se utiliza para representar agregados estructurales, es decir agregaciones en las cuales, si desaparece el todo, desparecen todas sus partes, en cambio en la agregación compartida ambas clases existen independientemente. La agregación se representa como una asociación con la diferencia de que se coloca un rombo en la punta de la línea a la que llega el Todo, y en el caso de la agregación de composición el rombo se rellena totalmente como en la figura 21, en la cual se muestran dos ejemplos, uno de agregación y otro de composición. La composición que se encuentra a la izquierda denota la relación de un vehículo con sus partes, de acuerdo al sentido de la relación si desaparece el vehículo, desaparecen sus partes, en el caso de la derecha la relación indica que un préstamo incluye muchos libros, sin embargo, no hay una dependencia estructural entre los libros y el préstamo, puesto que estos se pueden usar en otras instancias del préstamo.

Figura 21. Ejemplos de agregación por composición (izquierda) y agregación compartida (derecha).

5.2.8.  Identificación de atributos Los atributos son las propiedades (datos) de cada uno de los objetos individuales, al momento de identificarlos es necesario realizar un ejercicio de abstracción, es decir, se debe colocar únicamente los atributos que sean relevantes para la aplicación o el modelo de dominio para el que estamos modelando; los atributos son la especificación de estas propiedades y cada objeto tiene un valor para cada uno de ellos. Para identificar atributos, es necesario determinar la información que guarda cada actor de los objetos sobre los que opera durante los escenarios o casos de uso descritos y la definición de cada atributo implica la especificación del tipo de dato que se almacenará. Es recomendable, además, identificar todas las asociaciones posibles entre las clases para evitar que se coloque como atributos, a características propias de las asociaciones. En la figura 22 se puede apreciar los atributos para la clase ReporteEmergencia, las cuales se identifican el tipo de emergencia (tipoEmergencia), la dirección donde produce la emergencia (ubicacion), y la descripción de la emergencia (descripcion), nótese que en este caso se ha identificado los atributos que reporta el actor OficialdeCampo cuando describe una emergencia, y no se consideran otros atributos que podrían incluirse como por ejemplo el vehículo desde el que se hacer el reporte, o el oficialdeCampo que reporta, ya que este último nace de una relación entre el oficial que reporta la emergencia y la emergencia en sí misma.

Figura 22. Identificación de atributos para la clase ReporteEmergencia.

62

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

De acuerdo a la heurística Abbott, definida en la tabla 8 para identificar atributos es necesario analizar adjetivos seguidos de una frase posesiva o una expresión con adjetivo. En el caso de los objetos entidad cualquier propiedad que deba almacenarse por el sistema es un atributo candidato, sin embargo, es necesario considerar que el descubrimiento de atributos puede completarse de manera tardía o en las revisiones con los usuarios. A continuación, se resumen la heurística establecida por Bruegge y Dutoit (2010) para la identificación de atributos: •

Examine frases posesivas.

•

Represente estados almacenados como atributo una entidad.

•

Describa cada atributo.

•

No represente un atributo como objeto; use una asociación en lugar de ello.

•

No desperdicie tiempo describiendo detalles finos del objeto antes de tener una arquitectura estable.

5.2.9.  Modelado del estado de objetos individuales. Los diagramas de estados o máquinas de estados, se utilizan para modelar la parte dinámica del sistema desde el punto de vista de cada objeto individual, lo cual favorece el desarrollo de descripciones más formales del comportamiento de los objetos y permite a los desarrolladores profundizar en los modelos, incluso identificar casos de uso faltantes, tampoco es necesario desarrollar máquinas de estados para todas las clases identificadas, sino solamente de aquellas clases con tiempo de vida extendida y comportamiento dependiente del estado. En la figura 23, podemos apreciar una máquina de estados para el objeto incidente y muestra lo que sucede con un incidente desde que este se activa (activado) hasta que el mismo es archivado, en el diagrama se puede ver la descomposición del estado Activado en sub estados, y las transiciones que permiten o provocan los cambios de estado.

Figura 23. Máquina de estados para el objeto incidente Fuente: Bruegge, B., y Dutoit, A. (2010) La Universidad Católica de Loja

63

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

ACTIVIDAD RECOMENDADA

Considere una aplicación para un sistema de biblioteca, en el cual se han definido los siguientes actores con sus casos de uso, desarrolle una breve especificación de lo que implicaría cada caso de uso en el formato utilizado en la presente unidad, y aplicando las heurísticas identifique objetos en cada una de las categorías establecidas: entidad, interface, control. Sistema biblioteca: Actor: Usuario Casos de uso: Reservar libro, Prestar libro, Devolver libro, extender período Actor: Buscador Casos de uso: Buscar. Actor: Personal Casos de uso: Préstamo revista, Devolución revista Actor: Bibliotecario Casos de uso: Actualizar catálogo. Una vez completada esta actividad, desarrolle diagramas de secuencia y actualice su modelo, luego complete el modelo de clases y elabore diagramas de estado para los objetos más importantes. 5.2.10.   Validación del modelo de análisis Normalmente el modelo de análisis no es completo y correcto en el primer intento, son necesarias varias iteraciones para lograrlo, y más importante aún es la participación de clientes y usuarios, antes de pasar al diseño e implementación. Una forma de saber si la etapa de análisis ha concluido, es cuando luego de las revisiones se han minimizado los cambios; a esta situación se la conoce como estabilización, además tanto clientes como usuarios y desarrolladores están seguros de que es el modelo es correcto, completo, consistente y realista, conforme las características resumidas en la tabla 13. Tabla 13. Características para validar el modelo de análisis. Aspecto

Correcto

64

Características –– –– –– –– –– ––

Glosario de objetos entidad comprensible para usuarios. Clases abstractas corresponden a conceptos de usuario. Descripciones correspondientes con definiciones de usuario. Nombres de objetos entidad e interfaz son sustantivos claros. Nombres de casos de uso y objetos de control son verbos. Errores identificados y gestionado.

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Aspecto

Características

Completo

–– –– –– –– –– –– –– ––

Todo objeto es requerido por al menos un caso de uso. Todo objeto se crea, modifica o destruye en un caso de uso. Todos los objetos accesibles desde un objeto interfaz. Procesos de inicialización de atributos identificados. Todos los atributos tienen su tipo de dato. Se identifican atributos cualificados. Asociaciones claras, multiplicidad definida. Cada objeto de control puede acceder a los objetos que participan en el caso de uso.

Consistente

–– Nombres de casos de uso o clases únicos en el modelo. –– Si hay nombres similares, deben corresponder al mismo elemento. –– Herencia correctamente aplicada.

Realista

–– Todas las características son factibles de implementar. –– Evidencia clara de que se puede cumplir con requerimientos de rendimiento y confiabilidad.

Fuente: Adaptado de Bruegge, B., y Dutoit, A. (2010)

En resumen, el modelo de análisis se puede establecer en el diagrama de actividades de la figura 24 y, como se puede apreciar se trata de un modelo iterativo que requiere varias pasadas hasta quedar completo, inicia con la definición de los casos de uso, y se repite el ciclo indicado hasta que en la revisión del modelo indique que está completo, lo cual depende de la comprensión se va alcanzando conforme se avanza en el desarrollo de la aplicación.

Figura 24. Resumen de actividades del análisis. Fuente: Adaptado de Bruegge, B., y Dutoit, A. (2010) La Universidad Católica de Loja

65

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Un aspecto que debe tener en cuenta mientras de desarrollan las actividades del análisis, es que todo parte de los requerimientos y el punto de vista de los usuarios, por eso es esencial entenderlo desde esta óptica, luego será más sencillo convertirlo en un modelo que cumpla con las condiciones necesarias para traducirlo a modelo de diseño.

5.3. Gestión del Análisis Las actividades del análisis no involucran simplemente el aspecto técnico, sino que es necesario gestionarlo, de forma tal que los equipos que trabajan en dicha actividad lo hagan coordinadamente y garanticen la consistencia en el uso de los recursos. En este apartado se establece un formato para documentar los resultados de la etapa de análisis, luego la asignación de roles al equipo de trabajo y finalmente, el cómo manejar algunos incidentes relacionados a los procesos iterativos e incrementales. 5.3.1.  Documentación del análisis La documentación es un aspecto esencial en las actividades de desarrollo de software, muchas de las veces los desarrolladores se centran en producir el software, y no dedican mucho tiempo a documentar, sin embargo, hay que insistir en que la documentación es esencial para apalancar las siguientes etapas del proceso de desarrollo, y esto, independientemente de la metodología de desarrollo de software que vayamos a adoptar. Al documento que describe las especificaciones necesarias lo denominaremos como DAR (Documento de Análisis de Requerimientos) y básicamente consiste en una versión ampliada del documento de requerimientos de software DRS, e incluye nueva información obtenida de las actividades del análisis. El esquema básico del documento es el que se muestra a continuación, no obstante, existen muchas versiones y plantillas de documentación del análisis que pueden utilizarse, es preferible de hecho utilizar plantillas estandarizadas en la organización para la que se desarrolla o la que desarrolla el producto, y alternativamente se puede utilizar estándares internacionales de documentación de software como el ISO/IEC 26514:2008 DOCUMENTO DE ANÁLISIS DE REQUERIMIENTOS 1. Introducción 2. Sistema actual 3. Sistema propuesto 3.1. Visión general 3.2. Requerimientos funcionales 3.3. Requerimientos no funcionales 3.4. Modelos del sistema 3.4.1. Escenarios 3.4.2. Modelo de casos de uso

3.4.3. Modelo de objetos 3.4.3.1 Diccionario de datos 3.4.3.2 Diagrama de clases 3.4.4. Modelos dinámicos 3.4.5. Interfaz de usuario – rutas de navegación o bocetos de pantalla. 4. Glosario

5.3.2.  Asignación de responsabilidades Como se había expuesto anteriormente, el proceso de desarrollo de software no es una tarea que se puede hacer individualmente, especialmente en la actividad de análisis se requiere la participación de un gran número de individuos, entre clientes, usuarios, equipo de desarrollo con diferentes roles. En la tabla 14, se describen algunos de los roles que asumen los participantes en esta actividad.

66

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Tabla 14. Organización del equipo de trabajo para el proceso de análisis Rol

Descripción

Usuario final

Es el experto en el dominio de la aplicación, su papel es informar cómo funciona el sistema actual, el entorno de operación del futuro sistema y las tareas que este deberá soportar. Los usuarios finales pueden modelarse como uno o varios actores en función de las responsabilidades que estos tienen con relación al sistema

Cliente

Es quien contrata el sistema, y como propietario define su alcance tomando como referencia los requerimientos de los usuarios. El cliente sirve como integrador de la información relacionada con el dominio y resuelve las inconsistencias que puedan presentarse con relación a las expectativas de los usuarios.

Analista

Es el experto en el dominio de la aplicación, cuya actividad principal es modelar el sistema actual y generar información acerca del futuro sistema.

Arquitecto

Trabaja desde la perspectiva del sistema e intenta integrar el modelo de casos de uso con el modelo de objetos. Provee la filosofía del sistema e identifica omisiones en los requerimientos.

Documentador

Responsable de generar, integrar e indexar la documentación del análisis.

Fuente: Bruegge, B. y Dutoit, A. (2010)

Con este apartado concluye la Unidad 5, en la cual se ha revisado el proceso de análisis orientado a objetos, y se ha ilustrado los pasos necesarios para elaborar un modelo de análisis adecuado para la transición al diseño.

La Universidad Católica de Loja

67

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Autoevaluación 5

Concluida la unidad 5, le invito a desarrollar la autoevaluación, recuerde que antes de verificar las respuestas debe desarrollar el aprendizaje, una vez resuelta la autoevaluación, verifique las respuestas y refuerce los contenidos que no hayan tenido aciertos. Seleccione la alternativa correcta en cada uno de las siguientes preguntas: 1.

2.

3.

4.

El modelo de análisis se compone de tres modelos individuales, ¿A cuál de estos modelos pertenecen los casos de uso? a.

Modelo objetos

b.

Modelo funcional

c.

Modelo dinámico

En el modelo dinámico del análisis, los diagramas que representan el comportamiento de un objeto individual son: a.

Diagramas de secuencia

b.

Diagramas de clases

c.

Diagramas de estados

De acuerdo a las descripciones dadas respecto de los diferentes estereotipos de los objetos identificados durante el análisis, los objetos de control cumplen la siguiente función: a.

Se encargan de la realización de los casos de uso.

b.

Permiten la comunicación con el actor.

c.

Representan la información persistente del sistema.

Considere un sistema de archivos con una interfaz gráfica de usuario, tal como el Mac Finder o Windows Explorer. Los siguientes objetos se identificaron desde un caso de uso describiendo como copiar un archivo desde una unidad de disco: archivo, ícono, basurero, carpeta, disco, puntero. Seleccione la alternativa que clasifique correctamente a los objetos en entidad, cuáles son interfaz y cuales son de control. a.

Entidad: ícono, carpeta; Interfaz: basurero, puntero; Control: disco, archivo.

b.

Entidad: archivo, disco; Interfaz: carpeta, basurero; Control: puntero.

c.

Entidad: archivo, carpeta, disco; Interfaz: ícono, puntero, basurero; Control: Ninguno.

68

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

5.

6.

7.

8.

9.

Guía Didáctica: Fundamentos de Ingeniería de Software

Una característica importante del modelado orientado a objetos, es que asocia entidades del mundo real, con clases del software. En la siguiente lista de objetos para un sistema de reloj satelital capaz de auto ajustar la hora en función de la localización geográfica (zona horaria), identifique aquellos que corresponden a clases del software. Seleccione todas las que apliquen. a.

LocalizadorGPS

b.

HoraUniversal,

c.

ZonaHoraria

d.

BasedeDatosZonaHoraria

e.

Ubicación

f.

IdentidadUsuario

La generalización y la especialización dan como resultado que una clase padre o súper clase herede sus características a una o más clases hijas, sin embargo, conceptualmente son cosas diferentes ¿Cuál es la diferencia entre generalización y especialización? a.

La generalización crea conceptos abstractos a partir de conceptos de bajo nivel y la especialización identifica conceptos específicos a partir de conceptos generales.

b.

La generalización trabaja de lo general a lo particular para crear relaciones jerárquicas y la especialización opera desde lo general a lo particular.

c.

Son sinónimos y no hay diferencia.

De acuerdo a la heurística de Abbot determine qué tipo de relación debería generarse a partir de la siguiente descripción: “La estación de bomberos está conformada por un jefe y muchas brigadas, las cuales a su se conforman por bomberos” a.

Agregación por composición

b.

Agregación compartida

c.

Asociación

En un sistema de Cajero Automático, se desarrolla un diagrama de secuencia para un escenario del caso de uso “Retirar Dinero”, se establece que el Actor Cliente , envía el mensaje ObtenerDinero (monto) al objeto RetirarFondos , luego RetirarFondos responde al cliente” no dispone de ese monto”. Analice el contexto y seleccione la alternativa que describa un juicio válido respecto del escenario. a.

La relación es incorrecta, ya que no se puede comunicar directamente a un actor con un objeto de control.

b.

La relación es correcta, debido a que no se atenta ninguna de las normas dadas.

c.

La relación está incompleta, ya que faltan elementos clave.

Durante la validación del modelo de análisis, se plantea que el mismo debe estabilizarse para dar por terminada la etapa. ¿Cuál de las siguientes alternativas el significado de estabilizarse? a.

Ya no hay más cambios.

b.

Se ha dispuesto que ya no se sigan haciendo cambios.

c.

El número de cambio se han minimizado.

La Universidad Católica de Loja

69

Guía Didáctica: Fundamentos de Ingeniería de Software

10.

70

SEGUNDO BIMESTRE

¿Cuál de los siguientes roles se hace cargo de integrar el modelo de casos de uso con el modelo de objetos? a.

Analista

b.

Arquitecto

c.

Programador

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

UNIDAD 6. DISEÑO ARQUITECTÓNICO Al diseño del sistema se lo puede definir cómo la transformación de un modelo de análisis en un modelo de diseño, el cual incluye la descomposición en subsistemas y una descripción clara de las estrategias de construcción. Para comenzar con el estudio del diseño, remítase al texto básico y estudie la parte introductoria del capítulo 6. Diseño Arquitectónico, donde se manera general revisará el proceso y la importancia que tiene esta etapa para la construcción de un sistema que satisface tanto a requerimientos funcionales, como no funcionales. Como habrá podido comprender con la lectura indicada, hay muchas implicaciones en el desarrollo futuro basado en las decisiones de diseño, por lo tanto, lo invito a desarrollar la siguiente actividad. Analice cada una de las siguientes interrogantes sobre la importancia del diseño y contestar con los argumentos que considere pertinentes: 1.

¿A qué niveles se puede entender la arquitectura y qué persigue cada nivel?

2.

¿Qué relación hay entre el diseño arquitectónico y los requerimientos no funcionales?

3.

¿Cómo se resuelven en diseño los requerimientos funcionales?

4.

¿Cuáles son las ventajas de documentar la arquitectura del sistema?

5.

¿Es posible desarrollar la arquitectura de forma incremental?

6.

¿Son compatibles los procesos de desarrollo ágiles con la arquitectura?

Ahora que ha podido responder a estas interrogantes, lo invito a profundizar en cada uno de los aspectos que implica el diseño del sistema, que entre otras cosas debe incluir cuestiones como la identificación de metas de diseño, las cuales están relacionadas con elementos de calidad, descomposición inicial del sistema en subsistemas más manejables que reducen la complejidad, y finalmente refinar la descomposición del sistema hasta que se cumplan las metas esperadas. El proceso de diseño según Bruegge y Dutoit, (2010), se alimenta del proceso de análisis y utiliza como insumos lo siguiente: conjunto de requerimientos no funcionales y restricciones, el modelo de casos de uso que describe las funcionalidades desde el punto de vista del actor, el modelo de objetos y los diagramas de secuencia, que además sirven como base para la comunicación entre el cliente y el equipo de desarrollo. Este modelo carece de información respecto de la estructura interna del sistema, y tampoco muestra información sobre la configuración del hardware y por lo tanto no se lo utiliza para la implementación. El proceso de diseño, por tanto, es el primer paso para definir la estructura del sistema y deriva finalmente en modelos que sirven para la implementación, para ello la fase de diseño necesita de los siguientes insumos: •

Objetivos del diseño, que describen aspectos relacionados con la calidad del sistema que los desarrolladores deben optimizar.

•

Arquitectura del software, que describe la descomposición en términos de responsabilidades de los subsistemas, dependencias entre subsistemas, mapeo de subsistemas a hardware, y las principales decisiones políticas tales como flujos de control, control de accesos, y almacenamiento de información.

La Universidad Católica de Loja

71

Guía Didáctica: Fundamentos de Ingeniería de Software

•

SEGUNDO BIMESTRE

Casos de uso de interfaz, que describen la configuración del sistema, inicio, apagado y manejo de excepciones.

6.1. Decisiones en el diseño arquitectónico. Estas decisiones, derivan de los requerimientos no funcionales, y además guían las decisiones a ser tomadas por los desarrolladores cuando se necesita seleccionar de entre varias características a las prioritarias. En la figura 25, se muestra la relación entre el diseño del sistema con otras actividades de la ingeniería del software.

Figura 25. Resumen de actividades de diseño. Fuente: Adaptado de Bruegge, B., y Dutoit, A. (2010)

En este momento, le invito a estudiar el apartado 6.1 del texto básico, en el cual se plantea como abordar las decisiones más importantes del diseño. Conforme profundiza en este tema, y según se expone en el texto analizado, son muchas las decisiones que se deben tomar durante el proceso de diseño, y ello no resulta fácil si no se utilizan los enfoques correctos. Estas decisiones tienen que ver con los requerimientos no funcionales priorizados en el producto de software, los cuales, están directamente relacionados con la arquitectura. Entre las decisiones más importantes se debe considerar, por ejemplo: el rendimiento, la seguridad, la protección, la disponibilidad, la mantenibilidad, cada una de estas características tendrá importancia en función de la naturaleza y propósito del sistema.

72

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

No es posible que una aplicación cumpla con todos los atributos de calidad, pues estos entran en conflicto por la demanda de recursos del sistema o elementos de interfaz que deben usarse. Para complementar la información sobre los conflictos entre atributos de calidad, investigue en la web mayores detalles sobre los atributos de calidad del software y en una tabla, trate de identificar la compatibilidad de atributos de calidad, para ello utilice una matriz que tanto en filas como columnas tenga los atributos de calidad, y con X indique si no hay compatibilidad, un ´-´ si no son compatibles, una X si hay compatibilidad.

6.2. Conceptos del diseño El diseño de software es una actividad compleja y combina varios elementos para poder obtener modelos de componentes que satisfagan las necesidades del cliente con los niveles de calidad requeridos, por tanto, antes de comenzar con la especificación de los procesos de diseño, es necesario estudiar los conceptos más importantes. 6.2.1.  Vistas Arquitectónicas Al igual que en la industria de la construcción, el diseño se puede apreciar desde diferentes puntos de vista, por ejemplo, la perspectiva, es una vista que muestra cómo se verá el edificio una vez terminado, la vista de planta muestra la distribución de ambientes, la vista de instalaciones sanitarias, la vista de seguridades, instalaciones eléctricas, etc, en conjunto constituyen el modelo completo que permitirá a los constructores visualizar todo lo que compone el edificio. En el software, la situación es un poco más compleja debido a que los componentes son intangibles y por tanto necesitamos capacidad de abstracción para identificar los elementos necesarios en cada aspecto, se requiere además dominio del lenguaje de modelado UML, para poder describir cada uno de los aspectos que implica el software. Ahora tome su texto básico, y estudie el apartado 6.1 Decisiones en el diseño arquitectónico, donde se explica las vistas que se requieren para la construcción del software. Como pudo revisar, la arquitectura de un sistema a decir de Krutchen, se puede evidenciar en el modelo 4+1, y se describen en el texto con claridad, lo que sí se considera importante recalcar que, si bien se necesita un lenguaje para especificar la arquitectura, este no es tan importante hasta que ya se necesita describirla y para eso se utilizan lenguajes de modelado como UML, y lenguajes de descripción arquitectónica ADL (Arquitecture Description Language), como AADL (Architecture Analysis & Design Language). En este punto, es importante mencionar que el diseño y la arquitectura son esenciales para cualquier producto de software, independientemente del tipo de metodología que se use; no obstante, el nivel de especificación depende más que de la metodología de la naturaleza, complejidad y las regulaciones que norman el desarrollo del proyecto. 6.2.2.  Subsistemas Para reducir la complejidad de un sistema de software, en tiempo de diseño es necesario descomponer el sistema en partes más pequeñas, a estas partes las denominamos subsistemas, diremos por tanto que “un subsistema es una parte reemplazable del sistema con interfaces bien definidas que encapsula el estado y el comportamiento de sus clases” ( Bruegge y Dutoit, 2010, p.218).

La Universidad Católica de Loja

73

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

La descomposición en subsistemas corresponde a un proceso de descomposición lógico, no obstante, para dimensionar el trabajo, se puede decir que un subsistema corresponde a una cantidad de trabajo que puede asumir un desarrollador o un equipo de ellos puede asumir. En un sistema orientado a objetos, un subsistema es una parte independiente del sistema que contiene un conjunto de clases relacionadas, y por tratarse de un sistema cada una de estas partes se encuentra relacionada con al menos una de las demás, no se puede concebir una parte aislada. Volviendo al ejemplo del sistema Amigo, el mismo que se utiliza para reportar emergencias; en la figura 26, se muestra una posible descomposición lógica del sistema.

Figura 26. Descomposición del sistema de reporte de emergencias Amigo en subsistemas. Fuente: Bruegge, B., y Dutoit, A. (2010).

Para implementar los subsistemas, los lenguajes de programación ofrecen diferentes alternativas, por ejemplo, C y C++ no tienen un tipo específico de codificación, por lo que la forma de implementarlo es separar el código en carpetas, en java se usan paquetes, y sin importar el lenguaje y sus posibilidades de representación, los desarrolladores deben documentar cuidadosamente la descomposición en subsistemas. 6.2.3.  Servicios e interfaces de subsistemas Un servicio, es un conjunto de operaciones relacionadas que comparten un propósito, este conjunto de operaciones que comparte un subsistema con otros subsistemas se muestra como una interface de subsistemas, esta interface especifica el nombre de las operaciones, los parámetros con sus tipos de datos y sus valores de retorno. En el diseño orientado a objetos, estas interfaces se implementan en la denominada Application Programmer Interface (API). En UML, estas interfaces se representan con conectores de ensamblaje (lollipop), como se muestra en la figura 27.

74

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

Figura 27. Representación UML de los servicios de los subsistemas. Fuente: Bruegge, B., y Dutoit, A. (2010).

6.2.4.  Cohesión y Acoplamiento El acoplamiento es el número de dependencias entre dos subsistemas, lo ideal es diseñar subsistemas con bajo acoplamiento o con acoplamiento moderado, de modo que los subsistemas mantengan cierta independencia entre sí, esto permite que la modificación en uno de los subsistemas tenga poco o ningún impacto en los demás, por el contrario, si los subsistemas se encuentran altamente acoplados las modificaciones tienen alto impacto. Además, se debe considerar que no se trata de eliminar el acoplamiento, sino de crear un diseño que permita un nivel de independencia eficiente entre subsistemas, ya que para conseguir esto, suele ser necesario añadir componentes, por ejemplo en la figura 28, se puede apreciar una transformación de una versión inicial con un acoplamiento nivel 3 contra el subsistema de base de datos, hacia un esquema que no reduce este nivel, sin embargo otorga mayor independencia de los diferentes subsistemas contra la base de datos, este cambio se justifica por lo siguiente: Si en la versión 1, se cambia de base de datos, deberá actualizar los tres componentes para que trabajen con la nueva base de datos; en la versión 2 se ha agregado un subsistema que es el único que interactúa con la base de datos, y si en este esquema cambiamos la base de datos, solo se deberá modificar el componente Almacenamiento, reduciendo trabajo innecesario.

La Universidad Católica de Loja

75

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Figura 28. Organización de subsistemas para reducir acoplamiento. Fuente: Bruegge, B., y Dutoit, A. (2010).

Por su parte la cohesión es el número de dependencias dentro del subsistema, entonces, se puede decir que si los objetos que forman parte un subsistema están relacionados y ejecutan tareas similares se tiene una cohesión alta, y si por el contrario los objetos de este subsistema no están relacionados o ejecutan tareas no relacionadas o diferentes, decimos entonces que la cohesión es baja. Ahora analice los ejemplos de las figuras 29 y 30, donde se observa un componente para un sistema de toma de decisiones, la primera versión contiene en un solo subsistema, objetos para analizar las reglas de negocio y para planificar las tareas, evidentemente las funciones no están relacionadas, por tanto, sobre modelo de la figura 32, diremos que el subsistema tiene baja cohesión entre sus componentes.

Figura 29. Sistema de decisión con baja cohesión entre sus componentes internos. Fuente: Bruegge, B., y Dutoit, A. (2010).

76

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

Para incrementar la cohesión entonces será necesario organizar los componentes de ese subsistema en dos subsistemas, de modo que en ambos casos los componentes estén relacionados, el resultado de este ejercicio se muestra en la figura 30, al separar los componentes en dos subsistemas, conseguimos mayor cohesión, debido a que las clases de cada subsistema están más relacionadas, no obstante, será necesario incrementar un elemento de interface entre estos dos subsistemas, esta decisión incrementa el acoplamiento.

Figura 30. Variante subsistemas para toma de decisiones, incrementa la cohesión y reduce el acoplamiento. Fuente: Bruegge, B., y Dutoit, A. (2010).

Las decisiones de diseño que se tomen con relación a la cohesión y el acoplamiento siempre producen conflicto en el sentido de que para incrementar la cohesión es necesario agregar nuevos subsistemas, lo cual incrementa el acoplamiento. No podemos hablar de una regla directa para saber cuánto de cohesión o acoplamiento es recomendable, sin embargo, Bruegge y Dutoit, (2010) sugieren utilizar el concepto 7 ± 2 a cualquier nivel de abstracción, esto significa considerar entre 5 y 9 niveles máximo de acoplamiento, si el valor supera los 9 sería necesario volver a revisar el modelo. 6.2.5.  Organización de subsistemas por capas Las capas lógicas (layers), corresponden a la distribución jerárquica de los sistemas, que permite la organización de los subsistemas agrupados de modo que provean servicios similares. Las capas se ordenan de modo que cada una depende solo de la capa en el nivel inferior, y no conoce de la existencia de otra capa.

La Universidad Católica de Loja

77

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Existen dos formas de organizar estas capas, para el primer caso hablaremos de una arquitectura cerrada, en la cual cada capa conoce únicamente a la capa inferior, y en una arquitectura abierta, una capa también puede acceder a niveles más profundos. En la figura 31, se puede apreciar la organización por capas de los subsistemas.

Figura 31. Organización de los subsistemas en capas

6.3. Patrones arquitectónicos Este apartado, se encuentra descrito en el texto básico, por tanto, no se desarrollará a detalle su contenido, se utilizará la información provista en él. El diseño de software es una actividad compleja, que requiere de una gran capacidad de abstracción para organizar subsistemas y componentes, de modo que el software que se construye cumpla con requerimientos funcionales y no funcionales, los cuales están atados directamente a la arquitectura. Una de las formas de conseguir esto es el uso de patrones arquitectónicos, los cuales demuestran ser esquemas de organización de subsistemas probados que pueden usarse en diferentes situaciones. En este momento, tome su texto básico y realice una lectura comprensiva del aparatado 6.3 Patrones arquitectónicos, donde encontrará una descripción de cada uno de ellos, así como la evolución histórica que han tenido. Una vez que ha concluido su lectura, es momento de reflexionar sobre los aspectos tratados en ella y son vitales para poder realizar el proceso de diseño, probablemente deberá realizar búsquedas en la web, en las lecturas sugeridas por el autor del texto básico al finalizar el capítulo. A partir de lo estudiado, conteste las siguientes preguntas:

78

1.

¿Qué es un patrón arquitectónico?

2.

¿Por qué es importante uso de patrones arquitectónicos?

3.

¿Cuándo debe usarse un patrón arquitectónico en particular?

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

4.

¿Cuáles son los patrones más utilizados?

5.

¿Por qué la arquitectura en capas esencial para grandes sistemas de software?

Además de ello, será necesario identificar cuáles serían las recomendaciones para utilizar diferentes tipos de aplicaciones empresariales, ya que debido a sus características se puede reutilizar software ya existente u organizarlo de formas probadas en su funcionamiento.

6.4. Arquitecturas de aplicación Las arquitecturas de aplicación son modelos arquitectónicos que encapsulan características comunes de sistemas que pueden usarse en diferentes empresas, ello permite que se puedan aplicar en cualquier momento con diferentes usos, que van desde usarlos como base para iniciar el proceso de diseño, hasta el usarlos como vocabulario para familiarizarse con estos tipos de aplicaciones. Para profundizar en este tema, remítase al apartado 6.4 Arquitecturas de aplicación de su texto básico, teniendo especial cuidado al momento de identificar las características de cada uno de los tipos de aplicación descritos. Luego de revisar el contenido, se identifican los denominados sistemas transaccionales, los sistemas de información y los sistemas de procesamiento de lenguaje, cada uno con sus características particulares, sin embargo podríamos preguntarnos ¿Qué relación hay entre los patrones arquitectónicos y las arquitectura de aplicación? Puede complementar lo indicado en el texto, visitando el sitio https://ifs.host.cs.st-andrews.ac.uk/Books/ SE9/Web/Architecture/AppArch/ indicado por el autor del texto básico, donde encontrará tres ejemplos más de arquitecturas de aplicación. ACTIVIDAD RECOMENDADA

Para el siguiente caso, seleccione un estilo arquitectónico, y proponga una estructura de sistema (subsistemas con relaciones), considerando los principios identificados. Escenario: Investigue el esquema de funcionamiento de un servicio de almacenamiento en la nube como Dropbox o Drive de Google, describa su operación y realice la actividad propuesta.

La Universidad Católica de Loja

79

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Autoevaluación 6

Con esto, hemos concluido el estudio de la Unidad 6, ahora, le invito a desarrollar la autoevaluación 6, que le permitirá hacer un recorrido por algunos de los temas más importantes de la asignatura. Seleccione la alternativa correcta en cada una de las siguientes preguntas: 1.

2.

3.

4.

5.

80

El autor del texto básico, propone que la arquitectura del software se puede evidenciar a dos niveles, a nivel pequeño y arquitectura en grande, por otro lado, si contrasta estas definiciones con los patrones arquitectónicos, ¿a qué nivel se mueve el Modelo Vista – Controlador? a.

Pequeño

b.

Grande

c.

Es independiente

Cuando se diseña la arquitectura del software, es necesario considerar tanto requerimientos funcionales como no funcionales, los cuales se implementan tanto con componentes individuales como en esquemas arquitectónicos. ¿En cuál de los siguientes componentes se implementan los requerimientos funcionales? a.

A nivel de arquitectura

b.

En componentes externos

c.

En componentes individuales

Cuando se habla de las ventajas de documentar la arquitectura se plantea el hecho de que favorece la comunicación con los participantes ¿Por qué motivo sucede esto? a.

Porque es una presentación de alto nivel del sistema.

b.

Porque se elabora es una etapa temprana del desarrollo.

c.

Porque muestra cómo se organiza el sistema.

¿Por qué el modelo de análisis es insuficiente para poder pasar a la implementación del sistema? a.

Carece de información de la estructura interna del sistema.

b.

Las descripciones de los casos de uso no son lo suficientemente detalladas.

c.

Falta complementar los diagramas de clases.

¿Cuál de las siguientes características debe implementarse en la arquitectura del sistema para garantizar la disponibilidad? a.

Activos críticos del sistema protegidos.

b.

Operaciones críticas del sistema implementadas ubicadas en algún componente individual.

c.

Incluir componentes redundantes.

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

6.

7.

8.

9.

10.

Guía Didáctica: Fundamentos de Ingeniería de Software

¿Por qué motivo no es posible que una aplicación cumpla con todos los atributos de calidad? a.

Porque algunos pueden entrar en conflicto con otros.

b.

Puede resultar demasiado costoso.

c.

Puede tomar demasiado tiempo implementarlo.

Según el modelo arquitectónico propuesto por Krutchen 4+1 ¿En cuál de las vistas se aprecian las clases del sistema? a.

Vista de desarrollo.

b.

Vista de proceso.

c.

Vista lógica.

¿Qué lenguajes se utilizan específicamente para describir la arquitectura del sistema? a.

UML

b.

ADL

c.

C

El uso de metodologías ágiles se ha popularizado y se utilizan en casi cualquier ámbito del quehacer humano, este movimiento inició en la industria del software, ¿Qué sucede con la arquitectura desde el punto de vista ágil para el desarrollo de software? a.

Ya no se necesita, puesto que el sistema evoluciona conforme se avanza en los requerimientos.

b.

Debe ser más robusta que en las no ágiles.

c.

El nivel de especificación de la arquitectura no depende de a metodología sino de la complejidad del sistema.

Al descomponer un sistema en subsistemas, surgen dos conceptos esenciales: la cohesión y el acoplamiento y pueden entrar en conflicto dada la dependencia entre ellos ¿Cuál es la recomendación al respecto? a.

Priorizar la cohesión.

b.

Aplicar la heurística 7 ± 2

c.

Minimizar el acoplamiento.

La Universidad Católica de Loja

81

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

UNIDAD 7. DISEÑO E IMPLEMENTACIÓN Continuando con el estudio acerca del proceso de desarrollo de software, nos adentraremos en las actividades del diseño, el cual como se indicó en la unidad 6, se trata de un proceso creativo, que requiere capacidad para resolver problemas, sin embargo, no por ello es improvisado, sino que es un proceso de alta complejidad, y por lo tanto, requiere mucho conocimiento. Las actividades de diseño, se orientan a decidir varios aspectos de implementación que provean soluciones que satisfagan tanto los requerimientos funcionales como los no funcionales y por tanto han de evaluar diferentes alternativas. Cada decisión que se tome, tendrá alto impacto en el desempeño y calidad del producto resultante. Por consiguiente, las actividades de diseño se orientan a resolver los siguientes aspectos: •

Selección de productos de software de mercado o componentes heredados los cuales puede reducir costos.

•

Mapeo de subsistemas a hardware.

•

Diseño de la infraestructura de administración de la información persistente.

•

Definición de una política de control de accesos a los objetos, esta política impacta en la forma como estos objetos se distribuyen.

•

Diseño del control de flujo global. Determinar la secuencia de operaciones impacta la interface del sistema.

Además de ello, el texto básico propone otros aspectos, que los diseñadores deben tener en cuenta. Realice una lectura comprensiva de la introducción al capítulo 7. Diseño e Implementación del texto básico. En ella se expresan otras preocupaciones que deben tener en cuenta los desarrolladores. Conforme lo plantea el autor del texto básico, el diseño y la implementación están estrechamente relacionados. Se puede usar UML para representar el diseño siempre y cuando se vaya a implementar utilizando algún lenguaje de programación como Java, Visual Studio, PHP u otros. El propósito de esta unidad es mostrar cómo el modelado del sistema y el diseño arquitectónico se ponen en práctica en el desarrollo de un diseño orientado a objetos. Además, se busca introducir algunos temas del diseño y la implementación como la reutilización del software, la administración de la configuración y el desarrollo de código abierto.

7.1. Diseño orientado a objetos con UML Para estudiar este apartado, se trabajará con el texto básico y se complementará con información adicional que permita clarificar o ampliar el contenido aquí explicado. En este momento le invito a realizar una lectura comprensiva del apartado 7.1 Diseño Orientado a Objetos con el uso de UML del texto básico, recuerde que varios de los aspectos aquí abordados, ya se estudiaron en el primer bimestre.

82

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

De acuerdo al contenido estudiado, el modelado del diseño implica cumplir algunas actividades, que intentaré resaltar a continuación. El primero es el modelo de contexto, que en realidad lo que hace es ubicar al sistema en desarrollo, en relación con otros sistemas, ello es esencial porque permitirá identificar aspectos como las interfaces que se deben desarrollar para dichas interacciones, las posibles protecciones del sistema y también las responsabilidades; es decir, incluir en nuestro diseño los aspectos que no están cubiertos por otros sistemas y que son necesarios para cubrir los requerimientos. Si lo recuerda, esto era parte de la decisión respecto de lo que se debería hacer con los sistemas existentes o con otros que podría resultar más adecuado comprarlos antes que desarrollarlos. Esto lleva a identificar nuevos casos de uso o a complementar los casos de uso que ya tenemos definidos, recuerde que los actores ya fueron identificados en las etapas iniciales del proceso de desarrollo y son personas, aplicaciones o dispositivos capaces de interactuar con nuestro sistema. Otro de los aspectos que contempla este apartado es el diseño de la arquitectura del sistema, para ello se debe utilizar los patrones arquitectónicos revisados en la unidad anterior. Recuerde que cada uno de los componentes de la arquitectura del sistema, es un subsistema, el cual, a su vez, está conformado por clases que tienen relación entre ellos. Por ello los conceptos sobre cohesión y acoplamiento estudiados, son necesarios al momento de estructurar los subsistemas. En relación a los modelos de diseño, básicamente podemos hablar de modelos estructurales y modelos dinámicos, los cuales se deben complementar con la definición de interfaces entre componentes del sistema. Analice los ejemplos sobre la estación meteorológica propuestos en el texto básico, para afianzar su comprensión respecto del diseño arquitectónico. Para complementar esta información, vamos a intentar resumir los pasos para el modelado con UML, para ello revisemos el proceso general del diseño orientado a objetos del sistema, como se muestra en la figura 32. Ya se ha comentado respecto de las metas del diseño, y la definición e implementación de subsistemas, los cuales se sustentan en el diseño arquitectónico, ahora se revisarán algunas de las actividades planteadas en la figura 35, que son esenciales para el proceso de diseño. Puesto que ya hemos acordado que la representación de los modelos se realizará con UML, empezaremos identificando los elementos de UML que se requieren en cada caso.

La Universidad Católica de Loja

83

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Figura 32. Actividades de diseño del sistema. Fuente: Bruegge, B., y Dutoit, A. (2010)

7.1.1.  Mapeo de subsistemas a plataformas de hardware y software El mapeo de subsistemas se hace a mediante la vista de despliegue, la cual según Rumbaugh, Jacobson y Booch (2005) muestra la organización física de los nodos en tiempo de corrida, esta vista se modela con los diagramas de despliegue. Los elementos que conforman un diagrama de despliegue son: •

Conforme lo establecen Rumbaugh, Jacobson, y Booch (2005), Un nodo es un recurso computacional en tiempo de corrida (dispositivo físico o ambiente de ejecución), el cual tiene como mínimo memoria y capacidad de procesamiento. Pueden colocárseles estereotipos para diferenciar clases de recursos tales como CPUs, dispositivos, memoria. Los nodos ejecutan los componentes.

•

El Object Management Group (2015), define a un Artefacto, como una entidad autocontenida que provee servicios, puede verse como un elemento físico y hay varios tipos de artefactos tales como: archivos de modelos, archivos fuente, scripts, archivos ejecutables, tablas de bases de datos, entregables de desarrollo, documentos de procesamiento de textos y mensajes de correo. La presencia de un artefacto en un nodo se muestra colocándolo dentro del nodo con el estereotipo correspondiente. Un artefacto implementa un componente u otra clase, esto se representa con una línea discontinua etiquetada con , la cual denota dicha implementación, la flecha se dirige al componente, esta relación se denomina manifestación.

En la figura 33, se modela un ejemplo que denota el despliegue de una aplicación para un cajero automático (ATMkiosk), en el cual se distinguen dos nodos que son el servidor del banco (BankServer), en el cual corren dos artefactos que lo la bases de datos de cuentas (accountDB) y la aplicación ejecutable de transacciones (Transaction.jar), este artefacto implementa el componente lógico de transacciones

84

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

(Transaction), además implementa una inteface de actualización de transacciones (update), que es invocada por el artefacto (ATM-Gui.jar) que se encuentra en el nodo del cajero (client:ATMKiosk). La comunicación entre nodos se representa mediante líneas continuas que implementan un protocolo de comunicación, como puede ser http, jdbc u otros.

Figura 33. Ejemplo de diagrama de despliegue, para un cajero automático. Fuente: Rumbaugh, J., Jacobson, I., y Booch, G., (2005)

Este tipo de diagramas son necesarios porque la mayoría de sistemas no se implantan en un solo dispositivo y en muchas ocasiones dependen del acceso a una red como una intranet o acceso a internet. Esto depende de varios factores que muchas de las veces identificamos en requerimientos no funcionales como el rendimiento o seguridad. Una vez que se ha identificado las plataformas de hardware, es necesario definir que se instalará en cada uno de los nodos o dispositivos, estos de acuerdo a lo estudiado son componentes ejecutables o binarios que cumplen una función en la operación del sistema, nótese que sólo se incluyen componentes ya compilados en algún formato de archivo que se instala en el dispositivo. 7.1.2.  Gestionar la información persistente Entendemos como información persistente a aquella que permanece aún después de que el sistema se haya ejecutado, es decir los datos de la empresa o del cliente, esta información puede almacenarse en diferentes formatos, y en este punto es necesario decidir dónde y cómo se almacenará la información. A continuación, se revisan brevemente los pasos requeridos para gestionar la información: •

Identificar objetos persistentes Los objetos que normalmente son candidatos para persistir son los objetos entidad que se definieron durante la etapa de análisis, los demás objetos tienen una duración temporal en tiempo de ejecución, sin embargo es necesario analizarlos a todos antes de tomar la decisión.

•

Seleccionar estrategia de almacenamiento Existen varias formas y formatos para almacenar la información persistente, esta decisión suele estar atada principalmente a los requerimientos no funcionales. Los formatos más comunes para almacenamiento en los que podemos elegir son:

La Universidad Católica de Loja

85

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

￮￮

Archivos planos, administrados por el sistema operativo, y se guardan como secuencias de bytes, tienen la ventaja de la simplicidad, sin embargo, puede ser complejo el acceso a los mismos, incluso la concurrencia puede verse comprometida, uno de los usos más comunes de este tipo de archivos es guardar rastros de auditoría.

￮￮

Bases de datos relacionales, que es el medio más ampliamente utilizado para el almacenamiento de información, la información se almacena en tablas y hay un conjunto de elementos que facilitan su manipulación, como los lenguajes de definición y lenguajes de consulta, lo cual las hace muy útiles para manejar grandes volúmenes de información y soportar concurrencia en miles de transacciones. Una de las desventajas son los costos.

￮￮

Bases de datos orientadas a objetos: Son motores de base de datos capaces de almacenar objetos con sus relaciones, entre las ventajas que tienen es que permiten el uso de tipos de datos abstractos, favorecen la herencia, pero por otro lado el rendimiento es muy inferior al de las bases de datos relacionales.

7.1.3.  Políticas de control de acceso En los sistemas multiusuario es necesario definir qué objetos pueden ser accedidos por los actores y que clase de acceso pueden tener en función del trabajo que deben realizar con el sistema, estas decisiones desde luego van relacionadas con los requerimientos de seguridad identificados. Los accesos se pueden representar utilizando varias técnicas, como por ejemplo una tabla “acceso global” una “lista de control de accesos” y una asociación entre el actor y su capacidad. El control de accesos también puede aplicarse a nivel de seguridad de acceso entre equipos de cómputo, para lo cual es necesario establecer un esquema que proteja sobre todo los datos, uno de los mecanismos más utilizados es el firewall que provee un control de acceso estático, o el uso de patrón de diseño proxy, para acceso dinámico. Otros mecanismos para restringir accesos son la autenticación que normalmente, ofrece acceso con contraseña y la encriptación que provee mecanismo de protección a través de algoritmos de encriptación cuyo propósito es evitar que la información sea comprendida por intrusos, para poder interpretar la información es necesario des encriptarla. 7.1.4.  Flujo de control global Este punto se refiere al orden en que deben ejecutarse las acciones del sistema, estas decisiones por lo general se toman en base a eventos externos generados por los usuarios. Existen tres posibles mecanismos de control del flujo. •

Control dirigido por procedimientos (Procedure-driven control). Este tipo de flujo de control es el comúnmente utilizado en sistemas antiguos, ya que el sistema espera por una entrada de usuario y se escriben en lenguajes procedimentales, no es muy conveniente utilizar este mecanismo cuando se trabaja con lenguajes orientados a objetos.

•

Control dirigido por eventos (Event-driven control): En este tipo de flujo de control hay un bucle principal que espera eventos externos, en cuanto se produce uno, este se asigna al objeto apropiado para resolverlo de acuerdo a la información que acompaña al evento. Este mecanismo puede causar complicaciones al momento de implementarse.

•

Hilos (Threads): Son una variación del control dirigido por procedimientos, el sistema crea un número arbitrario de hilos, cada uno respondiendo a diferentes eventos, las complicaciones en

86

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

este tipo de control de flujo pueden darse al momento de depurar la aplicación, a no ser que se disponga de buenas herramientas. 7.1.5.  Identificación de condiciones límite Las condiciones límite (boundary), permiten decidir cómo es iniciado, inicializado, y apagado, por consiguiente, es necesario dar tratamiento a las fallas de operación más importantes tales como: daños en los archivos de datos debidos a fallas del sistema, los casos de uso que atienden este tipo de fallos. Los casos de uso que establecen estas condiciones se denominan boundary use cases y, normalmente no se especifican durante el análisis, no obstante, sus funcionalidades pueden ser inferidas de las operaciones del día a día; otras son decisiones de diseño, para identificar este tipo de casos de uso puede es necesario analizar cada uno de los objetos persistentes, y podemos identificar los siguientes tipos de casos de uso: •

Configuración, se analiza cada objeto persistente buscando en qué momento se crea o se destruye, si no hay un lugar donde eso suceda, se crea un casos de uso invocado por el administrador del sistema.

•

Inicio y apagado, por cada componente añadimos un caso de uso de inicio, apagado y configuración.

•

Manejo de excepciones, por cada tipo de falla de un componente, se debe decidir cuál debería ser la reacción del sistema, se documenta cada decisión con un caso de uso que extiende los casos de uso relevantes de la fase de requerimientos. Las excepciones en general pueden ser: Fallas de hardware, cambios en el ambiente de operación o fallas de software. El manejo de excepciones es el mecanismo por el cual el sistema da tratamiento a una excepción.

En la figura 34, podemos apreciar un ejemplo de casos de uso para manejar condiciones límite para un sistema de viajes.

Figura 34. Ejemplo de casos de uso para operaciones límite. Fuente: Bruegge, B., y Dutoit, A. (2010) La Universidad Católica de Loja

87

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

7.1.6.  Validación y documentación del diseño En la ingeniería de software orientada a objetos, todos los procesos son iterativos, o al menos es la manera más efectiva de trabajar sobre ella, y a diferencia del análisis no se dispone de un cliente que esté en condiciones de revisar las diferentes versiones de los que está diseñando, y por lo tanto, es necesario implementar una estrategia de validación que permita asegurar el cumplimiento de los objetivos del proyecto. Dada la naturaleza de los insumos de diseño, lo más adecuado sería trabajar con otros desarrolladores no relacionados con el proyecto, que sean capaces de validar los resultados obtenidos de manera objetiva. Entre los aspectos que se deben validar tenemos, el cumplimiento de los requerimientos no funcionales, identificados en los objetivos del diseño, y también que el modelo sea correcto, completo, consistente, realista y comprensible. Por ejemplo, un modelo es correcto, si es posible mapear el modelo de análisis al modelo de diseño; el modelo es completo si cada requerimiento y cada incidente con el sistema ha sido direccionado; el modelo es consistente si no se identifican contradicciones; es realista si el sistema en cuestión es factible de implementarse, y es comprensible si desarrolladores no relacionados al proyecto son capaces de entenderlo. En cuanto a documentación del diseño, se debe elaborar un documento que contenga los objetivos de diseño, descomposición del sistema (diagramas de clases) mapeo de hardware y software (diagramas de implantación), administración de los datos, control de accesos, mecanismos de control del flujo y condiciones límite. Al igual que en la documentación del análisis, la siguiente puede ser una estructura para el documento de diseño. Documento de especificación del diseño del sistema 1. Introducción 1.1. Propósito del sistema 1.2. Metas de diseño 1.3. Definiciones, acrónimos, abreviaturas 1.4. Referencias 1.5. Visión general 2. Arquitectura del sistema actual

y

3. Arquitectura propuesta 3.1. Visión general 3.2. Descomposición en subsistemas 3.3. Mapeo de hardware/software 3.4. Administración de la persistencia de datos 3.5. Controles de acceso y seguridad 3.6. Control global del software 3.7. Condiciones límite 4. Servicios de subsistema Glosario

7.2. Patrones de diseño Gamma et al (1995), definen a un patrón de diseño como una descripción de clases y objetos comunicándose entre sí, adaptada para resolver un problema de diseño general en un contexto particular, tienen amplio uso en el diseño de software y su uso permite resolver una gran cantidad de problemas comunes.

88

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Se han creado diferentes tipos de patrones para diferentes propósitos, Blancarte (2016), presenta 3 tipos de patrones como son: creacionales, estructurales y de comportamiento, en la tabla 21, se listan los patrones de diseño en estas categorías. Tabla 15. Patrones de diseño de uso común. Tipo de Patrón

Patrón

Creacionales

Factory Method Abstract Factory Singleton Builder Prototype Object Pool

Estructurales

Adapter Bridge Composite Decorator Facade Flyweight Proxy

Patrones de Comportamiento:

Iterator Command Observer Templete Method Strategy Chain of Responsability Interpreter Mediator Memento Null Object State Visitor

Fuente: Blancarte, O (2016)

Para comprender este apartado le invito a tomar su texto básico, y estudiar el apartado 7.2 Patrones de diseño. Y sobre todo revisar un ejemplo de aplicación del patrón observer. Una vez que ha completado la revisión del apartado del texto básico, ya tiene una idea de lo que son los patrones y la forma como pueden ayudarnos en el diseño del software, lo importante es aplicarlos de manera efectiva en contextos específicos. Ahora le invito a complementar la información en el sitio sugerido por el autor del texto básico, http://hillside.net/ donde encontrará mayor información de referencia y libros que puede adquirir para profundizar en el tema.

La Universidad Católica de Loja

89

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

7.3. Conflictos de implementación En este apartado se estudian algunas cuestiones comunes en el desarrollo de software profesional, que deben tener un enfoque para abordarlas. Entre estas cuestiones tenemos por ejemplo la reutilización de código, que puede ahorrar mucho dinero y tiempo de desarrollo y que hoy en día es bastante común; la administración de la configuración que se preocupa por el problema del almacenamiento y control de las diferentes versiones del código que se van generando a lo largo del ciclo de desarrollo, cómo evitar conflictos entre estas sobre todo si se trabajan en equipo; y, el denominado Huésped-Objetivo, que en realidad de preocupa por las diferencias entre entorno de desarrollo y el ambiente de producción. En este momento le invito a estudiar todo el apartado 7.3 de texto básico. ¿Cómo le fue con el estudio de este apartado?, estoy seguro de que muchos de los aspectos aquí mencionados no los ha tomado en cuenta, excepto si ya tiene experiencia como desarrollador.

A continuación, se plantean algunas preguntas que le ayudarán a profundizar en estos temas. Respecto de la reutilización de software. 1.

Este aspecto aborda el problema de completar el desarrollo en el menor tiempo posible y minimizando costos. ¿Si los costos de producir el software se reducen a cero, en qué costos podría incurrirse? ¿De qué dependen estos costos?

2.

¿A cuántos niveles se puede reutilizar el software? ¿Cuál es el más conveniente? ¿Cuál podría resultar más complejo? ¿Cuál el más costoso?

3.

¿Qué métodos se pueden utilizar para determinar si una pieza de código es reutilizable? ¿En qué parte del diseño se debe evaluar esta posibilidad?

4.

¿Se puede considerar al código abierto como software reutilizable?

Respecto de la administración de la configuración. 1.

¿Qué problemas resuelve la administración de la configuración?

2.

¿Es conveniente utilizar este tipo de herramientas cuando hay solo 1 o 2 desarrolladores?

3.

¿Qué tan costoso resulta trabajar con estas herramientas?

Respecto del desarrollo huésped-objetivo 1.

¿Qué estrategias se pueden utilizar para reducir el problema de incompatibilidad entre la plataforma de desarrollo y la plataforma de ejecución?

2.

¿Con las plataformas web, móviles o soluciones en la nube, qué efecto tendría el problema planteado sobre huésped-objetivo?

Con estas reflexiones, se cierra la unidad, recuerde que el proceso de diseño implica la aplicación de muchos principios y sobre todo de mucha creatividad.

90

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

Si ha tenido problemas sobre todo con los modelos desarrollados en UML, le invito a revisar nuevamente el capítulo de modelado con UML del primer bimestre, y buscar información complementaria en la bibliografía recomendada. ACTIVIDAD RECOMENDADA

Para el caso planteado en la Unidad 6, proponga un diagrama de despliegue donde se visualice la operación tanto del servidor como de los usuarios del servicio en las diferentes versiones web, cliente local.

La Universidad Católica de Loja

91

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Autoevaluación 7

Una vez concluida la unidad, pasemos a desarrollar la autoevaluación número 7. Le recuerdo nuevamente que en esta sección se recogen los aspectos importantes de la Unidad, sin embargo, con ese número de preguntas no se puede cubrir todos los contenidos. Seleccione la alternativa correcta en cada uno de las siguientes preguntas: 1.

2.

3.

4.

5.

92

Una de las preocupaciones del diseño, es la definición de objetivos de diseño. Estos objetivos de diseño ¿Con cuál de los siguientes aspectos se encuentra más relacionado? a.

Requerimientos funcionales

b.

Requerimientos no funcionales

c.

Necesidades de usuario

Cuando se modela el contexto del sistema ¿Cuál de las siguientes alternativas describe en qué consiste el contexto? a.

Los sistemas externos con los cuales se relaciona el sistema.

b.

Las condicionantes internos y condiciones límite del sistema.

c.

Las restricciones impuestas por el usuario.

El propósito del diseño arquitectónico es: a.

Identificar los casos de uso que serán atendidos por el sistema.

b.

Identificar las clases que resuelven las necesidades del usuario.

c.

Identificar subsistemas que conformarán el sistema.

Los modelos de diseño comprenden tres tipos de modelos. ¿A qué categoría corresponden aquellos que representan cómo los objetos individuales cambian en respuesta a eventos? a.

De subsistema

b.

De secuencia

c.

De máquina de estados

¿En qué tipo de diagramas de UML se representan los dispositivos donde se instalarán los componentes y las relaciones entre ellos? a.

Diagrama de componentes.

b.

Diagrama de implantación.

c.

Diagrama de actividades.

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

6.

7.

8.

9.

10.

Guía Didáctica: Fundamentos de Ingeniería de Software

¿Cuál de los siguientes elementos es un candidato obvio para ser almacenado de manera persistente? a.

Objetos Entidad.

b.

Objetos interfaz.

c.

Objetos de control.

¿Qué problema pueden tener las bases de datos orientadas a objetos al momento de almacenar la información persistente? a.

Pueden representar tanto los objetos como sus relaciones.

b.

Son difíciles de implementar.

c.

El rendimiento es bajo.

¿Qué beneficio ofrece la protección con encriptación? a.

Se necesita des encriptarla para leerla.

b.

Es muy rápida de obtener el código encriptado.

c.

Si alguien logra robarla, no la podrá entender.

¿Cómo ayudan al proceso de diseño los patrones? a.

Proveen soluciones específicas para problemas generales.

b.

Proveen soluciones generales a problemas particulares.

c.

Ayudan a identificar componentes de software para resolver problemas de diseño.

¿Qué beneficio ofrecen las herramientas de administración de la configuración al trabajo en equipo? a.

Proveen estándares de codificación.

b.

Almacenan la información del proyecto en un repositorio central.

c.

Evitan conflictos de uso de código por parte de varios programadores.

La Universidad Católica de Loja

93

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

UNIDAD 8. PRUEBAS DE SOFTWARE Una vez que se conoce la forma de diseñar y posteriormente implementar un sistema de software, se puede aplicar diferentes enfoques para asegurar su liberación o despliegue cumpliendo con los requerimientos en un nivel de calidad aceptable o cumpla con las especificaciones. El propósito de las pruebas es demostrar que el sistema hace lo que debe, identificar defectos antes de que lleguen a manos del usuario, para lo cual se aplica diferentes enfoques y pruebas que son el objeto de estudio de esta Unidad. Para comenzar, acuda a su texto básico y realice una lectura comprensiva de la parte introductoria del capítulo 8. En este apartado encontrará de especificación de los objetivos de las pruebas y una orientación general de todo el proceso. Si ya ha completado la lectura, puede identificar ¿cuáles son las metas de los procesos de pruebas? Dijkstra (1972), indica que las pruebas pueden mostrar sólo la presencia de errores, mas no su ausencia. Ello nos da a entender que el proceso de pruebas debe ser exhaustivo sin garantía de éxito al 100%, de hecho, en este tipo de pruebas cuando se detectan muchos errores, se dice que hay un buen trabajo, pero si no se detectan errores quedan dudas del trabajo realizado. A lo largo de la presente Unidad, se revisará distintas estrategias de prueba aplicables durante el ciclo de desarrollo de las aplicaciones y previo a su puesta en producción.

8.1. Conceptos relacionados a las pruebas En este apartado se revisarán algunos conceptos asociados a las pruebas del software, que sobre todo ayudarán a comprender los procesos a estudiar. Para desarrollar este apartado, se tomarán algunos conceptos de pruebas del software tomados de Sánchez, Sicilia y Rodriguez (2012), y para simplificar la comprensión se desarrollará a manera de glosario. Prueba de software: Es todo proceso orientado a comprobar la calidad del software mediante la identificación de fallos en el mismo. La prueba implica necesariamente la ejecución del software. Caso de prueba: Es un conjunto de entradas, condiciones de ejecución y resultados esperados, que han sido desarrollados para un objetivo particular como, por ejemplo, ejercitar un camino concreto de un programa o verificar el cumplimiento de un determinado requisito. Prueba exhaustiva/completa: Prueba ideal que proporciona la seguridad de que se han comprobado todas y cada una de las posibles causas de fallo. Fallo: Es un efecto indeseado observado en las funciones o prestaciones desempeñadas por un software. Error (defecto): Es una imperfección en el software que provoca un funcionamiento incorrecto del mismo. Probar: Proceso de mostrar la presencia de un error en el software.

94

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

Depurar: Descubrir en qué lugar exacto se encuentra un error y modificar el software para eliminar dicho error. Oráculo: Cualquier agente (humano o no) capaz de decidir si un programa se comporta correctamente durante una prueba y, por tanto, capaz de dictaminar si la prueba se ha superado o no. Trazabilidad: Capacidad para interrelacionar dos o más entidades, inequívocamente identificables, dentro de una cadena de sucesos cronológicamente ordenada.

8.2. Pruebas de desarrollo Las pruebas de desarrollo son las que se realiza por parte de los desarrolladores, corresponden a 4 categorías identificadas, las cuales se encuentran descritas en el texto básico. Pero antes de estudiar a detalle en qué consisten las pruebas, en la figura 35, los autores Sánchez, Sicilia, y Rodríguez (2012), proponen un esquema sobre los niveles a los que se aplican las pruebas.

Figura 35. Niveles a los que se aplican las pruebas de software Fuente: Sánchez, S., Sicilia, M., y Rodriguez, D. (2012)

Según la ilustración, tenemos pruebas unitarias, que se aplican a elementos o módulos individuales, luego a nivel de componente y finalmente a nivel de sistema. Remítase al texto básico, y estudie al apartado 8.1 en el que podrá estudiar en qué consisten las pruebas de desarrollo. Una vez que ha terminado de revisar este apartado, realizaremos algunas puntualizaciones respecto de los tipos de prueba estudiados. 8.2.1.  Pruebas de Unidad Tienen como propósito probar un módulo concreto con el fin de determinar de forma aislada si el mismo cumple con la especificación con la que fue creado, este mismo proceso se aplica a todos los elementos individuales y con ello se intenta asegurar que todos cumplen con su especificación, sin pensar en la colaboración con otros. El desarrollo de este tipo de pruebas, puede tomar mucho tiempo y resultar costoso, por lo que de ser posible es recomendable utilizar herramientas de software que permitan automatizar este proceso. La Universidad Católica de Loja

95

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Para poder realizar estas pruebas, es evidente que necesitamos definir los casos de prueba, para ello se proponen dos estrategias denominada pruebas de partición y las pruebas basadas en lineamientos, estos escenarios de prueba tal como se plantea en el apartado 8.1.2 del texto básico deben tener identificadas las variables de entrada y las salidas correctas, además, para los datos de entrada, se requiere datos de la operación normal y datos extremos para verificar el comportamiento del componente tanto en condiciones normales como en condiciones extremas de operación. Revise el ejemplo de las pruebas unitarias de la estación meteorológica, en el mismo se puede apreciar los eventos de prueba que deberían aplicarse al objeto interfaz EstacionMeteorológica. 8.2.2.  Pruebas de componentes El siguiente nivel de pruebas, son las pruebas de componentes, los componentes en este caso pueden ser subsistemas que se forman al combinar varias clases o conforme se haya establecido en el diseño. Una característica particular de este tipo de pruebas y la diferencia de las pruebas de unidad, es que se enfocan en probar las interfaces de las piezas individuales, para ello utilizan varias estrategias que permiten determinar si los componentes individuales colaboran correctamente entre sí. Las interfaces pueden ser de diferente tipo, y por tanto es necesario diseñar pruebas para cada una de ellos, por ejemplo, si estamos verificando una interfaz de parámetro, será necesario determinar el funcionamiento correcto de la interfaz colocando casos de prueba en cada uno de ellos, verificando el número de parámetros, los tipos de datos que pasan y si en general el componente los procesa para obtener resultados correctos. La recomendación para realizar este tipo de pruebas, es identificar el tipo de interfaz y por cada una de ellas establecer escenarios de prueba válidos. A este tipo de pruebas también se las conoce como pruebas de integración, y es necesario recalcar que son pruebas incrementales a lo largo del ciclo de desarrollo del producto, el texto básico amplia sobre este tipo de pruebas en https://ifs.host.cs.st-andrews.ac.uk/Books/SE9/Web/Testing/Integration. html del cual se muestra la estrategia incremental en la figura 36. Es decir, por cada componente que se agrega, es necesario realizar todas las pruebas, para determinar si el sistema se comporta correctamente con la inclusión del nuevo componente. En la figura los recuadros con las letras son los componentes y los círculos representan los Test que se hacen en cada secuencia de pruebas.

Figura 36. Estrategia incremental para pruebas de integración. Fuente: Sánchez, S., Sicilia, M., y Rodriguez, D. (2012)

96

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

Guía Didáctica: Fundamentos de Ingeniería de Software

Sánchez, Sicilia, y Rodriguez (2012), añaden que estas pruebas se pueden realizar de tres maneras diferentes. 1.

Integración ascendente, que consiste en incluir primero los componentes de infraestructura y progresivamente ir añadiendo los componentes funcionales, lo cual significa que se empieza por probar en una primera pasada los componentes de menor nivel, luego los que son invocados por los anteriores y así hasta llegar al nivel más alto. Esta estrategia se puede apreciar en la figura 37.

Figura 37. Estrategia incremental ascendente para pruebas de integración. Fuente: Sánchez, S., Sicilia, M., y Rodriguez, D. (2012)

2.

Integración descendente, en la cual se desarrolla un esqueleto del sistema al que se añaden componentes de manera progresiva, para ello se empieza probando en primera instancia el componente de más alto nivel, luego los que dicho componente utiliza y así hasta llegar hasta los de más bajo nivel, como se aprecia en la figura 38.

Figura 38. Estrategia incremental descendente para pruebas de integración. Fuente: Sánchez, S., Sicilia, M., y Rodriguez, D. (2012)

3.

Estrategia combinada, en la cual se combinan las dos estrategias, el sistema se presente como un sándwich con 3 capas, la capa central es la que se desea probar, y mediante enfoque ascendente para probar la capa central, asumiendo que la inferior ya ha sido implementada, y se desciende a la capa de prueba desde la capa superior.

La Universidad Católica de Loja

97

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

8.2.3.  Pruebas de sistema El siguiente nivel de las pruebas, son las pruebas del sistema. En este punto la mayoría de fallos debieron haberse identificado y por tanto es necesario comprobar si el sistema completo satisface las especificaciones antes de pasar a producción. Sánchez, Sicilia, y Rodriguez (2012), sostienen que estas pruebas se enfocan en aspectos como la seguridad, la velocidad, la exactitud, la fiabilidad, interconexiones externas con otras aplicaciones, utilidades, dispositivos hardware o con el sistema operativo, y que las pruebas deben enfocarse desde las siguientes perspectivas: 1.

Pruebas de funcionalidad y operativa: Buscan determinar si se cumple con las especificaciones funcionales dadas, son pruebas de caja negra.

2.

Pruebas de rendimiento: Comprueban el cumplimiento de los requisitos no funcionales, por tanto, incluyen pruebas de desgaste que sirven para determinar el comportamiento del sistema cuando se lo pone a operar en sus límites; pruebas de volumen, que se realizan sobrecargando al sistema con datos; pruebas de configuración, que sirven para determinar el comportamiento en diferentes plataformas, además se realizan pruebas de compatibilidad, de regresión, de seguridad, de recuperación.

3.

Pruebas de aceptación: Una vez que se ha determinado que el sistema cumple con todas las especificaciones, estas pruebas se realizan con los usuarios, quienes establecen los casos de prueba. Estas pruebas pueden ser de benchmarking o de comparación con valores de referencia, pruebas piloto en cuyo caso, se realiza una instalación para en un entorno controlado para determinar el comportamiento del sistema y proyectarlo al entorno real, además de las pruebas alfa, beta y pruebas en paralelo.

4.

Pruebas de instalación: Consisten en realizar las pruebas necesarias para asegurar que el sistema se instala correctamente, se debe probar todas las opciones de instalación y desinstalación.

Una vez que se ha revisado todo el panorama del proceso y tipos de pruebas , en la figura 39, se expone los diferentes niveles a los que se realizan y la relación de las mismas con las etapas del ciclo de vida.

Figura 39. Niveles a los que se realizan las pruebas. Fuente: Sánchez, S., Sicilia, M., y Rodriguez, D. (2012)

Para complementar información sobre este tipo de pruebas, sírvase revisar la sección 8.2 del texto básico, donde se mostrarán mayores detalles sobre la realización de las pruebas e incluye información sobre lo que sucede con las metodologías ágiles.

98

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Anteriormente se recomendó trabajar con herramientas para la realización de pruebas Unitarias, en este punto, para desarrolladores java, se recomienda utilizar JUnit, que la puede encontrar en el sitio http:// junit.org/junit5/

8.3. Actividades y gestión de las pruebas Las pruebas de software son una actividad necesaria que implica en muchos casos trabajo de equipos paralelos y el uso de técnicas y herramientas, por este motivo es necesario organizar las actividades de pruebas para monitorear el avance y los resultados obtenidos, por tanto, no se trata de actividades marginales, sino que a medida que se incrementa la importancia, el tamaño y la criticidad del producto, se torna cada vez más importante y se necesitan dos enfoques: 1.

Orientación individual hacia la calidad: en el cual todo el equipo de desarrollo está implicado y realizan tanto el desarrollo como las pruebas unitarias correspondientes.

2.

Equipo de aseguramiento de calidad: en el cual se conforma un equipo independiente del de desarrollo, y son quienes se encargan de hacer pruebas a distintos niveles, principalmente las pruebas del sistema.

Es necesario medir el avance de las pruebas, y la estabilidad que se consigue con los productos o componentes completados, por ello es necesario analizar las métricas asociadas al proceso de pruebas. Los autores Sánchez, Sicilia, y Rodriguez (2012), consideran que las métricas son útiles para realizar estimaciones, proporcionan información para controlar el propio proceso y facilitan la identificación de riegos asociados al producto, entre otros beneficios. A continuación, se describen las métricas obtenidas durante el proceso de pruebas, y las que miden el mismo proceso de pruebas. 8.3.1.  Medidas durante las pruebas Son medidas útiles para la planificación y diseño de pruebas de programas, permiten clasificar analizar los errores, establecer la densidad de los fallos o también determinar si se debe continuar o no con las pruebas. En la tabla 22, se resumen las medidas utilizadas en esta categoría. Tabla 16. Medidas durante las pruebas Tipos de medidas

Descripción

Métricas

Dirección de las pruebas

Ayudan en la planificación y diseño de pruebas de programas.

–– Tamaño (Líneas de código) –– Estructura (Complejidad)

Tendencias

Muestran las tendencias en base a los casos de prueba.

–– Número de defectos sin resolver

Efectividad

Permiten medir el aumento de la efectividad

–– Tipos de errores detectados –– Frecuencia de aparición.

Densidad de fallos

Permiten comparar un módulo con otros.

–– Número de Errores descubiertos. –– Razón entre errores y tamaño del programa.

La Universidad Católica de Loja

99

Guía Didáctica: Fundamentos de Ingeniería de Software

Tipos de medidas

Descripción

SEGUNDO BIMESTRE

Métricas

Conclusión de pruebas

Determinan si las pruebas ya pueden darse por terminadas.

–– Fiabilidad del software

Crecimiento de la fiabilidad

Permiten estimar la tasa de fallos

–– Tasa de fallos

Fuente: Sánchez, S., Sicilia, M., y Rodriguez, D. (2012)

En general, la intención de estas mediciones es determinar si el producto evoluciona hacia una versión más estable. En la figura 40, se puede apreciar cómo se debe ver la tendencia en las pruebas realizadas.

Figura 40. Evolución de la tasa de fallos en sistemas de software Fuente: Sánchez, S., Sicilia, M., y Rodriguez, D. (2012)

8.3.2.  Evaluación de las pruebas realizadas Este tipo de medidas son útiles para el propio proceso de desarrollo en curso y para procesos futuros: ––

Evaluación de la cobertura, sirven para determinar el nivel de compleción de las pruebas mediante comparación de los elementos cubiertos con el número total.

––

Estimación de errores, la inclusión de errores ficticios, sirve para comprobar cuántos de estos errores son detectados, con ello se determina cuántos errores genuinos no se detectan.

––

Medición de la efectividad, la relación entre el número de mutantes (modificaciones de código para determinar si se encuentra el fallo en las pruebas), en especial el número de mutantes identificados y el total de mutantes generados, se usa como medida de efectividad.

––

Estudio de adecuación de las pruebas, Mide la efectividad relativa de las diferentes técnicas de prueba, sirve para determinar cuál es la técnica más adecuada en determinadas situaciones.

8.3.3.  El proceso de prueba Para integrar todos los aspectos que implica la realización de las pruebas, es necesario elaborar un Plan de Gestión de Pruebas, el cual se puede desarrollar considerando los siguientes aspectos: ––

Finalidad de la guía del proceso Se debe explicar el propósito de la realización de las pruebas, ya que en función de este propósito se deciden los escenarios de pruebas.

100

MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

––

Guía Didáctica: Fundamentos de Ingeniería de Software

Gestión del proceso de prueba Se establece quienes serán las personas responsables, cuando se aplicarán las pruebas, las herramientas que se usarán, normas aplicables, medidas que se usarán como referencia, todo enmarcado en el ciclo de vida del software.

––

Documentación y productos de las pruebas Todo el proceso de pruebas debe ser formal, se puede usar estándares como el IEEE829 cuyo formato se coloca en el anexo 2.

––

Estructura del equipo de pruebas Se refiere al grupo de personas que se harán cargo de las pruebas, pueden ser miembros internos, no necesariamente parte del equipo de desarrollo, el contar con un equipo interno, puede facilitar las cosas debido a que son personas que ya se conocen y conocen el sistema que se está desarrollando, no obstante, también pueden ser recomendable trabajar con equipos externos, que pueden aportar una visión independiente y sin prejuicios sobre lo que se está probando, aunque ello redunde en costos más elevados, de hecho alguno autores sugieren que los equipos externos actuarán sin compromisos con el equipo de desarrollo. Cabe acotar aquí la decisión final sobre cómo se constituirá el equipo depende también del presupuesto y de las metodologías que se apliquen tanto para el desarrollo como para las pruebas.

––

Medidas del proceso El uso de medidas o métricas del proceso siempre ayuda a mejorar el proceso de pruebas, también para obtener información histórica que pueda utilizarse para mejorar proyectos futuros, entre otras cosas las medidas deben ser útiles para determinar si las actividades de prueba han sido eficaces, identificar las más eficientes, cuáles técnicas nos han provisto de mejores resultados.

––

Fin del proceso de pruebas. El fin del proceso de pruebas está supeditado a factores como el nivel de calidad deseado, los costos y los niveles de riesgo que se podría identificar en determinado momento. Además, se debe tener en cuenta que el número de defectos identificados tiende a disminuir con el tiempo, como se muestra en la figura 43, además los equipos de pruebas tienen suficiente experiencia como para realizar procesos de prueba más efectivos.

Se ha concluido la unidad, y también el contenido de la asignatura, con toda seguridad, el estudio de estos temas le será de mucha utilidad, sobre todo si usted trabaja o piensa trabajar con áreas de desarrollo de software, revise nuevamente los temas indicados, busque la bibliografía recomendada y consulte a su tutor cualquier duda que tenga respecto del contenido del texto, la guía o cualquier otro material.

La Universidad Católica de Loja

101

Guía Didáctica: Fundamentos de Ingeniería de Software

SEGUNDO BIMESTRE

Autoevaluación 8

Estimado estudiante con esto se termina la presente unidad, ahora le invito a desarrollar la autoevaluación de la Unidad 8. Recuerde que puede verificar los resultados al final de la guía didáctica, y si alguna pregunta no le queda clara revise nuevamente la sección correspondiente o contáctese con su tutor. Sírvase responder a las siguientes interrogantes, seleccionado la alternativa correcta: 1.

2.

3.

4.

5.

102

¿La diferencia entre verificación y validación es? a.

No hay diferencia, son sinónimos.

b.

La verificación sirve para determinar si el producto cumple con las expectativas del cliente y la validación si el producto se construyó correctamente.

c.

La verificación sirve para determinar si el producto se construyó correctamente y la validación si el producto cumple con las expectativas del cliente.

Según Prowel et al (1999), más del 90% de defectos pueden encontrarse realizando inspecciones, sin embargo, en la práctica estas no resultan tan buenas. Señale el motivo por el que pueden verse afectadas estas previsiones. a.

Las inspecciones no consideran las interfaces entre componentes.

b.

Las inspecciones permiten analizar código, y este no es claro para los responsables de las pruebas.

c.

Suele ser muy complejo reunir un equipo para realizar las inspecciones.

Usted lidera un equipo de proyecto para desarrollar software, y en los primeros componentes de software liberados para pruebas, encuentra cientos de errores que son identificados por los equipos de pruebas cada vez más rápido. Este es un claro indicio de: a.

Curva normal de detección de errores.

b.

Riesgo de errores en componentes futuros.

c.

La experiencia del equipo de pruebas minimiza los errores.

¿Cuál de las siguientes alternativas expresa el significado de la palabra “fallo” en el contexto de las pruebas del software? a.

Descripción de los resultados de las pruebas realizadas.

b.

Imperfección del software.

c.

Efecto indeseado en las funciones o prestaciones del sistema.

¿A qué nivel se desarrollan las pruebas que toman un objeto o una operación de un objeto para determinar si cumple con la especificación? a.

Componentes

b.

Integración

c.

Sistema MODALIDAD ABIERTA Y A DISTANCIA

SEGUNDO BIMESTRE

6.

7.

8.

9.

10.

Guía Didáctica: Fundamentos de Ingeniería de Software

¿Cuál es el objetivo de las pruebas de componentes? a.

Determinar si los componentes cumplen con las especificaciones.

b.

Valorar la usabilidad del componente.

c.

Determinar si las interfaces funcionan correctamente.

Cuando se realizan pruebas de integración, una de las estrategias recomendadas es la de realizar pruebas incrementales. ¿En qué consiste esta estrategia? a.

Probar un grupo de componentes dejándolos ya certificados, conforme avanza del desarrollo agregar los nuevos y así sucesivamente.

b.

La igual que en las metodologías ágiles, implica ir a la par que en el desarrollo, desarrollar – probar – implantar y avanzar con el siguiente grupo de entregables.

c.

Por cada nuevo componente que se agrega, es necesario probar todos.

Entre las estrategias de pruebas incrementales, tenemos la ascendente, descendente y combinada. ¿Cuál de ellas utiliza tres capas de componentes? a.

Combinada

b.

Ascendente

c.

Descendente

¿En cuáles de los siguientes aspectos se centran las pruebas del sistema? a.

Integración de componentes

b.

Seguridad, velocidad, exactitud

c.

Las interfaces.

En relación al equipo de pruebas del sistema ¿Cuál es la ventaja más significativa que se tiene si el equipo es externo? a.

La independencia para generar los resultados.

b.

El desconocimiento del sistema.

c.

El equipo interno se puede dedicar de lleno al desarrollo.

La Universidad Católica de Loja

103

Guía Didáctica: Fundamentos de Ingeniería de Software

7.

SOLUCIONARIO

Solucionario

A continuación, se presentan las claves de respuesta a las autoevaluaciones que constan en cada unidad. PRIMER BIMESTRE

AUTOEVALUACIÓN Nº 1

104

Pregunta

Respuesta Correcta

1.

C

2.

A

3.

B

4.

A

5.

B

6.

A

7.

A

8.

C

9.

B

10.

B

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

SOLUCIONARIO

AUTOEVALUACIÓN Nº 2

La Universidad Católica de Loja

Pregunta

Respuesta Correcta

1.

A

2.

A

3.

B

4.

C

5.

B

6.

C

7.

A

8.

C

9.

B

10.

B

105

Guía Didáctica: Fundamentos de Ingeniería de Software

SOLUCIONARIO

AUTOEVALUACIÓN Nº 3

106

Pregunta

Respuesta Correcta

1.

A

2.

B

3.

C

4.

A

5.

B

6.

B

7.

A

8.

C

9.

C

10.

A

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

SOLUCIONARIO

AUTOEVALUACIÓN Nº 4

La Universidad Católica de Loja

Pregunta

Respuesta Correcta

1.

C

2.

B

3.

C

4.

C

5.

A

6.

A

7.

B

8.

C

9.

A

10.

B

107

Guía Didáctica: Fundamentos de Ingeniería de Software

SOLUCIONARIO

SEGUNDO BIMESTRE

AUTOEVALUACIÓN Nº 5

108

Pregunta

Respuesta Correcta

1.

B

2.

C

3.

A

4.

C

5.

A,D,F

6.

A

7.

B

8.

A

9.

C

10.

B

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

SOLUCIONARIO

AUTOEVALUACIÓN Nº 6

La Universidad Católica de Loja

Pregunta

Respuesta Correcta

1.

B

2.

C

3.

A

4.

A

5.

C

6.

A

7.

C

8.

B

9.

C

10.

B

109

Guía Didáctica: Fundamentos de Ingeniería de Software

SOLUCIONARIO

AUTOEVALUACIÓN Nº 7

110

Pregunta

Respuesta Correcta

1.

B

2.

A

3.

C

4.

C

5.

B

6.

A

7.

C

8.

C

9.

B

10.

C

MODALIDAD ABIERTA Y A DISTANCIA

Guía Didáctica: Fundamentos de Ingeniería de Software

SOLUCIONARIO

AUTOEVALUACIÓN Nº 8

La Universidad Católica de Loja

Pregunta

Respuesta Correcta

1.

C

2.

A

3.

B

4.

C

5.

A

6.

C

7.

C

8.

A

9.

B

10.

A

111

Guía Didáctica: Fundamentos de Ingeniería de Software

8.

GLOSARIO

Glosario

Alcance Identifica y limita lo que hará el sistema como parte del nuevo proyecto de desarrollo. Analista de negocios(BA) Es el rol en un equipo de proyecto que tiene la responsabilidad de interactuar con los representantes de los interesados para obtener, analizar, especificar, validar y administrar los requisitos del proyecto. También se lo denomina analista de requisitos, analista de sistemas, ingeniero de requisitos, administrador de requisitos, analista de sistemas de negocios o simplemente analista. Arquitectura de software Es la estructura del sistema, la cual comprende elementos de software, las propiedades eternamente visibles de esos elementos y las relaciones entre ellos. Diagrama de contexto Es un modelo de análisis que representa un sistema con un alto nivel de abstracción. El diagrama de contexto identifica objetos fuera del sistema que intercambian datos con el sistema, pero no muestra nada sobre la estructura interna o el comportamiento del sistema. Modelo 4+ 1 Vistas Modelo desarrollado por Philippe Krutchen, que describe la arquitectura del software usando cinco vistas concurrentes, cada vista se refiere a un conjunto de intereses de diferentes stakeholders del sistema: vista lógica que describe el modelo de objetos del diseño, vista de procesos que describe los aspectos de concurrencia y sincronización del diseño, vista física que describe el mapeo del software en el hardware y refleja los aspectos de distribución, y la vista de desarrollo describe la organización estática del software en su ambiente de desarrollo. A esta vista se agrega la vista de escenarios que representa una abstracción de los requisitos más importantes. Objetivo de negocio Un beneficio comercial financiero o no financiero que una organización espera recibir como resultado de un proyecto o alguna otra iniciativa. Patrón arquitectónico Son un conjunto responsabilidades, reglas y directrices que se utilizan para expresar una estructura de organización base o esquema para un software, que sirven para determinar la organización, comunicación, interacción y relaciones entre ellos. Patrón de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software, brindan una solución ya probada y documentada a problemas de desarrollo de software que están sujetos a contextos similares.

112

MODALIDAD ABIERTA Y A DISTANCIA

GLOSARIO

Guía Didáctica: Fundamentos de Ingeniería de Software

Product champion Término utilizado para identificar a un representante de una clase de usuario específica que proporciona los requisitos de usuario para el grupo que representa. Requisito Circunstancia o condición necesaria para algo. Es un concepto amplio que podría referirse a cualquier función, atributo, capacidad, característica o calidad necesaria de un sistema para que tenga valor y utilidad para un cliente, organización, usuario interno u otro interesado. Se usa comúnmente en un sentido formal en el diseño de ingeniería, que incluye, por ejemplo, ingeniería de sistemas, ingeniería de software o ingeniería empresarial. Requisitos de negocio Un conjunto de información que describe una necesidad comercial y que conducen a uno o más proyectos para entregar una solución con los resultados deseados. Los requisitos del negocio incluyen oportunidades comerciales, objetivos comerciales, métricas de éxito, una declaración de visión y alcance y limitaciones. Stakeholder Término utilizado para identificar a una persona, grupo u organización que tiene interés o preocupación en una organización. Los interesados pueden afectar o ser afectados por las acciones, objetivos y políticas de la organización. Es común utilizar el término en inglés o su equivalente en español (Interesado). UML Abreviatura en inglés del lenguaje de modelado unificado, que describe un conjunto de notaciones estándar para crear varios modelos visuales de sistemas, particularmente para el desarrollo de software orientado a objetos. Visión Es una declaración que describe el concepto estratégico o el propósito final y la forma de un nuevo sistema.

La Universidad Católica de Loja

113

Guía Didáctica: Fundamentos de Ingeniería de Software

9.

REFERENCIAS BIBLIOGRÁFICAS

Referencias bibliográficas

•

Bruegge, B., y Dutoit, H. (2010). Object-Oriented Software Engineering Using UML, Patterns, and Java. United States: Prentice Hall.

•

SWEBOK. (2014). Guide to the Software Engineering Body of Knowledge. IEEE.

•

Braude, E., y Bernstein, M. (2016). Software Engineering. Modern Approaches. Waveland Press.

•

Raval, R., y Rathod, H. (2013). Comparative Study of Various Process Model in Software Development. International Journal of Computer Applications.

•

Gottesdiener, E. (2005). The Software Requirements - Memory Jogger. GOAL/QPC.

•

Rodriguez, C. (2017). Metodologías Ágiles, objetivos, características, ventajas. Recuperado de http:// comunidad.iebschool.com/metodologiasagiles/general/concepto-metodologias-agiles/

•

Sánchez, S., Sicilia, M., y Rodríguez, D. (2012). Ingeniería de Software. Un enfoque desde la guía SWEBOK. México. Alfaomega.

•

Rumbaugh, J., Jacobson, I., y Booch, G. (2005). The Unified Modeling Language, Reference Manual. United States. Addison-Wesley.

•

Blancarte, O. (2016). Introducción a los patrones arquitectónicos. Un enfoque práctico. Mexico. Oscar Javier Blancarte Iturralde.

•

Object Management Group. OMG Unified Modeling Language (OMG UML). V 2.5. [online]. Marzo 2015. Available: http://www.omg.org/spec/UML/2.5

•

Dijkstra, E. (1972) Chapter I: Notes on structured programming, Structured programming, Academic Press Ltd., London, UK.

•

Gamma, E., Helm, R., Johnson, R., y Vlissides, J. Design Patterns. (1995). Elements of resusable object-oriented software. Unted States. Addison-Wesley Professional Computing Series

114

MODALIDAD ABIERTA Y A DISTANCIA

DI CTI ONARY

TH ESA UR US

ANEXOS

Guía Didáctica: Fundamentos de Ingeniería de Software

10. Anexos

Anexo 1: Plantilla para documentar los requisitos de software según Wiegers y Beatty (2013)

La Universidad Católica de Loja

115

Guía Didáctica: Fundamentos de Ingeniería de Software

ANEXOS

Anexo 2: ESQUEMA DEL PLAN DE PRUEBA SEGÚN ESTÁNDAR IEEE829 1. Identificador del Plan de Pruebas 2. Referencias 3. Introducción 4. Elementos de prueba (funciones) 5. Problemas de riesgo de software 6. Características que no serán probadas 7. Enfoque (Estrategia) 8. Criterios de Elementos Aprobados/Fallidos 9. Criterios de Suspensión y Requisitos de Reanudación 10. Entregables de las Prueba 11. Tareas de prueba restantes 12. Necesidades del Entorno 13. Necesidades de personal y de capacitación 14. Responsabilidades 15. Cronograma 16. Planificación de riesgos y contingencias 17. Aprobaciones 18. Glosario

116

MODALIDAD ABIERTA Y A DISTANCIA