TECNOLOGICO DE ESTUDIOS SUPERIORES DE CHALCO

Desarrollo de Proyectos de Software

Prof.: Lic. Liliana Lozada

Tema: Antologa

Daniel G. Moreno Becerril Israel David Escobar Contreras

8296AV

INDICEIntroduccin. Unidad 1Conceptos Introductorios.1.1 La arquitectura de 4+1 vistas 1.2 Desarrollo orientado a objetos. 1.3 Diagramacin

Unidad 2 Diseo orientado a objetos.2.1 Diseo del sistema en base aprocesos... 2.1.1 Actividades y casos de uso.. 2.1.2 Interfaces de usuario.. 2.2 Diseo de la lgica.. 2.2.1 Clases y Objetos... 2.2.2 Interaccin.. 2.2.3 Estados y Transiciones..

Unidad 3 Construccin.3.1 Despliegue de componentes y arquitectnico 3.2 Tcnicas de desarrollo de las arquitecturas de referencia en diferentes dominios 3.2.1 Los modelos de componentes.. 3.2.2 Arquitectura de referencia para sistemas de tiempo real fuente de alimentacin. 3.2.3 Arquitectura de referencia para sistemas mviles con conexin a Internet. 3.2.4 Arquitectura de referencia para sistemas de informacin 3.2.5 Arquitectura de referencia para ambientes virtuales de aprendizaje. 3.2.6 Arquitecturas de referencia para lneas de productos..

2

Unidad 4 Pruebas de software.4.1 Definiciones. 4.1.1 Prueba, caso de prueba, defecto, falla, error, verificacin, validacin. 4.1.2 Relacin entre defecto-fallaerror 4.1.3 Pruebas estructurales, funcionales y aleatorias 4.1.4 Documentacin del diseo delas pruebas. 4.2 Proceso de pruebas.. 4.2.1 Generar un plan de pruebas 4.2.2 Disear pruebas especficas.. 4.2.3 Tomar configuracin del software a probar 4.2.4 Configurar las pruebas. 4.2.5 Evaluar resultados. 4.2.5.1 Depuracin 4.2.5.2 Anlisis de errores.. 4.3 Tcnicas de diseo de casos de pruebas 4.4 Enfoque prctico recomendado para el diseo de casos 4.5 Estrategias de aplicacin de las pruebas. 4.5.1 De unidad 4.5.2 De integracin 4.5.3 Del sistema. 4.5.4 De aceptacin

Unidad 5 Implantacin y mantenimiento.5.1 Implantacin e Integracin de casos de uso y componentes de software. 5.2 Mantenimiento del software.

3

Introduccin

La presente antologa de la materia de desarrollo de proyectos de software es una recopilacin de informacin y ejemplos acordes a los temas que fueron vistos en clase, se pretende que esta antologa sea un material de apoyo para alumnos que cursen dicha asignatura. As como un material didctico para profesores pues en este trabajo tambin se incluyen ejemplos de casos de uso que pueden ser implementados en dinmicas en clase. Es importante sealas que este trabajo fue recabado de distintos libros, y pginas web las cuales se anexan al final para su consulta directa. El contenido a sido revisado con el fin de entregar material de calidad y fiable para su consulta.

4

UNIDAD ICONCEPTOS INTRODUCTORIOS Laarquitectura de software l diseo e implementacin de la estructura de alto nivel del software. Eselresultadodeensamblarunciertonmerodeelementosarquitectnicosparasatisfacerlafun cionalidadyejecucindelosrequisitosdelsistema: Arquitectura software = {elementos, formas, fundamentos/restricciones} Una vista es una presentacin de un modelo, la cual es una descripcin completa de un sistema desde una particular perspectiva. El modelo ms aceptado a la hora de establecer las vistas necesarias para describir una arquitectura de software es el modelo 4+1 vistas. 1. Vista Lgica (logicalview), modelo de objetos, clases, entidad relacin, etc. 2. Vista de Proceso (processview), modelo de concurrencia y sincronizacin. 3. Vista de Desarrollo (developmentview), organizacin esttica del software en su entorno de desarrollo (libreras, componentes, .ear, .jar, etc.). 4. Vista Fsica (physicalview), modelo de correspondenciasoftware hardware. Y una vista ms, la "+1", que se muestra y traza en cada una de las anteriores y que est formada por las necesidades funcionales que cubre el sistema, y que en ocasiones identificamos como vista de "casos de uso". De donde deducimos que segn este modelo, la arquitectura es en realidad evolucionada desde escenarios. 1.1La arquitectura de 4+1 vistas. 1. Arquitectura Lgica (LogicalArchitecture) Soporta el anlisis y la especificacin de los requisitos funcionales: lo que el sistema debera proporcionar en trminos de servicios a sus usuarios. El sistema se descompone en un conjunto de abstracciones clave tomadas mayormente del dominio del problema, en forma de objetos o clases. En esta vista se usan comnmente los diagramas de clases, los de interaccin y objetos. Notacin: La notacin ms usada es UML, y dentro de esta diagramas de clases y paquetes. Estilo: El estilo ms usado para la vista lgica es el Orientado a Objetos. 2. Arquitectura de Procesos (ProcessArchitecture)

5

Se tratan algunos requisitos no funcionales. Ejecucin, disponibilidad, tolerancia a fallos, integridad, etc. Esta vista tambin especifica que hilo de control ejecuta cada operacin identificada en cada clase identificada en la vista lgica. La vista se centra por tanto en la concurrencia y distribucin de procesos. Notacin: La notacin ms usada es UML, y dentro de esta diagramas estados, actividad y similares. Estilo: pueden encajar varios estilos. Por ejemplo, tomando la taxonoma de Garlan y Shaw (1993), pueden usarse tuberas y filtros (pipes and filtres) o Cliente Servidor (con variantes de mltiples clientes simple servidor y mltiples clientes mltiples servidores). Para sistemas ms complejos puede usarse un estilo similar a la ISIS system'sprocessgroups, como describe Kenneth Birman (1994). 3. Arquitectura de Desarrollo (DevelopmentArchitecture) La vista de desarrollo o despliegue se enfoca en la organizacin de los mdulos software en el entorno de desarrollo. El software es empaquetado en pequeos trozos (libreras de programa, subsistemas, componentes, etc.), los subsistemas se organizan en capas jerrquicas, y cada capa proporciona una interfaz bien definida a sus capas superiores La vista de desarrollo toma por tanto requisitos internos relacionados con facilidad de desarrollo, gestin del software (reparto de requisitos, trabajo del equipo), evaluacin de costes, planificacin, monitorizacin del progreso del proyecto, reutilizacin, portabilidad, seguridad y restricciones impuestas por las herramientas o por el lenguaje de programacin Esta organizacin del software se suele apoyar en diagramas de mdulos o de subsistemas que muestran las relaciones de exportacin (export) e importacin (import). Y destacar que podr describirse la vista de desarrollo por completo solamente despus de haber identificado todos los elementos software. Notacin: La notacin ms usada es UML, y dentro de esta diagramas de componentes y paquetes. Estilo: se recomienda definir de cuatro a seis capas de subsistemas en la vista de desarrollo. Una regla de diseo es que un subsistema puede solamente depender de subsistemas en la misma capa o en las menores. Esto minimiza las dependencias entre mdulos a favor de una ms simple estrategia capa capa. 4. Arquitectura Fsica (PhysicalArchitecture) La vista fsica se centra en los requisitos no funcionales, tales como la disponibilidad del sistema, la fiabilidad (tolerancia a fallos), ejecucin y escalabilidad. Y tambin presenta cmo los procesos, objetos, etc., corresponden a nodos de proceso: Componentes: nodos de proceso.

6

Conectores: LAN, WAN, bus, etc. Contenedores: subsistemas fsico Varias configuraciones fsicas pueden usarse. La correspondencia del software a los nodos debe ser altamente flexible y tener el mnimo impacto en el cdigo fuente. 5. Escenarios (Scenarios) La vista de escenarios corresponde con instancias de casos de uso que unifican todas las vistas. As, desde casos de uso se debiera poder hacer una trazabilidad a todos los componentes del sis tema software, viendo, por ejemplo, que mquinas, o clases, o componentes, o .jar, o procesos, son los responsables de que el sistema cubra una cierta funcionalidad. Relacin entre las vistas Como sucede en otras muchas ocasiones, si bien el modelo no es una metodologa si que "sugiere" un mtodo de trabajo. Parece lgico que la vista de escenarios o casos de uso sea la de arranque, y que de ah se pase a la vista lgica. Desde la vista lgica afrontaremos la de desarrollo y procesos, una vez que tenemos por ejemplo las clases definiremos maneras de agruparlas y modos de ejecucin. Para con todo concluir en la vista fsica. Todo ello, obviamente, con sus correspondientes y tpicas iteraciones. Arquitectura y UML Se ha ido exponiendo a lo largo de la explicacin de cada una de las vistas su translacin a un lenguaje de modelado concreto como UML. Hya que tener en cuenta que UML nace casi a la vez que el modelo 4+1, por lo que en un origen no exista una clara relacin entre ambos, lo que amenudo produce confusin al diseador que en la actualidad quiere modelar una arquitectura con ambas herramientas. A modo de resumen la translacin se presenta en la siguiente tabla:

Vista Escenarios Lgica Desarrollo Fsica Procesos

UML Casos de Uso Clases, de Estados y Colaboracin Componentes Despliegue Actividad, Estados, Secuencia

7

1.2 Desarrollo orientado a objetos. Diseo orientado a objetos es una fase de la metodologa orientada a objetos para el desarrollo de Software. Su uso induce a los programadores a pensar en trminos de objetos, en vez de procedimientos, cuando planifican su cdigo. Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La 'interfaz del objeto', esto es, las formas de interactuar con el objeto, tambin es definida en esta etapa. Un programa orientado a objetos es descrito por la interaccin de esos objetos. El diseo orientado a objetos es la disciplina que define los objetos y sus interacciones para resolver un problema de negocio que fue identificado y documentado durante el anlisis orientado a objetos.

1.3 Diagramacin. Introduccin El primer paso en el diseo de objetos o procesos es la representacin mediante diagramas de su estructura, funcionamiento y comportamiento, concretando as las primeras ideas abstractas. En el caso de productos interactivos con interfaz, como por ejemplo los sitios web, esta interfaz tambin es objeto de diagramacin, especificando cul ser la organizacin y estructuracin visual de los diferentes elementos. Los diagramas se deben realizar a partir de la informacin recogida durante las etapas de investigacin de la audiencia, en las que se estudia a los usuarios con el objetivo de crear un producto que satisfaga sus necesidades. En qu consiste la diagramacin

8

La diagramacin, a la cual nos referimos, consiste en la representacin de los contenidos que tendr un producto digital, y las relaciones entre dichos contenidos. Desde sus orgenes los seres humanos representaron escenas de caza, danzas rituales y otros aspectos de su vida. La representacin forma parte de la naturaleza cognitiva humana, y es lgico que el hombre, en su devenir histrico, haya usado esta capacidad para plasmar en algn soporte, ideas concebidas mentalmente. La representacin se ha usado desde los comienzos del diseo de software, en forma de organigramas, diagramas de flujo de datos, rboles de decisin, etc. Al evolucionar las interfaces grficas de usuario, las labores de representacin se ampliaron con los llamados guiones de navegacin y guiones de interaccin, los cuales consistan en diagramas que representaban el funcionamiento de los productos electrnicos que se generaban en ese momento.

UNIDAD 2DISEO ORIENTADA A OBJETO

Introduccin Cuando se va a construir un sistema software es necesario conocer un lenguaje de programacin, pero con eso no basta. Si se quiere que el sistema sea robusto y mantenible es necesario que el problema sea analizado y la solucin sea cuidadosamente diseada. Se debe seguir un proceso robusto, que incluya las actividades principales. Si se sigue un proceso de desarrollo que se ocupa de plantear cmo se realiza el anlisis y el diseo, y cmo se relacionan los productos de ambos, entonces la construccin de sistemas software va a poder ser planificable y repetible, y la probabilidad de obtener un sistema de mejor calidad al final del proceso aumenta considerablemente, especialmente cuando se trata de un equipo de desarrollo formado por varias personas. Para este curso se va a seguir el mtodo de desarrollo orientado a objetos que propone Craig Larman [Larman99]. Este proceso no fija una metodologa estricta, sino que define una serie de actividades que pueden realizarse en cada fase, las cuales deben adaptarse segn las condiciones del proyecto que se est llevando a cabo. Se ha escogido seguir este proceso debido a que aplica los ltimos avances en Ingeniera del Software, y a que adopta un enfoque eminentemente prctico, aportando soluciones a las principales dudas y/o problemas con los que se enfrenta el desarrollador. Su mayor aportacin consiste en atar los cabos sueltos que anteriores mtodos dejan. Se va a abarcar todo el ciclo de vida, empezando por los requisitos y acabando en el sistema funcionando, proporcionando as una visin completa y coherente de la produccin de sistemas software. El enfoque que toma es el de un ciclo de vida iterativo

9

incremental, el cual permite una gran flexibilidad a la hora de adaptarlo a un proyecto y a un equipo de desarrollo especficos. El ciclo de vida est dirigido por casos de uso, es decir, por la funcionalidad que ofrece el sistema a los futuros usuarios del mismo. 2.1 Diseo del sistema en base a procesos. Diseo del Sistema El diseo del sistema es la estrategia de alto nivel para resolver problemas y construir una solucin. ste incluye decisiones acerca de la organizacin del sistema en subsistemas, la asignacin de subsistemas a componentes hardware y software, y decisiones fundamentales conceptuales y de poltica que son las que constituyen un marco de trabajo para el diseo detallado La organizacin global del sistema es lo que se denomina la arquitectura del sistema. Existe un cierto nmero de estilos frecuentes de arquitectura, cada uno de los cuales es adecuado para ciertas clases de aplicaciones. Una forma de caracterizar una aplicacin es por la importancia relativa de sus modelos de objetos, dinmico y funcional. Las distintas arquitecturas ponen distintos grados de nfasis en los tres modelos. El diseo de sistemas es la primera fase de diseo en la cual se selecciona la aproximacin bsica para resolver el problema. Durante el diseo del sistema, se decide la estructura y el estilo global. La arquitectura del sistema es la organizacin global del mismo en componentes llamados subsistemas. La arquitectura proporciona el contexto en el cual se toman decisiones ms detalladas en una fase posterior del diseo. AL tomar decisiones de alto nivel que se apliquen a todo el sistema, el diseador desglosa el problema en subsistemas, de tal manera que sea posible realizar ms trabajo por parte de varios diseadores que trabajarn independientemente en distintos subsistemas. El diseador de sistemas debe tomar las siguientes decisiones: - Organizar el sistema en subsistemas - Identificar la concurrencia inherente al problema - Asignar los subsistemas a los procesadores y tareas - Seleccionar una aproximacin para la administracin de almacenes de datos - Manejar el acceso a recursos globales - Seleccionar la implementacin de control en software - Manejar las condiciones de contorno - Establecer la compensacin de prioridades.

2.1.1 Actividades y casos de uso.

10

1. La experiencia y prctica de quien hace los diagramas y su respectiva descripcin marca el punto de vista o tendencia, que genera una manera particular de poner nfasis en determinados elementos. Por ejemplo si soy un desarrollador, veo en todas partes mens, tablas, opciones, clics y dems elementos es decir no analizo un problema y doy su solucin sino que de una vez pienso en como debera correr la apliacin. 2. El modelo de casos de uso, permite hacer una mejor toma de requerimientos y clarificar la funcionalidad del sistema, es decir que espera el usuario que haga el sistema, no tanto como lo haga o con que. 3. Por lo tanto una descripcin de un caso de uso especfico se debe orientar hacia que es lo que ese usuario hara all en interaccin con un sistema. Por lo tanto si tiene un caso de uso llamado Registrar inventario, en la descripcin no puede tener un paso que diga el usuario registra el inventario y listo, puesto que eso es precisamente lo que le preguntan, como se registra, (los pasos), los datos que se manipulan y que operaciones se hacen con ellos. Para que posteriormente un desarrollador pueda crear las pantallas y mens Recuerde que usted como tecnologo o ingeniero, entra a ser parte de un equipo, no lo hace todo usted y los dems necesitan especifaciones claras para poder hacer su trabajo. Una buena descripcin de casos de uso, en relacin con un buen modelo de clases facilita inmediatamente los diagras de secuencias y actividades y por lo tanto favorecen un ptimo desarrollo de la aplicacin. 2.1.2 Interfaces de usuario. En el contexto del proceso de interaccin persona-ordenador, la interfaz grfica de usuario, es el artefacto tecnolgico de un sistema interactivo que posibilita, a travs del uso y la representacin del lenguaje visual, una interaccin amigable con un sistema informtico. La interfaz grfica de usuario (en ingls GraphicalUser Interface, GUI) es un tipo de interfaz de usuario que utiliza un conjunto de imgenes y objetos grficos para representar la informacin y acciones disponibles en la interfaz. Habitualmente las acciones se realizan mediante manipulacin directa para facilitar la interaccin del usuario con la computadora. Surge como evolucin de la lnea de comandos de los primeros sistemas operativos y es pieza fundamental en un entorno grfico. Como ejemplo de interfaz grfica de usuario podemos citar el escritorio o desktop del sistema operativo Windows y el entorno X-Window de Linux.

11

2.2 Diseo de la lgica. El diseo lgico es el proceso de construir un esquema de la informacin que utiliza la empresa, basndose en un modelo de base de datos especfico, independiente del SGBD concreto que se vaya a utilizar y de cualquier otra consideracin fsica. En esta etapa, se transforma el esquema conceptual en un esquema lgico que utilizar las estructuras de datos del modelo de base de datos en el que se basa el SGBD que se vaya a utilizar, como puede ser el modelo relacional, el modelo de red, el modelo jerrquico o el modelo orientado a objetos. Conforme se va desarrollando el esquema lgico, ste se va probando y validando con los requisitos de usuario. La normalizacin es una tcnica que se utiliza para comprobar la validez de los esquemas lgicos basados en el modelo relacional, ya que asegura que las relaciones (tablas) obtenidas no tienen datos redundantes. Esta tcnica se presenta en el captulo dedicado al diseo lgico de bases de datos. El esquema lgico es una fuente de informacin para el diseo fsico. Adems, juega un papel importante durante la etapa de mantenimiento del sistema, ya que permite que los futuros cambios que se realicen sobre los programas de aplicacin o sobre los datos, se representen correctamente en la base de datos. Tanto el diseo conceptual, como el diseo lgico, son procesos iterativos, tienen un punto de inicio y se van refinando continuamente. Ambos se deben ver como un proceso de aprendizaje en el que el diseador va comprendiendo el funcionamiento de la empresa y el significado de los datos que maneja. El diseo conceptual y el diseo lgico son etapas clave para conseguir un sistema que funcione correctamente. Si el esquema no es una representacin fiel de la empresa, ser difcil, sino imposible, definir todas las vistas de usuario (esquemas externos), o mantener la integridad de la base de datos. Tambin puede ser difcil definir la implementacin fsica o el mantener unas prestaciones aceptables del sistema. Adems, hay que tener en cuenta que la capacidad de ajustarse a futuros cambios es un sello que identifica a los buenos diseos de bases de datos. Por todo esto, es fundamental dedicar el tiempo y las energas necesarias para producir el mejor esquema que sea posible. 2.2.1 Clases y Objetos. La clase Para crear una clase se utiliza la palabra reservada class y a continuacin el nombre de la clase. La definicin de la clase se pone entre las llaves de apertura y cierre. El nombre de la clase empieza por letra mayscula. classRectangulo{ //miembros dato //funciones miembro

12

} Los miembros dato Los valores de los atributos se guardan en los miembros dato o variables de instancia. Los nombres de dichas variables comienzan por letra minscula. Vamos a crear una clase denominada Rectangulo, que describa las caractersticas comunes a estas figuras planas que son las siguientes: El origen del rectngulo: el origen o posicin de la esquina superior izquierda del rectngulo en el plano determinado por dos nmeros enteros x e y. Las dimensiones del rectngulo: ancho y alto, otros dos nmeros enteros. classRectangulo{ int x; int y; int ancho; int alto; //faltan las funciones miembro } Las funciones miembro En el lenguaje C++ las funciones miembro se declaran, se definen y se llaman. En el lenguaje Java las funciones miembro o mtodos solamente se definen y se llaman. El nombre de las funciones miembro o mtodos comieza por letra minscula y deben sugerir acciones (mover, calcular, etc.). La definicin de una funcin tiene el siguiente formato: tiponombreFuncion(tipo parm1, tipo parm2, tipo parm3){ //sentencias } Entre las llaves de apertura y cierre se coloca la definicin de la funcin. tipo indica el tipo de dato que puede ser predefinido int, double, etc, o definido por el usuario, una clase cualquiera. Para llamar a un funcin miembro o mtodo se escribe retorno=objeto.nombreFuncion(arg1, arg2, arg3);

13

Cuando se llama a la funcin, los argumentos arg1, arg2, arg3 se copian en los parmetros parm1, parm2, parm3 y se ejecutan las sentencias dentro de la funcin. La funcin finaliza cuando se llega al final de su bloque de definicin o cuando encuentra una sentencia return. Cuando se llama a la funcin, el valor devuelto mediante la sentencia return se asigna a la variable retorno. Cuando una funcin no devuelve nada se dice de tipo void. Para llamar a la funcin, se escribe objeto.nombreFuncion(arg1, arg2, arg3); Estudiaremos ms adelante con ms detalle como se definen las funciones. Una funcin suele finalizar cuando llega al final del bloque de su definicin voidfuncion(.){ //sentencias } Una funcin puede finalizar antes del llegar al final de su definicin voidfuncion(.){ //sentencias if(condicion) return; //sentencias.. } Una funcin puede devolver un valor (un tipo de dato primitivo o un objeto). doublefuncion(.){ double suma=0.0; //sentencias return suma; } Cualquier variable declarada dentro de la funcin tiene una vida temporal, existiendo en memoria, mientras la funcin est activa. Se trata de variables locales a la funcin. Por ejemplo: voidnombreFuncion(intparm){ // int i=5; // } La variable parm, existe desde el comienzo hasta el final de la funcin. La variable local i, existe desde el punto de su declaracin hasta el final del bloque de la funcin.

14

Se ha de tener en cuenta que las funciones miembro tienen acceso a los miembros dato, por tanto, es importante en el diseo de una clase decidir qu variables son miembros dato, qu variables son locales a las funciones miembro, y qu valores les pasamos a dichas funciones. Los ejemplos nos ayudarn a entender esta distincin. Hemos definido los atributos o miembros dato de la clase Rectangulo, ahora le vamos aadir un comportamiento: los objetos de la clase Rectangulo o rectngulos sabrn calcular su rea, tendrn capacidad para trasladarse a otro punto del plano, sabrn si contienen en su interior un punto determinado del plano. La funcin que calcula el rea realizar la siguiente tarea, calcular el producto del ancho por el alto del rectngulo y devolver el resultado. La funcin devuelve un entero es por tanto, de tipo int. No es necasario pasarle datos ya que tiene acceso a los miembros dato ancho y alto que guardan la anchura y la altura de un rectngulo concreto. classRectangulo{ int x; int y; int ancho; int alto; intcalcularArea(){ return (ancho*alto); } } A la funcin que desplaza el rectngulo horizontalmente en dx, y verticalmente en dy, le pasamos dichos desplazamientos, y a partir de estos datos actualizar los valores que guardan sus miembros dato x e y. La funcin no devuelve nada es de tipo void. classRectangulo{ int x; int y; intancho; int alto; voiddesplazar(int dx, intdy){ x+=dx;

15

y+=dy; } } La funcin que determina si un punto est o no en el interior del rectngulo, devolver true si el punto se encuentra en el interior del rectngulo y devolver false si no se encuentra, es decir, ser una funcin del tipo boolean. La funcin necesitar conocer las coordenadas de dicho punto. Para que un punto de coordenadas x1 e y1 est dentro de un rectngulo cuyo origen es x e y, y cuyas dimensiones son ancho y alto, se deber cumplir a la vez cuatro condiciones x1>x y a la vez x1y y a la vez y1x)&&(x1y)&&(y1