Está en la página 1de 56

ESTRUCTURA DE LA TESIS

1.

Aspecto Formal Tamao y Tipo De Papel .- Se utilizar papel bond de formato A4, de 80grs. Y de color blanco. Se escribe en una sola cara, a doble espacio, evitando errores. El Tipo y Tamao de Letra es Arial : 12. Mrgenes.- Se debe respetar los cuatro mrgenes : El superior, el inferior, el lateral izquierdo y el lateral derecho. Margen Superior : 3cm. Margen Inferior : 3cm. Margen Lateral Izquierdo : 3.5cm. Margen Lateral Derecho : 2.5cm. Lneas por pginas.- Respetando estos mrgenes, la pgina contendr 25 lneas a doble espacio, para el cuerpo del texto. Numeracin de la pgina.- Todas las pginas del informe se cuentan, para efectos de paginacin. Esta pude ser colocada en la parte superior, al centro o al lmite del margen lateral derecho, o tambin en la parte inferior, al lmite del margen derecho. Las pginas del texto se enumeran con nmeros arbigos. Las pginas de portada, dedicatoria, prlogo e introduccin se numeran independientemente del texto con nmeros romanos. Secciones o Partes Las secciones o partes del Proyecto : Portada, Dedicatoria, Agradecimiento, Prlogo, Introduccin, Indice, Captulos I, II, III,...,Conclusiones, Recomendaciones, Bibliografa, Glosario de Trminos, Anexos. Portada.- Debe contener datos del ao declarado, logo de la institucin, ttulo del proyecto, datos de los integrantes, mes y ao de presentacin. Dedicatoria y Agradecimiento.- Reconocimiento a alguna persona o institucin. Suele colocarse a la altura de la octava lnea, prxima al margen lateral derecho. No debe ser muy extensa ni incluir un excesivo nmero de nombres. Prlogo.- Presentacin del Proyecto hecha por otra persona. Se coloca la palabra Prlogo en la sptima lnea, debidamente centrada, en maysculas y subrayada. Introduccin.- Se coloca la palabra Introduccin en la sptima lnea, debidamente centrada, en maysculas y subrayada. La introduccin debe presentar de forma clara y resumida una visin general de lo que trata la investigacin. Captulos y Subcaptulos.- Debe empezar con la palabra correspondiente, centrada, escrita con maysculas en la sptima lnea. El ttulo se escribir con mayscula, centrado y subrayado.

2.

-1-

Estilo de la redaccin.-Deber ser formal, en primera persona del plural o en impersonal, tercera persona del singular. Deber ser directo, adecuado al objeto de la investigacin. Citas.- Estas pueden ser textuales e ideogrficas. En las primeras, se cita textualmente al autor y en las segundas, el investigador las presenta con sus propias palabras. Las citas permiten al investigador corroborar algunas de sus afirmaciones. En este caso, la cita deber seguir algunas pautas. El fragmento que se cita textualmente debe escribirse entre comillas y dentro del formato normal de cada prrafo, si no excede dos lneas; si es mayor, debe de escribirse en espacio simple toda la cita, empezando a quince espacios para la primera lnea y a diez espacios del margen izquierdo y a dos espacios del prrafo anterior. Al concluir cada cita, debe colocarse la numeracin correlativa de notas entre parntesis. Notas al captulo.- En hoja aparte y al final de cada captulo o de todos los captulos, se comenzar en la sptima lnea con la palabra Notas al Captulo centrada y escrita con maysculas y subrayada. El texto se comenzar a tres espacios simples dejando entre nota y nota un espacio simple en blanco. La numeracin debe ser correlativa y entre parntesis. Conclusiones y Recomendaciones.- En la sptima lnea, se pondr la palabra Conclusiones, centrada con maysculas y subrayada. Despus de tres espacios simples se escribir las conclusiones a doble espacio. Debe ir numeradas. Son la sntesis del trabajo. Proporcionan un resumen sinttico pero completo de la argumentacin, las pruebas y los ejemplos consignados en el trabajo. Bibliografa.- En la sptima lnea, se pondr la palabra Bibliografa, escrita con maysculas, centrada y subrayada. Glosario de Trminos.- Definicin de nuevos trminos utilizados en la tesis. Anexos (opcional).- Esta seccin puede incluir todo el material suplementario. Cada uno de los materiales presentados en esta seccin debe tener una numeracin, un ttulo y la indicacin de la fuente.

3.

Estructura del Proyecto -2-

Portada Dedicatoria Agradecimiento Prlogo Introduccin

CAPTULO I : ANTECEDENTES DE LA ORGANIZACIN 1.1. Datos Generales Nombre o Razn Social Rubro Direccin, Distrito Telfono, Fax, e-mail Ubicacin Geogrfica 1.2. Productos y/o Servicios que Comercializan 1.3. Principales Clientes 1.4. Resea Histrica 1.5. Planeamiento Estratgico Empresarial 1.5.1 Definicin del Horizonte de Tiempo (2 Aos). 1.5.2 Principios Corporativos 1.5.3 Diagnstico Estratgico Anlisis FODA 1.5.4 Direccionamiento Estratgico Misin Visin Objetivos Estratgicos 1.5.5 Proyeccin Estratgica reas Estratgicas Proyectos Estratgicos 1.5.6 Plan Operativo Estrategias Planes de Accin 1.5.7 Monitoreo Estratgico 1.6. Estructura Organizacional 1.6.1. Organigrama 1.6.2. Manual de Funciones y Procedimientos 1.6.3. Flujogramas de Procesos CAPTULO II : ESTUDIO PRELIMINAR 2.1. Caractersticas del Proyecto 2.1.1. Objetivos del Proyecto Objetivo General Objetivos Especficos 2.1.2. Planteamiento del Problema -3-

2.1.3. Alcances del Proyecto 2.2. Estudio de Factibilidad 2.2.1. Factibilidad Tcnica 2.2.2. Factibilidad Econmica 2.2.3. Factibilidad Operativa 2.2.4. Anlisis Costo/Beneficio 2.3. Programacin del Proyecto 2.3.1. Equipo de Trabajo 2.3.2. Planeacin de Actividades y Tiempos 2.3.3. Diagrama de Gantt 2.4. Metodologa y Herramientas 2.4.1. Metodologa de Desarrollo 2.4.2. Herramientas a Utilizar CAPTULO III : DESCRIPCION DEL SISTEMA ACTUAL 3.1. Informacin del Sistema Actual 3.1.1. Entrevistas. Detalles e Informes 3.1.2. Cuestionarios. Detalles e Informes 3.1.3. Anlisis de Documentos 3.1.3.1 Identificacin y Funciones 3.1.3.2 Formato. Diseo. 3.1.4. Observacin. Detalle e Informe. 3.2. Modelado del Negocio 3.2.1. Modelado de Casos de Uso del Negocio 3.2.1.1. Diagrama de Casos de Uso del Negocio 3.2.1.2. Descripcin de Casos de Uso del Negocio 3.1.3.3 Especificacin de Reglas del Negocio 3.2.2. Modelo de Objetos del Dominio 3.2.3. Modelo de Objetos de Negocios 3.3. Modelado del Sistema Actual 3.3.1. Diagrama de Casos de Uso del Sistema Actual 3.3.2. Diagrama de Actividades del Sistema Actual CAPTULO IV : MODELADO DEL SISTEMA PROPUESTO 4.1. Informacin del Sistema Propuesto 4.1.1. Entrevistas. Detalles e Informes 4.1.2. Cuestionarios. Detalles e Informes 4.1.3. Anlisis de Nuevos Documentos Propuestos 4.1.3.1. Identificacin y Funciones 4.1.3.2. Formato. Diseo de Nuevos Documentos. 4.1.4. Observacin. Detalle e Informe. 4.2. Modelado del Sistema Propuesto 4.2.1. Modelado de Casos de Uso del Sistema Propuesto 4.2.1.1. Diagrama de Casos de Uso del Sistema 4.2.1.2. Descripcin de Casos de Uso del Sistema 4.2.2. Diagrama de Clases del Sistema Propuesto -4-

4.2.3. Diagrama e Interaccin del Sistema Propuesto 4.2.3.1. Diagrama de Secuencia 4.2.3.2. Diagrama de Colaboracin 4.2.4. Diagrama e Actividades del Sistema Propuesto CAPTULO V : DISEO DEL SISTEMA 5.1. Diseo de Interfaces 5.1.1. Interfaz de Seguridad 5.1.2. Interfaces de Entrada 5.1.3. Interfaces de Salida 5.2. Diseo de Base de Datos. 5.2.1. Modelado de Datos 5.2.1.1. Diseo Conceptual 5.2.1.2. Diseo Lgico 5.2.1.3. Diseo Fsico 5.2.2. Diseo de la Base de Datos. 5.3. Diseo de Reportes CAPTULO VI : IMPLEMENTACIN DEL SISTEMA 6.1. Plan de Pruebas del Sistema 6.2. Instalacin del Sistema 6.2.1. Requisitos de Instalacin 6.2.2. Modo de Instalacin 6.3. Diagrama de Componentes 6.4. Diagrama de Despliegue CAPTULO VII : MANUAL DE USUARIO 7.1. Introduccin 7.2. Objetivos 7.3. Especificaciones Tcnicas 7.3.1 Hardware 7.3.2 Software 7.4. Ingreso al Sistema 7.5. Operacin del Sistema 7.6. Glosario de Trminos 7.7 ndice Conclusiones Recomendaciones Bibliografa Glosario de Trminos Anexos Documentacin Carta de Presentacin

-5-

FUNDAMENTOS DE LOS SISTEMAS WEB


1. Servicios de Internet Un servicio Web (en ingls Web service) es una coleccin de protocolos y estndares que sirven para intercambiar datos entre aplicaciones Accesible desde cualquier aplicacin Por cualquier lenguaje de programacin Desde cualquier plataforma Usando estndares abiertos

2. Protocolos conocidos XML: Es el formato estndar para los datos que se vayan a intercambiar. SOAP o XML-RPC: Protocolos sobre los que se establece el intercambio. HTTP, FTP, o SMTP: los datos en XML tambin pueden enviarse de una aplicacin a otra mediante protocolos normales ya bien conocidos. WSDL: Es el lenguaje de la interfaz pblica para los servicios Web. UDDI: Protocolo para publicar la informacin de los servicios Web. WS-Security: Protocolo de seguridad aceptado como estndar por OASIS 3. Ventajas de los servicios Web Aportan interoperabilidad entre aplicaciones de software Los servicios Web fomentan los estndares y protocolos basados en texto (ms humanos y accesibles) Al apoyarse en HTTP, permiten acceder a cualquier sistema conectado a la red (http usa el puerto 80) Permiten el uso de servicios integrados cambiando el de varias compaas y varios software Permiten la interoperabilidad entre plataformas de distintos fabricantes por medio de protocolos estndar. 4. Inconvenientes de los servicios Web Para realizar transacciones no pueden compararse en su grado de desarrollo con los estndares abiertos de computacin distribuida como CORBA. Su rendimiento es bajo si se compara con otros modelos de computacin distribuida, tales como RMI o CORBA (XML no est diseado para el rendimiento) Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en firewalls cuyas reglas tratan de bloquear o auditar la comunicacin entre programas a ambos lados de la barrera. Existe poca informacin de servicios Web para algunos lenguajes de programacin 5. Razones para el uso de servicios Web -6-

La principal razn para usar servicios Web es que se basan en HTTP sobre TCP en el puerto 80 Buena interfaz para acceder a servicios y funcionalidades de otros ordenadores en la red Gran independencia y flexibilidad entre aplicacin y servicio 6. Plataformas de Servicios y contenedores de Aplicaciones Axis y el servidor Jakarta Tomcat (de Apache) ColdFusion MX de Macromedia Java Web Services Development Pack (JWSDP) de Sun Microsystems (basado en Jakarta Tomcat) JOnAS (parte de ObjectWeb una iniciativa de cdigo abierto) Microsoft .NET Novell exteNd (basado en la plataforma J2EE) WebLogic WebSphere 7. Tipos de Arquitecturas en tecnologas cliente-servidor Aplicaciones mono-capa: Tanto los datos de aplicacin como la interfaz como la lgica de modelo residen en una misma identidad.

Interface de usuario Lgica de negocio

Datos

Aplicaciones Cliente Servidor 2 capas -7-

Se separan 2 de las tres capas. El cliente an puede integrar parte de la funcionalidad del sistema.

Interface de usuario Funcionalidad Parcial de negocio Lgica

Datos

Aplicaciones Cliente Servidor 3 capas Creamos un cliente que carece de toda lgica de negocio y apenas ofrece alguna funcionalidad ms que la de visin y peticin de datos.

Lgica de negocio

Datos

Interface de usuario Funcionalidad Parcial


8. Caractersticas de las capas -8-

Las diferentes capas suelen ser Capa 1 : Cliente de aplicacin Ejemplos: Set-top box, navegador Web Capa 2 : Servidor de Aplicaciones Ejemplo: Servidor Tomcat con servlets Capa 3 : Servidor de Datos Ejemplo: Base de datos, servidor SMTP 9. Esquema de la arquitectura Se representa de la siguiente manera
Set-Top Box
<http 1.0> <to> <from> <body>

MHProject Server

<smtp> <HELO> <Mail From>

Servidor Mail

Peticin HTTP

Peticin SMTP

Respuesta HTTP Cliente


<http 1.0> <confirmacin>

Respuesta SMTP Servidor de Aplicaciones


<smtp> <HELO> <OK>

Servidor de Datos

MODELADO DE APLICACIONES CLIENTE / SERVIDOR


-9-

1. 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. Nivel 3: Almacenamiento mecanismo de almacenamiento.

2. Arquitectura de tres niveles orientadas a objetos 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. 3. 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. - 10 -

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.

4. 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.

- 11 -

5. 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.

- 12 -

ARQUITECTURA MULTICAPAS
1. Arquitectura multicapas orientadas a objetos Descomposicin de la capa de la lgica de aplicaciones: Objetos del dominio. Servicios.

Presentacin

TPDVApplet Pago Venta Generador de reportes


Conceptos del dominio

Lgica de aplicaciones

Interfaz de la Base de datos

Servicios

Almacenamiento

Base de Datos

2. Motivos para usar arquitectura multicapas Aislamiento de la lgica de aplicaciones en componentes susceptibles de reutilizarse despus en otros sistemas.

independientes

Distribucin de las capas en varios nodos fsicos de computo y en varios procesos. Esto puede mejorar el desempeo, la coordinacin y el compartir la informacin en un sistema de cliente-servidor. Asignacin de los diseadores para que construyan determinadas capas; por ejemplo, un equipo que trabaje exclusivamente en la capa de presentacin. Y as se brinda soporte a los conocimientos especializados en las habilidades de desarrollo y tambin a la capacidad de realizar actividades simultaneas en equipo.

- 13 -

3. Representacin de la Arquitectura con Paquetes UML


Presentacin
Presentacin

Conceptos de dominio

Elementos bsicos

Ventas

Lgica de aplicaciones

Dominio

Servicios

Paquetes en UML

Almacenamiento

Base de datos

4. Ejemplo de paquetes y de dependencias

Presentacin1

Dominio Capa de servicios de alto nivel orientada a objetos Capa de servicios de bajo nivel (orientados a objetos y no orientados a objetos)

Interfaz de base de datos relacional

Comunicacin

Interfaz de base de datos orientada a objetos

Reportes

Esquemas de aplicaciones y bibliotecas de soportes2

Ejemplos: 1. Applets de Java, documentos y vistas MFC VisualParts de VisualAge 2.JDK, MFC,STL

Base de datos relacional

Base de datos orientada a objetos

5. Identificacin de los Paquetes - 14 -

Agrupe los elementos en 1 paquete as: Agrupe los elementos para ofrecer en un paquete un servicio comn (o una familia de servicios relacionados), con un nivel relativamente alto de acoplamiento y colaboracin. En cierto nivel de abstraccin, se vera el paquete como muy cohesivo (tiene responsabilidades estrechamente relacionadas). En cambio, habr relativamente bajo acoplamiento y colaboracin entre los elementos de diferentes paquetes.

Dominio

Elementos bsicos

Ventas

Productos

Servicios Interfaz de base de datos orientada a objetos

Interfaz de base de datos relacional

Comunicacin

Reportes

Particiones horizontales

EXTENSIN DE UML
- 15 -

1. Descripcin Esta extensin de UML define un conjunto de estereotipos, valores etiquetados y restricciones que nos permiten modelar aplicaciones Web. Los estereotipos y restricciones se aplican a ciertos componentes que son particulares de sistemas Web y nos permiten representarlos en el mismo modelo, y en los mismos diagramas que describen el resto del sistema. El elemento principal especfico de aplicaciones Web es la pgina Web. Hay varios estereotipos que pueden ser aplicados a una pgina Web, y otros adicionales que son asignados a otros elementos de HTML y que representan componentes arquitecturalmente significativos del sistema (frames, formularios...). La mayora de los valores etiquetados mencionados en esta extensin pueden ser considerados como una presentacin ms bien que estructurales. 2. Estereotipos 1.1. Server Page (Pgina servidor)

Clase Metamodelo: Clase Descripcin: Una pgina de servidor representa una pgina Web que tiene scripts que ejecutados por el servidor. Estos scritps interactan con recursos del servidor como bases de datos, lgica de negocio y sistemas externos. Las operaciones del objeto representan las funciones en el script, y sus atributos representan las variables que son visibles en el mbito de la pgina (accesibles por todas las funciones de la pgina). Restricciones: La pgina de servidor slo puede tener relaciones con objetos localizados en el servidor. Valores Etiquetados: Motor del Script Tanto el lenguaje como el motor que se debera usarse para ejecutar o interpretar esta pgina (JavaScript, VBScript, Perl, etc.)

1.2. Server Cliente - 16 -

Clase del metamodelo: Clase Descripcin: Una instancia de una pgina cliente es una pgina Web con formato HTML y es una mezcla de datos, presentacin e incluso lgica. Las pginas clientes son representadas por los navegadores clientes, y pueden contener scripts que son interpretados por el navegador. Las funciones de la pgina cliente mapean las funciones en las etiquetas script de la pgina. Los atributos de la pgina cliente mapean las variables declaradas en las etiquetas script de la pgina, que son accesibles por una funcin en la pgina (con mbito de pgina).Las pginas cliente pueden tener asociaciones con otras pginas cliente o servidor. Restricciones: No Valores Etiquetados: EtiquetaTtulo El ttulo de la pgina lo muestra el navegador EtiquetaBase El URL base por referencia de URLs relativos. EtiquetaCuepo El conjunto de atributos para la etiqueta <cuerpo> que establecen el color de fondo y los atributos del texto por defecto.
1.3.

Form

Clase del metamodelo: Clase Descripcin: Una clase estereotipada como form es una coleccin de campos de entrada que forman parte de una pgina cliente. Una clase form se mapea directamente con la etiqueta HTML form. Los atributos de est clase representan los campos de entrada del formulario HTML (input boxes, text areas, radio buttons, check boxes, y campos hidden). Un form no tiene operaciones, por lo que no pueden ser encapsuladas en un formulario. Cualquier operacin que interacte con el formulario es una propiedad de la pgina que contiene al formulario. - 17 -

Restricciones: Ninguna Valores Etiquetados: Method el mtodo usado para enviar datos al URL del action, puede tomar los valores GET o POST. 1.4. Submit Clase del metamodelo: Asociacin Descripcin: Una asociacin submit es siempre entre un form (formulario) y una server-page (pgina servidor). Los formularios envan los valores de sus campos al servidor a travs de pginas servidor para procesarlos. El servidor Web procesa la pgina servidor, la cual acepta y usa la informacin dentro del formulario enviado Restricciones: Ninguna Valores Etiquetados: Parmetros una lista de nombres de parmetros que deberan ser pasados con la peticin de la pgina enlazada 1.5. Link Clase del metamodelo: Asociacin Descripcin: Un link (enlace) es un puntero desde una pgina cliente a otra Page. En un diagrama de clases, un link es una asociacin entre una client page y cualquier otra client page o una server page. Una asociacin Link se mapea dirctamente con la etiqueta HTML ancla. Restricciones: Ninguna Valores Etiquetados: Parmetros una lista de nombres de parmetros que deberan ser pasados con la peticin de la pgina enlazada 1.6. Build Clase del metamodelo: Asociacin Descripcin: La relacin builds es un tipo especial de relacin que une el vaco entre las pginas cliente y de servidor. Las pginas de servidor existen nicamente en el servidor. Son usadas para crear pginas cliente. La asociacin builds identifica que pgina de servidor es responsable de la creacin de una pgina cliente. sta es una relacin direccional, pues la pgina cliente no tiene conocimiento de cmo ha sido creada. Una pgina de servidor puede crear mltiples pginas cliente, pero una pgina cliente tan solo puede ser construida por una pgina de servidor. Restricciones: Ninguna Valores Etiquetados: No 1.7. Redirect Clase del metamodelo: Asociacin. Descripcin: Una relacin redirect es una asociacin unidireccional con otra pgina Web. Puede ser dirigida desde y hasta una pgina cliente o de servidor. Si la relacin se origina desde una server page entonces indica que el procesado de la pgina solicitada debe continuar en la otra pgina. Esto indica que la pgina destino siempre participa en la creacin de la pgina cliente. Esta relacin no es completamente estructural, pues la invocacin - 18 -

de una operacin de redireccin se debe hacer a travs de programacin en el cdigo de la pgina origen. Si la relacin se origina desde una client page entonces esto indica que la pgina destino ser automticamente solicitada por el navegador, sin la participacin activa del usuario. Se puede especificar un tiempo de demora (en segundos) antes de que la segunda pgina sea solicitada. El uso de la redireccin se corresponde con la etiqueta META y HTTPEQUIV el valor de "Refresh". Valores Etiquetados: Demora Cantidad de tiempo que una pgina cliente debera esperar para ser redirigida a la siguiente pgina. Este valor se corresponde con el atributo Content de la etiqueta Meta.
1.8.

Input Element Clase del Metamodelo: Atributo Descripcin: Un Input Element es un atributo de un objetoForm. Se mapea directamente con la etiqueta HTML <input>. Este atributo es usado para introducir una palabra o una lnea de texto. Los Valores Etiquetados asociados con este atributo estereotipado se corresponden con los atributos de la etiqueta <input>. Para completar los valores requeridos por la etiqueta HTML; el nombre del atributo se usa como el nombre de la etiqueta <input>, y el valor inicial del atributo es el valor de la etiqueta. Restricciones: Ninguna Valores Etiquetados: Type El tipo del control input puede ser {Text, Number, Password, Checkbox, Radio, Submit, Reset}. Size Especfica la longitud del rea que aparece en pantalla, en caracteres. Maxlength El mximo nmero de caracteres que el usuario puede introducir.

1.9. Select Element Clase del Metamodelo: Atributo Descripcin: Un control input usado en los formularios. Este control permite al usuario seleccionar uno o ms elementos de una lista. La mayora de los navegadores representan este control como un combo o un list box. Restricciones: Ninguna Valores Etiquetados: Size Especifica cuantos campos se muestran al mismo tiempo. Multiple Booleano que indica puede ser seleccionado mltiples campos de la lista. Text Area Element Clase del Metamodelo: Atributo Descripcin: Un control input usado en los formularios que permite introducir mltiples lneas. Restricciones: Ninguna - 19 -

Valores Etiquetados: Rows Nmero de filas de texto visibles. Cols El ancho visible del control in average character widths. 1.10. Web Page

Clase del Metamodelo: Componente Descripcin: Un componente pgina es una pgina Web. Puede ser solicitada por su nombre por un navegador. Un componente pgina puede contener o no scripts cliente o servidor. Tpicamente los componentes pgina son ficheros de texto accesibles por el servidor Web, pero tambin pueden ser mdulos compilables que son cargados e invocados por el servidor Web. Finalmente cuando se accede a travs del servidor Web una pgina produce un documento con formato HTML que se enva como respuesta a la peticin de un navegador. Restricciones: Ninguna Valores Etiquetados: Path La ruta requerida para especificar la pgina Web en el servidor Web. Este valor debera ser relativo a directorio raz de la aplicacin Web... 1.11. Pgina ASP

Clase del Metamodelo: Componente Descripcin: Son pginas Web que implementan cdigo del lado del servidor. Este estereotipo es aplicable solamente en aplicaciones basadas en Microsoft Active Server Pages. - 20 -

Restricciones: Ninguna Valores Etiquetados: Los mismos que una pgina Web 1.12. Libreras Script

Clase del Metamodelo: Componente Descripcin: Componente que proporciona una serie de subrutinas de funciones que pueden ser incluidas por otros componentes de pginas Web Restricciones: Ninguna Valores Etiquetados: Los mismos que una pgina Web 1.13. Servlet

Clase del Metamodelo: Componente Descripcin: Un componente Java Servlet. Este estereotipo es aplicable nicamente en entornos de desarrollo con soporte para los Servlets de Sun Restricciones: Ninguna Valores Etiquetados: Los mismos que una pgina Web

1.14. Pgina JSP

- 21 -

Clase del Metamodelo: Componente Descripcin: Pginas Web que implementan cdigo JSP del lado del servidor. Este estereotipo es aplicable nicamente en entornos de aplicaciones Web que usen JavaServer Pages. Restricciones: Ninguna Valores Etiquetados: Los mismos que una pgina Web 3. Reglas Bien formadas. Realizacin de componentes En general, los componentes pueden realizar las clases estereotipadas server page, client page, frameset,form,JavaScript Object,ClientScript object, y target. Generalizacin Todo el modelado de elementos en una generalizacin debe estar en el mismo estereotipo. Asociacin La pgina cliente puede tener como mximo una relacin builds con una pgina de servidor, aunque una pgina de servidor puede tener mltiples relaciones builds con diferentes pginas cliente. Adems de las combinaciones UML estndar, se permiten las siguientes combinaciones para cada estereotipo:

- 22 -

INGENIERA DIRECTA PARA APLICACIONES WEB


1. Ingeniera Directa Selecciona Modelo Web 1. Desde el men principal seleccione Tools / Option, mostrndose la siguiente ventana

Seleccione la opcin

2. Haga clic en la pestaa Notation y seleccione el lenguaje Web Modeler 3. Haga clic derecho en la vista lgica, seleccione Web Modeler /New /Virtual Directory

- 23 -

4. Seleccione como plataforma el ASP en indique los siguientes parmetros como se muestra a continuacin URL: www.biblionet.com Virtual Directory: ModeloWeb Physical Location: D:\ApliRFH\rose\BiblioNet 5. Luego pulse el botn Ok, mostrndose el siguiente Browse

Estereotipos de las Clases Web. Pagina Servidor 1. Luego pulse el botn Ok, mostrndose el siguiente Browse 2. Haga clic derecho en el directorio virtual Modelo Web 3. Seleccione Web Modeler/New/Server Page 4. Definir un nombre a la pagina cliente: Biblio - 24 -

Biblio
(from ModeloWeb)

Estereotipos de las Clases Web. Pagina Cliente 1. Haga clic derecho en el directorio virtual Modelo Web 2. Seleccione Web Modeler/New/Client Page 3. Definir un nombre a la pagina cliente: Inicio

Inicio
(from Model oWeb)

4. De Igual manera crea las pginas cliente inscripcin y prstamo. Relacin entre las paginas 1. Ubquese en la barra de herramienta y seleccione el icono Asociacin direccional (Unidireccional Association) 2. Ubquese en la pagina cliente inicio y arrastre hasta la pagina inscripcin 3. Para llamar de nuevo desde la pagina inscripcin seleccione el icono de Asociacin direccional y arrastre de la pagina inscripcin hasta la pagina inicio 4. De igual manera haga clic en el icono de la asociacin direccional y arrastre desde la pagina servidor hasta la pagina cliente inicio, apareciendo una ventana y pulse el botn aceptar 5. Para cambiar el tipo de estereotipo ubquese en la relacin creada anteriormente, haciendo clic derecho y seleccione la opcin de especificacin estndar (Open Standard Specification) y seleccione el estereotipo Build como se muestra en la ventana

- 25 -

Seleccione estereotipo

6. Luego pulse el botn Ok. mostrndose el siguiente diagrama


<<Build>>

Biblio
(from M ode loWe b)

Inicio
(from M odeloWeb)

<<Link>>

<<Link>>

<<Link>>

<<Link>>

Prestamo
(from M odel oWeb)

Inscripcion
(from M odeloWeb)

1. 2. 3. 4.

Estereotipos de las Clases Web. Formulario Haga clic derecho en la Pagina Cliente Inscripcin. Seleccione Web Modeler/New/HTML Form. Arrastre desde el Navegador hacia el rea de trabajo. De igual manera haga para la clase prstamo.

- 26 -

Propiedades del Formulario 1. Ubquese en el navegador y haga clic derecho en el formulario Inscripcin, seleccione Web Modeler/New/HTML Input e ingrese el siguiente valor

2. Para generar un control radio ubquese en el navegador y haga clic derecho, seleccione Web Modeler/New/HTML Input e ingrese el siguiente valor

- 27 -

3. Para generar un botn ubquese en el navegador y haga clic derecho, seleccione Web Modeler/New/HTML Input e ingrese el siguiente valor

4. De igual manera realice para el formulario prstamo, quedando el diagrama de la siguiente forma
<<Build>>

Biblio
(from ModeloWeb)

Inicio
(from ModeloWeb)

<<Link>> <<Link>>

<<Link>> <<Link>>

Inscripcion Prestamo
(from ModeloWeb) (from ModeloWeb)

Form
(from Inscripcion)

Form
(from Prestamo)

<<HTML Input>> Nombre del usuario : text <<HTML Input>> Respuesta[1] : radio = M <<HTML Input>> Respuesta[2] : radio = F <<HTML Input>> attribute : submit = Enviar

<<HTML Input>> Nombre del Usuario : text <<HTML Input>> Titulo del Libro : text <<HTML Input>> attribute : submit = Enivar

- 28 -

Generar el Cdigo 1. Haga clic derecho en el paquete del directorio virtual seleccione Web Modeler/ Generate Code. 2. Cuando finaliza termina de la siguiente forma

Grabar Modelo y Ejecutar 1. Grabe su modelo en la carpeta creada anteriormente, como se muestra a continuacin

- 29 -

2. Haga clic en el archivo inicio y seleccione del men principal la opcin ver/Cdigo Fuente y se vera el cdigo correspondiente para lo cual puede embellecer su pagina

2 Ingeniera Reversa Crear Paginas


1.

Crear las siguientes pginas web en la carpeta creada Biblioteca

- 30 -

Selecciona Modelo Web 1. Desde el men principal seleccione Tools / Web Modeler / Engineer a New Web Application, como se muestre a continuacion

- 31 -

2. Haga clic en botn siguiente Next.

3. Seleccione los archivos html como se muestra

4. Pulse el botn Siguiente, luego finalice con el botn Final 5. Desde el navegador expanda el directorio virtual y arrastre los iconos hacia el rea de trabajo, luego expanda las paginas clientes y arrastre los formularios como se muestra a continuacin

- 32 -

<<Link>> inicio.html
(from Bi blio)

<<Link>>

inscripcion.html
(from Bi blio)

prestamo.html
(from Biblio)

Form
(from inscri pcion.html)

<<HTML Input>> nombre del Usuario : TEXT <<HTML Input>> Respuesta[1] : RADIO = M <<HTML Input>> Respuesta[2] : RADIO = F <<HTML Input>> attribute : Submit = Enviar Form
(from prestamo.html)

<<HTML Input>> nombre del Usuario : TEXT <<HTML Input>> Titulo del libro : TEXT <<HTML Input>> attribute : Submit = Enviar

6. Para finalizar grabe su modelo en la carpeta creada anteriormente

- 33 -

INTRODUCCIN AL DISEO DE PATRONES


1. Nociones Durante el anlisis analizaremos el dominio del problema para construir un modelo del mundo real utilizando objetos. Investigaremos para hacer una descripcin del problema y obtencin de los requerimientos. El diseo consiste en el refinamiento de los modelos de anlisis para crear especificaciones adicionales que enriquecen el modelo de anlisis con detalles prximos a la implementacin. Una solucin lgica, de forma que se cumplan los requerimientos (asignacin de responsabilidades, interacciones entre objetos, etc.) La implementacin la deberemos realizar en un lenguaje orientado a objetos, durante la cual codificaremos el diseo obtenido en las fases de anlisis y diseo. (Lenguajes OO: Java, C++, Delphi, etc.) A pesar de todas estas divisiones sigue habiendo interacciones debidas al uso inadecuado de la orientacin a objetos, una muy comn es el mal empleo de la encapsulacin. Otro de los problemas fundamentales es el vaco existente entre el anlisis, diseo e implementacin, que hace que el programador tenga que tomar decisiones de diseo, o se produzca sobrespecificacin Para solventar estos problemas se produce un nuevo enfoque: el diseo con patrones. La idea nace del arquitecto Christopher Alexander, que aplica el concepto a la construccin urbanstica. 2. Diseo de Patrones El objetivo es agrupar una coleccin de soluciones de diseo que son vlidas en distintos contextos y que han sido aplicadas con xito en otras ocasiones. Un patrn de diseo es una solucin a un problema de diseo no trivial que es efectiva (ya se resolvi el problema satisfactoriamente en ocasiones anteriores) y reusable (se puede aplicar a diferentes problemas de diseo en distintas circunstancias). Los patrones son soluciones de sentido comn que deberan formar parte del conocimiento de un diseador experto. Adems facilitan la comunicacin entre diseadores, pues establecen un marco de referencia (terminologa, justificacin). Por otro lado, los patrones de diseo, facilitan el aprendizaje al programador inexperto, pudiendo establecer parejas problema-solucin.

- 34 -

En la programacin orientada a objetos resulta complicado descomponer el sistema en objetos (encapsulacin, granularidad, dependencias, flexibilidad, reusabilidad, etc.), los patrones de diseo nos permitirn identificar a los objetos apropiados de una manera mucho ms sencilla. Tambin nos permitirn determinar la granularidad de los objetos. Adems, los patrones de diseo, tambin nos ayudarn a especificar las interfaces, identificando los elementos claves en las interfaces y las relaciones existentes entre distintas interfaces. De igual modo nos facilitar la especificacin de la implementacin. Tambin, y de forma casi automtica, nos ayudan a reutilizar cdigo, facilitando la decisin entre "herencia o composicin" (favorece la composicin sobre la herencia y hace uso de la delegacin). Relacionan estructuras en tiempo de compilacin y en tiempo de ejecucin. Nos permiten hacer un diseo preparado para el cambio. Podemos clasificar a los patrones segn su propsito: Patrones de creacin: para creacin de instancias. Patrones estructurales: relaciones entre clases, combinacin y formacin de estructuras mayores. Patrones de comportamiento: interaccin y cooperacin entre clases. 3. Patrones de Creacin Los patrones de creacin abstraen la forma en la que se crean los objetos, permitiendo tratar las clases a crear de forma genrica dejando para ms tarde la decisin de qu clases crear o cmo crearlas. Segn donde se tome dicha decisin podemos clasificar a los patrones de creacin en patrones de creacin de clase (la decisin se toma en los constructores de las clases y usan la herencia para determinar la creacin de las instancias) y patrones de creacin de objeto (se modifica la clase desde el objeto).
4. Patrones estructurales

Tratan de conseguir que cambios en los requisitos de la aplicacin no ocasionen cambios en las relaciones entre los objetos. Lo fundamental son las relaciones de uso entre los objetos, y, stas estn determinadas por las interfaces que soportan los objetos. Estudian como se relacionan los objetos en tiempo de ejecucin. Sirven para disear las interconexiones entre los objetos.

- 35 -

5. Patrones de comportamiento Los patrones de comportamiento estudian las relaciones entre llamadas entre los diferentes objetos, normalmente ligados con la dimensin temporal.
6. Antipatrones

Los patrones nos ofrecen una forma de resolver un problema tpico, los antipatrones nos ensean formas de enfrentarse a problemas con consecuencias negativas conocidas. Los antipatrones se basan en la idea de que puede resultar ms fcil detectar a priori fallos en el desarrollo del proyecto que elegir el camino correcto, o lo que es lo mismo, descartar las alternativas incorrectas nos puede ayudar a la eleccin de la mejor alternativa. Los antipatrones se clasifican en antipatrones de desarrollo, de arquitectura de software y de gestin de proyectos. 6.1. Antipatrones de desarrollo: The blob (clases gigantes) Lava flow (cdigo muerto) Functional Decomposition (Diseo No Orientado a Objetos) Poltergeists (No se sabe lo que hacen algunas clases) Golden Hammer (Para un martillo todo son clavos) Spaghetti Code (Muchos if o switch) Cut & Paste programming (cortar y pegar cdigo) 6.2. Antipatrones de arquitectura de software: Stovepipe enterprise (Aislamiento en la empresa, Islas de Automatizacin o Empresa con sistemas parcheados). La causa suele estar en una falta de estrategia tecnolgica en la empresa, falta de cooperacin y comunicacin entre departamentos y niveles, deficiencias en el conocimiento de la tecnologa, etc. Stovepipe system (Legacy System, Sistema Heredado, Aislamiento entre sistemas o Sistema Parcheado) Vendor Lock-In (Arquitectura dependiente del producto, Amarrado por el vendedor, Esclavitud y Sumisin) Architecture by implication (Arquitectura Implcita). No se especifica la arquitectura del sistema o ignora alguno de sus apartados. Design by committee (Diseo por Comit, Navaja suiza, Chapa de Oro, Enfermedad de Estandarizacin) Se da cuando el proyecto se disea a travs de las reuniones de un comit demasiado numeroso o inexperto. Reinvent the wheel Se supone que se debe desarrollar desde cero, falta informacin y tecnologa reusable entre proyectos

- 36 -

6.3. Antipatrones de gestin de proyectos: Analysis paralysis. Ocurre cuando un equipo de analistas comienza una fase de anlisis que slo acaba cuando se cancela el proyecto. Death by planning Corncob (Personas problematicas) Irrational management Project mismanegement 7. Principales Patrones A continuacin se muestra algunos de los patrones bsicos: Patrones de creacin Patrn Factora Patrn Factora Abstracta Patrn Singleton (Instancia nica) Patrn Prototipo Patrones estructurales Patrn Adaptador Patrn Puente Patrn Composicin Patrn Decorador Patrn Fachada Patrn Proxy Patrones de comportamiento Patrn Cadena de Responsabilidad Patrn Comando Patrn Intrprete Patrn Iterador Patrn Mediador Patrn Recuerdo (Memento) Patrn Observador Patrn Estado Patrn Estrategia Patrn Plantilla Patrn Visitante

- 37 -

PATRONES CREACIONALES
1. Nociones Abstraen el proceso de instanciacin. Nos ayudan a independizar a un sistema, de cmo sus objetos son creados. En general, tratan de ocultar las clases y mtodos concretos de creacin, de tal forma que al variar su implementacin, no se vea afectado el resto del sistema. 2. Patrn Singleton 2.1. Contexto. En algunas situaciones, necesitamos que algunos datos sean accesibles desde el resto del sistema. Y tambin necesitamos que esos datos sean nicos. Por ejemplo, un objeto que abstraiga lo que es el Sistema Operativo actual. Tambin podra ser un objeto que represente al Sistema Contable, que sea el punto de entrada a un sistema externo. 2.2. Problema. Cmo hacer que la instancia de un objeto sea accesible globalmente, y que sea nica? 2.3. Solucion. El patrn Singleton proporciona la siguiente solucin: Hacer que la clase provea una instancia de s misma. Permitir que otros objetos obtengan esa instancia, mediante la llamada a un mtodo de la clase. Declarar el constructor como privado, para evitar la creacin de otros objetos. El diagrama UML correspondiente es muy simple:

Singleton Singleton() getInstance()


Este diagrama UML muestra que Singleton es una clase. Contiene una propiedad esttica (el subrayado indica que es un mtodo de clase, mas que de instancia), que retorna un Singleton, un objeto de la misma clase. Segn la notacin UML el nmero 1 en la esquina superior derecha, indica que solamente habr una instancia de esta clase. El signo "-" en el constructor, lo seala como privado. Esto consigue que nadie aparte de la propia clase, pueda crear una instancia.

- 38 -

2.4. Implementacin. Public Class Singleton Private Shared Instancia As Singleton Private Hora As String ' Constructor privado Private Sub New() Hora = Now.ToLongTimeString MsgBox("Objeto Singleton Creado en New a las " + Hora) End Sub Public Shared Function CrearInstancia() As Singleton If Instancia Is Nothing Then Instancia = New Singleton End If Return Instancia End Function Public Function MostrarHora() As String Return Hora End Function End Class Esta es una implementacin en VB.NET. Notamos que el mtodo CrearInstancia est marcado como "shared", siendo entonces un mtodo de la clase. Conseguimos que el constructor no pueda usarse desde otra parte del sistema, catalogando con "private" al Sub New.

- 39 -

PATRONES ESTRUCTURALES
1. Nociones Se ocupan de cmo las clases y objetos se agrupan, para formar estructuras ms grandes. Tambin se puede considera como la composicin de clases y objetos 2. Tipos de patrones 2.1. De Clase. Usa herencia para componer interfaces o implementaciones. Entre ellas tenemos: 2.1.1. Herencia mltiple 2.1.2. Class Adapter
2.2.

De Objeto. Composicin de objetos en tiempo de ejecucin. entre ellas tenemos 2.2.1. Object Adapter 2.2.2. Bridge 2.2.3. Composite 2.2.4. Decorator 2.2.5. Facade 2.2.6. Flyweight 2.2.7. Proxy

3. Patrn Adaptador 3.1. Propsito. Convertir la interfaz de una clase en otra que esperan los clientes. 3.2. Otras denominaciones 3.2.1. Class Adapter y Object Adapter 3.2.2. Wrapper (Envolvente)
3.3.

Motivacin. Para reutilizar una clase de una biblioteca aunque su interfaz no correspondiera exactamente con el que requiere una aplicacin concreta

Patrn Estructural Decorador


1. Objetivo del patrn Decorador El objetivo de este patrn es aadir responsabilidades a un objeto concreto de forma dinmica, cuando sea imposible la extensin de funcionalidad por herencia, por ser sta imprevisible en tipo y nmero.

- 40 -

2. Caso Practico: Problema de las Flores Veamos el siguiente caso. Supongamos que tenemos la siguiente clase: (Ver Figura 2).

Figura 2.
Como vemos, la clase FLOR consta de un mtodo que siempre ser utilizado por todas sus instancias y que realiza acciones propias de una flor. Pero supongamos que despus necesitamos un nuevo tipo de flor, una flor que necesite ser 'podada'. Entonces podemos crear una subclase denominada 'FLOR1,' de la siguiente manera: ( Figura 3)

Figura 3.
Pero ahora, nuevamente, la situacin nos presenta la necesidad de tener una flor que adems necesite ser 'Abonada.' Entonces dentro de nuestra jerarqua actual, podemos resolver este problema de varias maneras: (Ver Figura 4)
a.

Aumentar a la clase que ya tenemos, FLOR1, la nueva funcionalidad que se requiere, es decir, Abonar ();

b. Crear una subclase de la clase FLOR1 llamada FLOR2, de manera que sta contenga el mtodo Abonar (); c. Crear una subclase de la clase FLOR llamada FLOR2, y que sta contenga el mtodo Abonar ();

- 41 -

d. Agregar el mtodo Abonar () a la clase general FLOR, de manera que todas las flores puedan ser fertilizadas; Podramos simplificar el problema simplemente desplazando los mtodos Abonar() y Podar() a una sola clase FLOR, de manera que todas las flores puedan ser podadas y fertilizadas

Figura 4.
Entonces, segn las necesidades actuales, nos arriesgamos y escogemos la opcin y hacemos los cambios. Pero, Qu pasa si despus necesitamos tener ms flores con diferentes y nuevas funcionalidades? Tendramos que crear subclases otra vez? Pero segn el caso anterior Dnde creamos las subclases? Qu nivel jerrquico es mejor para la modificacin? Y despus, si necesitamos ms y ms funcionalidades, Cmo lo haramos? Cmo es que mi simple clase FLOR que se tena en un principio se volvi ms complicada?

- 42 -

3. Uso del patrn Decorador Tal vez la respuesta a las preguntas anteriores es usar el patrn Decorador. La principal diferencia entre usar subclases y el patrn Decorador es que con las subclases se trabaja directamente con la clase, en cambio con el patrn Decorador se modifican los objetos dinmicamente. Cuando se extiende una clase, los cambios hechos a las clases hijos sern afectados a todas las instancias de las clases hijos; sin embargo, con el patrn Decorador se aplican los cambios a cada objeto individual que se quiere cambiar. 4. Estructura del patrn Decorador

Figura 5.
A continuacin describiremos la estructura:

Componente: Clase abstracta comn a todas las clases susceptibles de ser ampliadas con el Decorador. ComponenteConcreto: Son las clases cuya funcionalidad se puede extender y en las que se delega en ltima instancia para realizar las operaciones propias de la clase. Decorador: Clase abstracta que declara la estructura comn a todos los Decoradores y declara (o implementa, segn sea el caso) la responsabilidad de mantener una referencia al objeto que se extiende. Es posible que sobrecargue todos los mtodos de la clase Componente con llamadas al componente concreto, de forma que aquellos mtodos cuya funcionalidad no se extiende simplemente llaman a los originales.

- 43 -

DecoradorConcreto1 y DecoradorConcreto2: Son clases concretas que heredan de Decorador e implementan las extensiones de funcionalidad de la clase original ComponenteConcreto.

Entonces, el diagrama de la segunda opcin presentada, aplicando el patrn Decorador al problema de las flores, es el siguiente:

Figura 6.

- 44 -

PATRONES DE COMPORTAMIENTOS
1. Nociones Un patrn comportamiento: Tiene que ver con la dimensin temporal Estudia las relaciones entre llamadas entre los diferentes objetos. Incide en facilidades para tiempo de ejecucin 2. Patrn Iterador

Aggregate +CreateIterator()

Iterator +First() +Next() +IsDone() +CurrentItem ()

ConcreteAggregate

ConcreteIterator

3. Patrn Memento

O r ig in a t o r

M e m e nto

Ca re ta k e r

+ me n e n to + S e tM e me n t o (m: M e me n to ) + G e tS t a te () + C re a te M e me n t o () + S e tS t a te ( )

- 45 -

4. Patrn Observador
+subject

Subject +Attach(o: Observer) +Detach(o: Observer) +Notify()

Observer +Update()

ConcreteSubject

ConcreteObserver

5. Patrn State
+state

Context +Request()

State +Handle()

ConcreteState

- 46 -

CALIDAD DE SISTEMAS
1.- CONCEPTOS DE CALIDAD Se define la calidad como una caracterstica o atributo de algo. Como un atributo de un elemento, la calidad se refiere a las caractersticas mensurables -cosas que se pueden comparar con estndares conocidos como longitud, color, propiedades elctricas, maleabilidad, etc. Sin embargo, el software en su gran extensin, como entidad intelectual, es ms difcil de caracterizar que los objetos fsicos. La calidad de diseo se refiere a las caractersticas que especifican los ingenieros de software para un elemento. El grado de materiales, tolerancias y las especificaciones del rendimiento contribuyen a la calidad del diseo. Cuando se utilizan materiales de alto grado y se especifican tolerancias ms estrictas y niveles ms altos de rendimiento, la calidad de diseo de un producto aumenta, si el producto se fabrica de acuerdo con las especificaciones. La calidad de concordancia es el grado de cumplimiento de las especificaciones de diseo durante su realizacin. Una vez ms, cuanto mayor sea el grado de cumplimento, ms alto ser el nivel de calidad de concordancia. En el desarrollo del software, la calidad de diseo comprende los requisitos, especificaciones y el diseo del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementacin. Si la implementacin sigue el diseo, y el sistema resultante cumple los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta. 2. CONTROL DE CALIDAD El control de cambios puede equipararse al control de calidad. Pero, cmo se logra el control de calidad? El control de calidad es una serie de inspecciones, revisiones y pruebas utilizados a lo largo del proceso del software para asegurar que cada producto cumple con los requisitos que le han sido asignados. El control de calidad incluye un bucle de realimentacin (feedback) del proceso que cre el producto. La combinacin de medicin y realimentacin permite afinar el proceso cuando los productos de trabajo creados fallan al cumplir sus especificaciones. Este enfoque ve el control de calidad como parte del proceso de fabricacin. 3. Qu es el control de calidad del software? Las actividades de control de calidad pueden ser manuales, completamente automticas o una combinacin de herramientas automticas e interaccin humana. Un concepto clave del control de calidad es que se hayan definido todos los productos y las especificaciones mensurables en las que se puedan comparar los resultados de cada proceso. El bucle de realimentacin es esencial para reducir los defectos producidos. - 47 -

4. Garanta de calidad La garanta de calidad consiste en la auditora y las funciones de informacin de la gestin. El objetivo de la garanta de calidad es proporcionar la gestin para informar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visin ms profunda y segura de que la calidad del producto est cumpliendo sus objetivos. Por supuesto, si los datos proporcionados mediante la garanta de calidad identifican problemas, es responsabilidad de la gestin afrontar los problemas y aplicar los recursos necesarios para resolver aspectos de calidad. 5. Coste de calidad El coste de calidad incluye todos los costes acarreados en la bsqueda de la calidad o en las actividades relacionadas en la obtencin de la calidad. Se realizan estudios sobre el coste de calidad para proporcionar una lnea base del coste actual de calidad, para identificar oportunidades de reducir este coste, y para proporcionar una base normalizada de comparacin. La base de normalizacin siempre tiene un precio. Una vez que se han normalizado los costes de calidad sobre un precio base, tenemos los datos necesarios para evaluar el lugar en donde hay oportunidades de mejorar nuestros procesos. Es ms, podemos evaluar cmo afectan los cambios en trminos de dinero. Los costes de calidad se pueden dividir en costes asociados con la prevencin, la evaluacin y los fallos. Entre los costes de prevencin se incluyen: planificacin de la calidad, revisiones tcnicas formales, equipo de pruebas, formacin entre los costos de evaluacin se incluyen actividades para tener una visin ms profunda de la condicin del producto la primera vez a travs de cada proceso. Los costos de fallos son los costes que desapareceran si no surgieran defectos antes del envo de un producto a los clientes. Estos costes se pueden subdividir en costes de fallos internos y costes de fallos externos. Los internos se producen cuando se detecta un error en el producto antes de su envo. Entre estos se incluyen: retrabajo (revisin), reparacin, anlisis de las modalidades de fallos. Los costes de fallos externos son los que se asocian a los defectos encontrados una vez enviado el producto al cliente. A continuacin se incluyen algunos ejemplos de costes de fallos externos: resolucin de quejas, devolucin y sustitucin de productos, soporte de lnea de ayuda, trabajo de garanta.

- 48 -

6. GARANTIA DE CALIDAD DE SOFTWARE Actividades de SQA La garanta de calidad del software comprende una gran variedad de tareas, asociadas con dos constitutivos diferentes : Los ingenieros de software que realizan trabajo tcnico y un grupo de SQA que tiene la responsabilidad de la Planificacin de garanta de calidad, supervisin, mantenimiento de registros, anlisis e informes. Los ingenieros de software afrontan la calidad (y realizan garanta de calidad) aplicando mtodos tcnicos slidos y medidas, realizando revisiones tcnicas formales y llevando a cabo pruebas de software bien planificadas. stas son las actividades que realizan (o facilitan) un grupo independiente de SQA: Establecimiento de un plan de SQA para un proyecto.El plan se desarrolla durante la planificacin del proyecto y es revisado por todas las partes interesadas. Las actividades de garanta de calidad realizadas por el equipo de ingeniera del software y el grupo SQA son gobernadas por el plan. El plan identifica: evaluaciones a realizar, auditoras y revisiones a realizar, estndares que se pueden aplicar al proyecto, procedimientos para informacin y seguimiento de errores, documentos producidos por el grupo SQA, realimentacin de informacin proporcionada al equipo de proyecto del software.

Participacin en el desarrollo de la descripcin del proceso de software del proyecto. El equipo de ingeniera del software selecciona un proceso para el trabajo que se va a realizar. El grupo de SQA revisa la descripcin del proceso para ajustarse a la poltica de la empresa, los estndares internos del software, los estndares impuestos externamente (por ejemplo: 1SO 9001), y a otras partes del plan de proyecto del software. Revisin de las actividades de ingeniera del software para verificar su ajuste al proceso de software definido. El grupo de SQA identifica, documenta y sigue la pista de las desviaciones desde el proceso y verifica que se han hecho las correcciones. Auditora de los productos de software designados para verificar el ajuste con los definidos como parte del proceso del software. El grupo de SQA revisa los productos seleccionados; identifica, documenta y sigue la pista de las desviaciones; verifica que se han hecho las correcciones, e informa peridicamente de los resultados de su trabajo al gestor del proyecto. - 49 -

Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido. Las desviaciones se pueden encontrar en el plan del proyecto, en la descripcin del proceso, en los estndares aplicables o en los productos tcnicos. Registrar lo que no se ajuste a los requisitos e informar a sus superiores. Los elementos que no se ajustan a los requisitos estn bajo seguimiento hasta que se resuelven.
7. Herramientas CASE

Son un conjunto de mtodos, utilidades y tcnicas que facilitan la automatizacin del ciclo de vida del desarrollo de sistemas de informacin, completamente o en alguna de sus fases. El empleo de herramientas Case permiten integrar el proceso de ciclo de vida: Anlisis de datos y procesos integrados mediante un repositorio. Generacin de interfaces entre el anlisis y el diseo. Generacin del cdigo a partir del diseo. Control de mantenimiento. Actualmente, la tendencia en el desarrollo de software est enfocada hacia las microcomputadoras como plataformas de ingeniera de software, que se interconectan mediante redes para que puedan comunicarse de forma efectiva. La base de datos del proyecto (tambin denominada biblioteca del proyecto o depsito de software), est disponible a travs de un servidor de archivos en red que es accesible desde todas las estaciones de trabajo. Un sistema operativo que gestiona el hardware, la red y las herramientas, mantiene todo el entorno unido.

La mayora de las herramientas Case no han sido construidas utilizando todos los bloques componentes. Muchas de stas son soluciones puntuales, esto es, una herramienta se utiliza como ayuda en una actividad concreta de ingeniera - 50 -

de software (por ejemplo: modelizacin del anlisis), pero no se comunica directamente con otras herramientas, porque no est unida a una base de datos de proyectos. Aunque esta situacin no es la ideal, una herramienta Case puede ser utilizada eficientemente, an siendo una solucin puntual.
8.

Tipos de Case No existe una nica clasificacin de herramientas CASE y, en ocasiones, es difcil incluirlas en una clase determinada. Podran clasificarse atendiendo a: Las plataformas que soportan. Las fases del ciclo de vida del desarrollo de sistemas que cubren. La arquitectura de las aplicaciones que producen. Su funcionalidad.

Las herramientas CASE, en funcin de las fases del ciclo de vida abarcadas, se pueden agrupar de la forma siguiente: Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas tambin CASE workbench.

Herramienta(s) que comprende(n) alguna(s) fase(s) del ciclo de vida de desarrollo de software:

Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o front-end, orientadas a la automatizacin y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: anlisis y diseo. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) o back-end, dirigidas a las ltimas fases del desarrollo: construccin e implantacin.

Juegos de herramientas o toolkits, son el tipo ms simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontraran las herramientas de reingeniera, orientadas a la fase de mantenimiento. Las herramientas I-CASE se basan en una metodologa. Tienen un repositorio y aportan tcnicas estructuradas para todas las fases del ciclo de vida. Una estrategia posible es utilizar una U-CASE para anlisis y diseo, combinada con otras herramientas ms modernas para las fases de construccin y pruebas. En este caso, habra que vigilar cuidadosamente la integracin entre las distintas herramientas.

- 51 -

Otra posible clasificacin, utilizando la funcionalidad como criterio principal, es la siguiente: Herramientas de planificacin de sistemas de gestin. Sirven para modelizar los requisitos de informacin estratgica de una organizacin. Proporcionan un "metamodelo" del cual se pueden obtener sistemas de informacin especficos. Su objetivo principal es ayudar a comprender mejor cmo se mueve la informacin entre las distintas unidades organizativas. Estas herramientas proporcionan una ayuda importante cuando se disean nuevas estrategias para los sistemas de informacin y cuando los mtodos y sistemas actuales no satisfacen las necesidades de la organizacin. Herramientas de anlisis y diseo. Permiten al desarrollador crear un modelo del sistema que se va a construir y tambin la evaluacin de la validez y consistencia de este modelo. Proporcionan un grado de confianza en la representacin del anlisis y ayudan a eliminar errores con anticipacin. Se tienen:

Herramientas de anlisis y diseo (Modelamiento). Herramientas de creacin de prototipos y de simulacin. Herramientas para el diseo y desarrollo de interfaces. Mquinas de anlisis y diseo (Modelamiento).

Herramientas de programacin. Se engloban aqu los compiladores, los editores y los depuradores de los lenguajes de programacin convencionales. Ejemplos de estas herramientas son:

Herramientas de codificacin convencionales. Herramientas de codificacin de cuarta generacin. Herramientas de programacin orientadas a los objetos.

Herramientas de integracin y prueba: Sirven de ayuda a la adquisicin, medicin, simulacin y prueba de los equipos lgicos desarrollados. Entre las ms utilizadas estn: Herramientas de anlisis esttico. Herramientas de codificacin de cuarta generacin. - 52 -

Herramientas de programacin orientadas a los objetos.

Herramientas de gestin de prototipos. Los prototipos son utilizados ampliamente en el desarrollo de aplicaciones, para la evaluacin de especificaciones de un sistema de informacin, o para un mejor entendimiento de cmo los requisitos de un sistema de informacin se ajustan a los objetivos perseguidos. Herramientas de mantenimiento: La categora de herramientas de mantenimiento se puede subdividir en:

Herramientas de ingeniera inversa. Herramientas de reestructuracin y anlisis de cdigo. Herramientas de reingeniera. Herramientas de gestin de proyectos. La mayora de las herramientas CASE de gestin de proyectos, se centran en un elemento especfico de la gestin del proyecto, en lugar de proporcionar un soporte global para la actividad de gestin. Utilizando un conjunto seleccionado de las mismas se puede: realizar estimaciones de esfuerzo, coste y duracin, hacer un seguimiento continuo del proyecto, estimar la productividad y la calidad, etc. Existen tambin herramientas que permiten al comprador del desarrollo de un sistema, hacer un seguimiento que va desde los requisitos del pliego de prescripciones tcnicas inicial, hasta el trabajo de desarrollo que convierte estos requisitos en un producto final. Se incluyen dentro de las herramientas de control de proyectos las siguientes: Herramientas de planificacin de proyectos. Herramientas de seguimiento de requisitos. Herramientas de gestin y medida.

Herramientas de soporte. Se engloban en esta categora las herramientas que recogen las actividades aplicables en todo el proceso de desarrollo, como las que se relacionan a continuacin: Herramientas de documentacin. Herramientas para software de sistemas. Herramientas de control de calidad.

9. Opciones de Integracin Las herramientas Case pueden ser integradas de muchas formas. En un extremo se utiliza una herramienta CASE de forma aislada. Se crea un nmero limitado de elementos de configuracin de software (documentos, programas o datos) que se manipulan mediante una nica herramienta y cuya salida tiene el formato de copia de pantalla y/o documentacin grfica. En cierto sentido, el enlace con el resto del entorno de desarrollo se realiza mediante copias en papel que gestiona el ingeniero. Pocas herramientas CASE se utilizan en forma aislada. Se suele disponer de las siguientes opciones: - 53 -

- 54 -

10. Niveles de Integracin CASE: a) Intercambio de datos, b) Acceso comn a herramientas, c) Integracin de datos, d) Integracin total. a) Intercambio de datos. La mayora de las herramientas permiten exportar datos en forma de archivo sin estructura con un formato conocido. Esto permite un intercambio de datos punto a punto entre las distintas herramientas CASE, utilizando normalmente un "filtro" de transmisin intermedio. La desventaja del intercambio de datos punto a punto est en que, a menudo, slo parte de los datos exportados es utilizable por la herramienta receptora, ya que no fue diseada para ser totalmente compatible. Adems, a medida que evoluciona el software, la necesidad de transferir archivos cada vez que se hace un cambio pequeo puede llevar mucho tiempo. Las versiones pueden quedar "desfasadas" fcilmente, perdindose la posibilidad de transferencia, la cual suele ser en un nico sentido. No hay posibilidad de que los cambios se reflejen en ambos sentidos y, es difcil hacer comprobaciones cruzadas de documentos y mantener la integridad de la configuracin a travs de las distintas herramientas que se estn utilizando. b) Acceso comn a herramientas. Permite al usuario utilizar distintas herramientas de forma similar, por ejemplo a travs de un men desplegable del gestor de ventanas del sistema operativo. En un entorno multitarea, un usuario podra abrir simultneamente varias herramientas, coordinando manualmente sus entradas y comparando las representaciones de diseo a medida que evolucionan. Por ejemplo, el usuario podra visualizar un diagrama de flujo de datos, un diagrama de estructura , un diccionario de datos y un segmento de cdigo fuente, todos mantenidos por diferentes herramientas. En estos entornos, el intercambio de datos de herramienta a herramienta podra simplificarse llamando al procedimiento de traduccin a travs de un simple men o de la seleccin de una macro. No es la opcin ms adecuada. - 55 -

c) Integracin de Datos: c1) Gestin comn de datos. Los datos de distintas herramientas se pueden mantener en una nica base de datos lgica, que puede estar fsicamente centralizada o distribuida. Hay una modalidad de fusin que permite combinar el trabajo de varias personas trabajando en diferentes partes de una aplicacin. Aunque los datos generados por las distintas herramientas se gestionan de forma conjunta en el nivel de gestin de datos comunes, las herramientas no conocen de forma explcita las estructuras de datos y la semntica de representacin del diseo de las dems. Consecuentemente, se requiere una etapa de traduccin (normalmente ejecutada manualmente) para permitir que una herramienta utilice la salida generada por otra. c2) Datos compartidos. Las herramientas del nivel de datos compartidos tienen estructuras de datos y semntica compatible, pudiendo intercambiar datos sin necesidad de una etapa de traduccin. Cada herramienta se disea para ser compatible con las dems. Por esta razn, la mayor parte del intercambio de datos se da entre herramientas de un nico fabricante o en casos en los que se han establecido relaciones estratgicas, entre distintos fabricantes para generar un conjunto de datos integrado, a veces, a peticin de clientes importantes. c3) Interoperabilidad. Las herramientas que combinan las caractersticas de acceso comn y la capacidad de compartir datos, tienen la capacidad de interoperacin. Esto representa el mayor nivel de integracin entre herramientas diferentes. Sin embargo, hay otras propiedades del entorno global CASE que se pueden aadir para mejorar la efectividad del proceso de desarrollo de software. d) Integracin Total Para alcanzar la integracin total del entorno CASE se necesitan dos caractersticas ms: gestin de metadatos y capacidad de control.

- 56 -