Manual Cursos Seminario de Tesis 01-04-11

5/10/2018 Manual Cursos Seminario de Tesis 01-04-11 - slidepdf.com

http://slidepdf.com/reader/full/manual-cursos-seminario-de-tesis-01-04-11 1/56

ESTRUCTURA DE LA TESIS

1.

Aspecto Formal• Tamaño y Tipo De Papel .- Se utilizará papel bond de formato A4, de80grs. Y de color blanco. Se escribe en una sola cara, a doble espacio,evitando errores.El Tipo y Tamaño de Letra es Arial : 12.

• Márgenes.- Se debe respetar los cuatro márgenes : 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.

•

Líneas por páginas.- Respetando estos márgenes, la página contendrá 25líneas a doble espacio, para el cuerpo del texto.• Numeración de la página.- Todas las páginas del informe se cuentan,

para efectos de paginación. Esta pude ser colocada en la parte superior, alcentro o al límite del margen lateral derecho, o también en la parte inferior,al límite del margen derecho. Las páginas del texto se enumeran connúmeros arábigos.Las páginas de portada, dedicatoria, prólogo e introducción se numeran

independientemente del texto con números romanos.

2. Secciones o Partes

Las secciones o partes del Proyecto : Portada, Dedicatoria,Agradecimiento, Prólogo, Introducción, Indice, Capítulos I, II,III,...,Conclusiones, Recomendaciones, Bibliografía, Glosario de Términos,Anexos.

• Portada.- Debe contener datos del año declarado, logo de lainstitución, título del proyecto, datos de los integrantes, mes y año depresentación.• Dedicatoria y Agradecimiento.- Reconocimiento a alguna personao institución. Suele colocarse a la altura de la octava línea, próxima almargen lateral derecho. No debe ser muy extensa ni incluir un excesivonúmero de nombres.• Prólogo.- Presentación del Proyecto hecha por otra persona. Secoloca la palabra “Prólogo” en la séptima línea, debidamente centrada, enmayúsculas y subrayada.• Introducción.- Se coloca la palabra “Introducción” en la séptimalínea, debidamente centrada, en mayúsculas y subrayada. La introduccióndebe presentar de forma clara y resumida una visión general de lo quetrata la investigación.• Capítulos y Subcapítulos.- Debe empezar con la palabracorrespondiente, centrada, escrita con mayúsculas en la séptima línea. El

título se escribirá con mayúscula, centrado y subrayado.- 1 -



• Estilo de la redacción.-Deberá ser formal, en primera persona delplural o en impersonal, tercera persona del singular. Deberá ser directo,adecuado al objeto de la investigación.• Citas .- Estas pueden ser textuales e ideográficas. En las primeras,se cita textualmente al autor y en las segundas, el investigador las presentacon sus propias palabras. Las citas permiten al investigador corroborar algunas de sus afirmaciones. En este caso, la cita deberá seguir algunaspautas. El fragmento que se cita textualmente debe escribirse entrecomillas y dentro del formato normal de cada párrafo, si no excede doslíneas; si es mayor, debe de escribirse en espacio simple toda la cita,empezando a quince espacios para la primera línea y a diez espacios delmargen izquierdo y a dos espacios del párrafo anterior. Al concluir cadacita, debe colocarse la numeración correlativa de notas entre paréntesis.

• Notas al capítulo.- En hoja aparte y al final de cada capítulo o de todos loscapítulos, se comenzará en la séptima línea con la palabra “Notas alCapítulo” centrada y escrita con mayúsculas y subrayada. El texto secomenzará a tres espacios simples dejando entre nota y nota un espaciosimple en blanco. La numeración debe ser correlativa y entre paréntesis.

• Conclusiones y Recomendaciones.- En la séptima línea, se pondrá lapalabra “Conclusiones”, centrada con mayúsculas y subrayada. Despuésde tres espacios simples se escribirá las conclusiones a doble espacio.Debe ir numeradas. Son la síntesis del trabajo. Proporcionan un resumensintético pero completo de la argumentación, las pruebas y los ejemplosconsignados en el trabajo.

•

Bibliografía.- En la séptima línea, se pondrá la palabra “Bibliografía”,escrita con mayúsculas, centrada y subrayada.• Glosario de Términos .- Definición de nuevos términos utilizados en la

tesis.• Anexos (opcional) .- Esta sección puede incluir todo el material

suplementario. Cada uno de los materiales presentados en esta seccióndebe tener una numeración, un título y la indicación de la fuente.

3. Estructura del Proy

ecto- 2 -



• Portada• Dedicatoria• Agradecimiento• Prólogo• Introducción

CAPÍTULO I : ANTECEDENTES DE LA ORGANIZACIÓN1.1. Datos Generales

• Nombre o Razón Social• Rubro• Dirección, Distrito• Teléfono, Fax, e-mail• Ubicación Geográfica

1.2. Productos y/o Servicios que Comercializan1.3. Principales Clientes1.4. Reseña Histórica1.5. Planeamiento Estratégico Empresarial

1.5.1 Definición del Horizonte de Tiempo (2 Años).1.5.2 Principios Corporativos1.5.3 Diagnóstico Estratégico

• Análisis FODA1.5.4 Direccionamiento Estratégico

•

Misión• Visión• Objetivos Estratégicos

1.5.5 Proyección Estratégica• Áreas Estratégicas• Proyectos Estratégicos

1.5.6 Plan Operativo• Estrategias• Planes de Acción

1.5.7 Monitoreo Estratégico1.6. Estructura Organizacional

1.6.1. Organigrama1.6.2. Manual de Funciones y Procedimientos1.6.3. Flujogramas de Procesos

CAPÍTULO II : ESTUDIO PRELIMINAR2.1. Características del Proyecto

2.1.1. Objetivos del Proyecto• Objetivo General• Objetivos Específicos

2.1.2. Planteamiento del Problema

- 3 -



2.1.3. Alcances del Proyecto

2.2. Estudio de Factibilidad2.2.1. Factibilidad Técnica

2.2.2. Factibilidad Económica2.2.3. Factibilidad Operativa2.2.4. Análisis Costo/Beneficio

2.3. Programación del Proyecto2.3.1. Equipo de Trabajo2.3.2. Planeación de Actividades y Tiempos2.3.3. Diagrama de Gantt

2.4. Metodología y Herramientas2.4.1. Metodología de Desarrollo2.4.2. Herramientas a Utilizar

CAPÍTULO III : DESCRIPCION DEL SISTEMA ACTUAL3.1. Información del Sistema Actual

3.1.1. Entrevistas. Detalles e Informes3.1.2. Cuestionarios. Detalles e Informes3.1.3. Análisis de Documentos

3.1.3.1 Identificación y Funciones3.1.3.2 Formato. Diseño.

3.1.4. Observación. 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 Negocio3.2.1.2. Descripción de Casos de Uso del Negocio3.1.3.3 Especificación de Reglas del Negocio

3.2.2. Modelo de Objetos del Dominio3.2.3. Modelo de Objetos de Negocios

3.3. Modelado del Sistema Actual3.3.1. Diagrama de Casos de Uso del Sistema Actual3.3.2. Diagrama de Actividades del Sistema Actual

CAPÍTULO IV : MODELADO DEL SISTEMA PROPUESTO4.1. Información del Sistema Propuesto

4.1.1. Entrevistas. Detalles e Informes4.1.2. Cuestionarios. Detalles e Informes4.1.3. Análisis de Nuevos Documentos Propuestos

4.1.3.1. Identificación y Funciones4.1.3.2. Formato. Diseño de Nuevos Documentos.

4.1.4. Observación. Detalle e Informe.4.2. Modelado del Sistema Propuesto

4.2.1. Modelado de Casos de Uso del Sistema Propuesto4.2.1.1. Diagrama de Casos de Uso del Sistema4.2.1.2. Descripción de Casos de Uso del Sistema

4.2.2. Diagrama de Clases del Sistema Propuesto

- 4 -



4.2.3. Diagrama e Interacción del Sistema Propuesto

4.2.3.1. Diagrama de Secuencia4.2.3.2. Diagrama de Colaboración

4.2.4. Diagrama e Actividades del Sistema Propuesto

CAPÍTULO V : DISEÑO DEL SISTEMA5.1. Diseño de Interfaces

5.1.1. Interfaz de Seguridad5.1.2. Interfaces de Entrada5.1.3. Interfaces de Salida

5.2. Diseño de Base de Datos.5.2.1. Modelado de Datos

5.2.1.1. Diseño Conceptual5.2.1.2. Diseño Lógico5.2.1.3. Diseño Físico

5.2.2. Diseño de la Base de Datos.5.3. Diseño de Reportes

CAPÍTULO VI : IMPLEMENTACIÓN DEL SISTEMA6.1. Plan de Pruebas del Sistema6.2. Instalación del Sistema

6.2.1. Requisitos de Instalación6.2.2. Modo de Instalación

6.3. Diagrama de Componentes

6.4. Diagrama de Despliegue

CAPÍTULO VII : MANUAL DE USUARIO7.1. Introducción7.2. Objetivos7.3. Especificaciones Técnicas

7.3.1 Hardware7.3.2 Software

7.4. Ingreso al Sistema7.5. Operación del Sistema7.6. Glosario de Términos

7.7 Índice

• Conclusiones• Recomendaciones• Bibliografía• Glosario de Términos• Anexos

Documentación Carta de Presentación

- 5 -



FUNDAMENTOS DE LOS SISTEMAS WEB

1. Servicios de InternetUn servicio Web (en inglés Web service) es una colección de protocolos yestándares que sirven para intercambiar datos entre aplicaciones

• Accesible desde cualquier aplicación• Por cualquier lenguaje de programación• Desde cualquier plataforma• Usando estándares abiertos

2. Protocolos conocidos• XML: Es el formato estándar 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 también pueden enviarse de una

aplicación a otra mediante protocolos normales ya bien conocidos.• WSDL: Es el lenguaje de la interfaz pública para los servicios Web.• UDDI: Protocolo para publicar la información de los servicios Web.• WS-Security: Protocolo de seguridad aceptado como estándar por OASIS

3. Ventajas de los servicios Web• Aportan interoperabilidad entre aplicaciones de software• Los servicios Web fomentan los estándares y protocolos basados en texto

(más 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 compañías

y varios software• Permiten la interoperabilidad entre plataformas de distintos fabricantes por

medio de protocolos estándar.

4. Inconvenientes de los servicios Web• Para realizar transacciones no pueden compararse en su grado de

desarrollo con los estándares abiertos de computación distribuida como

CORBA.• Su rendimiento es bajo si se compara con otros modelos de computación

distribuida, tales como RMI o CORBA (XML no está diseñado para elrendimiento)

• Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas enfirewalls cuyas reglas tratan de bloquear o auditar la comunicación entreprogramas a ambos lados de la barrera.

• Existe poca información de servicios Web para algunos lenguajes deprogramación

5. Razones para el uso de servicios Web- 6 -



DatosLógica de negocio

Interface de usuario

• La principal razón 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 aplicación 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 código abierto)• Microsoft .NET

• Novell exteNd (basado en la plataforma J2EE)• WebLogic• WebSphere

7. Tipos de Arquitecturas en tecnologías cliente-servidor • Aplicaciones mono-capa:

Tanto los datos de aplicación como la interfaz como la lógica de modeloresiden en una misma identidad.

• Aplicaciones Cliente – Servidor 2 capas- 7 -



Se separan 2 de las tres capas. El cliente aún puede integrar parte dela funcionalidad del sistema.

• Aplicaciones Cliente – Servidor 3 capasCreamos un cliente que carece de toda lógica de negocio y apenasofrece alguna funcionalidad más que la de visión y petición de datos.

8. Características de las capas

Funcionalidad ParcialDatos

Lógica de negocioInterface de usuario

Lógica de negocio

Interface de usuario

Funcionalidad Parcial

- 8 -

Datos



Las diferentes capas suelen ser

– Capa 1 : Cliente de aplicación• Ejemplos: Set-top box, navegador Web

– Capa 2 : Servidor de Aplicaciones• Ejemplo: Servidor Tomcat con servlet’s

– Capa 3 : Servidor de Datos• Ejemplo: Base de datos, servidor SMTP…

9. Esquema de la arquitecturaSe representa de la siguiente manera

MODELADO DE APLICACIONES CLIENTE / SERVIDOR

MHProjectServer

Set-TopBox

Servidor Mail

PeticiónHTTP

RespuestaHTTP

RespuestaSMTP

PeticiónSMTP

Servidor deAplicaciones

ClienteServidor de Datos

<http 1.0><to> <from><body>

<http 1.0><confirmación>

<smtp><HELO><Mail From>

<smtp><HELO><OK>

- 9 -



1. Arquitectura de tres niveles

La llamada “Arquitectura en Tres Niveles”, es la más común en sistemas de

información, que además de tener una interfaz de usuario contemplan lapersistencia de los datos.Una descripción de los tres niveles sería la siguiente:

Nivel 1: Presentación – ventanas, informes, etc.Nivel 2: Lógica de la Aplicación – tareas y reglas que gobiernan el proceso.Nivel 3: Almacenamiento – mecanismo de almacenamiento.

2. Arquitectura de tres niveles orientadas a objetos Descomposición del nivel de lógica de la aplicación. En el diseño

orientado a objetos, el nivel de lógica de la aplicación se descompone ensubniveles que son los siguientes:

Objetos del Dominio: son clases que representan objetos del dominio.Por ejemplo en un problema de ventas, una “Venta” sería un objeto deldominio.

Servicios: se hace referencia a funciones de interacción con la base de

datos, informes, comunicaciones, seguridad, etc.

3. Arquitectura MULTI-nivelLa arquitectura de tres niveles puede pasar a llamarse de Múltiples Niveles sitenemos en cuenta el hecho de que todos los niveles de la arquitectura detres niveles se pueden descomponer cada uno de ellos cada vez más.

Por ejemplo el nivel de Servicios, se puede descomponer en servicios de altoy de bajo nivel, identificando como de alto nivel los servicios de generación deinformes 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 diferentesniveles es múltiple:

Separación de la lógica de la aplicación en componentes separadosque sean más fácilmente reutilizables.

Distribución de niveles en diferentes nodos físicos de computación Reparto de recursos humanos en diferentes niveles de la arquitectura.

4. PaquetesLa forma que tiene UML de agrupar elementos en subsistemas es a través deluso de Paquetes, pudiéndose anidar los paquetes formando jerarquías depaquetes. 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.

Gráficamente un paquete viene representado como se indica en la figura.

En la siguiente figura vemos cómo se representa la arquitectura del sistema,con la notación de paquetes.

- 11 -



5. Identificación de Paquetes

Vamos a definir una serie de reglas que nos pueden ser de utilidad a la horade 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 cohesión, es decir deben estar muy relacionados. Los elementos que estén en diferentes paquetes deben tener poca

relación, es decir deben colaborar lo menos posible.

- 12 -



ARQUITECTURA MULTICAPAS

1. Arquitectura multicapas orientadas a objetosDescomposición de la capa de la lógica de aplicaciones:

• Objetos del dominio.• Servicios.

2. Motivos para usar arquitectura multicapas• Aislamiento de la lógica de aplicaciones en componentes independientes

susceptibles de reutilizarse después en otros sistemas.

• Distribución de las capas en varios nodos físicos de computo y en variosprocesos. Esto puede mejorar el desempeño, la coordinación y elcompartir la información en un sistema de cliente-servidor.

• Asignación de los diseñadores para que construyan determinadas capas;por ejemplo, un equipo que trabaje exclusivamente en la capa depresentación. Y así se brinda soporte a los conocimientos especializadosen las habilidades de desarrollo y también a la capacidad de realizar actividades simultaneas en equipo.

Presentación TPDVApplet

Lógica de

aplicaciones

Pago

Interfaz de la

Base de datos

Venta

Generador de

reportes

Conceptos del

dominio

Servicios

Almacenamiento Base de

Datos

- 13 -



3. Representación de la Arquitectura con Paquetes UML

4. Ejemplo de paquetes y de dependencias

5. Identificación de los Paquetes

Paquetes en UML

Conceptos de dominio

VentasElementosbásicos

Almacenamiento Base de datos

PresentaciónPresentación

Lógica de

aplicaciones

Dominio

Servicios

Capa deservicios

de alto nivel

orientada a

objetos

Capa de

servicios

de bajo nivel(orientados a

objetos y noorientados a

objetos)

Reportes

Presentación1

Dominio

Interfaz de base

de datos relacional Comunicación

Interfaz de base

de datos

orientada

a objetos

Esquemas de aplicaciones

y bibliotecas de soportes2

Base de datos

relacional

Base de datos

orientada a

objetos

Ejemplos:1. Applets de Java,

documentos y vistas MFCVisualParts de VisualAge

2.JDK, MFC,STL

- 14 -



Agrupe los elementos en 1 paquete así:

Agrupe los elementos para ofrecer en un paquete un servicio común (o una

familia de servicios relacionados), con un nivel relativamente alto deacoplamiento y colaboración.

En cierto nivel de abstracción, se vera el paquete como muy cohesivo (tieneresponsabilidades estrechamente relacionadas).

En cambio, habrá relativamente bajo acoplamiento y colaboración entre loselementos de diferentes paquetes.

EXTENSIÓN DE UML

Dominio

Elementos básicos Ventas Productos

Servicios

Interfaz de base

de datos relacionalComunicación

Interfaz de base

de datos orientadaa objetos

Reportes

Particiones horizontales

- 15 -



1. Descripción

Esta extensión de UML define un conjunto de estereotipos, valores

etiquetados y restricciones que nos permiten modelar aplicaciones Web. Losestereotipos y restricciones se aplican a ciertos componentes que sonparticulares de sistemas Web y nos permiten representarlos en el mismomodelo, y en los mismos diagramas que describen el resto del sistema.

El elemento principal específico de aplicaciones Web es la página Web. Hayvarios estereotipos que pueden ser aplicados a una página Web, y otrosadicionales que son asignados a otros elementos de HTML y que representancomponentes arquitecturalmente significativos del sistema (frames,formularios...).La mayoría de los valores etiquetados mencionados en esta extensiónpueden ser considerados como una presentación más bien que estructurales.

2. Estereotipos1.1.Server Page (Página servidor)

Clase Metamodelo: ClaseDescripción: Una página de servidor representa una página Web quetiene scripts que ejecutados por el servidor. Estos scritps interactúan conrecursos del servidor como bases de datos, lógica de negocio y sistemasexternos. Las operaciones del objeto representan las funciones en elscript, y sus atributos representan las variables que son visibles en elámbito de la página (accesibles por todas las funciones de la página).

Restricciones: La página de servidor sólo puede tener relaciones conobjetos localizados en el servidor.Valores Etiquetados: Motor del Script – Tanto el lenguaje como el motor que se debería usarse para ejecutar o interpretar esta página (JavaScript,VBScript, Perl, etc.)

1.2.Server Cliente

- 16 -



Clase del metamodelo: ClaseDescripción: Una instancia de una página cliente es una página Web conformato HTML y es una mezcla de datos, presentación e incluso lógica.Las páginas clientes son representadas por los navegadores clientes, y

pueden contener scripts que son interpretados por el navegador. Lasfunciones de la página cliente mapean las funciones en las etiquetasscript de la página. Los atributos de la página cliente mapean lasvariables declaradas en las etiquetas script de la página, que sonaccesibles por una función en la página (con ámbito de página).Laspáginas cliente pueden tener asociaciones con otras páginas cliente oservidor.Restricciones: NoValores Etiquetados: EtiquetaTítulo – El título de la página lo muestra elnavegador EtiquetaBase – El URL base por referencia de URLs relativos.

EtiquetaCuepo – El conjunto de atributos para la etiqueta <cuerpo> queestablecen el color de fondo y los atributos del texto por defecto.

1.3. Form

Clase del metamodelo: ClaseDescripción: Una clase estereotipada como «form» es una colección decampos de entrada que forman parte de una página cliente. Una claseform se mapea directamente con la etiqueta HTML form. Los atributos deest clase representan los campos de entrada del formulario HTML (inputboxes, text areas, radio buttons, check boxes, y campos hidden).Un «form» no tiene operaciones, por lo que no pueden ser encapsuladasen un formulario. Cualquier operación que interactúe con el formulario es

una propiedad de la página que contiene al formulario.- 17 -



Restricciones: NingunaValores Etiquetados: Method – el método usado para enviar datos alURL del action, puede tomar los valores GET o POST.

1.4.SubmitClase del metamodelo: AsociaciónDescripción: Una asociación “submit” es siempre entre un “form”(formulario) y una “server-page” (página servidor). Los formularios envíanlos valores de sus campos al servidor a través de páginas servidor paraprocesarlos. El servidor Web procesa la página servidor, la cual acepta yusa la información dentro del formulario enviadoRestricciones: NingunaValores Etiquetados: Parámetros – una lista de nombres de parámetrosque deberían ser pasados con la petición de la página enlazada

1.5.LinkClase del metamodelo: AsociaciónDescripción: Un link (enlace) es un puntero desde una página cliente aotra «Page». En un diagrama de clases, un link es una asociación entreuna «client page» y cualquier otra «client page» o una «server page».Una asociación Link se mapea diréctamente con la etiqueta HTML ancla.Restricciones: NingunaValores Etiquetados: Parámetros – una lista de nombres de parámetrosque deberían ser pasados con la petición de la página enlazada

1.6.BuildClase del metamodelo: AsociaciónDescripción: La relación «builds» es un tipo especial de relación que uneel vacío entre las páginas cliente y de servidor. Las páginas de servidor existen únicamente en el servidor. Son usadas para crear páginas cliente.La asociación «builds» identifica que página de servidor es responsablede la creación de una página cliente. Ésta es una relación direccional,pues la página cliente no tiene conocimiento de cómo ha sido creada. Unapágina de servidor puede crear múltiples páginas cliente, pero una páginacliente tan solo puede ser construida por una página de servidor.

Restricciones: NingunaValores Etiquetados: No

1.7.RedirectClase del metamodelo: Asociación.Descripción: Una relación «redirect» es una asociación unidireccionalcon otra página Web. Puede ser dirigida desde y hasta una página clienteo de servidor.Si la relación se origina desde una «server page» entonces indica que elprocesado de la página solicitada debe continuar en la otra página. Estoindica que la página destino siempre participa en la creación de la página

cliente. Esta relación no es completamente estructural, pues la invocación- 18 -



de una operación de redirección se debe hacer a través de programaciónen el código de la página origen.Si la relación se origina desde una «client page» entonces esto indica que

la página destino será automáticamente solicitada por el navegador, sin laparticipación activa del usuario. Se puede especificar un tiempo dedemora (en segundos) antes de que la segunda página sea solicitada. Eluso de la redirección se corresponde con la etiqueta META y HTTP-EQUIV el valor de "Refresh".

Valores Etiquetados: Demora – Cantidad de tiempo que una páginacliente debería esperar para ser redirigida a la siguiente página. Este valor se corresponde con el atributo Content de la etiqueta Meta.

1.8. Input ElementClase del Metamodelo: AtributoDescripción: Un Input Element es un atributo de un objeto«Form». Semapea directamente con la etiqueta HTML <input>. Este atributo es usadopara introducir una palabra o una línea de texto. Los Valores Etiquetadosasociados con este atributo estereotipado se corresponden con losatributos de la etiqueta <input>. Para completar los valores requeridos por la etiqueta HTML; el nombre del atributo se usa como el nombre de laetiqueta <input>, y el valor inicial del atributo es el valor de la etiqueta.Restricciones: NingunaValores Etiquetados: Type – El tipo del control input puede ser {Text,

Number, Password, Checkbox, Radio, Submit, Reset}.Size – Específica la longitud del área que aparece en pantalla, encaracteres.Maxlength – El máximo número de caracteres que el usuario puedeintroducir.

1.9.Select ElementClase del Metamodelo: AtributoDescripción: Un control input usado en los formularios. Este controlpermite al usuario seleccionar uno o más elementos de una lista. Lamayoría de los navegadores representan este control como un combo o

un list box.Restricciones: NingunaValores Etiquetados: Size – Especifica cuantos campos se muestran almismo tiempo.Multiple– Booleano que indica puede ser seleccionado múltiples camposde la lista.Text Area Element

Clase del Metamodelo: AtributoDescripción: Un control input usado en los formularios que permiteintroducir múltiples líneas.

Restricciones: Ninguna- 19 -



Valores Etiquetados: Rows – Número de filas de texto visibles.Cols – El ancho visible del control in average character widths.

1.10. Web Page

Clase del Metamodelo: ComponenteDescripción: Un componente página es una página Web. Puede ser solicitada por su nombre por un navegador. Un componente páginapuede contener o no scripts cliente o servidor.Típicamente los componentes página son ficheros de texto accesiblespor el servidor Web, pero también pueden ser módulos compilables queson cargados e invocados por el servidor Web. Finalmente cuando seaccede a través del servidor Web una página produce un documento conformato HTML que se envía como respuesta a la petición de un

navegador.Restricciones: NingunaValores Etiquetados: Path – La ruta requerida para especificar lapágina Web en el servidor Web. Este valor debería ser relativo adirectorio raíz de la aplicación Web...

1.11. Página ASP

Clase del Metamodelo: ComponenteDescripción: Son páginas Web que implementan código del lado delservidor. Este estereotipo es aplicable solamente en aplicaciones

basadas en Microsoft Active Server Pages.- 20 -



Restricciones: NingunaValores Etiquetados: Los mismos que una página Web

1.12. Librerías Script

Clase del Metamodelo: ComponenteDescripción: Componente que proporciona una serie de subrutinas defunciones que pueden ser incluidas por otros componentes de páginasWebRestricciones: NingunaValores Etiquetados: Los mismos que una página Web

1.13. Servlet

Clase del Metamodelo: ComponenteDescripción: Un componente Java Servlet. Este estereotipo es aplicableúnicamente en entornos de desarrollo con soporte para los Servlets deSun

Restricciones: NingunaValores Etiquetados: Los mismos que una página Web

1.14. Página JSP

- 21 -



Clase del Metamodelo: ComponenteDescripción: Páginas Web que implementan código JSP del lado delservidor. Este estereotipo es aplicable únicamente en entornos deaplicaciones Web que usen JavaServer Pages.

Restricciones:Ninguna

Valores Etiquetados: Los mismos que una página Web

3. Reglas Bien formadas. Realización de componentes

En general, los componentes pueden realizar las clases estereotipadas«server page», «client page», «frameset»,«form»,«JavaScriptObject»,«ClientScript object», y «target».

GeneralizaciónTodo el modelado de elementos en una generalización debe estar en elmismo estereotipo.

AsociaciónLa página cliente puede tener como máximo una relación «builds» con unapágina de servidor, aunque una página de servidor puede tener múltiplesrelaciones «builds» con diferentes páginas cliente.Además de las combinaciones UML estándar, se permiten las siguientescombinaciones para cada estereotipo:

- 22 -



INGENIERÍA DIRECTA PARA APLICACIONES WEB

1. Ingeniería Directa

• Selecciona Modelo Web1. Desde el menú principal seleccione Tools / Option, mostrándose la

siguiente ventana

2. Haga clic en la pestaña Notation y seleccione el lenguaje Web Modeler 3. Haga clic derecho en la vista lógica, seleccione Web Modeler /New /Virtual

Directory

- 23 -

Seleccionela opción



4. Seleccione como plataforma el ASP en indique los siguientes parámetroscomo se muestra a continuación

URL: www.biblionet.comVirtual Directory: ModeloWebPhysical Location: D:\ApliRFH\rose\BiblioNet

5. Luego pulse el botón Ok, mostrándose el siguiente Browse

• Estereotipos de las Clases Web. Pagina Servidor 1. Luego pulse el botón Ok, mostrándose el siguiente Browse2. Haga clic derecho en el directorio virtual Modelo Web3. Seleccione Web Modeler/New/Server Page4. Definir un nombre a la pagina cliente: Biblio

- 24 -

http://www.biblioweb.com/

http://www.biblioweb.com/



Biblio

(from M odeloWeb)

• Estereotipos de las Clases Web. Pagina Cliente1. Haga clic derecho en el directorio virtual Modelo Web2. Seleccione Web Modeler/New/Client Page

3. Definir un nombre a la pagina cliente: Inicio

Inicio

(from M odeloWeb)

4. De Igual manera crea las páginas cliente inscripción y préstamo.

• Relación entre las paginas1. Ubíquese en la barra de herramienta y seleccione el icono Asociación

direccional (Unidireccional Association)2. Ubíquese en la pagina cliente inicio y arrastre hasta la pagina

inscripción3. Para llamar de nuevo desde la pagina inscripción seleccione el icono de

Asociación direccional y arrastre de la pagina inscripción hasta lapagina inicio

4. De igual manera haga clic en el icono de la asociación direccional yarrastre desde la pagina servidor hasta la pagina cliente inicio,

apareciendo una ventana y pulse el botón aceptar 5. Para cambiar el tipo de estereotipo ubíquese en la relación creadaanteriormente, haciendo clic derecho y seleccione la opción deespecificación estándar (Open Standard Specification) y seleccione elestereotipo Build como se muestra en la ventana

- 25 -



6. Luego pulse el botón Ok. mostrándose el siguiente diagrama

Inscripcion(from M odeloWeb)

Prestamo(from M odeloWeb)

Inicio

(from M odeloWeb)

<<Link>>

<<Link>>

<<Link>>

<<Link>>

Biblio(from Mode loWeb)

<<Bu

ild>>

• Estereotipos de las Clases Web. Formulario1. Haga clic derecho en la Pagina Cliente Inscripción.2. Seleccione Web Modeler/New/HTML Form.3. Arrastre desde el Navegador hacia el área de trabajo.4. De igual manera haga para la clase préstamo.

- 26 -

Seleccione

estereotipo



• Propiedades del Formulario

1. Ubíquese en el navegador y haga clic derecho en el formularioInscripción, seleccione Web Modeler/New/HTML Input e ingrese elsiguiente valor

2. Para generar un control radio ubíquese en el navegador y haga clicderecho, seleccione Web Modeler/New/HTML Input e ingrese elsiguiente valor

- 27 -



3. Para generar un botón ubíquese 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 préstamo, quedando eldiagrama de la siguiente forma

Biblio

(from ModeloWeb)

Inscripcion

(from ModeloWeb)

Form

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

<<HTML Input>> attribute : submit = Enviar

(from Inscripcion)

Inicio

(from ModeloWeb)

<<Build>>

<<Link>>

<<Link>>

Prestamo(from ModeloWeb)

<<Link>>

<<Link>>

Form

<<HTML Input>> Nombre del Usuario : text<<HTML Input>> Titulo del Libro : text

<<HTML Input>> attribute : submit = Enivar

(from Prestamo)

- 28 -



• Generar el Código

1. Haga clic derecho en el paquete del directorio virtual seleccione WebModeler/ 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 continuación

- 29 -



2. Haga clic en el archivo inicio y seleccione del menú principal la opción

ver/Código Fuente y se vera el código correspondiente para lo cualpuede embellecer su pagina

2 Ingeniería Reversa• Crear Paginas

1. Crear las siguientes páginas web en la carpeta creada Biblioteca

- 30 -



• Selecciona Modelo Web1. Desde el menú principal seleccione Tools / Web Modeler / Engineer a

New Web Application, como se muestre a continuacion

- 31 -



2. Haga clic en botón siguiente Next.

3. Seleccione los archivos html como se muestra

4. Pulse el botón Siguiente, luego finalice con el botón Final5. Desde el navegador expanda el directorio virtual y arrastre los iconos

hacia el área de trabajo, luego expanda las paginas clientes y arrastrelos formularios como se muestra a continuación

- 32 -



Form

<<HTML Input>> nombre del Usuario : TEXT

<<HTML Input>> Titulo del libro : TEXT

<<HTML Input>> attribute : Submit = Enviar

(from prestamo.html)

inicio.html

(from Biblio)

prestamo.html

(from Biblio)

<<Link>><<Link

>>

Form

<<HTML Input>> nombre del Usuario : TEXT

<<HTML Input>> Respuesta[1] : RADIO = M

<<HTML Input>> Respuesta[2] : RADIO = F

<<HTML Input>> attribute : Submit = Enviar

(from inscripcion .html)

inscripcion.html

(from Biblio)

<<Link>><<Link>>

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

- 33 -



INTRODUCCIÓN AL DISEÑO DE PATRONES

1. NocionesDurante el análisis analizaremos el dominio del problema para construir unmodelo del mundo real utilizando objetos. Investigaremos para hacer unadescripción del problema y obtención de los requerimientos.

El diseño consiste en el refinamiento de los modelos de análisis para crear especificaciones adicionales que enriquecen el modelo de análisis con detallespróximos a la implementación. Una solución lógica, de forma que se cumplanlos requerimientos (asignación de responsabilidades, interacciones entreobjetos, etc.)

La implementación la deberemos realizar en un lenguaje orientado a objetos,durante la cual codificaremos el diseño obtenido en las fases de análisis ydiseño. (Lenguajes OO: Java, C++, Delphi, etc.)

A pesar de todas estas divisiones sigue habiendo interacciones debidas al usoinadecuado de la orientación a objetos, una muy común es el mal empleo de laencapsulación.Otro de los problemas fundamentales es el vacío existente entre el análisis,diseño e implementación, que hace que el programador tenga que tomar decisiones de diseño, o se produzca sobrespecificación

Para solventar estos problemas se produce un nuevo enfoque: el diseño conpatrones. La idea nace del arquitecto Christopher Alexander, que aplica elconcepto a la construcción urbanística.

2. Diseño de PatronesEl objetivo es agrupar una colección de soluciones de diseño que son válidasen distintos contextos y que han sido aplicadas con éxito en otras ocasiones.

Un patrón de diseño es una solución a un problema de diseño no trivial que esefectiva (ya se resolvió el problema satisfactoriamente en ocasiones anteriores)y reusable (se puede aplicar a diferentes problemas de diseño en distintascircunstancias).

Los patrones son soluciones de sentido común que deberían formar parte delconocimiento de un diseñador experto. Además facilitan la comunicación entrediseñadores, pues establecen un marco de referencia (terminología, justificación).

Por otro lado, los patrones de diseño, facilitan el aprendizaje al programador inexperto, pudiendo establecer parejas problema-solución.

- 34 -



En la programación orientada a objetos resulta complicado descomponer elsistema en objetos (encapsulación, granularidad, dependencias, flexibilidad,reusabilidad, etc.), los patrones de diseño nos permitirán identificar a los

objetos apropiados de una manera mucho más sencilla. También nospermitirán determinar la granularidad de los objetos.

Además, los patrones de diseño, también nos ayudarán a especificar lasinterfaces, identificando los elementos claves en las interfaces y las relacionesexistentes entre distintas interfaces. De igual modo nos facilitará laespecificación de la implementación.

También, y de forma casi automática, nos ayudan a reutilizar código, facilitandola decisión entre "herencia o composición" (favorece la composición sobre laherencia y hace uso de la delegación).

Relacionan estructuras en tiempo de compilación y en tiempo de ejecución.Nos permiten hacer un diseño preparado para el cambio.

Podemos clasificar a los patrones según su propósito:

Patrones de creación: para creación de instancias.

Patrones estructurales: relaciones entre clases, combinación y formación deestructuras mayores.

Patrones de comportamiento: interacción y cooperación entre clases.

3. Patrones de CreaciónLos patrones de creación abstraen la forma en la que se crean los objetos,permitiendo tratar las clases a crear de forma genérica dejando para más tardela decisión de qué clases crear o cómo crearlas.Según donde se tome dicha decisión podemos clasificar a los patrones decreación en patrones de creación de clase (la decisión se toma en losconstructores de las clases y usan la herencia para determinar la creación delas instancias) y patrones de creación de objeto (se modifica la clase desde

el objeto). 4. Patrones estructurales

Tratan de conseguir que cambios en los requisitos de la aplicación noocasionen cambios en las relaciones entre los objetos. Lo fundamental son lasrelaciones de uso entre los objetos, y, éstas están determinadas por lasinterfaces que soportan los objetos. Estudian como se relacionan los objetos entiempo de ejecución. Sirven para diseñar las interconexiones entre los objetos.

- 35 -



5. Patrones de comportamiento

Los patrones de comportamiento estudian las relaciones entre llamadas entrelos diferentes objetos, normalmente ligados con la dimensión temporal.

6. AntipatronesLos patrones nos ofrecen una forma de resolver un problema típico, losantipatrones nos enseñan formas de enfrentarse a problemas conconsecuencias negativas conocidas. Los antipatrones se basan en la idea deque puede resultar más fácil detectar a priori fallos en el desarrollo del proyectoque elegir el camino correcto, o lo que es lo mismo, descartar las alternativasincorrectas nos puede ayudar a la elección de la mejor alternativa.

Los antipatrones se clasifican en antipatrones de desarrollo, de arquitectura desoftware y de gestión de proyectos.

6.1. Antipatrones de desarrollo:• The blob (clases gigantes)• Lava flow (código muerto)• Functional Decomposition (Diseño 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 código)

6.2. Antipatrones de arquitectura de software:• Stovepipe enterprise (Aislamiento en la empresa, Islas de

Automatización o Empresa con sistemas parcheados). La causa sueleestar en una falta de estrategia tecnológica en la empresa, falta decooperación y comunicación entre departamentos y niveles, deficienciasen el conocimiento de la tecnología, etc.

• Stovepipe system (Legacy System, Sistema Heredado, Aislamiento entresistemas o Sistema Parcheado)

• Vendor Lock-In (Arquitectura dependiente del producto, Amarrado por el

vendedor, Esclavitud y Sumisión)• Architecture by implication (Arquitectura Implícita). No se especifica la

arquitectura del sistema o ignora alguno de sus apartados.• Design by committee (Diseño por Comité, Navaja suiza, Chapa de Oro,

Enfermedad de Estandarización) Se da cuando el proyecto se diseña através de las reuniones de un comité demasiado numeroso o inexperto.

• Reinvent the wheel Se supone que se debe desarrollar desde cero, faltainformación y tecnología reusable entre proyectos

- 36 -



6.3. Antipatrones de gestión de proyectos:• Analysis paralysis. Ocurre cuando un equipo de analistas comienza una

fase de análisis que sólo acaba cuando se cancela el proyecto.• Death by planning• Corncob (Personas problematicas)• Irrational management• Project mismanegement

7. Principales PatronesA continuación se muestra algunos de los patrones básicos:Patrones de creaciónPatrón FactoríaPatrón Factoría Abstracta

Patrón Singleton (Instancia Única)Patrón PrototipoPatrones estructuralesPatrón Adaptador Patrón PuentePatrón ComposiciónPatrón Decorador Patrón FachadaPatrón ProxyPatrones de comportamientoPatrón Cadena de Responsabilidad

Patrón ComandoPatrón IntérpretePatrón Iterador Patrón Mediador Patrón Recuerdo (Memento)Patrón Observador Patrón EstadoPatrón EstrategiaPatrón PlantillaPatrón Visitante

- 37 -

http://www.elrincondelprogramador.com/default.asp?pag=articulos%2Fleer.asp&id=45






PATRONES CREACIONALES

1. NocionesAbstraen el proceso de instanciación. Nos ayudan a independizar a unsistema, de cómo sus objetos son creados. En general, tratan de ocultar lasclases y métodos concretos de creación, de tal forma que al variar suimplementación, no se vea afectado el resto del sistema.

2. Patrón Singleton2.1. Contexto. En algunas situaciones, necesitamos que algunos datos sean

accesibles desde el resto del sistema. Y también necesitamos que esosdatos sean únicos. Por ejemplo, un objeto que abstraiga lo que es elSistema Operativo actual. También podría ser un objeto que represente al

Sistema Contable, que sea el punto de entrada a un sistema externo. 2.2. Problema. ¿Cómo hacer que la instancia de un objeto sea accesibleglobalmente, y que sea única?

2.3. Solucion. El patrón Singleton proporciona la siguiente solución:

Hacer que la clase provea una instancia de sí misma. Permitir que otros objetos obtengan esa instancia, mediante lallamada a un método de la clase. Declarar el constructor como privado, para evitar la creación deotros objetos.

El diagrama UML correspondiente es muy simple:

Singleton

Singleton()

getInstance()

Este diagrama UML muestra que Singleton es una clase. Contiene una

propiedad estática (el subrayado indica que es un método de clase, masque de instancia), que retorna un Singleton, un objeto de la misma clase.Según la notación UML el número 1 en la esquina superior derecha,indica que solamente habrá una instancia de esta clase. El signo "-" en elconstructor, lo señala como privado. Esto consigue que nadie aparte dela propia clase, pueda crear una instancia.

- 38 -



2.4.Implementación.

Public Class SingletonPrivate Shared Instancia As Singleton

Private Hora As String' Constructor privadoPrivate Sub New()

Hora = Now.ToLongTimeStringMsgBox("Objeto Singleton Creado en New a las " + Hora)

End SubPublic Shared Function CrearInstancia() As Singleton

If Instancia Is Nothing ThenInstancia = New Singleton

End If Return Instancia

End FunctionPublic Function MostrarHora() As String

Return HoraEnd Function

End Class

Esta es una implementación en VB.NET. Notamos que el métodoCrearInstancia está marcado como "shared", siendo entonces un métodode la clase.Conseguimos que el constructor no pueda usarse desde otra parte del

sistema, catalogando con "private" al Sub New.

- 39 -



PATRONES ESTRUCTURALES

1. NocionesSe ocupan de cómo las clases y objetos se agrupan, para formar estructurasmás grandes. También se puede considera como la composición de clases yobjetos

2. Tipos de patrones2.1. De Clase. Usa herencia para componer interfaces o implementaciones.

Entre ellas tenemos:2.1.1. Herencia múltiple2.1.2. Class Adapter

2.2. De Objeto. Composición de objetos en tiempo de ejecución. entre ellastenemos2.2.1. Object Adapter 2.2.2. Bridge2.2.3. Composite2.2.4. Decorator 2.2.5. Facade2.2.6. Flyweight2.2.7. Proxy

3. Patrón Adaptador 3.1. Propósito. Convertir la interfaz de una clase en otra que esperan los

clientes.

3.2.Otras denominaciones3.2.1. Class Adapter y Object Adapter 3.2.2. Wrapper (Envolvente)

3.3. Motivación. Para reutilizar una clase de una biblioteca aunque su interfazno correspondiera exactamente con el que requiere una aplicaciónconcreta

Patrón Estructural Decorador

1. Objetivo del patrón Decorador El objetivo de este patrón es añadir responsabilidades a un objeto concreto deforma dinámica, cuando sea imposible la extensión de funcionalidad por herencia, por ser ésta imprevisible en tipo y número.

- 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 método que siempre será utilizado

por todas sus instancias y que realiza acciones propias de una flor. Perosupongamos que después necesitamos un nuevo tipo de flor, una flor quenecesite ser 'podada'. Entonces podemos crear una subclase denominada'FLOR1,' de la siguiente manera: ( Figura 3)

Figura 3.

Pero ahora, nuevamente, la situación nos presenta la necesidad de tener una

flor que además necesite ser 'Abonada.' Entonces dentro de nuestra jerarquíaactual, podemos resolver este problema de varias maneras: (Ver Figura 4)

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

b. Crear una subclase de la clase FLOR1 llamada FLOR2, de manera queésta contenga el método Abonar ();

c. Crear una subclase de la clase FLOR llamada FLOR2, y que ésta contengael método Abonar ();

- 41 -



d. Agregar el método Abonar () a la clase general FLOR, de manera que

todas las flores puedan ser fertilizadas;

Podríamos simplificar el problema simplemente desplazando los métodosAbonar() y Podar() a una sola clase FLOR, de manera que todas las florespuedan ser podadas y fertilizadas

Figura 4.

Entonces, según las necesidades actuales, nos arriesgamos y escogemosla opción y hacemos los cambios. Pero, ¿Qué pasa si después necesitamostener más flores con diferentes y nuevas funcionalidades? ¿Tendríamos quecrear subclases otra vez? Pero según el caso anterior ¿Dónde creamos lassubclases? ¿Qué nivel jerárquico es mejor para la modificación? Y después, sinecesitamos más y más funcionalidades, ¿Cómo lo haríamos? ¿Cómo es quemi simple clase FLOR que se tenía en un principio se volvió más complicada?

- 42 -



3. Uso del patrón Decorador

Tal vez la respuesta a las preguntas anteriores es usar el patrón Decorador.La principal diferencia entre usar subclases y el patrón Decorador es que con

las subclases se trabaja directamente con la clase, en cambio con el patrónDecorador se modifican los objetos dinámicamente. Cuando se extiende unaclase, los cambios hechos a las clases hijos serán afectados a todas lasinstancias de las clases hijos; sin embargo, con el patrón Decorador se aplicanlos cambios a cada objeto individual que se quiere cambiar.

4. Estructura del patrón Decorador

Figura 5.

A continuación describiremos la estructura:

• Componente: Clase abstracta común a todas las clases susceptiblesde ser ampliadas con el Decorador.

• ComponenteConcreto: Son las clases cuya funcionalidad se puedeextender y en las que se delega en última instancia para realizar lasoperaciones propias de la clase.

• Decorador : Clase abstracta que declara la estructura común a todoslos Decoradores y declara (o implementa, según sea el caso) laresponsabilidad de mantener una referencia al objeto que se extiende.Es posible que sobrecargue todos los métodos de la clase Componentecon llamadas al componente concreto, de forma que aquellos métodoscuya funcionalidad no se extiende simplemente llaman a los originales.

- 43 -



• DecoradorConcreto1 y DecoradorConcreto2: Son clases concretas

que heredan de Decorador e implementan las extensiones defuncionalidad de la clase original ComponenteConcreto.

Entonces, el diagrama de la segunda opción presentada, aplicando el patrónDecorador al problema de las flores, es el siguiente:

Figura 6.

- 44 -



PATRONES DE COMPORTAMIENTOS

1. NocionesUn patrón comportamiento:

Tiene que ver con la dimensión temporal Estudia las relaciones entre llamadas entre los diferentes objetos. Incide en facilidades para tiempo de ejecución

2. Patrón Iterador

Aggregate

+CreateIterator()

Iterator

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

ConcreteAggregate ConcreteIterator

3. Patrón Memento

O r i g i n a t o r

+ S e t M e m e n t o ( m: M e m e n t o )

+C rea teMe mento ( )

M e m e n t o

+ GetS ta te ( )

+ Se tS ta te ( )

C a r e t a k e r

+ m e n e n t o

- 45 -



4. Patrón Observador

Subject

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

Observer

+Update()

ConcreteSubject ConcreteObserver

+subject

5. Patrón State

Context

+Request()

State

+Handle()

ConcreteState

+state

- 46 -



CALIDAD DE SISTEMAS

1.- CONCEPTOS DE CALIDADSe define la calidad como «una característica o atributo de algo». Como unatributo de un elemento, la calidad se refiere a las característicasmensurables -cosas que se pueden comparar con estándares conocidoscomo longitud, color, propiedades eléctricas, maleabilidad, etc. Sin embargo,el software en su gran extensión, como entidad intelectual, es más difícil decaracterizar que los objetos físicos.La calidad de diseño se refiere a las características que especifican losingenieros de software para un elemento. El grado de materiales, toleranciasy las especificaciones del rendimiento contribuyen a la calidad del diseño.Cuando se utilizan materiales de alto grado y se especifican tolerancias más

estrictas y niveles más altos de rendimiento, la calidad de diseño de unproducto aumenta, si el producto se fabrica de acuerdo con lasespecificaciones.La calidad de concordancia es el grado de cumplimiento de lasespecificaciones de diseño durante su realización. Una vez más, cuantomayor sea el grado de cumplimento, más alto será el nivel de calidad deconcordancia.En el desarrollo del software, la calidad de diseño comprende los requisitos,especificaciones y el diseño del sistema. La calidad de concordancia es unaspecto centrado principalmente en la implementación. Si la implementaciónsigue el diseño, y el sistema resultante cumple los objetivos de requisitos y de

rendimiento, la calidad de concordancia es alta.

2. CONTROL DE CALIDADEl control de cambios puede equipararse al control de calidad. Pero, ¿cómose logra el control de calidad? El control de calidad es una serie deinspecciones, revisiones y pruebas utilizados a lo largo del proceso delsoftware para asegurar que cada producto cumple con los requisitos que lehan sido asignados. El control de calidad incluye un bucle de realimentación(feedback)del proceso que creó el producto. La combinación de medición yrealimentación permite afinar el proceso cuando los productos de trabajocreados fallan al cumplir sus especificaciones. Este enfoque ve el control decalidad como parte del proceso de fabricación.

3. ¿Qué es el control de calidad del software?Las actividades de control de calidad pueden ser manuales, completamenteautomáticas o una combinación de herramientas automáticas e interacciónhumana. Un concepto clave del control de calidad es que se hayan definidotodos los productos y las especificaciones mensurables en las que se puedancomparar los resultados de cada proceso. El bucle de realimentación esesencial para reducir los defectos producidos.

- 47 -



4. Garantía de calidad

La garantía de calidad consiste en la auditoría y las funciones de informaciónde la gestión. El objetivo de la garantía de calidad es proporcionar la gestión

para informar de los datos necesarios sobre la calidad del producto, por lo quese va adquiriendo una visión más profunda y segura de que la calidad delproducto está cumpliendo sus objetivos. Por supuesto, si los datosproporcionados mediante la garantía de calidad identifican problemas, esresponsabilidad de la gestión afrontar los problemas y aplicar los recursosnecesarios para resolver aspectos de calidad.

5. Coste de calidadEl coste de calidad incluye todos los costes acarreados en la búsqueda de lacalidad o en las actividades relacionadas en la obtención de la calidad. Serealizan estudios sobre el coste de calidad para proporcionar una línea basedel coste actual de calidad, para identificar oportunidades de reducir estecoste, y para proporcionar una base normalizada de comparación. La base denormalización siempre tiene un precio. Una vez que se han normalizado loscostes de calidad sobre un precio base, tenemos los datos necesarios paraevaluar el lugar en donde hay oportunidades de mejorar nuestros procesos.Es más, podemos evaluar cómo afectan los cambios en términos de dinero.Los costes de calidad se pueden dividir en costes asociados con laprevención, la evaluación y los fallos. Entre los costes de prevención seincluyen: planificación de la calidad, revisiones técnicas formales, equipo depruebas, formación entre los costos de evaluación se incluyen actividades

para tener una visión más profunda de la condición del producto «la primeravez a través de» cada proceso.

Los costos de fallos son los costes que desaparecerían si no surgierandefectos antes del envío de un producto a los clientes. Estos costes sepueden subdividir en costes de fallos internos y costes de fallos externos. Losinternos se producen cuando se detecta un error en el producto antes de suenvío. Entre estos se incluyen:

retrabajo (revisión), reparación,

análisis de las modalidades de fallos.

Los costes de fallos externos son los que se asocian a los defectosencontrados una vez enviado el producto al cliente. A continuación seincluyen algunos ejemplos de costes de fallos externos:

resolución de quejas, devolución y sustitución de productos, soporte de línea de ayuda, trabajo de garantía.

- 48 -



6. GARANTIA DE CALIDAD DE SOFTWARE

Actividades de SQA

La garantía de calidad del software comprende una gran variedad de tareas,asociadas con dos constitutivos diferentes : Los ingenieros de software querealizan trabajo técnico y un grupo de SQA que tiene la responsabilidad de laPlanificación de garantía de calidad, supervisión, mantenimiento de registros,análisis e informes. Los ingenieros de software afrontan la calidad (y realizangarantía de calidad) aplicando métodos técnicos sólidos y medidas,realizando revisiones técnicas formalesy llevando a cabo pruebas de software bien planificadas.

Éstas son las actividades que realizan (o facilitan) un grupo independiente deSQA:

Establecimiento de un plan de SQA para un proyecto.El plan se desarrolladurante la planificación del proyecto y es revisado por todas las partesinteresadas. Las actividades de garantía de calidad realizadas por el equipode ingeniería del software y el grupo SQA son gobernadas por el plan. El planidentifica:

evaluaciones a realizar, auditorías y revisiones a realizar, estándares que se pueden aplicar al proyecto,

procedimientos para información y seguimiento de errores, documentos producidos por el grupo SQA, realimentación de información proporcionada al equipo de proyecto del software.

Participación en el desarrollo de la descripción del proceso de softwaredel proyecto. El equipo de ingeniería del software selecciona un procesopara el trabajo que se va a realizar. El grupo de SQA revisa la descripción delproceso para ajustarse a la política de la empresa, los estándares internos delsoftware, los estándares impuestos externamente (por ejemplo: 1SO 9001), y

a otras partes del plan de proyecto del software.Revisión de las actividades de ingeniería del software para verificar suajuste al proceso de software definido. El grupo de SQA identifica,documenta y sigue la pista de las desviaciones desde el proceso y verificaque se han hecho las correcciones.

Auditoría de los productos de software designados para verificar elajuste con los definidos como parte del proceso del software. El grupo deSQA revisa los productos seleccionados; identifica, documenta y sigue la pistade las desviaciones; verifica que se han hecho las correcciones, e informa

periódicamente de los resultados de su trabajo al gestor del proyecto.- 49 -



Asegurar que las desviaciones del trabajo y los productos del softwarese documentan y se manejan de acuerdo con un procedimiento

establecido. Las desviaciones se pueden encontrar en el plan del proyecto,en la descripción del proceso, en los estándares aplicables o en los productostécnicos.

Registrar lo que no se ajuste a los requisitos e informar a sussuperiores. Los elementos que no se ajustan a los requisitos están bajoseguimiento hasta que se resuelven.

7. Herramientas CASESon un conjunto de métodos, utilidades y técnicas que facilitan laautomatización del ciclo de vida del desarrollo de sistemas de información,completamente o en alguna de sus fases.El empleo de herramientas Case permiten integrar el proceso de ciclo de vida:

Análisis de datos y procesos integrados mediante un repositorio. Generación de interfaces entre el análisis y el diseño. Generación del código a partir del diseño. Control de mantenimiento.

Actualmente, la tendencia en el desarrollo de software está enfocada hacia lasmicrocomputadoras como plataformas de ingeniería de software, que seinterconectan mediante redes para que puedan comunicarse de forma

efectiva. La base de datos del proyecto (también denominada biblioteca delproyecto o depósito de software), está disponible a través de un servidor dearchivos en red que es accesible desde todas las estaciones de trabajo. Unsistema operativo que gestiona el hardware, la red y las herramientas,mantiene todo el entorno unido.

La mayoría de las herramientas Case no han sido construidas utilizando todoslos bloques componentes. Muchas de éstas son soluciones puntuales, esto es,

una herramienta se utiliza como ayuda en una actividad concreta de ingeniería- 50 -



de software (por ejemplo: modelización del análisis), pero no se comunicadirectamente con otras herramientas, porque no está unida a una base dedatos de proyectos. Aunque esta situación no es la ideal, una herramienta

Case puede ser utilizada eficientemente, aún siendo una solución puntual.

8. Tipos de CaseNo existe una única clasificación de herramientas CASE y, en ocasiones, esdifícil incluirlas en una clase determinada. Podrían 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 función 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 llamadastambién CASE workbench.

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

• Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) ofront-end, orientadas a la automatización y soporte de las actividadesdesarrolladas durante las primeras fases del desarrollo: análisis y diseño.

• Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) oback-end, dirigidas a las últimas fases del desarrollo: construcción e implantación.

• Juegos de herramientas o toolkits, son el tipo más simple deherramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de estegrupo se encontrarían las herramientas de reingeniería, orientadas a la fase demantenimiento.

Las herramientas I-CASE se basan en una metodología. Tienen un repositorioy aportan técnicas estructuradas para todas las fases del ciclo de vida. Unaestrategia posible es utilizar una U-CASE para análisis y diseño, combinadacon otras herramientas más modernas para las fases de construcción ypruebas. En este caso, habría que vigilar cuidadosamente la integración entrelas distintas herramientas.

- 51 -



Otra posible clasificación, utilizando la funcionalidad como criterio principal,es la siguiente:

• Herramientas de planificación de sistemas de gestión. Sirven paramodelizar los requisitos de información estratégica de una organización.Proporcionan un "metamodelo" del cual se pueden obtener sistemas deinformación específicos. Su objetivo principal es ayudar a comprender mejor cómose mueve la información entre las distintas unidades organizativas. Estasherramientas proporcionan una ayuda importante cuando se diseñan nuevasestrategias para los sistemas de información y cuando los métodos y sistemas

actuales no satisfacen las necesidades de la organización.• Herramientas de análisis y diseño. Permiten al desarrollador crear unmodelo del sistema que se va a construir y también la evaluación de la validez yconsistencia de este modelo. Proporcionan un grado de confianza en larepresentación del análisis y ayudan a eliminar errores con anticipación. Se tienen:

Herramientas de análisis y diseño (Modelamiento). Herramientas de creación de prototipos y de simulación. Herramientas para el diseño y desarrollo de interfaces. Máquinas de análisis y diseño (Modelamiento).

•

Herramientas de programación. Se engloban aquí los compiladores, loseditores y los depuradores de los lenguajes de programación convencionales.Ejemplos de estas herramientas son:

Herramientas de codificación convencionales. Herramientas de codificación de cuarta generación. Herramientas de programación orientadas a los objetos.

• Herramientas de integración y prueba: Sirven de ayuda a la adquisición,medición, simulación y prueba de los equipos lógicos desarrollados. Entre las másutilizadas están:

Herramientas de análisis estático. Herramientas de codificación de cuarta generación.

- 52 -



Herramientas de programación orientadas a los objetos.

• Herramientas de gestión de prototipos. Los prototipos son utilizados

ampliamente en el desarrollo de aplicaciones, para la evaluación deespecificaciones de un sistema de información, o para un mejor entendimiento decómo los requisitos de un sistema de información se ajustan a los objetivosperseguidos.

• Herramientas de mantenimiento: La categoría de herramientas demantenimiento se puede subdividir en:

Herramientas de ingeniería inversa. Herramientas de reestructuración y análisis de código. Herramientas de reingeniería.

•

Herramientas de gestión de proyectos. La mayoría de las herramientasCASE de gestión de proyectos, se centran en un elemento específico de lagestión del proyecto, en lugar de proporcionar un soporte global para laactividad de gestión. Utilizando un conjunto seleccionado de las mismas sepuede: realizar estimaciones de esfuerzo, coste y duración, hacer unseguimiento continuo del proyecto, estimar la productividad y la calidad, etc.Existen también herramientas que permiten al comprador del desarrollo deun sistema, hacer un seguimiento que va desde los requisitos del pliego deprescripciones técnicas inicial, hasta el trabajo de desarrollo que convierteestos requisitos en un producto final. Se incluyen dentro de lasherramientas de control de proyectos las siguientes:

Herramientas de planificación de proyectos. Herramientas de seguimiento de requisitos. Herramientas de gestión y medida.

• Herramientas de soporte. Se engloban en esta categoría las herramientasque recogen las actividades aplicables en todo el proceso de desarrollo, como lasque se relacionan a continuación:

Herramientas de documentación. Herramientas para software de sistemas. Herramientas de control de calidad.

9. Opciones de IntegraciónLas herramientas Case pueden ser integradas de muchas formas. En unextremo se utiliza una herramienta CASE de forma aislada. Se crea unnúmero limitado de elementos de configuración de software (documentos,programas o datos) que se manipulan mediante una única herramienta y cuyasalida tiene el formato de copia de pantalla y/o documentación gráfica. Encierto sentido, el enlace con el resto del entorno de desarrollo se realizamediante 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 Integración CASE:a) Intercambio de datos,

b) Acceso común a herramientas,c) Integración de datos,d) Integración total.

a) Intercambio de datos. La mayoría de las herramientas permiten exportar datos en forma de archivo sin estructura con un formato conocido. Estopermite un intercambio de datos punto a punto entre las distintas herramientasCASE, utilizando normalmente un "filtro" de transmisión intermedio.

La desventaja del intercambio de datos punto a punto está en que, amenudo, sólo parte de los datos exportados es utilizable por la herramientareceptora, ya que no fue diseñada para ser totalmente compatible. Además, amedida que evoluciona el software, la necesidad de transferir archivos cadavez que se hace un cambio pequeño puede llevar mucho tiempo. Lasversiones pueden quedar "desfasadas" fácilmente, perdiéndose la posibilidadde transferencia, la cual suele ser en un único sentido. No hay posibilidad deque los cambios se reflejen en ambos sentidos y, es difícil hacer comprobaciones cruzadas de documentos y mantener la integridad de laconfiguración a través de las distintas herramientas que se estén utilizando.b) Acceso común a herramientas. Permite al usuario utilizar distintasherramientas de forma similar, por ejemplo a través de un menú desplegabledel gestor de ventanas del sistema operativo. En un entorno multitarea, unusuario podría abrir simultáneamente varias herramientas, coordinandomanualmente sus entradas y comparando las representaciones de diseño amedida que evolucionan. Por ejemplo, el usuario podría visualizar un diagramade flujo de datos, un diagrama de estructura , un diccionario de datos y unsegmento de código fuente, todos mantenidos por diferentes herramientas. Enestos entornos, el intercambio de datos de herramienta a herramienta podríasimplificarse llamando al procedimiento de traducción a través de un simplemenú o de la selección de una macro. No es la opción más adecuada.

- 55 -



c) Integración de Datos:

c1) Gestión común de datos. Los datos de distintas herramientas se puedenmantener en una única base de datos lógica, que puede estar físicamente

centralizada o distribuida. Hay una modalidad de fusión que permite combinar el trabajo de varias personas trabajando en diferentes partes de unaaplicación.Aunque los datos generados por las distintas herramientas se gestionan deforma conjunta en el nivel de gestión de datos comunes, las herramientas noconocen de forma explícita las estructuras de datos y la semántica derepresentación del diseño de las demás. Consecuentemente, se requiere unaetapa de traducción (normalmente ejecutada manualmente) para permitir queuna herramienta utilice la salida generada por otra.c2) Datos compartidos. Las herramientas del nivel de datos compartidostienen estructuras de datos y semántica compatible, pudiendo intercambiar datos sin necesidad de una etapa de traducción. Cada herramienta se diseñapara ser compatible con las demás. Por esta razón, la mayor parte delintercambio de datos se da entre herramientas de un único fabricante o encasos en los que se han establecido relaciones estratégicas, entre distintosfabricantes para generar un conjunto de datos integrado, a veces, a peticiónde clientes importantes.c3) Interoperabilidad. Las herramientas que combinan las características deacceso común y la capacidad de compartir datos, tienen la capacidad deinteroperación. Esto representa el mayor nivel de integración entreherramientas diferentes. Sin embargo, hay otras propiedades del entorno

global CASE que se pueden añadir para mejorar la efectividad del proceso dedesarrollo de software.d) Integración Total

Para alcanzar la integración total del entorno CASE se necesitan doscaracterísticas más: gestión de metadatos y capacidad de control.

- 56 -

Manual Cursos Seminario de Tesis 01-04-11

Documents

Transcript of Manual Cursos Seminario de Tesis 01-04-11