Modulo Ingenieria Del Software II 4.0

UNIVERSIDAD TECNOLGICA SAN ANTONIO DE MACHALA
MODALIDAD DE EDUCACIN SEMIPRESENCIAL Y A DISTANCIA
ESCUELA DE INFORMTICA
ESCUELA DE INFORMTICA INGENIERA EN SISTEMAS
INGENIERA DE SOFTWARE II
ING. LEWIS CHIMARRO CHIPANTIZA
EL ORO - ECUADOR
[INGENIERIA DEL SOFTWARE II]
TABLA DE CONTENIDO
ANALISIS Y DISEO ESTRUCTURADO DEL SOFTWARE ............................................................................ 19 CODIFICACIN ........................................................................................................................................................ 46 CONCEPTOS DEL PARADIGMA ORIENTADO A OBJETOS ......................................................................... 57 DEPURACIN DE LOS ERRORES, FALLOS Y DEFECTOS ENCONTRADOS EN EL SOFTWARE .... 51 EL ANLISIS ESTRUCTURADO .......................................................................................................................... 20 EL DISEO ESTRUCTURADO.............................................................................................................................. 26 EL PARADIGMA ORIENTADO A OBJETOS ...................................................................................................... 57 EL PROCESO DE LA INGENIERIA DEL SOFTWARE Y SU GESTION ......................................................... 4 GESTIN DEL PROYECTO DE SOFTWARE ....................................................................................................... 6 IMPLANTACIN DEL SOFTWARE ...................................................................................................................... 53 IMPLEMENTACION, PRUEBAS Y MANTENIMIENTO DEL SOFTWARE ..................................................... 46 INGENIERA DE REQUISITOS ................................................................................................................................ 5 INGENIERA DE SOFTWARE ORIENTADOS A OBJETOS ............................................................................ 57 LENGUAJE UNIFICADO DE MODELADO (UML): DIAGRAMAS DE: CASOS DE USO, SECUENCIA, COLABORACIN, ACTIVIDADES, CLASES, OBJETOS, ESTADOS, COMPONENTES E INTEGRACIN..................................................................................................................................................... 76 Mantenimiento del software ................................................................................................................................. 54 MANUALES TCNICO, DE INSTALACIN Y DE USUARIO .......................................................................... 52 METODOLOGAS ORIENTADAS A OBJETOS ................................................................................................. 59 REVISIN Y EJECUCIN DEL PLAN DE PRUEBAS ...................................................................................... 48
UTSAM-Modalidad Semipresencial y a Distancia
Unidad Didctica I EL PROCESO DE LA INGENIERA DEL SOFTWARE Y SU GESTION
UNIDAD DIDACTICA I: EL PROCESO DE LA INGENIERA DEL SOFTWARE Y SU GESTIN OBJETIVO: Gestionar un proyecto de desarrollo de software aplicando estndares de documentacin, la especificacin de requisitos, principios de gestin para un adecuado seguimiento y control de cada proceso de ingeniera de software.
1. EL PROCESO DE LA INGENIERA DEL SOFTWARE Y SU GESTION 1.1. AMBITO DEL SOFTWARE (Estudio Preliminar)
En el estudio preliminar se debe determinar cul ser el mbito de desarrollo del software, esto ayudar a centrarse en los departamentos donde se va a realizar el respectivo levantamiento de requisitos durante la etapa siguiente. Todos los puntos dentro del estudio preliminar son importantes, pero a continuacin se detallarn algunos en los cuales se prestar mucha atencin: En el Orgnico Funcional se debe colocar el organigrama de la empresa de estudio, si la empresa lo posee. Caso contrario se debe detener y proporcionar ayuda para la generacin del organigrama, con el fin de poder organizar la situacin de la institucin. Es necesario analizar todos los departamentos involucrados y marcar el mbito de la siguiente manera (Recomendado):
CONSEJO ASESOR
CONSEJO SUPERIOR RECTOR
CONSEJO DE REG
CONSEJO ACADMICO VICERRECTOR

SECRETARIA PROCURADORIA
COMISIN DE EVALUACIN INTERNA
RELACIONES PBLICAS
UNIDAD ADMINISTRATIVA
COMISIN DE VINCULACIN CON LA COLECTIVIDAD
CENAPSI
CENTRO DE ASESORIA JURDICA
POSTGRADO Y
DIRECTOR ACADMICO
SECRETARIA
mbito del sistema

SUBDIRECTOR ACADMICO
COORDINADOR ACADMICO PROGRAMA 1
UNIDAD ACADMICA DE PREGRADO MODALIDAD PRESENCIAL
UNIDAD ACADMICA DE PREG MOD. A DIST. Y SEMIPRESE DIRECTOR GENERAL
Una vez que se ha definido el mbito, ya sabemos quines van a ser las personas que ESCUELAS sern la Fuente de Informacin y se podr coordinar las respectivas citas para las futuras entrevistas o encuestas. SECRETARIA COORDINADOR
ACADMICO
CO ADM

DERECHO CIENCIAS DE LA SALUD DISEO GESTIN EDUCACIN INFORMTICA
DIRECTOR
DIRECTOR
DIRECTOR
DIRECTOR
DIRECTOR
DIRECTOR
El siguiente punto es el Orgnico de Procesos, en donde se debe solicitar las funciones que realizan cada persona que est dentro del mbito definido. En caso de que la empresa no posea definido el orgnico de procesos, se debe proceder a detallar cada una de las funciones que realizan las personas que laboran dentro del mbito de desarrollo. De darse este caso, es recomendable que el usuario explique todo lo que l hace dentro de su rea de trabajo, sin limitarlo, es decir que se debe tomar nota de todo lo que el usuario exponga.
1.2.
INGENIERA DE REQUISITOS
La ingeniera de requisitos comprende todas las actividades de desarrollo del software como: la obtencin, anlisis, especificacin, verificacin & validacin, y gestin. Estas actividades permitirn determinar los requisitos a nivel de sistema y de software. Los requisitos del sistema son determinados en base a las observaciones, entrevistas, encuestas con los usuarios y otras tcnicas. Como punto de partida para la obtencin de los requisitos del sistema, se toma de referencia el orgnico funcional, plasmado en el estudio preliminar de la etapa anterior, el cual posee todas las funciones que realiza cada empleado en el o los departamentos que conforman nuestro mbito. Luego se procede a separar las tareas funcionales (es decir aquellas que posiblemente son automatizables) y no funcionales que realiza el usuario en su lugar de trabajo. Seguidamente los requisitos de sistema o tambin llamados requisitos generales son narrados tal como se evidencian en la empresa dentro del mbito definido en el estudio preliminar. A continuacin se detalla un ejemplo:
El proceso de facturacin inicia cuando un estudiante se acerca al Dpto. de Tesorera, pregunta cunto es el valor adeudado y procede a entregar el dinero o papeleta de depsito por el costo de la pensin; en ese momento la tesorera, procede a registrar la factura, tomando los datos personales del estudiante y dems datos de la factura como: .. Es importante tener en cuenta que los requisitos del sistema, deben estar redactados lo ms aproximadamente posible a como se da en la realidad, esto garantizar que la siguiente actividad tenga resultados favorables. Es recomendable se revise una y otra vez los requisitos del sistema hasta cuando juntamente con el usuario lleguen a un acuerdo. Lo siguiente a formular son los requisitos del software o tambin llamados requisitos especficos, para lo cual deber organizarlos por: Gestiones, Controles y Procesos (Requisitos especficos). Ejemplo:
Gestiones Controles Procesos (alta, modificacin, consulta, baja) Gestin Contabilidad Control Balances Balance general Balance de comprobacin Estado de Prdidas y Ganancias Recuerde que la especificacin de requisitos es la base de todas las dems actividades del proceso de la ingeniera del software, de la cual depende la satisfaccin futura del cliente y usuario.
1.3.
GESTIN DEL PROYECTO DE SOFTWARE
A continuacin se proceder a reforzar algunos conceptos bsicos sobre la gestin del proyecto de software. Qu es Proyecto? Un proyecto es un emprendimiento temporal para crear un producto o servicio nico, en nuestro caso un software. Cuando se habla de temporal, nos referimos a: Que un proyecto tiene inicio y fin. Termina cuando: o Se alcanzan los objetivos. o O es claro que no se van a alcanzar. o La necesidad ya no existe y el proyecto es cancelado. La oportunidad o ventana de mercado es temporal. El equipo rara vez sobrevive al proyecto. Ejemplo: Campaa poltica.
Qu es Gestin de Proyectos? Es la aplicacin de conocimientos, habilidades, herramientas y tcnicas a las actividades de un proyecto, para satisfacer los requisitos (las necesidades y expectativas) de un proyecto. Un aspecto clave a considerar es que las principales actividades de los gestores se centran en: La planificacin La estimacin Control y seguimiento
1.3.1. Planificacin 1.3.1.1. Plan general del proyecto de software
El plan general del proyecto establecer todos los componentes que permitan el eficiente desarrollo del sistema informtico integrado, los elementos a determinar son: tiempo, recursos y costo de desarrollo. Para determinar el calendario del proyecto, estimar el esfuerzo y costo asociados, se debe saber: Cunta gente va a estar trabajando en el proyecto. Qu tareas van a desarrollar. Qu habilidades y experiencia deben tener. Quin hace qu y cmo se va a organizar el personal.
Es decir que no se puede estimar con precisin si no s quin va a trabajar en el proyecto, para lo cual se debe planificar las actividades y determinar el personal que va a realizar dichas actividades. Conformacin del equipo de desarrollo En el desarrollo de software el trabajo en grupo se impone: Por el tamao del proyecto y Porque el problema a resolver abarca muchos aspectos distintos en los que se requieren diferentes expertos.
La pregunta es: Cmo seleccionar el personal del equipo de desarrollo?....., puede ser en base a entrevistas o referencias. Caractersticas del personal Aqu algunas consideraciones al momento de seleccionar el personal: Capacidad para desempear una tarea. Inters en el trabajo. Experiencia con aplicaciones similares, herramientas, lenguajes, tcnicas y ambiente de desarrollo. Capacitacin estudios. Capacidad para comunicarse con otros y compartir la responsabilidad. Capacidad de supervisin. Capacidad para resolver problemas. Adaptabilidad Capacidad de aprender, aceptar y asimilar cambios. Capacidad para resistir cierta cantidad de tensin. Personalidad.
Comunicaciones en el equipo de desarrollo Dentro del equipo de desarrollo las comunicaciones son necesarias e inevitables para que el grupo trabaje con eficiencia. Pero tambin son improductivas ya que mientras dura la comunicacin el individuo no est realizando su funcin. Qu factores afectan a la comunicacin en grupo? Tamao del grupo. 7
Estructura del grupo. Composicin del grupo - Personalidades implicadas y su categora profesional. Ambiente fsico de trabajo
Cuanto mayor es el grupo, mayor es el nmero de enlaces de comunicacin entre sus miembros y para disminuirlas se puede realizar lo siguiente: Estructurar las comunicaciones de manera que todas pasen por un coordinador central dentro de cada grupo de trabajo. Establecer grupos de comunicacin y el mnimo de comunicaciones entre grupos. Los grupos ideales son de entre 2 y 8 personas. Disminuyen los problemas de comunicacin.
1.3.1.2.
El plan de pruebas
Cuando se desarrolla software, en ocasiones es normal escuchar este tipo de interrogantes: El software fall?, es decir el software no hizo lo requerido (o hace algo que no debera). Cuando se dan este tipo de situaciones puede ser por las siguientes razones: Las especificaciones no estipulan exactamente lo que el cliente precisa o quiere (requerimientos faltantes o incorrectos). Requerimiento no se puede implementar. Faltas en el diseo. Faltas en el cdigo.
Ahora, Cul es la solucin a este tipo de problemas? La ingeniera del software nos dice que debemos detectar y corregir estas faltas antes de liberar el producto.
Objetivos del plan de pruebas Su objetivo es el de descubrir defectos (para corregirlos) realizando lo siguiente: Provocar fallas (una forma de detectar defectos). Revisar los productos (otra forma de detectar defectos). Evaluar la calidad de los productos.
Tipos de errores Los tipos de errores en el desarrollo de software pueden ser: En algoritmos, sintaxis, de precisin y clculo, de documentacin, de estrs o sobrecarga, capacidad o de borde, de capacidad de procesamiento o desempeo, recuperacin, de estndares y procedimientos, relativos al hardware o software sistema. En algoritmos de de de del
Los errores tpicos son: o o o o Preguntar por la condicin equivocada. No inicializar variables. No evaluar una condicin particular. Comparar variables de tipos no adecuados.
De sintaxis
Aunque los compiladores detectan la mayora, es posible que sucedan este tipo de errores o Ejemplo: Confundir un 0 por una O.
De precisin o de clculo
Estos son errores tpicos al momento de la construccin del software: o o o Frmulas no implementadas correctamente. No entender el orden correcto de las operaciones. Faltas de precisin como un truncamiento no esperado.
De documentacin
Normalmente en estos errores la documentacin no es consistente con lo que hace el software. o Ejemplo: El manual de usuario tiene un ejemplo que no funciona en el sistema.
De estrs o sobrecarga
Se refiere a exceder el tamao mximo de un rea de almacenamiento intermedio. Ejemplos: o El sistema funciona bien con 100 usuarios pero no con 110. 9
Sistema que funciona bien al principio del da y se va degradando paulatinamente el desempeo hasta ser espantoso al caer la tarde. Error: haba tareas que no liberaban memoria.
De capacidad o de borde
En ciertos casos se asigna tareas al software ms de lo que puede manejar. Ejemplos: o o El sistema funciona bien con importes <1000000. Ao 2000, software trata bien fechas hasta el 31/12/99.
De capacidad de procesamiento o desempeo o o No terminar el trabajo en el tiempo requerido. Tiempo de respuesta inadecuado.
De recuperacin
Un error que se da cuando no se puede volver a un estado normal luego de una falla. De estndares o procedimientos
No cumplir con la definicin de estndares y/o procedimientos. De hardware o software del sistema
Incompatibilidad entre componentes. Pruebas en el Proceso de Desarrollo Las pruebas se ejecutan durante todo el proceso de desarrollo del software, y se las puede clasificar de la siguiente manera:
COMPONENT CODE
UNIT
UNIT
PRUEBA INTEGRACIN
PRUEBA FUNCIONAL
PRUEBA DESEMPEO
PRUEBA ACEPTACIN
PRUEBA INSTALACIN
Mdulos Integrados UNIT
Sistema Funcionando
Software Verificado
Sistema Aceptado
SISTEMA EN USO
Ambiente de uso
Especificaciones del diseo
Especificaciones requerimientos para el cliente
Requerimientos funcionales del sistema
Otros requerimientos del software
10
Mdulo, componente o unitaria
Verifica las funciones de los componentes, normalmente las realiza el equipo de desarrollo. En general la misma persona que lo implement debido al conocimiento detallado del mdulo a probar. Tcnicas estticas: o Anlisis de cdigo fuente: En este anlisis se revisa el cdigo buscando defectos, se puede llevar a cabo en grupos. o Anlisis automatizado de cdigo fuente: La entrada es el cdigo fuente del programa y la salida es una serie de defectos detectados. Ejemplo: Un software analizador recibe el cdigo fuente:
a:= a + 1 a:= 2
El analizador detecta que se asigna dos veces la variable sin usarla entre las asignaciones.
Anlisis formal Se parte de una especificacin formal y se busca probar (demostrar) que el programa cumple con la misma.
Tcnicas dinmicas: Definiciones bsicas: o Prueba (test) a) Proceso de ejecutar un programa con el fin de encontrar fallas. b) Ejecutar un producto para verificar que satisface los requerimientos. c) Identificar diferencias entre el comportamiento real y el esperado (IEEE). o Caso de Prueba (test case) Datos de entrada, condiciones de ejecucin y resultado esperado. o Conjunto de Prueba (test set) 11
Conjunto de casos de prueba
Caja Blanca: La prueba de caja blanca es una tcnica por el que todas las trayectorias con el programa estn probadas con cada valor posible. Este acercamiento requiere un cierto conocimiento de cmo el programa debe comportarse. Por ejemplo, si tu programa aceptara un valor entero entre 1 y 50, una prueba de caja blanca probara el programa con los 50 valores para asegurar que estaba correcto cada uno de los valores posibles, probando como se comport segn lo esperado. En vista del nmero de los datos que un programa tpico puede tener, la caja blanca puede ser extremadamente difcil para los programas grandes. La prueba de caja blanca se puede aplicar a las funciones crticas de seguridad de un programa grande, y el resto puede ser probado usando la caja negra. Debido al nmero de permutaciones, la prueba de caja blanca se realiza generalmente usando un equipo de la prueba, donde las gamas de valores se alimentan al programa rpidamente con un programa especial, registrando excepciones al comportamiento previsto. La prueba de caja blanca se refiere a veces como la prueba estructural, clara, o abierta de la caja.
Entradas
for (i=0; i<=10;i++) { echo Contador = .i; }
Salidas
Caja Negra: Se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesar su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que tambin podran ser cajas negras) entendiendo qu es lo que hace, pero sin dar importancia a cmo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento. Cuando de un subsistema se conocen slo las entradas y las salidas pero no los procesos internos se dice que es una caja negra.
12
Entradas
Salidas
Integracin
Verifica que los componentes trabajan juntos como un sistema integrado. Normalmente las realiza el equipo de desarrollo y es necesario el conocimiento de las interfaces y funciones en general. Funcional
Determina si el sistema integrado cumple las funciones de acuerdo a los requerimientos. A partir de esta etapa, evalan un equipo especializado (verificadores) y es necesario conocer los requerimientos y tener una visin global. Por qu un equipo especializado? Maneja mejor las tcnicas de pruebas, normalmente conocen los errores ms comunes realizados por el equipo de programadores. Adems debido a problemas de psicologa de pruebas: o o o El autor de un programa tiende a cometer los mismos errores al probarlo. Debido a que es SU programa inconscientemente tiende a hacer casos de prueba que no hagan fallar al mismo. Puede llegar a comparar mal el resultado esperado con el resultado obtenido debido al deseo de que el programa pase las pruebas.
Desempeo
Determina si el sistema integrado, en el ambiente objetivo cumple los requerimientos de tiempo de respuesta, capacidad de proceso y volmenes. Aceptacin
Esta etapa est bajo la supervisin del cliente, y se debe verificar si el sistema cumple con los requerimientos del cliente (y lo satisface), en base a una validacin del sistema. Instalacin El sistema queda instalado en el ambiente de trabajo del cliente y funciona correctamente. 1.3.1.3. Gestin de la configuracin 13
Disciplina cuya misin es controlar la evolucin de un sistema de software. Segn Babich: El arte de coordinar el desarrollo de software para minimizar la confusin, se denomina gestin de configuracin. La gestin de configuracin es el arte de identificar, organizar y controlar las modificaciones que sufre el software que construye un equipo de programacin. El objetivo es maximizar la productividad minimizando los errores
Conceptos Configuracin del Software:
Es el conjunto de toda la informacin y productos utilizados o producidos en un proyecto como resultado del proceso de Ingeniera de Software. Elemento de Configuracin del Software (ECS):
Se llama a cada uno de los componentes de la configuracin del software. ECS es la unidad de trabajo de la GCS. Ejemplo: Especificaciones, planes, diseos, programas, prueba de datos, manuales, entre otros. Objetivos de la Gestin de la Configuracin Establecer y mantener la integridad de los productos generados durante un proyecto de desarrollo de software y a lo largo de todo el ciclo de vida del producto. Evaluar y controlar los cambios sobre ellos, es decir, controlar la evolucin del sistema software: Gestin de cambios. Facilitar la visibilidad sobre el producto. Facilitar la trazabilidad el producto hacia delante y hacia atrs. Controlar la evolucin del proyecto.
La Gestin de la Configuracin vs Mantenimiento No se debe confundir gestin de la configuracin con mantenimiento. Mantenimiento: conjunto de actividades que empiezan cuando el software ya est instalado en el cliente y est operativo. En cambio, el conjunto de actividades de la gestin de la configuracin van desde el inicio hasta el final del proyecto. Actividades de GC segn IEEE Identificacin de la configuracin Control de cambios de la configuracin Generacin de informes de estado Auditora de la configuracin 14
Construccin Control de trabajo en equipo Control de versiones Gestin de problemas Gestin de la calidad
1.3.1.4.
Qu es la calidad del software? Calidad: Satisfaccin de las necesidades del cliente Calidad del software: Concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo explcitamente documentados, y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente.
Por qu es necesario desarrollar software de calidad? Niveles ms altos de las expectativas de los clientes Cliente actual tiene mayor poder Varios clientes exigen certificaciones de calidad Existe mayor competencia
Calidad del software Todas las metodologas y herramientas tienen un nico fin, que es producir software de gran calidad Definiciones de calidad del software: Concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente [Pressman 93] El conjunto de caractersticas de una entidad que le confieren su aptitud para satisfacer las necesidades expresadas y las implcitas ISO 8402 (UNE 66-00192).[ISO][AENOR]
Aseguramiento de la calidad El aseguramiento de calidad del software es el conjunto de actividades planificadas y sistemticas necesarias para aportar la confianza en que el producto (software) satisfacer los requisitos dados de calidad. 1.3.1.5. Gestin de riesgos
Un proyecto es una accin iniciada por la empresa en la que recursos humanos, financieros y materiales se organizan de una nueva forma para acometer un trabajo nico, en el que, dadas unas especificaciones dentro de unas limitaciones en coste y tiempo, se intenta conseguir un cambio beneficioso definido por unos objetivos cualitativos y cuantitativos, Rodney J.
15
Categoras de los riesgos Requerimientos Requerimientos poco claros Requerimientos mal especificados Cambios en los requerimientos Los usuarios no visualizan el sistema hasta el uso
Tecnologa Una plataforma de produccin con problemas. Negocios Proveedores que retrasan Por ejemplo que no se adquiera a tiempo la plataforma deseada.
Habilidades Habilidades de los miembros del equipo. Poco familiar con la tecnologa. Poco familiar con los procesos del negocio.
Despliegue y soporte La infraestructura requerida no est lista. El equipo de soporte no est listo. La organizacin no est lista.
Integracin Interfaces entre sistemas hacen que no trabaje bien juntos. Se recomienda hacer la integracin junto con el desarrollo. La comunicacin es la clave para reducir el riesgo
Cronograma Recursos no disponibles cuando se necesitan. Subestimacin de tiempos de desarrollo. Ejecutar un buen plan de proyecto.
Diseo Poca calidad en los diseos. Poca flexibilidad para los cambios.
Mantenimiento
16
Personal poco entrenado. Documentacin inadecuada. La plataforma ha venido a ser obsoleta
1.3.2. Estimacin 1.3.2.1. Estudio de factibilidad Como parte de la gestin del proyecto de software, el siguiente paso una vez generada la especificacin de requisitos, es realizar un estudio corto para resolver si es posible y conveniente construir el sistema con la tecnologa existente, las restricciones de costo y tiempo, etc. El estudio de factibilidad debe responder a la pregunta: Vale la Pena? Este estudio se estructura de: Factibilidad Tcnica: Este punto debe hacerse estas preguntas: o o Es posible? Puede ser implementado con la tecnologa existente, dentro de las restricciones de costo y tiempo?
Factibilidad Econmica: o Cunto cuesta? o En ciertos casos se hace anlisis de flujos financieros. Factibilidad Operativa En esta factibilidad hay que determinar: o Habr algo que haga que el sistema no funcione? Ejemplo: Cultura de la organizacin o Puede ser integrado con otros sistemas existentes?
Anlisis Costo/Beneficio Este anlisis debe evidenciar si es factible o no el avance del proyecto. Se debe realizar el anlisis con la ayuda de grficos estadsticos.
1.3.2.2.
Estimacin del software con COCOMO
La estimacin a travs de los puntos de funcin es muy importante, esta puede ser elaborada juntamente con el plan general del proyecto y estudio de factibilidad, ya que
17
para estos documentos se debe proporcionar informacin de la cantidad del personal requerido en el desarrollo del software y el costo del mismo, respectivamente. Para reforzar los conocimientos de: El plan de gestin de la configuracin, calidad, riesgos, seguimiento y control, revisar el material ajunto a la asignatura INGENIERA DEL SOFTWARE I.
1.3.3. Seguimiento y Control El propsito del Seguimiento y Control de Proyectos de Software es el de proveer una visin objetiva del estado actual del proyecto y determinar las posibles alternativas a fin de tomar las correcciones del caso. Es en este sentido en el cual le llamamos Seguimiento a la evaluacin rutinaria del estado en tanto que llamamos Control a la toma de los correctivos. Cuando una planificacin se encuentra correctamente documentada, es posible verificar su cumplimiento. El producto mnimo de esta prctica es el Cierre de Iteracin, un documento, donde anotamos los resultados de la evaluacin de una iteracin, de momento sin decir las correcciones a tomar. Una vez determinada las alternativas de solucin, es necesario que el equipo determine oportunamente la correccin requerida y la lleve a cabo durante la siguiente iteracin o en el momento en que sea oportuno. Finalmente es necesario que la correccin planteada sea a su vez, objeto de seguimiento, lo que implica que la planificacin debe ser actualizada para que refleje las acciones que se han determinado necesarias para corregir la desviacin. A la hora de realizar las reuniones de seguimiento del proyecto, es til contar con unos momentos para discutir y revisar el Plan de Riesgos, a fin de verificar la ocurrencia de alguno de estos eventos negativos. Otros factores que deben ser objeto de seguimiento incluyen el presupuesto en tiempo y dinero del proyecto y el cumplimiento de los hitos sealados como objetivos del ciclo de vida. Cierre de Iteracin Si el Plan de Iteracin es la planificacin de un periodo corto de tiempo dentro del proyecto, entonces el Cierre de Iteracin es el informe del cumplimiento de dicho plan. El documento de cierre de iteracin es una presentacin de las actividades realizadas, los recursos dedicados, los hitos, los riesgos concretados, as como cualquier otro evento o informacin de la que queramos dejar constancia. La idea es que en el Plan de Aseguramiento de Calidad se indiquen los criterios que deben ser evaluados en cada documento, para que luego entre el Plan de Iteracin y el Cierre de Iteracin se siga la pista de la evolucin de estas situaciones encontradas. Es una caracterstica un poco compleja, pero si se cuenta con recursos para mantener un equipo de control de calidad, entonces se va a poder llevar a cabo este control, con miras a mejorar la ejecucin del proyecto en su conjunto.
18
Unidad Didctica II
19
ANLISIS Y DISEO ESTRUCTURADO DEL SOFTWARE
UNIDAD DIDACTICA II: ANLISIS Y DISEO ESTRUCTURADO DEL SOFTWARE OBJETIVO: Modelar la arquitectura del software, aplicando la tcnica de anlisis y diseo estructurado, de tal forma que dichos modelos sirvan de base para la implementacin del producto final.
2. ANALISIS Y DISEO ESTRUCTURADO DEL SOFTWARE

El Anlisis del Software es el proceso de clasificacin e interpretacin de hechos, diagnstico de problemas y empleo de la informacin para recomendar mejoras al sistema actual de la empresa y/o institucin. El anlisis comienza con una serie de tareas de modelado que son representaciones tcnicas de un sistema, siendo el modelo de anlisis como un puente entre la descripcin del sistema (requisitos) y el modelado de diseo.
20
Descripcin del sistema Modelado de anlisis Modelado de diseo Existen dos enfoques para modelado de anlisis, llamados: Anlisis Estructurado y Anlisis Orientado a Objetos. El anlisis estructurado es un mtodo para el anlisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Cuando los analistas de sistemas abordan una situacin poco familiar, siempre existe una pregunta sobre dnde comenzar el anlisis. Una situacin dinmica siempre puede ser vista como abrumadora debido a que muchas de las actividades se llevan a cabo constantemente. El anlisis estructurado permite al analista conocer un sistema o proceso (actividad) en una forma lgica y manejable, al mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle pertinente. El anlisis orientado a objetos, se centra en la definicin de clases y en la manera en que stas colaboran entre ellas para efectuar los requisitos del cliente. El UML, proceso unificado, est orientado a objetos en forma predominante.
2.1.
EL ANLISIS ESTRUCTURADO
Significado de estructurado Para poder entender mejor su significado, trataremos de responder a estas preguntas: qu es lo que desea estructurar?, qu significa estructurar? El objetivo que persigue el anlisis estructurado es organizar las tareas asociadas con la determinacin de requerimientos para obtener la comprensin completa y exacta de una situacin dada. En el anlisis estructurado la palabra estructura significa que: El mtodo intenta estructurar el proceso de determinacin de requerimientos comenzando con la documentacin del sistema existente. los
El proceso est organizado de tal forma que intenta incluir todos los detalles relevantes que describe al sistema en uso. La identificacin de los requerimientos ser similar entre varios ingenieros/analistas e incluir las soluciones y estrategias para las oportunidades del desarrollo de sistemas. 21
Los documentos de trabajo generados para documentar los sistemas existentes o propuestos son dispositivos de comunicacin eficientes.
2.1.1 MODELADO DE PROCESOS 2.1.1.1 Diagrama de Flujo de Datos (DFD) El diagrama de flujo de datos es una representacin grfica de la secuencia del flujo que los datos hacen para la ejecucin de un sistema determinado. El DFD tiene una visin del sistema del tipo entrada-proceso-salida. Esto indica que los datos fluyen hacia el interior del software, se transforman mediante elementos de procesamiento, y los datos resultantes fluyen al exterior del software. En el DFD, el flujo de los datos se representan mediante flechas rotuladas y las transformaciones se representan por medio de crculos (tambin llamadas burbujas). Este modelado se representa en una forma jerrquica, es decir que el primer modelo de flujo de datos (llamado DFD de nivel 0 o diagrama de contexto) representa al sistema como un todo. Los diagramas de flujo de datos subsecuentes refinan el diagrama de contexto, ya que proporcionan una cantidad creciente de detalles con cada nivel subsiguiente. Simbologa utilizada Entidad Externa.- Son generalmente clases lgicas de cosas o de personas, las cuales representan una fuente o destino de transacciones, como por ejemplo clientes, empleados, proveedores, etc., con las que el sistema se comunica. Tambin pueden ser una fuente o destino especfico, como por ejemplo departamento contable u otro sistema. Mediante la designacin de alguna cosa o de algn sistema como entidad externa estamos estableciendo implcitamente que se encuentra fuera de los lmites del sistema que estamos considerando, por lo cual no nos interesa la transformacin o proceso que se realiza dentro de ellos, es decir que estn fuera del control del sistema que se est modelando. Son slo proveedores o requeridores de datos del sistema bajo consideracin.
Entidad externa o terminador Proceso.- Indican aquellos lugares dentro del sistema en donde la informacin (flujos de datos) que ingresan se procesa o transforma. Es decir, son las funciones o procesos que transforman entradas de datos en salidas de informacin. Su nombre deber ponerse mediante una frase imperativa, que consistir idealmente de un verbo activo seguido por una clusula objeto, cuanto ms simple mejor. Al ingeniero/analista le servir pensar que la descripcin de la funcin o proceso es "una orden a un empleado sin conocimiento del tema". Estas frases imperativas no tienen
22
sujeto; tan pronto como se introduce un sujeto se habr indicado cmo deber realizarse fsicamente la funcin ("El operador ingresar los datos del alumno").
Proceso Flujo de datos.- Representa un transporte de paquetes de datos desde su origen hasta su destino, es decir que representa una estructura de datos en movimiento de una parte del sistema a otro. Un flujo muestra las interfaces entre los elementos del DFD. Puede imaginarse como una tubera por donde se envan paquetes de datos, pero deber tener una descripcin de su contenido la cual deber elegirse de forma que sea lo ms til posible a los usuarios que revisen el DFD. Entonces la flecha indica la direccin del flujo.
Flujo de datos Almacn o archivo.- Representa un archivo lgico en donde se agregan o de donde se extraen datos. Es una estructura de datos, pero esttica. Puede ser fsicamente un archivo de tarjetas, una microficha, un archivo, o un archivo en cinta o diskette. Deber elegirse el nombre que sea ms descriptivo para el usuario, que identifique los paquetes de datos que contiene.
Almacenes
2.1.1.2 Reglas de los diagramas de flujo de datos 1. Primero se debern identificar las entidades externas ya que ello implica definir los lmites del sistema.
23
2. Se debern elegir nombres con significado tanto para procesos como tambin para flujos de datos, almacenes y entidades externas. Si es posible a partir del vocabulario del usuario evitando terminologas tcnicas. 3. Identificar el papel del proceso del sistema, no quien lo realiza. 4. Se debern, en la medida de lo posible, evitar los DFD excesivamente complejos. Debern ser comprensibles, asimilables a la vista sin demasiados elementos. 5. Todos los elementos se relacionan entre s a travs de Flujos de Datos. 6. Los procesos se relacionarn con: Almacenes, entidades externas, otros procesos. 7. Los procesos debern tener al menos una entrada y una salida. 8. Los almacenes se relacionarn solamente con procesos. 9. Las entidades externas: Se relacionarn solamente con procesos. 10. En todos los niveles del Diagrama de Flujo de Datos deber haber igual cantidad de entradas y de salidas. 11. Los Niveles del DFD: En nivel de partida o Diagrama de Contexto: No existirn almacenes o archivos. Se representarn las entidades externas que son fuente y destino de los datos. El sistema ser representado como un proceso simple. Se dibujarn slo los flujos de datos de comunicacin exterior-sistema.
Nivel 1 y subsiguientes: Deber haber igual cantidad de archivos. Aunque podr existir mayor cantidad de almacenamientos en el nivel 2 debido a la explosin de algn proceso. En el ltimo nivel, cada proceso realizar una funcin especfica y concreta. Cada proceso en el DFD de alto nivel de un sistema puede ser "explotado" para convertirse en un DFD en s mismo. Cada proceso en el nivel inferior deber estar relacionado, inversamente, con el proceso del nivel superior. Es decir que, cada proceso padre que se detalla en el DFD, ha de estar balanceado. La regla del balanceo consiste en que cada proceso debe tener exactamente los mismos datos de entrada/salida netos que el DFD hijo.
24
2.1.1.3 Transicin de los ERS a los DFDs Para hacer la transicin de los ERS a los DFDs, se la debe hacer tomando como referencia los requisitos generales de la especificacin de requisitos. Anlisis textual de los requisitos generales El anlisis textual de los requisitos generales consiste en extraer los verbos y nombres que puedan existir. Los nombres pueden ser propios y comunes, los verbos tienen relacin con hacer, ser y tener. En relacin del anlisis textual con los DFD, los verbos que podamos encontrar sern los procesos y los nombres propios equivaldrn a las entidades externas y los nombres comunes haran referencia a posibles almacenes. A continuacin un ejemplo:
Si un cliente entra a un almacn con la intencin de comprar un juguete para un nio, entonces, es preciso ofrecerle consejo dentro de unos lmites de tiempo razonables, en lo tocante a si el juguete es apropiado o no para el nio. Esto depender del intervalo de edades del nio, as como de los atributos del juguete. Si el juguete es peligroso, entonces, no es adecuado para el nio. He puesto en cursiva algunos candidatos a entidades externas y en negrita algunos candidatos a procesos. La siguiente tabla nos ilustra cmo poder analizar el texto de los requisitos generales. Parte de la oracin Nombre propio Nombre comn Verbo de accin Verbo de existencia Verbo de posesin Verbo afirmativo Componente del modelo Entidad externa Almacenes Proceso Flechas de flujo Flechas de flujo Flechas de flujo Ejemplo J. Garca Juguete Comprar Es un Tiene un posee
2.1.1.4 Diccionario de los datos del DFD. Un anlisis del mbito de informacin estara incompleto si solo se considera el flujo de la informacin. Cada flecha del diagrama de flujo de datos representa uno o varios elementos de informacin, cada archivo de datos es una coleccin de elementos de datos individuales, incluso puede que el contenido de una entidad externa requiera ser expandido antes de que su significado pueda ser definido explcitamente. Por lo tanto, el ingeniero/analista debe disponer de algn mtodo para representar el contenido de cada componente del modelo de flujo de datos.
Contenido del Diccionario de Datos El Diccionario de datos debe contener la siguiente informacin:
25
1. Nombre: El nombre principal del elemento, del flujo de datos, del repositorio de datos o de una entidad externa. 2. Alias: Otros nombres usados para la entrada, dado que un mismo elemento puede ser conocido por diferentes nombres. 3. Definicin: Exposicin clara y precisa de las caractersticas genricas y diferenciales del objeto. 4. Descripcin: Explicar las diversas partes o circunstancias que componen la definicin de los objetos. 5. Dnde se usa/cmo se usa: Un listado de los procesos que usan un elemento de datos, o del control de cmo lo usan. 6. Descripcin del contenido: El contenido es representado mediante una anotacin que se describe en la siguiente tabla. 2.1.2 MODELADO DE DATOS
El objetivo de esta actividad es identificar las necesidades de informacin de cada uno de los procesos que conforman el software, con el fin de obtener un modelo de datos que contemple todas las entidades, relaciones, atributos y reglas de negocio necesarias para dar respuesta a dichas necesidades. A partir del modelo conceptual de datos, se incorporan a dicho modelo todas las entidades que vayan apareciendo, como resultado de las funcionalidades que se deban cubrir y de las necesidades de informacin del usuario. Es necesario tener en cuenta la especificacin de requisitos y el modelo de procesos, productos que se estn generando en paralelo en las actividades. Una vez construido el modelo conceptual y definido sus entidades, se resuelven las relaciones complejas y se completa la informacin de entidades, relaciones, atributos y ocurrencias de las entidades, generando el modelo lgico de datos. 2.1.2.1 Elaboracin del Modelo Conceptual de Datos (MER) El objetivo de esta tarea es identificar y definir las entidades que quedan dentro del mbito del software y las relaciones existentes entre las entidades, indicando las cardinalidades mnimas y mximas. Tambin se identifican aquellas entidades que no forman parte del modelo, pero que estn relacionadas con alguna entidad del mismo, indicando a su vez el tipo de relacin y las cardinalidades mnimas y mximas. A continuacin un ejemplo de cmo sera el modelo conceptual de datos en este nivel, elaborado con la herramienta CASE Erwin.
26
2.1.2.2 Elaboracin del Modelo Lgico de Datos (MER) En esta tarea se obtiene el modelo lgico de datos a partir del modelo conceptual para lo cual se realizarn las acciones siguientes: Resolver las relaciones complejas que pudieran existir entre las distintas entidades. Agregar los atributos de cada entidad y su respectiva informacin. Completar la informacin de las entidades, una vez resueltas las relaciones complejas.
A continuacin un ejemplo de cmo sera el modelo lgico de datos en este nivel, elaborado con la herramienta CASE Erwin.
2.1.2.3 Diccionario del Modelo Lgico de Datos (MER) El diccionario de datos del modelo entidad-relacin puede describirse en matrices que contengan los siguientes datos: Entidades: Nombres de entidad, descripcin, atributos y descripcin de atributos. Relaciones: ID de relacin, entidad padre, entidad(es) hija(s), tipo de relacin, cardinalidad. 27
2.2 EL DISEO ESTRUCTURADO

2.2.1 CONCEPTOS GENERALES DEL DISEO. 2.2.1.1 Principios del Diseo El modelado de diseo del software es equivalente al plano de una casa para un arquitecto. Se inicia con la representacin total, por ejemplo: un diseo tridimensional de una casa. El modelado de anlisis, describe los procesos que se desarrollan en el problema, las funciones visibles para el usuario, el comportamiento del sistema, entre otros, mientras que el modelo de diseo traduce esta informacin en arquitectura. La arquitectura del software es el esqueleto del sistema que se va a construir, y solo despus que se ha establecido la arquitectura, es posible considerar los siguientes aspectos ms detallados del diseo. En el modelado de diseo tambin se definen las interfaces de usuario, siendo esta la manifestacin visible del software. Y es curioso, que sin importar que tan sofisticadas sean sus funciones internas, un diseo de interfaz pobre siempre conduce a la percepcin de que el software est mal hecho. Como casi todas las actividades creativas, el diseo ocurre de modo iterativo. Las primeras iteraciones sirven para refinar el diseo y corregir errores, pero esas iteraciones posteriores deben buscar que el diseo sea tan simple como sea posible. En conclusin, el propsito del diseo es comunicar informacin a los profesionales que generan cdigos, a aquellos que evaluarn el software y a quienes en futuro, mantenga el software. 2.2.1.2 Conceptos del Diseo Los conceptos del diseo de software proporcionan el marco de trabajo necesario para conseguir un diseo ideal. Abstraccin Cuando se tiene en consideracin una solucin modular a cualquier problema, se pueden exponer muchos niveles de abstraccin. En el nivel ms alto de abstraccin, la solucin se pone como una medida extensa empleando el lenguaje del entorno del problema. En niveles inferiores de abstraccin, se toma una orientacin ms procedimental. Cada paso del proceso del software es un refinamiento en el nivel de abstraccin de la solucin del software. A medida que nos adentramos en el proceso de diseo, se reduce el nivel de abstraccin. Finalmente el nivel de abstraccin ms bajo se alcanza cuando se genera el cdigo fuente. A medida que vamos entrando en diferentes niveles de abstraccin, trabajamos para crear abstracciones procedimentales y de datos. Una abstraccin procedimental es una secuencia nombrada de instrucciones que tiene una funcin especfica y limitada.
28
Refinamiento El refinamiento paso a paso es una estrategia del diseo, se realiza refinando sucesivamente los niveles de detalle procedimentales. Una jerarqua se desarrolla descomponiendo una sentencia macroscpica de funcin (una abstraccin procedimental) paso a paso hasta alcanzar las sentencias del lenguaje de programacin. El refinamiento hace que el diseador trabaje sobre la sentencia original, proporcionando cada vez ms detalles a medida que van teniendo lugar sucesivamente todos y cada uno de los refinamientos. Modularidad El concepto de modularidad se ha ido exponiendo desde hace casi cinco dcadas en el software para computadoras. La arquitectura de computadora expresa la modularidad; es decir, el software se divide en componentes nombrados y abordados por separado, llamados frecuentemente mdulos, que se integran para satisfacer los requisitos del problema. Se ha afirmado que la modularidad es el nico atributo del software que permite gestionar un programa intelectualmente. El software monoltico, es decir, un programa grande formado por un nico mdulo, no puede ser entendido fcilmente por el lector. La cantidad de rutas de control, la amplitud de referencias, la cantidad de variables y la complejidad global har que el entendimiento est muy cerca de ser imposible. Arquitectura La arquitectura del software alude a la estructura global del software y a las formas en que la estructura proporciona la integridad conceptual de un sistema. En su forma ms simple, la arquitectura es la estructura jerrquica de los componentes del software (mdulos), la manera en que los componentes interactan y la estructura de datos que van a utilizar los componentes. Sin embargo, en un sentido ms amplio, los componentes se pueden generalizar para representar los elementos principales del sistema y sus iteraciones. 2.2.1.3 Diseo Modular Los conceptos fundamentales de diseo descritos en la seccin anterior sirven para incentivar diseos modulares. De hecho, la modularidad se ha convertido en un enfoque aceptado en todas las disciplinas de ingeniera. Un diseo modular reduce la complejidad, facilita los cambios (un aspecto crtico de la capacidad de mantenimiento del software), y da como resultado una implementacin ms fcil al fomentar el desarrollo paralelo de las diferentes partes de un sistema. Ocultacin de informacin El concepto de modularidad conduce a todos los diseadores de software a formularse una pregunta importante: Cmo se puede descomponer una solucin de software para obtener el mejor conjunto de mdulos?
29
Los mdulos debern especificarse y disearse de manera que la informacin (procedimiento y datos) que est dentro de un mdulo sea inaccesible a otros mdulos que no necesiten esa informacin. Ocultacin significa que se puede conseguir una modularidad efectiva definiendo un conjunto de mdulos independientes, que se comunican entre s, intercambiando slo la informacin necesaria para lograr la funcin del software. La abstraccin ayuda a definir las entidades (o informacin). Independencia funcional El concepto de independencia funcional es la suma de la modularidad y de los conceptos de abstraccin y ocultacin de informacin. La independencia funcional es disear el software de manera que cada mdulo trate una subfuncin de requisitos y tenga una interfaz sencilla cuando se observa desde otras partes de la estructura del programa. El software con una modularidad efectiva, es decir, mdulos independientes, es ms fcil de desarrollar porque la funcin se puede fragmentar y las interfaces se simplifican (tengamos en consideracin las ramificaciones cuando el desarrollo se hace en equipo). Los mdulos independientes son ms fciles de mantener y probar, porque se limitan los efectos secundarios originados por modificaciones de diseo/cdigo, porque se reduce la propagacin de errores y porque es posible utilizar mdulos usables. En resumen, la independencia funcional es la clave para un buen diseo y el diseo es la clave para la calidad del software. 2.2.1.4 Heurstica del Diseo para una Modularidad Efectiva Se puede conseguir una modularidad efectiva aplicando los conceptos de diseo explicados anteriormente. La estructura del programa se puede manipular de acuerdo con el siguiente conjunto de heursticas: 1. Evaluar la primera iteracin de la estructura del programa. Una vez que se ha desarrollado la estructura del programa, se pueden explosionar los mdulos con vistas a mejorar la independencia del mdulo. Un mdulo explosionado se convierte en dos mdulos o ms en la estructura final del programa. 2. Evaluar las interfaces de los mdulos para reducir la complejidad, redundancia y mejorar la consistencia. La complejidad de la interfaz de un mdulo es la primera causa de los errores del software. Las interfaces debern disearse para pasar informacin de manera sencilla y debern ser consecuentes con la funcin de un mdulo. La inconsistencia de interfaces (es decir, datos aparentemente sin relacionar, pasados a travs de una lista de argumentos u otra tcnica) es una indicacin de poca coherencia. El mdulo en cuestin deber volverse a evaluar. 3. Definir mdulos cuya funcin se pueda predecir, pero evitar mdulos que sean demasiado restrictivos. 4. Intentar conseguir mdulos de entrada controlada. Esta heurstica de diseo advierte contra el acoplamiento de contenido. El software es ms fcil de entender y por tanto ms fcil de mantener cuando los mdulos que se interaccionan estn restringidos y controlados.
30
2.2.2
METODOS DEL DISEO
El Diseo del Software se define como el proceso de aplicar tcnicas y principios con el propsito de especificar un sistema, con suficientes detalles como para permitir su interpretacin y realizacin fsica. El proceso del diseo encierra cuatro etapas claves: El diseo fsico de datos
Transforma el modelo lgico de datos creado durante el anlisis, en las estructuras de datos fsicas y necesarias para implementar el Software. El Diseo Arquitectnico.
Define la relacin entre cada uno de los elementos estructurales del programa. El Diseo de la Interfaz.
Describe como se comunica el software consigo mismo, con los sistemas que operan junto con l, con los administradores y usuarios que lo emplean. El Diseo de Procedimientos.
Debe proporcionar una completa idea de lo que es el software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la implementacin. Otra actividad que se incorpora, desarrollada en paralelo con las tareas de diseo del software es el diseo de mens, el cual ser detallado ms adelante. 2.2.2.1 Diseo Fsico de Datos 2.2.2.1.1 Modelo Relacional El objetivo de esta tarea es realizar el diseo del modelo fsico de datos a partir del modelo lgico de datos normalizado o del modelo de clases, en el caso de diseo orientado a objetos. Como paso previo al diseo de la estructura fsica de datos, se analizan las peculiaridades tcnicas del gestor de bases de datos o sistema de ficheros a utilizar, y las estimaciones sobre la utilizacin y volumen de las ocurrencias de cada entidad/clase. Adems, si se ha establecido la necesidad de llevar a cabo una migracin de datos, se deben tener en cuenta tambin los volmenes de las estructuras de datos implicadas en la conversin. De acuerdo al anlisis anterior, se determina cmo se van a convertir las entidades/clases en tablas, considerando las relaciones existentes entre ellas y los identificadores, definiendo sus claves primarias, ajenas, alternativas u otros medios de acceso en general. Tambin se definen aquellos elementos que, en funcin del gestor o sistemas de ficheros a utilizar, se considere necesario implementar. Entre estos elementos podemos citar los siguientes: Vistas 31
Procedimientos Almacenados Triggers
A continuacin un ejemplo de cmo sera el modelo relacional en este nivel, elaborado con la herramienta CASE Erwin.
2.2.2.1.2
Diccionario de Datos del Modelo Relacional
El diccionario de datos del modelo relacional puede describirse en matrices que contengan la siguiente informacin sobre la Base de Datos: Tablas, columnas, restricciones, ndices principales y forneos, usuarios, tipos de datos, parmetros del sistema. 2.2.2.2 Diseo Arquitectnico EL diseo arquitectnico representa la estructura de los datos y los componentes del software que se requiere para construir un sistema basado en computadora. Constituye el estilo arquitectnico que tendr el sistema, la estructura y las propiedades de los componentes que ese sistema comprende.
32
Qu es arquitectura? Cuando hablamos de la arquitectura de un edificio, nos vienen a la cabeza diferentes atributos. A nivel ms bsico, pensamos en la forma global de la estructura fsica, pero, en realidad la arquitectura es mucho ms. Es la forma en la que los diferentes componentes del edificio se integran para formar un todo unido. Es la forma en la que el edificio encaja en su entorno y con los otros edificios de su vecindad. Es el sentido esttico de la estructura e impacto visual del edificio y el modo en el que las texturas, los colores y los materiales son combinados para crear la fachada externa y el entorno vivo interno. Son los pequeos detalles del diseo de las instalaciones elctricas, del tipo de suelo, de la colocacin de tapices y una lista casi interminable. De qu se ocupa? El objetivo principal del diseo arquitectnico es desarrollar una estructura de software modular y representar las relaciones de control entre los mdulos. Mezcla la estructura del software y la estructura de datos y define las relaciones que facilitan el flujo de los datos a lo largo del software. De qu no se ocupa? Diseo detallado Diseo de algoritmos Diseo de estructuras de datos
2.2.2.2.1
Estilos Arquitectnicos
Los sistemas basados en computadora, la gran mayora pueden ser clasificados dentro de uno de los estilos arquitectnicos siguientes: Arquitecturas centradas de datos En el centro de esta arquitectura se encuentra un almacn de datos (por ejemplo, una base de datos) al que otros componentes acceden con frecuencia para actualizar, aadir, borrar o bien modificar los datos del almacn.
33
El software de cliente accede a un almacn central. En algunos casos, el almacn de datos es pasivo. Esto significa que el software de cliente accede a los datos independientemente de cualquier cambio en los datos o de las acciones de otro software de cliente. Una variacin en este acceso transforma el almacn en una pizarra que enva notificaciones al software de cliente cuando los datos de inters del cliente cambian. Las arquitecturas basadas en los datos promueven la capacidad de integracin. Por consiguiente, los componentes existentes pueden cambiarse o los componentes del nuevo cliente pueden aadirse a la arquitectura sin involucrar a otros clientes (porque los componentes del cliente operan independientemente). Adems, los datos pueden ser transferidos entre los clientes utilizando un mecanismo de pizarra (por ejemplo, el componente de pizarra sirve para coordinar la transferencia de informacin entre clientes). Los componentes cliente son procesos ejecutados independientemente. Entonces visto de otra manera el grfico sera el siguiente:
Arquitecturas de flujo de datos Esta arquitectura se aplica cuando los datos de entrada son transformados a travs de una serie de componentes computacionales o manipulativos en los datos de salida.
34
Un patrn tubera y filtro tiene un grupo de componentes, llamados filtros, conectados por tuberas que transmiten datos de un componente al siguiente.
Cada filtro trabaja independientemente de aquellos componentes que se encuentran en el flujo de entrada o de salida, est diseado para recibir la entrada de datos de una cierta forma y producir una salida de datos (hacia el siguiente filtro) de una forma especfica. Sin embargo, el filtro no necesita conocer el trabajo de los filtros vecinos. Si el flujo de datos degenera en una simple lnea de transformadores se le denomina secuencia1 por lotes. Este patrn aplica una serie de componentes secuenciales (filtros) para transformarlos. Arquitecturas de llamada y retorno Este estilo arquitectnico permite al diseador del software construir una estructura de programa relativamente fcil de modificar y ajustar a escala.
35
Existen dos subestilos dentro de esta categora: Arquitecturas de programa principal/subprograma: Esta estructura clsica de programacin descompone las funciones en una jerarqua de control donde un programa principal llama a un nmero de componentes del programa, los cuales, en respuesta, pueden tambin llamar a otros componentes. Arquitecturas de llamada de procedimiento remoto: Los componentes de una arquitectura de programa principal/subprograma, estn distribuidos entre varias computadoras en una red. Arquitecturas estratificadas. En la estructura bsica de una arquitectura estratificada se crea diferentes capas y cada una realiza operaciones que progresivamente se aproximan ms al cuadro de instrucciones de la mquina. En la capa externa, los componentes sirven a las operaciones de interfaz de usuario. En la capa interna, los componentes realizan operaciones de interfaz del sistema. Las capas intermedias proporcionan servicios de utilidad y funciones del software de aplicaciones.
2.2.2.3 Diseo de Interfaz El plano de una casa (su diseo arquitectnico) no est completo sin la representacin de puertas, ventanas y conexiones de servicios para el agua, electricidad y telfono (por no mencionar la televisin por cable). Las puertas, ventanas y conexiones de servicios del software informtico es lo que constituye el diseo de la interfaz de usuario. El objetivo de esta tarea es realizar el diseo detallado de la interfaz de usuario, tanto de pantalla como impresa (reportes), a partir de la especificacin obtenida en el
36
proceso de Anlisis del Software, de acuerdo al entorno tecnolgico (Arquitectura) seleccionado, considerando los estndares y directrices marcados por la instalacin. En esta etapa se elabora el detalle de la navegacin entre ventanas y la informacin precisa para la ejecucin de cada dilogo, identificando las relaciones de dependencia entre los datos para establecer la secuencia de presentacin ms apropiada. Se determinan los datos obligatorios y opcionales, y aquellos que requieren un rango de valores predefinido o algn tipo de informacin que se considere relevante en el contexto del dilogo. Se comprueba que la informacin necesaria en cada interfaz, tanto de pantalla como impresa, es tratada por el mdulo correspondiente de la arquitectura del sistema Igualmente, se realiza el diseo de los mensajes de error, mensajes de aviso o advertencia que genera el sistema en funcin del tipo de accin realizado por el usuario en el contexto del dilogo, as como las facilidades de ayuda que proporciona la interfaz durante la interaccin con el sistema. Reglas de oro para el diseo de la interfaz 1. Dar el control al usuario 2. Reducir la carga de memoria del usuario 3. Construir una interfaz consistente Estas reglas de oro forman en realidad la base para los principios del diseo de la interfaz de usuario que servirn de gua para esta actividad de diseo del software tan importante. Dar el control al usuario
Es necesario que las interfaces sean intuitivas, flexibles y adecuadas para la interaccin del usuario. Tambin es muy importante dar opciones de rehacer/deshacer, de interrumpir una accin o volver a ejecutar una accin. Reducir la carga de memoria del usuario
Cuanto ms tenga que recordar un usuario, ms propensa a errores ser su interaccin con el sistema. Esta es la razn por la que una interfaz de usuario bien diseada no pondr a prueba la memoria del usuario. Siempre que sea posible, el sistema deber recordar la informacin pertinente y ayudar a que el usuario recuerde mediante un escenario de interaccin. Cuando los usuarios se ven involucrados en tareas complejas, exigir una memoria a corto plazo puede ser significativo. La interfaz se deber disear para reducir los requisitos y recordar acciones y resultados anteriores. Esto se puede llevar a cabo mediante claves visuales que posibiliten al usuario reconocer acciones anteriores sin tenerlas que recordar (valores por defecto). La interfaz deber adquirir y presentar la informacin de forma consistente
Esto implica que toda la informacin visual est organizada de acuerdo con el diseo estndar que se mantiene en todas las presentaciones de pantallas.
37
Mantener la consistencia en toda la familia de aplicaciones. Un conjunto de aplicaciones deber implementar las mismas reglas de diseo para mantener la consistencia en toda la interaccin. Una vez que una secuencia interactiva se ha convertido en un estndar (por ejemplo, la utilizacin de alt + S para grabar un archivo), el usuario espera utilizar esta combinacin en todas las aplicaciones que se encuentre. Un cambio podra originar confusin (por ejemplo, la utilizacin de alt + S para invocar la funcin cambiar de tamao). Formatos Individuales de Interfaz de Pantalla Para el diseo de las interfaces se sugiere definir una plantilla que sea aplicada a todas las de entrada de datos.
A continuacin ejemplos de diseo de interfaces:

Registro de clientes
Datos a Registrar
Cdula: Apellidos: Nombres:

Guardar
Clie_Cedu Clie_Apel Clie_Nomb
Mensajes de alerta Mensajes de ayuda
NOTA: Los campos detallados en este formulario, manejan el mismo tipo y tamao de datos correspondientes a la tabla: cliente.
38
Formatos Individuales de Reportes Para el diseo de los reportes se sugiere definir una plantilla que sea aplicada a todas las salidas de datos.
39
A continuacin ejemplos de diseo de reportes:
Catlogo de Controles del Diseo de Interfaz de Pantalla Es muy importante definir los conos y las acciones a realizar por cada uno de ellos dentro de las pantallas de entrada de datos. Id C1 C2 C3 C4 C5 C6 C7 C8 C9 Icono Alias Nuevo Abrir Guardar Editar Imprimir Consultar Anular Deshacer Ayuda Accin Agrega nuevos registros. Abre registros. Almacena registros. Edita registros Imprime reportes Vista preliminar de reportes Anula registros Deshace una accin Muestra la ayuda del sistema
2.2.2.4 Diseo Procedimental Esta tarea se realiza despus que se ha establecido la estructura del programa (diseo arquitectnico) y de los datos. Debemos especificar los detalles de los procedimientos del funcionamiento de la interfaz sin ambigedad. Notaciones grficas para el diseo procedimental Diagrama de flujo u organigrama
40
Es la representacin grfica ms usada para el diseo procedimental, la notacin es la siguiente:
41
Diagrama de cajas Tambin conocidos como diagramas de cajas.
Una notacin de diseo debe conducir a una representacin procedimental, que sea fcil de comprender, revisar y sobre todo debe de facilitar la codificacin. A continuacin unos ejemplos: Diseo procedimental para una consulta de informacin:
42
Inicio
Fecha_inicial, fecha_final
Cargar consulta de la(s) tabla(s)
Consulta de la(s) tabla(s)

NO
Imprimir = "Si"
SI
NO
Consulta de la(s) tabla(s)
Consultar = "NO"
SI
Fin
43
Diseo procedimental para almacenamiento de informacin:

Inicio
Forma_factura, Tipo_factura
Cabecera_factura
Cargar procedimiento de clientes
Cargar procedimiento de garantes
Cargar procedimiento de art culos
Detalle_factura
Meses
Letras de pago
Cargar procedimiento de validacin
Validacin="ok"
SI
NO
Cabecera_Factura, Detalle_Factura
Fin
44
2.2.2.5 Diseo de mens Dentro del diseo, es tambin importante la organizacin del men de opciones del software, ya que esto le facilitar el acceso al usuario en las diferentes opciones del sistema. A continuacin se detalla el significado de mens. Mens: Herramienta de seleccin de opciones en un programa. Tipos de mens Debido a la tendencia grfica del diseo de interfaces, en la actualidad, se presentan dos variantes de mens: a) Los mens de tipo ndice, consiste en una lista de palabras o frases muy cortas que describen o indican lo que la opcin puede hacer. Se pueden utilizar tipos de letras, estilos y tamaos para hacer el men ms legible y ms estructurado. b) Los mens mediante pequeos iconos, describen las acciones que el software ofrece en un momento determinado. Encontrar estos iconos no es tarea fcil, ya que los dibujos deberan indicar la accin que su seleccin desencadena. Mens anidados.- Los mens se pueden presentar como mens de mens o mens anidados. Cada opcin del men abre otro men y la seleccin final se hace en las hojas del rbol de mens. Este recorrido de un rbol de selecciones no debe ser muy profundo, mximo 3 niveles. Generalmente los submens se abren a la derecha y hacia abajo. Cuando los mens encuentran el borde derecho e inferior de la ventana se deben abrir hacia arriba y a la izquierda.
Mens pull-down (emergentes).- Este men se desenrolla hacia abajo al presionar la opcin del men.
Reglas para el diseo de mens. No deben ser muy largos ni muy anidados. El estilo, tipo y tamao del texto debe ayudar a la presentacin del men. El men puede contener al lado de su texto la clave o tecla a presionar para una seleccin rpida desde el teclado para usuarios expertos. El men no debe tapar los elementos presentes en la pantalla que son necesarios para tomar una decisin. 45
Unidad Didctica III IMPLEMENTACIN, PRUEBAS Y MANTENIMIENTO DEL SOFTWARE
46
UNIDAD DIDACTICA III: IMPLEMENTACIN, PRUEBAS Y MANTENIMIENTO DEL SOFTWARE OBJETIVO: Construir software en base a las diferentes vistas de diseo, utilizando las herramientas ms adecuadas con proyeccin a la obtencin del producto final (el software y su documentacin).
3. IMPLEMENTACION, PRUEBAS Y MANTENIMIENTO DEL SOFTWARE 3.1. CODIFICACIN

3.1.1. Preparacin del entorno de generacin de cdigo fuente El objetivo de esta actividad es asegurar la disponibilidad de todos los medios y facilidades para que se pueda llevar a cabo la construccin del software. Entre estos medios, cabe destacar la preparacin de los puestos de trabajo, equipos fsicos y lgicos, gestores de bases de datos, bibliotecas de programas, herramientas de generacin de cdigo, bases de datos o ficheros de prueba, entre otros. Las caractersticas del entorno de implementacin y sus requisitos de operacin y seguridad, as como las especificaciones de construccin de la estructura fsica de datos, que constituyen el punto de partida para la realizacin de esta actividad.
3.1.1.1.
Implantacin de la base de datos fsica o ficheros
En esta tarea hay que: Crear los elementos del sistema gestor de base de datos o sistema de ficheros. Reservar el espacio de almacenamiento, definiendo, entre otros, los dispositivos fsicos a emplear, tamao de los bloques, tipo de registro fsico, opciones de almacenamiento de datos, etc. Inicializar la base de datos o ficheros, cargando los datos considerados necesarios en el espacio de almacenamiento previamente definido. Preparacin del entorno de implementacin
3.1.1.2.
En esta tarea se prepara el entorno en el que se construirn los componentes del software, contemplando aspectos tales como: Bibliotecas o libreras a utilizar Herramientas: generadores de cdigo, editores, compiladores, verificadores sintcticos Puestos de trabajo Implementacin de los procedimientos de operacin y seguridad propios del entorno de implementacin, de acuerdo a los requisitos de seguridad y operacin establecidos.
3.1.2. Normas de implementacin del software
47
El software es desarrollado y mantenido por personas tcnicas que forman equipos, los cuales deben contar con estndares que les permitan forzar a organizarse. Estos estndares sirven para que otros entiendan: Qu escribi uno Por qu Cmo se relaciona con el trabajo de otros
Es necesario que en la generacin del cdigo fuente se deba documentar todo el proceso de construccin, para lo cual se debe etiquetar con: Encabezados y comentarios. Documentacin de Encabezamiento La documentacin de encabezamiento debe contener los siguientes datos al inicio de cada archivo: Estado y fecha de creacin. Autor. Descripcin de cul es la funcionalidad. Si se relaciona con algn otro archivo (con cul). Una lista de los cambios que se van haciendo.
A esta lista se pueden agregar algunos comentarios que el autor considere relevantes. Comentarios Los comentarios hacen referencia a las etiquetas que debemos colocar en el cdigo fuente que se va generando. A continuacin unos ejemplos: // Incremento i3 i3 = i3 + 1; // Ajusto contador para leer siguiente i3 = i3 + 1; case_counter = case_counter + 1; 3.1.3. Construccin del cdigo fuente Para la construccin del cdigo fuente es necesario seguir algunas recomendaciones que ayudarn a los programadores a mantener una misma escritura del cdigo fuente, a fin de que otros puedan entender el trabajo ya realizado. Las variables comunes utilizadas dentro de los procedimientos o funciones deben ser escritas con letras minsculas. Codificar cada variable con un nombre que intente describir lo ms cercano posible la utilidad que va a tener. Ejemplo: iva, saldo_fac. Antes de cada procedimiento o funcin se debe documentar con un comentario.
48
Los nombres de los objetos en los formularios debern llevar al inicio el identificativo de la clase a la cual pertenecen y en maysculas. Ejemplos: o o o o o o o Formularios: Frm Cuadros de texto: Txt Botones: Btn ComboBox: Cmb Listas: Lst Reportes: Rpt Mens: Mns
Los nombres de las variables que van a contener informacin de la base de datos deben empezar con: rs_ si se trata de un recordset, Ejemplo: rs_cliente. Y row_ si se trata de una variable que almacena la informacin en un arreglo producto de un recorset, Ejemplo: row_cliente. En caso de almacenar el total de registros utilizar total_. Ejemplo: total_cliente. Si se encuentran errores, stos deben ser corregidos inmediatamente donde se encontraron y no a travs de un parche, ms adelante en el cdigo o en el flujo del programa travs ms cdigo. No intentar ser muy inteligente al momento de codificar. Se debe intentar escribir soluciones lo ms simple posibles. Usar un espaciado apropiado (identacin) en los programas, y hacerlo de manera consistente, hace los programas ms fciles de leer.
A ms de esto es importante mencionar que la codificacin comienza cuando hay algn diseo ya realizado y toda su especificacin del mdulo a desarrollar.
3.2.
REVISIN Y EJECUCIN DEL PLAN DE PRUEBAS
3.2.1. Ejecucin de las pruebas de acuerdo a los tipos y tcnicas planificadas Las pruebas se realizan a lo largo del desarrollo del software (pruebas informales) y no simplemente al final. Las pruebas se realizan en los subsistemas o mdulos del software antes de que sea puesto en produccin, stos son revisados con datos de prueba para ver si los mdulos trabajan correctamente entre ellos, tal como se plane. Tambin debe ser probado el software trabajando como un todo. Esto incluye probar las interfaces entre subsistemas, la correccin de la salida, la utilidad y comprensibilidad de la documentacin de la salida del software. Para la ejecucin de las pruebas en la etapa correspondiente, utilizamos la planificacin ya establecida en la gestin de proyecto del software, en donde estn definidas las tcnicas para conseguir y detectar los defectos existentes.
Para el enfoque de la prueba en un software de una magnitud mediana y grande es recomendable la tcnica de caja negra, para la cual no es necesario conocer la
49
estructura lgica de las partes a evaluar como en la tcnica de caja blanca, sino que es suficiente las entradas y las salidas del software.
Durante la ejecucin de las pruebas, el plan debe guiarnos a corroborar ciertos puntos estndares en el funcionamiento del software, detallados a continuacin: Identificar las restricciones al formato y contenido de los datos de las entradas. Identificar datos vlidos. Identificar datos no vlidos o errneos. Explorar las condiciones lmites de un software. Si la entrada o la salida de un software es un conjunto ordenado (por ejemplo, una tabla, un archivo secuencial, otros), los casos deben concentrarse en el primero y en el ltimo elemento. Enumerar una lista de errores comunes y en funcin de ella elaborar los casos de prueba. Es importante la intuicin y la experiencia. Ejemplos: o El valor cero es una situacin propensa a error tanto en la salida como en la entrada. o Cuando se introduce un nmero variable de valores, centrarse en el caso de no introducir ningn valor y en el de un solo valor. Tambin puede ser interesante una lista que tiene todos los valores iguales. o Es recomendable imaginar que el programador pudiera haber interpretado algo mal en la especificacin. o Tambin interesa imaginar lo que el usuario puede introducir como entrada a un software.
3.2.2. Obtencin de los resultados de las pruebas La obtencin de los resultados de las pruebas es producto de la documentacin de todos los hechos relevantes ocurridos durante la ejecucin del plan de pruebas.
50
Es necesario documentar cada incidente (Ejemplo: Una interrupcin en las pruebas debido a un corte de electricidad, bloqueo del teclado, etc.) ocurrido en la prueba y que requiera una posterior investigacin. Los expertos encargados de realizar las pruebas del software debern emitir un informe de resultados, documento que tendr el siguiente formato:
INFORME DE REVISION Y RESULTADOS DEL PLAN DE PRUEBA

NOMBRE DEL PRODUCTO: CODIGO: FECHA: LUGAR:
DESCRIPCION DEL PRODUCTO
DESARROLLADORES NOMBRES APELLIDOS
EVALUACION DE ITEMS CODIGO DE PRUEBA RESULTADOS
EQUIPO DE REVISION
NOMB RES Y APELLIDOS PROFES ION OCUPACION ACTUAL DIRECCION LABORAL
______________________________ FIRMA RESPONSABLE
Estos informes debern contener todas las anomalas encontradas en el software, en sus diferentes mdulos durante la etapa de las pruebas.
51
3.3.
DEPURACIN DE LOS ERRORES, FALLOS ENCONTRADOS EN EL SOFTWARE
Y DEFECTOS
Con los informes finales de las pruebas emitidos por los evaluadores, lo siguiente es localizar, analizar y corregir los defectos que contiene el software. Es decir que se debe encontrar la causa del error, analizarla y corregirla. 3.3.1. Etapas de la Depuracin La depuracin est compuesta por dos etapas detalladas a continuacin: Localizacin del error (mayor esfuerzo) Correccin del defecto Localizacin del Error
3.3.1.1.
Detectar el error en muchos de los casos no es tarea fcil, ya esto conlleva a realizar un anlisis profundo, que por lo general toma demasiado tiempo. Anlisis de errores Cuando un error es localizado, no basta solo con corregir el defecto, es necesario realizar un intensivo anlisis y determinar cul fue la causa, ya que esto nos ayudar corregir otros posibles errores cuando el software asuma diferentes valores para procesar. Dependiendo de la ubicacin del error en el ciclo de vida de las pruebas, ser necesario volver a revisar la documentacin en la etapa correspondiente del paradigma de desarrollo del software.
En el grafico anterior podemos ver el ciclo de vida de las pruebas del software, y en comparacin con el grfico mostrado en el tema I de esta gua, podemos evidenciar
52
dos etapas como son la: Funcional y Desempeo, las cuales estn agrupadas en las Pruebas de Sistema, del grafico mostrado en esta pgina. De la mano con la revisin de la documentacin en la etapa del paradigma de desarrollo del software donde se localiz el error, y como parte del anlisis de errores, es necesario contestar las siguientes preguntas: Cundo se cometi? Quin lo hizo Qu se hizo mal? Cmo se podra haber prevenido? Por qu no se detect antes? Cmo se podra haber detectado antes? Cmo se encontr el error? Correccin del defecto
3.3.1.2.
El defecto deber ser corregido por los encargados en la etapa del paradigma donde encontr el problema.
3.4.
MANUAL TCNICO, DE INSTALACIN Y DE USUARIO
3.4.1. Manual Tcnico El manual tcnico est dirigido al personal del rea tcnica como: programadores, analistas, ingenieros, entre otros, con el nico objetivo de brindar el debido soporte para entender la estructura interna del sistema informtico y poder mejorar e incorporar nuevos procesos en un futuro. Este manual est estructurado por cada uno de los diferentes documentos que han sido elaborados en el proceso de desarrollo del software. 3.4.2. Manual de Instalacin El manual de instalacin est tambin dirigido al personal tcnico, pero sobre todo a los administradores, operadores y usuarios expertos del software. Este manual debe mostrar paso a paso cmo configurar y hacer funcionar el software partiendo desde cero, orientndonos acerca de los requerimientos mnimos que se necesitan para operar el software, aspectos importantes para la puesta en marcha del motor de bases de datos y as como la creacin de los usuarios para la utilizacin del mismo. 3.4.3. Manual de Usuario El manual de usuario est dirigido a los usuarios finales del software, y tiene el objetivo de dar las directrices para el correcto manejo de las funciones que realiza el software, ilustrando cmo acceder al sistema, tambin debe mostrar las diferentes opciones que posee el men principal y luego debe evidenciar todas las opciones operacionales del software a travs de ejemplos prcticos.
53
3.5.
IMPLANTACIN DEL SOFTWARE
Este proceso tiene como objetivo principal la entrega y aceptacin del sistema en su totalidad, y la realizacin de todas las actividades necesarias para el paso a produccin del mismo. En esta actividad interviene la participacin del usuario de operacin (administrador) en las pruebas de implantacin, del usuario final en las pruebas de aceptacin, y del responsable de mantenimiento. Las actividades previas al inicio de la produccin incluyen la preparacin de la infraestructura necesaria para configurar el entorno, la instalacin de los componentes, la activacin de los procedimientos manuales y automticos asociados y la migracin o carga inicial de datos y su documentacin asociada. Se realizan las pruebas de implantacin y de aceptacin del sistema en su totalidad, las cuales responden a los siguientes propsitos: Las pruebas de implantacin cubren un rango muy amplio, que va desde la comprobacin de cualquier detalle de diseo interno hasta aspectos tales como las comunicaciones. Se debe comprobar que el sistema puede gestionar los volmenes de informacin requeridos, se ajusta a los tiempos de respuesta deseados y que los procedimientos de respaldo, seguridad e interfaces con otros sistemas funcionan correctamente. Se debe verificar tambin el comportamiento del sistema bajo las condiciones ms extremas. Las pruebas de aceptacin se realizan por y para los usuarios. Tienen como objetivo validar formalmente que el sistema se ajusta a sus necesidades. La transicin del sistema antiguo al nuevo.
3.5.1. Migracin de datos Teniendo en cuenta que el software a implantar puede mejorar, ampliar o sustituir a otros ya existentes en la organizacin, puede ser necesaria una carga inicial o una migracin de datos. Una migracin de datos puede venir determinada desde el proceso del estudio preliminar, en la actividad alternativas de solucin. En la carga inicial de datos del nuevo sistema, se comprueba que ha finalizado correctamente su instalacin y a continuacin se hace la migracin de datos, activando los procedimientos correspondientes, para efectuar la transformacin de los datos de la estructura existente a la nueva. Los participantes en la migracin de datos son: El equipo de implantacin, equipo de operacin, administradores de bases de datos y usuarios expertos. 3.5.2. Puesta a produccin Esta actividad tiene como objetivo establecer el punto de inicio en que el sistema pase a produccin y se empiezan a dar los servicios para el cual fue construido el sistema informtico. Para ello es necesario que est instalado correctamente el hardware y software de base, componentes del nuevo sistema y procedimientos manuales y automticos.
54
Una vez que el sistema ya est en produccin, se les notificar al responsable de mantenimiento y al responsable de operacin (administrador).
3.6.
Mantenimiento del software
El mantenimiento del software surge debido a que el sistema por naturaleza es cambiante por cualquier modificacin realizada luego de entrar en produccin. El objetivo de este proceso es la obtencin de una nueva versin del software desarrollado, a partir de las peticiones de mantenimiento que los usuarios realizan con motivo de un problema detectado en el sistema, o por la necesidad de una mejora del mismo. En este proceso se realiza el registro de las peticiones de mantenimiento recibidas, con el fin de llevar el control de las mismas y de proporcionar, si fuera necesario, datos estadsticos de peticiones recibidas o atendidas en un determinado periodo. Sistemas se han visto afectados por los cambios, en la medida y el tiempo empleado para la resolucin de dichos cambios. Es recomendable, por lo tanto, llevar un catlogo de peticiones de mantenimiento sobre los sistemas informticos, en el que se registren una serie de datos que nos permitan disponer de la informacin antes mencionada. Una vez registrada la peticin y su origen, se determina de quin es la responsabilidad de atender la peticin. En el supuesto de que la peticin sea remitida, se registra en el catlogo de peticiones de mantenimiento y contina el proceso. La peticin puede ser denegada. En este caso, se notifica al usuario y acaba el proceso. La estructura propuesta para el proceso de mantenimiento comprende las siguientes actividades:
Registro de la peticin
Anlisis de la peticin
Preparacin de la implementacin de la modificacin
Seguimiento y Evaluacin de los cambios
3.6.1. Tipos de mantenimientos Correctivo: Son aquellos cambios precisos para corregir errores del producto software. Evolutivo: Son las incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansin o cambio en las necesidades del usuario. Adaptativo: Son las modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de configuracin del hardware, software de base, gestores de base de datos, comunicaciones, etc.
55
Perfectivo: Son las acciones llevadas a cabo para mejorar la calidad interna de los sistemas en cualquiera de sus aspectos: reestructuracin del cdigo, definicin ms clara del sistema y optimizacin del rendimiento y eficiencia. 3.6.2. Rejuvenecimiento del software Dentro del mantenimiento del software, el rejuvenecimiento trata de mejorar la calidad global de un sistema informtico, tiene que ver con re-documentar el anlisis del cdigo fuente para proveer ms informacin para asistir al mantenimiento, reestructurar y transformar cdigo mal estructurado en cdigo bien estructurado, transformar la arquitectura, aplicando Ingeniera Reversa o Reingeniera, es decir recrear diseo y especificacin a partir del cdigo. A continuacin un grfico para poder entender el rejuvenecimiento del software:
Especificacin Diseo Cdigo Fuente
56
Unidad Didctica IV INGENIERA DE SOFTWARE ORIENTADO A OBJETOS
57
UNIDAD DIDACTICA IV: INGENIERA DE SOFTWARE ORIENTADOS A OBJETOS OBJETIVO: Modelar el software en base a la perspectiva de la tcnica orientada a objetos en sus dos fases: anlisis y diseo, para una mejor abstraccin del problema a resolver.
4. INGENIERA DE SOFTWARE ORIENTADOS A OBJETOS 4.1. EL PARADIGMA ORIENTADO A OBJETOS

En el paradigma orientado a objetos, los sistemas estn compuestos por un conjunto de objetos. Estos objetos son responsables de llevar a cabo ciertas acciones. Los objetos colaboran para llevar a cabo sus responsabilidades. Dentro de los principios del paradigma orientado a objetos tenemos: Todo es un objeto Los objetos se comunican enviando y recibiendo mensajes Los objetos tienen su propia memoria (en trminos de objetos)
En este paradigma la principal construccin es la nocin de objetos, siendo los objetos bsicamente unidades de comportamiento. La forma de pedirle a un objeto que lleve a cabo una determinada tarea es por medio del envo de un mensaje. Qu es un programa en el paradigma OO? Un conjunto de objetos que colaboran envindose mensajes.
4.2.
CONCEPTOS DEL PARADIGMA ORIENTADO A OBJETOS
4.2.1. Clases Una clase es la estructura de un objeto, es decir, la definicin de todos los elementos de que est hecho un objeto. Un objeto es, por lo tanto, el "resultado" de una clase. En realidad, un objeto es una instancia de una clase, por lo que se pueden intercambiar los trminos objeto o instancia (o incluso evento). Las clases son plantillas que agrupan comportamiento (mtodos) y estados (atributos) de los futuros objetos.
58
Una clase se compone de dos partes: Atributos.- Denominados, por lo general, datos que se refieren al estado del objeto. Mtodos.- Denominados, por lo general, funciones que pueden aplicarse a objetos. Una operacin o mtodo es una funcin o transformacin que puede ser aplicada sobre los objetos en una clase. Por ejemplo: abrir, cerrar, ocultar, desplegar, son operaciones sobre una clase ventana. Cada operacin tiene un objeto destino con un argumento implcito. El comportamiento de la operacin depende de la clase destino.
Si tenemos una clase llamada auto, los objetos Peugeot y Renault sern instancias de esa clase. Tambin puede haber otros objetos Peugeot 406, diferenciados por su nmero de modelo. Asimismo, dos instancias de una clase pueden tener los mismos atributos, pero considerarse objetos distintos independientes. En un contexto real: dos camisas pueden ser idnticas, pero no obstante, tambin ser diferentes de alguna manera. Sin embargo, si las mezclamos es imposible distinguir una de la otra. 4.2.2. Objetos Se puede decir que un objeto es todo aquello que pueda ser identificable dentro de una especificacin de requerimientos o problemas y que tenga las siguientes caractersticas:

Tenga estados definibles (abierto, cerrado). Posea comportamientos asociados (puede correr, saltar, volar, etc.). stos son denominados mtodos. Son capaces de interactuar/comunicarse con otros objetos por medio de sus mtodos
Una caracterstica propia de este paradigma, es la transparencia entre la implementacin a nivel de cdigo y la funcionalidad que provee un mtodo (no me interesa cmo lo haga, slo que lo haga). Qu se puede considerar como objeto? Persona Equipo Hardware Materiales Informacin Software Procesos Procedimientos
4.2.3. Mensajes Un programa orientado a objetos, est constituido por varios objetos en ejecucin, que estn interrelacionados. Esta interrelacin se da a travs de mensajes que ellos se pasan entre s. En la POO un mensaje est relacionado con un objeto, de tal forma que cuando un objeto recibe un mensaje, la respuesta a ese mensaje es ejecutar el mtodo asociado.
59
4.2.4. Encapsulamiento Hay muchos datos que no tiene por qu conocerlo aquel que est usando una clase. Por ejemplo la clase Persona, ya que son inherentes al objeto y solo controlan su funcionamiento interno; por ejemplo, cuando alguien te ve puede saber inmediatamente si eres hombre o mujer (propiedad-atributo) o puede hablarte y obtener una respuesta procesada (mtodo), tambin puede conocer el color de tu cabello y ojos. En cambio, jams sabr qu cantidad de energa exacta tienes o cuntas neuronas te quedan, ni siquiera preguntndote ya que ninguna de tus propiedades externas visibles o funciones de comunicacin al pblico te permiten saber esos datos. Esto es la encapsulacin u ocultacin, hacer las variables que son innecesarias para el tratamiento del objeto pero necesarias para su funcionamiento privado, as como las funciones que no necesitan interaccin del usuario o que solo pueden ser llamadas por otras funciones dentro del objeto. Como por ejemplo: palpitar. La encapsulacin es muy conveniente y nos permite (si programamos bien) colocar en funcionamiento nuestro objeto en cualquier tipo de sistema, de una manera modular y escalable (algunas de las reglas de la ingeniera del software). Formas de encapsular Abierto: Hace que el miembro de la clase pueda ser accedido desde el exterior de la clase y cualquier parte del programa. Protegido: Solo es accesible desde la clase y las clases que heredan (a cualquier nivel). Cerrado: Solo es accesible desde las clases.
4.2.5. Herencia En los conceptos anteriores no se ha visto nada ms interesante que una forma ms cmoda de escribir Estructura de datos, pero qu pasa si por ejemplo, necesitamos extender el comportamiento de un objeto que posee las mismas caractersticas de comportamiento y adems tiene otras caractersticas propias? La reutilizacin de cdigo es fundamental en este paradigma y en casos como estos se expresa como Herencia, cuya estructura jerrquica nos permite extender clases heredando todo (comportamientos y estados) desde una clase padre o sper clase. Las clases que hereden de una sper clase se denominan clases hijas o sub clases. Ejemplo: Imaginemos que una persona ha sido expuesta a una extraa radiacin y ahora tiene sper poderes, por lo que no deja de ser persona, pero ahora tiene nuevos comportamientos y estados, por lo que diremos que la nueva clase Superhroe hereda de la clase persona. 4.2.6. Polimorfismo Polimorfismo significa que la misma operacin puede comportarse diferentemente sobre distintas clases. Por ejemplo, la operacin "mover" puede comportarse diferentemente sobre una clase llamada ventana y una clase llamada piezas_ajedrez.
4.3.
METODOLOGAS ORIENTADAS A OBJETOS

60
4.3.1. LA METODOLOGA OMT (OBJECT MODELING TECHNIQUE) Esta metodologa fue creada por James Rumbaugh y Michael Blaha en 1991, mientras James diriga un equipo de investigacin de los laboratorios General Electric. OMT es una de las metodologas de anlisis y diseo orientadas a objetos ms maduras y eficientes que existen en la actualidad. La gran virtud que aporta esta metodologa es su carcter de abierta (no propietaria), que le permite ser de dominio pblico y, en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolucin para acoplarse a todas las necesidades actuales y futuras de la ingeniera de software. Las fases que conforman a la metodologa OMT Anlisis.- El analista construye un modelo del dominio del problema, mostrando sus propiedades ms importantes. El modelo de anlisis es una abstraccin resumida y precisa de lo que debe de hacer el sistema deseado y no de la forma en que se har. Los elementos del modelo deben ser conceptos del dominio de aplicacin y no conceptos informticos tales como estructuras de datos. Un buen modelo debe poder ser entendido y criticado por expertos en el dominio del problema que no tengan conocimientos informticos. Diseo del sistema.- El diseador del sistema toma decisiones de alto nivel sobre la arquitectura del mismo. Durante esta fase el sistema se organiza en subsistemas basndose tanto en la estructura del anlisis como en la arquitectura propuesta. Diseo de objetos.- El diseador de objetos construye un modelo de diseo basndose en el modelo de anlisis, pero incorporando detalles de implementacin. El diseo de objetos se centra en las estructuras de datos y algoritmos que son necesarios para implementar cada clase. OMT describe la forma en que el diseo puede ser implementado en distintos lenguajes (orientados y no orientados a objetos, bases de datos, etc.). Implementacin.- Las clases de objetos y relaciones desarrolladas durante el anlisis de objetos se traducen finalmente a una implementacin concreta. Durante la fase de implementacin es importante tener en cuenta los principios de la ingeniera del software de forma que la correspondencia con el diseo sea directa y el sistema implementado sea flexible y extensible. No tiene sentido que utilicemos AOO y DOO de forma que potenciemos la reutilizacin de cdigo y la correspondencia entre el dominio del problema y el sistema informtico, si luego perdemos todas estas ventajas con una implementacin de mala calidad. Modelos para describir el sistema en la metodologa OMT Modelo de objetos.- Describe la estructura esttica de los objetos del sistema (identidad, relaciones con otros objetos, atributos y operaciones). El modelo de objetos proporciona el entorno esencial en el cual se pueden situar el modelo dinmico y el modelo funcional. El objetivo es capturar aquellos conceptos del mundo real que sean importantes para la aplicacin. Se representa mediante diagramas de objetos. Modelo dinmico.- Describe los aspectos de un sistema que tratan de la temporizacin y secuencia de operaciones (sucesos que marcan los cambios, secuencias de sucesos, estados que definen el contexto para los sucesos) y la organizacin de sucesos y estados. Captura el control, aquel aspecto de un 61
sistema que describe las secuencias de operaciones que se producen sin tener en cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en que estn implementadas. Se representa grficamente mediante diagramas de estado. Modelo funcional.- Describe las transformaciones de valores de datos (funciones, correspondencias, restricciones y dependencias funcionales) que ocurren dentro del sistema. Captura lo que hace el sistema, independientemente de cundo se haga o de la forma en que se haga. Se representa mediante diagramas de flujo de datos.
4.3.2. LA METODOLOGA RUP (RATIONAL UNIFIED PROCESS) Las siglas RUP en ingls significa Rational Unified Process (Proceso Unificado de Rational) es un producto del proceso de ingeniera del software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin del desarrollo. Su meta es asegurar la produccin del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo establecidos. 4.3.2.1. Dimensiones del RUP
El RUP tiene dos dimensiones: El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del proceso. El eje vertical representa las disciplinas, que agrupan actividades definidas lgicamente por la naturaleza.
La primera dimensin representa el aspecto dinmico del proceso y se expresa en trminos de fases, de iteraciones, y la finalizacin de las fases. La segunda dimensin representa el aspecto esttico del proceso: cmo se describe en trminos de componentes de proceso, las disciplinas, las actividades, los flujos de trabajo, los artefactos, y los roles. En la siguiente figura se puede observar como vara el nfasis de cada disciplina en un cierto plazo en el tiempo, y durante cada una de las fases. Por ejemplo, en iteraciones tempranas, pasamos ms tiempo en requerimientos, y en las ltimas iteraciones pasamos ms tiempo en poner en prctica la realizacin del proyecto en s.
62
Disciplinas, fases, iteraciones del RUP
Se puede hacer mencin de las tres caractersticas esenciales que definen al RUP: Proceso Dirigido por los Casos de Uso: Con esto se refiere a la utilizacin de los Casos de Uso para el desenvolvimiento y desarrollo de las disciplinas con los artefactos, roles y actividades necesarias. Los Casos de Uso son la base para la implementacin de las fases y disciplinas del RUP. Un Caso de Uso es una secuencia de pasos a seguir para la realizacin de un fin o propsito, y se relaciona directamente con los requerimientos, ya que un Caso de Uso es la secuencia de pasos que conlleva la realizacin e implementacin de un Requerimiento planteado por el Cliente. Proceso Iterativo e Incremental: Es el modelo utilizado por RUP para el desarrollo de un proyecto de software. Este modelo plantea la implementacin del proyecto a realizar en Iteraciones, con lo cual se pueden definir objetivos por cumplir en cada iteracin y as poder ir completando todo el proyecto iteracin por iteracin, con lo cual se tienen varias ventajas, entre ellas se puede mencionar la de tener pequeos avances del proyecto que son entregables al cliente, el cual puede probar mientras se est desarrollando otra iteracin del proyecto, con lo cual el proyecto va creciendo hasta completarlo en su totalidad. Proceso Centrado en la Arquitectura: Define la arquitectura de un sistema, y una arquitectura ejecutable construida como un prototipo evolutivo. Arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes. Una arquitectura ejecutable es una implementacin parcial del sistema, construida para demostrar algunas funciones y propiedades. 63
RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo.
4.3.2.2.
Fases
Fases del RUP
El ciclo de vida del software del RUP se descompone en cuatro fases secuenciales. En cada extremo de una fase se realiza una evaluacin (actividad: Revisin del ciclo de vida de la finalizacin de fase) para determinar si los objetivos de la fase se han cumplido. Una evaluacin satisfactoria permite que el proyecto se mueva a la prxima fase. Planeando las fases El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versin del producto, cada ciclo est compuesto por fases y cada una de estas fases est compuesta por un nmero de iteraciones, estas fases son: Concepcin, Inicio o Estudio de oportunidad Define el mbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto
Elaboracin Tanto la funcionalidad como el dominio del problema se estudian en profundidad. Se define una arquitectura bsica. Se planifica el proyecto considerando recursos disponibles
Construccin El producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas de anlisis, diseo e implementacin. Las fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu refinada de manera incremental conforme se construye (se permiten cambios en la estructura). Gran parte del trabajo es programacin y pruebas. Se documenta tanto el sistema construido como el manejo del mismo. Esta fase proporciona un producto construido junto con la Documentacin. 64
Transicin Se libera el producto y se entrega al usuario para un uso real. Se incluyen tareas de marketing, empaquetado atractivo, instalacin, configuracin, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la informacin anterior. Estas tareas se realizan tambin en iteraciones.
Todas las fases no son idnticas en trminos de tiempo y esfuerzo. Aunque esto vara considerablemente dependiendo del proyecto, un ciclo de desarrollo inicial tpico para un proyecto de tamao mediano debe anticipar la distribucin siguiente, el esfuerzo y horario:
Esfuerzo-horario contra fases del RUP
Lo cual se puede representar grficamente como se muestra en la siguiente imagen:
Recursos utilizados en las fases del RUP en el tiempo.
En un ciclo evolutivo, las fases de concepcin y elaboracin seran considerablemente ms pequeas. Algunas herramientas que pueden automatizar una cierta porcin del esfuerzo de la fase de construccin pueden atenuar esto, haciendo que la fase de construccin sea mucho ms pequea que las fases de concepcin y elaboracin juntas. Este es precisamente el objetivo del trabajo. Cada paso con las cuatro fases produce una generacin del software. A menos que el producto "muera", se desarrollar nuevamente repitiendo la misma secuencia: Las fases de concepcin, elaboracin, construccin y transicin, pero con diversos nfasis cada fase. Estos ciclos subsecuentes se llaman los ciclos de la evolucin. Mientras que el producto pasa durante varios ciclos, se producen las nuevas generaciones. A continuacin se muestre este ciclo evolutivo.
65
Ciclo evolutivo en la elaboracin de software basado en el RUP
Los ciclos evolutivos pueden ser iniciados por las mejoras sugeridas por el usuario, cambios en el contexto del usuario, cambios en la tecnologa subyacente, reaccin a la competicin, etc. Los ciclos evolutivos tienen tpicamente fases de concepcin y elaboracin mucho ms cortas, puesto que la definicin y la arquitectura bsicas del producto son determinadas por los ciclos de desarrollo anteriores. Las excepciones a esta regla son los ciclos evolutivos en los cuales ocurre o surge un producto significativo o una redefinicin arquitectnica. Esfuerzo respecto de los flujos de trabajo En la figura siguiente se muestran ciertos porcentajes, de forma vertical; se muestra el esfuerzo que se tiene que realizar por cada una de las disciplinas o flujos de trabajo, y los dos porcentajes que se muestran de forma horizontal son para todo el proyecto. Explicando ms puntualmente la figura 5 se puede observar que para la obtencin de requerimientos o requisitos en la fase de concepcin se empiezan a obtener, en la fase de elaboracin tiene su auge y va declinando en la fase de construccin, realizar todo esto requiere aproximadamente un 15% de esfuerzo, y as sucesivamente con las dems disciplinas. En esta seccin y la siguiente, los porcentajes pueden variar de un proyecto a otro.
Esfuerzo respecto de los flujos de trabajo
Esfuerzo respecto de las fases En la figura siguiente se muestran dos filas de porcentajes, el primero que es el esfuerzo realizado por cada fase en forma general e incluyendo las iteraciones dentro
66
de cada fase; y en la segunda fila, la duracin que tiene aproximadamente en porcentajes del tiempo total del proyecto para cada una de las fases incluyendo todas las iteraciones que conlleven realizar cada fase. Explicando puntualmente una pequea parte de la siguiente figura, se puede observar que para la fase de construccin se tiene que dedicar ms esfuerzo, mayor duracin, siempre y cuando dependiendo de qu disciplina estemos ejecutando, por ejemplo en la disciplina de implementacin se tiene mucho auge en la fase de construccin.
Esfuerzo respecto de las fases
4.3.2.3.
Iteraciones
El RUP maneja el proceso Iterativo Incremental para el desarrollo de las aplicaciones o proyectos, por tal motivo es de suma importancia explicar brevemente en qu consiste este proceso. Proceso Iterativo e Incremental Este proceso se refiere a la realizacin de un ciclo de vida de un proyecto y se basa en la evolucin de prototipos ejecutables que se muestran a los usuarios y clientes. En este ciclo de vida iterativo a cada iteracin se reproduce el ciclo de vida en cascada a menor escala, estableciendo los objetivos de una iteracin en funcin de la evaluacin de las iteraciones precedentes y las actividades se encadenan en una mini-cascada con un alcance limitado por los objetivos de la iteracin. En la siguiente figura se muestran los pasos a realizar para seguir el ciclo de vida iterativo incremental, hasta la realizacin de una fase.
67
Ciclo de vida Iterativo incremental
Para la realizacin de cada iteracin se tiene que tomar en cuenta la planificacin de la iteracin, estudiando los riesgos que conlleva su realizacin, tambin incluye el anlisis de los casos de uso y escenarios, el diseo de opciones arquitectnicas, la codificacin y pruebas, la integracin gradual durante la construccin del nuevo cdigo con el existente de iteraciones anteriores, la evaluacin de la entrega ejecutable (evaluacin del prototipo en funcin de las pruebas y de los criterios definidos) y la preparacin de la entrega (documentacin e instalacin del prototipo). Algunos de estos elementos no se realizan en todas las fases. A continuacin se presenta una comparacin entre 2 enfoques de un ciclo de vida del desarrollo de software, el primero consiste en el ciclo comn, el de cascada, en el cual cada disciplina se realiza al finalizar su predecesora y solo al finalizar la nueva se empieza la sucesora y as hasta terminar con las disciplinas necesarias.
En el grfico siguiente se muestra el ciclo de vida de un software siguiendo el enfoque Iterativo Incremental (utilizado por el RUP), en el cual se puede observar que en cada iteracin se realiza una pequea parte de cada disciplina en paralelo, aumentando as poco a poco hasta concluir con la realizacin de todas las disciplinas con un nmero de iteraciones prudente. En la grfica siguiente se habla de ingeniera del negocio y en la siguiente seccin de modelado del negocio, es necesario conservar la consistencia de esto en todo el trabajo, una u otra.
68
4.3.2.4.
Disciplinas
Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para la culminacin de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo. Las primarias son las necesarias para la realizacin de un proyecto de software, aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen: Modelado del Negocio, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Despliegue. Las de apoyo son las que como su nombre lo indica sirven de apoyo a las primarias y especifican otras caractersticas en la realizacin de un proyecto de software; entre estas se tienen: Entorno, Gestin del Proyecto, Gestin de Configuracin y Cambios. A continuacin se describe rpidamente cada una de estas disciplinas. Modelado del negocio Esta disciplina tiene como objetivos comprender la estructura y la dinmica de la organizacin, comprender problemas actuales e identificar posibles mejoras, comprender los procesos de negocio. Utiliza el Modelo de CU del Negocio para describir los procesos del negocio y los clientes, el Modelo de Objetos del Negocio para describir cada CU del Negocio con los Trabajadores, adems utilizan los Diagramas de Actividad y de Clases. Requerimientos Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer (Especificar Requisitos), definir los lmites del sistema, y una interfaz de usuario, realizar una estimacin del costo y tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden los CU, Actores y Relaciones, adems utiliza los diagramas de Estados de cada CU y las especificaciones suplementarias. Anlisis y diseo Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementacin, al decir anlisis se refiere a transformar CU en clases, y al decir diseo se refiere a refinar el anlisis para poder implementar los diagramas de clases de anlisis de cada CU, los diagramas de colaboracin de cada CU, el de clases de diseo de cada CU, el de secuencia de diseo de CU, el de estados de las clases, el modelo de despliegue de la arquitectura. Implementacin Esta disciplina tiene como objetivos implementar las clases de diseo como componentes (ej. fichero fuente), asignar los componentes a los nodos, probar los componentes individualmente, integrar los componentes en un sistema ejecutable (enfoque incremental). Utiliza el Modelo de Implementacin, conjuntamente con los Diagramas de Componentes para comprender cmo se organizan los Componentes y dependen unos de otros. Pruebas Esta disciplina tiene como objetivos verificar la integracin de los componentes (prueba de integracin), verificar que todos los requisitos han sido implementados
69
(pruebas del sistema), asegurar que los defectos detectados han sido resueltos antes de la distribucin. Despliegue Esta disciplina tiene como objetivos asegurar que el producto est preparado para el cliente, proceder a su entrega y recepcin por el cliente. En esta disciplina se realizan las actividades de probar el software en su entorno final (Prueba Beta), empaquetarlo, distribuirlo e instalarlo, as como la tarea de ensear al usuario. Gestin y configuracin de cambios Es esencial para controlar el nmero de artefactos producidos por la cantidad de personal que trabajan en un proyecto conjuntamente. Los controles sobre los cambios son de mucha ayuda ya que evitan confusiones costosas como la compostura de algo que ya se haba arreglado, etc., y aseguran que los resultados de los artefactos no entren en conflicto con algunos de los siguientes tipos de problemas: Actualizacin simultnea: Es la actualizacin de algo elaborado con anterioridad, sin saber que alguien ms lo est actualizando. Notificacin limitada: Al realizar alguna modificacin, no se deja informacin sobre lo que se hizo, por lo tanto no se sabe quin, cmo, y cundo se hizo. Versiones mltiples: No saber con exactitud, cul es la ltima versin, y al final no se tiene un orden sobre qu modificaciones se han realizado a las diversas versiones.
Gestin del proyecto Su propsito es equilibrar los objetivos competitivos, administrar el riesgo, y superar restricciones para entregar un producto que satisface las necesidades de ambos clientes con xito (los que pagan el dinero) y los usuarios. Con la Gestin del Proyecto se logra una mejora en el manejo de una entrega exitosa del software. En resumen su propsito consiste en proveer pautas para: Administrar proyectos de software intensivos. Planear, dirigir personal, ejecutar acciones y supervisar proyectos. Administrar el riesgo.
Sin embargo, esta disciplina no intenta cubrir todos los aspectos de direccin del proyecto. Por ejemplo, no cubre problemas como: Administracin de personal: contratando, entrenando, enseando. Administracin del presupuesto: definiendo, asignando. Administracin de los contratos con proveedores y clientes.
Entorno Esta disciplina se enfoca sobre las actividades necesarias para configurar el proceso que engloba el desarrollo de un proyecto y describe las actividades requeridas para el desarrollo de las pautas que apoyan un proyecto. Su propsito es proveer a la organizacin que desarrollar el software, un ambiente en el cual basarse, el cual provee procesos y herramientas para poder desarrollar el software.
70
4.3.2.5.
Organizacin y elementos en RUP
Ya conociendo varias partes del RUP nos concentraremos ahora en los elementos que lo componen, entre stos se tienen: Flujos de Trabajo, Detalle de los Flujos de Trabajo, Actores, Actividades y Artefactos. En la figura siguiente se muestran ms claramente cmo se representan grficamente cada uno de estos elementos y la interrelacin entre ellos. Se puede observar que el Flujo de Trabajo de Requerimientos conlleva varios pasos, cada uno de estos pasos tiene asociado uno o varios actores, los cuales a su vez son los encargados de la ejecucin de varias actividades, las cuales a la vez estn definidas en artefactos o guas para su realizacin.
Elementos que conforman el RUP
Actores o roles Son los personajes encargados de la realizacin de las actividades definidas dentro de los flujos de trabajo de cada una de las disciplinas del RUP, estos actores se dividen en varias categoras: Analistas, Desarrolladores, Probadores, Encargados, Otros actores. A continuacin se presenta una lista de actores de acorde a las categoras mencionadas con anterioridad: Analistas Analista del Proceso del Negocio Diseador del Negocio Revisor del Modelo del Negocio Revisor de Requerimientos Analista del Sistema Especificador de Casos de Uso Diseador de Interfaz del Usuario
Desarrolladores Arquitecto Revisor de la Arquitectura Diseador de Cpsulas 71
Revisor del Cdigo y Revisor del Diseo Diseador de la Base de Datos Diseador Implementador y un Integrador
Probadores Profesionales Diseador de Pruebas Probador
Encargados Otros Cualquier trabajador Artista Grfico Administrador del Sistema Escritor tcnico Especialista de Herramientas Encargado de Control del Cambio Encargado de la Configuracin Encargado del Despliegue Ingeniero de Procesos Encargado de Proyecto Revisor de Proyecto
Artefactos Los artefactos son el resultado parcial o final que es producido y usado por los actores durante el proyecto. Son las entradas y salidas de las actividades, realizadas por los actores, los cuales utilizan y van produciendo estos artefactos para tener guas. Un artefacto puede ser un documento, un modelo o un elemento de modelo. Conjuntos de artefactos Se tiene un conjunto de artefactos definidos en cada una de las disciplinas y utilizadas dentro de ellas por los actores para la realizacin de las mismas, a continuacin se definen cada una de estas categoras o grupos de artefactos dentro de las disciplinas del RUP: a) Modelado del negocio Los artefactos del modelado del negocio capturan y presentan el contexto del negocio del sistema. Los artefactos del modelado del negocio sirven como entrada y como referencia para los requisitos del sistema. b) Requerimientos Los artefactos de requerimientos del sistema capturan y presentan la informacin usada en definir las capacidades requeridas del sistema.
72
c) Anlisis y diseo del sistema Los artefactos para el anlisis y del diseo capturan y presenta la informacin relacionada con la solucin a los problemas se presentaron en los requisitos fijados. d) Implementacin Los artefactos para la implementacin capturan y presentan la realizacin de la solucin presentada en el anlisis y diseo del sistema. e) Pruebas Los artefactos desarrollados como productos de las actividades de prueba y de la evaluacin son agrupadas por el actor responsable, con el cual se lleva un conjunto de documentos de informacin sobre las pruebas realizadas y las metodologas de pruebas aplicadas. f) Despliegue Los artefactos del despliegue capturan y presentan la informacin relacionada con la transitividad del sistema, presentada en la implementacin en el ambiente de la produccin. g) Administracin del proyecto El conjunto de artefactos de la administracin del proyecto capturan los artefactos asociados con el proyecto, el planeamiento y a la ejecucin del proceso. h) Administracin de cambios y configuracin Los artefactos de la configuracin y administracin del cambio capturan y presentan la informacin relacionada con la disciplina de configuracin y administracin del cambio. i) Entorno o ambiente El conjunto de artefactos del ambiente presentan los artefactos que se utilizan como direccin a travs del desarrollo del sistema para asegurar la consistencia de todos los artefactos producidos.
4.3.3. METODOLOGA RAD (DESARROLLO RPIDO DE APLICACIONES)
James Martin cre el trmino Desarrollo Rpido de Aplicaciones apuntando hacia una metodologa y conjunto de herramientas especficos. Mientras tanto, hoy da se utiliza el trmino RAD para sealar una serie de tecnologas que utilizan esta metodologa y que intentan reducir el tiempo de desarrollo. Esta es una metodologa que permite a las organizaciones desarrollar sistemas estratgicamente importantes, de manera ms rpida reduciendo a la vez los costos de desarrollo y manteniendo la calidad. Esto se hace por medio de la
73
automatizacin de porciones grandes del ciclo de vida del desarrollo de sistemas, imponiendo lmites entre los plazos de desarrollo y volviendo a usar los componentes existentes y se logra mediante el uso de una serie de tcnicas de utilidad comprobada de desarrollo de aplicaciones, dentro de una metodologa bien definida. Algunas de estas tecnologas son: JAD (Joint Application Development): Pequeos grupos (hasta 10 personas) de usuarios y analistas hacen reuniones, para en un corto espacio de tiempo analizar y especificar entradas, procesos y salidas, a travs del desarrollo conjunto de un prototipo. Generadores de Aplicacin: estas herramientas posibilitan generar cdigo ejecutable a partir de definiciones generales o prototipos. Son utilizadas como parte de un proceso mayor de JAD o prototipacin. El mayor problema es la calidad (desempeo) del cdigo generado, principalmente en un ambiente multiusuario. Prototipacin rpida: el objetivo de esta tcnica es obtener en el menor tiempo posible el anlisis, diseo e implementacin de un sistema completo o parcial, a travs de la utilizacin de tcnicas y tecnologas complementarias (JAD, generadores de aplicacin, etc.).
Estas tcnicas incluyen el uso de: Equipos pequeos de desarrollo y bien capacitados. Prototipos evolutivos. Herramientas poderosas integradas que apoyan el modelo, el prototipo y la reutilizacin de componentes. Un depsito central de la informacin para tenerla a la mano en el momento que se le necesita. Requisitos interactivos y talleres de diseo. Lmites rgidos en los plazos de desarrollo.
Las herramientas grficas orientadas a objetos tienen, casi todas, interiorizadas el concepto general de RAD. Adems, con la creacin bien planificada de objetos, la programacin de nuevos mdulos se vuelve cada vez ms simplificada, reutilizando los objetos creados anteriormente. Uno de los conceptos de RAD ms interesantes, y que provee mejores resultados prcticos, es el de entrega incremental de productos. La idea es detectar durante el anlisis mdulos del sistema tributario que puedan ser desarrollados e implantados aisladamente, y trabajar en este sentido utilizando las tcnicas descritas anteriormente. Por ejemplo, en el subsistema de Registro de Contribuyentes, el mdulo de captura de datos del contribuyente puede ser rpidamente desarrollado e implantado por un pequeo equipo de personas, mientras se desarrollan otros mdulos: actualizacin, emisin de tarjetas, estadsticas, etc. Para el xito de un desarrollo tipo RAD el personal tcnico elegido debe poseer fuertes habilidades de relaciones interpersonales, aliadas a un dominio excelente de las herramientas utilizadas y tambin conocer el negocio. Adems, es esencial la disponibilidad y el fcil acceso a los usuarios para la realizacin de las muchas
74
reuniones requeridas. Con esto se puede decir que una de las limitantes de implementar el RAD es el costo elevado, debido a las exigencias que requiere para su implementacin, tanto de personal como de tecnologa. El RAD apoya el anlisis, el diseo, el desarrollo y la implementacin de los sistemas de aplicacin individual. Sin embargo, el RAD no apoya la planificacin o el anlisis necesario para definir las necesidades de informacin de la empresa en su totalidad o de un rea empresarial principal de la empresa.
4.3.3.1. Etapas de la metodologa RAD
La metodologa del RAD tiene cuatro etapas principales: 1. La etapa de Definicin Conceptual que define las funciones del negocio y las reas sujeto de datos que el sistema apoyar y determina el alcance del sistema. La etapa de Diseo Funcional que usa los talleres para modelar los datos y los procesos del sistema y para construir un prototipo de trabajo de los componentes crticos del sistema. La etapa de Desarrollo que completa la construccin fsica de la base de datos y del sistema de aplicacin, construye el sistema de conversin y elabora ayudas de usuarios y planes de trabajo a desarrollar o de despliegue. La etapa de Despliegue que incluye la puesta a prueba y la capacitacin del usuario final, la conversin de datos y la implementacin del sistema de aplicacin.
2.
3.
4.
4.3.3.2. Caractersticas de la metodologa RAD Modelo Central: Se pueden crear modelos o redefinir modelos existentes, y se pueden integrar estos modelos con la funcionalidad de aplicaciones existentes (componentes, paquetes, etc.). Desarrollo Visual: Proporciona un nivel alto de abstraccin, y da facilidad de crear nuevas aplicaciones y mantener las existentes. Cdigo Construido: Diseado para alto rendimiento, escalabilidad y ahorro de tiempo. Finalizacin de la Integracin del Desarrollo del Ciclo de Vida : Proporciona un desarrollo de artefactos y semntica del negocio capturados y organizados en modelos visuales. Universalmente aplicados durante el desarrollo del proyecto. Dar esfuerzo a la Orientacin a Objetos: Implica que el proceso de desarrollo est manejado por el modelo del negocio (clases). Extensible: La integracin que tiene abarca: XML, Servicios Web, Java / componentes EJB, DHTML. 4.3.3.3. Problemas en la metodologa RAD
Los problemas que se han encontrado a esta metodologa son: 1. 2. 3. Se requiere que el problema sea fcilmente modularizable. Se requiere de recursos humanos para cada equipo. Cada equipo debe estar altamente comprometido y con la capacidad de manejar las herramientas muy bien.
75
RAD no es recomendable cuando los riesgos tcnicos del proyecto son altos. Por ejemplo cuando se introducen nuevas herramientas, nueva tecnologa no probada, o cuando se requiere de complicadas interfaces con software ya existente. Hay voces en favor y en contra de la efectividad de la tcnica RAD. Algunas veces, el tiempo reducido de puesta en marcha de un sistema es obtenido al costo de baja calidad y/o difcil mantenimiento y/o un pobre desempeo.
76
4.4.
LENGUAJE UNIFICADO DE MODELADO (UML): DIAGRAMAS DE: CASOS DE USO, SECUENCIA, COLABORACIN, ACTIVIDADES, CLASES, OBJETOS, ESTADOS, COMPONENTES E INTEGRACIN
UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estndar de facto de la industria, debido a que ha sido concebido por los autores de los tres mtodos ms usados de orientacin a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron contratados por la empresa Rational Software Co. para crear una notacin unificada en la que basa la construccin de sus herramientas CASE. En el proceso de creacin de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, as como grupos de analistas y desarrolladores.
Esta notacin ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a que incorpora las principales ventajas de cada uno de los mtodos particulares en los que se basa: Booch, OMT y OOSE. UML ha puesto fin a las llamadas guerras de mtodos que se han mantenido a lo largo de los 90, en las que los principales mtodos sacaban nuevas versiones que incorporaban las tcnicas de los dems. Con UML se fusiona la notacin de estas tcnicas para formar una herramienta compartida entre todos los ingenieros software que trabajan en el desarrollo orientado a objetos.
El objetivo principal cuando se empez a gestar UML era posibilitar el intercambio de modelos entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello era necesario definir una notacin y semntica comn. En la siguiente figura se puede ver cul ha sido la evolucin de UML hasta la creacin de UML 1.1.
77
Hay que tener en cuenta que el estndar UML no define un proceso de desarrollo especfico, tan solo se trata de una notacin. NOTACIN BSICA UML 4.4.1. Modelos Un modelo representa a un sistema software desde una perspectiva especfica. Al igual que la planta y el alzado de una figura en dibujo tcnico nos muestran la misma figura vista desde distintos ngulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema. Los modelos de UML que se tratan en esta parte son los siguientes: Diagrama de Estructura Esttica. Diagrama de Casos de Uso. Diagrama de Secuencia. Diagrama de Colaboracin. Diagrama de Estados.
4.4.2. Elementos Comunes a Todos los Diagramas Notas Una nota sirve para aadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama. Es un modo de indicar informacin en un formato libre, cuando la notacin del diagrama en cuestin no nos permite expresar dicha informacin de manera adecuada. Una nota se representa como un rectngulo con una esquina doblada con texto en su interior. Puede aparecer en un diagrama tanto sola como unida a un elemento por medio de una lnea discontinua. Puede contener restricciones, comentarios, el cuerpo de un procedimiento, etc.
Dependencias La relacin de dependencia entre dos elementos de un diagrama significa que un cambio en el elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el elemento destino habra que revisar el elemento origen). Una dependencia se representa por medio de una lnea de trazo discontinuo entre los dos elementos con una flecha en su extremo. El elemento dependiente es el origen de la flecha y el elemento del que depende es el destino (junto a l est la flecha).
78
4.4.3. Diagramas de Estructura Esttica Con el nombre de Diagramas de Estructura Esttica se engloba tanto al Modelo Conceptual de la fase de Anlisis como al Diagrama de Clases de la fase de Diseo. Ambos son distintos conceptualmente, mientras el primero modela elementos del dominio, el segundo presenta los elementos de la solucin software. Sin embargo, ambos comparten la misma notacin para los elementos que los forman (clases y objetos) y las relaciones que existen entre los mismos (asociaciones). 4.4.3.1. Clases
Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra el nombre de la clase, en la media los atributos y en la inferior las operaciones. Una clase puede representarse de forma esquemtica (plegada), con los detalles como atributos y operaciones suprimidos, siendo entonces tan solo un rectngulo con el nombre de la clase. En la siguiente figura se ve cmo una misma clase puede representarse a distinto nivel de detalle segn interese, y segn la fase en la que se est.
4.4.3.2.
Objetos
Un objeto se representa de la misma forma que una clase. En el compartimento superior aparece el nombre del objeto junto con el nombre de la clase subrayado, segn la siguiente sintaxis:
79
nombre_del_objeto: nombre_de_la_clase Puede representarse un objeto sin un nombre especfico, entonces slo aparece el nombre de la clase.
4.4.3.3.
Asociaciones
Las asociaciones entre dos clases se representan mediante una lnea que las une. La lnea puede tener una serie de elementos grficos que expresan caractersticas particulares de la asociacin. A continuacin se vern los ms importantes de entre dichos elementos grficos. Nombre de la Asociacin y Direccin El nombre de la asociacin es opcional y se muestra como un texto que est prximo a la lnea. Se puede aadir un pequeo tringulo negro slido que indique la direccin en la cual leer el nombre de la asociacin. En el ejemplo de la siguiente figura se puede leer la asociacin como Director manda sobre Empleado.
Los nombres de las asociaciones normalmente se incluyen en los modelos para aumentar la legibilidad. Sin embargo, en ocasiones pueden hacer demasiado abundante la informacin que se presenta, con el consiguiente riesgo de saturacin. En ese caso se puede suprimir el nombre de las asociaciones consideradas como suficientemente conocidas. En las asociaciones de tipo agregacin y de herencia no se suele poner el nombre.
80
Multiplicidad
La multiplicidad es una restriccin que se pone a una asociacin, que limita el nmero de instancias de una clase que pueden tener esa asociacin con una instancia de la otra clase. Puede expresarse de las siguientes formas: Con un nmero fijo: 1. Con un intervalo de valores: 2..5. Con un rango en el cual uno de los extremos es un asterisco. Significa que es un intervalo abierto. Por ejemplo, 2..* significa 2 o ms. Con una combinacin de elementos como los anteriores separados por comas: 1, 3..5, 7, 15..*. Con un asterisco: * . En este caso indica que puede tomar cualquier valor (cero o ms).
Roles Para indicar el papel que juega una clase en una asociacin se puede especificar un nombre de rol. Se representa en el extremo de la asociacin junto a la clase que desempea dicho rol.
Agregacin El smbolo de agregacin es un diamante colocado en el extremo en el que est la clase que representa el todo.
81
Clases Asociacin Cuando una asociacin tiene propiedades propias se representa como una clase unida a la lnea de la asociacin por medio de una lnea a trazos. Tanto la lnea como el rectngulo de clase representan el mismo elemento conceptual: la asociacin. Por tanto ambos tienen el mismo nombre, el de la asociacin. Cuando la clase asociacin slo tiene atributos, el nombre suele ponerse sobre la lnea (como ocurre en el ejemplo de la siguiente figura). Por el contrario, cuando la clase asociacin tiene alguna operacin o asociacin propia, entonces se pone el nombre en la clase asociacin y se puede quitar de la lnea.
Asociaciones N-Arias En el caso de una asociacin en la que participan ms de dos clases, las clases se unen con una lnea a un diamante central. Si se muestra multiplicidad en un rol, representa el nmero potencial de tuplas de instancias en la asociacin cuando el resto de los N-1 valores estn fijos. En la figura siguiente se ha impuesto la restriccin de que un jugador no puede jugar en dos equipos distintos a lo largo de una temporada, porque la multiplicidad de Equipo es 1 en la asociacin ternaria.
82
Navegabilidad En un extremo de una asociacin se puede indicar la navegabilidad mediante una flecha. Significa que es posible "navegar" desde el objeto de la clase origen hasta el objeto de la clase destino. Se trata de un concepto de diseo, que indica que un objeto de la clase origen conoce al (los) objeto(s) de la clase destino, y por tanto puede llamar a alguna de sus operaciones. 4.4.3.4. Herencia
La relacin de herencia se representa mediante un tringulo en el extremo de la relacin que corresponde a la clase ms general o clase padre.
Si se tiene una relacin de herencia con varias clases subordinadas, pero en un diagrama concreto no se quieren poner todas, esto se representa mediante puntos suspensivos. En el ejemplo de la siguiente figura, slo aparecen en el diagrama 3 tipos de departamentos, pero con los puntos suspensivos se indica que en el modelo completo (el formado por todos los diagramas) la clase Departamento tiene subclases adicionales, como podran ser Recursos Humanos y Produccin. 4.4.3.5. Elementos Derivados
Un elemento derivado es aquel cuyo valor se puede calcular a partir de otros elementos presentes en el modelo, pero que se incluye en el modelo por motivos de claridad o como decisin de diseo. Se representa con una barra / precediendo al nombre del elemento derivado. 4.4.4. Diagrama de Casos de Uso Un Diagrama de Casos de Uso muestra la relacin entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interaccin externa.
83
4.4.4.1.
Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso. Actores Un actor es una entidad externa al sistema que realiza algn tipo de interaccin con el mismo. Se representa mediante una figura humana dibujada con palotes. Esta representacin sirve tanto para actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.). Casos de Uso Un caso de uso es una descripcin de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea especfica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea especfica que el actor desea llevar a cabo usando el sistema. Relaciones entre Casos de Uso Entre dos casos de uso puede haber las siguientes relaciones: Extiende: Cuando un caso de uso especializa a otro extendiendo su funcionalidad. Usa: Cuando un caso de uso utiliza a otro.
Se representan como una lnea que une a los dos casos de uso relacionados, con una flecha en forma de tringulo y con una etiqueta <<extiende>> o <<usa>> segn sea el tipo de relacin. Persona En el diagrama de casos de uso se representa tambin el sistema como una caja rectangular con el nombre en su interior. Los casos de uso estn en el interior de la caja del sistema, y los actores fuera, y cada actor est unido a los casos de uso en los que participa mediante una lnea. En la siguiente figura se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automtico.
84
4.4.5. Diagramas de Interaccin En los diagramas de interaccin se muestra un patrn de interaccin entre objetos. Hay dos tipos de diagrama de interaccin, ambos basados en la misma informacin, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de Colaboracin. 4.4.5.1. Diagrama de Secuencia
Un diagrama de secuencia muestra una interaccin ordenada segn la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interaccin y los mensajes que intercambian ordenados segn su secuencia en el tiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes en la interaccin, sin un orden prefijado. Cada objeto o actor tiene una lnea vertical, y los mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren.
85
4.4.5.2.
Diagrama de Colaboracin
Un Diagrama de Colaboracin muestra una interaccin organizada basndose en los objetos que toman parte en la interaccin y los enlaces entre los mismos (en cuanto a la interaccin se refiere). A diferencia de los Diagramas de Secuencia, los Diagramas de Colaboracin muestran las relaciones entre los roles de los objetos. La secuencia de los mensajes y los flujos de ejecucin concurrentes deben determinarse explcitamente mediante nmeros de secuencia.
En cuanto a la representacin, un Diagrama de Colaboracin muestra a una serie de objetos con los enlaces entre los mismos, y con los mensajes que se intercambian dichos objetos. Los mensajes son flechas que van junto al enlace por el que circulan, y con el nombre del mensaje y los parmetros (si los tiene) entre parntesis. Cada mensaje lleva un nmero de secuencia que denota cul es el mensaje que le precede, excepto el mensaje que inicia el diagrama, que no lleva nmero de secuencia. Se pueden indicar alternativas con condiciones entre corchetes (por ejemplo 3 [condicin_de_test] : nombre_de_mtodo() ), tal y como aparece en el ejemplo de la figura anterior. Tambin se puede mostrar el anidamiento de mensajes con nmeros de secuencia como 2.1, que significa que el mensaje con nmero de secuencia 2 no acaba de ejecutarse hasta que no se han ejecutado todos los 2. x . 4.4.6. Diagrama de Estados Un diagrama de estados muestra la secuencia de estados por los que pasa un caso de uso o un objeto a lo largo de su vida, indicando qu eventos hacen que se pase de un estado a otro y cules son las respuestas y acciones que genera. En cuanto a la representacin, un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos.
86
Un estado se representa como una caja redondeada con el nombre del estado en su interior. Una transicin se representa como una flecha desde el estado origen al estado destino. La caja de un estado puede tener 1 2 compartimentos. En el primer compartimento aparece el nombre del estado. El segundo compartimento es opcional, y en l pueden aparecer acciones de entrada, de salida y acciones internas. Una accin de entrada aparece en la forma entrada/accin_asociada donde accin_asociada es el nombre de la accin que se realiza al entrar en ese estado. Cada vez que se entra al estado por medio de una transicin la accin de entrada se ejecuta. Una accin de salida aparece en la forma salida/accin_asociada. Cada vez que se sale del estado por una transicin de salida la accin de salida se ejecuta. Una accin interna es una accin que se ejecuta cuando se recibe un determinado evento en ese estado, pero que no causa una transicin a otro estado. Se indica en la forma nombre_de_evento/accin_asociada.
Un diagrama de estados puede representar ciclos continuos o bien una vida finita, en la que hay un estado inicial de creacin y un estado final de destruccin (del caso de uso o del objeto). El estado inicial se muestra como un crculo slido y el estado final como un crculo slido rodeado de otro crculo. En realidad, los estados inicial y final son pseudoestados, pues un objeto no puede estar en esos estados, pero nos sirven para saber cules son las transiciones inicial y final(es).
NOTACIN AVANZADA UML 4.4.7. Modelado Dinmico 4.4.7.1. Diagramas de Actividades Vamos a recordar los diferentes modelos que sirven para representar el aspecto dinmico de un sistema: Diagramas de secuencia. Diagramas de colaboracin. Diagramas de estados. 87
Diagramas de casos de uso Diagramas de actividades
En este captulo nos centraremos en los diagramas de actividades que sirven fundamentalmente para modelar el flujo de control entre actividades. La idea es generar una especie de diagrama Pert, en el que se puede ver el flujo de actividades que tienen lugar a lo largo del tiempo, as como las tareas concurrentes que pueden realizarse a la vez. El diagrama de actividades sirve para representar el sistema desde otra perspectiva, y de este modo complementa a los anteriores diagramas vistos. Grficamente un diagrama de actividades ser un conjunto de arcos y nodos. Desde un punto de vista conceptual, el diagrama de actividades muestra cmo fluye el control de unas clases a otras con la finalidad de culminar con un flujo de control total que se corresponde con la consecucin de un proceso ms complejo. Por este motivo, en un diagrama de actividades aparecern acciones y actividades correspondientes a distintas clases. Colaborando todas ellas para conseguir un mismo fin. Ejemplo: Hacer un pedido. 4.4.7.2. Contenido del diagrama de actividades
Bsicamente un diagrama de actividades contiene: Estados de actividad. Estados de accin. Transiciones. Objetos.
Estados de actividad y estados de accin La representacin de ambos es un rectngulo con las puntas redondeadas, en cuyo interior se representa bien una actividad o bien una accin. La forma de expresar tanto una actividad como una accin, no queda impuesta por UML, se podra utilizar lenguaje natural, una especificacin formal de expresiones, un metalenguaje, etc. La idea central es la siguiente: Un estado que represente una accin es atmico, lo que significa que su ejecucin se puede considerar instantnea y no puede ser interrumpida En la siguiente figura, podemos ver ejemplos de estados de accin.
88
En cambio un estado de actividad, s puede descomponerse en ms sub-actividades representadas a travs de otros diagramas de actividades. Adems estos estados s pueden ser interrumpidos y tardan un cierto tiempo en completarse. En los estados de actividad podemos encontrar otros elementos adicionales como son: acciones de entrada (entry) y de salida (exit) del estado en cuestin, as como definicin de submquinas, como podemos ver en la siguiente figura.
Transiciones Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de accin. Esta transicin se produce como resultado de la finalizacin del estado del que parte el arco dirigido que marca la transicin. Como todo flujo de control debe empezar y terminar en algn momento, podemos indicar esto utilizando dos disparadores de inicio y fin tal y como queda reflejado en el ejemplo de la siguiente figura.
Bifurcaciones Un flujo de control no tiene porqu ser siempre secuencial, puede presentar caminos alternativos. Para poder representar dichos caminos alternativos o bifurcacin se utilizar como smbolo el rombo. Dicha bifurcacin tendr una transicin de entrada y dos o ms de salida. En cada transicin de salida se colocar una expresin booleana que ser evaluada una vez al llegar a la bifurcacin, las guardas de la bifurcacin han de ser excluyentes y contemplar todos los casos ya que de otro modo la ejecucin del flujo de control quedara interrumpida. Para poder cubrir todas las posibilidades se puede utilizar la palabra ELSE, para indicar una transicin obligada a un determinado estado cuando el resto de guardas han fallado. En la siguiente figura podemos ver un ejemplo de bifurcacin.
89
Divisin y unin No slo existe el flujo secuencial y la bifurcacin, tambin hay algunos casos en los que se requieren tareas concurrentes. UML representa grficamente el proceso de divisin, que representa la concurrencia, y el momento de la unin de nuevo al flujo de control secuencial, por una lnea horizontal ancha. En la Figura 23 podemos ver cmo se representa grficamente.
Calles Cuando se modelan flujos de trabajo de organizaciones, es especialmente til dividir los estados de actividades en grupos, cada grupo tiene un nombre concreto y se denominan calles. Cada calle representa a la parte de la organizacin responsable de las actividades que aparecen en esa calle. Grficamente quedara como se muestra en la siguiente figura.
90
4.4.7.3. Modelado Fsico de un Sistema OO 4.4.7.3.1. Componentes Los componentes pertenecen al mundo fsico, es decir, representan un bloque de construccin al modelar aspectos fsicos de un sistema. Una caracterstica bsica de un componente es que: debe definir una abstraccin precisa con una interfaz bien definida, y permitiendo reemplazar fcilmente los componentes ms viejos con otros ms nuevos y compatibles. En UML todos los elementos fsicos se modelan como componentes. UML proporciona una representacin grfica para stos como se puede ver en la siguiente figura, en la que XXXX.dll, es el nombre del componente.
Cada componente debe tener un nombre que lo distinga de los dems. Al igual que las clases los componentes pueden enriquecerse con compartimentos adicionales que muestran sus detalles, como se puede ver en la siguiente figura.
91
Vamos a ver con ms detalle cules son los parecidos y las diferencias entre los componentes y las clases.
Interfaces Tanto los servicios propios de una clase como los de un componente, se especifican a travs de una Interfaz. Por ejemplo, todas las facilidades ms conocidas de los sistemas operativos, basados en componentes (COM+, CORBA, etc.), utilizan las interfaces como lazo de unin entre unos componentes y otros. La relacin entre un componente y sus interfaces se puede representar de dos maneras diferentes, de forma icnica como se indica en la Figura 27, y de forma expandida como se muestra en la siguiente figura.
92
Tipos de componentes Existen bsicamente tres tipos de componentes: Componentes de despliegue: componentes necesarios y suficientes para formar un sistema ejecutable, como pueden ser las bibliotecas dinmicas (DLLs) y ejecutables (EXEs). Componentes producto del trabajo: estos componentes son bsicamente productos que quedan al final del proceso de desarrollo. Consisten en cosas como archivos de cdigo fuente y de datos a partir de los cuales se crean los componentes de despliegue. Componentes de ejecucin: son componentes que se crean como consecuencia de un sistema en ejecucin. Es el caso de un objeto COM+ que se instancia a partir de una DLL.
Organizacin de componentes Los componentes se pueden agrupar en paquetes de la misma forma que se organizan las clases. Adems se pueden especificar entre ellos relaciones de dependencia, generalizacin, asociacin (incluyendo agregacin), y realizacin. Estereotipos de componentes UML define cinco estereotipos estndar que se aplican a los componentes:
UML no especifica conos predefinidos para estos estereotipos. 4.4.7.3.2. Despliegue Nodos Al igual que los componentes, los nodos pertenecen al mundo material. Vamos a definir un nodo como un elemento fsico, que existe en tiempo de ejecucin y
93
representa un recurso computacional que generalmente tiene alguna memoria y, a menudo, capacidad de procesamiento. Los nodos sirven para modelar la topologa del hardware sobre el que se ejecuta el sistema. Un nodo representa normalmente un procesador o un dispositivo sobre el que se pueden desplegar los componentes. Un nodo debe tener un nombre asignado que lo distinga del resto de nodos. Adems los nodos se representan grficamente como se indica en la siguiente figura.
Nodos y componentes En muchos aspectos los nodos y los componentes tienen caractersticas parecidas. Vamos a ver con ms detalle cules son los parecidos y las diferencias entre los componentes y los nodos.
La relacin entre un nodo y los componentes que despliega se pueden representar mediante una relacin de dependencia como se indica en la figura. Los nodos se pueden agrupar en paquetes igual que las clases y los componentes. Los tipos de relacin ms comn entre nodos es la asociacin. Una asociacin entre nodos viene a representar una conexin fsica entre nodos como se puede ver en la siguiente figura.
94
Existen dos tipos de diagramas que sirven para modelar los aspectos fsicos de un sistema orientado a objetos: Diagramas de Componentes Diagramas de Despliegue Seguidamente veremos para qu sirve cada uno de ellos y cul es su representacin grfica.
4.4.7.3.3. Diagramas de Componentes Un diagrama de componentes muestra la organizacin y las dependencias entre un conjunto de componentes. Para todo sistema OO se han de construir una serie de diagramas que modelan tanto la parte esttica (diagrama de clases), como dinmica (diagramas de secuencia, colaboracin, estados y de actividades), pero llegado el momento todo esto se debe materializar en un sistema implementado que utilizar partes ya implementadas de otros sistemas, todo esto es lo que pretendemos modelar con los diagramas de componentes. Algunos conceptos Un diagrama de componentes muestra un conjunto de componentes y sus relaciones de manera grfica a travs del uso de nodos y arcos entr estos. Normalmente los diagramas de componentes contienen: Componentes. Interfaces. Relaciones de dependencia, generalizacin, asociaciones y realizacin. Paquetes o subsistemas. 95
Instancias de algunas clases.
Visto de otro modo un diagrama de componentes puede ser un tipo especial de diagrama de clases que se centra en los componentes fsicos del sistema. Usos ms comunes a) Modelado de Cdigo Fuente Los diagramas de componentes se pueden utilizar para modelar la gestin de la configuracin de los archivos de cdigo fuente, tomando como productos de trabajo precisamente estos ficheros. Esto resulta bastante til, por ejemplo cuando se han implementado unas partes con Java otras con C, etc. El resultado de esta implementacin puede ser multitud de ficheros ejecutables con caractersticas particulares, de manera que la mejor forma de controlarlos es estableciendo gestin de configuracin. Para poder llevar a cabo esta gestin con xito ser necesario definir los estereotipos de ficheros que se quieren tener bajo control as como las relaciones entre dichos tipos de ficheros. Para modelar el cdigo fuente de un sistema: Hay que identificar el conjunto de archivos de cdigo fuente de inters y modelarlos como componentes estereotipados como archivos. Si el sistema es muy grande es necesario utilizar los paquetes para agrupar los archivos de cdigo fuente. Es necesario identificar la versin del componente.
b) Modelado de una versin ejecutable y bibliotecas. La utilizacin de los componentes para modelar versiones ejecutables se centra en la definicin de todos los elementos que componen lo que se conoce como versin ejecutable, es decir la documentacin, los ficheros que se entregan etc. Para modelar una versin ejecutable es preciso: Identificar el conjunto de componentes que se pretende modelar. Identificar el estereotipo de cada componente del conjunto seleccionado. Para cada componente de este conjunto hay que considerar las relaciones con los vecinos. Esto implica definir las interfaces importadas por ciertos componentes y las exportadas por otros.
c) Modelado de una base de datos fsica Para modelar una base de datos fsica es necesario: Identificar las clases del modelo que representan el esquema lgico de la base de datos. Seleccionar una estrategia para hacer corresponder las clases con tablas. As como la distribucin fsica de la/s base/s de datos.
96
Para poder visualizar, especificar, construir y documentar dicha correspondencia, es necesario crear un diagrama de componentes que tenga componentes estereotipados como tablas. Donde sea posible es aconsejable utilizar herramientas que ayuden a transformar diseo lgico en fsico.
4.4.7.3.4. Diagramas de Despliegue Tcnicas ms comunes de modelado a) Modelado de un sistema empotrado El desarrollo de un sistema empotrado es ms que el desarrollo de un sistema software. Hay que manejar el mundo fsico. Los diagramas de despliegue son tiles para facilitar la comunicacin entre los ingenieros de hardware y los de software. Para modelar un sistema empotrado es necesario: Identificar los dispositivos y nodos propios del sistema. Proporcionar seales visuales, sobre todo para los dispositivos poco usuales. Modelar las relaciones entre esos procesadores y dispositivos en un diagrama de despliegue. Si es necesario hay que detallar cualquier dispositivo inteligente, modelando su estructura en un diagrama de despliegue ms pormenorizado.
b) Modelado de un sistema cliente servidor La divisin entre cliente y servidor en un sistema es complicada, ya que implica tomar algunas decisiones sobre dnde colocar fsicamente sus componentes software, qu cantidad de software debe residir en el cliente, etc. Para modelar un sistema cliente/servidor hay que hacer lo siguiente: Identificar los nodos que representan los procesadores cliente y servidor del sistema. Destacar los dispositivos relacionados con el comportamiento del sistema. Proporcionar seales visuales para esos procesadores y dispositivos a travs de estereotipos. Modelar la tipologa de esos nodos mediante un diagrama de despliegue.
4.4.7.3.5. Arquitectura del Sistema Arquitectura de tres niveles La llamada Arquitectura en Tres Niveles, es la ms comn en sistemas de informacin que adems de tener una interfaz de usuario contemplan la persistencia de los datos. Una descripcin de los tres niveles sera la siguiente: Nivel 1: Presentacin ventanas, informes, etc. Nivel 2: Lgica de la Aplicacin tareas y reglas que gobiernan el proceso.
97
Nivel 3: Almacenamiento mecanismo de almacenamiento. Arquitectura de tres niveles orientada a objetos a) Descomposicin del nivel de lgica de la aplicacin En el diseo orientado a objetos, el nivel de lgica de la aplicacin se descompone en subniveles que son los siguientes: Objetos del Dominio: son clases que representan objetos del dominio. Por ejemplo en un problema de ventas, una Venta sera un objeto del dominio. Servicios: se hace referencia a funciones de interaccin con la base de datos, informes, comunicaciones, seguridad, etc. Arquitectura MULTI-nivel La arquitectura de tres niveles puede pasar a llamarse de Mltiples Niveles si tenemos en cuenta el hecho de que todos los niveles de la arquitectura de tres niveles se pueden descomponer cada uno de ellos cada vez ms. Por ejemplo el nivel de servicios, se puede descomponer en servicios de alto y de bajo nivel, identificando como de alto nivel los servicios de generacin de informes y como de bajo nivel los de manejo de ficheros de entrada y salida. El motivo que lleva a descomponer la arquitectura del sistema en diferentes niveles es mltiple: Separacin de la lgica de la aplicacin en componentes separados que sean ms fcilmente reutilizables. Distribucin de niveles en diferentes nodos fsicos de computacin. Reparto de recursos humanos en diferentes niveles de la arquitectura.
Paquetes La forma que tiene UML de agrupar elementos en subsistemas es a travs del uso de Paquetes, pudindose anidar los paquetes formando jerarquas de paquetes. De hecho un sistema que no tenga necesidad de ser descompuesto en subsistemas se puede considerar como con un nico paquete que lo abarca todo. Grficamente un paquete viene representado como se indica en la figura.
En la siguiente figura, vemos cmo se representa la arquitectura del sistema con la notacin de paquetes.
98
Identificacin de Paquetes Vamos a definir una serie de reglas que nos pueden ser de utilidad a la hora de agrupar los diferentes elementos en paquetes. Conviene agrupar elementos que proporcionen un mismo servicio. Los elementos que se agrupen en un mismo paquete han de presentar un alto grado de cohesin, es decir deben estar muy relacionados. Los elementos que estn en diferentes paquetes deben tener poca relacin, es decir deben colaborar lo menos posible.
99

Modulo Ingenieria Del Software II 4.0

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Modulo Ingenieria Del Software II 4.0

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSIDAD TECNOLGICA SAN ANTONIO DE MACHALA

MODALIDAD DE EDUCACIN SEMIPRESENCIAL Y A DISTANCIA

ESCUELA DE INFORMTICA INGENIERA EN SISTEMAS

ING. LEWIS CHIMARRO CHIPANTIZA

[INGENIERIA DEL SOFTWARE II]

UTSAM-Modalidad Semipresencial y a Distancia

[INGENIERIA DEL SOFTWARE II]

Unidad Didctica I EL PROCESO DE LA INGENIERA DEL SOFTWARE Y SU GESTION

UTSAM-Modalidad Semipresencial y a Distancia

[INGENIERIA DEL SOFTWARE II]

CONSEJO SUPERIOR RECTOR

CONSEJO ACADMICO VICERRECTOR

COMISIN DE EVALUACIN INTERNA

COMISIN DE VINCULACIN CON LA COLECTIVIDAD

CENTRO DE ASESORIA JURDICA

mbito del sistema

UNIDAD ACADMICA DE PREGRADO MODALIDAD PRESENCIAL

UNIDAD ACADMICA DE PREG MOD. A DIST. Y SEMIPRESE DIRECTOR GENERAL

UTSAM-Modalidad Semipresencial y a Distancia

[INGENIERIA DEL SOFTWARE II]

UTSAM-Modalidad Semipresencial y a Distancia

[INGENIERIA DEL SOFTWARE II]

GESTIN DEL PROYECTO DE SOFTWARE

1.3.1. Planificacin 1.3.1.1. Plan general del proyecto de software

UTSAM-Modalidad Semipresencial y a Distancia

[INGENIERIA DEL SOFTWARE II]

UTSAM-Modalidad Semipresencial y a Distancia

[INGENIERIA DEL SOFTWARE II]

[INGENIERIA DEL SOFTWARE II]

UTSAM-Modalidad Semipresencial y a Distancia

[INGENIERIA DEL SOFTWARE II]

Mdulos Integrados UNIT

UTSAM-Modalidad Semipresencial y a Distancia

Especificaciones del diseo

Especificaciones requerimientos para el cliente

Requerimientos funcionales del sistema

Otros requerimientos del software

[INGENIERIA DEL SOFTWARE II]

Mdulo, componente o unitaria

UTSAM-Modalidad Semipresencial y a Distancia

[INGENIERIA DEL SOFTWARE II]

Conjunto de casos de prueba

for (i=0; i<=10;i++) { echo Contador = .i; }

UTSAM-Modalidad Semipresencial y a Distancia

[INGENIERIA DEL SOFTWARE II]

UTSAM-Modalidad Semipresencial y a Distancia

[INGENIERIA DEL SOFTWARE II]

Conceptos Configuracin del Software:

UTSAM-Modalidad Semipresencial y a Distancia

[INGENIERIA DEL SOFTWARE II]

[INGENIERIA DEL SOFTWARE II]

[INGENIERIA DEL SOFTWARE II]

Personal poco entrenado. Documentacin inadecuada. La plataforma ha venido a ser obsoleta

Estimacin del software con COCOMO

UTSAM-Modalidad Semipresencial y a Distancia

[INGENIERIA DEL SOFTWARE II]

[INGENIERIA DEL SOFTWARE II]

UTSAM-Modalidad Semipresencial y a Distancia

[INGENIERIA DEL SOFTWARE II]

ANLISIS Y DISEO ESTRUCTURADO DEL SOFTWARE

2. ANALISIS Y DISEO ESTRUCTURADO DEL SOFTWARE

UTSAM-Modalidad Semipresencial y a Distancia

[INGENIERIA DEL SOFTWARE II]

UTSAM-Modalidad Semipresencial y a Distancia