Desarrollo de Aplicaciones Web en MicroSoft C Modeladas en UML

UNIVERSIDAD PRIVADA DEL VALLE DEPARTAMENTO DE SISTEMAS Y TECNOLOGA INFORMTICA
INGENIERA DE SISTEMAS INFORMTICOS CENTRO DE CMPUTO
DESARROLLO DE APLICACIONES WEB EN MICROSOFT C# .NET MODELADAS EN UML
Autores: Ing. MsC. Roberto Flix Zamuriano Sots Ing. Carlos Eduardo Caldern Vildoso
FEBRERO-2008
DESCRIPCIN El Texto guiar al estudiante, por medio de documentos, a travs de los entornos de modelacin e implementacin, utilizando UML y la miniarquitectura Microsoft.NET para el desarrollo de una aplicacin Web. La modalidad es terico prctico, el estudiante deber complementar con lecturas recomendadas sobre cada captulo antes de realizar la parte prctica que ser evaluada. El Objetivo general es documentar el desarrollo de una aplicacin Web de acuerdo con el lenguaje UML, siguiendo un determinado proceso desarrollo basado en RUP. Todo el texto se basa en un ejemplo prctico que incluir todos los puntos sealados en los captulos. OBJETIVOS ESPECFICOS Conocer las caractersticas de la Programacin en .NET Modelar en UML aplicaciones Web Desarrollar aplicaciones en C# que han sido modeladas en UML Conocer la nueva filosofa de la programacin Web y Web Service Profundizar en las tcnicas de Ingeniera de Software de las etapas de Requisitos y Anlisis Profundizar en las tcnicas de diseo de aplicaciones de cualquier tipo (clsicas y Web).
CAPTULOS A DESARROLLAR El proyecto est dividido en cinco captulos, los cuales engloban las caractersticas ms importantes de documentacin y de implementacin. El primer captulo introducir al estudiante al mundo de Microsoft.NET, donde podr ver las caractersticas fundamentales de esta miniarquitectura que permite desarrollar software, culminado con dos pequeas aplicaciones que permite garantizar el conocimiento del estudiante de la nueva filosofa de .NET. El segundo captulo trata de la ingeniera de requisitos y la fase de anlisis, el cual permitir obtener conocimientos para estudiar una determinada aplicacin de informacin y finaliza con una pequea vista de la futura aplicacin de informacin. Continuando, el captulo tres inicia con la determinacin de la arquitectura, que es el inicio de la fase de diseo. La fase de diseo tiene como objetivo fundamental de definir y determinar las clases y componentes para la implementacin de la aplicacin. La implementacin es el cuarto captulo, el cual se har por medio del nuevo lenguaje C# de Microsoft, antes de iniciar esta aventura se debe definir un estndar de implementacin para el futuro de la aplicacin. Por ltimo, el captulo cinco denominado Prueba de la Aplicacin, es el que dar valides a la aplicacin construida, se utilizar los casos de uso de prueba para realizar esta fase del desarrollo. Se ver, ahora, el contenido de los distintos captulos.
NDICE
INTRODUCCIN A LA PROGRAMACIN EN MICROSOFT C#.NET ..................................................................... 1 INTRODUCCIN AL TEXTO ................................................................................................................................................ 2 INTRODUCCIN A MICROSOFT .NET ............................................................................................................................... 20 ELEMENTOS BSICOS DE PROGRAMACIN C# ............................................................................................................... 31 IMPLEMENTAR LA PRIMERA APLICACIN EN WEB ........................................................................................................... 50 IMPLEMENTAR UN SERVICIO WEB................................................................................................................................... 72 INGENIERA DE REQUISITOS Y ANLISIS .............................................................................................................. 85 INTRODUCCIN A LA MODELACIN CON UML ................................................................................................................. 86 INTRODUCCIN A LA MODELACIN DEL NEGOCIO .......................................................................................................... 95 MODELO DE CASOS DE USO DEL NEGOCIO ...................................................................................................................109 DIAGRAMA DE ACTIVIDADES DEL CASO DE USO DEL NEGOCIO ......................................................................................124 MODELO DE OBJETO DEL NEGOCIO ..............................................................................................................................142 INTRODUCCIN AL FLUJO DE REQUISITOS ....................................................................................................................156 DIAGRAMA DE CASOS DE USO ......................................................................................................................................161 DESCRIPCIN DE LOS CASOS DE USO DE LA APLICACIN .............................................................................................175 DETERMINACIN DE LOS REQUISITOS NO FUNCIONALES DE LA APLICACIN .................................................................190 FLUJO DE ANLISIS: DESCRIPCIN DETALLA DE CASOS DE USO ...................................................................................201 DIAGRAMA DE COLABORACIN O COMUNICACIN ........................................................................................................224 DIAGRAMA DE PAQUETES .............................................................................................................................................250 DISEO DE APLICACIONES WEB ............................................................................................................................255 DEFINICIN DE LA ARQUITECTURA ...............................................................................................................................256 MAPA DE NAVEGACIN .................................................................................................................................................279 DIAGRAMA DE CLASES WEB ..........................................................................................................................................293 DIAGRAMA DE SECUENCIA ............................................................................................................................................311 DIAGRAMA DE CLASES..................................................................................................................................................329 CAPITULO IV .............................................................................................................................................................342 IMPLEMENTACIN ......................................................................................................................................................342 ESTNDARES DE IMPLEMENTACIN ..............................................................................................................................343 IMPLEMENTACIN DE LA CAPA DE PRESENTACIN........................................................................................................347 IMPLEMENTACIN DE LA CAPA DE NEGOCIO Y DATOS ...................................................................................................381 INTEGRANDO CAPAS .....................................................................................................................................................398 CAPITULO V ..............................................................................................................................................................411 PRUEBA .........................................................................................................................................................................411 DISEO DE CASOS DE USO DE PRUEBA. ..........................................................................................................412 BIBLIOGRAFA..............................................................................................................................................................421
Universidad Privada del Valle Bolivia Unidad Acadmica Sucre
CAPTULO I
INTRODUCCIN A LA PROGRAMACIN EN MICROSOFT C#.NET
Objetivo Introducir y conocer la filosofa de la programacin en .NET, para que el estudiante tenga una claridad sobre la programacin orientada a objetos, de esta manera no tendr dificultades para entender la filosofa de la modelacin con UML
1
Ingeniera de Sistemas Informticos
INTRODUCCIN AL TEXTO
APRENDA A DESARROLLAR UNA APLICACIN EN 48 HORAS
Bienvenidos al Texto, lanzamos el presente texto esperando que cumpla con sus expectativas y que contribuya a su formacin profesional. El texto abarca muchos temas de investigacin, sin embargo se ha dirigido hacia un ejemplo concreto para comprender la modelacin con UML y la utilizacin de artefactos y estereotipos
Grupo de Investigacin Univalle - 2006
Introduccin al Curso
La
modalidad del curso es terico prctico Al final del curso se tendr implementada una aplicacin ASP.NET simple, donde estarn presentes todos los captulos del curso Se abordar muy rpido y bsicamente las aplicaciones tradicionales con interfaz Windows.
Grupo de Investigacin Univalle - 2006 2
El texto est dividido por captulos, que sern descritos ms adelante. El texto toma ms en cuenta la parte prctica que la terica y la meta es cubrir los procesos fundamentales del desarrollo de software culminando con una aplicacin Web, para finalizar se realizar un ejemplo sobre la interfaz Windows.
Introduccin al Curso
Objetivos
del Documento
Conocer las caractersticas de la programacin en .NET Modelar en UML aplicaciones a ser desarrolladas en .NET, utilizando Rational Rose Desarrollar aplicaciones en C# que han sido modeladas en UML Conocer la nueva filosofa de la programacin Web y Web Service
La primera parte del texto est dirigida a las caractersticas de la programacin en .NET. Esta tecnologa ha dado un cambio muy provechoso en el mundo de la programacin. Luego, se realizar un modelo con ayuda de Rational Rose de anlisis y diseo de una aplicacin. Usted puede seleccionar otro software que le ayude con los diagramas de UML que se vern en este proceso de modelacin. El propsito fundamental del texto es programar en C#, pero la programacin estar guiada por la modelacin, todo lo que se modele debe estar plasmado en la implementacin. Por ltimo, se aprender como implementar un Servicio Web.
2
Introduccin
Software
a Utilizar
Visual Studio .NET MS-SQL Server 2000 Lenguaje C# Rational Software
Durante el texto utilizaremos distintas herramientas software que ayudan a llevar a cabo el desarrollo de software, entre ellos estn el Visual Studio, del cual utilizaremos el lenguaje C#, el MS-SQL Server y por ltimo, la herramienta que nos ayudar a documentar nuestra aplicacin, el Rational Rose
Contenido Del Documento

CAPTULO
I: Introduccin a la programacin en Microsoft C#.NET

Objetivo:
Introducir y conocer la filosofa de la programacin en .NET, para que el estudiante tenga una claridad sobre la programacin orientada a objetos, de esta manera no tendr dificultades para entender la filosofa de la modelacin con UML

CAPTULO

I: Introduccin a la programacin en Microsoft C#.NET

Introduccin a Microsoft .NET Elementos bsicos de programacin C# Implementar la primera aplicacin en Web Implementar un Servicio Web
El contenido del texto est formado por cinco captulos, los cuales estarn abarcando el ciclo de vida del desarrollo del producto. El primer mdulo est dirigido a introducir al mundo de la programacin con .NET y C#. Es muy importante entender que la programacin en C# es totalmente orientada a objetos. Este primer mdulo asegurar que el estudiante comprenda de manera general la programacin orientada a objetos. A continuacin veremos el contenido del primer mdulo. Dentro del primer captulo se realizar una introduccin a Microsoft. NET donde se ver la arquitectura conformada por Microsoft para el desarrollo de software, para luego seguir con otro captulo de los elementos bsicos de C#, declaracin de variables, tipos de datos, bucles, sentencias de condicin, excepciones, declaraciones de clases, etc. Para finalizar, este primer captulo, se desarrollar una pequea aplicacin Web y un Servicio Web, los cuales servirn para reflejar la programacin orientada a objetos y la nuevas caractersticas que tiene ASP.NET
3

CAPTULO
II: : Ingeniera de Requisitos
y Anlisis
Objetivo:
Introducir y conocer la filosofa de las etapas de Ingeniera de Requisitos y Anlisis
Ya en el segundo captulo se iniciar la modelacin. El objetivo fundamental de este captulo es estimar el tiempo, costo y esfuerzo que se necesitara para el desarrollo de software, solo se realizar una estimacin, para esto necesitaremos parte de la Ingeniera de Requisitos. Luego de la estimacin, pasaremos a construir la aplicacin.
El contenido del captulo dos es muy amplio ya que englobar la Modelacin del Negocio, con el Diagrama de Casos de Uso del Negocio que son CAPTULO II: : Ingeniera de Requisitos muy distintos a los Casos de Uso del Sistema, el y Anlisis Diagrama de Actividad, el cual es utilizado para la Introduccin a la Modelacin con UML descripcin de los Casos de Uso del Negocio, Modelacin del Negocio para finalizar con el Modelo de Objeto del Flujo de Requisito Negocio. Estimacin de Esfuerzo, Tiempo y Costo Flujo de Anlisis El primer Flujo Requisitos, est conformado con el Diagrama de Casos de Usos del Sistema y su descripcin de forma general. Cuando se tiene una idea de los Casos de Uso del Sistema que conforman la aplicacin a desarrollar ya se puede llevar a cabo la Estimacin de Costos, Esfuerzo y Tiempo, factores muy importantes de la calidad de software. Para finalizar el mdulo, est el Flujo de Anlisis El captulo III se iniciar con la definicin de la Contenido Del Documento arquitectura, una descripcin global del sistema, determinando las reglas de juego para el diseo CAPTULO III: Diseo de Aplicaciones y la implementacin. Web Tambin, se ver los estereotipos para la Objetivo: descripcin de la aplicacin Web. Profundizar en las tcnicas de diseo de
aplicaciones de cualquier tipo (clsicas y Web)
4
El contenido se inicia, como se indicaba anteriormente, con la definicin de la arquitectura, luego con una descripcin de la CAPTULO III: Diseo de Aplicaciones posible navegacin entre pginas. Del Mapa de Web Navegacin se pasar a una describir del cmo Definicin de la Arquitectura va a interactuar el sistema con los datos. Esta Mapa de Navegacin Web interaccin se la describe a travs del diagrama Diagrama de Clases Web de secuencias, el cual dar una gran lista de Diagrama de Clases del Diseo Diagrama de Secuencias mtodos correspondientes a las clases que Definicin de la Base de Datos Relacional representan el comportamiento o funcionalidades de la aplicacin. Para culminar, debe definirse la base de datos relacional a travs del diagrama de clases del diseo. Pasando al captulo IV, denominado Contenido Del Documento Implementacin de la Aplicacin. No es ms que iniciar la codificacin, con la direccin del CAPTULO IV: Implementacin de la modelo del diseo y cumpliendo con la Aplicacin arquitectura definida. Antes de llevar a cabo la Objetivo: implementacin de la aplicacin, debe hacerse Utilizar la modelacin efectuada anteriormente para desarrollar una aplicacin de acuerdo a lo un parntesis para determinar el estndar de modelado implementacin, este estndar debe considerar como sern escritas, las Variables, Componentes Web, Clases, Objetos, etc. Se ver un ejemplo de estndar de programacin que corresponda y responda con la arquitectura definida para la aplicacin. El captulo se inicia con la implementacin de la Contenido Del Documento Capa de Presentacin, la cual es la interfaz del usuario con la aplicacin, se debe colocar los CAPTULO IV: Implementacin de la componentes que nos ayudan a mostrar y Aplicacin capturar los datos. Luego se implementa la Capa Implementacin de la Capa de Presentacin Implementacin de la Capa del Negocio del Negocio de la aplicacin, es aqu donde se Implementacin del Servicio Web determina las reglas para los datos (validacin, Implementacin de la Capa de Datos lgica). Si es necesario se llama a un Servicio Implementacin de la Capa del Negocio de los Datos Web a travs de la capa de negocio. Integrando Capas Luego, se inicia la implementacin del Servicio Web con sus distintas capas para la consulta de los datos hacia la base de datos. Esto implica el desarrollo de la Capa de Datos y la Capa del Negocio de los Datos. No se debe olvidar que un Servicio Web es una aplicacin pero sin interfaz. Para culminar, con el captulo, se realizar la integracin de las distintas capas. Esta integracin permite observar que el trabajo del desarrollo se puede dividir, varias personas pueden desarrollar una determinada capa, y otro grupo de personas puede desarrollar otra, de esta manera logrando dividir el desarrollo.
10
11
12
5

CAPTULO
V: Diseo de Pruebas de la
Aplicacin
Objetivo
Validar la aplicacin desarrollada y ver si cumple con los requisitos utilizando una tcnica de prueba
Por ltimo est el captulo V, que culmina con el texto. El cual, tiene como objetivo realizar una validacin de la aplicacin con los requisitos determinados en la fase de Ingeniera de Requisitos. La Validacin se entiende como si la aplicacin desarrollada cumple con los requisitos de los usuarios.
13

CAPTULO
V: Diseo de Pruebas de la
Aplicacin
Diseo de Casos de Uso de Prueba Validacin de los Casos de Uso de Prueba Recopilacin y Resumen de los defectos Definir el Control de Cambio

14
Introduccin al Desarrollo de Software
Para realizar la validacin se utilizar el diseo de Casos de Uso de Prueba, los cuales estn en funcin de los Casos de Uso del Sistema que son los requisitos de la aplicacin. Los Casos de Uso de Prueba describen una situacin dentro del sistema que debe satisfacer al usuario, se puede tener varios Casos de Uso de Prueba por un solo Caso de Uso del Sistema. El resultado de esta tcnica es un conjunto de defectos dentro de la aplicacin, los cuales deben ser corregidos. Esta correccin debe ser documentada y planificada para llevar un control y tener una biblioteca de posibles defectos que se pueden encontrar en la implementacin. Antes de iniciar la aventura de desarrollar una aplicacin Web, se realizar una introduccin al mundo del desarrollo de software. Esta introduccin nos dar una visin de los problemas y soluciones que se dan en este mundo.
15
6

En
las siguientes Diapositivas se har referencia algunos conceptos que se deben tomar en cuenta en el desarrollo de software El mantener un software cumple con el ciclo de vida del software el cual se debe documentar a travs de un proceso determinado y normado institucionalmente
Para iniciar con esta introduccin se har referencia a algunos conceptos que son muy importantes para emprender el desarrollo de software, como por ejemplo la calidad de software, los modelos de proceso de software que involucra la calidad, algunas tcnicas para trabajar en equipo, etc. Todos estos conceptos contribuyen al inicio y culminacin con xito el ciclo de vida del software. El trabajo ms importante para esta aventura es la documentacin que se genera del software, ya que con ella se podr garantizar una calidad y un Veamos algunas mtricas que corresponden con el desarrollo de software. Esta mtrica depende de la complejidad de la aplicacin a desarrollar y de la metodologa del ciclo de vida del producto. Generalmente, se utiliza el 15% del tiempo total del desarrollo para la implementacin. Imagnense, solo es el 15% que algunas veces es el 20%. Muchas personas que estn involucradas en el desarrollo de software solo realizan esta actividad, dejando a un lado las otras. Para el Anlisis y el Diseo se utiliza el 60% del tiempo total y para la integracin y prueba un
futuro para la aplicacin a desarrollar

Mtricas
de la Industria de software
Slo el 15% del tiempo del desarrollo del producto de software se dedica a la programacin, algunas veces el 20% 60% del tiempo es para el Anlisis y Diseo 25% del tiempo para la Integracin y Prueba, algunas veces el (20%)
17
25%. Algunas veces, dependiendo de la complejidad de la aplicacin, el porcentaje de integracin y prueba se incrementa, porque existen aplicaciones con muchos casos que pueden producir un error o varios defectos. Como es de conocimiento general la tecnologa Introduccin al Desarrollo va desarrollndose muy rpidamente, uno de los de Software objetivos es solucionar problemas ms Hoy la tecnologa va desarrollndose complejos que abarcan ms requisitos de los muy rpidamente. Dando la posibilidad usuarios. Esto incrementa el esfuerzo de la de: creatividad para desarrollar o crear nuevos Solucionar requisitos ms complejos paradigmas y soluciones. Estas soluciones y Implementar soluciones ms complejas Implantar nuevos paradigmas nuevos paradigmas deben ser documentados de Desarrollar software ms complejo alguna forma para que futuras generaciones puedan estudiarlas y proponer sus propias soluciones.
7
Estas soluciones o nuevos paradigmas, respecto al software, toman en cuenta varias disciplinas o especialidades como por ejemplo: la habilidad de Soluciones complejas trabajar en equipo, planificar el tiempo propio, Desarrollo en equipo estndares de implementacin, el control de Planificacin cambio dentro de los artefactos creados en el Aseguramiento de la Calidad desarrollo de software. Todo esto en base a un Gestin de Configuracin Proceso Definido de Desarrollo Software que Proceso Definido de Software debe ser estudiado o por lo menos conocido por los desarrolladores. Entendiendo como artefacto como cualquier cosa que es producida o creada por las actividades dentro del desarrollo de software Como se puede evidenciar el desarrollo de Introduccin al Desarrollo software se ha convertido en una tarea muy de Software compleja, debido a los problemas surgidos en El Desarrollo del Software se ha dcadas pasadas. Dentro de las instituciones, el convertido en una tarea muy compleja software se hace tan indispensable que cuando que ha sobrepasado en gran medida la falla en un momento dado, la institucin se habilidad personal y empresarial para el paraliza o se retrasa, un retraso de unos minutos mantenimiento del software e incluso en el ciclo de vida conocido. significa un trabajo adicional de horas o a veces das. El Desarrollo de Software ha sobrepasado en gran medida la habilidad personal, es decir que es muy POCO PROBABLE que una sola persona pueda realizar todas las actividades que involucra el ciclo de vida del producto incluyendo el mantenimiento. El Desarrollo de software se ha convertido en una actividad multidisciplinaria. Como se mencion anteriormente, el software es Introduccin al Desarrollo difcil de desarrollar, pero toda institucin debe de Software tomar en cuenta la mejora de su proceso de Toda institucin debe iniciar desarrollo Surge una pregunta: muchas de las Una mejora del Proceso de Desarrollo de personas en nuestro medio no trabaja en una Software. Esto incluye el mantenimiento empresa de software, la cual desarrolla La Gestin del conocimiento sobre el cmo desarrollar software aplicaciones por qu la persona debe tomar en La definicin de sus actividades y del cuenta la mejora del proceso?.. Bien, en toda proceso institucin se maneja un determinado producto El control del desarrollo del software software, ya sea para la contabilidad, para la facturacin, inventario, etc. Este software, necesita ser mantenido o se realiza una planificacin para su mantenimiento. El mantenimiento seguir con el ciclo de vida del software (planificacin, anlisis, diseo, implementacin y prueba), el cual implica seguir un proceso de desarrollo. Cada mantenimiento o cambio debe ser documentado, para que ninguna de las personas involucradas sea indispensable. Es por este motivo que toda institucin debe tomar en cuenta la mejora del proceso de desarrollo. Tambin, se debe pensar en una gestin del conocimiento, ya que es necesario que las nuevas
19
20
21
8
personas que entren a trabajar ocupen el menor tiempo para el aprendizaje e integrarse en un tiempo ptimo al trabajo en grupo dentro de la institucin. Esta gestin del conocimiento permitir definir (poner en papel y de forma escrita) las actividades que se realizan para el desarrollo o para el mantenimiento. Es una responsabilidad del jefe de desarrollo o responsable del software llevar a cabo estas actividades con una calidad determinada, adems, est dentro de la tica profesional del Ingeniero de Software. Al desarrollar software no debe olvidarse de las Introduccin al Desarrollo metas presentadas en la diapositiva. de Software Una meta al desarrollar software es que los Se busca al desarrollar software desarrolladores deben hacer que los usuarios Cumplir con la necesidades del usuario final utilicen la tecnologa disponible al mximo. Esto Garantizar la calidad quiere decir, que si se desarrolla un software que Aumentar la cultura dentro de las personas que participan en el desarrollo corre en un CPU de 800 MHz y se solicita la Mejor empleo de la tecnologa y del compra de un CPU de 2,8 GHz para el software, conocimiento. Empleo correcto de los recursos y de la es muy posible que no llegue a utilizar de forma tecnologa total el CPU de 2,8GHz. Este es un ejemplo bsico que trata de representar la importancia de la planificacin de los recursos. Un ejemplo tradicional es el mal de las secretarias, generalmente a las secretarias de una determinada empresa o institucin se le da una maquina de ltima generacin para solo escribir y redactar cartas. Es muy claro que se pierden recursos. No se quiere decir, en ningn momento, que el trabajo de la secretaria no ocupa tiempo. Otro punto a considerar, en este mismo aspecto, es la Facilidad de Uso dentro de la interfaz, ya que esta es la que ayudar al usuario a interactuar con el software, si se tiene una Facilidad de Uso no planificada y llevada a cabo incorrectamente es muy posible que el software creado no sea el correcto, no utilice correctamente la tecnologa y, es muy posible, que se pierdan recursos. La Facilidad de Uso es un atributo de la calidad de software, muy importante por ser la que define la interaccin entre la aplicacin y el usuario. Muchos investigadores recalcan que la obtencin Introduccin correcta de los requisitos garantiza en gran medida un buen desarrollo de software. La parte fundamental del desarrollo de software es El problema de obtener un software que cumplir con los requisitos de los usuarios o cumpla con los requisitos de los institucin. La afirmacin, si se obtiene un usuarios y tenga una determinada calidad se inicia desde el momento de la software que cumple con los requisitos, es deteccin de los requisitos de un usuario posible gracias a las actividades de Prueba del Software, existen muchas, pero en el Mdulo V se ver un mtodo para validar el software desarrollado y ver de esa forma si cumple con los requisitos de los usuarios
Grupo de Investigacin Univalle - 2006 22 Grupo de Investigacin Univalle - 2006 23
9
Introduccin
La figura trata de expresar que si no se determina correctamente los requisitos es posible que los que participan en el desarrollo de software no comprendan lo que se quiere lograr. En la siguiente diapositiva se ve que todos deben hablar el mismo idioma para lograr un producto que cumpla con los requisitos.
24
Introduccin
Todos los del equipo deben entender, a la perfeccin, los requisitos y los objetivos del software a desarrollar, esto debe garantizar todo el proceso de desarrollo. El responsable del desarrollo de software son las personas involucradas en todas las actividades, es por eso que se afirma, el desarrollo de software es una actividad en equipo y se debe obtener la habilidad de trabajar en equipo.
25

Problemas
de la industria de Software
Entrega del Software excesivamente tarde Incremento del costo Medios y procesos indisciplinados Actividades y procedimientos no normalizados, son improvisados La empresa se dedica a apagar el fuego La planificacin en tiempo y recursos no se cumplen
Gracias a la experiencia se han detectado varios problemas que involucran a la industria de software y a las instituciones que tienen un grupo de desarrollo de software. En la diapositiva se pueden observar varios problemas, es seguro que uno o ms de estos han ocurrido en su institucin, empresa o en su carrera universitaria.
10
Dentro del ciclo de vida del software se han detectado varios problemas. El ms preocupante es el abandono de los programadores que se Problemas en el Desarrollo de Software hacen cargo de todo el desarrollo, ellos no (Dentro del ciclo de vida) documentan en absoluto su actualidad, ya que Retrasos en los plazos Rpido deterioro del sistema instalado (requisitos no es su rol. Es un problema muy comn, que en muy dinmicos) el mundo entero se trata de eliminar con Tasa de defectos, errores y fallas muy alta Requisitos mal comprendidos distintas polticas. El preparar a una persona para Cambios frecuentes en el dominio del problema que retome o finalice el desarrollo del software Buenos programadores se cansan y dejan el se convierte en algo imposible. equipo Otro problema muy comn es el seguimiento que se realiza a los requisitos, algunas veces son muy variables en el tiempo, este caso incrementa la posibilidad de que el software no cumpla con los requisitos de los usuarios o no se llegue a terminar con xito. Este problema es un riesgo que hay que controlar y hacer seguimiento. Otro problema a sealar es cuando no existe un entendimiento en el equipo de desarrollo, este problema va produciendo errores que incrementan los defectos en el software, estos defectos incrementarn el tiempo que dura el desarrollo. Algunos resultados de los problemas que existen Introduccin al Desarrollo en el desarrollo de software ya se han de Software mencionado, sin embargo, se sealan cuatro Los problemas en la industria de importantes de manera general, el primero es Software dan como resultado que la calidad y la funcionalidad se llevan al La calidad y la funcionalidad se llevan al limite lmite de no obtenerla. El segundo problema es No se puede cuantificar la calidad del software que no se puede cuantificar o medir la calidad No se sabe si realmente el software cumple los requisitos del usuario final (ms adelante definiremos lo que es calidad de Las revisiones y pruebas son eliminadas o se software), que involucra a todas las actividades realizan parcialmente del desarrollo de software, es decir que todas las actividades para el desarrollo deben realizarse de una forma ptima para que se pueda hablar de calidad.
27
28
El tercer problema, se genera cuando no existe suficiente tiempo para realizar las distintas pruebas al software. Esta actividad, la prueba del software, es la que permite validar el software contra los requisitos del usuario. El ltimo problema es la omisin del proceso de revisin, el cual es una actividad de control de calidad que permite realizar el seguimiento de varios aspectos dentro del desarrollo, como por ejemplo: las revisiones de la Facilidad de Uso, del desarrollo de la especificacin de los casos de uso o la implementacin, etc.
11

Calidad
y la Productividad se logra
Aplicando Metodologas y tecnologas para desarrollar y mantener el software Administrando los procesos de Software Realizando revisiones e inspecciones Documentando los procesos respecto a normas internas y estndares internacionales Planificar y documentar las pruebas
En la dispositiva se mencionan algunas polticas que se requieren para lograr calidad y, sobretodo, ser productivo a la hora de desarrollar software. El problema es: Cmo puedo lograr la calidad y ser productivo? Ms adelante, presentaremos algunos de los paradigmas mas recomendados en el mundo para el desarrollo de software.
En las siguientes diapositivas explicaremos algunos Modelos de Proceso de Calidad, los cuales pueden ayudar, en gran medida, en las instituciones y empresas de software a mejorar el proceso de desarrollo de software. Antes de continuar se define lo que es la Calidad Que de Software. hacer? Es el grado en el que el software satisface una serie de requisitos de operacin preestablecidos, los estndares de desarrollo especificados con anterioridad y las caractersticas inherentes a todo producto de software desarrollado de manera profesional (Pressman) Existen tres puntos importantes respecto a la definicin de la calidad de software que menciona Pressman y son: 1. Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad. 2. Los estndares definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera de software. Si no se siguen esos criterios, casi siempre habr falta de calidad. 3. Existe un conjunto de requisitos implcitos que a menudo no se mencionan. Si el software se ajusta a sus requisitos explcitos pero falla en alcanzar los requisitos implcitos, la calidad del software queda en entredicho. En prximos textos se hablar de la Calidad de Software en detalle, adems aprenderemos cmo podremos controlarla y llevarla a cabo. Dentro de la teora de TQM (Gestin de Calidad Total) la calidad de un producto es mayormente determinada por la calidad del proceso que es usado para desarrollar y mantener a este.
30
12
Cuatro puntos de la Calidad de Software

Proceso de Software
Personal Proyecto
Tecnologa Producto
31
Para continuar. Existen cuatro puntos importantes dentro de la calidad, cada uno de estos debe ser controlado y medido para ver si se va mejorando o si se est ejecutando correctamente. El primero es el personal, ya se ha dicho que es muy poco probable que una sola persona pueda lograr realizar todas las actividades del desarrollo de software. El desarrollo se debe realizar en equipo, el cual debe coordinar sus actividades. El segundo punto es el proyecto, este tiene un ciclo de vida, el cual debe ser planificado y controlado. En prximos textos hablaremos
de la Gestin de Proyectos de Software Otro punto importante es el producto, este tiene un ciclo de vida, las etapas son conocidas ampliamente (planificacin, anlisis, diseo, implementacin), pero el resultado, el producto, debe ser validado y certificado por alguna organizacin externa o por un grupo interno que garantice que el producto es el correcto, como todo producto tangible. Por ltimo, est el Proceso de Software, es el punto ms importante y ser el que dar los mrgenes para llevar a cabo el desarrollo, el proceso de software involucra la planificacin de los otros puntos ya vistos. El proceso opera en dos niveles (nivel organizacional y nivel de proyecto). A nivel de proyecto ayuda a satisfacer las metas del proyecto (Alta Calidad y productividad). A nivel de la organizacin ayuda a satisfacer los objetivos de la organizacin de poder predecir y mejorar. Dentro de la diapositiva existe un quinto punto, que es la Tecnologa. Si no se toma en cuenta, es muy probable no cumplir con los requisitos. No se puede desarrollar, hoy en da, un software en una maquina con un procesador 8086, ya que esta tecnologa es muy antigua y no va a cumplir con requisitos no funcionales del software. Ahora se ve algunos aspectos para entender lo El Proceso de Software que es el Proceso de Software. El conjunto de actividades, planes, controles, Un proceso es un conjunto de revisiones, pruebas, entre otros, forman parte de prcticas realizadas para alcanzar un proceso. Este conjunto debe apoyarse en un propsito dado; este puede herramientas, mtodos, personas y tecnologa. incluir herramientas, mtodos, La unin de estos puntos va conformando, a materiales, y/o personas. medida que pasa el tiempo, disciplinas para desarrollar un determinado producto. Todo lo sealado, est presente en el Proceso de Software. Con la diferencia de tener un Ciclo de Vida del Producto distinto.
13
Muchos grupos de investigacin en el mundo entero han tratado de estandarizar el proceso de software. Se dice que una organizacin es Algunos Modelos de Proceso de Calidad medible, si sigue un proceso definido. Un CMMI. Capability Maturity Model concepto de proceso definido es que todas las SPICE. Software Process Improvement and actividades estn descritas y estandarizadas. Capability dEtermination (ISO-15504) Desde los aos 80s se han detectado muchos ISO-9001: 2000 MSF (Microsoft Software Framework) problemas al desarrollar software, para muchos el software era incompleto. El mayor problema TODOS ESTABLECEN NIVELES DE era el mantenimiento, no se poda modificar MADUREZ EN EL DESARROLLO porque no exista una documentacin para aprender cmo estaba desarrollado. Es por eso que muchos grupos de investigacin han propuesto modelos de Proceso de Calidad para el Software, los cuales tienen como objetivo fundamental ayudar a obtener la calidad de software que es requerida para las organizaciones, cumpliendo con exactitud, eficacia y eficiencia sus requisitos. En la diapositiva se presenta algunos de los Modelos de Proceso de Calidad para el Software. Todos estos, establecen niveles de madurez en el desarrollo. La palabra madurez se puede interpretar como la capacidad de desarrollar correctamente y ptimamente una actividad. Es como el ciclo de vida como persona. A medida que pasa el tiempo y se crece, cada uno de nosotros, puede realizar ms actividades. A medida que se estudia, se aprende a resolver problemas. Debe pasar un tiempo de madurez para que las actividades, establecidas, para desarrollar software sean correctamente llevadas a cabo. Para lograr esto debe iniciarse con polticas de control de evaluacin de los procesos que se tiene en la empresa de software. Cada uno de estos procesos definidos, sealados en la diapositiva, es una gua para mejorar los procesos internos dentro del desarrollo de software. Veamos algunas de las caractersticas de los SPICE (Software Process Improvement and Capability dEtermination) modelos de proceso. La SPICE, ms conocida como ISO-15504 nos SPICE, es equivalente a la ISO-15504 ofrece la posibilidad de definir, desplegar y Surgi como un esfuerzo de colaboracin determinar procesos. internacional que deba materializarse en un nuevo estndar para la valoracin del proceso Procesos como Gestin, de relacin con el cliente del software y proveedor, la organizacin y por ltimo el La realizacin de pruebas de campo sera una proceso de soporte. labor fundamental Ha surgido, como cualquier norma ISO con la Nos permite valorar los procesos software, fomentando la auto-evaluacin colaboracin de muchas organizaciones internacionales, lastimosamente, esta norma se quedo en proyecto, no se aprob, esto quiere decir que no llego a ser norma internacional. Sin embargo es muy aconsejable tener conocimiento de las caractersticas y puntos de vista.
33
34
14
SPICE (Software Process Improvement and Capability dEtermination)

Evaluacin
del proceso, mejora del proceso y la determinacin de la capacidad Dos dimensiones:

Determina los procesos a ser valorados, definiendo el proceso de vida del software. Presenta una escala para evaluar la capacidad.
35
SPICE, tiene un procedimiento de evaluacin de los procesos, algo muy importante para poder certificarse. Se puede trabajar en dos dimensiones. Una es la determinacin de los procesos importantes para evaluarlos y la segunda dimensin es que determina una escala para la evaluacin de la capacidad. Se entiende la palabra capacidad como la habilidad de lograr algo.
ISO 9001:2000
Define
y establece la poltica y objetivos de calidad de una empresa permitiendo a la misma implementar los procedimientos necesarios para alcanzar las metas prevista Se basa en tres conceptos:
Los procesos La mejora continua Orientacin al cliente

Otra norma ISO es la 9001. Donde se establece que cada organizacin debe definir, establecer polticas y objetivos de calidad para cada uno de los procesos que le permiten alcanzar sus metas. Como se ve en la diapositiva se basa en tres conceptos, los procesos, la mejora continua y la orientacin al cliente.
ISO 9001:2000
Tiene

como premisa
Medir Mejorar Analisar

Medir El
Tiene como premisa medir los procesos para analizar y mejorar. Esta premisa, tiene embebido el control de calidad, ya que la medicin est involucrada en el plan de aseguramiento de calidad.
es la premisa fundamental seguimiento y medicin del producto es equivalente al control de calidad clsico
15
MSF (Microsoft Software Framework)

Se emplea como una metodologa gil Es flexible e interrelacionada con una serie de conceptos, modelos y prcticas de uso Se compone de varios modelos

Modelo de Arquitectura del Proyecto Modelo de Equipo Modelo de Proceso Modelo de Gestin de Riesgo Modelo de Diseo del Proceso Modelo de Aplicacin
Otro marco de trabajo es el de Microsoft, que ha liberado el MSF o Microsoft Solutions Framework. Muchos de los desarrolladores lo utilizan como una metodologa gil, sin embargo se adapta fcilmente a un desarrollo grande y complejo. Se compone de varios modelos, como se puede observar en la diapositiva.

CMMI
(2001)
Departamento de Defensa de los Estados Unidos El Instituto de Ingeniera de Software (SEI) Universidad Carnegie Mellon
Hewlett-Packard Company, Ericsson, IBM, Boeing, Computer Sciences Corporation , Motorola, Software Productivity Consortium
Por ltimo est el Modelo de Madurez de Capacidad Integrado liberado en el ao 2001 por el departamento de defensa de los Estados Unidos con la colaboracin del Instituto de Ingeniera de Software de la Universidad de Carnegie Mellon. En este proyecto han participado muchas instituciones y personajes del desarrollo de software, como se puede ver en la diapositiva. Se ve a continuacin algunas caractersticas de este modelo de calidad.
Desde la dcada de los aos 80s, muchas de las empresas que utilizaban software tenan problemas para el mantenimiento o para CMMI mantener nuevas funcionalidades del software El propsito del proyecto es proveer con el cual trabajaban. A medida que pasan los mejoras en costo, cumplimiento de aos el problema fue creciendo, es por eso que cronogramas y calidad de los proyectos Esta estructura por niveles de madurez desde mediados de los 90s, Estados Unidos se Cada nivel de madurez esta dividido por puso en la tarea de solucionar estos problemas, reas surgiendo lo que es CMM en su primera versin y ahora CMMI. Este ltimo tiene el propsito de minimizar el costo de desarrollo dentro del ciclo de vida, esto implica el cumplimiento de los distintos cronogramas que se planifican para lograr un software de calidad. Para el logro de este propsito debe incrementar el desempeo y para esto debe mejorarse la capacidad de todo punto de vista. Un ejemplo de capacidad y desempeo es el siguiente: Suponga un proceso: Codificar Probar Entregar De los datos de muchos proyectos se obtiene que la calidad de la capacidad del proceso es de 3-6 defectos por KLOC (miles de lneas de cdigo) Si se desea entregar el software con 2 defectos por KLOC, no se puede utilizar este proceso Conclusin: Debe mejorarse el proceso Cmo: Mejorar el proceso a Codificar Revisar Cdigo Probar Entregar
40
16
La calidad de este proceso es ligeramente mejor, es de 2-5 defectos por KLOC Si se usa este proceso se tiene la posibilidad de entregar a 2 defectos por KLOC Este proceso no puede entregar a 1 Defecto por KLOC Conclusin: Debe mejorarse el proceso Cmo: Mejorar el Proceso a Codificar Revisar Hacer Plan Revisar Plan Probar Entregar La calidad de este proceso ser mejor, es de 0.5-2 defectos por KLOC Se puede usar este proceso para entregar a 1 defecto por KLOC
Como otros modelos, CMMI est estructurado por niveles de madurez, se puede decir que est estructurado por escalones o gradas, que a medida que pasa el tiempo y logrando la mejora de las actividades del desarrollo de software se obtiene una madurez. Cada nivel de madurez est dividido por reas de trabajo. Que se explicarn muy brevemente a continuacin. Dentro de este modelo existen dos CMMI (Capability Maturity Model representaciones, una es Continua y la otra por Integration) Etapas. Esta divisin se debe, Existen dos representaciones fundamentalmente, a que muchas empresas han Continua. Permite formar una estrategia de mejora logrado certificarse por CMM, estas empresas que se adapte a las metas globales de la respectiva organizacin generalmente seleccionan la representacin Etapas. Est dividido por niveles de madurez Continua para volver a certificarse. Tambin, Nivel 1. Inicial Nivel 2. Administrado existen empresas que no estn certificadas por Nivel 3. Definido Nivel 4. Administrado Cuantitativamente CMM, si no por otro modelo, si estas empresas Nivel 5. Optimizado quieren certificarse por CMMI deben seleccionar la representacin Continua. Como se puede ver en la diapositiva, el objetivo es que permite formar una estrategia que se adapte a los procesos o actividades de la empresa que desarrolla software. Pero, otras que inician el camino de la mejora del proceso de desarrollo deben seleccionar la representacin por Etapas. Que se explicarn brevemente. Cada nivel es un objetivo dentro de las Introduccin al Desarrollo instituciones u organizaciones que desarrollan de Software software, cada uno de ellos garantiza al cliente CMMI, Niveles de madurez. (contratante o la organizacin a la cual pertenece Nivel 1 (Inicial). No hay proceso definido el grupo de desarrollo) que el software a Nivel 2 (Administrado). Administracin de requisitos desarrollar obtenga una calidad adecuada. Planificacin de proyectos Dentro del primer nivel de CMMI, no existe un Monitoreo y Control del Proyecto. proceso definido, esto quiere decir que es un Administracin del Acuerdo del Proveedor. Medicin y Anlisis. desarrollo a la suerte (muchas veces emprico o Aseguramiento de Calidad del Proceso y el Producto. artesanal), mucho riesgo de no culminar Administracin de Configuracin exitosamente con el desarrollo, pero se realiza el trabajo. El segundo nivel, tiene el nombre de Administrado, el cual se adhiere a la poltica del grupo de desarrollo, se siguen planes y procesos documentados, se aplican los recursos adecuados, se asignan responsabilidades y autoridad, se entrena al personal, se monitorea, controla y evala

Grupo de Investigacin Univalle - 2006 41 Grupo de Investigacin Univalle - 2006 42
17
procesos, identifica y envuelve a los involucrados y se revisa con la direccin El tercer nivel tiene el nombre Definido. El Introduccin al Desarrollo proceso del proyecto es personalizado desde el de Software proceso estndar de la organizacin, se entiende CMMI, Niveles de madurez Nivel 3 (Definido). el proceso cualitativamente, el proceso Desarrollo de Requisitos. Solucin Tcnica. contribuye a la mejora de la organizacin. En la Integracin del Producto. Verificacin. diapositiva se ve las reas que involucra este Validacin. Enfoque del Proceso Organizativo. nivel. Cada una de estas reas debe estar Definicin del Proceso Organizativo. Entrenamiento Organizativo. definida. Se entiende como definido que este Administracin integrada del Proyecto. Administracin de Riesgos descrito el proceso que se va a seguir, de esta Anlisis de Decisiones y Resolucin. Ambiente Organizativo para la Integracin. forma se est estandarizando el proceso. Una Equipo Integrado. estandarizacin es una definicin.
El cuarto nivel, denominado Administrado Cuantitativamente, mide el desempeo del proceso, estabiliza el proceso, controla los CMMI, Niveles de madurez cronogramas y trata las causas de las variaciones Nivel 4 (Administrado Cuantitativamente ) especiales. Como se ven en a diapositiva existen Desempeo Funcionamiento del Proceso Organizativo. dos reas, la primera est encargada de medir el Administracin Cuantitativa del Proyecto desempeo del proceso, en este nivel ya se tiene Nivel 5 (Optimizado) un proceso organizado y la segunda es la Innovacin y Despliegue Organizativo. administracin del proyecto. Anlisis de Causas y Resolucin El quinto nivel, denominado Optimizado, est dedicado a la prevencin de defectos, mejora proactiva, la innovacin tecnolgica se inserta y despliega, para esto existe un rea de Anlisis de Causas y Resolucin. Las ventajas de emprender el camino de la Introduccin al Desarrollo mejora continua del proceso son evidentes. En de Software primer lugar est el incremento de la Ventajas de CMMI productividad, mejorar la comunicacin con el Incremento de la productividad cliente, mejor comunicacin con los Mejor comunicacin con el cliente profesionales involucrados en el proyecto de Mejor comunicacin con los profesionales desarrollo y mayor satisfaccin de las solicitudes de la empresa o institucin Mayor satisfaccin de las solicitudes de los y requisitos de los clientes.
44
clientes
45
18
Conclusiones
Se
ha explicado brevemente los distintos captulos del documento, que permitirn realizar una aplicacin Web, lo ms importante es que se tendr parte de la documentacin correspondiente a la aplicacin
Al inicio de la presentacin se ha explicado las caractersticas y objetivos que tiene el texto. El objetivo principal de este texto y del conjunto de documentos es realizar una aplicacin Web que permita describir todo el Ciclo Bsico de Vida del Producto de Software.
46
Conclusiones
Se
ha logrado ver los problemas ms comunes en el desarrollo de software. No hay que olvidar que mantener un software es parte de las etapas que corresponde al ciclo de vida
Por lo menos debe seleccionarse una metodologa y cumplirla, de esa forma se puede iniciar la mejora del desarrollo de software y no tener los problemas anteriormente sealados. Otra alternativa para iniciar la mejora del Proceso de Software es, implementar algunas reglas o listas de comprobacin, que con el tiempo se pueden volver estndares dentro de la institucin y lograr que los desarrolladores hagan sus actividades correctamente
47
Conclusiones
Por
ltimo se ha visto algunos Modelos de Proceso de Calidad para el Desarrollo de Software, los cuales nos sirven de referencia para tomar polticas en nuestra vida como profesionales.
Es muy importante tener conocimiento de los modelos de calidad para el software. Este conocimiento no debe ser solo para los Ingenieros de Sistemas Informticos, sino para todos los que estn involucrados en la administracin de recursos para el desarrollo de software u otra persona que necesite evaluar un determinado software para su institucin u organizacin.
48
19
INTRODUCCIN A MICROSOFT .NET Iniciamos la aventura realizando una introduccin a Microsoft.NET

Intr o d u c ci n a
Micr os oft . NE T
O b je tivo s

I n t r o d u c c i n a Mi c r o s o f t . N E T C onocer
C o m m on
L a n g u a g e R u nti m e ( C L R , L e n g u aje
C o m n e n Ti e m p o d e Ej e c u ci n)
Mi c r os oft Int er m e diat e L a n g u a g e ( M S I L, L e n g u ajeI nt er m a di o d e Mi cros oft)
B a s e C l a s s Li b r a r y ( B C L , L i b r e r a d e cl a s e b as e)
Dentro de este conjunto de diapositivas veremos de forma bsica las caractersticas de la miniarquitectura Microsoft.NET. Conoceremos las caractersticas del Runtime, del cdigo MSIL, la Librera de Clases Base y el Sistema de Tipos Comn. Estas son la caractersticas principales que se debe conocer para comprender la nueva filosofa de programacin
C o m m o n T yp e S ys t e m ( C T S , Sis te m a d e Ti p os C o m n )
G r u p o d e I n v e s t i g a c i n U n i v a ll e - 2 0 0 6 2
Desde la segunda guerra mundial exista la iniciativa de crear una mquina que pueda ayudar a minimizar los clculos matemticos. La iniciativa fue marcada L a d c ad a del 80 fue m arc a da por el cuando el hombre llego a la Luna, sin embargo, las s urgi mi e nto d e la C o m p uta d o ra s computadoras de ese tiempo no podan ser P e r s o n a l e s y d e l a i nt e r f a z g r fi c a alcanzadas por las personas comunes. Es en la E n l a d c a d a d e l 9 0 I nt e r n e t p e r m i ti dcada de los aos 80s donde instituciones co ne ctar co m p ut ad oras e n una es c ala pequeas y personas con bastante dinero pudieron glob al tener una computadora. Esta dcada tambin se A h o r a , l o s S e r vi ci o s W e b b a s a d o s e n caracteriza por la definicin de una interfaz que X M L pueda ayudar a los usuarios a realizar su trabajo con la computadora. A mediados de la dcada de los 90s surgi, la denominada autopista de la informacin, Internet. Muchos conocen la historia de Internet. Ahora en este tiempo, se habla de los Servicios Web, que est en base a los protocolos (lenguajes) de comunicacin de Internet como el http o el XML, estndares internacionales de comunicacin. Los Servicios Web, son Sistemas de Servicios o Sistemas sin una Interfaz que permita interactuar con el usuario. Se ver con mayor profundidad los que es un Servicio Web durante el documento.
Intr o d u c ci n a Micr os oft . NE T
G r u p o d e I n v e s t i g a c i n U n i v a ll e - 2 0 0 6 3
20
Intr o d u c ci n a
Micr os oft . NE T
E l o b j e ti v o d e . N E T e s p e r m i ti r, a s u b si s t e m a s , c o m u n i c a r s e e n tr e s i y c o m o ta m b i n , a si s t e m a s h e t e r o g n e o s d e ntr o y fu er a d e la e m p r e s a
L a c o m u n i c a ci n d e b e s e r i n d e p e n di e n t e d el si st e m a o p e r ati v o, l e n g u aj e o m o d e l o d e pr o g r a m a ci n
Uno de los objetivos principales de .NET, es la comunicacin dentro y fuera de la institucin, sin importar la interfaz o el sistema operativo. Microsoft ha creado los Servicios Web y otras herramientas basadas en XML y otros protocolos, que dan la posibilidad de desarrollar aplicaciones que cumplan con este objetivo
G r u p o d e I n v e s t i g a c i n U n i v a ll e - 2 0 0 6
Introduccin a Microsoft .NET
Para conseguir la independencia entre la comunicacin se han creado varios estndares (http://www.w3c.org)

XML (Lenguaje de marcas Extendido), Es un formato universal para representar los datos SOAP (Protocolo de Acceso a Objetos Simples), Es un protocolo que permite mover los datos entre aplicaciones y sistemas. Es el protocolo que permite invocar a los servicios Web
Dentro de World Wide Web Consortium (W3C), se han aprobado varios protocolos que garantizan la independencia entre la comunicacin en distintos sistemas operativos, como por ejemplo: El XML, es un lenguaje que permite representar los datos SOAP, es un protocolo que permite manipular objetos simples entre aplicaciones y sistemas
5
UDDI (Descubrimiento, Descripcin e Integracin Universal), es un lenguaje que permite publicar, encontrar y usar los servicios Web basados en XML (Pagina Amarilla) WSDL (Lenguaje de Descripcin de Servicios Web), es un lenguaje que permite describir la funcionalidad que implementa un servicio Web
Otro protocolo es el UDDI, este es uno de los ms importantes, y que se usa para publicar y encontrar Servicios Web que estn disponibles a travs de Internet Y por ltimo, est el WSDL, que tambin es un lenguaje de descripcin para los Servicios Web
21
El Concepto fundamental de esta nueva tecnologa es integrar las aplicaciones a travs de una arquitectura orientada a sevicios, es una nueva manera de ver las cosas y hacerlas
Como se ha dicho anteriormente .NET est orientada los servicios, por este motivo es esencial entender correctamente la arquitectura que involucra esta tecnologa. Muchos autores hablan de una tercera generacin de Internet
Tercera generacin de Internet
Romper Barreras entre
Distintas aplicaciones con distintos lenguajes de programacin Los sistemas y la gente que los utiliza Las organizaciones que desarrollan
La meta de Microsoft con esta nueva tecnologa es romper barreras de todo tipo, como se ve en la diapositiva, se seala varias dificultades que se tenan al programar en distintos lenguajes y plataformas. Estas dificultades han tratado de ser resueltas con esta tecnologa. Usted ser el que juzgue al final de este documento si realmente Microsoft ha cumplido la tarea de romper estas barreras.
8
La plataforma de .NET no es ms que un conjunto de tecnologas para desarrollar y utilizar Formularios Web, Servicios Web y aplicaciones de Windows que se comunican a travs de XML
.Net no es ms que un conjunto de tecnologas que nos ayudan a llevar a cabo el desarrollo de software, pudiendo integrar formularios Web, formularios Windows y Servicios Web en una sola aplicacin basada en XML. Dentro del documento solo se ver en la parte de implementacin, la cual nos ayudar a llevar a cabo la codificacin.
22
Con las herramientas que proporciona .NET se puede crear un mundo de servicios de distintos tipos. Se puede colocar aplicaciones en varios servidores que estn conectados entre s, para lograr que distintos tipos de usuarios (por ejemplo Computadoras, celulares y otros componentes que utilizan los usuarios) obtengan los mismos servicios que el equipo de desarrollo ofrece, toda la comunicacin, ya sea, entre los servidores o los servidores a los clientes est a travs del lenguaje XML, que permite lograr esta comunicacin. Obviamente, cada usuario tendr una sugerencia para mejorar las aplicaciones. Un equipo de desarrollo solo puede dedicarse a desarrollar Servicios Web, para luego publicarlos y administrar su acceso, otros equipos se encargaran de desarrollar la interfaz que utilizarn los usuarios finales. Como se ha dicho anteriormente, se busca una Introduccin a Microsoft .NET aplicacin o plataforma para conseguir aplicaciones que se adapten al usuario y que el usuario no se Se busca crear una plataforma de adapte a la aplicacin. Se debe conseguir servicios Web para conseguir aplicaciones centradas en los usuarios, adems la aplicaciones centradas en el usuario informacin del usuario debe estar en los servidores La idea es que el usuario no debe adaptarse a la aplicacin sino por el y no as en el dispositivo que maneja la interfaz, a contrario la aplicacin debe reconocer al esto se conoce como cliente delgado
10
usuario La informacin del usuario no debe estar relacionada con ningn dispositivo
11
Los Componentes de la plataforma .NET pueden interactuar de distintas maneras. Esta comunicacin es permitida por los servicios Web que integran los distintos tipos de dispositivos y componentes
Como se ha dicho anteriormente todos los componentes que han sido desarrollados pueden comunicarse a travs de los Servicios Web que garantizan la integracin
12
23
Cuatro tipos de Interacciones

Cliente con Cliente Cliente con Servidor Servidor con Servidor Servicio con Servicio
13
Dentro de esta comunicacin existen cuatro tipos, como se puede ver en la diapositiva. Cliente con Cliente: Smart Clients o dispositivos pueden proveer de servicios Web y utilizarlos para permitir que la informacin est disponible en todo momento y lugar Cliente con Servidor: Los servicios Web permiten que un servidor comparta datos con una PC o un dispositivo mvil va Internet Servidor con Servidor: Una aplicacin en un servidor puede programticamente acceder a otra aplicacin utilizando un servicio Web
como interfase Servicio con Servicio: Un servicio Web puede invocar a otro, aumentando de esta manera la funcionalidad disponible .NET ofrece un entorno de ejecucin para sus Common Language Runtime aplicaciones conocido como CLR. La CLR es la (CLR) implementacin de Microsoft de un estndar El Runtime de Lenguaje Comn provee llamado Common Language Infraestruture. ste fue lo que se llama cdigo administrado es creado y promovido por la propia Microsoft pero decir un entorno que provee servicios desde hace aos es un estndar reconocido automticos al cdigo que se ejecuta mundialmente por el European Computer El CLR es el ncleo de la plataforma Manufacturers Association (ECMA). .NET. Es el motor encargado de gestionar la ejecucin de las El CLR/CLI esencialmente define un entorno de aplicaciones ejecucin virtual independiente en el que trabajan las aplicaciones escritas con cualquier lenguaje .NET. Este entorno virtual se ocupa de multitud de cosas importantes para una aplicacin: desde la gestin de la memoria y la vida de los objetos hasta la seguridad y la gestin de subprocesos. Todos estos servicios unidos a su independencia respecto a arquitecturas computacionales convierten la CLR en una herramienta extraordinariamente til puesto que, en teora, cualquier aplicacin escrita para funcionar segn la CLI puede ejecutarse en cualquier tipo de arquitectura de hardware. Por ejemplo Microsoft dispone de implementacin de .NET para Windows de 32 bits, Windows de 64 bits e incluso para Windows Mvil, cuyo hardware no tiene nada que ver con la arquitectura de un ordenador comn. El CLR esencialmente define un entorno de ejecucin virtual independiente en el que trabajan las aplicaciones escritas con cualquier lenguaje .NET
24
Common Language Runtime (CLR)
La estructura del CLR se la puede observar en la diapositiva, tiene varias funcionalidades para ofrecer a los desarrolladores. Una de las caractersticas del CLR es que genera el cdigo mquina nativo
15
Servicios del CLR

Cargador de Clases: Permite cargar en memoria las clases Compilador MSIL a nativo: Transforma cdigo intermedio de alto nivel independiente del hardware que lo corre a cdigo de mquina propio del dispositivo que lo ejecuta. Administrador de Cdigo: Coordina toda la operacin de los distintos subsistemas del Runtime de lenguaje comn Colector de Basura: Elimina de memoria objetos no utilizados. Motor de Seguridad: Administra la seguridad del cdigo que se ejecuta
Se puede observar algunos servicios del CLR: Los principales son el cargador de clases, el compilador MSIL a nativo , que es indispensable para que el cdigo se adapte a cualquier arquitectura, el Administrador de Cdigo que coordina las operaciones del CLR, el recolector de Basura que elimina a los objetos que no tienen enlaces y ya no sern usados, el motor de seguridad.
18
Servicios de CLR
Motor de Depuracin: Permite hacer un seguimiento de la ejecucin del cdigo aun cuando se utilicen lenguajes distintos. Chequeador de Tipos: Controla que las variables de la aplicacin usen el rea de memoria que tienen asignado. Administrador de Excepciones: Maneja los errores que se producen durante la ejecucin del cdigo Soporte de Hilos: Permite ejecutar cdigo en forma paralela Empaquetador de COM: Coordina la comunicacin con los componentes COM para que puedan ser usados por el Marco de Trabajo. Soporte de la Librera de Clase Base: Interfaz con las clases bases del Marco de Trabajo
Otros servicios son el motor de depuracin, el chequeador de tipos que permite realizar un control de la asignacin de memoria a las variables, el administrador de excepciones, que permite realizar un manejo de los posibles aspectos no controlados de la aplicacin, el soporte de hilos que permite realizar una ejecucin de cdigo paralela, el empaquetador de COM que permite comunicar a los componentes COM con el .NET Framework y por ltimo la librera de clases base que es una interfaz para la comunicacin con el .NET Framework.
25
Como se puede ver el CLR es el ncleo de la plataforma .NET ya que permite, mediante todos sus servicios, la ejecucin del cdigo.
Como se puede deducir, el CLR tiene la funcin de gestionar la ejecucin de las aplicaciones diseadas para la plataforma .NET
20
Una aplicacin .NET desarrollada en C# tiene diferentes niveles que pueden diferenciarse claramente, entre estos niveles se encuentran los editores y diseadores, que interactan con el cdigo fuente el cual va directamente al compilador que lo lleva al lenguaje intermedio, luego independientemente del lenguaje se realiza una verificacin, una compilacin JIT para pasar al cdigo nativo y luego a la ejecucin del CLR propiamente dicha
21
Microsoft Intermediate Language (MSIL)
Todos los compiladores de los lenguajes generan un cdigo MSIL y no un cdigo nativo Es como la mquina virtual de JAVA y precisamente el cdigo MSIL es el cdigo mquina de esta mquina virtual
Ahora veremos lo referente al lenguaje intermedio de Microsoft que es el generado por los compiladores y acta de manera similar a una mquina virtual de JAVA, ste cdigo es independiente a cualquiera de los lenguajes .NET que se utilice y de la misma manera es independiente al hardware de la computadora que se tenga y del sistema operativo
22
26
Por qu el MSIL?
Una aplicacin nativa no puede utilizarse directamente en otros sistemas operativos, en ocasiones ni en distintas versiones del mismo sistema, y tampoco se ejecutaran en otros procesadores Por tanto, por cada procesador y sistema operativo es necesario generar un cdigo nativo
La necesidad de tener el Lenguaje intermedio es evidente debido a que una aplicacin compilada en cdigo nativo no podra ejecutarse en un SO y en un procesador distinto al que fue compilado, lo que se logra con el MSIL es encontrar una manera de uniformizar todos los lenguajes de .Net para todas las plataformas tanto de software como de hardware
Por qu el MSIL?

.NET genera un cdigo intermedio Es independiente del sistema operativo y procesadores Para que un compilador genere un cdigo MSIL utiliza el Sistema Comn de Tipos
Como se dijo anteriormente el MSIL genera un cdigo que es independiente del lenguaje de programacin y de las plataformas, para lograr este cometido se usa el Sistema Comn de Tipos que logra unificar a todos los lenguajes.
24

El MSIL debe ser convertido a un cdigo nativo que entienda el CPU JIT se encarga de generar un cdigo nativo a travs del MSIL JIT ira generando cdigo nativo a medida que se necesite o se solicite. Solo se convierte una sola vez, a la segunda solicitud no es utilizado el JIT Por todo esto, se llama cdigo administrado
Posteriormente de tener un cdigo intermedio ste se debe traducir en un cdigo nativo que sea entendible por el CPU De esto se encarga el depurador JIT que es el depurador dinmico que utiliza la plataforma .NET, ste cdigo se va ejecutando a medida que se solicita, pero slo la primera vez, si se solicita un cdigo ya compilado al lenguaje nativo no se ejecuta el depurador JIT, todo lo anteriormente mencionado se denomina cdigo administrado.
27
Se muestra en la figura el diagrama de trabajo de .NET hasta la depuracin JIT , se muestra cmo se compila al MSIL, para pasar al compilador JIT y posteriormente pasar al cdigo nativo con el cdigo Administrado y el cdigo No Administrado que proporciona directamente el compilador del lenguaje.
26

File.asxp Qu lenguaje? Cdigo C# Compilador C# Compilador VB.NET HTML Compilador JIT Runtime Cdigo Nativo MSIL
Cdigo VB.NET
Ahora se muestra de manera grfica cmo trabaja la plataforma .NET dentro de un ejemplo prctico de una pgina Web en ASP.NET, lo que se muestra es que el archivo aspx se compila a MSIL por el compilador del lenguaje y posteriormente se lleva al compilador JIT para generar el cdigo nativo y todo ello se traduce en una pgina HTML.
27
Librera de clase base (BCL)
Es una librera incluida en el .NET Framework formada por cientos de tipos de datos, permite:
La BCL proporciona los bloques fundamentales para construir cualquier tipo de aplicacin, esta puede ser una aplicacin web, una aplicacin para Windows, o un servicio web.
Acceder a los servicios ofrecidos por el CLR Obtener funcionalidades ms frecuentemente usadas a la hora de escribir programas Crear nuevas clases mediante herencia
28

La BCL est estructurada en clases, cada una particularmente especializada. La BCL generalmente sirve como el punto principal de interaccin en el tiempo de ejecucin.
Esta librera est escrita en MSIL A travs de las clases suministradas en ella es posible desarrollar cualquier tipo de aplicacin
29

Espacio de nombres
System
Estas clases se conocen como namespaces. El namespace System incluye los tipos bsicos, por ejemplo string, int32, datetime, boolean, etc. System.Collections contiene interfaces y clases que definen contenedores como listas y arreglos. System.IO implementa clases clases de manipulacin de archivo y directorio, puertos seriales, etc. El espacio de nombres System.Reflection contiene clases e interfaces que proporcionan una vista administrada de los campos, los mtodos y los tipos cargados, con la posibilidad de crear e invocar tipos dinmicamente. Runtime.Remoting contiene clases que admiten y controlan los canales y los receptores de canales, que se utilizan como el medio de transporte cuando un cliente llama a un mtodo en un objeto remoto. System.Threading proporciona clases e interfaces que permiten la programacin multiproceso. Adems de clases para la sincronizacin de actividades de subprocesos y el acceso a datos
Utilidad de los tipos de datos que contiene Tipos muy frecuentemente usados, como los los tipos bsicos, tablas, excepciones, fechas, nmeros aleatorios, recolector de basura, entrada/salida en consola, etc. Colecciones de datos de uso comn como pilas, colas, listas, diccionarios, etc. Manipulacin de bases de datos. Forman la denominada arquitectura ADO.NET. Manipulacin de ficheros y otros flujos de datos. Realizacin de comunicaciones en red.
System.Collections
System.Data
System.IO System.Net

System.Reflection System.Runtime.Remoting System.Security System.Threading System.Web.UI.WebControl s System.Windows.Forms
Acceso a los metadatos que acompaan a los mdulos de cdigo. Acceso a objetos remotos. Acceso a la poltica de seguridad en que se basa el CLR. Manipulacin de hilos. Creacin de interfaces de usuario basadas en ventanas para aplicaciones Web. Creacin de interfaces de usuario basadas en ventanas para aplicaciones estndar. Acceso a datos en formato XML.
System.XML
29
Common Type System (CTS)
El CTS es utilizado por todos los lenguajes del framework .NET Una parte fundamental de .NET es CLR, donde el CTS no especifica ninguna sintaxis o tipo, sino define un conjunto de tipos comunes que pueden ser utilizados por los distintos lenguajes. Un ejemplo es el alias que utiliza C# para el tipo de datos System.Int32, que en este lenguaje se maneja como int
32
Sistema de Tipo Comn es el conjunto de reglas que han de seguir las definiciones de tipos de datos para que el CLR las acepte. Algunas reglas del CTS son las siguientes:
Cada tipo de dato puede constar de cero o ms miembros. Cada uno de estos miembros puede ser un campo, un mtodo, una propiedad o un evento. No puede haber herencia mltiple, y todo tipo de dato ha de heredar directa o indirectamente de System.Object.
Common Type System (CTS)
Los modificadores de acceso admitidos son

Cdigo desde el que es accesible el miembro Cualquier cdigo Cdigo del mismo tipo de dato Cdigo del mismo tipo de dato o de hijos de ste. Cdigo del mismo ensamblado Cdigo del mismo tipo o de hijos de ste ubicado en el mismo ensamblado Cdigo del mismo tipo o de hijos de ste, o cdigo ubicado en el mismo ensamblado
Existen modificadores que establecern las restricciones de acceso a los datos de una clase, entre ellos public que permite el acceso desde cualquier parte del cdigo. Private que permite el acceso solamente al cdigo a la clase a la cual pertenece. Family para acceder desde la misma clase o clases heredadas. El CLR es una parte fundamental del .NET framework
Modificador
public private family assembly family and assembly family or assembly
Resumen

Se ha visto lo importante que es el CLR dentro de la plataforma .NET Se ha explicado de manera general las funciones que tiene disponible el CLR Se dio un concepto general de los protocolos de comunicacin que utiliza .NET para interactuar con las distintas aplicaciones Se vio las caractersticas de la Librera de Clases, la cual nos permitir realizar aplicaciones
30
ELEMENTOS BSICOS DE PROGRAMACIN C# En este documento se realizar una introduccin al lenguaje de programacin C#, el lenguaje de Microsoft para el desarrollo de aplicaciones
Elementos Bsicos de Programacin con C#

Objetivos
Introduccin al lenguaje Caracterstica del lenguaje Tipos de Datos Espacios de Nombres Clases, objetos Visibilidad de una clase y sus miembros Manejo de excepciones

Los objetivos sealados en la diapositiva servirn para introducir a la programacin en C#.NET. Realizaremos una introduccin breve, pasando por algunas de las caractersticas del lenguaje, tipos de datos, espacios de nombres, la creacin de clases y objetos. Explicaremos, tambin, la visibilidad de cada clase que se utiliza y el manejo de excepciones tan importante para controlar los errores cometidos por el usuario.
Introduccin al Lenguaje C#

Es un lenguaje desarrollado por la Microsoft para la plataforma de .NET Sus principales creadores son Scout Wiltamuth y Anders Hejlsberg La sintaxis y estructuracin de C# es muy parecida a la de C++ o Java C# es un lenguaje de programacin que toma las mejores caractersticas de lenguajes preexistentes como Visual Basic, Java y C++
C# es un lenguaje de ltima generacin creado por Microsoft. Es el nico lenguaje que ha nacido exclusivamente en Microsoft. Por este motivo se considera a este lenguaje como el lenguaje nativo de .NET. Microsoft contrat al encargado de proyecto de Delphi, Anders Hejlsberg, el cual fue uno de los ms influyentes para la creacin de este lenguaje junto con Scout Wiltamuth. Ellos fueron los jefes de proyecto para C#. Este lenguaje tiene la influencia de varios otros lenguajes como c++, Java, Visual Basic, etc.
31
El
hecho de ser relativamente reciente no implica que sea inmaduro Su compilador es el ms depurado y optimizado de los incluidos en el .NET Framework SDK. El lenguaje C# no ha sido creado tan solo por y para Microsoft y su plataforma .NET
Conjuntamente con Intel y HP, a finales del ao 2000 Microsoft remiti al ECMA (European Computer Manufacturers Association)

El borrador del lenguaje C# El de CLI (Common Language Infraestructura)
Muchos de los desarrolladores han creado una resistencia a este nuevo lenguaje, sin conocer las nuevas caractersticas y la facilidad de aprendizaje. Como se puede leer en la diapositiva, este lenguaje ha sido considerado maduro y tiene las mismas facilidades que los otros e incluso el compilador es el ms optimizado respecto a las lneas de cdigo generadas para MSIL. El proyecto MONO ha desarrollado una versin de C# para Linux, esto quiere decir que este lenguaje no es exclusivo para .NET. En futuros aos se prev la posibilidad de programar en distintos Sistemas Operativos La historia de C# comienza el ao 2000 cuando Intel y HP colaboran con Microsoft para enviar el borrador de la especificacin de C# y el CLI a la ECMA. Esto significa que cualquiera puede crear un compilador de C# para cualquier sistema operativo, recurriendo al estndar definido en la ECMA
Una de las caractersticas fundamentales de este lenguaje es la sencillez. Se ver a continuacin algunos de los atributos de la sencillez para este Sencillez. lenguaje: El cdigo escrito en C# es autocontenido. Es Autocontenido, lo que significa que no Portabilidad del cdigo. necesita de ficheros o archivos No se incluye la herencia mltiple. adicionales Modernidad. Portabilidad del Cdigo, ya que los tipos La inclusin de una instruccin foreach que permita recorrer colecciones con facilidad y de datos bsicos son independientes del es ampliable a tipos definidos por el usuario compilador, sistema operativo o mquina No se incluye la Herencia mltiple, los macros utilizados en C++ o la necesidad de un operador diferente. Otro punto importante es la modernidad y una de las instrucciones novedosas es el foreach que permite recorrer colecciones como matrices, tablas, dataset, ect.
Caracterstica del lenguaje C#.
32

Orientado
a Componentes.
La propia sintaxis de C# incluye elementos propios del diseo de componentes. Es decir, la sintaxis de C# permite definir cmodamente propiedades, eventos o atributos
Todo el lenguaje est orientado a componentes, se utiliza clases base para la creacin de otras. La estructura de una clase est estructurada para la creacin de propiedades, eventos y atributos
Otra caracterstica es la seguridad de tipos de datos, como se especifica en la diapositiva
Seguridad de tipos.
Slo se admiten conversiones entre tipos compatibles No se pueden usar variables no inicializadas Se puede controlar la produccin de desbordamientos en operaciones aritmtica A diferencia de Java, C# incluye delegados, siguen un enfoque orientado a objetos Pueden definirse mtodos que admitan un nmero indefinido de parmetros de un cierto tipo
8
Tipos de Datos
Estos son todos los tipos de datos que ofrece el lenguaje para la programacin, existen otros tipos que no hay que confundir, son las clases comunes que utilizan todos los lenguajes de .NET, como por ejemplo el DataSet.
33
Variables
C#
requiere una asignacin definida, esto quiere decir que las variables deben ser asignadas o inicializadas antes de su uso. int Codigo = 12; string nombre = Pepe;
10
Constantes
Una
constante es una variable que no tendr un cambio en ejecucin. const int x = 1000; const char Nom= e ;
Toda variable hereda de una clase genrica denominada System.Object, la cual permite una conversin casi automtica hacia un tipo de dato string (cadena de caracteres). Toda variable debe ser inicia con un valor, es una de las reglas que no se debe olvidar. Los ejemplos que se muestran en la diapositiva definen a una variable de tipo numrica entera y la otra a una variable cadena de caracteres. El lenguaje C# es sensible a las maysculas y minsculas dentro del las letras, no es lo mismo X, como variable, a x, a estas dos letras las considera como variables distintas Las constantes son tipos de variables que no cambian de valor durante la ejecucin. Para declarar una variable debe adicionarse, al principio la palabra const, todo con minsculas, a continuacin el tipo de dato y el nombre de la constante, no hay que olvidar asignar un valor ya que es una de las reglas.
11
Enumeradores
Es una alternativa de una constante, pero el enumerador puede contener un conjunto de constantes o valores estticos implcitos dentro de su cuerpo. enum Temperaturas { TempMax = 34, TempMin = 5, TempAgradable = 23, }
Otra alternativa para definir una constante o varias constantes es el enumerador. Un Enumerador puede contener varias constantes, esta caracterstica sirve para agrupar algunas constantes que tienen alguna similitud. Un ejemplo se puede observar en la diapositiva. Se define un Enumerador con el nombre de Temperaturas. Dentro del enumerador existen tres distintas constantes, la Temperatura Mxima, Temperatura Mnima y la Temperatura Agradable.
34
Enumeradores
La definicin de los enumeradores es la siguiente: enum <nombreEnumeracin> : <tipoBase> { <literales> } Para poder visualizar o utilizar los valores de un enumerador solo se debe referencias al nombre del enumerador y a la constante. int Tiempo = Temperaturas.TempMax;
13
En la anterior diapositiva se ha visto una definicin de un Enumerador. De forma general el Enumerador debe definirse iniciando con la palabra enum, como se ve en la diapositiva, seguido con el nombre del enumerador y el tipo de datos que va a manejar, todas las constantes que estn dentro del enumerador heredar el tipo de dato. Para utilizar el enumerador solo se debe referenciar al nombre el enumerador, un punto y el nombre de la constante que est dentro del enumerador. La definicin de una cadena es relativamente fcil y similar a la definicin de una variable. Como se puede observar en la diapositiva, primero debe introducirse la palabra string, define que la variable va a ser una cadena, seguidamente el nombre de la variable string, en este caso Nombre. Como en todas las variables, esta debe iniciarse con un valor, en este caso Carlos Poppe
C a d e n a s (strin g)
P a r a d e fi ni r y u ti li z a r u n c o n j u n t o d e c a r a c t e r e s d e n o m i n a d o c a d e n a o s t ri n g s o l o s e d e b e d e fi ni r d e l a si g ui e nt e m a n era. s t ri n g N o m b r e = C a r l o s P o p p e ;
G r u p o d e I n v e s t i g a c i n U n i v a ll e - 2 0 0 6
14
Como en todo lenguaje existen instrucciones de decisin. La ms importante y la ms utilizada es if. Esta instruccin permite determinar un La instruccin if permite ejecutar camino de instrucciones a ejecutarse respecto a ciertas instrucciones slo si da una una decisin. La sintaxis se puede observar en la determinada condicin. diapositiva. Si existe ms de una instruccin debe if (<condicin>) iniciarse con un llave { y finalizar, tambin, con <instruccionesIf> una llave cerrada }, dentro de estas deben ir las else instrucciones o las lneas de cdigo. <instruccionesElse> La condicin nos determina un determinado camino, debe ir siempre entre parntesis (<condicin>). La palabra else determina un camino de instrucciones que se ejecutan cuando al condicin es falsa, de igual forma las instrucciones deben ir entre llaves {}.
if else
15
35
Se ve un pequeo ejemplo de cmo utilizar una sentencia de decisin. No se olvide que en el lenguaje C# existe una Ejemplo: diferencia entre maysculas y minsculas if (Codigo==123) Se inicia con la palabra if, a continuaci n la { condicin, que permite determinar el camino de } ejecucin para las sentencias o lneas de cdigo. else Esta condicin esta dentro de parntesis. Como { se ha dicho en la anterior diapositiva, si existe } ms de una lnea de cdigo para ejecutar, luego de la decisin, debe iniciarse con una llave { y finalizarse otra llave cerrada }. La palabra else es un camino alternativo cuando la condicin es falsa Estos son los operadores relacionales que se if else pueden emplear dentro de la condicin.
if else
16
Operadores
relacionales:
== (Igual), != (No Igual), > (Mayor), <(Menor), >= (Mayor igual), <=(Menor igual).
17
if else
Operadores
Estos son los operadores lgicos que se pueden utilizar dentro de la condicin
Lgicos:
& (AND), | (OR), ^ (OR exclusiva bit a bit), ! (Negacin), true (Verdadero), false (Falso)
18
36
switch
La instruccin switch permite ejecutar unos u otros bloques de instrucciones segn el valor de una cierta expresin. switch (<expresin>) { case <valor1>: <bloque1> <siguienteAccin> case <valor2>: <bloque2> <siguienteAccin> ... default: <bloqueDefault> <siguienteAccin> }
Una de las instrucciones ms utilizadas por los programadores es el switch. Que permite ejecutar bloques de cdigo o instrucciones de acuerdo a un valor de una variable o expresin. La sintaxis se la puede observar en la diapositiva
switch
Ejemplo switch(x) { case Jos: t=1; break; case Paco: t=2; break; default: t=0; break; }
Un ejemplo del cmo se puede utilizar el switch se puede observar en la diapositiva. Si el valor de la variable x es Jos, el valor de t sera 1. Si el valor de x fuera Paco, el valor de t sera 2. Si el valor de x fuera otro, por defecto el valor de t seria 0. La palabra break es obligatoria al final de cada case, significa que finaliza las instrucciones dentro de ese conjunto de instrucciones.
Espacios de Nombres (namespace)

Es
un espacio donde el desarrollador puede colocar sus propias definiciones. namespace Nombre { //definiciones }
Los Espacios de Nombre son muy utilizados por los programadores y adems por cada clase que se crea en cualquier entorno de Visual Studio se crea un namespace. En el siguiente documento donde se describe como crear una aplicacin sencilla en ASP.NET se explicar y identificar los Espacios de Nombre.
21
37
El namespace puede contener clases, las cuales sern utilizadas de una forma clara y ordenada. Para referirse a una clase u objeto dentro de un namespace slo se coloca el nombre del espacio, el punto y el nombre del objeto. namespace NombreEspacio { class cliente { string nombre; } } string nom = NombreEspacio.cliente.nombre;
22
Una alternativa para referirse a un espacio de nombre es la de adicionar la palabra using y el nombre del espacio using EspacioDeNombre; string nom = cliente.nombre
Como se explica en la diapositiva los Espacios de Nombre pueden contener un conjunto de clases, de esta forma se ordena el cdigo. Dentro de un Espacio de nombre no pueden existir dos clases con el mismo nombre, pero en distintos Espacios de Nombre puede existir dos clases con el mismo nombre. Lo que las diferenciara es el Espacio de Nombre. Para referirse a una clase en un Espacio de Nombre solo se debe colocar el nombre del Espacio de Nombre, un punto y el nombre de la clase. Esta expresin es similar a los Enumeradores ya vistos Generalmente al iniciar un proyecto o crear una clase, las primeras lneas contendrn Espacios de Nombres por defecto incluyendo la palabra using, como por ejemplo: using System.data using System.Web Estos Espacios de Nombres contienen clases por defecto que se pueden utilizar en cualquier momento dentro del cdigo.
23
Clases, objetos

En todo momento se trabaja con clases y objetos definidos. Las clases representan otro mecanismo para crear nuevos tipos de datos. Las clases, se definen como los enumeradores. C# es un conjunto de objetos que interaccionan unos con otros a travs de mtodos. class <nombreClase> { <miembros> }
Un objeto es una instancia de una clase. En todo momento utilizaremos clases para trabajar con objetos. La sintaxis simple para definir una clase se la puede observar en la diapositiva.
24
38
Clases, objetos
Todas las clases heredan de System.Object, que es la base de todos los tipos de datos de C#. Una clase esta conformada por:
Nombre Atributos o campos Mtodos o Servicios Eventos
25
Como se ha dicho en anteriores diapositivas toda variable o clase va a heredar de System.Object. Una clase que est conformada por: Nombre, Atributos que caracterizan a la clase Mtodos o servicios que se utilizan para determinar las actividades y funcionalidades que realizas una clase Eventos, que son sucesos que puede presentar la clase. En las siguientes diapositivas se aclarar un poco ms estos atributos. El nombre de la clase es la caracterstica que representa el elemento del cual se realiz la abstraccin. El nombre servir para identificar las posibles acciones que podemos utilizar. El nombre tiene que ser corto, claro y sin abreviaturas.
Clases, objetos
Nombre:
Es la caracterstica que representa el elemento del cual se realiz la abstraccin.
26
Un atributo es una caracterstica de una clase, como se puede ver en la diapositiva. La Clase Libro tiene varios atributos que son Atributo caractersticos de los libros, como por ejemplo: Es un dato comn que caracteriza a un objeto, algunas veces un atributo es un tipo de clase Nombre, Autor y NumPaginas class Libro Se puede apreciar que antes de un nombre de un { atributo se especifica el tipo de dato. Dentro del string Nombre; string Autor; ejemplo que se presenta en la diapositiva, el uint NumPaginas; atributo Nombre es de tipo string (cadena), el } atributo Autor es de tipo string y el NumPaginas es de tipo uint (numero entero) Tambin, como se puede apreciar los atributos estn dentro de dos llaves {}, que marcan el inicio y final de la definicin de los atributos.
Clases, objetos
27
39
Clases, objetos
Atributo
Cada uno de los atributos puede contener un valor, se comportarn como una variable, en una instancia podrn almacenar un solo valor
Cada uno de estos atributos contendrn un valor, Por ejemplo, el Nombre tendr el nombre de libro, el Autor ser el nombre del autor que ha escrito el libro y el NumPaginas contendrn el nmero de paginas que tiene el libro
28
Clases, objetos
Mtodos
o Servicios
Son actividades o servicios que corresponden una determinada funcionalidad de un objeto. En si un mtodo es un conjunto de instrucciones, si se quiere referenciar a un mtodo solo debe de colocarse el nombre del objeto, un punto y el nombre asociado a las instrucciones
Los mtodos son operaciones que puede realizar una clase. Dentro de la literatura son conocidos como actividades o servicios que identifican una determinada funcionalidad de una clase u objeto. Por lo tanto un mtodo ser un conjunto de lneas de cdigo que manipular o convertir un conjunto de datos en informacin.
La sintaxis para la definicin de un mtodo se la puede observar en la diapositiva. Dentro del C#, el primer atributo que hay que especificar para la Mtodos o Servicios definicin de un mtodo, es el tipo de dato que Dentro del conjunto de las instrucciones es devolver, solo se puede definir un solo tipo de valido referirse a los atributos y obtener o dato de devolucin. Luego, se define el nombre cambiar su valor. <tipoDevuelto> <nombreMtodo> del mtodo y entre parntesis estn los (<parametros>) parmetros de entrada. Al final est el cuerpo { del mtodo entre llaves {}. <instrucciones> El tipo devuelto ser el resultado de las } instrucciones y la manipulacin de los datos. Si no se quiere devolver ningn resultado solo debe colocarse la palabra void. Todo mtodo puede devolver un objeto. Si el mtodo devuelve algn objeto es necesario colocar la palabra return y el resultado u objeto al final, este debe ser compatible con el tipo devuelto definido para el mtodo. Los parmetros sern los valores o objetos que necesitan las instrucciones para elaborar o construir el resultado esperado al ejecutar el mtodo, estos deben cumplir la misma sintaxis de declaracin de un tipo de dato
Clases, objetos
30
40
Clases, objetos
Mtodos
y Servicios
Para llamar al mtodo NombreAutor del objeto L que corresponde a la clase Libro se debe realizar: string nomautor = L.NombreAutor();
Para poder llamar a un mtodo de una clase, primero se debe crear una instancia, luego a travs del objeto creado y un punto se puede llamar al mtodo. Al definir una clase se puede definir varios mtodos con el mismo nombre pero distintos parmetros. Esta utilizacin tiene el nombre de Sobrecarga de mtodo. C# ser el encargado de diferenciar entre los mtodos con el mismo nombre.
32
Clases y Objetos
Mtodos y Servicios
class Libro { string Nombre; string Autor; uint NumPaginas; string NombreAutor () { return Nombre+Autor; } string NombreAutor (string Fecha) { return Nombre+Autor+Fecha; } }
La diapositiva muestra un ejemplo de un mtodo que est en sobre cargado. Para poder llamar a estos mtodos veamos estos ejemplos L.NombreAutor(); //Devuelve el nombre del libro y el nombre del autor L.nombreAutor(12/12/2004); //Devuelve el nombre del libro, el nombre del autor y la fecha.
Clases y Objetos
Mtodos
y Servicios
Para definir un objeto se utiliza la palabra new, pero es necesario que la clase contenga un constructor que es en si un mtodo con el mismo nombre que la clase.
Para determinar una instancia de una clase u objeto se debe utilizar la palabra new seguidamente del nombre del constructor. El constructor es un mtodo que inicializa el objeto.
35
41
Clases y Objetos
Mtodos y Servicios class Libro { string Nombre; string Autor; uint NumPaginas; Libro(){} //Constructor string NombreAutor () { return Nombre+Autor; } string NombreAutor (string Fecha) { return Nombre+Autor+Fecha; } }
Veamos un ejemplo: se tiene una clase Libro, con atributos y mtodos. Adems aparece el constructor de la clase con el nombre de Libro(){}. Generalmente el nombre el constructor es el mismo de la clase
Clases y Objetos
Mtodos
y Servicios
Libro L = new Libro();
Para definir un objeto o una instancia, como se ha visto anteriormente, se utiliza la palabra new seguido del nombre del constructor. Una vez creado el objeto podemos referirnos a los atributos o mtodos de esa clase.
37
Visibilidad de una clase y sus miembros

La
visibilidad de una clase o sus miembros, como atributos y mtodos, est en funcin de los modificadores que se coloquen delante de la palabra class en el momento de su definicin. Estos modificadores pueden aplicarse a los miembros de las clases: mtodos, propiedades, variables, etc
Un factor importante para las clases y objetos es la Visibilidad. La visibilidad de las clases y sus miembros es algo que debe deducirse directamente del diseo lgico. Internamente, estas clases pueden utilizar otras no visibles desde el exterior, as como miembros privados y protegidos
42
Veamos algunas de las opciones que permiten determinar la Visibilidad. public. La clase, o el miembro, es visible en public todos los mbitos, no solo en el que se ha protected definido. Los miembros pblicos de una clase Private son accesibles, al crear un objeto, desde internal fuera de la propia clase. protected internal protected. Este modificador solo es aplicable a los miembros de una clase, no a la clase en si. Es decir, un miembro protegido no es accesible externamente 43todo43. Es el mbito ms reducido. Una clase privada solo puede utilizarse en el interior del mbito en que se encuentra incluida, ya sea un namespace u otra clase. Los miembros que tienen este modificador, igualmente, solo pueden ser usados desde el interior de la clase donde se han definido, nunca desde fuera, ni siquiera en clases derivadas. internal. Es similar al public. Si bien la clase o miembro es visible desde fuera de su mbito inmediato, esta regla solamente se aplica dentro del ensamblado al que pertenece. Una clase public puede usarse desde otros ensamblados, mientras que una internal no. protected internal. El resultado es que los identificadores pueden utilizarse en el ensamblado en que se han definido, as como en clases derivadas a pesar de que se encuentren en otros ensamblados La sintaxis para definir herencia es sencilla, se la Herencia pude observar en la diapositiva, la caracterstica fundamental al definir son los dos puntos : La herencia es una de los pilares luego del nombre de la clase hija. fundamentales de la programacin orientada a
Visibilidad de una clase y sus miembros
39
objetos, permite definir nuevas clases a partir de otras ya definidas de modo que si en la definicin de una clase indicamos que sta deriva de otra, entonces la primera es hija. class <nombreHija>:<nombrePadre> { <miembrosHija> }
43
Herencia
Los miembros definidos en la clase padre se aadirn a la clase hija. La clase padre no necesariamente debe estar en el mismo lenguaje que la hija. (Novedad) Se puede realizar una herencia en distintos lenguajes. public class ClaseBase { public string saludos() { Return Hola Sucre; } }
Todas las caractersticas como atributos y mtodos de una clase Padre sern heredadas a la clase Hija. Una de las novedades de .NET es que la clase Padre puede estar en un lenguaje diferente al que se est utilizando. Veamos un ejemplo. Se tiene una clase padre con el nombre ClaseBase con un mtodo que es pblico y devuelve una variable de tipo string, el nombre del 44todo es saludos Ahora se define una clase hija con el nombre de ClaseDerivada con un mtodo pblico y devuelve una variable de tipo int (entero), con el nombre de Cuadrado. Esta clase hereda de la clase padre con el nombre de ClaseBase. Esto significa que la ClaseDerivada tendr el mtodo de la clase padre con el nombre saludos. Pero, la clase padre no tiene el mtodo Cuadrado
Herencia
public class ClaseDerivada : ClaseBase { public int Cuadrado(int N) { Return N*N; } }
Polimorfismo
Es el concepto segn el cual objetos diferentes poseen implementaciones diferentes de una misma propiedad o mtodo.
Por ejemplo, un helicptero y un avin a chorro poseen el mtodo LevantaVuelo y la propiedad AltitudMax, sin embargo son implementaciones diferentes
Una de las caractersticas de la programacin orientada a objeto es el polimorfismo. Es el concepto segn el cual objetos diferentes poseen implementaciones diferentes de una misma propiedad o mtodo. Por ejemplo, un helicptero y un avin a chorro poseen el mtodo LevantaVuelo y la propiedad AltitudMax, sin embargo ambos tienen implementaciones diferentes
43
44
Estructuras
struct Point { public int x, y; public Point(int x, int y) { this.x = x; this.y = y; } } Punto p = new Punto(10,10); Punto p2 = p; p2.x = 100; Console.WriteLine(p.x);
Dentro de la programacin no pueden faltar las estructuras. Una estructura es un tipo especial de clase pensada para representar objetos ligeros. Es decir, que ocupen poca memoria y deban ser manipulados con velocidad, como objetos que representen puntos, fechas, etc. En el ejemplo de la diapositiva se puede comprender el uso de las Estructuras
44
Arrays
Un arrays o matriz es un tipo de variable que es capaz de almacenar en su interior y de manera ordenada uno o varios datos de un determinado elemento tipo
<tipoDato>[] <NombreArray>; int[] tabla = new int[100] {1, 2, 3 }; tabla[0]= 3; int x =tabla[0]; tabla.Length; //longitud de la matriz
Tambin, no puede faltar dentro de un lenguaje el manejo de una matriz o un vector, que permiten realizar distintas operaciones. Es muy sencillo definir una matriz, como se puede ver en la diapositiva.
Arrays
int[][] tablaDentada = {new int[] {1,2}, new int[] {3,4,5}}; int[][] tablaDentada = new int[2][5]; int[][] tablaDentada; int[][][] tablaDentada = new int[][][] { new int[][] {new int[5], new int[5]}, new int[][] {new int[4], new int[3]}}; tablaDentada[1][0][3] = 10
Cada vez que se adiciona una dimensin a una matriz es ms complicada la comprensin y la utilizacin
46
45
Arrays
int[,] tablaMultidimensional = new int[3,4] {{1,2,3,4}, {5,6,7,8}, {9,10,11,12}}; int[,] tablaMultidimensional = new int[3,4]; int[,,] tablaMultidimensional = new int[3,4,2]; int[][,][] tablaMixta; string[] tablaCadenas = {Manolo, Paco, Pepe}; object[] tablaObjetos = tablaCadenas;
Una de las caractersticas en este lenguaje es la definicin y manipulacin de matrices dentadas. Como se puede ver en el ejemplo de una tablaMixta.
47
Bucles
Instruccin While
while (<condicin>) {<instrucciones>} break. Indica que se va a abortar la ejecucin del bucle y continuando con la ejecucin por la instruccin siguiente al while. continue. Indica que se va a abortar la ejecucin de las instrucciones y revaluarse la condicin, volviendo a ejecutarse las instrucciones
Veamos algunas instrucciones que nos permiten realizar bucles de repeticin de lneas de cdigo. La primera es la instruccin While, mientras se cumpla una condicin se ejecutarn las instrucciones o lneas de cdigo que estn dentro de las llaves {}. Existen algunas palabras que nos permiten romper con el bucle o mandar a evaluar nuevamente la condicin. Como se puede ver en la diapositiva Otra instruccin de repeticin es el do while, se ejecuta una vez las instrucciones y se evala una condicin, si se cumple la condicin, es decir, si es verdadera, se ejecutan nuevamente las instrucciones
48
Bucles
Instruccin do while do <instrucciones> while(<condicin>);
49
46
Bucles
Instruccin for
for (<inicializacin>; <condicin>; <modificacin>) <instrucciones>
for (int i=1;i<=10;i++) {} Al igual que con while, dentro de las <instrucciones> del for tambin pueden incluirse instrucciones continue y break; que puedan alterar el funcionamiento normal del bucle.
Una de las ms utilizadas dentro de la programacin es la instruccin for. La sintaxis de esta instruccin es similar a la de C++. Como se puede ver en la diapositiva. Al igual que en la instruccin while se pueden utilizar las palabra que permiten romper el bucle o evaluar nuevamente la condicin
Bucles
La instruccin foreach es una variante del for pensada especialmente para compactar la escritura de cdigos donde se realice algn tratamiento a todos los elementos de una coleccin. foreach (<tipoElemento> <elemento> in <coleccin>) <instrucciones> string[] matriz; foreach (string mt in matriz) {}
Una de las instrucciones novedosas en los lenguajes de .NET es la de foreach, que permite realizar bucles a travs de conjuntos o colecciones de datos. Como se puede ver en el ejemplo de la diapositiva.
51
Fechas
El tipo de valor DateTime representa fechas y horas cuyos valores estn comprendidos entre la medianoche (12:00:00) del 1 de enero de 0001 d.C. (era cristiana) y las 11:59:59 de la noche del 31 de diciembre de 9999 d.C. (era cristiana).
Uno de los tipos de datos ms conflictivos para la manipulacin es la fecha y la hora, dentro de .NET existe una clase que maneja este tipo de dato y es DateTime
52
47
Fechas

DateTime.Date. Obtiene la fecha DateTime.Day. Obtiene el dia DateTime.DayOfWeek. Obtiene el da de la semana (17) DateTime.DayOfYear. Obtiene el da del ao (1364) DateTime.Hour. Obtiene la hora de la fecha. DateTime.Now. Obtiene la fecha y hora de la maquina. DateTime.ToDay. Obtiene la fecha actual. DateTime.Month. Obtiene el mes de la fecha. DateTime.Year. Obtiene el ao de la fecha
Estas son algunas de las operaciones que se pueden realizar con el tipo de dato DateTime. Como se puede ver, existen distintos mtodos que permiten obtener parte de una fecha u hora.
Manejo de excepciones
Las excepciones son el mecanismo recomendado en la plataforma .NET para propagar soluciones ante un defecto o falla durante la ejecucin de las aplicaciones
El manejo de las excepciones es un mecanismo muy importante dentro de la programacin, sirve para varias alternativas, la ms utilizada es para la validacin de los datos, el control de comunicacin con un servidor de datos u otro servicio externo a la aplicacin. Se ver a continuacin la sintaxis y la utilizacin de las excepciones
54
Existen tres cuerpos importantes dentro del manejo de excepciones, uno se inicia con la palabra try, las instrucciones que pertenezcan Bsicamente, son objetos derivados de la clase System.Exception que se generan cuando en tiempo de a try, sern las controladas bajo la excepcin, ejecucin se produce algn error y que contienen informacin sobre el mismo. es decir, si se produce un error en las lneas de try <instrucciones> cdigo que pertenecen a try se producir una catch (<excepcin1>) <tratamiento1> excepcin y .NET identificar la excepcin por catch (<excepcin2>) <tratamiento2> medio de los catch. Esta ltima palabra, es en ... finally si la excepcin que se produce, a partir de la <instruccionesFinally> palabra catch el tcnico programador puede introducir lneas de cdigo que puedan corregir el por qu de la excepcin o mandar un mensaje al usuario para que l la corrija. La palabra finally sirve para introducir lneas de cdigo que se van ejecutar si se produce o no una excepcin. Las lneas de cdigo que estn en el cuerpo de finally se ejecutarn siempre.
55
48
La instruccin throw, nos sirve para informar una error que se considera falta en la ejecucin de la aplicacin. throw <objetoExcepcinALanzar>;
El tcnico programador tiene la opcin de genera su propia excepcin por medio de la palabra throw, si el tcnico programador considera que existe un error puede generar un excepcin
56
try { int c = 0; int d = 2/c; } catch (DivideByZeroException) { d=0; } finally {}
Se puede observar un ejemplo en la diapositiva para el uso de las excepciones. El error que se produce es por la divisin entre cero. El catch es el encargado de identificar la excepcin. Si no existiera este manejo de excepciones dentro de la interfaz del usuario a parecer un mensaje de error que algunas veces es incomprensible. Es muy recomendable utilizar el try, catch y finally en el software que se desarrolla. El potencial de C# no ha quedado reducido, existen muchos grupos de discusin dentro de Internet que han logrado un nivel muy grande en el manejo de este nuevo lenguaje. Se considera a C# como el lenguaje nativo de Microsoft. En las siguientes pginas se realizara una introduccin a ASP.NET.
Conclusiones
Se ha logrado conocer algunos conceptos bsicos del lenguaje de Microsoft C#. Se ha logrado entender la sintaxis de las distintas instrucciones del lenguaje C#
58
49
IMPLEMENTAR LA PRIMERA APLICACIN EN WEB Antes de iniciar la aventura para la desarrollar la primera aplicacin Web, se har una introduccin a la nueva filosofa de programacin en ASP.NET. Internet (Interconnected Networks, redes interconectadas) es la red de redes de informacin, su evolucin fue y es vertiginosa con millones de usuarios conectados tratando de encontrar informacin que sea significativa. El inicio de Internet fue gracias al protocolo de comunicacin HTTP (HyperText Transfer Protocol), es decir que Internet utiliza este protocolo para poder comunicar a usuarios que buscan informacin, garantiza que cualquier cliente con un navegador estndar pueda conectarse con un servidor remoto. En la primera etapa de Internet solo existan pginas estticas en HTML (Hipertext Markup Language, Lenguaje de Marcacin de Hipertexto) las cuales se tratan como textos planos en formato ASCII con algunas cabeceras para la transmisin. Para poder acceder a estos documentos se tuvo que crear una direccin nica que se la denomin URL (Uniform Resource Locutor, Localizador uniforme de Recursoss) que indica tanto la localizacin exacta del recursos como el protocolo necesario para su transferencia. La forma genrica de la URL de una pgina Web es: Protocolo://www.servidor.dominio/carpeta/pagina.html Luego se incorporaron lenguajes como el Java o VBScript que permitieron colocar cdigo en paginas HTML. Esta incorporacin permiti a los desarrolladores a realizar pginas Web dinmicas, convirtindose en aplicaciones Web, el cdigo incorporado poda manipular datos dentro de una base de datos, pero todo el cdigo deba estar en la maquina del cliente, siendo una dificultad, ya que la maquina del cliente se volva muy lenta y consuma muchos recursoss. La siguiente etapa de Internet fue colocar cdigo en el lado del servidor para as, alivianar la maquina del cliente y incrementar la seguridad, ya que el usuario no debe acceder al cdigo. La tecnologa de Microsoft, para crear una aplicacin Web, fue ASP (Active Server Pages) que se ejecuta en el Servidor Internet Information Services. Las paginas ASP permiten mezclar HTML con cdigo como JAVA o VBScript. ASP se basa en CGI (Common Gateway Interface), se puede considerar que ASP es una evolucin de CGI. El siguiente paso para Microsoft, dentro del desarrollo de aplicaciones Web fue ASP.NET, esta nueva tecnologa permite desarrollar formularios Web y Servicios Web. Este ltimo, son componentes que pueden ser accedidos desde Internet y permiten desarrollar aplicaciones distribuidas y centradas en los usuarios. Un servicio Web es una aplicacin sin interfaz. Las Aplicaciones Web ASP.NET tienen varios componentes: Formularios Web o pginas .ASPX: Proveen de la interfase visual. No tienen cdigo ejecutable. Pginas de Cdigo por detrs: Estn asociadas con cada formulario y son las que proveen del cdigo ejecutable. A diferencia de las pginas ASP con la tecnologa anterior, no se mezcla cdigo y TAGs en la misma pgina. Archivos de Configuracin: Son archivos que permiten configurar la aplicacin, por ejemplo el archivo Web.config y el servidor por ejemplo el archivo machine.config. Global.asax: Es un archivo que contiene cdigo. Este cdigo responde a eventos que se disparan en la aplicacin Web. Enlaces a Servicios Web XML: Permite a la aplicacin Web transferir datos XML desde y hacia Servicios Web. 50
Conectividad a Bases de Datos: Permite a la aplicacin Web transferir datos desde y hacia distintas Bases de datos. Caching: Permite a la aplicacin Web devolver formularios Web ms rpidamente despus del primer acceso Se inicia el desarrollo de una pequea aplicacin Web que permitir introducir al mundo de la programacin orientada a objetos y a los conceptos nuevos de ASP.NET. Se utilizar Visual Studio 2005 para el desarrollo de la aplicacin Web. El entorno inicial de desarrollo se puede observar en la Pantalla 1
Pantalla 1: Entorno inicial e Desarrollo de Visual Web Developer Para crear una nueva aplicacin se debe realizar un clic en la opcin File del men principal y seleccionar New Web Site. Como se puede observar en la Pantalla 2.
51
Pantalla 2: Inicio de una nueva aplicacin Una vez seleccionada la opcin de New Web Site aparecer una pantalla para seleccionar el tipo de aplicacin que se quiere desarrollar como se puede ver en la Pantalla 3.
Pantalla 3: Seleccin de Tipo de aplicacin Como se puede observar, se puede seleccionar el tipo de proyecto, ya sea una ASP.NET Web Site o un ASP.NET Web Service. Adems, se puede seleccionar el lenguaje y la ubicacin (lo normal ser en el disco duro de la computadora que se utiliza, pero podramos elegir un sitio gestionado por FTP o http). Una vez seleccionado el lenguaje y haber introducido el nombre de la nueva aplicacin se debe realizar un clic en el botn OK. Una vez presionado el botn OK de la Pantalla 3, aparecer el entorno de desarrollo que se puede observar en la Pantalla 4.
52
Pantalla 4. Entorno de Desarrollo de la nueva aplicacin. Como se pude observar aparecen distintas pestaas como Tollbox, Solution Explorer y Properties. A estas pantallas se las puede ocultar parcialmente, solo se debe realizar un clic en el botn Auto Hide , que est ubicado en la parte derecha superior de cada una de estas pestaas. Como podr ver se ocultarn automticamente, para poder verlas solo debe pasar el cursor del Mouse por la etiqueta de la pestaa. Luego de realizar esta operacin nuestro entorno se podr ver de la siguiente forma (ver Pantalla 5).
53
Pantalla 5. Entorno de desarrollo con pantallas ocultas Veamos algunas de las caractersticas del entorno. El Solution Explorer sirve para mostrar las distintas aplicaciones en la cuales se est trabajando. Se puede observar el Solution Explorer en la Pantalla 6.
Pantalla 6: El Solution Explorer con la Primera Aplicacin Como se puede observar contiene un rbol en el cual existe un directorio o carpeta llamada App_Data y una pgina ASPX. Que es el inicio de toda aplicacin. Existe un rea de trabajo, donde podemos realizar el diseo de nuestra interfaz o introducir cdigo como ejemplo, podemos ver en la Pantalla 7.
54
Pantalla 7: rea de trabajo Contiene los diferentes editores de cdigo as como diseadores de diversos tipos (de interfaz de usuario, de clases, de DataSets). Es en donde se pasar la mayor parte del tiempo trabajando. En esta vista se muestra un editor de HTML. Otra pantalla es el Tollbox (Barra de Herramientas), cuadro de herramientas, el cual contiene a varios componentes ya diseados que permiten reducir el tiempo de desarrollo, sirven para disear la interfaz de usuario, aunque existen componentes no visuales, se puede observar el Tollbox en la Pantalla 8. Dentro de la Barra de Herramientas existe una clasificacin de componentes, que estudiaremos poco a poco durante el texto.
Pantalla 8: Barra de Herramientas (Tollbox) Existe una pantalla importante que es la de propiedades, que se puede observar en la Pantalla 9. Esta pantalla nos permite ajustar los valores de los componentes a nuestros requisitos en tiempo de diseo.
55
Pantalla 9. Propiedades de un componente Algunas de estas propiedades se pueden editar directamente, pero otras abren un asistente que nos ayuda a manipular las caractersticas de la propiedad. Por ltimo se tiene que describir las opciones de men vista en la Pantalla 10. Dentro de estas opciones se encuentran todas las caractersticas, configuraciones y vistas.
Pantalla 10. Men principal El entorno de trabajo que hemos explorado es muy intuitivo y fcil de utilizar. En la mayor parte de los casos se hace uso nicamente de los tres plantillas de diseo: diseador visual de formularios Web, diseador de HTML y editor de cdigo de C#. Existe una barra de botones que permita acceder a dos de estas plantillas la de Diseo Visual y la de HTML , est ubicada en la parte inferior izquierda del entorno de desarrollo, se puede observar en la Pantalla 11.
Pantalla 11. Pantalla de acceso a Diseo Visual y Cdigo HTML La tercera plantilla, que se puede observar en la Pantalla 12, es la que permite introducir lneas de cdigo. A esta plantilla se puede acceder por medio de un doble clic en la plantilla de Diseo Visual. Se ha descrito de manera general el entorno de desarrollo. Ahora, se inicia con un ejemplo que nos introducir a la programacin con C# en formularios Web. Se crear un ejemplo sencillo para ver cmo 56
se trabaja en el entorno del Visual Web Developer. Luego estudiaremos la estructura de los archivos generados para comprender su funcionamiento. El ejemplo que se desarrollar es el Juego al 7, el jugador que saque tres nmero con el valor de 7 ganar el juego. Se generar de forma aleatoria tres nmeros en un rango de 1 a 9. Para iniciar, realicemos un clic en el botn de Diseo Visual . Tenemos que seleccionar varios componentes de la Barra de Herramientas y colocarlos en la plantilla de Diseo Visual. El primer componente que se utilizar se encuentra en la papeleta de HTLM dentro de la Barra de Herramientas y es Table, que nos permite definir una rejilla en un formato tabla, como se puede ver en la Pantalla 12. Una vez realizada la seccin de este componente se debe arrastrar hacia la Plantilla de Diseo Visual, esto permitir colocar una tabla de tres columnas y tres filas.
Pantalla 12. Componentes HTML A primera vista, la tabla no se observa, ya que dentro de sus propiedades algunas estn en blanco, para poder visualizar se tiene que cambiar algunas propiedades que se encuentran en la Pantalla de Propiedades. La tabla introducida debe estar seleccionada para poder visualizar sus propiedades. En la Pantalla 13 se puede observar las propiedades de la tabla.
57
Pantalla 13: Propiedades del componente Table Las propiedades que se deben cambiar para poder visualizar la tabla son Border, CellPadding y CellSpacing, para cada una de estas propiedades se dar el valor de 1. Como se puede visualizar, el formato de la tabla cambiar como se puede observar en la Pantalla 14.
Pantalla 14. Formato cambiado de una Table Para el propsito del ejemplo solo utilizaremos tres columnas y dos filas, es decir que tenemos que eliminar una fila. Para hacer esta operacin debe realizar un clic derecho sobre la fila que se quiere eliminar, aparecer un men emergente como se puede ver en la Pantalla 15. Se debe seleccionar la opcin Delete y Rows, para culminar la operacin de eliminacin. Dentro del men emergente, tambin, existen otras opciones como de insercin de una fila o columna. 58
Pantalla 15. Men emergente del componente Table. El siguiente paso es colocar tres componentes Label de la Barra de Herramientas dentro de la categora Standard como se puede ver en la Pantalla 16.
Pantalla 16. Ubicacin del componente Label dentro de la barra de Herramientas Se debe arrastrar tres componentes Label a la plantilla de Diseo Visual y ubicarlos como se ve en la Pantalla 17.
59
Pantalla 17. Ubicacin de Label para el ejemplo Como se puede observar en la parte izquierda de los componentes Label, existe un icono de color verde . Este icono, significa que se ejecutar en el lado del servidor. Todo componente que tenga este icono se ejecutar en el servidor. Una vez ubicados los componentes Label, se tiene que realizar cambios en sus propiedades. Las propiedades que se cambiarn son Text y ID. Antes de cambiar se debe seleccionar un Label, realizando un clic sobre alguno de ellos. Para el Label1 el valor de la propiedad Text ser Nmero 1 y su ID sea L_Numero1 como se puede ver en la Pantalla 18.
60
Pantalla 18. Propiedades de Label Para el Label2, el valor de la propiedad Text ser Nmero 2 y su ID ser L_Numero2 Para el Label3, el valor de la propiedad Text ser Numero 3 y su ID ser L_Numero3 Una vez concluida la Plantilla de Diseo Visual se ver como en la Pantalla 19.
61
Pantalla 19. Etiquetas configuradas Una vez que se haya concluido con la configuracin de los Label, se debe introducir otros tres Label dentro de la tabla, los cuales nos servirn para mostrar los nmeros generados aleatoriamente entre 1 y 9, y otro que nos permitir mostrar mensajes. Cada uno de estos Label, en su propiedad ID tiene que llevar L_Aleatorio1, para el Label que esta debajo de Nmero 1, L_Aletorio2, L aleatorio3 y por ltimo, para el Label que nos permitir mostrar mensajes, L_Mensaje. Adems, se incluir un Botn que servir para generar los nmeros aleatorios cada vez que se realice un clic. La propiedades Text del botn se cambiar a Jugar y su ID ser B_Jugar, la plantilla de Diseo Visual quedar como se ve en la Pantalla 20.
Pantalla 20. Diseo Visual finalizado La Pantalla 20 muestra el diseo visual final, pero en la Pantalla 21 muestra el cdigo HTML que se genera a travs del diseo visual, para poder ver el cdigo HTML solo se debe realizar un clic en el botn Source .
62
Pantalla 21. Cdigo HTML del Diseo Visual El siguiente paso es introducir el cdigo en C#, que permita generar los nmeros aleatorios. Para realizar esto se debe seleccionar el botn B_Jugar, en la plantilla de Diseo Visual. Este tipo de botn tiene un evento llamado Click, que permite capturar el clic del ratn que realice el usuario y ejecutar un determinado cdigo. Para poder visualizar el evento se debe ir a la pantalla de propiedades y realizar un clic en el botn Event en la Pantalla 22. , una vez realizado se mostrarn los eventos del botn, como se puede ver
63
Pantalla 22. Eventos del B_Jugar Para poder introducir el cdigo debe realizar doble clic en el evento donde se introducir, luego de realizar esta operacin, automticamente a parecer la plantilla de Edicin de Cdigo, como se muestra en la Pantalla 23.
Pantalla 23. Editor de Cdigo
64
Como se puede ver aparece una nueva pestaa o papeleta en la parte superior con el nombre de Default.aspx.cs, la cual se ha generado automticamente, esta pestaa que realmente es un archivo dentro del disco duro almacenar el cdigo para la Default.aspx que es nuestro formulario Web. Tambin, se puede ver que el formulario Web Default.aspx.cs cumple con los requisitos y la estructura de una Clase. En la parte superior se encuentran Espacios de Nombre, estos se pueden utilizar en cualquier momento. En la parte inferior existen dos mtodos o eventos, uno con el nombre de Page_Load (se hablar de este mtodo ms adelante) y el otro es B_Jugar_Click. Este ltimo es el que interesa, ya que ser el encargado de generar los nmeros aleatorios. En la Pantalla 24 se muestra el cdigo para este evento.
Pantalla 24. Lneas de Cdigo para el Evento B_Jugar_Click En la lnea 22, 23 y 24 del cdigo se convierte un numero real Double a Entero por medio de (int). Una caracterstica de C# para convertir cualquier tipo de datos, no necesariamente a entero. Luego de introducir el cdigo, la aplicacin esta lista para ser ejecutada, para realizar esta actividad se debe hacer un clic en el botn Start Debugging o seleccionar del men principal la opcin Debug y Start Debugging. Cuando se ejecutada por primera vez, aparecer una pantalla de advertencias, que se la puede ver en la Pantalla 25, esta pantalla da la alternativa de crear un archivo de Web.config o ejecutar la aplicacin sin este archivo. El archivo Web.config permite configurar varias caractersticas de acceso y de formato dentro de una aplicacin Web, a medida que se avance en el documento se irn explicando la utilizacin de este archivo de configuracin.
65
Pantalla 25. Adicionar el archivo Web.Config a nuestra aplicacin Para nuestra aplicacin seleccionaremos la primera opcin. En la Pantalla 26 se muestra la ejecucin de la aplicacin. Si realizar un clic en el botn Jugar automticamente se generarn nmeros aleatorios.
Pantalla 26. Ejecucin de la Aplicacin Si se cierra el Internet Explorer, automticamente ir al entorno de desarrollo. Algo muy importante que se debe observarse es que dentro de la pantalla Solution Explorer, como se puede ver en la Pantalla 27, aparece un nuevo archivo que es el Web.config.
Pantalla 27. Solution Explorer con el archivo Web.config Como se ha visto, es muy fcil la programacin en ASP.NET. Ahora, modificaremos un poco la aplicacin, adicionaremos una clase, que contenga un mtodo que devuelva un nmero aleatorio entero entre el rango de 0 y 9. 66
Antes de iniciar la modificacin se tiene que hablar de algunas de las carpetas que se generan automticamente al crear una aplicacin Web. Como puede ver en la Pantalla 27, dentro del rbol de la aplicacin existe una carpeta por defecto que es App_Data. Esta carpeta puede contener los archivos de datos de aplicacin incluso los archivos MDF, archivos XML, as como otros archivos de almacn de datos. ASP.NET 2.0 utiliza la carpeta App_Data para almacenar la base de datos local de una aplicacin, que se puede utilizar para mantener informacin sobre suscripciones y funciones. Existen otras carpetas que se pueden utilizar en las aplicaciones Web. Para poder introducirlas solo debe realizar un clic derecho en la raz del rbol de la aplicacin como se puede ver en la Pantalla 28.
Pantalla 28. Carpetas de la Aplicacin ASP.NET reconoce estos tipos de nombre de carpetas de la aplicacin. Explicaremos brevemente cada una de ellas a continuacin: Bin. Contiene ensamblados compilados (archivos .dll) para los controles, componentes u otro cdigo al que desea hacer referencia en su aplicacin App_Code. Contiene cdigo fuente para clases de utilidad y objetos comerciales (por ejemplo, archivos .cs, .vb y .jsl) que debe compilar como parte de su aplicacin. Esta carpeta es la que utilizaremos para generar nuestra clase que nos permita generar nmeros aleatorios. App_GlobalResources. Contiene recursoss (archivos .resx y .resources) que se compilan en los ensamblados con mbito global. Los recursoss en la carpeta App_GlobalResources tienen un establecimiento inflexible de tipos y se puede obtener acceso a ellos mediante programacin. App_LocalResources. Contiene recursoss (archivos .resx y .resources) que estn asociados con una pgina especfica, control de usuario o pgina principal en una aplicacin. 67
App_WebReferences. Contiene archivos de contrato de referencia (archivos .wsdl), esquemas (archivos .xsd) y archivos de documentos de descubrimiento (archivos .disco y .discomap) que definen una referencia Web para utilizarla en una aplicacin. App_Browsers. Contiene definiciones del explorador (archivos .browser) que ASP.NET utiliza para identificar los exploradores individuales y determinar sus funciones. Theme. Contiene una coleccin de archivos (archivos .skin y .css, as como archivos de imagen y recursoss genricos) que definen el aspecto de las pginas Web y controles ASP.NET.
Pantalla 28. Carpeta App_Code adicionada a la aplicacin Una vez adicionada a nuestra aplicacin la carpeta App_Code como se puede ver en la Pantalla 28 podremos agregar una clase. Para hacer esta actividad se debe realizar un clic derecho en la carpeta App_Code y seleccionar Add New Item, como se puede ver en la Pantalla 29.
Pantalla 29. Adicionar una Item a la carpeta App_Code Una vez seleccionada esta opcin de Add New Item se visualizar una pantalla donde se debe seleccionar el tipo de archivo que se quiere adicionar a nuestra aplicacin. Para el propsito de la aplicacin se debe seleccionar Class , que contiene un plantilla estructurada por defecto de una clase en C#. Una vez seleccionada, se debe introducir el nombre de la clase, para nuestra aplicacin ser Numero, como se puede ver en la Pantalla 30.
68
Pantalla 30. Creacin de una nueva clase con el nombre de Numero.cs La pantalla de Solution Explorer cambiar como se puede ver en la Pantalla 31.
Pantalla 31. Nueva clase Numero.cs adicionada a la aplicacin La plantilla de Edicin de Cdigo visualiza el archivo Numero.cs como se puede ver en la Pantalla 32. Mostrando una estructura por defecto de una clase en C#.
69
Pantalla 32. Estructura de la clase Numero.cs Para continuar con nuestra codificacin a la clase Numero.cs adicionaremos un mtodo con el nombre de NumeroAleatorio y este mtodo sea pblico, el cual generar un nmero entero entre 0 y 9. Las lneas de cdigo se pueden observar en la Pantalla 33.
Pantalla 33. Lneas de Cdigo para el mtodo NumeroAleatorio de la clase Numero.cs El mtodo que se ha creado devolver un nmero entero, no se adicionan parmetros de entrada ya que no se necesitan. Para poder utilizar la clase Numero.cs en Default.aspx.cs se debe crear una instancia, esto se puede ver en la pantalla 34. La creacin de la instancia debe realizarse en el evento B_Jugar_Click. Las lneas de cdigo que se han introducido, en este ltimo mtodo, variarn un poco, como se puede observar.
70
Pantalla 34. Nuevo cdigo del evento B_Jugar_Click llamando a un mtodo de una clase Una vez modificadas las lneas de cdigo se podr ejecutar la aplicacin. Se ha finalizado con xito la primera aplicacin en ASP.NET. En el prximo documento modificaremos la aplicacin, anteriormente hecha, se utilizar un Servicio Web que generar los nmeros aleatorios.
71
IMPLEMENTAR UN SERVICIO WEB En el anterior documento se ha creado una pequea aplicacin Web, la cual ha servido como introduccin a la programacin en ASP.NET, adems hemos comprendido la programacin orientada a objetos. Al final de este documento se enlazar la aplicacin Web con el Servicio Web que ser creado a continuacin. En este documento se desarrollar un Servicio Web. Esta caracterstica dentro de la programacin Web ha cambiado mucho la visin de programacin, un Servicio Web es una aplicacin sin interfaz, es un componente que ofrece servicios a travs del protocolo http en base al lenguaje XML. En anteriores documentos se ha explicado los protocolos que utiliza la plataforma .NET para las aplicaciones Web. Los Servicios Web han dado origen a la Arquitectura Orientadas a Servicios, se basa en el uso de este tipo de componentes que suplen las necesidades de una o varias aplicaciones, son independientes entre s y trabajan independientemente del sistema operativo o la plataforma. Iniciemos la creacin de un Servicio Web. Tendr un mtodo o servicio que genere nmeros aleatorios entre un rango de 0 y 9 pero enteros. Para iniciar esta aventura se ejecuta el Visual Web Developed y se debe realizar un clic en la opcin del men File y seleccionar New Web Site, como se puede ver en la Pantalla 1.
Pantalla 1. Inicio de creacin para un Servicio Web Una vez seleccionada la opcin se visualizar una pantalla, ya conocida, la cual nos permitir crear un Servicio Web. Dentro de la pantalla se debe seleccionar ASP.NET Web Service, esta plantilla permitir crear un Servicio Web, adems se debe especificar el directorio donde se va a alojar, para este ejemplo, el directorio tendr el nombre de WS_PrimeraAplicacion, como se puede ver en la Pantalla 2.
72
Pantalla 2. Creacin de un Servicio Web Una vez que se realice un clic en el botn OK. Automticamente el Visual Web Developed crea varios archivos dentro del Solution Explorer, como se puede ver en la Pantalla 3. El archivo ms importante tiene la extensin .asmx, el cual permite acceder a los servicios a travs del protocolo http.
Pantalla 3. Archivos que Conforman el Servicio Web El archivo Service.cs, debe contener todos los servicios que se necesite, se puede ver en la Pantalla 4 la estructura de este archivo.
Pantalla 4. Estructura del archivo Sercive.cs 73

Se puede apreciar que existe un instruccin entre corchetes que es [WebMethod], esta instruccin es la que define si un mtodo ser publicado en el Servicio Web. Debajo de esta instruccin est definido un mtodo de tipo pblico que devuelve una cadena con el nombre de HelloWorld, dentro del cuerpo de este mtodo, se ve claramente que va a devolver la cadena Hello World. Lo anteriormente descrito pertenece a un mtodo de un Servicio Web. Para el propsito del documento se crear un nuevo mtodo que genere nmeros aleatorios, como se puede ver en la Pantalla 5.
Pantalla 5. Nuevo mtodo creado que devuelve nmeros aleatorios Como se puede observar, existen ya dos mtodos para el Servicio Web, lo que queda es ejecutar el Servicio Web. De igual forma que en las aplicaciones Web se visualizar una pantalla que dar a leccin si se quiere crear un archivo Web.config, el cual permite administrar el acceso y la configuracin del Servicio Web. Como se puede ver en la Pantalla 6. Se debe seleccionar la primera opcin para continuar con la ejecucin el Servicio Web.
Pantalla 6. Adicionar el archivo Web.config Al ejecutarse la aplicacin se abrir una pantalla del Internet Explorer, la cual mostrar todos los mtodos del Servicio Web, en este caso mostrar dos mtodos, como se puede ver en la Pantalla 7. Uno de los mtodos que se muestra es el que se ha creado con el nombre de NumeroAleatorio.
74
Pantalla 7. Mtodos del Servicio Web Si se realiza un clic en el mtodo NumeroAleatorio, se visualizar la especificacin del mtodo y un botn con el nombre de Invoke, este botn es el que ejecutar, realmente, las lneas de cdigo del mtodo, como se puede ver en la Pantalla 8.
Pantalla 8. Especificacin del mtodo NumeroAleatorio Si se realiza un clic en el botn se podr ver una nueva ventana de Internet Explorer con una estructura XML y dentro de ella el nmero aleatorio que se ha generado, como se puede observar en la Pantalla 9.
Pantalla 9. Resultado de invocar al mtodo NumeroAleatorio 75

De esta forma se ha terminado de desarrollar un Aplicacin Web utilizando el concepto de Servicio Web. A continuacin se explica cmo integrar la primera aplicacin Web con el primer Servicio Web desarrollado. Antes de integrar, el Servicio Web debe ser publicado en el Internet Information Server, para que pueda ser visto por la Aplicacin Web o por cualquier otra aplicacin. Para publicar una aplicacin Web o un Servicio Web se debe realizar un clic derecho en Mi PC dentro del Explorador de Windows, se visualizar un men emergente como se puede ver en la Pantalla 10.
Pantalla 10. Men emergente de Mi PC Una vez desplegado el men se debe realizar un clic en la opcin Administrar o Manage, la cual abrir una nueva pantalla de administracin de la computadora, que se puede ver en la Pantalla 11. Esta pantalla sirve para realizar la administracin de los servicios y cuentas de la computadora donde se trabaja.
Pantalla 11. Administracin de la Computadora En el rbol de directorios se puede visualizar Services and Applications (Aplicaciones y Servicios), si se realiza un clic en el signo ms (+), de esta opcin, podr ver otras. La que debe estudiarse, para publicar una aplicacin Web o un Servicio Web, es Internet Information Services Manager (IISM), al realizar un 76
clic en esta opcin mostrar varias carpetas que contienen distintos archivos de configuracin, como se puede ver en la Pantalla 12. De estas carpetas la que utilizaremos para crear un directorio virtual y por consecuencia publicar el Servicio Web es la de Web Sites.
Pantalla 12. Opciones de Configuracin de IIS Para crear un directorio virtual se debe realizar un clic derecho en Default Web Site, de inmediato se visualizar un men emergente que se puede observar en la Pantalla 13.
Pantalla 13. Opciones para crear un Directorio Virtual Una vez desplegado el men emergente se debe seleccionar las opciones New y a continuacin Virtual Directory. De inmediato se visualizar un asistente de Creacin de un Directorio Virtual como se puede ver en la Pantalla 14.
77
Pantalla 14. Asistente para Crear un Directorio Virtual Como en todo asistente se debe seguir las instrucciones. Para nuestro propsito se debe realizar un clic en el botn Next, donde inmediatamente se visualizar la Pantalla 15. Donde se debe introducir el nombre del directorio virtual, en este caso ser WS_PrimeraAplicacion.
Pantalla 15. Definicin del Alias del Servicio Web Una vez introducido el sobre nombre del directorio virtual se debe realizar un clic en el botn Next, de inmediato se visualizar la Pantalla 16. Donde se debe especificar y buscar el directorio donde se encuentra el Servicio Web creado como se puede ver en la Pantalla 16.
78
Pantalla 16. Definicin del directorio que almacena el Servicio Web A continuacin se debe realizar un clic en el botn Next, donde inmediatamente se visualizar la Pantalla 17, donde se debe especificar los derechos de acceso al directorio virtual, para la aplicacin se dejar las opciones por defecto.
Pantalla 17. Permisos de Acceso al Directorio Virtual Cuando se realiza un clic en el botn Next, de la pantalla 17, de inmediato se visualizara la Pantalla 18, que es el final del asistente para la creacin de un directorio virtual, solo se debe realizar un clic en el botn Finish para finalizar.
79
Pantalla 18. Final del asistente para crear un directorio virtual Se puede ver en la Pantalla 19 que se ha creado el directorio virtual, esto garantiza que el Servicio Web est publicado y que ya se puede utilizar en distintas aplicaciones, ya sea con interfaz Web o Windows.
Pantalla 19. Archivos del nuevo Directorio Virtual Se ha finalizado con la creacin de un directorio virtual, ahora se continuar con la integracin del Servicio Web con la Aplicacin Web. Para esto, debemos estar en el entorno de desarrollo de Visual Web Developed y haber cargado nuestra Primera Aplicacin Web. Para iniciar se debe realizar un clic en el nombre de la aplicacin dentro del Solution Explorer y seleccionar el directorio por defecto con el nombre de App_WebReferences, el cual tiene la caracterstica de contener las referencias a servicios Web que necesite interactuar la aplicacin. Como se puede ver en la Pantalla 20.
80
Pantalla 20. Adicionar el directorio App_WebReferences Una vez realizada esta actividad, se puede adicionar el Servicio Web que se ha creado en esta aplicacin. Para realizar esto, debe realizar un clic derecho en el directorio creado App_WebReferences, de inmediato se visualizar un men emergente donde se debe seleccionar la opcin Add Web Referente, como se puede ver en la Pantalla 21.
Pantalla 21. Adicionar una Referencia Web De inmediato se visualizara la Pantalla 22. Donde se debe seleccionar el link Web Services on the local machine, el cual nos permite visualizar todos los Servicios Web disponibles en la computadora local.
81
Pantalla 22. Adicionar una referencia Web La lista de los Servicio Web disponibles se la puede ver en la pantalla 23. El Servicio Web que se adicionar a la aplicacin Web ser: http://localhost/WS_PrimeraAplicacion/Service.asmx El cual contiene el mtodo para generar los nmeros aleatorios. Primero se debe seleccionar el Servicio Web y luego se debe realizar un clic en el botn Add Reference, como se puede ver en la Pantalla 23.
Pantalla 23. Agregar una referencia de Servicio Web a la Primera Aplicacin Una vez que se adicione el Servicio Web, en la aplicacin Web, dentro del Solution Explorer se adicionar un directorio con el nombre de localhost, como se pude ver en la Pantalla 24.
82
Pantalla 24. Adicin del primer Servicio Web a la Aplicacin Con esta accin se determina que realizaremos una referencias al servicio Web creado anteriormente, para poder utilizar el primer Servicio Web, de ahora en adelante se debe considerar como una clase, es decir, que necesitamos crear una instancia y crear un objeto que haga referencia al Servicio Web, como se puede ver en la Pantalla 25. La creacin de la instancia del Servicio Web se debe realizar en el evento Click de botn Jugar para este ejemplo. Cuando se crea una instancia de un Servicio Web, la utilizacin de esta instancia es similar a la utilizacin de la instancia de una clase, como en el documento anterior. El cdigo de evento variar como se ve en la Pantalla 25.
Pantalla 25. Cdigo para la utilizacin del Servicio Web dentro de la aplicacin Web Luego de introducir el cdigo de la Pantalla 25, lo que queda realizar es ejecutar aplicacin Web, esta ejecucin se la puede ver en la Pantalla 26. El comportamiento del botn es similar a lo anterior, en este caso se est refiriendo a un servicio Web que devuelve nmeros aleatorios.
Pantalla 25. Ejecucin de la Aplicacin Web con referencia a un Servicio Web De igual forma se puede realizar una aplicacin con interfaz Windows y hacer una referencia al Servicio Web, utilizando el mtodo de generar nmeros aleatorios. 83
De esta forma se ha finalizado la introduccin a la programacin con ASP.NET, en los documentos de la etapa de Implementacin se volver a tocar con mayor detalle la programacin en ASP.NET.
84
CAPTULO II
INGENIERA DE REQUISITOS Y ANLISIS
Objetivo Introducir y conocer la filosofa de las etapas de Ingeniera de Requisitos y Anlisis.
85
INTRODUCCIN A LA MODELACIN CON UML En este documento se hablar brevemente de UML (Lenguaje de Modelacin Unificado), tambin se darn algunos conceptos importantes de la tecnologa orientada a objetos.
DESARROLLO DE APLICACIONES WEB EN MICROSOFT C#.NET MODELADAS EN UML
Objetivos
Conocer
aspectos bsicos del lenguaje UML Usar adecuadamente los diagramas fundamentales del lenguaje UML
Los objetivos de este documento enmarcan los conceptos bsicos de UML y los diagramas que se utilizan para la modelacin de una aplicacin.
Sumario
Enfoques
en el anlisis y diseo de sistemas. Conceptos de la orientacin a objetos. UML y sus diagramas.
Un tema importante son los diagramas que se utilizan para la modelacin orientada a objetos, los cuales sern descritos durante todos los documentos que conforman esta aventura. Se mencionar brevemente los distintos enfoques que han permitido desarrollar software con xito. Por ltimo, conceptos bsicos sobre los distintos diagramas que utiliza UML que nos ayudan a desarrollar y entender el software.
3
86
Enfoques en el anlisis y diseo de sistemas
Enfoque estructurado:

Orientado a flujos de datos y funciones. Dominio de herramientas y lenguajes de programacin estructurada, orientados a flujos de datos que permiten una modelacin de las funciones o procesos de un sistema Autores principales:

Tom DeMarco Edward Yourdon Palmer y McMenamin
Enfoques en el anlisis y diseo de sistemas
Enfoque orientado a objetos:

Orientado a conceptos u objetos y relaciones entre estos. Exige un cambio de paradigma que no se satisface nicamente en utilizar un lenguaje o herramienta de orientacin a objetos
Uno de los enfoques que se ha utilizado mucho para la descripcin de las aplicaciones ha sido el Enfoque Estructurado, est orientado a los flujos de datos y funciones ayudados por una herramienta que es el Diagrama de flujo. Existieron muchas metodologas que se han utilizado para la documentacin de las aplicaciones con el enfoque estructurado. Estructurado se refiere al hecho de que las tcnicas son instrucciones cuidadosamente descritas, con frecuencia paso a paso, donde cada paso se desprende del anterior Dentro de la vida diaria se est rodeado de objetos, estos estn relacionados, cada uno de estos tiene un concepto y un significado. El concepto de objeto da como origen a este nuevo enfoque de orientado a objetos que cambia de paradigma a los programadores, analistas y diseadores. Este enfoque orientado a objetos, ha cambiado mucho el desarrollo de software en el mundo entero, dando origen a nuevos conceptos, teoras, modelos de procesos, metodologas, mediciones, actividades, estndares, etc. Es un total cambio de paradigma Para entender el enfoque orientado a objeto, primero se debe definir algunos conceptos que son importantes. Cada objeto que nos rodea tiene un nombre, varios atributos, acciones que se pueden realizar y por ltimo est conformado por partes que estn relacionadas para conformar el objeto. En la diapositiva se puede ver un ejemplo de objeto el cual tiene como nombre Martillo, tiene un atributo que es color y este atributo tiene el valor Blanco, se puede realizar una accin que es de golpear y est conformado de dos partes que son la Cabeza y Mango
Conceptos de la orientacin a objetos

OBJETOS
Nombre Martillo Atributos Color Blanco Partes Cabeza Mango Acciones Golpear
87
Tipo de Objeto:
Descripcin generalizada que coleccin de objetos similares
describe
una
Clase:
Implementacin en software de un tipo de objeto. Es el comportamiento de un tipo de objeto. A travs de ellas se encapsulan los datos. Implementacin en software de la operacin.
Operacin:

Mtodo:
Dentro de las aplicaciones varan algunos de los conceptos descritos, pero cada objeto debe pertenecer a un tipo de objeto, en el mbito de Software denominado clase. De esta ltima caracterstica pueden ser definidos varios objetos que se pueden utilizar dentro de las aplicaciones. Una clase est compuesta por un Nombre, Atributos y Operaciones, denominados en Software mtodos. Ms adelante en prximos documentos se hablara con mayor detalle de las caractersticas que incluye la definicin de una clase. Para comprender el enfoque orientado a objetos se ver algunos de los conceptos bsicos como: encapsulamiento, herencia y el polimorfismo. En las siguientes diapositivas se explicar estos conceptos bsicamente.

Caractersticas Distintivas
Encapsulamiento. Herencia Polimorfsmo

Todo el detalle, al estar encapsulado, es desconocido por el resto de la aplicacin, limitando el impacto de cualquier cambio en la implementacin del objeto, ya Caractersticas Distintivas que los cambios a las propiedades internas del objeto Encapsulamiento no afectan su interaccin externa. Obviamente Empaque conjunto de datos y mtodos cualquier cambio en la propia interface del objeto Atributos afectara potencialmente a todo el resto de la Operaciones aplicacin. Sin embargo el porcentaje de cdigo dedicado a las interfaces es por lo general muchsimo menor que el porcentaje total de lneas de cdigo utilizados para datos e implementacin de funciones. De tal manera se reduce la complejidad del sistema protegiendo los objetos contra posibles errores, y permitiendo lograr de mejor manera extensiones futuras en la implementacin de los objetos.
88
La herencia es una abstraccin importante para compartir similitudes entre clases, donde todos los atributos y operaciones comunes a varias clases se Caractersticas Distintivas pueden compartir por medio de la superclase, una Herencia. clase ms general. Las clases ms refinadas se conocen Propiedad de una clase de heredar el comportamiento de sus ancestros como las subclases Polimorfsmo. De manera simplificada, mediante el polimorfismo se Mecanismo que permite a la subclase definen funciones con el mismo nombre e interfaz en implementar la misma operacin con un mtodo diferente. distintas clases de objetos, pero bajo implementaciones distintas. El polimorfismo es til para extender la funcionalidad existente en los objetos del sistema, a nuevos objetos an desconocidos en ese momento. Es como definir un estndar de interfaces para los objetos la cual debe ser seguida por todos los existentes y nuevos. Haciendo una analoga, todo el tiempo aparecen nuevas aplicaciones de software que pueden ejecutarse en sistemas ya existentes. UML es un lenguaje que ha logrado ser un estndar a UML y sus diagramas nivel internacional para la descripcin del desarrollo de software, se base en la tecnologa orientada a Unified Modelling Language objetos. Muchos confunden a UML como una Es una notacin estndar para especificar metodologa, realmente es un apoyo hacia una sistemas con la tecnologa Orientada a metodologa. Es decir que una metodologa orientada Objetos No es una metodologa es un lenguaje a objetos tiene que basarse en UML. En posteriores Booch, Rumbaugh y Jacobson se unen diapositivas se ver la historia y la evolucin de UML para crear UML en estos aos, sin embargo se tiene que sealar que son tres investigadores muy conocidos en el mundo del desarrollo de software que se reunieron para crear las especificaciones bsicas de UML y apoyar a que sea un estndar internacional, ellos son Booch, Rumbaugh y Jacobson. James Rumbaugh propone en 1991 un artculo para UML y sus diagramas realizar la modelacin y el diseo orientado a objetos para el desarrollo de software. JAMES RUMBAUGH Otro investigador, en el mismo ao, publica otro Object-Oriented Modelling and Design 1991 artculo para el diseo orientado a objetos fue Grady (OMT) GRADY BOOCH Booch. Object Oriented Design with Applications El ltimo investigador, en el ao 1992, marca el inicio 1991 de la determinacin de requisitos a travs de los casos IVAR JACOBSON de uso, esta tcnica es utilizada por el Proceso Object Oriented Software Engineering: A Use Case Driven Approach 1992 (OOSE) Unificado de Rational. El artculo de Ivar Jacobson fue publicado en el ao 1992. Estos tres investigadores se reunieron para crear UML, Lenguaje de Modelacin Unificado
10
11
12
89
La primera versin de UML fue presentada en el ao 1997 a la OMG, esta, en el mismo ao, fue aprobada. Solo tard un ao en ser aprobada como un estndar Primera Versin a OMG (Object para la modelacin orientada a objetos y para el Management Group, Grupo de Gestin desarrollo de software. de Objetos), Enero 97 Las razones para usar UML difieren de acuerdo al Versin Final a OMG, Sep 97 contexto. Si alguno pregunta por qu cambiar de Aceptacin de OMG, Nov 1997 alguno de los mtodos anteriormente desarrollados por Rumbaught, Booch o Jacobson, la respuesta sera debido a que UML es uno de los ms desarrollados, es un real sucesor de los tres mtodos muy utilizados para la especificacin del desarrollo de software. La mayora de los nuevos CASE para el desarrollo de software soportan herramientas basadas en UML. La evolucin se inicia con la publicacin de artculos de Introduccin a UML Booch, Rumbaugh y Jacobson, los cuales se renen y crean un Mtodo Unificado en el ao 1995. Un ao despus aparece en Junio la primera versin de UML. Como se dijo anteriormente en el ao 1997 se publica la primera versin de UML. Desde ese entonces fue evolucionando hasta la versin 1.5 que fue al rededor de los aos 2001 y 2004 el estndar de desarrollo de software. En abril del 2004, se lanza la versin 2 de UML, la cual est dirigida a la produccin automtica de programas basados en la especificacin de software. Est compuesto por dos categoras de diagramas: Diagramas estructurales Diagramas dinmicos o de comportamiento Dentro de este conjunto de documentos se utilizar la versin 1.5 de UML. Se entiende diagrama como una representacin grfica de un conjunto de elementos, que la mayora de las veces se dibuja como un conjunto conexo de nodos (elementos) y arcos (relaciones). Cada caso de uso o flujo se compone de una secuencia UML y sus diagramas de eventos iniciada por el usuario de la aplicacin. Dado que los casos de uso describen la aplicacin a Casos de Uso y Diagrama de Casos de uso desarrollarse, cambios en los requisitos significarn cambios en los casos de uso. Se considera que un caso de uso es un requisito de la aplicacin. Un caso de uso es iniciado por un usuario o actor, los cuales representa los elementos fundamentales para Casos de uso el Diagrama de Casos de Uso. El Caso de Uso es el elemento ms importante dentro del desarrollo, aunque no se requiere mucha tecnologa para poder utilizarlo. Sin embargo, la correcta utilizacin y la completa descripcin marcan un inicio del desarrollo exitoso, el detalle que se introduce en la descripcin dar una visin muy clara de las caractersticas que son necesarias para la aplicacin o para el usuario. 90
Introduccin a UML
13
14
A Usuario
CU Reservar Habitaci n
(f rom Recepcin)
(from Actors)
CU Confirmar Reserva
(f rom Recepcin)
A Cliente
(from Actors)
A Recepcionista
(from Actors)
CU Sal ir del Hotel

(f rom Recepcin)
15
UML y sus diagramas

Diagrama
de Estructura esttica
Diagrama de Clases Diagrama de Objetos
El Diagrama de Clases es el diagrama principal para el anlisis y diseo. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La definicin de clase incluye definiciones para atributos y operaciones. El modelo de casos de uso aporta informacin para establecer las clases, objetos, atributos y operaciones. Est compuesto por dos elementos fundamentales, la Clase como tal y la relacin. Un Diagrama de Objetos representa una situacin concreta del dominio
16
El diagrama de transicin de estado (tambin conocido como DTE) enfatiza el comportamiento dependiente del tiempo del sistema. Este tipo de diagrama slo Diagramas de importaba para una categora de sistemas conocido Comportamiento como sistemas de tiempo-real. Determina la dinmica Diagrama de transicin de estado para cada clase del sistema, entendidas como las Diagrama de vistas de vidas posibles (estados vlidos) para las Actividad instancias de la clase. Un diagrama de Actividad demuestra la serie de actividades que deben ser realizadas en un caso de uso, as como las distintas rutas que pueden irse desencadenando. Es importante recalcar que aunque un diagrama de actividad es muy similar en definicin a un diagrama de flujo (tpicamente asociado en el diseo de Software), estos no son lo mismo. Un diagrama de actividad es utilizado en conjuncin de un diagrama de casos de uso, para auxiliar a los miembros del equipo de desarrollo a entender como es utilizado el sistema y como se reacciona en determinados eventos. Lo anterior, en contraste con un diagrama de flujo que ayuda a un programador a desarrollar cdigo a travs de una descripcin lgica de un proceso. Se pudiera considerar que un diagrama de actividad describe el problema, mientras un diagrama de flujo describe la solucin. Estos dos diagramas conocidos, tambin como UML y sus diagramas Diagramas de Interaccin, entendiendo la interaccin como: conjunto de mensajes intercambiados por los Diagramas de Comportamiento roles a travs de los roles de una asociacin. Diagrama de Secuencia El Diagrama de Secuencia, muestra la secuencia de Diagrama de Colaboracin mensajes entre objetos durante un escenario concreto, cada objeto viene dado por una barra vertical, el tiempo transcurre de arriba abajo y cuando existe demora entre el envo y la atencin se puede indicar usando una lnea oblicua. El Diagrama de Colaboracin es una descripcin de una coleccin de objetos que interactan para implementar un cierto comportamiento dentro de un contexto. Describe una sociedad de objetos cooperantes unidos para realizar un cierto propsito. Una colaboracin contiene ranuras que son rellenadas por los objetos y enlaces en tiempo de ejecucin.
UML y sus diagramas

Cliente
Mesero
Cocinero
Mozo del Bar
Solicitar servicio
Recepcionar Solicitud
Solicitud de Servicio
[Llena]
Solicitar Bebidas al Bar
Calcular Costo de Bebidas
Solicitud de Bebidas
Solicitud de Bebidas
[Llena]
[Con el Costo]
Verificar Solicitud de Bebidas
Precios incorrectos
Calcular Costo Total del Servicio
Verificar el costo del Servicio
Solicitud de Servicio
[Con el Costo]
Costo Incorrecto
17
: IABebidas
: EABebida
7: IntroducirBebida(int, int)
9: IntroducirBebida( )
8: IntroducirBebida(int, int)
5: Mostrar( )
PAdicionar : PAdicionar
3: BuscarHabitacion(string)
: CSWPersonal CPersonal : SWHotel : CPersonal SWHotel InsertarPersonal( ) InsertarPersonal( ) InsertarPersonal( )
: DTOPersonal
: AssemblerPersonal
: EAPersonal
LlenarDTOPersonal( )
1: BuscarCliente(string) 13: GrabarOrden( )
2: BuscarCliente(string)
: EAHabitacion
LlenarPersonal( )
14: GrabarOrden(int)
4: BuscarCliente(int)
BuscarNombre( )
: A Jefe de Cocina
: IAOrdenServicio
: CAServicio
InsertarPersonal( )
10: IntroducirComida(int, int)
InsertarPersonal( )
6: Mostrar( )
12: IntroducirComida(int)
: EACliente
11: IntroducirComida(int, int)
15: GrabarOrden(DataSet, DataSet)
: IAComidas
: EAComida
: EAOrdenServiocio
18
91
El Diagrama de Secuencia es ms adecuado para observar la perspectiva cronolgica de las interacciones, muestra la secuencia explcita de mensajes y son mejores para especificaciones de tiempo real y para escenarios complejos. El Diagrama de Colaboracin ofrece una mejor visin espacial mostrando los enlaces de comunicacin entre objetos, muestra las relaciones entre objetos y son mejores para comprender todos los efectos que tiene un objeto y para el diseo de procedimientos. El diagrama de Colaboracin puede obtenerse automticamente a partir del correspondiente diagrama de Secuencia (o viceversa). Un diagrama de componentes representa las UML y sus diagramas dependencias entre componentes de software, incluyendo componentes de cdigo fuente, Diagramas de Implementacin componentes del cdigo binario, y componentes Diagrama de Componentes ejecutables. Un mdulo de software se puede Diagramas de instalacin/Distribucin (Despliegue) representar como componente. Algunos componentes existen en tiempo de compilacin, algunos en tiempo de enlace y algunos en tiempo de ejecucin, otros en varios de stos. Los Diagramas de Despliegue muestran la disposicin fsica de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. La vista de despliegue representa la disposicin de las instancias de componentes de ejecucin en instancias de nodos conectados por enlaces de comunicacin. Un nodo es un recursos de ejecucin tal como un computador, un dispositivo o memoria Un requisito dentro del sistema se expresa a travs de Qu es Requisito? una funcionalidad necesaria para el usuario. Es muy necesario estudiar todos los requisitos ya que pueden El modelo de requisitos tiene como ser variables o cambiantes en el transtexto del objetivo delimitar el sistema y capturar la desarrollo de software, esto implica un riesgo de no funcionalidad que debe ofrecer desde la cumplirse exitosamente el desarrollo de software. perspectiva del usuario. Otra importancia sobre el requisito es la descripcin, si no est bien descrito no se podr logar una implementacin correcta para cumplir, influyendo en el tiempo y el esfuerzo que se empela para esta actividad.
ASPX
Servidor Web Servidor de Servicios Servidor de Base de Datos
ASPX.cs
ASCX
ASCX.cs
preemptive
<process name> <thread name>
Cliente de Hotel1
Swith
ASMX
ASMX.cs
Cliente Hotel 2
Router
Clases.cs
DTO.cs
SQLHelper. cs
Maquina del Cliente
Celular Cliente
19
20
Qu es Anlisis?
Distincin y separacin de las partes de un todo. Qum. Anlisis cualitativo, el que descubre y asla a los elementos de un cuerpo compuesto: anlisis cuantitativo, el que tiene por objeto determinar la cantidad de cada componente.
Dentro de la modelacin orientada a objetos el anlisis se entiende como: Con el anlisis orientado a objetos se puede examinar los requisitos desde la perspectiva de las clases y los objetos encontrados en el dominio del problema.
21
92
Qu es Diseo?
Traza
de un edificio, delineacin de una figura. Descripcin, bosquejo hecho por palabras. Disear: delinear, bosquejar, trazar.
El diseo orientado a objetos es un mtodo de diseo que se basa en el concepto de que el modelo del sistema es una coleccin de objetos que cooperan entre si para garantizar los requisitos del usuario y donde cada objeto es una instancia de una clase en una jerarqua de clases
22
Qu es Modelo?
Lo
que ha de servir de objeto de imitacin. Figura de barro, yeso o cera que se ha de reproducir en madera, mrmol o metal. Representacin en pequeo de alguna cosa
Existen muchos conceptos para modelo por la gran cantidad de ciencias dentro del mundo. Pero se pude interpretar como una abstraccin de la realidad para su estudio o su construccin.
23
Qu es Proceso de Desarrollo?
Es
el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema de software.
Proceso de desarrollo de software Sistema software
Requisitos del usuario
Dentro de la introduccin a estos documentos se ha tratado de explicar lo que es un proceso de desarrollo de software, sin embargo, dentro de la diapositiva, existe una definicin que sirve para el recuerdo, qu es un proceso de desarrollo? En resumen se tiene un conjunto de requisitos donde entrarn a un proceso de cambio para convertirse en una aplicacin o sistema de informacin o un software.
24
93
Conclusiones
Se
ha logrado una visin de general de UML dentro de las diapositivas. Se ha visto los distintos diagramas que se utilizan para la modelacin de una aplicacin Se definido el enfoque estructurado ya en desuso y tambin el enfoque orientado a objetos
Ha sido una introduccin a mundo de UML, que ayuda a la documentacin y sobre todo a entender de forma ms rpida el desarrollo de software. Es muy importante su estudio y sobre todo la aplicacin de estos conceptos, aunque son un poco tediosos para una sola persona cuando la aplicacin a desarrollar es grande, sin embargo es muy aconsejable la utilizacin para este tipo de aplicaciones de gran tamao ya que ordena y orienta a los desarrolladores. No se debe olvidar que el desarrollo de software es una actividad multidisciplinaria donde se debe trabajar en equipo.
94
INTRODUCCIN A LA MODELACIN DEL NEGOCIO Antes de iniciar la modelacin se hace una breve descripcin del negocio que se quiere automatizar, el cual servir para aprender la modelacin con UML y la utilizacin de Racional Rose. El negocio a estudiar es de una empresa Hotelera que presta servicio de hospedaje, con servicios bsicos como por ejemplo: servicios de alimentacin en la habitacin o los servicios bsicos como desayuno, almuerzo y cena. El registro de solicitudes de estos servicios hace el Mozo encargado del restauran del hotel, el que determina el costo del servicio es el Cocinero y el Jefe del Bar, uno determina el costo de la comida y el otro de las bebidas solicitadas por la persona hospedada. Es muy claro que a la persona que se le va a servir, ya sea en la habitacin o de un servicio bsico, debe estar registrada en el hotel. Antes de su registro debe realizar una reserva de habitacin para luego confirmarla, esta operacin la realiza la recepcionista. Una vez que la persona, que est hospedada, decide abandonar el hotel debe acercarse a la recepcionista para solicitar su cierre de cuenta y poder pagar el monto de dinero que ha costado su hospedaje. El primer paso para iniciar este camino es el Modelo del Negocio. Iniciemos sta aventura de modelar una aplicacin explicando de una forma muy breve el Modelo del Negocio. La obtencin del modelo del negocio es opcional, normalmente solo se realiza si ste trabajo es renumerado de forma independiente. Sin embargo, para conseguir sus objetivos una empresa organiza sus actividades por medio de un conjunto de procesos de negocio. Cada uno de ellos se caracteriza por una coleccin de datos que son producidos y manipulados mediante un conjunto de tareas, en las que ciertos agentes (por ejemplo, trabajadores o departamentos) participan de acuerdo a un flujo de trabajo determinado que es activado por una persona externa al negocio. Adems, estos procesos se hallan sujetos a un conjunto de reglas de negocio, que determinan la estructura de la informacin y las polticas de la empresa. Por tanto, la finalidad del modelado del negocio es describir cada proceso del negocio, especificando sus datos, actividades (o tareas), roles (o agentes) y reglas de negocio. No debe olvidarse que con la modelacin del negocio se estudia el flujo de informacin que est dentro de los procesos del negocio. Se entiende como proceso del negocio a una actividad que es llevada a cabo por personas involucradas dentro de la empresa. No se debe confundir con el proceso que sigue una aplicacin. En ningn momento se debe modelar la aplicacin futura dentro del Modelo del Negocio. Dentro de la experiencia que se tiene, existe una confusin muy errnea, muchos de los que se dedican a la modelacin establecen una igualdad o similitud del Diagrama de Casos de Uso del Negocio con el Diagrama de Casos de Uso de la Aplicacin. Como se ha dicho anteriormente el Diagrama de Casos de Uso del Negocio estudia los procesos del negocio como tal y el Diagrama de Casos de Uso de la Aplicacin estable los requisitos de la aplicacin a desarrollar. En prximos documentos se dar una explicacin de la determinacin de requisitos. Los objetivos principales de la Modelacin del Negocio son los siguientes: Entender la estructura y la dinmica de la organizacin Entender los problemas actuales e identificar mejoras potenciales Asegurarse de que los clientes, usuarios finales y desarrolladores tienen una idea comn de la organizacin Derivar los requisitos de la aplicacin Identificar los procesos en el negocio 95
Definir las fronteras del negocio que van a modelarse Definir quin y qu interacta con el negocio Crear diagramas del modelo de casos de uso del negocio
El Modelo del Negocio est compuesto por dos modelos uno es el Modelo de Casos de Uso del Negocio y el Modelo de Objetos del Negocio. El Modelo de Casos de Uso del Negocio est compuesto por el Diagrama de Casos de Uso, la Descripcin y el Diagrama de Actividad de los Casos de Uso del Negocio. Describe los procesos de negocio de una empresa en trminos de casos de uso del negocio y actores del negocio que se corresponden con los procesos del negocio y los clientes, respectivamente El otro Modelo de Objetos del Negocio es un modelo de objetos que describe cmo colaboran los trabajadores y las entidades del negocio dentro del flujo (realizacin). Estereotipos de la Modelacin del Negocio El responsable de utilizar estos estereotipos es el Diseador del Negocio, es una persona dentro de la empresa de software que tiene la labor de desarrollar, estudiar e identificar los elementos de un negocio. Se entiende la palabra estereotipo como representacin de una subclasificacin de un elemento del modelo. Un estereotipo puede tener su propio icono en el Rational Rose. Artefacto: Actor del Negocio
El actor del negocio representa un rol realizado en relacin al negocio por alguien o algo en el entorno de negocio. Otras relaciones: Rol: Opcional: Representacin en UML: Es parte del modelo de casos de uso del negocio. Diseador del negocio Puede ser excluido. Es un actor, estereotipado como actor del negocio.
Ingreso a las actividades: Detallar un caso de uso del negocio.
Salida de las actividades: Encontrar actores del negocio y casos de uso.
Propsito Las personas siguientes utilizan actores del negocio: 96

Analistas del sistema del negocio, al momento de definir el marco del negocio. Diseadores del negocio, al describir los casos de uso del negocio y su interaccin con los actores del negocio. Diseadores de la interfaz de usuario, como una entrada al capturar las caractersticas de los actores (usuarios) del sistema. Analistas del sistema, como una entrada para encontrar actores del sistema.
Propiedades Nombre de la Propiedad Nombre Descripcin Breve El nombre del actor del negocio. Es una breve descripcin de las responsabilidades del actor y el porque de la necesidad del actor del negocio en la organizacin. Representacin en UML El atributo nombre en el elemento del modelo. Caracterizado por ser texto corto.
Descripcin
Caractersticas
Utilizado principalmente por actores (personas) del negocio que actuarn como compradores o vendedores: Entorno fsico, nmero de personas Caracterizado por ser que el actor representa, grado de conocimiento de texto con formato. la organizacin, grado de experiencia en computacin, otras aplicaciones que el actor utiliza, y otras caractersticas como gnero, edad, etc. Generalizaciones y asociaciones de comunicacin en las cuales participa el actor del negocio. Cualquier diagrama comn al actor, pueden ser diagramas de casos de uso que expresen las asociaciones de comunicacin con otros casos de uso del negocio. A travs de la agregacin dueos A travs de la agregacin dueos
Relaciones
Diagramas
Cronologa Los actores del negocio se definen y relacionan con los casos de uso del negocio en la fase de concepcin, al momento de delimitar el proceso de la ingeniera del negocio. Responsabilidad Un analista del proceso del negocio es responsable de la integridad de los actores del negocio, debe asegurarse de cumplir los siguientes puntos:
Cada actor (persona) del negocio debe representar las caractersticas necesarias. 97
Cada actor del negocio debe enlazarse correctamente con las asociaciones de comunicacin para cada caso de uso con los cuales participa. Cada actor del negocio debe ser parte del grupo correcto de generalizacin. Cada actor del negocio define un rol cohesivo y es independiente de otros actores del negocio. Los diagramas de casos de uso que describen al actor del negocio son entendibles y consistentes con las otras propiedades.
Elaboracin Se debe decidir que propiedades utilizar y como usarlas. Se debe determinar el grado de detalle de las caractersticas a describir. Artefacto: Trabajador del negocio Un trabajador del negocio es una abstraccin de una persona en un sistema de software que representa el rol que lleva a cabo y sus tareas dentro del caso de uso del negocio. Un trabajador del negocio colabora con otros trabajadores del negocio, recibe notificaciones de eventos del negocio y manipula a entidades del negocio para cumplir sus responsabilidades. Otras relaciones: Rol: Opcional Ejemplos: Representacin UML: Clase, estereotipada como trabajador del negocio. Salida de las actividades: Detallar al trabajador del negocio Encontrar trabajadores del negocio y entidades Es parte del modelo de anlisis del negocio Diseador del negocio Puede ser excluido. Los trabajadores del negocio deben ser modelados si se considerarn cambios en la organizacin.
Ingreso a las actividades: Detallar al trabajador del negocio Revisar el modelo de anlisis del negocio
Propsito El trabajador del negocio se utilice para representar el rol de una persona o una aplicacin de software que cumple dentro de la organizacin. Esta abstraccin permite encontrar mejoras potenciales dentro de los procesos del negocio y considerar el efecto de la automatizacin del proceso del negocio o la tercerizacin del proceso del negocio. 98
La partes interesadas utilizan a los trabajadores del negocio para confirmar que las responsabilidades e interacciones del mismo reflejen correctamente como se realiza el trabajo, o como debera llevarse a cabo. Los trabajadores del negocio tambin se utilizan para considerar el impacto de los cambios en la organizacin (como la automatizacin del proceso del negocio). El diseador del negocio describe en detalle el flujo de trabajo de cada caso de uso utilizando a los trabajadores del negocio. Los trabajadores del negocio tambin son tiles para los analistas del sistema al momento de identificar los actores del sistema de software y los casos de uso, as se podr derivar los requisitos de la aplicacin. Propiedades Nombre de la Propiedad Nombre Descripcin breve Responsabilidades Descripcin Breve Nombre del trabajador del negocio. Breve descripcin del rol y propsito del trabajador del negocio. Un informe de las responsabilidades definidas por el trabajador del negocio. Esto puede incluir el ciclo de vida del trabajador del negocio. Las relaciones como generalizaciones, asociaciones y agregaciones en las cuales el trabajador del negocio participa. Las operaciones definidas por el trabajador del negocio. Los atributos definidos por el trabajador del negocio. Representacin en UML Atributo nombre en el elemento del modelo. Caracterizado por ser texto corto. Un valor predefinido de la superclase tipo
Relaciones
A travs de la agregacin dueos Perteneciente a la superclase Tipo mediante la agregacin miembros Perteneciente a la superclase Tipo mediante la agregacin miembros, algunos atributos pueden ser estereotipados.
Operaciones
Atributos
Caractersticas
Usado principalmente en personas que son Caracterizado por ser texto trabajadores del negocio: El entorno fsico del con formato trabajador, el nmero de individuos que el trabajador representa, el nivel de conocimiento del negocio, el nivel de experiencia en computacin, otras herramientas que utiliza el trabajador y caractersticas generales como gnero, edad, etc. Todos los diagramas relacionados con el trabajador del negocio, como diagramas de A travs de la agregacin dueos 99
Diagramas
interaccin o diagramas de estado.
Cronologa Los trabajadores del negocio son inicialmente definidos en la fase de concepcin y redefinidos y detallados en la fase de elaboracin. Responsabilidad El diseador del negocio es responsable de la integridad del trabajador del negocio, asegurndose de que: El nombre y la descripcin breve deben ser ilustrativos. Las responsabilidades estn correctamente descritas. El trabajador del negocio tiene las relaciones, atributos y operaciones apropiadamente definidas para cumplir a cabalidad sus responsabilidades.
Elaboracin Si se intenta modelar la manera en la cual los casos de uso se realizan actualmente, se puede utilizar a los trabajadores del negocio para representar los roles y los sistemas de software en la organizacin. En este caso se puede utilizar nombres que estereotipen como trabajador y sistema para representar a las personas y al sistema. Artefacto: Caso de uso del negocio Los casos de usos del negocio definen y determinan las instancias de los casos de uso del negocio en las cuales cada instancia es una secuencia de acciones que realiza un negocio, esta accin es significativa para un actor del negocio en particular. Otras relaciones: Rol: Opcional: Ejemplos: Representacin en UML: Casos de uso, estereotipados como casos de uso del negocio Salida de las actividades: Detallar un caso de uso del negocio. 100
Parte del modelamiento de casos de uso del negocio. Diseador del negocio. Puede ser excluido. Se utilizan cuando se necesita entender mejor o cambiar el proceso del negocio.
Entrada a las actividades:
Encontrar a actores y casos de uso del negocio. Detallar una entidad del negocio. Estructurar el modelo de casos de uso del negocio. Detallar un caso de uso del negocio. Detallar a un trabajador del negocio. Revisar el modelo de casos de uso del negocio. Estructurar el modelo de casos de uso del negocio.
Propsito Un caso de uso del negocio describe un proceso del negocio desde un punto de vista externo. Los casos de uso del negocio son procesos del negocio que atraviesan los lmites de la organizacin, pueden incluir socios y proveedores, para poder brindar ms valor al interesado en el negocio. Los casos de uso del negocio son tiles para proveer de informacin a quien necesite saber que valores proporciona el negocio y como interacta con el entorno. Los interesados, los analistas del proceso del negocio, y los diseadores del negocio utilizan los casos de uso del negocio para describir los procesos del negocio y entender el efecto de cualquier cambio propuesto (por ejemplo una fusin de organizaciones o implementar un CRM por primera vez) a la manera de trabajar del negocio. Los casos de uso del negocio tambin se utilizan entre analistas del sistema y arquitectos de software para entender la manera en que la cual un sistema de software encajara en el negocio. Los administradores de pruebas utilizan estos casos de uso para abastecer de informacin en la creacin de escenarios de prueba para el sistema de software. Los administradores del proyecto utilizan los casos de uso del negocio para planificar el contenido de las iteraciones del modelamiento y su supervisin. Propiedades Nombre de la Propiedad Nombre Descripcin breve Metas del rendimiento Flujo de trabajo Descripcin Breve El nombre del caso de uso del negocio. Breve descripcin del rol y propsito de caso de uso del negocio. Especificacin de las mtricas relevantes al caso de uso del negocio, y definicin de los objetivos al utilizar esas mtricas. Una descripcin textual del flujo de trabajo que el caso de uso representa. El flujo debe describir que Representacin en UML El atributo nombre en el elemento del modelo. Caracterizado por ser texto corto. Caracterizado por ser texto corto con formato. Caracterizado por ser texto corto con formato. 101
hace el negocio de forma significante para el actor, y no que hace el negocio para resolver sus problemas. La descripcin debera ser fcil de entender para cualquier persona de la organizacin. Categora El caso de uso puede pertenecer a la categora central, de soporte o de administracin. Caracterizado por ser texto corto. Opcionalmente se pueden utilizar diferentes iconos para diferenciar las distintas categoras. Riesgo Especificacin del riesgo de ejecutar o implementar el caso de uso. El riesgo se define en trminos de la diferencia potencial del valor esperado y el valor previsto. Descripcin de la mejora potencial del caso de uso del negocio. Definicin del propietario del proceso del negocio, es decir la persona que administra y planifica los cambios. Las caractersticas y cuantificadores del caso de uso del negocio que no se especifican en el flujo de trabajo que fue descrito. Caracterizado por ser texto corto con formato.
Posibilidades Propietario del proceso Requerimientos especiales Puntos de extensin.
Caracterizado por ser texto corto con formato. Caracterizado por ser texto corto con formato. Caracterizado por ser texto corto con formato.
Una lista de sitios del flujo de los eventos del caso de Caracterizado por ser uso del negocio en el cual se pueden insertar texto corto con formato. comportamientos adicionales utilizando relaciones de extensin. Dependencias estereotipadas indicando las metas del negocio alcanzables por el caso de uso del negocio. Relaciones como asociaciones de comunicacin, relaciones de inclusin y extensin, en las cuales el caso de uso del negocio participa. Estos diagramas muestran la estructura del flujo de trabajo. Dependencia
Metas soportadas por el negocio Relaciones
A travs de la agregacin dueos. Mediante agregaciones de tipos y relaciones en colaboraciones hacia el caso de uso. Mediante agregaciones de tipos y relaciones en colaboraciones hacia el 102
Diagramas de actividad
Diagrama de casos Estos diagramas muestran las relaciones que de uso conciernen al caso de uso del negocio.
caso de uso. Ilustraciones del flujo de trabajo Bosquejos hechos a mano como resultado de los eventos captados en las sesiones con la parte interesada.
Descripcin breve Los casos de uso se pueden desarrollar en una herramienta de modelamiento visual, por ejemplo Racional Rose. Cronologa Los casos de uso se identifican y si es posible se describen brevemente tempranamente en la fase de concepcin para ayudar a definir el alcance del proyecto. Si el modelamiento del negocio se hace como parte de un proceso de (re)ingeniera del negocio entonces los casos de uso arquitecturalmente significativos sern detallados durante la fase de elaboracin y el resto durante la fase de construccin. Si el modelamiento del negocio se hace como parte del desarrollo de software, los casos de uso aplicables al sistema de software se describirn con mayor detalle en la fase de elaboracin. Responsabilidad El analista del proceso del negocio es responsable de la integridad de los casos de uso del negocio, debe asegurarse que: Se describa correctamente como la organizacin trabaja. El flujo de trabajo es fcil de entender y cumple su propsito. Las relaciones de inclusin y extensin que se originan en el caso de uso del negocio son consistentes y se justifican. El rol de las asociaciones de comunicacin en los casos de uso del negocio son claras e intuitivas. Los diagramas que describen al caso de uso del negocio y sus relaciones son fciles de entender y cumplen su propsito. Los requerimientos especiales son fciles de entender y cumplen su propsito. Las precondiciones son fciles de entender y cumplen su propsito. Las poscondiciones son fciles de entender y cumplen su propsito.
Elaboracin Si se realiza el modelamiento de un negocio existente con un fin explicativo, sin ninguna intencin de realizar un cambio, se pueden excluir las siguientes secciones del caso de uso del negocio: Metas de rendimiento Riesgos Posibilidades Propietario del proceso 103
Artefacto: Entidad del Negocio Una Entidad del Negocio representa informacin significante y persistente que es manipulada por Actores del Negocio y Trabajadores del Negocio. Las Entidades del Negocio son pasivas, as que no tienen que iniciar acciones con ellas mismas. Una Entidad del Negocio puede ser utilizada en muchas Ejecuciones de Casos de Uso del Negocio y vive ms tiempo que cualquier interaccin sola. Las Entidades del Negocio proveen la base para compartir informacin (flujo de documentos) entre los Trabajadores del Negocio que participan en diferentes Ejecuciones de Casos de Uso del Negocio. Otras Relaciones: Rol: Opcional: Representacin UML: Parte del modelamiento de casos de uso del negocio. Diseador del negocio. Puede ser excluido. Las Entidades del Negocio son muy tiles para proporcionar un slo punto de referencia para trminos y definiciones usadas entre departamentos o proyectos. Casos de uso, estereotipados como Entidades del Negocio Salida de las actividades: Detallar una entidad del negocio. Encontrar trabajadores del negocio y entidades.
Entrada a las actividades: Detallar una entidad del negocio. Revisar el modelo de casos de uso del negocio.
Propsito Las Entidades del Negocio representan una abstraccin importante de informacin persistente dentro del negocio. Cualquier informacin que es una propiedad de algo ms probablemente no sea una Entidad del Negocio de por s. Por ejemplo, ContactDetails es una propiedad de Customer y por tanto no es una Entidad del Negocio en s. La informacin que no es almacenada pero es creada o determinada a pedido (cuando es necesario) es probable que no sea una Entidad de Negocio. Por ejemplo, el inventario de productos es informacin significativa pero no es informacin persistente. Cualquier momento alguien necesita saber cuntas instancias de un particular cdigo de barras est en los estantes (o en el depsito), esta informacin ser calculada y luego descartada. Los participantes (Stakeholders) usan la Entidad del Negocio para asegurarse de que la informacin creada y requerida por la organizacin est presente en el Modelo de Anlisis del Negocio. Un diseador del negocio es responsable de identificar y describir Entidades del Negocio, as tambin de avaluar el impacto de cambios en la organizacin sobre la informacin creada y requerida por el negocio. Las Entidades del Negocio son tambin usadas por analistas de sistemas y diseadores cuando describen casos-de-uso de sistema e identifican entidades de software respectivamente. Propiedades 104
Nombre de la Propiedad Nombre Descripcin breve Responsabilidades
Descripcin Breve El nombre de la Entidad del Negocio. Breve descripcin del rol y propsito de la Entidad del Negocio. Una encuesta de las responsabilidades definida por la Entidad del Negocio Esto puede incluir el ciclo de vida de la Entidad de ser instanciada y poblada hasta que el trabajo est terminado. Relaciones como asociaciones de comunicacin, relaciones de inclusin y extensin, en las cuales la Entidad del Negocio participa. Definidas por la Entidad del Negocio
Representacin en UML El atributo nombre en el elemento del modelo. Caracterizado por ser texto corto. Valor (predefinido) de la superclase Tipo
Relaciones
A travs de la agregacin owns.
Operaciones
Perteneciente a la superclase "Tipo" a travs de la agregacin "miembros". Perteneciente a la superclase "Tipo" a travs de la agregacin "miembros". A travs de la agregacin "owns".
Atributos
Definidas por la Entidad del Negocio
Diagramas
Cualquier diagrama local de la Entidad del Negocio, como diagramas de interaccin o diagramas de clase.
Cronologa Las Entidades del Negocio ms significativas son identificadas durante la fase de iniciacin. Las Entidades del Negocio restantes son identificadas durante la fase de Elaboracin en la cual Las Entidades del Negocio son refinadas y descritas. Responsabilidad El diseador del negocio es responsable de la integridad de la Entidad del Negocio, asegurando que: El nombre y la breve descripcin sean explicativos. Las responsabilidades sean descritas correctamente. Que tenga las definidas relaciones, atributos y operaciones apropiadas para cumplir sus responsabilidades. Elaboracin 105
Si se est haciendo el modelamiento del dominio, significando que solo se identifican las Entidades del Negocio, se puede usar el estereotipo domain class en vez de business entity. Iniciemos con la aventura de la Modelacin del Negocio Para iniciar un proyecto en Racional Rose debe seguirse los siguiente pasos: Al ejecutar el Rational Rose, aparece una pantalla emergente para seleccionar una plantilla que ayuda con la documentacin del software a desarrollar. Ver Pantalla 1.
Pantalla 1: Seleccin de una Plantilla para iniciar la modelacin Para este documento se utilizar la plantilla de Rational Unified Process, la cual contiene una plantilla recomendada por Rational. Debe seleccionar realizando un clic en rational unified process, como se puede observar en la Pantalla 1 y luego realizar un clic en el botn OK. De esta forma, se crear una nuevo proyecto, que servir para modelar y documentar la nueva aplicacin. El resultado se puede observar en la Pantalla 2.
106
Pantalla 2: Nuevo proyecto para iniciar la modelacin Para grabar el proyecto debe realizar las siguientes operaciones: Realice un clic en el botn Save Model , que esta en la barra de acceso rpido. Debe seleccionar un directorio para grabar el modelo A continuacin, debe introducir el nombre del modelo, para este documento se utilizar el ejemplo de una empresa hotelera, descrito anteriormente. El nombre que se le dar al modelo ser HotelRational.mdl, ver Pantalla 3.
Pantalla 3. Grabar el Modelo 107

Una vez introducido el nombre, debe realizar un clic en el botn Guardar, para confirmar la grabacin en el directorio seleccionado. A continuacin se iniciar con la modelacin de ejemplo de la Empresa Hotelera, se iniciar con la Modelacin del Negocio.
108
MODELO DE CASOS DE USO DEL NEGOCIO Una vez creado el nuevo proyecto que servir para desarrollar la Modelacin del Negocio de una empresa hotelera. El primer paso es la determinacin de los Actores del Negocio que se hace por medio de la identificacin de los procesos de la institucin o empresa, cada uno de los procesos identificados puede ser un Casos de Uso del Negocio. Para desarrollar el Diagrama de Casos de Uso del Negocio se debe estudiar los esteriotipos de Casos de Uso del Negocio y el de Actor del Negocio. Estos dos esteriotipos son suficientes para la creacin del Diagrama de Casos de Uso del Negocio. La definicin de estos estereotipos ya se ha visto en el anterior documento Introduccin al Modelo del Negocio. El Modelo de Caso de Uso del Negocio implicar la determinacin de los Actores y Casos de Uso del Negocio, como se ha dicho anteriormente. Con sta actividad se pretende: Identificar los procesos en el negocio Definir las fronteras del negocio que van a modelarse Definir quin y qu interactuarn con el negocio Crear diagramas del modelo de casos de uso del negocio
Un candidato a Actor del Negocio es cualquier individuo, grupo, organizacin o mquina que interacta con el negocio. Por tanto, stos pueden ser: Clientes o potenciales clientes Socios Proveedores Autoridades Propietarios Sistemas de informacin externos al negocio Otras parte de la organizacin, si la organizacin es grande
El trmino Actor del Negocio significa el rol que algo o alguien juega cuando interacta con el negocio. De acuerdo con esta idea un Actor del Negocio representa un tipo particular de usuario del negocio ms que un usuario fsico, ya que varios usuarios fsicos pueden realizar el mismo papel en relacin al negocio, o sea, ser instancias de un mismo actor. Sin embargo, un mismo usuario puede actuar como diferentes actores. El nombre de un Actor del Negocio debe hacerse de modo que exprese su rol dentro del negocio. Cada Actor del Negocio debe definirse brevemente con su responsabilidad y por qu interacta con el negocio. Los Actores del Negocio interactan con el negocio enviando y recibiendo mensajes, y para conocer el papel del actor se debe precisar en qu procesos se involucra el actor. Esto se muestra por la llamada asociacin de comunicacin entre el Actor del Negocio y el Caso de Uso del Negocio que representa al proceso. 109
Un Caso de Uso del Negocio define qu debe ocurrir en el negocio cuando este se realiza, describe el comportamiento de una sucesin de acciones que produce un resultado de valor para un Actor particular del negocio. Es decir, un Caso de Uso del Negocio describe una secuencia de acciones realizadas en el negocio que produce un resultado de valor observable para un actor individual del negocio. Por tanto, desde la perspectiva de un actor individual, un caso de uso del negocio define el flujo de trabajo completo que produce los resultados deseados. En un negocio se pueden identificar al menos tres tipos de procesos: Actividades comercialmente importantes, a menudo llamadas procesos del negocio y constituyen la esencia o ncleo del negocio. Actividades que no son comercialmente importantes pero son necesarias para que el negocio funcione. Ejemplo: actividades administrativas, de limpieza, de seguridad, etc. Estos casos de uso del negocio tienen carcter de soporte. Actividades gerenciales. Ejemplo: monitorear los procesos, crear procesos.
Para encontrar los casos de uso primarios del negocio hay que considerar qu producto o servicio espera el actor del negocio. Estos procesos responden a la pregunta: Cules son los servicios primarios que el consumidor recibe del negocio?. Antes de la creacin del Diagrama de Casos de Uso del Negocio dentro de Rational Rose, se debe crear distintas carpetas que permitan ordenar de manera adecuada el Modelo de Casos de Uso del Negocio. Estas carpetas son las siguientes: Actores del Negocio. Contendr a todos los actores que estn involucrados en la Modelacin del Negocio Casos de Uso. Contendr a todos los Casos de Uso del Negocio que se identifiquen con un proceso de la empresa Entidades. Contendr a todos los objetos o entidades que se identifiquen por medio del Diagrama de Actividad que se crea por cada Caso de Uso del Negocio. La creacin de un diagrama de actividad se ver ms adelante en otro documento. Trabajadores del Negocio. Contendr a todos los trabajadores que participan en el flujo de informacin dentro de la empresa.
El contenido de las ltimas dos carpetas se utilizan para el Diagrama de Objeto del Negocio. Dentro de la plantilla que presenta el Rational Rose existe una carpeta Use Case View, la cual contiene otras dos, Bussiness Use-Case Model y el Use-Case Model. El primero es exclusivamente para la Modelacin del Negocio, la cual se utiliza en este documento, adems para la creacin de las carpetas anteriormente sealadas. La segunda carpeta es para Requisitos de la Aplicacin por medio de los Casos de Uso. Para crear una carpeta solo se debe realizar un clic derecho en Bussiness Use-Case Model seleccionar New y luego Package, como se puede ver en la Pantalla 1.
110
Pantalla 1. Adicionar una Carpeta Luego de seleccionar esta opcin se debe cambiar el nombre, esto se pude ver en la Pantalla 2.
Pantalla 2. Cambio de nombre a las carpetas Una vez creada la estructura para la modelacin del negocio se puede iniciar el desarrollo del Diagrama de Casos de Uso. Estos son los pasos a seguir para el desarrollo del Diagrama de Casos de Uso del Negocio: Usted puede cambiar de nombre al diagrama de casos de uso por defecto que muestra la Pantalla 3, sin embargo existe otro camino para crear un nuevo diagrama de casos de uso del negocio.
111
Pantalla 3. Inicio de creacin de un diagrama de casos de uso del negocio Para crear un nuevo diagrama de casos de uso debe hacer un clic derecho en Business Use-Case Model, se visualizar un men emergente con varias opciones que se pueden ver en la Pantalla 4.
Pantalla 4: opciones emergentes Para crear un nuevo diagrama de caso de uso del negocio seleccione la opcin New, a continuacin aparecern opciones de creacin de distintos diagramas como se muestra en la Pantalla 5
112
Pantalla 5: Especificaciones para crear un Diagrama de casos de uso Una vez seleccionada la opcin de Use Case Diagram, que sirve para la creacin del Diagrama de Casos de Uso, se deber cambiar el nombre del nuevo diagrama a Diagrama de casos de Uso del Negocio, esto se puede ver en la Pantalla 6.
113
Pantalla 6: Pantalla de cambio de nombre del Diagrama de Casos de Uso del Negocio Una vez que se cambie el nombre del diagrama debe realizar doble clic en el diagrama para abrir la plantilla de trabajo que ayuda a crear las relaciones entre los Casos de Uso y Actores del Negocio. Como se puede ver en la Pantalla 7, existir una plantilla en blanco a la derecha, la cual va a contener a los Casos de Uso y los Actores del Negocio.
114
Pantalla 7: Plantilla para realizar el Diagrama de Casos de Uso Se debe adicionar los estereotipos que ayuden a crear el Diagrama de Casos de Uso los cuales son: Actores del Negocio representado con el estereotipo de la Figura 1 Casos de Uso del Negocio representado con el estereotipo de la Figura 2
Cliente
Figura 1 Actores del Negocio

(f rom Actores del Negocio)
Figura 2 Casos de Uso del Negocio
Se puede observar que la barra de herramientas ToolBox no cuenta con los estereotipos ya mencionados, para agregarlos se hace Clic derecho en la barra de herramientas y se selecciona la opcin CUSTOMIZE como se puede observar en la Pantalla 8
115
Pantalla 8: Opciones de la Barra de Herramientas (ToolBox) Despus de hacer Clic en CUTOMIZE aparecer la Pantalla 9 la cual nos ayuda a personalizar la Barra de Herramientas.
Pantalla 9: Personalizacin de la Barra de Herramientas. En la lista ubicada en la parte izquierda de la Pantalla 10 debe seleccionar los estereotipos necesarios, en este caso en particular los estereotipos de los Casos de Uso del Negocio y los Actores del Negocio. Como se muestra en la Pantalla 10, como puede ver ya se ha adicionado el estereotipo de Casos de Uso del Negocio y se tiene seleccionado a los Actores del Negocio para despus adicionarlos haciendo un Clic en el botn Agregar.
116
Pantalla 10: Seleccin y adicin de estereotipos a la Barra de Herramientas Como se observa en la Pantalla 11 ya se han agregado los estereotipos de Casos de Uso del Negocio y los Actores del Negocio necesarios para la realizacin de los Diagramas de Casos de Uso del Negocio.
Pantalla 11: Estereotipos agregados a la Barra de Herramientas. Se adiciona un Actor que representa al Cliente, el cual representa el rol de la persona que estar hospedado en el hotel, para hacer esto se debe realizar un clic en la barra de Herramientas en el botn con el estereotipo del Actor del Negocio , luego, otro clic en la plantilla de Casos de Uso del Negocio, el resultado se ilustra grficamente en la Pantalla 12
117
Pantalla 12: Creacin del Actor del Negocio Como se observa en la Pantalla 12 el Actor creado aparece dentro de la raz, del rbol de carpetas ubicado en la parte izquierda, el mismo debe estar dentro de la carpeta Actores del Negocio, para conseguir se debe arrastrar haciendo un clic izquierdo en el Actor del Negocio y arrastrndolo hasta la carpeta de Actores del Negocio que se encuentra dentro de Bussiness Use-Case Model, el resultado se puede ver en la Pantalla 13.
Pantalla 13 Reubicacin del Actor creado Para renombrar al Actor del Negocio se realiza doble clic en l, posteriormente se desplegar una pantalla en la que podr editar las propiedades del Actor del Negocio, como podemos observar en la Pantalla 14. Dentro de Documentation debe existir una breve descripcin del rol del actor. 118
Pantalla 14: Cambio de nombre del Actor del Negocio Luego de haber cambiado el nombre del Actor del Negocio a Cliente, que es nuestro nico actor del negocio, como se puede ver en la Pantalla 15.
Pantalla 15: Nombre del Actor del Negocio cambiado Ahora se debe crear los Casos de Uso que se han identificado dentro del negocio donde el Cliente es el que inicia. Para crear un Caso de Uso existen dos alternativas. La primera, es similar a la creacin de un Actor del Negocio. Si se selecciona esta alternativa el caso de uso del negocio creado estar en la raz del directorio de carpetas, como se puede ver en la Pantalla 16.
119
Pantalla 16. Nuevo caso de uso creado Se debe cambiar el nombre a este nuevo caso de uso a Confirmar Habitacin, luego, arrastrarlo a la carpeta Casos de Uso, el resultado se puede ver en la Pantalla 17.
Pantalla 17. Cambio de Nombre y Lugar del caso de uso Confirmar Habitacin La segunda manera para la creacin de un caso de uso es similar a la creacin de una carpeta. Primero debe realizar un clic derecho en la carpeta de Casos de Uso, de inmediato se visualizar un men emergente como se puede ver en la Pantalla 18.
120
Pantalla 18. Opciones para la Creacin de un Caso de Uso Una vez seleccionada la opcin de Use Case, se debe cambiar el nombre del caso de uso a Solicitar servicio Bsico, como se puede ver en la Pantalla 19.
Pantalla 19. Cambio de Nombre al nuevo caso de uso Una vez cambiado el nombre se debe cambiar el estereotipo a Business Use Case, que corresponde para un caso de uso del negocio. Para realizar esta actividad se debe realizar doble clic sobre el caso de uso, lo cual permitir visualizar las opciones de especificaciones de los casos de uso, estas opciones se las puede observar en la Pantalla 20, donde se debe seleccionar el nombre del esteriotivo Business Use Case dentro de Stereotype.
121
Pantalla 20. Determinar el estereotipo para un Caso de Uso del Negocio Una vez que se haya realizado un clic en el botn OK de la Pantalla 20, se tendr creado un caso de uso del negocio con su respectivo estereotipo. Lo que faltara por hacer es arrastrar a la plantilla del Diagrama de Casos de Uso el nuevo Caso de Uso del Negocio. El resultado de esta operacin se ve en la Pantalla 21.
Pantalla 21. Adicin de un Caso de Uso al Diagrama De esta forma se puede crear todos los casos de uso que se determinen dentro de un negocio. Sin embargo, se necesita determinar relaciones entre los actores y los casos de uso que estn dentro del Diagrama de Casos de Uso, para determinar las relaciones se debe realizar un clic en el botn Unidirectional Association y realizar un clic izquierdo sobre el actor arrastrando hasta el caso de uso que, por lgica, tenga una relacin, el resultado se puede ver en la Pantalla 22.
122
Pantalla 22. Determinar una relacin entre un Caso de Uso y un Actor del Negocio De esta forma se podr crear un diagrama de Casos de Uso del Negocio. El resultado final se puede observar en la Pantalla 23.
Pantalla 23. Diagrama de Casos de Uso del Negocio finalizado De esta forma se ha finalizado la creacin del Modelo de Casos de Uso del Negocio.
123
DIAGRAMA DE ACTIVIDADES DEL CASO DE USO DEL NEGOCIO Continuando con el desarrollo del Modelo del Negocio, se ver en este documento cmo crear un Diagrama de Actividad, se utilizar el caso de uso del negocio Salir Hotel. Antes de iniciar se vern los estereotipos que se utilizan para el desarrollo del Diagrama de Actividad. El Diagrama de Actividad es un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren la parte dinmica de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el flujo de control entre objetos. Los estereotipos son los siguientes:
Estado de Inicio: Inicia el Diagrama de Actividad, solo puede existir un estado de inicio por cada Diagrama de Actividad.
NewActivity
Actividad: Representa la ejecucin de un sentencia de un procedimiento o el funcionamiento de una actividad en un flujo de trabajo.
NewActivity
Transicin: Indica cul Actividad sigue a otra.
Estado de Finalizacin: Finaliza las Actividades de un Diagrama de Actividad, puede existir varios estados de finalizacin en un Diagrama de Actividad. Vas Alternativas: Indican decisiones acerca de qu transicin seguir despus de completada una actividad.
Barras de Sincronizacin: Muestra subflujos paralelos. Permite que se puedan expresar hilos concurrentes en el proceso de un caso de uso del negocio.
124
Calles (swimlanes): Cada una de las cuales representa una responsabilidad o rol para todo el proceso, llevada a cabo por una parte de la organizacin. El orden relativo de las calles no tiene significado semntico. Cada estado de actividad se asigna a una calle y una transicin puede cruzar las calles.
Objeto
Objeto o Documento: Cada objeto que se pueda introducir dentro del Diagrama de Actividad es una informacin que fluye a travs de las actividades o es el resultado de una o varias. Durante la descripcin de un proceso del negocio mediante un diagrama de actividad, es posible encontrar una actividad de tal complejidad que requiera describirla mediante otro diagrama adicional. Por tanto, este nuevo diagrama describir un subobjetivo en relacin con el objetivo original vinculado al proceso del negocio. De este modo los procesos de negocio se organizan jerrquicamente. Tambin es posible mostrar en diferentes diagramas de actividad el flujo normal y los flujos alternativos. Para crear un diagrama de actividades lo primero que se debe hacer es desplegar la opcin Use-Case View como se puede observar en Pantalla 1.
Pantalla 1: Despliegue de la opcin Use Case View Para empezar a crear un diagrama de actividades, se debe expandir la Carpeta Casos de Uso que est dentro de Business Use-Case Model, realizando un clic en el signo +. Una vez que la carpeta Casos de Uso est desplegada se debe identificar el caso de uso Salir del Hotel y hacer clic derecho sobre ste e ir al submen New. Posteriormente elegir la opcin Activity Diagram como se muestra en la Pantalla 2.
125
Pantalla 2: Nuevo Diagrama de Actividades del Caso de Uso Salir del Negocio Una vez que se realice el clic sobre la opcin Activity Diagram, se debe colocar el nombre al Diagrama de Actividad como muestra la pantalla 3.
Pantalla 3: Asignacin de nombre del nuevo diagrama de actividades Es conveniente colocar el mismo nombre que tiene el caso de uso. Una Vez asignado el nombre se debe realizar un clic derecho sobre el nuevo diagrama de actividades Salir del Hotel y elegir la opcin Open para abrir la plantilla de actividades, como se muestra en la pantalla 4.
126
Pantalla 4: Abrir la plantilla de un nuevo diagrama de actividades Una vez abierta la plantilla en blanco aparecer una barra de botones ToolBar como se muestra en la pantalla 5.
Pantalla 5: Plantilla de edicin de un nuevo diagrama de actividades Para tener todas las herramientas en la barra, basta con hacer clic derecho sobre sta y seleccionar la opcin Customize, tal como se ve en la pantalla 6.
127
Pantalla 6: Como agregar botones a la barra para la creacin de un diagrama de actividad Una vez que se elije la opcin Customize aparecer una ventana donde se debe elegir los botones: Creates an Object y Creates a Object Flow, una vez se elija cada uno de estos se debe hacer clic en el botn Agregar como se ve en la pantalla 7.
Pantalla 7: Agregacin de botones necesarios en la barra Al terminar de agregar los botones basta con presionar el botn Cerrar para ver los botones que hayamos agregado en nuestra nueva barra de botones para la creacin de un diagrama de actividades, tal como se muestra en la Pantalla 8.
128
Pantalla 8: Nueva Barra de Botones para la creacin de un diagrama de actividades Para empezar a crear un diagrama de actividades lo primero que se debe hacer es crear las calles o Swimlane, la primera representa al actor del negocio y las restantes a los trabajadores del negocio que participan en el caso de uso y realizan una actividad, para agregar una nueva calle se debe hacer clic sobre el botn Swimlane , luego hacer otro clic en la plantilla y asignar el nombre del actor del negocio en este caso Cliente. Esto se puede ver en la Pantalla 9.
Pantalla 9: Creacin de una calle para el actor del negocio 129

Una vez creada la calle se debe iniciar el diagrama de actividad, para esto se debe realizar un clic en el botn Start State , y otro clic en la calle del Actor del Negocio Cliente, como se muestra en la Pantalla 10.
Pantalla 10: Inicio del diagrama de actividades El estereotipo de Start State o estado de inicio permite iniciar el diagrama de actividad, este estereotipo debe ir siempre en la calle del actor del negocio ya que este siempre iniciar en el caso de uso. En el caso que exista un caso de uso Extendido o Incluido, el inicio del diagrama de actividad estar en la calle de un trabajador del negocio. Para continuar con el diagrama de actividad, se adicionarn varias actividades con el nombre de Solicitar Cuenta, esta actividad va a ser realizada por el actor del negocio. Esto se puede ver en la Pantalla 11, para realizar esto debe hacer un clic en el boto Activity y hacer otro clic en la calle del actor del negocio de esta forma se puede adicionar varias actividades al diagrama.
Pantalla 11: Creacin de una actividad Para determinar la transicin entre el inicio y una actividad o entre actividades, se debe agregar un flujo haciendo clic en el botn State Transition , se debe hacer un clic en el origen (Start State) arrastrar, 130
presionando el botn izquierdo del Mouse hasta el destino (Solicitar Cuenta), esto se puede ver en la Pantalla 12.
Pantalla 12: Creacin de un Flujo de Transicin Este proceso se puede realizar, de igual forma, entre actividades como se ver ms adelante. Para continuar con el diagrama de actividad se crea una nueva calle que representa a un trabajador del negocio y adems es lgico decir que el cliente va a interactuar con ste, en este caso el Recepcionista. La creacin de una nueva calle es similar a la anterior. Este nuevo trabajador del negocio realizar una actividad para calcular la cuenta total del cliente, para esto se debe crear una nueva actividad y colocarla en la calle de este trabajador del negocio, adems debe existir un flujo de transicin entre las actividades Solicitar Cuenta y Calcular Cuenta, como puede ver en la Pantalla 13.
Pantalla 13: Creacin de una nueva actividad A continuacin se de agregar una lnea de sincronizacin horizontal, que sirve para unir o separar actividades que se pueden ejecutar simultneamente. Para agregar este estereotipo se debe hacer clic sobre el botn horizontal Synchronization colocar en el diagrama, como se muestra en la Pantalla 14. y luego
131
Pantalla 14: Creacin de una nueva lnea horizontal de sincronizacin Una vez que est agregada la lnea horizontal de sincronizacin, se debe agregar un flujo entre la actividad Calcular Cuenta y la lnea horizontal de sincronizacin, como se pudo ver en la pantalla 12. Luego de hacer esto, el empleado del negocio Recepcionista, inicializar 3 actividades; a partir de la lnea de sincronizacin, dos de estas actividades son de otro empleado del negocio que es el Cocinero y la otra actividad es realizada por el mismo empleado del negocio Recepcionista, para ello se debe agregar otra calle que corresponde al empleado del negocio Cocinero. Las 3 actividades agregadas son: Calcular Cuenta Estada, Calcular Cuenta Servicios Bsicos, Calcular Cuenta Servicios de Habitacin. Todo esto se puede apreciar en la pantalla 15.
Pantalla 15: Inicializacin de mltiples de actividades a partir de una lnea horizontal de sincronizacin Una vez creadas las actividad es, cuando se dispara la actividad Calcular Cuenta Estada, cambiar el objeto Cuenta de Estada, un objeto puede tener de uno a muchos estados, en este caso solo tiene dos estados: Lleno y Vaco, el objeto ser creado con el estado Lleno. Anteriormente se ha creado con un estado Vacio 132
Para agregar un objeto se debe hacer clic en el botn Object Cuenta Estada, esto se puede ver en la Pantalla 16.
, este objeto llevar el nombre de
Pantalla 16: Creacin de un Objeto Para asignar un estado a un objeto se debe hacer doble clic sobre el objeto, para ver las propiedades de ste, posteriormente se debe seleccionar la opcin New en el campo State, como se puede observar en la Pantalla 17.
Pantalla 17: Creacin de un nuevo estado en un objeto
133
Posteriormente se debe asignar el nombre al estado, en el campo Name, y terminar presionar el botn Ok. sto se muestra en la pantalla 18.
Pantalla 18: Asignacin de nombre de un estado de objeto Una vez creado el objeto Cuenta Estada, se debe unir este a una actividad en este caso la actividad Calcular Cuenta Estada, esto se hace por medio de un flujo, para agregar un flujo entre un objeto y una actividad, basta con hacer clic en el botn Object Flow , y hacer un clic en el origen (Calcular Cuenta Estada) y en el destino (Cuenta Estada) arrastrando el Mouse con el botn izquierdo presionado, esto se puede ver en la Pantalla 19.
Cliente
Recepcionista
Cocinero
Solicitar Cuenta
Calcular Cuenta
Calcular Cuenta Servicios Bsicos Cuenta Estada [Lleno]
Cuenta de Servicios Bsicos [Lleno]
Calcular Cuenta Estada Calcular Cuenta Servicios de Habitacin
Cuenta de Servicios de Habitacin [Lleno]
Pantalla 19: Creacin de un Flujo entre Actividad y Objeto

Resumen de Cuentas Rechazar monto a pagar Cuenta [Lleno]
Recibir Cuenta
134
Posteriormente se debe crear el objeto Cuenta de Servicios Bsicos, el cul procede desde la actividad Calcular Cuenta de Servicios Bsicos; tambin se debe crear el objeto Cuenta de Servicios de Habitacin el cul procede de la actividad Calcular cuenta de Servicios de Habitacin, esto se puede ver en la Pantalla 19. A partir de las tres actividades: Calcular Cuenta Estada, Calcular Cuenta de Servicios Bsicos, Calcular cuenta de Servicios de Habitacin, se crea una nueva lnea de sincronizacin, como se puede observar en la Pantalla 19. A partir de esta lnea de sincronizacin se llamar a una nueva actividad ejecutada por el empleado del Cliente Recepcionista Cocinero negocio Recepcionista, esta actividad se denominar Resumir Cuenta, se puede ver la creacin de esta actividad en la Pantalla 20. A partir de esta actividad se crea un nuevo objeto llamado Cuenta, esto se puede ver en la Pantalla 20; este objeto debe tener el estado de Lleno. Este objeto se utiliza en la actividad Revisar Cuenta, esta ser ejecutada por Solicitar el Actor del Negocio, en laCalcular cual revisar el detalle de la cuenta. Cuenta
Cuenta
Desde la actividad Recibir Cuenta, se deber crear un estereotipo de decisin, el cual podr dar dos posibles respuestas representadas por una etiqueta, estas respuestas podrn ser: Aceptar la cuenta a pagar o Rechazar monto a pagar; para agregar el estereotipo de decisin se debe hacer clic en el Caldular Cuenta de botn Decisin esto se puede ver en la Pantalla 20, y colocar en el diagrama; este estereotipo se Servicios Bsicos unir con 2 actividades por medio de un flujo, una vez este agregado este flujo se asignarn las etiquetas correspondientes. Cuenta
Estadia [Llena] Calcular Cuenta Estadia Calcular Cuenta de Servicios a la Habitacin
Rechazar Monto a Pagar
Resumir Cuenta
Cuanta Revisar Cuenta [Llena]
Pantalla 20: Creacin de un componente de Decisin
135
Para asignar una etiqueta a una State Transition basta con hacer doble clic sobre esta y en el campo de Event se debe colocar la condicin para ese estado, como se puede ver en la pantalla 21.
Pantalla 21. Determinar la condicin de transicin de estado Se debe crear una actividad denominada Pagar, esta ser una actividad que pueda realizar el Actor del Negocio, y la otra actividad ser la actividad Calcular Cuenta. Todo esto se puede ver en la pantalla 22.
136
Pantalla 22: Toma de decisin en un diagrama de actividades Una vez se realice la actividad Pagar, se crear una nueva actividad denominada Recibir Pago, esta actividad ser ejecutada por el empleado d el negocio Recepcionista. Esta actividad debe estar relacionada mediante un flujo con la actividad Pagar. Posteriormente se crea la actividad Crear Factura, que estar enlazada a la actividad Recibir Pago, la actividad Crear Factura, dar como resultado un objeto denominado Factura, este objeto tendr el estado Lleno. Posteriormente este objeto crear la actividad Recibir Factura Conforme, esta actividad nos llevar al final del diagrama mediante el botn End State , como se puede ver en la Pantalla 23.
137
Pantalla 23: Creacin de un fin de estado El diagrama concluido se ve en la pantalla 24.
138
Cliente
Recepcionista
Cocinero
Solicitar Cuenta
Calcular Cuenta
Calcular Cuenta Servicios Bsicos Cuenta Estada [Lleno]
Cuenta de Servicios Bsicos [Lleno]
Calcular Cuenta Estada Calcular Cuenta Servicios de Habitacin
Cuenta de Servicios de Habitacin [Lleno]
Resumen de Cuentas Rechazar monto a pagar Cuenta [Lleno]
Recibir Cuenta
Aceptar la cuenta a pagar Pagar Recibir Pago
Crear Factura
Recibir Factura Conforme
Factura [Lleno]
Pantalla 24: Diagrama de Actividades caso de uso Salir del Hotel Una vez que se realice todos los diagramas de actividad, que debe ser por cada caso de uso del negocio, se debe definir y describir a los Actores y trabajadores del Negocio. Esta tarea es una de las partes importante de la Modelacin del Negocio, se debe especificar de una forma completa a los Actores y los Trabajadores del Negocio. Estos dos involucrados son los que mueven la informacin a travs del negocio. En prximos documentos se ver que ya sea un Actor o Trabajador del Negocio se puede convertir en un Actor de la Aplicacin, esto es depende las polticas de la empresa, por este motivo es muy necesario documentar correctamente a estos dos tipos de involucrados. Es claro que esta descripcin incluye a todos los trabajadores y actores del negocio, aunque en este documento no 139
aparecen algunos, ya que slo se ha desarrollado un diagrama de actividad. Sin embargo el estudiante se podr dar cuenta que son necesarios otros trabajadores del negocio. Actores del Negocio. Existe un solo actor del negocio, es el que interacta con los trabajadores del negocio. Cliente. Es la persona que solicita servicios de hospedaje y de alimentacin en el hotel. Trabajadores del Negocio. Existen varios Trabajadores del Negocio que le prestan servicios al Actor del Negocio que es el Cliente Recepcionista. Es la persona que interacta con el cliente para reservar o confirmar una habitacin para su hospedaje, adems es la encargada de resumir las cuentas del Cliente para el da de salida Cocinero. Es el encargado calcular el costo de los servicios de comida, ya se a la habitacin o en los servicios bsicos como desayuno, almuerzo o cena, que solicita el Cliente Mesero. Es el encargado de registrar o tomar nota de los servicios bsicos que solicita el cliente Mozo del Bar. Es el encargado de calcular el costo de los servicios de bebidas, ya sea a la habitacin o en los servicios bsicos, que solicita el Cliente.
Algunas observaciones en la creacin de Diagramas de Actividad Los Diagramas de Actividad permiten muchas libertades, lo que a veces estimula a los creadores a incluir un alto nivel de detalle. En definitiva, un modelo de comunicacin requiere un adecuado nivel de detalle para ubicar el problema a resolver. La claridad y brevedad son dos atributos importantes para evitar la sobrecarga y limitarse slo a presentar los aspectos claves de los flujos de los casos de uso. Se sugieren seguir las siguientes reglas, entre otras; No intentar mostrar elementos de diseo. Centrarse en las necesidades del cliente y no moverse hacia el espacio de la solucin, es decir, seguir el principio de enfocarse a la funcionalidad, desde la perspectiva del usuario o del negocio. Por ejemplo, crear una actividad que sea Conectar a la Base de Datos Oracle, estara violando ese principio. No sustituir los diagramas de actividad por la descripcin de los casos de uso. Limitar el nivel de complejidad de cada diagrama. Para ello: Si hay ms de 3 posibles caminos (alternos o de excepcin), usar diagramas adicionales para mejorar la comprensin. Usar Swimlanes para separar responsabilidades. No capturar procesamientos detallados del sistema. 140
En la medida de lo posible utilizar un diagrama por cada caso de uso. Usar una herramienta para mantener la consistencia de los modelos.
Mantener los modelos. Los diagramas deben actualizarse cuando se modifiquen los casos de uso.
141
MODELO DE OBJETO DEL NEGOCIO Para crear el Modelo de Objeto del Negocio se deben utilizar los siguientes estereotipos:
Actor del Negocio
<Actor Name>
(f rom Actors)
Trabajador del Negocio
Business Worker
Entidad del Negocio
Business Entity
Con estos tres estereotipos se puede desarrollar un Modelo de Objeto del Negocio. Este modelo identifica todos los roles y cosas en el negocio, los cuales son representados como clases en la Vista Lgica. El Modelo de Objeto es creado a travs de los Diagramas de Actividad que describen los Casos de Uso del Negocio con los objetos o documentos incluidos. Generalmente la primera calle que inicia el Diagrama de Actividad corresponde a un Actor del Negocio, las restantes pertenecen a un Trabajador del Negocio. Iniciemos la creacin del Modelo de Objeto del Negocio. Dentro de la plantilla que ofrece Rational Rose para la modelacin existe una carpeta con el nombre de Business Object Model, la cual est dentro de Logical View como se puede ver en la Pantalla 1. Esta carpeta de Modelo de Objeto de Negocio almacenar el diagrama compuesto por entidades, trabajadores y actores del negocio.
142
Pantalla 1. Carpeta del Modelo de Objeto del Negocio Para crear el diagrama se debe realizar un click derecho en la carpeta Business Objet Model, inmediatamente se visualizar un men emergente como se puede ver en la Pantalla 2. Se debe seleccionar la opcin New y a continuacin Class Diagram (Diagrama de Clases). Dentro de un Diagrama de Clases se puede crear un Modelo de Objeto del Negocio.
Pantalla 2. Crear un Diagrama de Clases para el Modelo de Objeto del Negocio Una vez que se seleccione las opciones anteriores, se tiene que cambiar el nombre del nuevo diagrama de clases a Modelo de Objeto del Negocio como se puede ver en la Pantalla 3.
Pantalla 3. Cambio de Nombre al nuevo diagrama de clases Luego se debe visualizar la plantilla que nos proporciona Rational Rose para la creacin del Modelo de Objeto del Negocio, solo se debe realizar doble clic sobre el nombre el diagrama del objeto del negocio. Inmediatamente se visualizar en la parte izquierda del entorno de Rational Rose la platilla en blanco como se puede ver en la Pantalla 4.
143
Pantalla 4. Plantilla y Barra de Herramientas para crear el Modelo de Objeto del Negocio Para iniciar debemos arrastrar los Actores del Negocio a la plantilla. En nuestro ejemplo existe un slo actor del negocio que es Cliente, a este actor se tiene que arrastrar hacia la plantilla del Modelo de Objeto del negocio como se puede ver la Pantalla 5.
Pantalla 5. Adicin al Modelo de Objeto del Negocio del Actor del Negocio Cliente Ahora, la pregunta es de dnde salen los trabajadores y las Entidades del Negocio?, la respuesta a esta pregunta es muy sencilla. Los Trabajadores y las Entidades del Negocio salen de Diagrama de Actividad 144
que describe un Caso de Uso del Negocio. Tomaremos como ejemplo el Diagrama de Actividad Solicitar Servicio del caso de uso Solicitar Servicio Bsico. La Pantalla 6 presenta el diagrama de actividad que corresponde al caso de uso Solicitar Servicio Bsico. La primera calle corresponde a un actor del negocio con el nombre Cliente, las otras calles pertenece a un Trabajador del Negocio que interacta con el Cliente. De este modo tememos varios trabajadores del negocio que son: Mesero, Cocinero y Mozo del Bar. Los Objetos o Documentos que se observan en el diagrama de actividad corresponden a Entidades del Negocio, entonces se tendr cuatro entidades del negocio, las cuales son: Solicitud de Servicio con el estado Llena, Solicitud de Bebidas con el estado Llena, Solicitud de Bebidas con el estado Con el Costo y Solicitud de Servicio con el estado Con el Costo.
145

Cliente Mesero Cocinero Mozo del Bar
Solicitar servicio
Recepcionar Solicitud
Solicitud de Servicio [Llena]
Solicitar Bebidas al Bar
Calcular Costo de Bebidas
Solicitud de Bebidas [Llena]
Solicitud de Bebidas [Con el Costo]
Verificar Solicitud de Bebidas
Precios incorrectos
Calcular Costo Total del Servicio
Verificar el costo del Servicio
Solicitud de Servicio [Con el Costo]
Costo Incorrecto
Pantalla 6. Diagrama de Actividad Solicitar Servicio Bsico Una vez hecho el anlisis se debe crear a los trabajadores y a las entidades del negocio. Se debe realizar un clic derecho en la carpeta de Trabajadores del Negocio y seleccionar las opciones de New y Actor, como se puede ver en la Pantalla 7.
146
Pantalla 7. Crear un trabajador del Negocio Luego, se debe cambiar el nombre al nuevo actor por el nombre del trabajador del negocio Mesero, que corresponde a una calle del Diagrama de Actividad. Como se puede ver en la Pantalla 8.
Pantalla 8. Cambio de nombre al nuevo actor por el Trabajador del Negocio Para cambiar el estereotipo de Actor hacia un Trabajador del Negocio, se debe realizar un clic derecho en el Actor y seleccionar la opcin de Open Specification, como se puede ver en la Pantalla 9.
Pantalla 9. Opcin para el Cambio de Estereotipo
147
Una vez seleccionada la opcin inmediatamente se visualizar la Pantalla 10, en la cual se debe seleccionar el estereotipo de Business Worker (Trabajador del Negocio), por ltimo se debe realizar un clic en el botn OK de la Pantalla 10.
Pantalla 10. Cambio de Estereotipo Cuando se finaliza, el esteriotipo de actor cambiar al estereotipo de Trabajador del Negocio como se puede ver en la Pantalla 11.
Pantalla 11. Trabajador del Negocio Creado Para crear los restantes Trabajadores del Negocio se debe realizar las mismas operaciones, el resultado debe ser como se puede ver en la Pantalla 12.
Pantalla 12. Vista de los Trabajadores del Negocio Existe en la Pantalla 12, un trabajador del negocio que no aparece en el diagrama de actividad Solicitar Servicio y es Recepcionista, est claro que pertenece a otro diagrama de de actividad, la carpeta de Trabajadores del Negocio contendr a todos los trabajadores que aparezcan en los distintos diagramas 148
de actividad, de igual forma la carpeta de Entidades contendr a todos los objetos o Documentos que aparezcan en los distintos Diagramas de Actividad. A continuacin se describen los pasos para la creacin de las entidades del negocio. Esta creacin de la entidades es algo similar a la de crear un trabajador del negocio. Se debe realizar un clic derecho en la carpeta Entidades y seleccionar las opciones de New y Class, como se puede observar en la Pantalla 13.
Pantalla 13. Crear una Entidad del Negocio Una vez realizada la actividad se debe cambiar de nombre a Solicitud de Bebidas, luego se debe cambiar el estereotipo, realizando un clic derecho y seleccionando la opcin Open Specification se visualizara la Pantalla 14, la cual permite cambiar el esteriotipo hacia Businness Entity.
Pantalla 14. Cambio de Esteriotipo hacia Entidad del Negocio 149

Para aceptar el cambio solo se debe realizar un clic en el botn OK, de inmediato el estereotipo de Clase cambiara al estereotipo Entidad del Negocio como se puede ver en la Pantalla 15.
Pantalla 15. Entidad del Negocio Creada Del mismo modo debe crear las otras entidades del negocio, el resultado debe ser igual a la Pantalla 16.
Pantalla 17. Entidades del Negocio Como se puede observar en la Pantalla 17, existen otras entidades que no se visualizan en los diagramas de actividad, como la entidad Bebidas. La explicacin, es que no todas las entidades del negocio aparecen en el diagrama de actividad, pero al momento de realizar el Modelo de Objeto del Negocio por el anlisis, estudio y la experiencia salen a la luz nuevas entidades. La entidad Bebidas representa a una hoja donde se encuentran los nombres de las Bebidas, en si es una lista de bebidas que puede seleccionar el Cliente al momento de realizar su orden de servicio. Lo nico que queda por realizar es arrastrar a los trabajadores y entidades del negocio hacia la plantilla que nos permita crear el Modelo de Objeto del Negocio. Como se puede ver en la Pantalla 18, se ha realizado esta operacin de arrastrar a los trabajadores y entidades del negocio.
150
Pantalla 18. Modelo de Objeto del Negocio con Entidades y Trabajadores del Negocio Ahora, falta realizar, en el Modelo de Objeto del Negocio las relaciones entre los actores y trabajadores del negocio, entre trabajadores y entidades del negocio y entre entidades del negocio. Ya se tiene conocimiento de cmo crear una relacin entre un estereotipo con otro. El resultado del modelo de objeto se puede observar en la Pantalla 19.
151
Pantalla 19. Modelo de objeto sin relaciones entre Entidades Se puede presentar relaciones de composicin entre entidades dentro del Modelo de Objeto del Negocio. Estas relaciones de Composicin se las ver con detalla cuando se hable del Diagrama de Clases. Para este documento se ha determinado una relacin de composicin de tipo Agregacin sobre las entidades Solicitud de Bebidas [Llena], Solicitud de Bebidas [Con Costo] y Bebidas, como se puede ver en la Pantalla 20.
Pantalla 20. Relaciones entre entidades Para visualizar la relacin de composicin entre dos entidades se debe realizar un clic derecho sobre uno de los extremos de la relacin, de inmediato se visualizar varias opciones como se puede ver en la Pantalla 21. Hay que aclarar que al hacer un clic en uno de los extremos de la relacin las opciones que se presentan varan, por ejemplo, si se hacer un clic en el extremo ms cercano de la Entidad Bebidas se cambiar la relacin de la entidad Bebidas con la Entidad Solicitud de Bebidas [Llena], es decir se est modificando la relacin que tienen Bebidas con la otra entidad. Si se hace un clic derecho en el extremo 152
ms cercano a la entidad Solicitud Bebidas [Llena] se estar cambiando la relacin que tiene con la entidad Bebidas.
Pantalla 21. Opciones para configurar la relacin entre dos entidades En la pantalla 21 se ha hecho un clic en el extremo mas cercano a la entidad Bebidas, la opcin que debe seleccionar es Navigable, la cual quitara la navegacin de la relacin como se puede ver en la Pantalla 22
Pantalla 22. Eliminacin de la Navegacin Para poder visualizar la Composicin se debe realizar un clic derechos sobre el extremo de la relacin que corresponde a la entidad Solicitud de Bebidas [Llena] y seleccionar la opcin Aggregate como se puede ver en la Pantalla 23.
153
Pantalla 23. Visualizar una relacin de Agregacin El resultado de esta operacin se la puede ver en la pantalla 24.
Pantalla 24. Relacin de Composicin/Agregacin De este modo se puede observar en la Pantalla 25, el Modelo de Objeto del Negocio terminado con todas sus relaciones.
154
Pantalla 25. Modelo de Objeto del Negocio terminado Se ha finalizado el desarrollo del Modelo de Objeto del Negocio, en prximos documentos se vera la utilizacin de los Casos de uso del Sistema, su descripcin y se entrar al Anlisis.
155
INTRODUCCIN AL FLUJO DE REQUISITOS Existen dos clases de requisitos, cada una de estas clases son muy importantes y hay que describirlas de una forma completa. La descripcin se la debe hacer por medio de una plantilla que debe ser acordada, previamente, por el grupo de desarrollo o por la empresa. Estas clases son las siguientes: Requisitos Funcionales. Una capacidad o condicin que la aplicacin debe cumplir Requisitos no Funcionales. Propiedades o cualidades que el producto de software debe tener.
Existe una clasificacin adicional a las descritas anteriormente, estas nos dan una visin ms clara de los requisitos que deben ser descritos por el grupo de desarrollo y son: Normales (Funcionales). Deben incluir los objetivos y metas para una aplicacin, esto significa que si estn presentes el cliente est satisfecho, ya que cumplirn con las necesidades del trabajo diario. Esperados (No Funciones). Estos sern implcitos a la aplicacin, puede que el cliente no los declare, pero si no estn puede que est insatisfecho. Como por ejemplo, la Facilidad de Uso o la Seguridad de transmisin de los datos que realiza la aplicacin. Innovadores (Funcional y No Funcional). Son requisitos con caractersticas que van ms all de las expectativas del cliente. Como por ejemplo, una calculadora o implementar una conversacin escrita en tiempo real (Chat) dentro de la aplicacin.
Existen cuatro pasos fundamentales para la determinacin de los requisitos, son los siguientes: Enumerar los Requisitos Funcionales Candidatos. Se puede listar de forma desordenada que es lo que se quiere que resuelva la aplicacin, tomando en cuenta el conocimiento de los futuros usuarios, clientes y desarrolladores. Comprender el Contexto de la Aplicacin. Los desarrolladores necesitan un fuerte conocimiento del contexto del sistema de informacin donde se desarrollar la aplicacin, as mismo un conocimiento muy acertado de las actividades y procesos que se van a automatizar. Esto se logra gracias al Modelo del Negocio, el cual estudia las actividades desde el punto de vista del negocio. Capturar los Requisitos Funcionales. Los requisitos funcionales sern expresados por medio de los Casos de Uso, los cuales describirn el flujo de actividades para el manejo de la aplicacin. La descripcin de los casos de uso debe realizarse de una forma completa utilizando una plantilla establecida por el grupo de desarrollo o de la empresa. La descripcin debe tomar en cuenta los escenarios diversos que puede tener un Caso de Uso, entendiendo como escenario a las situaciones diversas que puede existir al momento de manejar la aplicacin. Otra alternativa, para la capturar a los requisitos es a travs del Modelo del Negocio, especficamente el Diagrama de Actividad que describe un caso de uso del negocio. Capturar los Requisitos no Funcionales. Debe pensarse en estas propiedades como las caractersticas que hacen al producto atractivo, usable, rpido o confiable. Estos requisitos incluyen: o Conjunto de Facilidades o Capacidades 156
o Restricciones o Seguridad Racional propone realizar un estudio y descripcin de los requisitos no funcionales: o Apariencia o Interfaz Externa o Facilidad de Uso o Rendimiento o Soporte o Seguridad o Confiabilidad o Ayudas y documentacin en lnea o Software y Hardware o Diseo e Implementacin o Polticos y Culturales Como se ha visto en el documento de introduccin, se puede definir los requisitos no funcionales a travs de la Normas internacionales como por ejemplo: ISO-9126, McCall y Boohem, siendo la primera la ms utilizada para este propsito. Cada requisito estar descrito dentro de un Caso de Uso, como tambin pueden existir requisitos generales que involucren a toda la aplicacin, conocidos como Requisitos Adicionales. Dentro del Proceso Unificado de Racional una de las herramientas utilizadas para la determinacin de requisitos para la aplicacin son los Casos de Uso. Esta herramienta, se ha utilizado durante muchos aos, ya que describe, de manera ptima, los requisitos de los clientes. Un Caso de Uso debe ser, para el usuario, un modo de utilizar la aplicacin, es decir un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza la aplicacin para un propsito. La transicin de la determinacin de las necesidades, pasando por los requisitos del cliente y llegar hasta la implementacin no es fcil. Las necesidades de un cliente no son fciles de discernir o descubrir y mucho ms traducirlas a un lenguaje que sirva para desarrollar una aplicacin. Esto obliga que se debe tener un modo de descubrir estas necesidades del cliente para poderlas transformar en requisitos de la aplicacin, de modo que sea fcil la comunicacin entre los involucrados en el proyecto. Despus, se debe llevar a cabo la implementacin, que debe ajustarse con las necesidades y requisitos. El ltimo problema es comprobar que la implementacin cubra de una manera ptima los requisitos del usuario, para esto se utiliza el proceso de prueba que nos garantiza una validacin de la aplicacin desarrollada para cubrir con las necesidades del cliente. Los Casos de Uso han sido adoptados en el mundo entero para la captura de requisitos de sistemas de software y sistemas basados en componentes, pero los Casos de Uso son ms que para la determinacin de los requisitos, dirigen y ayudan, en forma total, el desarrollo. Es normal que una aplicacin cuente con muchos usuarios o actores, lo cuales son los que interactan con los casos de uso. Un Caso de Uso es una secuencia de acciones que la aplicacin lleva a cabo para ofrecer un resultado para el actor. El Modelo de Casos de Uso, est compuesto por todos los actores y los Casos de Uso relacionados.
157
Para realizar la captura de los requisitos se debe iniciar con la determinacin de los actores, luego por cada actor determinar los casos de uso. Cada caso de uso tiene que estar debidamente descrito. Por ltimo realizar el Diagrama de Casos de Uso
Identificar los actores Para identificar los actores de la aplicacin se utiliza la descripcin de los Casos de Uso del Negocio, es decir, los Diagramas de Actividad. Ya sea, un Actor o un Trabajador del Negocio se convertir en un Actor de la Aplicacin, esto se determina por medio de: La situacin de la Institucin. Algunas veces no tiene para invertir en recursoss tcnicos que permitan desarrollar una aplicacin con la ltima tecnologa. Aunque, algunas veces, es un error utilizar la ltima tecnologa por motivos de compatibilidad. Esta situacin puede llegar a determinar que los trabajadores del negocio son los candidatos a ser Actores de la Aplicacin. Las necesidades de la Institucin. Algunas veces por el incremento del manejo de informacin o por el crecimiento de servicios se necesita desarrollar una aplicacin en un entorno Web, que incluye al cliente como posible actor de la aplicacin.
Estos factores son los que se deben tomar en cuenta para determinar a los actores de la aplicacin. Sin embargo, como se ha explicado en anteriores documentos, el Modelo del Negocio se puede obviar, en este caso los actores de la aplicacin sern determinados de distinta forma, que se explica a continuacin. Los actores se caracterizan por: No son parte de la aplicacin, son roles de un usuario Pueden intercambiar informacin con el sistema Pueden ser un recipiente pasivo de informacin Pueden representar a un humano a una mquina o un software
Para identificar los actores en el contexto de la aplicacin deben realizarse las siguientes preguntas: Quin est interesado en cierto requisito? Dnde en la organizacin es usado el sistema? Quines usan, eliminan o suministran informacin? Quin usar una funcionalidad de la aplicacin? Quin soporta y mantiene el sistema? Usa el sistema un recursos externo? Cules actores necesitan el caso de uso? Un actor juega diferentes roles o varios actores juegan el mismo rol?
158
Identificar los casos de uso De igual forma que para determinar a los actores de la aplicacin se debe estudiar los Diagramas de Actividad de los Casos de Uso del Negocio y sus actividades. Este estudio nos permitir identificar a los Casos de Uso de la aplicacin. Las actividades que estn dentro de los diagramas de actividades deben ser analizadas y resumidas, de esta forma se puedan convertir en Requisitos de la aplicacin. No todas las actividades que se presentan en un diagrama de actividad sern automatizadas. Se tiene dos mtodos para identificar los casos de uso si no se cuenta con el Modelo del Negocio: Mtodo basado en los Actores Mtodo basado en Eventos
En el mtodo basado en los actores se tiene en cuenta lo siguiente: Se relacionan los actores con un sistema o empresa Para cada actor, se identifican los procesos que inician o en que participan
En el mtodo basado en los eventos se tiene en cuenta lo siguiente: Se identifican los eventos externos a los que un sistema debe responder Se relacionan los eventos con los actores y con los casos de uso
Una vez que se hayan determinado los Actores y Casos de Uso de la Aplicacin se debe describir cada uno de estos. Esta descripcin se ver ms adelante con mucho detalle, ya que es la parte ms importante dentro del desarrollo de software. El siguiente paso es realizar el Diagrama de Casos de Uso de la aplicacin, el cual nos dar una vista muy resumida y completa de la magnitud del desarrollo. Este diagrama se desarrolla con los estereotipos de Casos de Uso y Actores. En este momento, se puede determinar los posibles Ciclos de Desarrollo y los Paquetes que ayudan a entender mucho mejor el modelo de requisitos. Una vez desarrollado el Diagrama de Casos de Uso, se procede a describir cada uno de los casos de uso que estn dentro del diagrama, de una forma resumida, lo cual nos da una visin de las operaciones y transacciones que se realizarn en la aplicacin, esto ltimo nos permite poder estimar el esfuerzo, tiempo y costo del desarrollo, lo cual nos permitir, posteriormente, desarrollar un Plan de Desarrollo. El ltimo paso es la determinacin de los Requisitos no Funcionales, los cuales deben estar de acuerdo a un estndar, ya sea interno, nacional o internacional. Estos requisitos son muy importantes, ya que con estos se podr medir, en gran parte la calidad. Estos requisitos demostrarn el trabajo que se realizar o que se ha realizado durante el desarrollo, ya que obligar a los desarrolladores a medir y controlar el desarrollo. En estos documentos se ve, muy poco, respecto a la definicin, control y seguimiento de estos requisitos. 159
160
DIAGRAMA DE CASOS DE USO Modelo de casos de uso Un Modelo de Casos de Uso es un modelo de las funciones deseadas de la aplicacin y sus ambientes, y sirve como un contrato entre el cliente y los desarrolladores. Los casos de uso sirven como un hilo unificador a lo largo de desarrollo de la aplicacin. El Modelo de Casos de Uso es el resultado del flujo de Requisitos y es usado como parte importante del Anlisis, Diseo y de la Prueba. Existen muchas maneras de modelar una aplicacin, cada una puede servir para un propsito diferente. Sin embargo, el propsito ms importante de un modelo de casos de uso es comunicar el comportamiento de la aplicacin al cliente o usuario final. Por consiguiente, el modelo debe ser fcil de entender. Los usuarios y cualquier otro sistema que pueden interactuar con la aplicacin a desarrollar, sern considerados como actores, porque estos representan a los usuarios de la aplicacin, los actores ayudan a delimitar la aplicacin y dan un cuadro ms claro de lo que se supone que debe hacer. Los casos de uso se desarrollan en base a las necesidades de los actores, esto asegura que la aplicacin terminar siendo la solucin que esperan los usuarios. Cmo Evoluciona el Modelo de Casos de Uso Los actores y los casos de uso son encontrados analizando las necesidades de los usuarios, el Modelo del Negocio (si es que se ha desarrollado) y los usuarios potenciales como informacin vital. Cuando los casos de uso son capturados, deben describirse de forma resumida (alto nivel) y los actores de igual forma. Antes de que los casos de uso se describan con todos los detalles necesarios para su completa comprensin, deben ser revisados por el cliente para verificar que se encuentran todos los casos de uso y actores, y que juntos pueden proporcionar lo que el cliente necesita. Cuando se han encontrado los actores y casos de uso, el flujo de eventos de cada caso de uso se describe de forma detallada. Estas descripciones muestran cmo el sistema interacta con los actores y lo que la aplicacin hace en cada caso individual. Finalmente, el Modelo de Casos de Uso terminado (incluyendo las descripciones de casos del uso) se revisa, los encargados de esta revisin son los diseadores y clientes, ya que son los que usarn y los interesados, ellos deben de estar de acuerdo en lo que la aplicacin har. Casos de Uso Concretos y Abstractos Existe una diferencia entre un Caso de Uso Concretos y un Casos de Uso Abstractos. Un caso del uso concreto es iniciado por un actor y constituye un flujo completo de eventos. "Concreto" significa que un caso de caso realiza la operacin de forma completa requerida por el actor. Un caso del uso abstracto nunca es iniciado por si mismo, ni tampoco iniciado por un actor. Los casos de uso abstractos son Incluido hacia, Extendido hacia, o Generalizado a. Cuando un caso de uso concreto comienza, una instancia del caso de uso abstracto se crea. 161
La diferencia entre los dos es importante, porque en los casos de uso concretos los actores sern los que utilicen. Existen cuatro tipos de relaciones o asociaciones (comunicacin) en el diagrama de casos de uso, son las siguientes: - Comunicacin. Es una relacin simple entre un actor y un caso de uso, como se puede ver en el ejemplo siguiente:
CU registrar cam bio de com ponente

(from registrar cambio de componente)
CU llenar inform e de reparacion de com ponente

(from llenar informe de reparacin)
CU gestionar contrasea CU autenticar usuario

(from autenticar) (from gestionar contrasea)
CU llenar recibo de com ponente nuevo Encargado del centro com puto
(f rom Actors)
(from registrar recibo componente nuevo)
indicar tipo de usuario

(from indicar tipo de usuario)
Usuario de sistem a
(f rom Actors)
CU Gestionar inventario CU Registrar cambio de tinta

(from registrar cambio de tinta) (from actualizar inventario )
Inclusin (Include). Si existe una parte de un caso de uso que representa una funcin que est en otro caso de uso, que slo depende del resultado, pero no el mtodo usado para producir el Funcionario Adm in (from Obserevar caracteristicas del equipo) resultado, se puede crear esa parte fuera a un caso de uso que sea adicional. La adiccin se CU llenar planilla reporte funcionam ineto de com putadora inserta, explcitamente, en un caso de uso relacionado con el creado y se debe incluir en la (from llenar planilla reporte funcionamiento computadora) relacin Incluir o Include. Como se puede ver en el ejemplo siguiente: CU Informar falla tcnica
CU Observar caracteristicas del equipo
(f rom Actors)
(from Informar falla tcnica)
CU llenar plantilla de recarga de tinta

(from llenar planilla de recarga de tinta)
Comprar por)Internet (from Solicitar software/hardware nuevo Cliente
CU Solicitar software/hardware nuevo
CU Solicitar carga de tinta

(from Solicitar carga de tinta)
<<include>>
Pagar con Tarjeta de Credito
Extencin (Extend). Si existe una parte de un caso del uso concreto que es optativa, es decir que exista una condicin lgica para su ejecucin o no necesaria, se puede crear un nuevo caso de 162
uso con la parte condicionada, esto ayuda a simplificar la estructura del caso de uso concreto. La adiccin se relaciona, implcitamente, con el caso de uso concreto y el creado, se debe usar la relacin Extender o Extend. Como se puede ver en el ejemplo siguiente: Ejemplo de comportamiento que se ejecuta bajo ciertas condiciones
Reportar Discrepancias
<<extend>>
Usuario
Chequear Pagos Realizados
<<extend>>
Especialista del Banco
Pagar Servicio por Internet
Buscar Cuentas Alternativas
Ejemplo de comportamiento que se ejecuta cuando lo indique el actor.
Herencia. Si hay casos del uso que tienen conducta en comn, estructura y similitudes dentro de su propsito, las partes comunes pueden ser separadas en un caso de uso concreto (padre), el cual puede heredas a otros casos de uso adicionales (hijos). Los casos de uso de Hijos pueden insertar nuevas conductas y pueden modificar la conducta en la estructura que ellos heredan del caso de uso de padre. Se puede usar la generalizacin de actores para mostrar cmo los casos de uso son especializaciones de otros entre si. Como se puede ver en el ejemplo siguiente:
Colocar Orden Empleado de Registro de Ordenes

(f rom Actors)
(from Colocar Orden)
Orden Telefnica
(from Actors)
Orden Por Internet

(from Actors)
Usuario
Usuario Internet
163
Un caso de uso debe ser simple, inteligible, claro y conciso. Generalmente hay pocos actores asociados a cada Caso de Uso. Para encontrar algunos parmetros en la construccin de un caso de uso se debe realizar las siguientes preguntas: Cules son las tareas del actor? Qu informacin crea, guarda, modifica, destruye o lee el actor? Debe el actor notificar a la aplicacin los cambios externos? Debe el sistema informar al actor de los cambios internos?
La flecha de comunicacin define al actor que inicia el caso de uso esperando una respuesta. Una lnea sin flecha asume una comunicacin bidireccional, donde el caso de uso es el que manda una respuesta a un actor, para luego, el actor, realice una actividad que active al caso de uso, pero pude que el caso de uso solo informe, en este caso la flecha apuntara al actor. Un caso del uso puede comenzarse segn una programacin (por ejemplo, una vez a la semana o una vez al da), que significa que el reloj de la aplicacin es el iniciador del caso de uso. Para la claridad del Diagrama de Casos de Uso, se debe utilizar un actor ficticio "Tiempo" para mostrar cmo el caso de uso se inicia. Un aspecto, importante, para la organizacin y comprensin del modelo de casos de uso, es agrupar los casos del uso en paquetes. Un paquete es un mecanismo de propsito general para organizar elementos en grupos. A continuacin se realiza el Diagrama de Casos de Uso para la aplicacin de Hotel. Para iniciar se debe determinar a los actores y a los casos de uso. En primer lugar se determina a los actores de la aplicacin, son los siguientes: Actor Recepcionista Descripcin Es la persona de atender al cliente en la reserva o confirmacin de una habitacin en el hotel, adems de llevar el costo del consumo que el cliente realice mientras este hospedado en el hotel. Este actor podr realizar actividades de reserva, confirmacin y cierre de cuenta para el cliente. Es una persona que est interesada en reservar una habitacin dentro del hotel. Este actor podr solo realizar la actividad de reserva de habitacin por medio de una interfaz Es la persona encargada de registrar las solicitudes de servicio de los clientes ya sea a la habitacin, donde se hospeda el cliente o en los servicios bsicos que ofrece el hotel para el cliente como desayuno, almuerzo o cena. Este actor podr realizar las actividades de registro de solicitudes Es la persona que se encarga de gestionar los permisos hacia la aplicacin, las bebidas y las comidas. Este actor podr realizar 164
Cliente
Jefe de Cocina
Administrador
las actividades de crear, actualizar y eliminar comidas y bebidas para los servicios hacia el cliente, adems de crear y modificar los permisos. Existen dos mtodos para la determinacin de los casos de uso, son los siguientes: Mtodo basado en Actores. En el mtodo debe tomarse en cuenta que los actores estn relacionados en una aplicacin o una empresa y que por cada actor se identifican los procesos que inician o en que participan. Mtodo basado en Eventos. En el mtodo debe identificarse a los eventos externos a los que la aplicacin debe responder y se debe analizar si los actores se relacionan con los actores y con casos de uso.
Para el ejemplo utilizaremos el primer mtodo. Actor Recepcionista Casos de Uso Reservar Habitacin Confirmar Reserva Salir del Hotel Cambiar Contrasea Autenticar Empleado Reservar Habitacin Cambiar Contrasea Autenticar Empleado Registrar Solicitud de Servicio a la Habitacin Registrar Solicitud de Servicio Bsico Gestionar Empleados Gestionar Bebidas Gestionar Cocina
Cliente Jefe de Cocina
Administrador
Como se puede observar, existen varios casos de uso que se repiten, lo que importa es identificar las actividades de cada actor, las cuales realizar con la aplicacin. Hay que sealar, que una ayuda para la determinacin de los casos de uso son los Diagramas de Actividad que corresponden a los casos de uso del negocio. Se debe realizar un anlisis de cada actividad dentro de los diagramas de actividad, debe preguntarse por cada actividad se pede automatizar?, ya que muchas, no todas, de las actividades son verbales o llegan a una solucin sin generar una informacin persistente. Otras situaciones que influyen en la decisin de automatizar, es la economa y la disponibilidad de los clientes y usuarios, ya que la tecnologa ser un limitante para el desarrollo del software, como tambin la disponibilidad de la inversin en dinero. Para el ejemplo, se propone una interfaz Web, para realizar una reserva de habitacin, ya sean los actores Cliente o Recepcionista podrn realizar la reserva de una habitacin, pero puede cambiar la poltica y decir que solo el Recepcionista es el encargado de realizar la reserva de la habitacin, en este caso puede que no sea necesario el desarrollo de una interfaz Web para realizar esta actividad. 165
Una vez identificados todos los casos de uso, que representa la solucin a las necesidades de los usuarios se debe crear el Diagrama de Casos de Uso. A continuacin se crea el Diagrama de Casos de Uso en el Rational Rose. La creacin es similar al Diagrama de Casos de Uso del Negocio. Iniciemos la creacin del Diagrama de Casos de Uso. Como se puede ver en la Pantalla 1, la ubicacin dentro del Rational Rose ser Use-Case Model (Modelo de Caso de Uso).
Pantalla 1. Ubicacin para la creacin del Modelo de Casos de Uso La carpeta de Use-Case Model est conformada por dos subcarpetas que son: Actors y Use Case (Actores y Casos de Uso), dentro de estas colocaremos, respectivamente, a los actores que se han determinado y a los casos de uso que se han captado de la aplicacin de ejemplo. Como se puede ver en la Pantalla 2, las subcarpetas tienen una estructura para documentar la aplicacin, muestra donde se tiene que colocar a los actores y como crear los casos de uso. Dentro de la carpeta Use Cases se encuentran dos subcarpetas con el nombre de Use Case Name e Included Use Cases. La primera subcarpeta nos indica que por casa caso de uso se debe crear una carpeta y dentro de esta, recin, el caso de uso. La segunda subcarpeta, Included Use Cases, es para los casos de uso que tienen una relacin con otro caso de uso de tipo Include. De igual forma que los casos de uso concretos, por cada caso de uso incluido debe existir una carpeta y dentro de esta el caso de uso.
Pantalla2. Plantilla para el Modelo de Casos de Uso
166
El primer paso es crear a los actores de la aplicacin, para esto se debe realizar un clic derecho en la carpeta Actors, se visualizar un men emergente, ya conocido, se debe seleccionar la opcin New, la cual desplegar un submenu, la opcin que se debe seleccionar es Actor, sobre la cual se debe realizar un clic como se puede ver en la Pantalla 3.
Pantalla 3. Crear un Actor de la aplicacin El resultado ser la Pantalla 4, donde se debe cambiar el nombre del actor por uno que sea significativo para la aplicacin.
Pantalla 4. Resultado de la Creacin de un Actor En la Pantalla 5 se ve al primer actor creado
Pantalla 5. Primer Actor Creado 167

Para los siguientes actores deben realizarse las operaciones anteriormente descritas. El resultado de la creacin de los actores se puede observar en la Pantalla 6.
Pantalla 6. Resultado de la creacin de los Actores de la Aplicacin Luego de crear a los actores resta crear a los casos de uso, es similar al proceso de creacin de los casos de uso de negocio. No debe olvidarse que por cada caso de uso debe existir una carpeta como se puede ver en la plantilla seleccionada al inicio de cada proyecto. Para crear un caso de uso se debe realizar un clic derecho en la carpeta Use Cases, esta actividad desplegar un men emergente como se puede ver en la Pantalla 7, debe seleccionarse la opcin New y luego Package, esta ltima permite crear una carpeta a la cual se debe cambiar el nombre.
Pantalla 7. Crear una Carpeta para el caso de uso
168
Como se dijo anteriormente, se debe cambiar el nombre a la carpeta, en este caso el nombre del primer caso de uso que se ha captado, que es: Reservar Habitacin. El resultado de esta actividad se puede ver en la Pantalla 8.
Pantalla 8. Cambio de Nombre de una Carpeta Queda crear el caso de uso, para esto se debe realizar un clic derecho en la carpeta Reservar Habitacin, aparecer un men emergente del cual se debe seleccionar la opcin New y Use Case, como se puede ver en la Pantalla 9.
Pantalla 9. Crear un Caso de Uso Una vez realizada la actividad, resta cambiar de nombre al caso de uso creado, en este caso ser Reservar Habitacin. El resultado de esta actividad se puede ver en la Pantalla 10.
169
Pantalla 10. Creacin del caso de uso Reservar Habitacin Para crear los otros casos de uso se debe realizar los pasos anteriormente descritos, el resultado se puede ver en la Pantalla 11. Se crea una carpeta por cada caso de uso, debido a que un caso de uso puede ser descrito ya sea por medio de un diagrama de actividad o de forma literal e incluso por medio de un diagrama de secuencia, diagrama de clases o un diagrama de estado. Estas descripciones estn en funcin de las polticas de la empresa o el grupo de desarrollo, por este motivo RUP aconseja que por cada caso de uso se deba crear una carpeta.
Pantalla 11. Resultado de crear los casos de Uso Para este ejemplo de aplicacin de Hotel, no se adiciona ningn otro estereotipo por caso de uso, solo se har una descripcin de forma literal. El paso final es crear el Diagrama de Casos de Uso, para realizar esta actividad se debe realizar un clic derecho en la carpeta Use-Case Model, aparecer un men emergente del cual se debe seleccionar la opcin de New y Use Case Diagram. Como se puede observar en la Pantalla 12.
170
Pantalla 12. Crear un Diagrama de Casos de Uso El siguiente paso es cambiar de nombre, el nombre debe ser Vista del Diagrama de Casos de Uso, como se puede ver en la Pantalla 13.
Pantalla 13. Cambio de nombre al Diagrama Una vez realizada la actividad se debe realizar doble clic en el diagrama, en la parte derecha de Rational Rose se visualizar una plantilla, en la cual se debe crear el Diagrama de Casos de Uso. Para crear el diagrama de casos de uso solo se debe arrastrar los actores y los casos de uso creados. El resultado se puede ver en Pantalla 14.
171
Pantalla 14. Casos de Uso y Actores en la Plantilla del Diagrama de Casos de Uso La actividad final es identificar las relaciones (comunicacin) que existe entre los actores y los casos de uso, para esto se debe utilizar el botn con el nombre de Unidireccional Association , se debe hacer un clic, ya sea en el actor o en el caso de uso, y arrastrar hasta el esteriotipo donde se piense que se tiene una relacin. El resultado de esta actividad se puede ver en la Pantalla 15.
172
Pantalla 15. Vista de Diagrama de Casos de Uso En la Vista del Diagrama de Casos de Uso se puede utilizar el concepto de Generalizacin para los actores, ya que varios de estos utilizan un mismo caso de uso, se recomienda, para la mejor comprensin del diagrama y para el futuro del Diagrama de Clases, que solo un actor sea el que inicia un caso de uso. En la Pantalla 16 se puede observar la utilizacin de la Generalizacin para los actores.
173
Pantalla 16. Utilizacin del Concepto de Generalizacin en Actores de la Aplicacin Para utilizar la Generalizacin en los actores se debe utilizar el botn Generalization para determinar la relacin es similar a la de actor con un caso de uso. , la operacin
De esta forma se ha creado el Modelo de Casos de Uso, en los prximos documentos se indica como describir los casos de uso, de forma tal que representen la interaccin entre el actor y la aplicacin. Los prximos documentos son muy importantes, ya que son temas muy interesantes y darn una visin diferente, ya sea, para la documentacin como en la planificacin en un proyecto de desarrollo de software.
174
DESCRIPCIN DE LOS CASOS DE USO DE LA APLICACIN Se cuenta con el Diagrama de Casos de Uso del Sistema que nos da una idea muy amplia de las funcionalidades que tendr la aplicacin. A continuacin se describe cada caso de uso de forma resumida (alto nivel) ya que en la parte de anlisis se har de forma completa con todas las interacciones del usuario hacia la aplicacin. Esta descripcin resumida nos permitir realizar una estimacin del esfuerzo, costo y tiempo a travs de los Puntos Funcin y los Casos de Uso. Esta tcnica se describir en este documento. A continuacin se realiza una breve descripcin de los casos de uso. La plantilla que se utiliza para la descripcin de los casos de uso es la siguiente: Caso de Uso Actores Resumen Nombre del caso de uso Actores Breve descripcin de lo que hace el CU Tabla 1. Plantilla para la descripcin de los Casos de Uso
DESCRIPCIN DE LOS CASOS DE USO Caso de Uso Actores Resumen Reservar Habitacin Usuario (Recepcionista y Cliente) El caso de uso se inicia cuando el Usuario quiere reservar una habitacin, respecto a su necesidad. La habitacin puede ser individual, doble o triple, el usuario debe registrar sus datos y la aplicacin tiene que proporcionarle opciones de seleccin para registrar la reserva. Confirmar Reserva Recepcionista El caso de uso se inicia cuando el Recepcionista debe confirmar la estancia de un Cliente hacia una habitacin, anteriormente reservada ya sea por el Cliente o el Recepcionista, la aplicacin debe dar la opcin de confirmar la habitacin enviando un mensaje. De esta forma el Cliente tendr una cuenta habilitada para todos los servicios del hotel. Salir del Hotel Recepcionista El caso de uso se inicia cuando el Recepcionista decide cerrar el hospedaje de un Cliente. El recepcionista debe calcular el monto de dinero que ha significado el servicio hacia el Cliente. La aplicacin debe proporcionar opciones para calcular el monto de dinero y emitir la factura 175
Caso de Uso Actores Resumen
Cambiar Contrasea Empleado (Recepcionista y Jefe de Cocina) El caso de uso se inicia cuando el empleado quiere cambiar la contrasea de acceso a la aplicacin. La aplicacin debe proporcionarle una interfaz para que pueda cambiar la contrasea de acceso, adems, debe emitir un mensaje de conformidad. Autentificar Empleado Empleado (Recepcionista y Jefe de Cocina) El caso de uso se inicia cuando el Empleado quiere ingresar a la aplicacin, para esto debe introducir su cuenta y contrasea de acceso a una interfaz que le proporciona la aplicacin. Registrar Solicitud de Servicio a la Habitacin Jefe de Cocina El caso de uso se inicia cuando el Jefe de Cocina va a registrar una solicitud de servicio a la habitacin que ha hecho el Cliente, esta solicitud involucra las comidas, las bebidas y la habitacin. La aplicacin le debe proporcionar una interfaz para registrar la solicitud, para esto debe seleccionar de una lista las bebidas y las comidas. Registrar Solicitud de Servicio Bsico Jefe de Cocina El caso de uso se inicia cuando el Jefe de Cocina va a registrar un solicitud de servicio bsico (Desayuno, Almuerzo o Cena) que ha hecho el Cliente a travs del mozo, esta solicitud involucra las comidas, las bebidas y la habitacin. La aplicacin debe proporcionar una interfaz para registrar la solicitud, para esto debe seleccionar de una lista las bebidas y las comidas solicitadas Gestionar Empleados Administrador El caso de uso se inicia cuando el Administrador necesita Adicionar, Modificar, Eliminar o Imprimir sus datos de un empleado. El sistema debe proporcionarle las opciones para realizar estas operaciones Gestionar Bebidas Administrador El caso de uso se inicia cuando el Administrador necesita Adicionar, Modificar, Eliminar o Imprimir datos de las bebidas disponibles para el 176
Cliente. La aplicacin debe proporcionarle las opciones para realizar estas operaciones Caso de Uso Actores Resumen Gestionar Comidas Administrador El caso de uso se inicia cuando el Administrador necesita Adicionar, Modificar, Eliminar o Imprimir datos de las comidas disponibles para el Cliente. La aplicacin debe proporcionarle las opciones para realizar estas operaciones Gestionar Habitacin Administrador El caso de uso se inicia cuando el Administrador necesita Adicionar, Modificar, Eliminar o Imprimir datos de las habitaciones disponibles para el Cliente. La aplicacin debe proporcionarle las opciones e interfaz para realizar estas operaciones
De esta forma se ha descrito de forma breve los casos de uso, lo cual da una pequea idea de la magnitud de la aplicacin. A continuacin realizaremos una estimacin de esfuerzo, costo y tiempo para la aplicacin Hotelera. ESTIMACIN DE ESFUERZO, COSTO Y TIEMPO Utilizar los Casos de Uso que permite documentar a los requisitos de una aplicacin en trminos de Actores y Casos de Uso. Como se ha explicado en anteriores documentos, un Actor tpicamente representa a un usuario humano o a otra aplicacin que interacta con la aplicacin bajo Desarrollo. Un Caso de Uso representa un requisito de la Aplicacin bajo anlisis, relata de forma secuencial las acciones que uno o ms actores llevan a cabo en el sistema para obtener un resultado de valor significativo. Si bien los Casos de Uso permiten especificar la funcionalidad de una aplicacin bajo anlisis, no permiten, por s mismos, efectuar una estimacin del tamao que tendr la aplicacin o del esfuerzo que tomara implementar. Para la estimacin del tamao de una aplicacin a partir de sus requisitos, una de las tcnicas ms difundidas es el Anlisis de Puntos de Funcin. sta tcnica permite cuantificar el tamao de un sistema en unidades independientes del lenguaje de programacin, las metodologas, plataformas y/o tecnologas utilizadas. Por otro lado, el SEI (del ingls, Software Engineering Institute) propone desde hace algunos aos un mtodo para la estimacin del esfuerzo llamado COCOMO II. ste mtodo est basado en ecuaciones matemticas que permiten calcular el esfuerzo a partir de ciertas mtricas de tamao estimado, como el Anlisis de Puntos de Funcin y las lneas de cdigo fuente (en ingls SLOC, Source Line Of Code).
177
Existe una relacin natural entre los Puntos de Funcin y los Casos de Uso. Los Puntos de Funcin permiten estimar el tamao del software a partir de sus requisitos, mientras que los Casos de Uso permiten documentar los requisitos. Ambos tratan de ser independientes de las tecnologas utilizadas para la implementacin. En etapas tempranas del ciclo de vida, se identifican los Actores y los Casos de Uso de la aplicacin y se documenta cada uno de estos mediante una breve descripcin. Utilizando el Anlisis de Puntos de Funcin a estos Casos de Uso, se podr obtener una estimacin grosera del tamao y a partir de esta del esfuerzo. Esta estimacin es bastante imprecisa debido, principalmente, a la escasa informacin que se tiene sobre el software al principio de un proyecto, pero permitir obtener una idea del esfuerzo necesario para llevar adelante el mismo, y podr ser refinada a medida que se obtenga ms informacin. Se recalca que es una estimacin, lo ms importante de esta actividad es que se podr realizar un plan para el desarrollo de software. La Planificacin est muy relacionada con las actividades de la estimacin, para determinar las actividades dentro de la planificacin es muy necesario conocer el tiempo, costo y el esfuerzo que se necesitarn para llevar a cabo el desarrollo. Pressman seala lo siguiente: Para llevar a cabo un buen proyecto de desarrollo de software, debemos comprender el mbito del trabajo a realizar, las tareas a ejecutar, las referencias a tener en cuenta, la agenda a seguir, el esfuerzo a emplear y los recursos requeridos. Con la descripcin y estudio de los casos de uso se determina el mbito del trabajo, las tareas a ejecutar y las referencias a tener en cuenta. Con la estimacin con ayuda de los Puntos Funcin y los Casos de Uso, se llega a determinar los recursos y el esfuerzo que se van a necesitar. Dentro de estos documentos que describen el desarrollo de una aplicacin no se llega a tocar el punto de planificacin del proyecto, la agenda de las actividades que se deben realizar para llevar a cabo el desarrollo. Pero, todo en la vida se debe planificar, si no se llega a obtener una planificacin no se podr hacer, no se tendr una estrategia y no se tendr un proyecto. El plan de proyecto debe tener en cuenta el alcance, tareas, calidad, mtricas, cronogramas y disponibilidad de recursoss. El desarrollo de software cumple un ciclo de vida como todo producto tangible, el ciclo de vida del proyecto de software se puede determinar en cinco fases de proceso que determina la Gua del PMBOK y son: Proceso de Inicializacin, Planificacin, Ejecucin, Seguimiento y Control y el Proceso de Cierre. En un prximo conjunto de documentos se hablar de la Gestin de Proyectos de Software. Para entender con mayor facilidad se define los siguientes conceptos: Esfuerzo: Tiempo que necesita una persona para trabajar en el desarrollo del proyecto (hombres/mes, hombres/das, hombres/horas). Tiempo: duracin total del proyecto. Cantidad de Personas: Recursoss necesarios para desarrollar el software. Costo: cantidad de dinero que se necesita para llevar a cabo el desarrollo de software. Transacciones: Est representada por uno o ms pasos del flujo de eventos principal del Caso de Uso, pudiendo existir ms de una transaccin dentro del mismo Caso de Uso. Los flujos de eventos alternativos dentro del Caso de Uso, ayudan a clarificar las transacciones.
178
La estimacin mediante el anlisis de Puntos de Casos de Uso es un mtodo propuesto originalmente por Gustav Karner de Objectory AB, y posteriormente refinado por muchos otros autores. Se trata de un mtodo de estimacin del tiempo de desarrollo de un proyecto mediante la asignacin de "pesos" a un cierto nmero de factores que lo afectan, para finalmente, contabilizar el tiempo total estimado para el proyecto a partir de esos factores. El primer paso es calcular los Puntos de Casos de Uso sin Ajustar. Este valor se calcula con la siguiente ecuacin: UUCP = UAW + UUCW donde, UUCP: Puntos de Casos de Uso sin ajustar UAW: Factor de Peso de los Actores sin ajustar UUCW: Factor de Peso de los Casos de Uso sin ajustar
El Factor de Peso de los Actores (UAW) sin ajustar se calcula mediante un anlisis de la cantidad de Actores presentes en el sistema y la complejidad de cada uno de ellos. La complejidad de los Actores se establece teniendo en cuenta: Si se trata de una persona o de otro sistema La forma en la que el actor interacta con el sistema.
Los criterios se muestran en la siguiente tabla Tipo de Actor Descripcin Factor de Peso Otro sistema que interacta con el sistema a desarrollar Simple mediante una interfaz de programacin 1 (API, Application Programming Interface) Otro sistema que interacta con el sistema a desarrollar Medio mediante un protocolo o una interfaz basada 2 en texto Una persona que interacta con el sistema mediante Complejo 3 una interfaz grfica Tabla 2. Posibles Factores de Peso de los Actores El Factor de Peso de los Casos de Uso sin Ajustar (UUCW) se calcula mediante un anlisis de la cantidad de Casos de Uso presentes en el sistema y la complejidad de cada uno de ellos. La complejidad de los Casos de Uso se establece teniendo en cuenta la cantidad de transacciones efectuadas en el mismo, donde una transaccin se entiende como una secuencia de actividades atmica, es decir, se efecta la secuencia de actividades completa, o no se efecta ninguna de las actividades de la secuencia. Los criterios se muestran en la siguiente tabla:
179
Tipo de Caso de Uso Descripcin Factor de Peso Simple El caso de uso tiene de 1 a 3 transacciones 5 Medio El caso de uso tiene de 4 a 7 transacciones 10 Complejo El caso de uso contiene ms de 8 transacciones 15 Tabla 3. Posibles Factores de Peso para los Casos de Uso Aplicando el anlisis al ejemplo de desarrollo que se desarrolla en estos documentos, se realiza el clculo de los Puntos de Casos de Uso sin Ajustar. Anlisis de los Actores para encontrar el Factor de Peso de Actores sin Ajustar Actor Factor Peso Cliente 3 Recepcionista 3 Jefe de Cocina 3 Administrador 3 UAW= 3+3+3+3 = 12 (Peso de los Actores sin Ajustar) Anlisis de los Casos de Uso para encontrar el Factor de Peso de Casos de Uso sin Ajustar El anlisis se debe hacer a cada caso de uso y pensar cuantas transacciones tiene cada uno de ellos. Casos de Uso Factor de Peso Reservar Habitacin (Una transaccin) 5 Confirmar Reserva (Dos transacciones) 5 Salir del Hotel (Cuatro Transacciones) 10 Cambiar Contrasea (Una Transaccin) 5 Autenticar Empleado (Una Transaccin) 5 Registrar Solicitud de (Tres Transacciones) 5 Servicio a la Habitacin Registrar Solicitud de (Tres Transacciones) 5 Servicio Bsico Gestionar Empleados (Siete Transacciones) 10 Gestionar Bebidas (Siete Transacciones) 10 Gestionar Comidas (Siete Transacciones) 10 Gestionar Habitacin (Siete Transacciones) 10 UUCW= 5+5+10+5+5+5+5+10+10+10+10 = 80 (Peso de Casos de Uso sin Ajustar) Finalmente, los Puntos de Casos de Uso sin ajustar seria: UUCP = 12 + 80 = 92 Nos falta calcular varias cosas antes de obtener el esfuerzo. 180
Una vez que se tiene los Puntos de Casos de Uso sin Ajustar se debe ajustar este valor mediante la siguiente ecuacin: UCP = UUCP x TCF x EF donde, UCP: Puntos de Casos de Uso ajustados UUCP: Puntos de Casos de Uso sin ajustar TCF: Factor de complejidad tcnica EF: Factor de ambiente
Para calcular el Factor de Complejidad Tcnica se debe definir varios Factores que influyen en la complejidad tcnica, son los siguientes: Sistema Distribuido. La aplicacin a desarrollar ser distribuida si varios mdulos estarn en varios lugares. Objetivos de Comportamiento o tiempo de respuesta. Si es necesario que el sistema de una respuesta en un espacio de tiempo mnimo. Si es en un entorno Web, el cargado entre paginas no sea muy lento Eficacia del Usuario Final. El usuario debe tener varias caminos para realizar su trabajo incrementando su eficacia Procedimiento Interno Complejo. Si la codificacin ser compleja y requerir de investigacin para realizarla o para optimizarla El cdigo debe ser reutilizable. Si varios mdulos o componentes deben poder ser utilizados en otras aplicaciones Facilidad de Instalacin. Si se debe crear inhaladores para la cmoda configuracin de la aplicacin Facilidad de uso. La aplicacin debe ser fcil de aprender, recordar, visible, entendible, etc Portabilidad. La aplicacin est desarrollada para facilitar el traslado de la tecnologa a otra. Facilidad de Cambio. La aplicacin debe estar implementada de manera que sea fcil detectar defectos y realizar los cambios para eliminarlos. Concurrencia. Si la aplicacin ser utilizada por un conjunto de personas grande debe comportase de manera ptima Incluye objetivos especiales de seguridad. Si va a ser necesario implementar parte de la seguridad para los datos o el acceso a la aplicacin. Provee acceso a terceras partes. Si la aplicacin ser utilizada por otras aplicaciones Se requiere facilidades especiales de entrenamiento a usuarios. Si se debe planificar un entrenamiento para que la aplicacin sea utilizada.
Este coeficiente se calcula mediante la cuantificacin de los factores explicados anteriormente, que determinan la complejidad tcnica del sistema. Cada uno de los factores se cuantifica con un valor de 0 a 5, donde 0 significa un aporte irrelevante y 5 un aporte muy importante. En la siguiente tabla se muestra el significado y el peso de cada uno de stos factores: 181
Factor T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13
Descripcin Peso Sistema Distribuido 2 Objetivos de Comportamiento o tiempo de respuesta 1 Eficacia del Usuario Final 1 Procedimiento Interno Complejo 1 El cdigo debe ser reutilizable 1 Facilidad de instalacin 0.5 Facilidad de Uso 0.5 Portabilidad 2 Facilidad de Cambio 1 Concurrencia 1 Incluye objetos especiales de seguridad 1 Provee Acceso directo a terceras partes 1 Se requiere facilidades especiales de entrenamiento a usuarios 1 Tabla 3. Factores que influyen en la Complejidad Tcnica
El Factor de Complejidad Tcnico se calcula mediante la ecuacin: TCF = 0.6 + 0.01 * (Pesoi * ValorAsignadoi) Para nuestro ejemplo el Factor de Complejidad Tcnica tendr el valor: Factor Descripcin T1 Sistema Distribuido T2 T3 Objetivos de Comportamiento o tiempo de respuesta Eficacia del Usuario Final Peso Comentario 2 La aplicacin utilizar varios Servicios Web 4 La aplicacin debe proporcionar una alta rapidez de respuesta a los Cliente 4 Debe asegurarse que la aplicacin proporcione una alta eficacia para los usuarios 2 No muchos clculos complejos 5 El cdigo debe ser reutilizable, los cual permita ser utilizado en otras aplicaciones 2 Escasos requisitos de facilidad de instalacin. 5 Es muy necesario crear interfaz que sean fciles de aprender, memorizar, que sean agradables y comprensibles. 2 Es necesario que sea compatible con los distintos navegadores Web existentes 1 Se debe garantizar la utilizacin de un estndar para la codificacin 3 La concurrencia ser relativamente 182
T4 T5
Procedimiento Interno Complejo El cdigo debe ser reutilizable
T6 T7
Facilidad de instalacin Facilidad de Uso
T8
Portabilidad
T9 T10
Facilidad de Cambio Concurrencia
T11 T12 T13
Incluye objetivos especiales de seguridad Provee Acceso directo a terceras partes Se requiere facilidades especiales de entrenamiento a usuarios
2 1 1
fluida Seguridad Baja Los Usuarios Web tienen acceso
TCF = 0.6 + 0.01 * (2*2 + 1*4 + 1*4 + 1*2 + 1*5 + 0.5*2 + 0.5*5 + 2*2 + 1*1 + 1*3 + 1*2 + 1*1 + 1*1) TCF = 0.945 Otro factor importante que debe calcularse es el Factor Ambiente (EF). Este factor determinar las habilidades. Y entrenamiento del grupo involucrado en el desarrollo tiene un gran impacto en la estimacin de tiempo. El clculo de este factor es similar al de Factor de Complejidad Tcnica, se debe cuantificar con valores de 0 a 5. La siguiente tabla muestra a los factores, la descripcin y el peso. Factor E1 E2 E3 E4 E5 E6 E7 E8 Descripcin Peso Familiaridad con el modelo del proyecto utilizado 1.5 Experiencia en la aplicacin 0.5 Experiencia en Teora Orientado a Objetos 1 Capacidad del Analista Lder 0.5 Motivacin de los involucrados en el desarrollo 1 Estabilidad de los requisitos 2 Personal Tiempo Parcial (Part-Time) -1 Dificultad del Lenguaje de Programacin -1 Tabla 4. Factores que influyen en el Ambiente
Para los factores E1 al E4, un valor asignado de 0 significa sin experiencia, 3 experiencia media y 5 amplia experiencia (experto). Para el factor E5, 0 significa sin motivacin para el proyecto, 3 motivacin media y 5 alta motivacin. Para el factor E6, 0 significa requisitos extremadamente inestables, 3 estabilidad media y 5 requisitos estables sin posibilidad de cambios. Para el factor E7, 0 significa que no hay personal tiempo parcial (es decir todos son tiempo completo), 3 significa mitad y mitad, y 5 significa que todo el personal es tiempo parcial (nadie es tiempo completo). Para el factor E8, 0 significa que el lenguaje de programacin es fcil de usar, 3 medio y 5 que el lenguaje es extremadamente difcil.
El Factor Ambiente se debe calcular con la siguiente ecuacin: EF = 1.4 0.03 * (Pesoi * Valor Asignadoi) Ahora se calcula el factor ambiente para el ejemplo que se est desarrollando 183
Factor Descripcin E1 E2 E3 E4 E5 E6 E7 E8
Valor Asignado Familiaridad con el Modelo del Proyecto 3 utilizado Experiencia en la aplicacin 4 Experiencia en Teora Orientada a 5 Objetos Capacidad del Analista Lder 3 Motivacin de los involucrados en el 5 Desarrollo Estabilidad de los requisitos 2 Personal Tiempo Parcial (Part-Time) 0 Dificultad del Lenguaje de Programacin 3
Comentario Est Familiarizado con el Modelo Se ha trabajado desde el inicio de la aplicacin Se tiene una fuerte preparacin El principiante pero tiene la especialidad Se tiene una gran motivacin para el desarrollo de la aplicacin Se esperan cambios La persona ser la encargada de llevar el desarrollo hasta la finalizacin Se usar el lenguaje C#
El valor del Factor Ambiente ser: EF = 1.4 0.03 (1.5*3 + 0.5*4 + 1*5 + 0.5*3 + 1*5 + 2*2 - 1*0 - 1*3) EF = 0.83 (Factor Ambiente) Ahora se debe calcular los Casos de Uso ajustados. Los dos factores anteriormente calculados ayudaran a ajustar los casos de uso. UCP = UUCP x TCF x EF UCP = 92 * 0.945 * 0.83 UCP = 72.16 (Puntos de Casos de Uso) Con este ltimo clculo se podr calcular el Esfuerzo. Un investigador llamado Gustav Karner propuso, en el ao 1993, que para cada Punto de Caso de Uso requiere 20 horas-hombre. Pero, en el transtexto del tiempo se ha perfeccionado al siguiente criterio: Se contabilizan cuntos factores de los que afectan al Factor de ambiente estn por debajo del valor medio (3), para los factores E1 a E6. Se contabilizan cuntos factores de los que afectan al Factor de ambiente estn por encima del valor medio (3), para los factores E7 y E8. Si el total es 2 o menos, se utiliza el factor de conversin 20 horas-hombre/Punto de Casos de Uso, es decir, un Punto de Caso de Uso toma 20 horas-hombre. Si el total es 3 o 4, se utiliza el factor de conversin 28 horas-hombre/Punto de Casos de Uso, es decir, un Punto de Caso de Uso toma 28 horas-hombre. Si el total es mayor o igual que 5, se recomienda efectuar cambios en el proyecto, ya que se considera que el riesgo de fracaso del mismo es demasiado alto.
184
Por esta teora, se determina que cada Punto de Caso de Uso tendr 20 horas-hombre para nuestro ejemplo de desarrollo. Para calcular el esfuerzo se debe aplicar la siguiente ecuacin: E = UCP * CF Donde: E es el Esfuerzo CF es Factor de Conversin UCP es Casos de Uso Ajustados El Factor de Conversin ser 20 horas-hombre Se debe tomar en cuenta que los clculos hechos para estimar de esfuerzo solo pertenecen a la parte del ciclo de vida de la implementacin o codificacin. Para una estimacin ms completa de la duracin total del proyecto, hay que agregar a la estimacin del esfuerzo obtenida por los Puntos de Casos de Uso, las estimaciones de esfuerzo de las dems actividades relacionadas con el desarrollo de software. Para ello se puede tener en cuenta el siguiente criterio, que estadsticamente se considera aceptable. El criterio plantea la distribucin del esfuerzo entre las diferentes actividades de un proyecto, segn la siguiente aproximacin: Actividad Porcentaje (%) Anlisis 10 Diseo 20 Programacin 40 Prueba 15 Sobrecarga (otras actividades) 15 Tabla 5. Porcentajes que involucran el tiempo de desarrollo Estos porcentajes pueden variase considerando la experiencia que se tenga en el desarrollo y se debe justificar la variacin. Para el ejemplo que se est desarrollando el clculo del esfuerzo ser: E = 72.16 * 20 E = 1443.204 Horas-Hombre Si se toma en cuenta que se trabaja 8 horas diarias y 20 das al mes se tardara en implementar esta aplicacin 9 meses para una sola persona. Para calcular el total del esfuerzo se debe calcular, por una regla de tres las otras fases. Actividad Anlisis
Porcentaje 360.801 185
Diseo Programacin Prueba Sobre Carga (Otras Actividades) TOTAL
721.602 1443.204 541.2015 541.2015 3608.01
Si se toma que se trabaja 8 horas al da y 20 das al mes el tiempo total para el desarrollo 22 meses. Bastante tiempo para una sola persona. Pero si se trabaja en equipo, por lo menos cuatro personas que se encarguen de las primeras cuatro actividades, el tiempo de desarrollo seria de 5 meses. Para calcular el costo de desarrollo se toma como parmetro el sueldo mnimo nacional que es de Bs.500. Esto significa que por hora se paga Bs.- 3. Si multiplicamos el total del esfuerzo por el valor por hora el resultado sera Bs.- 10824.03. De esta forma se ha culminado la estimacin del Esfuerzo, Costo y Tiempo. Como se puede entender es importante tener una experiencia alta para realizar la estimacin del numero de transacciones por cada casos de uso, adems de definir correctamente los pesos de los factores. Un detalle que nos lleva a reflexionar es el monto del salario mnimo nacional utilizado en el clculo anterior. Si se hace una estimacin solo se gana Bs.- 25 por da trabajado. Se gana menos que una persona que realiza actividades tcnicas, ya que estas personas tienen un pago de Bs.- 50 por da. Siendo una actividad muy compleja el desarrollar software, como se ha descrito en estos documentos, no es posible que se gane por da Bs.- 25. Aunque muchos dirn que es fcil hoy en da, implementar software, pero surgen preguntas A qu costo? A qu Calidad? Cunto durar el Software? La persona que ha desarrollado software se convertir en un activo fijo en la organi zacin? Es claro que surgen ms preguntas, a las cuales se debe responder con claridad. Una vez determinado el esfuerzo, tiempo y costo, podemos realizar una planificacin de las actividades principales del desarrollo de software. Este texto no entra en detalles de la planificacin de las actividades del Desarrollo de Software. Sin embargo, se muestra en los cuadros siguientes un ejemplo de planificacin de un proyecto. No se debe olvidar que la planificacin es un proceso que va desde la determinacin de las actividades pasando por la definicin de los riesgos hasta la gestin del proyecto. EJEMPLO DE PLAN DE PROYECTO DE SOFTWARE
186
187
188
En el siguiente documento se determinan los requisitos no funcionales de la aplicacin, los cuales sern los que hablen de la aplicacin desarrollada.
189
DETERMINACIN DE LOS REQUISITOS NO FUNCIONALES DE LA APLICACIN
Se debe definir los requisitos no funcionales del software a desarrollar. Implica la determinacin de los atributos no funcionales asociadas a las facilidades, funcionalidades y de caractersticas generales del software como controles necesarios para garantizar la confiabilidad del sistema, seguridad propuesta, requisitos de la calidad, interfaces con otros sistemas de procesamiento manual o automatizado, ambiente de software y hardware. Para la definicin de los requisitos no funcionales se utilizar la clasificacin de la Norma ISO-9126 (2000), el modelo de calidad que clasifica los atributos de la calidad del software en seis caractersticas, que son adems divididas en sub-caractersticas. El efecto combinado de las caractersticas de calidad de software para el usuario se define como la calidad en el uso. Las caractersticas definidas son aplicables a todo tipo de software. La ISO 9126 permite especificar y evaluar la calidad del producto de software desde las perspectivas diferentes, asociados con la adquisicin, regulacin, desarrollo, uso, evaluacin, apoyo, mantenimiento, aseguramiento de la calidad y auditora del software. El modelo de calidad definido puede usarse para: Validar la integridad de la definicin de los requisitos; Identificar los requisitos no funcionales del software (Este punto es el que interesa para este documento); Identificar los objetivos del diseo del software; Identificar los objetivos de prueba del software; Identificar el criterio de aceptacin de usuario para un producto de software completo.
Las seis caractersticas son: Funcionalidad. La capacidad del software para proporcionar funciones que satisfacen las necesidades declaradas e implcitas cuando el software se usa bajo las condiciones especificadas. Esta caracterstica est relacionada con lo que hace el software para satisfacer las necesidades. o La Idoneidad. La capacidad del software para mantener un conjunto apropiado de funciones para las tareas especificadas y los objetivos del usuario. o La Precisin. La capacidad del software para proporcionar efectos o resultados correctos o convenidos en clculos y resultados. o La Interoperabilidad. La capacidad del software para actuar recprocamente con uno o ms sistemas especificados. La interoperabilidad se usa en lugar de la compatibilidad para evitar la posible ambigedad o La Seguridad. La capacidad del software para proteger informacin y los datos, para que personas o sistemas desautorizados no puedan leer o pueden modificar los mismos, y a las personas o sistemas autorizados no les sea denegado el acceso a ellos. Debe aplicarse a los datos en transmisin. Debe tomarse en cuenta para la aplicacin completa o La Conformidad. La capacidad del software para adherirse a las normas que se le apliquen , convenciones, regulaciones, leyes y las prescripciones similares Confiabilidad. La capacidad del software para mantener su nivel de ejecucin cuando se usa bajo las condiciones especificadas. El sobre uso o el envejecimiento no ocurre en el software 190
o La Madurez. Capacidad del software de evitar errores como resultado de haberse producido un fallo del software o La Tolerancia ante fallos. Capacidad del software de mantener un nivel de ejecucin especfico en caso de fallos del software o de infraccin de sus interfaces especificadas. Un nivel de ejecucin especfico puede incluir la falta la capacidad segura o La facilidad de restablecer. Capacidad del software de restablecer su nivel de ejecucin y recobrar los datos directamente afectados en caso de avera. Facilidad de Uso. La capacidad del software ser comprendido, aprendido, utilizado y de ser amigable para el usuario, cuando se emplee bajo las condiciones especificadas. o La Facilidad de Comprensin. La capacidad del producto de software para permitirle al usuario entender si el software es conveniente, y cmo puede usarse para las tareas particulares y condiciones de uso. Esto depender de la documentacin y la impresin inicial dada por el software. o La Facilidad Cognoscitiva. La capacidad del producto del software para permitirle al usuario aprender su aplicacin. o La Operabilidad. La capacidad del producto del software para permitirle al usuario operarlo y controlarlo. Operabilidad corresponde a la capacidad de ser controlado, la tolerancia ante errores y la conformidad con las expectativas del usuario o La Atraccin. La capacidad del producto del software de ser amigable para el usuario. Esto se refiere a los atributos del software que se aplican para hacer el software ms atractivo al usuario. Eficiencia. La capacidad del software para proporcionar la requerida ejecucin, en relacin con la cantidad de recursos usados, bajo las condiciones declaradas. o El crono-comportamiento. La capacidad del software para proporcionar una respuesta apropiada y los tiempos de procesamiento y tasas de rendimiento de procesamiento al realizar su funcin, bajo condiciones declaradas. o La Utilizacin de los Recursos. La capacidad del software para usar los recursos apropiados en un plazo de tiempo adecuado cuando el software realiza su funcin bajo las condiciones declaradas Facilidad de mantenimiento. La capacidad del software de ser modificado. Las modificaciones pueden incluir las correcciones, mejoras o adaptacin del software a los cambios en el ambiente, y en los requisitos y las especificaciones funcionales. o La Facilidad de Diagnostico. La capacidad del producto del software ser diagnosticado para detectar deficiencias o causas de defectos o errores en el software y detectar a las partes para ser modificadas para ser identificadas o La Mutabilidad. La capacidad del producto del software para permitir llevar a cabo una modificacin especificada. Incluye la codificacin, diseo y documentacin de los cambios. o La Estabilidad. La capacidad del software para minimizar los efectos inesperados de las modificaciones del software. o La facilidad de Comparacin. La capacidad del producto del software para permitir validar el software modificado Portabilidad. Capacidad de software ser transferido de un ambiente a otro. El ambiente puede incluir el ambiente del software, del hardware u organizacional o La facilidad de adaptacin. La capacidad del software de ser modificado para los ambientes especificados sin aplicar acciones o medios de otra manera que aquellos 191
suministrados con este propsito para el software considerado. Adaptabilidad incluye el escalado de la capacidad interna (por ejemplo los campos de la pantalla, las tablas, los volmenes de transaccin o los formatos de informes.). o La facilidad de Instalacin. La capacidad del software ser instalado en un ambiente especificado o La coexistencia. La capacidad del software para coexistir con otro software independiente en un ambiente comn que comparte los recursos comunes o La facilidad de Reemplazo. La capacidad del software ser usado en lugar de otro software especificado en el ambiente de ese software. Se usa en lugar de la compatibilidad para evitar la posible ambigedad con el interoperabilidad. Como se puede comprender, sobre estas caractersticas o atributos del software, es muy importante tenerlas muy en cuenta y definirlas. Es claro que para un determinado software se seleccionan algunas de estas caractersticas, esto se debe a gran variedad de tipos de software que se pueden desarrollar, no es lo mismo desarrollar un editor de texto que una aplicacin de gestin de informacin. Pero al seleccionar, estos atributos, implica un compromiso de demostrar al final del desarrollo que se ha llegado a una conformidad exitosa de estas. En prximos textos se hablar de mtricas de software que ayudan a validar el software sobre las caractersticas definidas y el cmo evaluar. Para este documento, la visin de la utilizacin de estas caractersticas es poder identificar a los requisitos no funcionales de la aplicacin que se est modelando. De este modo se definir algunas de las caractersticas que a consideracin del Grupo de Investigacin corresponden para la aplicacin Hotelera. REQUISITOS NO FUNCIONALES PARA LA APLICACIN FUNCIONALIDAD La Idoneidad. La aplicacin debe proporcionar opciones bien descritas para los usuarios, explicando la operacin que se puede realizar. La Precisin. Debe proporcionar al usuario opciones que permiten realizar el trabajo y deben estar correctamente descritas y debe existir una orientacin para cada una de ellas. No debe presentarse al usuario opciones restringidas La Seguridad. El acceso a la aplicacin debe estar controlada por una contrasea y nombre de usuario. La contrasea debe estar protegida de acuerdo a un algoritmo de encriptacin a un nivel internacional, correctamente documentado. Debe garantizarse que la informacin transmitida no pueda ser capturada o interpretada.
CONFIABILIDAD. La Madurez. Debe presentarse al usuario informacin sobre los errores que comete al utilizar al aplicacin, estos errores deben estar bien identificados y en el idioma Espaol. Los mensajes de 192
error deben contar con una ayuda para orientar al usuario en su trabajo as no cometer reiteradamente el mismo error, adems debe existir una explicacin del porqu del error. FACILIDAD DE USO. La Facilidad de Comprensin. La aplicacin debe ayudar al trabajo o al inters del usuario. Debe explicarse de una manera correcta las distintas opciones que le permite la aplicacin o una determinada interfaz. Cada opcin debe escribirse de forma completa La Facilidad Cognoscitiva. Debe considerarse imgenes para la mejor comprensin y aprendizaje de la aplicacin, tomando en cuenta el tiempo de ejecucin. La Atraccin. Debe definirse un estndar de interfaz tomando en cuenta los colores de la institucin y los colores de la empresa que desarrolla la aplicacin, ya que con estas dos combinaciones se tiene la probabilidad de que el usurario este cmodamente trabajando con la aplicacin. No se debe olvidar el estndar que proporciona la interfaz Windows y el diseo de interfaz que muestra Microsoft para las pginas Web.
EFICIENCIA. La Utilizacin de los Recursoss. Debe utilizarse procedimientos almacenados bsicos, que no tengan ms de una sentencia, esto para el acceso a la base de datos. Los filtros de bsquedas o lgica del negocio para los datos debe implementarse en la capa de negocio.
FACILIDAD DE MANTENIMIENTO. La Facilidad de Diagnostico. Debe realizarse la Prueba con la ayuda de los casos de uso de prueba. De esta forma garantizar el buen funcionamiento de la aplicacin.
PORTABILIDAD. La facilidad de adaptacin. Se debe utilizar un marco de trabajo que garantice un mantenimiento respecto a la tecnologa que pueda aparecer y a los paradigmas de desarrollo de interfaz. Adems, la interfaz a desarrollar debe ser probada en distintos escenarios de navegadores y/o computadoras, para de esta forma garantizar la adaptacin de la aplicacin. La facilidad de Instalacin. Debe crearse para la aplicacin un paquete de instalacin con su respectivo manual para que los encargados de la aplicacin puedan restablecer con bastante rapidez la aplicacin, debe tomarse en cuenta que pude ser ms de un instalador ya que la aplicacin est orientada a los Servicios. Solo se tomar en cuenta la tecnologa Windows para desarrollar el paquete de instalacin. La coexistencia. Debe poderse instalar en una sola computadora toda la aplicacin, ya sea los Servicios Web como las Aplicaciones Web. Pero, deben tener caractersticas independientes.
De esta forma se ha especificado los Requisitos No Funcionales para la aplicacin de Hotel. Como se ha dicho anteriormente, al describir los atributos se llega a un compromiso de cumplimiento de cada uno de estos. Este texto no demostrar el cumplimiento de estos ya que se tiene que estudiar parte de la teora de Mediciones y Mtricas en el Software. 193
Luego de determinar y explicar cmo tiene que llevarse a cabo los requisitos no funcionales se deben realizar varias actividades adicionales son las siguientes: Determinar la importancia y el riesgo Separar en ciclos (Priorizar). Determinar los paquetes Detallar de forma expandida (completa)
DETERMINAR LA IMPORTANCIA Y EL RIESGO Para realizar estas dos tareas, las cuales se las puede llevar conjuntamente se debe realizar un anlisis por cada caso de uso y determinar la importancia que tiene en la aplicacin, se puede utilizar una escala del 1 al 5, donde 5 es ms significativo. Esto se realiza para determinar parte del dominio del riego por requisito y determinar cual caso de uso debe ser ms estudiado para no tener dificultades. Luego se determina el total del dominio de riesgo por cada caso de uso, para esto se realiza un estudio del flujo bsico de cada caso de uso y los procesos de la empresa a travs del los diagrama de actividad. El riego es considerado como el cambio que se puede producir en el requisito. Muchos de los requisitos (casos de uso) pueden cambiar en su flujo bsico de interaccin con el usuario o que la empresa cambie sus procesos que van a influenciar al requisito, este cambio implica un cambio total en todas las etapas. Por este motivo es muy importante determinar el riesgo de cada caso de uso. El riesgo y la importancia que se determinen permitirn realizar un seguimiento correcto a los casos de uso. En este texto no se ve como llevar a cabo estas tareas. SEPARAR EN CICLOS DE DESARROLLO. Una vez determinada la importancia de los casos de uso se pueden separar por ciclos de desarrollo. Un ciclo de desarrollo ser llevado a cabo de principio a fin, logrando en su finalizacin un producto que funcione y que este probado. Cada ciclo, que est compuesto por casos de uso, seguir un ciclo de vida del producto. A continuacin se ve un ejemplo de cmo se ha determinado los ciclos de desarrollo. Se ve en la Figura 1 un diagrama de casos de uso que corresponde a una aplicacin que distribuye productos de todo tipo.
194
Autenticar Cambiar Contrasea

(f rom Cambiar Contrasea) (f rom Autenticar)
Registar Horas de Trabajo

(f rom Registrar Horas de Trabajo)
Gestionar Ventas
(f rom Gestionar Ventas)
Gestionar Reportes de Personal

(f rom Gestionar Reportes de Personal)
Personal Usuario Asi gnar Movil idad

(f rom Asignar Mov ilidad)
(from Actors) (from Actors)
Gestionar Reportes de Cl iente Asi gnar Ruta

(f rom Asignar Ruta)
Contador
(from Actors)
(f rom Gestionar Reportes de Cliente)
Gestionar Rutas
(f rom Gestionar Rutas)
Gestionar Reportes de Ingreso de Producto

(f rom Gestionar Reportes de Ingresos Producto)
Gestionar Gastos
(f rom Gestionar Gastos)
Gestionar Reportes de Ventas

(f rom Gestionar Reportes de Ventas)
Administrador
(from Actors)
Gestionar Ingresos de Producto Gestionar Producto

(f rom Gestionar Producto) (f rom Gestionar Ingresos de Producto)
Gestionar Reportes de Rutas

(f rom Gestionar Reportes de Rutas)
Gestionar Reportes de Gastos

(f rom Gestionar Reportes de Gastos)
Gestionar Reportes de Di stribuidores Asi gnar Activo Solicitar Pedi do a los Distribui dores
(f rom Asignar Activ o) (f rom Solicitar Pedido a los Distribuidores) (f rom Gestionar Reportes de Distribuidores)
Gestionar Personal
(f rom Gestionar Personal)
Gestionar Distribuidores
(f rom Gestionar Distribuidores)
Gestionar Reportes de Activo Fijo Gestionar Cliente Gestionar Activo Fij o

(f rom Gestionar Activ o Fijo) (f rom Gestionar Cliente) (f rom Gestionar Reportes de Activ o Fijo)
Figura 1. Diagrama de Casos de Uso Distribucin de Productos La Figura 2 muestra el Primer Ciclo de desarrollo
Cambiar Contrasea
(from Cambiar Contrasea)
Autenticar
(from Autenticar)
Personal
(f rom Actors)
Gestionar Distribuidores
(from Gestionar Distribuidores)
Gestionar Ingresos de Producto

(from Gestionar Ingresos de Producto)
Usuario
(f rom Actors)
Gestionar Ventas
(from Gestionar Ventas)
Administrador
(f rom Actors)
Gestionar Producto
(from Gestionar Producto)
Contador
(f rom Actors)
Solicitar Pedido a los Distribuidores

(from Solicitar Pedido a los Distribuidores)
Gestionar Personal
(from Gestionar Personal)
Gestionar Cliente
(from Gestionar Cliente)
Gestionar Reportes de Ventas

(from Gestionar Reportes de Ventas)
Figura 2. Primer Ciclo de Desarrollo 195

En la siguiente figura, Figura 3, se ve el Segundo ciclo.
Administrador
(f rom Actors)
Asignar Activo
(from Asignar Activo)
Gestionar Rutas
(from Gestionar Rutas)
Gestionar Reportes de Activo Fijo Asignar Ruta

(from Asignar Ruta)
Gestionar Activo Fijo
(from Gestionar Reportes de Activo Fijo) (from Gestionar Activo Fijo)
Asignar Movilidad
(from Asignar Movilidad)
Contador
(f rom Actors)
Gestionar Reportes de Cliente Gestionar Reportes de Ingreso de Producto

(from Gestionar Reportes de Ingresos Producto) (from Gestionar Reportes de Cliente)
Gestionar Reportes de Distribuidores

(from Gestionar Reportes de Distribuidores)
Figura 3. Segundo Ciclo de Desarrollo La siguiente Figura 3 muestra el ltimo ciclo de desarrollo.
Contador
(f rom Actors)
Gestionar Gastos
(from Gestionar Gastos)
Registar Horas de Trabajo

(from Registrar Horas de Trabajo)
Gestionar Reportes de Gastos Gestionar Reportes de Personal

(from Gestionar Reportes de Personal) (from Gestionar Reportes de Gastos)
Gestionar Reportes de Rutas

(from Gestionar Reportes de Rutas)
Administrador
(f rom Actors)
196
Figura 4. Tercer Ciclo de Desarrollo Como se puede observar, cada ciclo representa parte de las funcionalidades futuras de la aplicacin de la aplicacin que se irn construyendo. A continuacin, se lleva a cabo el anlisis de los ciclos para la aplicacin que sirve de emplo. La Pantalla 1 es el resultado del desarrollo del Diagrama de Casos de Uso, el cual no servir para analizar los ciclos de desarrollo.
Pantalla 1. Diagrama de Casos de Uso Existen muchas alternativas para definir los ciclos de desarrollo. Se puede dividir en ciclo de desarrollo, por ejemplo, por Actor de la aplicacin, es decir tener cuatro ciclos de desarrollo, que serian: Primer Ciclo: Gestionar Empleados, Gestionar Bebidas, Gestionar Cocina. Segundo Ciclo de Desarrollo: CU Reservar Habitacin, CU Confirmar Reserva, CU Salir del Hotel. Tercer Ciclo de Desarrollo: Cambiar Contrasea, Autenticar Empleado. Cuarto Ciclo de Desarrollo: CU Registrar Solicitud de Servicio a la Habitacin, CU Registrar Solicitud de Servicio Bsico.
197
Tambin, se puede dividir por funcionalidad de los casos de uso, es decir, los que estn relacionados para realizar una actividad completa, por ejemplo: Primer Ciclo de Desarrollo: Gestionar Empleados, Autenticar Empleado, Cambiar Contrasea. Segundo Ciclo de Desarrollo: CU Reservar Habitacin, CU Confirmar Reserva, Salir Hotel. Tercer Ciclo de Desarrollo: Gestionar Bebidas, Gestionar Cocina, CU Registrar Solicitud de Servicio Bsico, CU Registrar Solicitud de Servicio a la Habitacin.
Como se puede ver, en los dos casos, al final de cada ciclo el resultado debe ser una aplicacin que pueda realizar algunas de las tareas necesarias para el usuario. Dentro del primer ciclo se debe seleccionar a los casos de uso que sean independientes, con poco acoplamiento entre los otros. Por ejemplo, para reservar una habitacin, el Empleado debe estar autenticado y tener autorizacin para realizar esta actividad, caso contrario no se podra reserva la habitacin, por este motivo es necesario desarrollar el primero el caso de uso que es Gestionar Empleado, luego Autenticar Empleado y Cambiar Contrasea. Este tipo de anlisis se debe realizar para determinar cada ciclo de desarrollo. Para el ejemplo de desarrollo, se toma la segunda opcin de divisin de ciclos. Como se puede ver en las siguientes Pantallas, se ha dividido por ciclo. El primer Ciclo a desarrollar se pude ver en la Pantalla 2.
Pantalla 2. Primer Ciclo de Desarrollo El Segundo Ciclo de Desarrollo se puede ver en la Pantalla 3.
198
Pantalla 3. Segundo Ciclo de Desarrollo El Tercer Ciclo de Desarrollo se puede ver en la Pantalla 4.
Pantalla 4. Tercer Ciclo de Desarrollo Cada uno de estos ciclos tendr las siguientes caractersticas (Ejemplo): 199
Planificacin para llevar a cabo el desarrollo por cada caso de uso Asignacin de personas para el desarrollo Plan de revisiones Plan de integracin La disciplina de Anlisis si es que se debe hacer La Disciplina de diseo La Disciplina de Implementacin La disciplina de Prueba
Cada ciclo que se determine tendr muchos artefactos que le acompaen, esto implica realizar todas las actividades del desarrollo de software. En el texto no se llevar a cabo el desarrollo por ciclos, solo se utilizara dos casos de uso que permitan ejemplificar algunas de las actividades necesarias para tener una aplicacin. Los otros dos puntos de Determinar los Paquetes y Detallar de forma Expandida se vern con mayor detalle en los prximos documentos.
200
FLUJO DE ANLISIS: DESCRIPCIN DETALLA DE CASOS DE USO En este documento iniciaremos el desarrollo de la aplicacin de forma interna, pensando en el desarrollador y ya no en la interaccin del Actor (Usuario) con la aplicacin. INTRODUCCIN. Dentro la documentacin de RUP (Rational Unified Process), existe la disciplina de Anlisis y Diseo, la cual tiene como objetivo la traduccin de las distintas interacciones entre el actor y la aplicacin (Requisitos expresados en Casos de Uso) a un lenguaje de programador, esto permitir una comprensin ms clara de los requisitos capturados y descritos hacia los analistas y diseadores. Para realizar esta traduccin se debe entender muy bien los requisitos de la aplicacin (Casos de Uso) y transformarlos de una manera ptima para cumplir con los objetivos del proyecto. Uno de los objetivos fundamentales del anlisis es transformar los requisitos en forma de mapa, permitiendo describir una solucin compuesta por objetos (clases), adems entender correctamente el problema que implicar el desarrollo de la aplicacin. Para esto se toman en cuenta los requisitos funciones y algunos no funcionales para realizar la transformacin. El anlisis se centra en la comprensin de los requisitos funcionales por parte de los desarrolladores. Otros autores sealan que el anlisis es el descubrimiento del comportamiento de la aplicacin para luego decidir cmo ser manejada. Se necesita descomponer los requisitos en los elementos y relaciones esenciales, los cuales sern la base de la solucin. El anlisis es el primer paso para poder expresar el mundo como objeto. El anlisis se desarrolla cuando existe: Una incertidumbre sobre la tecnologa que servir para la implementacin e implantacin de la aplicacin. Si los riesgos de los requisitos y del proyecto son muy elevados. Se entiende Riesgos de Requisitos como la inestabilidad de los estos, que puedan cambiar en el proceso de desarrollo y en la vida del software. Cuando se necesita implementar en distintas plataformas, arquitecturas, marcos de trabajo, hardware, niveles de seguridad, entres otros.
No es necesario desarrollar el Anlisis, slo se realiza cuando existen las condiciones sealadas anteriormente. Tambin, uno de los objetivos importantes del anlisis es mantener el software para incrementar su vida de productividad, este mantenimiento es necesario ya que la tecnologa va cambiando muy rpidamente, esto implica realizar cambios en el software. En el desarrollo del anlisis no debe tomarse en cuenta la tecnologa como: Lenguajes de Programacin, Hardware, Plataforma de desarrollo, entre otras. Todas estas se deben emplear en el Diseo y la Implementacin de la aplicacin. Existen dos partes dentro del modelo de anlisis, una es denominada Esttica a la cual corresponde el diagrama de clases y la otra es la Dinmica que se representa por medio del diagrama de Colaboracin o, denominado tambin, de Comunicacin. Dentro del Anlisis existen dos entradas fundamentales y son:
201
El Modelo del negocio. Contiene la descripcin de los flujos de informacin del contexto del negocio, para esto, se utiliza los casos de uso del negocio con su respectiva descripcin por medio del diagrama de actividad. El Modelo de Casos de uso. Es una vista externa de la aplicacin, para esto se utilizan los casos de uso de la aplicacin y su descripcin de forma detallada, permitiendo explicar la interaccin del actor con la aplicacin.
Estas entradas son transformadas por medio de un modelo de objeto, ya sea por un diagrama de clases o por un diagrama de comunicacin. La mayor parte de los objetos que se descubren en esta etapa corresponden a los objetos o a los conceptos fsicos en el del mundo real. Una vez que se tiene un modelo de objetos, por medio de una revisin se garantizar que este modelo de la solucin sea el que se busca. Una vez finalizado el anlisis se garantiza que los requisitos de la aplicacin y el contexto de negocio han sido entendidos correctamente. Por medio de una revisin, se debe garantizar este ltimo punto sobre el anlisis. A continuacin se ve un resumen sobre los Casos de Uso y el Anlisis. Modelo de Casos de Uso 1. Lenguaje cliente. 2. Por cada caso de uso se ve una vista externa de la aplicacin. 3. Contrato con el cliente y desarrolladores. Modelo Anlisis 1. Lenguaje desarrollador. 2. Clases y paquetes, vista interna. 3. Para mejor comprensin de los requisitos de la aplicacin hacia los desarrolladores. 4. No debe contener redundancias e inconsistencias entre requisitos. 5. Esboza cmo llevar a cabo esa funcionalidad. Primera aproximacin al diseo. 6. Define realizaciones de casos de uso y cada una de estas representa el anlisis de un caso de uso.
4. Puede contener redundancias inconsistencias entre requisitos.
5. Captura qu funcionalidad debe tener el sistema, incluida la significativa para la arquitectura. 6. Define un caso de uso que se analizar con ms profundidad en el modelo de anlisis.
El primer paso para iniciar el anlisis es la descripcin de los casos de uso en una forma completa (Expandida) utilizando una plantilla para describir cada una de las interacciones entre el actor (usuario) y la aplicacin. De esta forma iniciar la transformacin La plantilla que se utiliza para describir a un caso de uso es la siguiente: 202
Caso de Uso Actores Resumen Responsabilidades CU asociados Precondiciones
Nombre del caso de uso Actores Breve descripcin de lo que hace el CU Responsabilidades del CU. Todo las metas que debe cumplir el caso de uso Nombre de los CU asociados con el tipo de asociacin (include, extend, generalizacin) Lo que se necesita para que se pueda ejecutar el CU. Debe describirse los pasos anteriores que son una condicin para que el caso de uso se ejecute Descripcin Respuesta del Sistema
Accin del Actor(es)
Interfaz (Pantallas enumeradas con sus componentes). Esta interfaz no es ms que un prototipo. Una herramienta de software recomendada para realizar el prototipo de interfaz es Microsoft Visio, el cual permite dibujar con facilidad la posible interfaz. Se realiza el desarrollo del prototipo de interfaz, para que el futuro usuario de la aplicacin entienda la interaccin con la computadora. Otra justificacin es la revisin de la lgica y completitud de la interfaz, que ser realizada por el futuro usuario, el equipo de diseadores y con el especificador de casos de uso, para lograr una completa ergonoma. Otro detalle sobre este punto, es la Facilidad de Uso. Esto quiere decir, que es el momento de iniciar la implementacin del estudio realizado para la facilidad de uso, tratando de lograr un equilibrio entre el uso de la tecnologa y la completitud de las necesidades del usuario. <Descripcin del flujo normal de eventos> Seccin Nombre de la Seccin (en caso de que exista) Interfaz ( Relacionada con la seccin) <Descripcin del flujo normal de eventos de la seccin> Textos Alternos Especificar la lnea en que ocurre, tanto del flujo normal de eventos del caso de uso como de las secciones Requisitos no Funcionales Postcondiciones Especificar su clasificacin
Lo que resulta del caso de uso especificando los posibles estados finales Tabla 1. Plantilla para la descripcin de un Caso de Uso Se ve a continuacin algunos ejemplos de la utilizacin de la plantilla descrita en la Tabla 1.
Ejemplo 1.
Caso de Uso Registrar Trabajo de Impresin 203
Actores Resumen
Usuario (Caja, Encargado) El caso de uso se inicia cuando el usuario debe registrar una trabajo de impresin por solicitud de una persona (Funcionario, Docente o Universitario), el Trabajo de Impresin puede ser de dos tipo en una impresora o en un plotter. Seleccin de una persona Registrar la cantidad de hojas a imprimir Mostrar Deuda de la persona de trabajos anteriores Calcular el costo del trabajo de impresin El usuario debe estar autenticado y autorizado Descripcin Accin del Actor(es) Respuesta de la Aplicacin 2. La aplicacin le proporciona una un interfaz que permite buscar a una persona ya sea por su nombre o por su carnet como se puede ver en la Pantalla 1 (A) (B). 5. Muestra una lista de posibles personas que tengan una similitud con el carnet universitario o con el nombre (D) 7. Activa el Registro de Impresin 8. Muestra la fotografa de la Persona (K) 9. Activa el botn de Datos Adicionales de Persona (J). Ver Seccin Datos Adicionales 13. Proporciona el Monto a Pagar por el trabajo de impresin 15. Proporciona un mensaje de conformidad para el registro de impresin. El mensaje es el siguiente: Se ha registrado un nuevo Trabajo de Impresin
Responsabilidades
CU asociados Precondiciones
1. El caso de uso inicia cuando el Usuario necesita registrar un trabajo de impresin solicitado por una Persona 3. Introduce el Carnet Universitario o parte del Nombre (A) o (B) 4. Realiza un Clic en el Botn Buscar (C) 6. Selecciona a una Persona 10. Debe seleccionar el tipo de impresin que desea la Persona, ya sea en Impresora o en Ploter (E) 11. Debe introducir la cantidad de hojas (F) 12. Debe realizar un clic en el botn Registrar Trabajo (G) 14. Debe realizar un clic en el botn de Pagar para que se registre el pago del trabajo de impresin.
204

Registro de Trabajos de Impresin
Carnet
Escriba texto
Nombre
Escriba texto
Buscar
Personas
Seleccione a una Persona Visualizar (Nombre Completo)
Registro de Impresion Tipo de Impresin

Impresora Ploter
E I
Cantidad de Hojas
D
Datos Adicionales de Persona
Escriba texto
G
Pagar
Registrar Trabajo
Costo a Pagar
Mostrar Texto
Mensajes Notificacion
J
Tipo Persona
Escriba texto
Fotografa
Direccin
Escriba texto
L
Telfono Oficina
Escriba texto
Telfono Domicilio
Escriba texto
Celular
Escriba texto
Correo Electronico
Escriba texto
Carnet Identidad
Escriba texto
Cargo
Escriba texto
Nombre Departamento de Trabajo

Escriba texto
Pantalla 1 Seccin Datos Adicionales 1. El Usuario realiza un Clic en el botn Datos Adicionales de Persona (J) 2. Proporciona los datos adicionales de la Persona (L) Pantalla 1: Tipo Persona (Funcionario, Docente, Universitario), Direccin, Telfono Domicilio, Telfono Oficina, Celular, Correo Electronico, Carnet Identidad, Cargo, Nombre Departamento de Trabajo.
Textos Alternos Paso 5. El sistema muestra un mensaje si no existe una similitud con el carnet o con el nombre de la persona. El mensaje es el siguiente : No existe la persona Paso 12. El sistema muestra un mensaje si la introduccin de la cantidad de hojas son letras, es un nmero negativo o un nmero de tipo real. El mensaje es el siguiente: Existe un error en la Cantidad de Hojas Requisitos no Funcionales Postcondiciones Al momento de cargar la fotografa no debe tardar ms de dos segundos Se registrar un nuevo trabajo de impresin.
Ejemplo 2.
Caso de uso Actualizar cliente 205
Actor(es) Propsito Resumen
Director de Cuenta Mantener actualizados los registros de clientes. El caso de uso se inicia cuando el Director de Cuenta requiere actualizar el registro del cliente existente. De acuerdo a su Requisito agrega, modifica, elimina o imprime la informacin necesaria, graba la informacin y el registro del cliente queda actualizado. Adicionar, modificar, eliminar e imprimir clientes del registro de clientes El Director de Cuenta ha ingresado al sistema y se encuentra en el men principal. Respuesta del Sistema
Responsabilidades Precondiciones
Accin del Actor
Pantalla 1 1. El Director de Cuenta selecciona la opcin Servicios Gerenciales y la subopcin Actualizar Clientes. 3. El Director de Cuenta elige la operacin a realizar. 2. El sistema muestra la Pantalla 1 y presenta la lista de los clientes registrados registrados (A). 4. a. Para agregar un cliente ver seccin Agregar Cliente. b. Para modificar un cliente ver seccin Modificar Cliente. c. Para eliminar un cliente ver seccin Eliminar Cliente. d. Para imprimir un cliente ver seccin Imprimir 206
Cliente. 5. El Director de Cuenta selecciona la opcin Salir (F). Seccin Agregar Clientes 6. El sistema cierra la Pantalla 1 y presenta el men principal.
Pantalla 2 1. El Director de Cuenta selecciona la opcin Agregar (B en Pantalla 1). 2. El sistema genera un nuevo cdigo de cliente y presenta la Pantalla 2 con el cdigo del cliente (G) y genera un formato en blanco con el resto de los datos: RazonSocial(H), Ruc(I), Giro(J), Tipo(K), Direccin(L), Distrito(M), Telfono(N), Fax(O), ContactoNombre (P), ContactoCargo (Q), ContactoArea (R). 5. El sistema valida los datos ingresados y busca si existe un cliente con los mismos datos. 6. El sistema crea un nuevo registro del cliente. 7. El sistema cierra la Pantalla 2 y muestra la Pantalla 1 con la lista de clientes actualizada.
3. El Director de Cuenta ingresa los datos del cliente: RazonSocial(H), Ruc(I), Giro(J), Tipo(K), Direccin(L), Distrito(M), Telfono(N), Fax(O), ContactoNombre (P), ContactoCargo (Q), ContactoArea (R). 4. El Director de Cuenta selecciona la opcin Aceptar (S). Seccin Modificar Clientes
207
1. El Director de Cuenta selecciona el cliente que desea modificar (A en Pantalla 1). 2. El Director de Cuenta selecciona la opcin Modificar (C en Pantalla 1).
3. El sistema muestra la Pantalla 2 con los datos del cliente seleccionado: Cdigo (G), RazonSocial(H), Ruc(I), Giro(J), Tipo(K), Direccin(L), Distrito(M), Telfono(N), Fax(O), ContactoNombre (P), ContactoCargo (Q), ContactoArea (R).
4. El Director de Cuenta modifica los 6. El sistema valida los datos modificados y busca si datos del cliente: RazonSocial(H), existe un cliente con los mismos datos. Ruc(I), Giro(J), Tipo(K), Direccin(L), 7. El Sistema actualiza la informacin del registro Distrito(M), Telfono(N), Fax(O), del cliente seleccionado. ContactoNombre (P), ContactoCargo 8. El sistema cierra la Pantalla 2 y muestra la (Q), ContactoArea (R). Pantalla 1 con la lista de clientes actualizada. 5. El Director de Cuenta selecciona la opcin Aceptar (S). Seccin Eliminar Clientes
Pantalla 3 1. El Director de Cuenta selecciona el cliente que desea eliminar (A en Pantalla 1). 2. El Director de Cuenta selecciona la opcin Eliminar (D en Pantalla 1). 3. El sistema toma el cdigo del cliente seleccionado y verifica que no est asociado a ninguna cuenta. 4. El sistema solicita confirmar la orden de eliminacin mostrando la Pantalla 3.
5. El Director de Cuenta confirma la 6. El sistema elimina el registro del cliente eliminacin del cliente seleccionado. seleccionando la opcin Aceptar (U). 7. El sistema cierra la Pantalla 3 y muestra la Pantalla 1 con la lista de clientes actualizada. Seccin Imprimir Clientes 1. El Director de Cuenta selecciona la 2. El sistema imprime la lista de clientes. De cada opcin de imprimir (E en Pantalla 1). cliente muestra los datos siguientes: Cdigo, Razn Social, RUC, Giro y Tipo. Textos Alternos 1. Seccin Agregar Cliente: Lnea 4. Si el Director de Cuenta selecciona la opcin Cancelar (T en Pantalla 2) el sistema traslada el control a la lnea 7 del flujo bsico de la Seccin Agregar Cliente. 208
2. Seccin Agregar Cliente: Lnea 5.
Pantalla 4 Si el sistema detecta que ya existe un registro con el mismo RUC; presenta la Pantalla 4. El Director de Cuenta selecciona la opcin Aceptar (W). El sistema cierra la Pantalla 4, muestra la Pantalla 2 y traslada el control a la lnea 3 del flujo bsico de la Seccin Agregar Cliente. 3. Seccin Modificar Cliente: Lnea 5. Si el Director de Cuenta selecciona la opcin Cancelar (T en Pantalla 2) el sistema traslada el control a la lnea 8 del flujo bsico de la Seccin Modificar Cliente. 4. Seccin Modificar Cliente: Lnea 6. Si el sistema detecta que ya existe un registro con el mismo RUC; presenta la Pantalla 4. El Director de Cuenta selecciona la opcin Aceptar (W). El sistema cierra la Pantalla 4, muestra la Pantalla 2 y traslada el control a la lnea 4 del flujo bsico de la Seccin Modificar Cliente. 5. Seccin Eliminar Cliente: Lnea 3.
Pantalla 5 Si el sistema detecta que el cliente est asignado a una cuenta presenta la Pantalla 5. El Director de Cuenta selecciona la opcin Aceptar (X). El sistema cierra la Pantalla 5, y traslada el control a la lnea 7 del flujo bsico de la Seccin Eliminar Cliente. 6. Seccin Eliminar Cliente: Lnea 5. Si el Director de Cuenta selecciona la opcin Cancelar (V en Pantalla 3) el sistema traslada el control a la lnea 7 del flujo bsico de la Seccin Eliminar Cliente. Post Condiciones: Los registros de clientes quedan actualizados.
Ejemplo 3. Con casos de uso incluidos (<include>)

Caso de uso
COLOCAR UNA LLAMADA 209
Actores Propsito Resumen
Responsabilidades CU asociados Precondiciones
Persona que desea llamar Garantizar la realizacin de una llamada telefnica. El caso de uso comienza cuando una persona desea realizar una llamada local y levanta el auricular. El sistema capta el nmero del telfono al que la persona desea llamar. El sistema produce la comunicacin. El caso de uso concluye cuando la persona cuelga el auricular y el sistema desconecta las partes. Realizar una llamada telefnica. Administrar circuito virtual (asociacin <<include>>). Descripcin
Acciones del Actor 1. La persona que llama (caller) levanta el auricular. 3. La persona que llama disca un dgito. 5. La persona que llama introduce el resto del nmero.
Respuestas del Sistema 2. El sistema presenta el tono de discar. 4. El sistema quita el tono de discar. 6. El sistema analiza los dgitos, y determina la direccin de la red de la Parte Receptora, es decir determina el nmero del sistema adyacente correspondiente al receptor de la llamada. 7. Incluir el caso de uso Administrar Circuito Virtual para establecer la conectividad con la red. Ejecutarlo para el nmero del sistema adyacente correspondiente al receptor de la llamada y el nmero del sistema desde el cual se hace la llamada. 8. Existe circuito virtual para la comunicacin. 9. El sistema pone al telfono de la Parte Receptora a dar timbre 10. . Etc, etc.
Textos alternos Texto normal, Lnea 8: En caso de que no exista circuito virtual para la comunicacin, el sistema pone al telfono de la persona que llama a dar tono de ocupado. Caso de uso INICIAR SISTEMA Actores Operador Propsito Ejecutar el inicio del funcionamiento del sistema. Resumen El caso de uso comienza cuando el operador decide activar el sistema. El sistema ejecuta todas las comprobaciones previas para evaluar su disponibilidad y finalmente se declara listo para iniciar su funcionamiento. 210
Responsabilidades
Iniciar sistema Casos de uso asociados: CU asociados Administrar circuito virtual (asociacin <<include>>). Precondiciones El sistema se encuentra disponible. Descripcin Acciones del Actor Acciones del Sistema 1. El operador activa el sistema. 2. El sistema ejecuta las pruebas de diagnstico de todos los componentes. Para cada sistema adyacente, ejecutar lneas 3 y 4 del caso de uso. 3. El sistema prueba las conexiones con un sistema adyacente. Incluir caso de uso Administrar Circuito Virtual. 4. Existe circuito virtual para la comunicacin 5. El Sistema responde que est listo para la operacin. 6. Etc. Etc. Textos alternos Texto normal, Lnea 4: En caso de que para al menos un sistema adyacente, no exista circuito virtual para la comunicacin, el sistema responde que no se encuentra listo para la operacin por tener un sistema adyacente sin conexin. Concluye la realizacin del caso de uso.
Ejemplo 4. Generalizacin
Caso de uso Actores Propsito Resumen COLOCAR LLAMADA Persona que llama (caller) Realizar una llamada telefnica. El caso de uso es un caso de uso general, padre de los casos de uso Colocar Llamada Local y Colocar Llamada de Larga Distancia. El proceso de conexin es un proceso especializado que se describe en los respectivos casos de uso hijos. Responsabilidades Realizar llamada telefnica. CU asociados Casos de uso hijos: Colocar llamada local. Colocar llamada de larga distancia. Precondiciones El sistema se encuentra disponible. Descripcin Acciones de los Actores Acciones del Sistema Seccin Proceso Inicial 211
1. La persona que llama (caller) levanta el 2. El sistema presenta el tono de discar. auricular. 3. La persona que llama disca un dgito. 4. El sistema quita el tono de discar. 5. La persona que llama introduce el resto 6. El sistema analiza el nmero. del nmero. Seccin Proceso especializado de conexin Seccin Desconexin 1. Las partes se desconectan. COLOCAR LLAMADA LOCAL Persona que llama (caller) Realizar una llamada telefnica local. El caso de uso comienza cuando una persona desea realizar una llamada local y levanta el auricular. El sistema capta el nmero del telfono al que la persona desea llamar detectando que es una llamada local. El sistema realiza el proceso de conexin especfico para la llamada local, el cual se describe en el presente caso de uso. El caso de uso concluye cuando la persona cuelga el auricular y el sistema desconecta las partes. Responsabilidades Realizar llamada telefnica. CU asociados Caso de uso padre vinculado: Colocar llamada. Precondiciones El sistema se encuentra disponible. Descripcin Acciones de los Actores Acciones del Sistema Seccin Proceso especializado de conexin 1. El sistema encuentra la parte correspondiente. 2. El sistema conecta las partes. Poscondiciones Caso de uso COLOCAR LLAMADA DE LARGA DISTANCIA Actores Persona que llama (caller) Propsito Realizar una llamada telefnica de larga distancia. El caso de uso comienza cuando una persona desea realizar una llamada de larga distancia y levanta el auricular. El sistema capta el nmero del telfono al que la persona desea llamar detectando que es una llamada de larga Resumen distancia. El sistema realiza el proceso de conexin especfico para la llamada de larga distancia, el cual se describe en el presente caso de uso. El caso de uso concluye cuando la persona cuelga el auricular y el sistema 212
Poscondiciones Caso de uso Actores Propsito Resumen
desconecta las partes. Responsabilidades Realizar llamada telefnica. Caso de uso padre vinculado: Cu asociados Colocar llamada. Precondiciones El sistema se encuentra disponible. Descripcin Acciones de los Actores Respuestas del Sistema Seccin Proceso especializado de conexin 1. El sistema enva el nmero a otro sistema. 2. El sistema conecta las lneas. Poscondiciones
Ejemplo 5.
Caso de Uso Actores Propsito Resumen Preinscribir alumno A Usuario(A Secretaria, A Administrador) Tomar datos bsicos del alumno para ingresarlos al sistema Se inicia el caso de uso cuando el usuario ingrese los datos de un estudiante nuevo en el sistema o desea modificarlo. De acuerdo al requisito agrega, elimina o modifica e imprime las notas y los registros quedan actualizados. Actualizar lista de postulantes a un nuevo Postgrado Ninguno El usuario debe estar autentificado con el sistema y se encuentra en el men principal Respuesta del Sistema
Responsabilidades CU asociados Precondiciones Accin del Actor(es)
1. El usuario entra al men gestin y 2. El sistema muestra la pantalla 1 que selecciona la opcin preinscribir alumno. despliega una lista de alumnos preinscritos en la primera maestra que las cuales se encuentran en orden de lista (B). 3. El usuario elige una maestra determinada 5. El sistema despliega la lista de alumnos de (A). la maestra elegida (B). 6. El usuario elige la operacin que desea 7. realizar C. Para agregar un alumno ver seccin Agregar alumno. 213
D. Para modificar un alumno ver seccin Modificar alumno. E. Para eliminar un alumno ver seccin Eliminar alumno. F. Para imprimir la lista de alumnos ver seccin Imprimir alumno 8. El usuario selecciona el botn salir G. 9. El sistema cierra la pantalla 1 y va al men principal.
Pantalla 1 Seccin Agregar alumno 1. El usuario elige la opcin agregar (C) en la pantalla 1.
2. El sistema muestra la pantalla 2, donde se encuentra la maestra que estaba seleccionada en lista de despliegue de la pantalla 1 (A), en el campo Maestra (H), los dems datos se generan en blanco: Carnet de identidad (I), Apellido Paterno (J), Apellido Materno (K), Nombres (L), Profesin (M), Telfono (N), Direccin (O) y Correo electrnico(P). 5. El sistema valida los datos ingresados 6. busca si el alumno con los mismos datos ya existe. 7. El sistema crea un nuevo registro del alumno. 8. El sistema cierra la pantalla 2, y muestra la pantalla 1 con la lista ya actualizada.
3. El usuario ingresa los datos del alumno: Carnet de identidad (I), Apellido Paterno (J), Apellido Materno (K), Nombres (L), Profesin (M), Telfono (N), Direccin (O) y Correo electrnico(P). 4. El usuario elige la opcin Aceptar (Q)
214
H J
I K
L M N Q O P Pantalla 2 Seccin Modificar alumno 1. El usuario elige el alumno que desea modificar en la lista (B) de la pantalla 1. 2. El usuario elige la opcin modificar (D) en la pantalla 1. 3. El sistema muestra la pantalla 2, donde se encuentra la maestra que estaba seleccionada en el combo de la pantalla 1 (B), en el campo Maestra (H), los dems datos se llenan con los datos del alumno: Carnet de identidad (I), Apellido Paterno (J), Apellido Materno (K), Nombres (L), Profesin (M), Telfono (N), Direccin (O) y Correo electrnico(P). R
4. El usuario modifica los campos que desea 6. El sistema valida los datos modificados y actualizar: Carnet de identidad (I), busca si existe un alumno con el mismo Apellido Paterno (J), Apellido Materno carnet de identidad. (K), Nombres (L), Profesin (M), Telfono 7. El sistema actualiza el registro con los (N), Direccin (O) y Correo electrnico(P). nuevos datos del alumno. 5. El usuario elige la opcin Aceptar (Q) de la 8. El sistema cierra la pantalla 2 y muestra la pantalla 2. nueva lista actualizada de en la pantalla 1. Seccin Eliminar alumno 1. El usuario elige el alumno que desea 3. El sistema muestra la orden confirmar eliminar en la lista (B) de la pantalla 1. eliminacin mostrando la pantalla 3. 2. El usuario oprime el opcin Eliminar (E) de la pantalla 1. 4. El usuario confirma la eliminacin del registro del alumno seleccionando Aceptar (S).
5. El sistema cierra la pantalla 3 y muestra la pantalla 1 con la lista ya actualizada.
215
Pantalla 3 Seccin Imprimir alumno 1. El usuario selecciona la opcin imprimir (F) de la pantalla 1. 2. El sistema imprime la lista de alumnos por cada alumno imprime: CI, Nombre completo, Profesin Telfono, Direccin y e-mail.
Textos Alternos 1. Seccin Agregar alumno: Lnea 4 Si el usuario selecciona la opcin cancelar (R en pantalla 2) el flujo el sistema traslada el control a la lnea 8 del flujo bsico de la seccin Agregar alumno. 2. Seccin Agregar alumno: Lnea 5 El sistema detecta que ya existe un alumno con el mismo carnet de identidad el sistema muestra la pantalla 4. El usuario selecciona la opcin Aceptar (U). El sistema cierra la pantalla 4 y traslada el control a la lnea 3 del flujo bsico de la seccin Agregar alumno.
Pantalla 4 3. Seccin Modificar alumno: Lnea 5 Si el usuario seleccin la opcin cancelar (R en pantalla 2) el flujo el sistema traslada el control a la lnea 8 del flujo bsico de la seccin Modificar alumno. 4. Seccin Modificar alumno: Lnea 6 El sistema detecta que ya existe un alumno con el mismo carnet de identidad el sistema muestra la pantalla 4. El usuario selecciona la opcin Aceptar (U). El sistema cierra la pantalla 4 y traslada el control a la lnea 4 del flujo bsico de la seccin Agregar alumno. 216
5. Seccin Eliminar alumno: Lnea 4 Si el usuario elige la opcin Cancelar (T en pantalla 3). El sistema traslada el control a la lnea 5 del flujo bsico de la seccin Eliminar alumno. Requisitos no Funcionales No deben existir abreviaciones en la interfaz. Todos los campos deben estar validados especialmente el del carnet de identidad. En la pantalla 2 en el campo de Maestra (H) el cajn de edicin no debe permitir editar.
Postcondiciones
Los registros de alumnos quedan actualizados.
La descripcin de un caso de uso es extensa y bastante detallada en la explicacin de la interaccin del actor con la aplicacin, lo cual implica un esfuerzo de abstraccin muy grande en la traduccin de las necesidades del actor (usuario) en la interaccin con la computadora. Esta descripcin es muy til, ya que servir para determinar un lenguaje comn entre los involucrados en el desarrollo, adems de ser til para realizar los Casos de Uso de Prueba, realizar el manual de usuario, la ayuda y agilizar el soporte tcnico ya sea para la descripcin de un problema o para identificacin del mismo, dentro del soporte. Un aspecto importante de la plantilla son los Requisitos no Funcionales, los cuales deben describirse en funcin del caso de uso, es decir, qu requisito no funcional necesita el caso de uso? Estos requisitos no funciones darn como resultado a la gran parte de los requisitos no funciones globales de la aplicacin. Recordar que estos requisitos no funcionales son caractersticas (atributos), los cuales se han visto en documentos anteriores, estos hablan de la aplicacin y de algunas de las caractersticas de la informacin que se manipula en el caso de uso. No se debe olvidar que un requisito no funcional es un compromiso, que debe cumplirse. Los ejemplos utilizados en este documento han sido sacados de la materia de Taller III de Sistemas de UNIVALLE-SUCRE y de la Ciudad Universitaria Jos Antonio Echeverra en Cuba. A continuacin se describen dos casos de uso de la aplicacin ejemplo: Caso de Uso Autenticar Empleado Actores Resumen Empleado (Jefe de Cocina, Recepcionista) El caso de uso se inicia cuando el Empleado quiere ingresar a la aplicacin, para esto debe introducir su cuenta y contrasea de acceso a una interfaz que le proporciona la aplicacin. Verificar si el actor tiene autorizacin para ingresar al manejo de la aplicacin.
Descripcin Accin del Actor(es) Respuesta del Sistema 217

Pantalla 1
Autenticar Empleado
Nombre de Cuenta
Escriba texto
A B
Contrasea
Escriba texto (*) Autenticar
Mensajes de Texto sobre la autenticacin
1. El caso de uso se inicia cuando el Empleado necesita ingresar a la aplicacin 2. Presenta una interfaz (Pantalla 1), en la cual debe ingresar el Empleado el Nombre de Cuenta (A) y la Contrasea (B) 3. Ingresa el Nombre de Cuenta (A) y la Contrasea (B) 4. Realiza un clic en el botn Autenticar (C) 5. Valida internamente comparando el Nombre de Cuenta y la Contrasea 6. Direcciona al men principal de la aplicacin para los Empleados Textos Alternos Paso 5. Si la validacin es incorrecta la aplicacin presenta un mensaje de texto (D) con las siguientes palabras El Nombre de Cuenta o la Contrasea es Incorrecta Paso 5. Si la validacin del Nombre de cuenta no coincide con seis caracteres al inicio ms dos nmeros, la aplicacin debe presentar un mensaje de texto con las siguientes palabras Verifique el Nombre de Cuenta (seis caracteres ms dos nmeros) Requisitos no Funcionales Seguridad. El Nombre de Cuenta debe contener un total de 8 caracteres, los seis primeros deben ser letras, los dos ltimos nmeros. La contrasea, luego de realizar un clic en el botn de Autenticar (C) debe aplicarse, sobre esta, un algoritmo de encriptacin, para lograr una ptima integridad Facilidad de Uso Los mensajes relacionados a la utilizacin de la interfaz debe ser legibles, explicativos y de un color llamativo, para lograr un corto tiempo de aprendizaje en la utilizacin de la interfaz y una ptima comprensin. 218
Postcondiciones
El Empleado tendr una autorizacin para la utilizacin de la aplicacin CU Registrar Solicitud de Servicio Bsico Jefe de Cocina El Caso de Uso se inicia cuando el Jefe de Cocina introduce la informacin de la solicitud de Servicio del Cliente que quiere ser atendido. Registrando las bebidas, la comida y el costo del servicio. El costo de servicio puede ser derivado a la cuenta general Registrar una solicitud de Servicio Bsico de un cliente hospedado en el hotel Seleccionar bebidas y comidas respecto a la solicitud de servicio bsico El cliente debe estar registrado en una habitacin. El Jefe de Cocina debe estar autenticado y autorizado. Descripcin Respuesta del Sistema Pantalla 1
Responsabilidades
CU asociados Precondiciones
Accin del Actor(es)

Registrar Servicio Bsico
Buscar Cliente
Introduzca el Numero de Habitacin:
Escriba nmero habitacin
Buscar Cliente
Nombre
Apellido Paterno
Apellido Materno
Numero de Cuenta
Credito
Comidas
Bebidas
Nombre Bebidas: Escriba texto

Nombre Bebida Costo
K
Cantidad
Cuenta a Pagar
Orden de Servicio
Nombre Costo Cantidad
L
Asignar
G
Eliminar
M N
H I
Imprimir Boleta
Mensajes de la interfaz
Costo Total: Escriba texto
1. El caso de uso se inicia cuando el Jefe de Cocina quiere introducir una nueva orden 219
de servicio bsico 2. Le presenta una interfaz para la bsqueda del Cliente (Pantalla 1) 4. Devuelve los datos del Cliente (C), Nombre, Apellido Paterno, Apellido Materno, Nmero de Cuenta, Crdito. 5. Le proporciona una interfaz para introducir las bebidas (ver seccin Bebidas) y la comida (ver seccin Comidas) que ha solicitado el cliente 6. Una vez terminado el ingreso de la solicitud el jefe de cocina imprime la Boleta de Servicio (J) 7. Le informa que la operacin ha tenido con xito con el mensaje siguiente: Se ha registrado correctamente el Servicio. 8. Imprime la Boleta de Servicio con los datos: Nombre del Cliente, Numero de Habitacin, Detalle de Servicio (Nombre, Costo, Cantidad) Seccin Comidas Pantalla 2
Comidas Bebidas
3. Introduce la habitacin (A)
Nombre Comida: Escriba texto

Nombre Comida Costo
D
Cantidad
E
Asignar
F
2. Le muestra una lista de comidas (E) (Pantalla 2) que coincidan con lo introducido en (D) (Pantalla 2), con los datos Nombre Comida, Costo, Cantidad.
1. Introduce el nombre de la comida (D) (Pantalla 2).
3. Selecciona la comida deseada (E) (Pantalla 2) por el Cliente en la orden de 220

servicio realizando un clic en (E) (Pantalla 2) 4. Realiza un clic en el botn Asignar (F) (Pantalla 2). 5. Adiciona a la Orden de Servicio una comida (G) (Pantalla 1) con los datos Nombre, Costo, Cantidad. 6. Calcula el Costo Total del Servicio (I) (Pantalla 1). Seccin Bebidas Pantalla 3
Comidas Bebidas
Nombre Bebidas: Escriba texto

Nombre Bebida Costo
K
Cantidad
L
Asignar
M
2. Le muestra una lista de Bebidas (L) (Pantalla 3) que coincidan con lo introducido en (K) (Pantalla 3), con los datos Nombre Comida, Costo, Cantidad.
1. Introduce el nombre de la Bebida (K) (Pantalla 3).
3. Selecciona la bebida deseada (L) (Pantalla 3) por el Cliente en la orden de servicio realizando un clic en (L) (Pantalla 3) 4. Realiza un clic en el botn Asignar (M) (Pantalla 3). 5. Adiciona a la Orden de Servicio una bebida (G) (Pantalla 1) con los datos Nombre, Costo, Cantidad. 6. Calcula el Costo Total del Servicio (I) (Pantalla 1). Textos Alternos Flujo Bsico. Paso 4. Si la habitacin introducida no coincide con el Cliente la Aplicacin visualiza un mensaje con el siguiente mensaje (N): La habitacin no est asignada a ningn Cliente 221
Seccin Comidas. Paso 2. Si no existe una coincidencia con lo introducido en (D) (Pantalla 2) la aplicacin muestra un mensaje (N): No existe la Comida en bsqueda Seccin Comidas. Paso 4. Si la cantidad de una comida es 0 la aplicacin debe mostrar un mensaje (N): No existe disponibilidad de comida. Seccin Comidas. Paso 6. Si el Costo Total del Servicio (I) es mayor que el Crdito (C), la aplicacin proporciona un mensaje: El Crdito es menor que el Consumo. Adicionalmente se deshabilita el botn Imprimir Boleta (J). El Jefe de Cocina debe eliminar Comidas, realizando un clic en el botn Eliminar (H), hasta que el crdito sea mayor o igual que el Servicio. Seccin Bebidas. Paso 2. Si no existe una coincidencia con lo introducido en (K) (Pantalla 3) la aplicacin muestra un mensaje (N): No existe la Bebida en bsqueda. Seccin Bebidas. Paso 4. Si la cantidad de una bebida es 0 la aplicacin debe mostrar un mensaje (N): No existe disponibilidad de Bebida. Seccin Comidas. Paso 6. Si el Costo Total del Servicio (I) es mayor que el Crdito (C), la aplicacin proporciona un mensaje: El Crdito es menor que el Consumo. Adicionalmente se deshabilita el botn Imprimir Boleta (J). El Jefe de Cocina debe eliminar Bebidas, realizando un clic en el botn Eliminar (H), hasta que el crdito sea mayor o igual que el Servicio. Requisitos no Funcionales Seguridad El Numero de Habitacin debe seguir una mascar que es la siguiente CC-NumHabitacion. Donde CC significa la zona que se ubica la habitacin dentro del Hotel son dos caracteres y NumHabitacin es el nmero de habitacin El Jefe de Cocina registra la Solicitud de Servicio Bsico
Postcondiciones
Estos dos casos de uso servirn para realizar el diagrama de colaboracin y los casos de uso de prueba. Se ha visto de forma completa la descripcin de los casos de uso, adicionalmente se tiene varios ejemplos que ayudarn a realizar el proyecto que lleva a cabo cada alumno. Este documento es uno de los ms importantes dentro del Texto, este lograr documentar la interaccin del usuario y la aplicacin, determinar las perspectivas de la aplicacin ya sea en el diseo como en la implementacin. En siguientes documentos se ver la utilidad de esta descripcin. ERRORES MS COMUNES Representar Casos de Uso como Imprimir Recibo. Este caso de uso pertenece a uno ms amplio Presencia de texto alterno dentro del texto normal Acciones del Actor Respuesta de la Aplicacin
222
1. El usuario suministra su identificacin 3 Actualiza los datos de la nueva factura 5 El usuario concluye la operacin.
2 Localiza la identificacin del usuario. Si no existe el usuario, ejecutar caso de uso Registrar Usuario. 4 Registra los datos de la factura.
Describir de manera insuficiente el caso de uso en aras de ganar tiempo
223
DIAGRAMA DE COLABORACIN O COMUNICACIN Existen dos tipos de diagramas que nos ayudan a determinar los contratos entre objetos, a estos se les llama Diagramas de Interaccin. Uno de estos es el Diagrama de Comunicacin, denominado de esta forma en UML 2. En la anterior versin de UML tiene el nombre de Diagrama de Colaboracin. Otro, que corresponde a los diagramas de interaccin es el Diagrama de Secuencia, este muestra la secuencia y tiempo de los mensajes de los contratos entre objetos. Este ltimo se ver en la parte de diseo, ahora nos dedicaremos a desarrollar los diagramas de colaboracin. Se entiende como Contrato a la relacin de dos objetos, uno que solicita servicio y otro que proporciona. DIAGRAMA DE COLABORACIN O COMUNICACIN Los diagramas de comunicacin agregan una perspectiva que muestra la integracin centrndose en los acoplamientos entre las partes de la aplicacin. Los diagramas de comunicacin son relativamente buenos en demostrar qu acoplamientos son necesarios entre los objetos de la aplicacin. Con una vista rpida a un diagrama de la comunicacin, se puede observar qu partes de la aplicacin necesitan ser conectadas para una interaccin que pueda ocurrir. Los diagramas de la comunicacin proporcionan una manera intuitiva de demostrar los acoplamientos entre las partes que se requieren para los acontecimientos que componen una interaccin. CUANDO USAR EL DIAGRAMA DE COLABORACIN PARA EL MODELO DINMICO? La utilizacin es, muchas veces, una decisin personal o poltica de la empresa. Muchas personas tienden a utilizar los diagramas de secuencia. Los diagramas de secuencia se utilizan cuando se desea acentuar la secuencia de llamadas a eventos y los diagramas de comunicacin se utilizan cuando se desea acentuar los acoplamientos. Muchas personas encuentran que los diagramas de comunicacin son ms fciles de mantener al ocurrir cambios. Otras utilidades del diagrama de colaboracin son: Validar si el diagrama de clases del anlisis esta completo y exacto. El diagrama de clases debe representar parte de la solucin. Ganar la confianza de los usuarios, desarrolladores y cliente. Verificar la funcionalidad de la interfaz que utilizar la aplicacin a desarrollar. La verificacin se debe realizar a varias de las interfaces logrando, de este modo, ver el acceso que se tendr con la aplicacin y sus objetos.
Segn Jacobson, uno de los pasos ms importantes para realizar el anlisis es la determinacin del las Realizaciones de Casos de Uso, estas son una derivacin de los casos de uso que permiten la divisin del caso de uso, esto permite una mejor distribucin y entendimiento de los Diagramas de Comunicacin. Para realizar la determinacin de las realizaciones de los casos de uso de anlisis se deben seguir los siguientes pasos: Tener una realizacin para el flujo bsico de un caso de uso. Tener una realizacin por cada seccin del caso de uso. 224
Realizar un anlisis de los flujos alternos, si es necesario tener una realizacin de un flujo alterno.
Una vez que se ha realizado la determinacin de las realizaciones se debe desarrollar, por cada una de estas, un diagrama de colaboracin, opcionalmente, un diagrama de clases. Para el ejemplo que se lleva a cabo, a continuacin se determinan las realizaciones de los casos de uso que se han descritos de forma completa en el anterior documento. Caso de Uso Autenticar Empleado. Este caso de uso solo tiene un flujo bsico, no tiene secciones y los flujos alternos no necesitan una realizacin, por lo tanto existir una sola realizacin para este caso de uso. Para poder especificar dentro del Rational Rose se deben seguir los siguientes pasos. Como se puede ver en la Pantalla 1, el desarrollo del anlisis tiene que realizarse en la carpeta Logical View.
Pantalla 1. Inicio del Anlisis Dentro de la carpeta Logical View existe otra con el nombre de Analysis Model, esta ltima nos permitir realizar el modelo de Anlisis. Para iniciar se crea por cada caso de uso un directorio que contendr el diagrama de realizaciones de cada caso de uso. En el caso de ejemplo se crea todos los directorios de los casos de uso. Para luego crear el diagrama de realizaciones. Para crear una carpeta se debe realizar un clic derecho sobre la carpeta de Analysis Model, aparecer un men emergente como se puede ver en la Pantalla 2. Se debe seleccionar la opcin New y Package.
225
Pantalla 3. Crear una carpeta Una vez hecha la seleccin se debe dar el nombre a la nueva carpeta, el nombre ser Autenticar Empleado como se puede ver en la Pantalla 4.
Pantalla 4. Carpeta de Autenticar Empleado para la Realizaciones De esta forma se debe crear una carpeta por cada caso de uso que se haya determinado. Como se puede ver en la Pantalla 5.
Pantalla 5. Vista de todas la carpetas para las realizaciones Se tomar como ejemplo dos casos de uso, Autenticar Empleado y Registrar Solicitud de Servicio Bsico. Los cuales permitirn describir la creacin de las realizaciones. A continuacin se crea las realizaciones para estos dos casos de uso. 226
Las realizaciones deben estar en un diagrama de casos de uso, para esto se debe realizar un clic derecho sobre la carpeta de autenticar empleado, seleccionar la opcin New y Use Case Diagram como se puede ver en la Pantalla 6.
Pantalla 6. Diagrama de Casos de Uso para Realizaciones Una vez realizada esta operacin se debe cambiar de nombre a Realizaciones de Autenticar Empleado como se puede ver en la Pantalla 7.
Pantalla 7. Nombre de Realizacin de Casos de Uso De esta forma se est listo para desarrollar las realizaciones de un caso de uso. Se debe realizar doble clic sobre el diagrama de casos de uso, en este caso Realizaciones de Autenticar Empleado, una vez realizada esta operacin en la parte izquierda se visualizar una plantilla, ya conocida, esta servir para colocar el caso de uso al cual se hace referencia con el nombre de la carpeta y crear las realizaciones que se determinen. Para esta operacin se debe arrastrar el caso de uso Autenticar Empleado de la ubicacin de Use Case View, Use-Case Model, Use Case y Autenticar Empleado, hacia el diagrama de casos de uso que corresponde a las realizaciones. Como se puede ver en la Pantalla 8.
227
Pantalla 8. Inicio del Diagrama de Realizaciones Una vez hecha esta operacin se deben crear las realizaciones. Un caso de uso puede tener de una a muchas realizaciones. Para crear se debe realizar un clic en el estereotipo de Casos de Uso en la Barra de Herramientas para luego realizar otro clic en la plantilla donde se ubica el caso de uso. Como se puede ver en la Pantalla 9. Luego, se debe cambiar de nombre a uno apropiado para la realizacin. En el caso de Autenticar Empleado, como solo cuenta con el flujo bsico y flujos alternos que no son complejos (que no llevan a una nueva interfaz), el nombre de la realizacin ser Autenticar.
Pantalla 9. Nombre de la Realizacin 228

Una vez hecha esta actividad lo que resta es cambiar de estereotipo y definir la asociacin de la realizacin hacia el caso de uso. Esta asociacin debe de llevar el nombre de realize, para lograr esta operacin se debe hacer doble clic en la realizacin, se visualizar la Pantalla 10, donde se debe seleccionar en el campo de Stereotype la opcin de use-case realization, posteriormente hacer un clic en botn OK.
Pantalla 10. Seleccin del estereotipo de realizacin Como se puede ver en la Pantalla 11, el estereotipo del caso de uso ha cambiado, este representa a una realizacin. Para realizar la asociacin se debe realizar un clic en el botn Unidirectional Association, y arrastrar desde la realizacin hacia el caso de uso.
Pantalla 11. Definir la asociacin de la realizacin 229

Para terminar, solo se debe cambiar de estereotipo a la asociacin realizando un clic sobre esta, aparecer una pantalla donde se debe seleccionar realice en el Sterotype, como se puede ver en la Pantalla 12.
Pantalla 12. Determinar el estereotipo de la asociacin de Realizacin Con esta ltima operacin se ha terminado con las realizaciones del caso de uso de Autenticar, el resultado se puede ver en la Pantalla 13.
Pantalla 13. Realizacin finalizada del caso de uso Para realizar el caso de uso de Registrar Solicitud de Servicio Bsico se debe seguir los mismos pasos. Sin embargo, este caso de uso presenta varias secciones, las cuales deben tomarse como una realizacin para una mejor comprensin al momento de realizar los diagramas de colaboracin. El resultado del diagrama de realizaciones para este caso de uso se puede observar en la Pantalla 14. 230
Pantalla 14. Realizaciones del caso de uso Registrar Solicitud de Servicio Bsico Como se puede observar en la Pantalla 14 no se toma en cuenta los flujos alternos ya que no sealan a una nueva interfaz o no implica grandes cambios. De esta forma se puede crear las realizaciones de anlisis. En conclusin un caso de uso puede tener de una a muchas realizaciones de anlisis. Luego de determinar todas las realizaciones de anlisis debe llevarse a cabo los diagramas de comunicacin, los cuales sern la transformacin de los casos de uso, que se encuentran en un lenguaje de usuario, hacia un lenguaje de programador y como se ha sealado al inicio del documento estos diagramas ayudarn a refinar los requisitos. Al realizar esta actividad no se debe pensar en una tecnologa ni mucho menos en un lenguaje de programacin o con qu gestor de base de datos se implementar las tablas para la aplicacin. SE ACLARA, NO SE DEBE PENSAR EN UNA TECNOLOGA, ya que esta tarea corresponde al Diseo. Antes de iniciar la creacin del diagrama de colaboracin se necesita estudiar tres estereotipos que ayudan a desarrollar el diagrama. Estos estereotipos mostrarn de una forma muy descriptiva la futura aplicacin. Estos estereotipos no son ms que clases de anlisis. Como se puede ver en la Figura 1, Interfaz, Control y Entidad son los estereotipos que ayudan a determinar el diagrama de comunicacin.
231
Clases de Anlisis
Interfaz
Control
Entidad
Figura 1. Tipos de Clases que participan en el Anlisis Interfaz o Frontera (boundary).
Interfaz
Sirven para modelar la interaccin entre la aplicacin y sus actores, esto pueden ser usuarios, sistemas o aplicaciones externas o dispositivos Representa por lo general abstracciones de ventanas, formularios, paneles, interfaz de comunicacin, sensores, terminales Es suficiente que permita representar la interaccin del actor con la aplicacin como se puede ver en la Figura 2.
<Actor Name>
(f rom Actors)
Interfaz
Figura 2. Representacin de la Interaccin del Actor con la aplicacin Control (control).
Control
Representan Coordinacin, secuencia, transacciones y control de objetos Lgica del Negocio, Clculos Complejos que no se pueden asociar a una informacin concreta 232
Los aspectos dinmicos se modelan a travs de esta clase No modela la interaccin entre el actor y la aplicacin, como se puede ver en la Figura 3.
<Actor Name>
(f rom Actors)
Interfaz
Control
Figura 3. Representacin de la interaccin de la Interfaz con la clase de Control Entidad (entity).
Entidad
Usada para modelar informacin de larga duracin y usualmente persistentes. Modela fenmenos o conceptos, es decir, objetos del mundo real o eventos. Los valores de sus atributos y relaciones son actualizados por un actor con frecuencia por medio de una clase control. Como se puede ver en la Figura 4.
<Actor Name>
(f rom Actors)
Interfaz
Control
Entidad
Figura 4. Representacin de la Interaccin entre Clase de Control y Clase Entidad Para desarrollar un diagrama de comunicacin o colaboracin se debe tomar en cuenta: Las interacciones descritas en el caso de uso. Se debe representar de forma completa la interaccin del usuario con la aplicacin. Si el usuario solicita informacin a la aplicacin debe existir un camino entendible del como la aplicacin le proporcionara la informacin.
233
Una secuencia de los mensajes entre las clases. Esta secuencia debe explicar de forma completa y consecutiva los mensajes que permiten recopilar los datos para ofrecer al usuario la informacin necesaria
Para el desarrollo de un diagrama de comunicacin o colaboracin se deben seguir los siguientes pasos. Se toma como ejemplo el caso de uso de Registrar Solicitud de Servicio Bsico. NO DEBE OLVIDARSE QUE EL DESARROLLO DEL DIAGRAMA SE HACE EN FUNCIN DE LA DESCRIPCIN DEL CASO DE USO. Caso de Uso Registrar Solicitud de Servicio Bsico Flujo Bsico. Se debe realizar un clic derecho en la realizacin de anlisis con el nombre de Flujo Bsico del Servicio Bsico, inmediatamente se visualizar un men emergente como se puede ver en la Pantalla 15, en el cual se debe seleccionar la opcin de New y Collaboration Diagram.
Pantalla 15. Creacin de un Diagrama de Colaboracin Una vez realizada esta actividad se debe dar nombre al diagrama de colaboracin, el nombre puede ser el mismo de la realizacin u otro que represente a toda la realizacin como se puede ver en la Pantalla 16.
234
Pantalla 16. Cambio de Nombre al Diagrama de Colaboracin Una vez hecho el cambio de nombre al diagrama de comunicacin se debe realizar sobre este doble clic, esta operacin visualizar una plantilla a la derecha y una nueva barra de herramientas como se puede ver en la Pantalla 17.
Pantalla 17. Plantilla para realizar el diagrama de colaboracin. Para mantener ordenado el modelo se recomienda crear tres carpetas que puedan almacenar a los tres tipos de clases que participan en el anlisis. Como se pude ver en la Pantalla 18.
235
Pantalla 18. Creacin de carpetas para los tipos de clases Cada una de estas carpetas contendr a un tipo de clase que sea utilizada en un diagrama de colaboracin. Para iniciar con el desarrollo se debe crear una primera Clase Interfaz con el nombre de Registrar Servicio Bsico, la cual representa a la interfaz del caso de uso descrito en el anterior documento. Para crear en el Rational Rose se debe realizar un clic derecho en la carpeta de Clases Interfaz, de inmediato aparecer opciones de la cuales se debe seleccionar New y Class, como se puede ver en la Pantalla 19.
Pantalla 19. Creacin de una Clases Interfaz 236

Una vez realizada esta actividad se debe cambiar de nombre a la clase, en este caso se da el nombre de Registrar Servicio Bsico como se puede ver en la Pantalla 20.
Pantalla 20. Cambio de nombre de la clase de interfaz Como se puede observar, la clase no lleva el estereotipo de Interfaz, para cambiar el estereotipo se debe realizar doble clic sobre la clase, inmediatamente se visualizar una pantalla donde se de seleccionar en el campo con el nombre de Stereotype el bondary como se puede ver en la Pantalla 21.
Pantalla 21. Seleccin del Estereotipo de Interfaz Una vez realizada esta actividad se debe realizar un clic en el botn de OK. Se puede observar en la Pantalla 22 como cambia el estereotipo de la clase.
237
Pantalla 22. Vista del Estereotipo de Interfaz (boundary) Para crear una controladora se debe seguir los mismos pasos excepto la seleccin del estereotipo, para una clase de control se debe seleccionar el estereotipo control como se puede ver en la Pantalla 23.
Pantalla 24. Seleccin del Estereotipo para la clase Control Como se puede observar, luego de realizar un clic en el botn OK, el estereotipo cambia. Para crear una clase con el estereotipo de Entidad se debe seguir los mismos pasos pero seleccionando el estereotipo de entity. En la pantalla 25 se visualiza los tres tipos de clases, los cuales servirn para iniciar el diagrama de colaboracin.
238
Pantalla 25. Tipos de clases de anlisis con estereotipos Para iniciar la creacin del diagrama de colaboracin se deben arrastrar las clases creadas hacia la plantilla del diagrama se colaboracin como se puede ver en la Pantalla 26. Un estereotipo que se debe adicionar al diagrama es el Actor. Esta ltima adicin es para expresar la interaccin del usuario con la aplicacin, esta interaccin debe ser similar a la descrita en el caso de uso. El actor de igual forma debe arrastrarse hacia la plantilla del diagrama. Para el ejemplo ser el Jefe de Cocina.
Pantalla 26. Inicio del Diagrama de Colaboracin. Se aclara que las clases que estn presentes en el diagrama salen de la descripcin del caso de uso, muchas veces con un simple anlisis se puede determinar todas las clases que participan en el caso de uso, sin embargo se recomienda discutir en el grupo de desarrollo cada una de estas. El Jefe de Cocina tiene una relacin con la clase de interfaz, ya que esta le proporcionara las opciones necesarias para realizar su trabajo. Adems, por la descripcin que se tiene del caso de uso Registrar Solicitud de Servicio Bsico debe existir una interfaz. Dentro de la descripcin del caso de uso en las lneas 1 y 2 describe la necesidad de una interfaz.
239
Para determinar la relacin entre un actor y una interfaz se debe realizar un clic en el botn Object Link , ubicado en la barra de herramientas., realizar un clic en el actor y arrastrar hasta la clase de interfaz, el resultado se puede ver en la Pantalla 27.
Pantalla 27. Relacin del Actor con la Interfaz De la misma forma se puede colocar la relacin entre clases, sin embargo debe existir una lgica y adems debe ir de a cuerdo con la descripcin del caso de uso. En la lnea 3 de la descripcin del caso de uso de Registrar Solicitud de Servicio Bsico indica que el Actor introducir el nmero de la habitacin para la bsqueda de un cliente, una vez introducida la aplicacin internamente tiene que realizar una bsqueda para encontrar al cliente. Para expresar dentro del diagrama de colaboracin la interaccion se debe insertar un Link Message , se debe hacer un clic en este botn y otro en la relacin del actor con la interfaz como se puede ver en la Pantalla 28.
Pantalla 28. Link Message para la relacin de actor con interfaz Un Link Message sirve para indicar que existir una peticin, en este caso la peticin del actor hacia la aplicacin por medio de la interfaz. Adicionalmente de introducir este enlace de mensaje se debe colocar un nombre para esto se debe realizar un clic derecho sobre la flecha del mensaje, aparece una ventana emergente de la cual se debe seleccionar <new operation> como se puede ver en la Pantalla 29. 240
Pantalla 29. Adicionar una Operacin Una vez hecha esta actividad aparecer en la parte superior del Link Message, una etiqueta con el nombre de 1:opname(), que representa el nombre de la operacin, como se puede ver en Pantalla 30. Este nombre de operacin debe cambiarse, para el ejemplo tendr el nombre BuscarCliente.
Pantalla 30. Introducir una operacin Para cambiar el nombre de la operacin se debe hacer doble clic sobre la clase interfaz, lo cual har aparecer una nueva ventana como se puede ver en la Pantalla 31.
241
Pantalla 31. Especificador de Objetos Como se puede ver no se encuentra el nombre del mensaje, para poder visualizar todos los mensajes y atributos de una clase se debe realizar un clic en el botn Browse y luego seleccionar la opcin Browse Class, como se puede ver en la Pantalla 32.
Pantalla 32. Visualizar la Clase
242
Una vez seleccionada esta opcin aparecer una nueva ventana con el nombre de Class Specification, la cual contiene todas las caractersticas de una clase, como se puede observar en la Pantalla 33. Para el fin del desarrollo de un diagrama de colaboracin se utilizar la pestaa de Operations.
Pantalla 33. Especificador de Clase Dentro de la pestaa Operations se debe cambiar el nombre de la operacin realizando doble clic retardado en el nombre de la operacin para luego introducir el nombre de BuscarCliente como se puede ver en la Pantalla 34.
Pantalla 34. Cambio de nombre de la operacin 243

Cada operacin debe contener datos de envo y de retorno, en el caso del ejemplo se debe enviar el Nmero de la Habitacin para que le devuelva el nombre del Cliente. Para especificar los datos de envo se debe realizar doble clic en el nombre de la operacin, lo cual llevar a una nueva ventana que se la puede ver en la Pantalla 35. Dentro de esta nueva ventana aparecern varias pestaas, de la cual se debe seleccionar Detail para luego ingresar los datos de envo. Un detalle, muy importante, los datos de envo deben estar expresados en la descripcin del caso de uso , no se debe inventarse u omitir seria un defecto muy costoso.
Pantalla 35. Pestaa para colocar datos de envio Para adicionar un dato de envo se debe realizar un clic derecho sobre el campo de Arguments, de inmediato aparecer un men emergente varias opciones de las cuales se debe seleccionar Insert, esta opcin adicionara un nuevo dato, al cual se debe cambiar de nombre en nuestro caso el nombre ser NumeroHabitacion, adicionalmente se debe definir el tipo de dato, Rational Rose tiene un conjunto de tipos de datos que se pueden seleccionar, sin embargo al criterio que desarrolla la clase puede escribir el tipo de dato que necesite. Toda esta descripcin se puede ver en la Pantalla 36.
244
Pantalla 36. Configurar un Dato de Envo Un detalle, es que cuando se realiza el diseo se debe tomar en cuenta los tipos de datos del lenguaje de programacin para definir los tipo de datos ya sea de los datos de envo o de devolucin, ya que Rational Rose tiene la propiedad de generar cdigo. Para terminar con la configuracin de la operacin se debe seleccionar el tipo de dato que devolver, este punto debe realizarse en la pestaa de Generar como se puede ver en la Pantalla 37, existe el nombre de la operacin (Name), en nuestro caso BuscarCliente, ms abajo est el tipo de dato de retorno (Return Type), de igual forma Rational Rose tiene varios tipos de datos los cuales pueden ser seccionados, pero el desarrollador puede escribir el tipo necesario. Respecto al ejemplo se devolver Object, representando un conjunto de datos, ya que la aplicacin tiene que devolver el conjunto de datos del Cliente. En el diseo se cambiar por DataSet o DTO, estos sern los tipos de datos que devolver la aplicacin.
245
Pantalla 37. Configurar Dato de Retorno Una vez hecha todas estas actividades se debe realizar un clic en el botn de OK hasta ver el diagrama de colaboracin. Como se puede ver en la Pantalla 38.
Pantalla 38. Fin de la Configuracin de una Operacin La operacin se puede entender como un mtodo de una clase, aunque varios autores la denominan Servicio, ya que se considera a una clase como servidora y la otra, que le solicita un servicio, como Cliente. Para continuar con el desarrollo del diagrama de secuencia se realiza asociaciones entre la clase interfaz y controladora, adems entre la controladora y entidad como se puede ver en la Pantalla 39.
246
Pantalla 39. Asociacin entre clases Una vez hecha esta actividad se debe colocar las operaciones como se puede ver en la Pantalla 40. A partir de la Interfaz hacia la controladora se considera operaciones internas de la aplicacin. Un error comn es la aparicin de datos en las operaciones, si aparece un dato debe ser explicado de forma que el diseador de la aplicacin comprenda su origen. En el ejemplo, solo existe un dato de envo que es el NumeroHabitacin. Cada vez que se ingresa un Link Message en el diagrama se ira enumerando incrementalmente. Cada vez que se crea una operacin se ir creando un servicio en la clase que apunta el Link Message.
Pantalla 40. Primeras operaciones de las clases La operacin 3:BuscarCliente(), devolver un dato de tipo Integer, ya que necesitamos un identificador del Cliente para obtener todos sus datos para enviar a la interfaz. Se necesita crear otra clase entidad con el nombre de Cliente, la cual contendr a todos los clientes. Un error comn es colocar el nombre de una clase en plural, no puede colocarse porque en una instancia solo representa a un solo objeto. Como se puede ver en la Pantalla 41, se adiciona la clase Cliente a la cual se le solicita los datos del cliente que est en una habitacin, el nombre de la operacin es ObtenerCliente, esta operacin devolver un tipo de dato Object, el dato de envo ser de tipo Integer que corresponde al identificador del cliente obtenido de la clase Habitacin. 247
Pantalla 41. Adicionar Clase Cliente En la lnea nmero 5 de la descripcin del caso de uso la aplicacin debe mostrar dos interfaz distintas una de estas tiene que permitir registrar a las comidas y la otra debe permitir registrar las bebidas, por esta lnea dentro de la descripcin del caso de uso se debe crear dos clases interfaz, realizar las relaciones y adicionar las operaciones para su visualizacin. El resultado se puede ver en la pantalla 42.
Pantalla 42. Adicin de dos Clases Interfaz En la lnea 6 de la descripcin del caso de uso el Jefe de Cocina imprime la Boleta de Servicio. La Pantalla 43 muestra como tiene que ser la secuencia para recuperar la informacin que generar la Boleta de Servicio.
248
Pantalla 43. Generar Boleta de Servicio Como se puede observar, la secuencia que se describe en el caso de uso debe estar presente en el diagrama de colaboracin especialmente las interacciones que tiene el actor con la aplicacin. De esta misma forma se debe realizar, por lo menos, un diagrama de colaboracin por cada realizacin que se determine por cada caso de uso.
249
DIAGRAMA DE PAQUETES Definicin de paquetes Es un elemento empleado para la estructuracin del modelo en partes pequeas ms fcilmente manejables. Un paquete es un mecanismo de propsito general para organizar elementos en grupos. Constituyen una forma de administrar la complejidad del modelo. Se utilizarn los paquetes para clasificar las realizaciones por cada caso de uso, en si se clasificarn los casos de uso. Un paquete se puede convertir en un Subsistema de la aplicacin dentro del diseo. Antes de realizar el diagrama de paquetes se debe analizar la forma de clasificar a los casos de uso. Se puede realizar la clasificacin por: - Por cada Actor. Es posible desarrollar un subsistema por cada actor, esto implica que ser una aplicacin exclusiva para un actor. - Por funcionalidad. Es posible que varios actores utilicen las mismas funcionalidades de la aplicacin, por este punto de vista se debe analizar cada caso de uso y cada actor. Una tercera opcin para determinar los paquetes es la mezcla de las dos anteriormente descritas, es decir clasificar por actor y por funcionalidad. Dentro del ejemplo de desarrollo utilizaremos la clasificacin tanto por cada actor como por funcionalidad. La creacin de los paquetes es sencilla y se ve a continuacin. En el anterior documento se ha visto la creacin de las realizaciones. Un caso de uso puede tener de una a ms realizaciones. El desarrollo termin en la Pantalla 1.
Pantalla 1. Realizaciones de Casos de Uso del Anlisis 250

Ahora, definiremos los paquetes de la aplicacin que a futuro se pueden convertir en Subsistemas. Para realizar esta actividad, el primer paso es crear un paquete en la carpeta de Analysis Model. Para crear se debe realizar un clic en la carpeta de Analysis Model, seleccionar la opcin de New y Package como se puede ver en la Pantalla 2.
Pantalla 2. Crear un Paquete Esta opcin crear un paquete, al cual tendr el nombre de Seguridad. Si se analiza los casos de uso que darn la seguridad de la aplicacin se puede seleccionar a Autenticar Empleado y Cambiar Contrasea. Estas dos carpetas que representa a los casos de uso se las debe mover al paquete de Seguridad como se puede ver en la Pantalla 3.
Pantalla 3. Determinar los Casos de Uso del Paquete Seguridad
251
Para colocar las carpetas que representan a los casos de uso dentro de un paquete solo se debe arrastrar hasta este. Como se puede ver el paquete Seguridad es una funcionalidad de la aplicacin. Los casos de uso de Gestionar Bebidas, Gestionar Comidas y Gestionar Comidas, son parte de la administracin de la aplicacin, estos son realizados por un actor con el nombre de Administrador, por lo cual, se toma la determinacin de tener un nuevo paquete con el nombre de Administrar. Como se puede ver en la Pantalla 4.
Pantalla 4. Paquete Administrar Se tendr dos paquetes mas, los cuales tendr como nombre Gestionar Hospedaje y Jefe de Cocina. Como se puede ver en la Pantalla 5.
Pantalla 5. Paquetes de la Aplicacin 252

Como se puede ver se a agrupado por funcionalidad y por actores, un paquete que corresponde a un actor es el de Jefe de Cocina. Esta claro que se puede tener otra solucin para la determinacin de los paquetes, esta actividad esta en funcin del anlisis de la persona o grupo que est desarrollando la aplicacin. Una vez que se determinen a todos los paquetes se debe determinar sus relaciones entre cada uno de estos. Esta actividad se la hace dentro de un diagrama de clases. Se realizar un clic derecho e la carpeta de Analysis Model, se selecciona la opcin de New y Class Diagram como se puede ver en la Pantalla 6.
Pantalla 6. Determinar el Diagrama de Paquetes Se debe dar el nombre de Diagrama de Paquetes, para luego realizar doble clic sobre este, lo cual mostrar una plantilla donde se debe colocar todos los paquetes, esto se debe realizar arrastrando a cada uno de los paquetes encontrados hacia la plantilla. El final de esta actividad se puede ver en la Pantalla 7.
Pantalla 7. Paquetes en la Plantilla El ltimo paso que falta es determinar las relaciones entre paquetes. Esto se debe realizar por medio del botn Dependency or Instantiates
ubicado en la barra de herramientas. Para poder relacionar a los 253
paquetes se debe realizar un anlisis de las clases que participan en las realizaciones de los casos de uso, es muy posible que un paquete utilice una clase entidad de otro paquete. Se puede ver el diagrama de paquetes del ejemplo en la Pantalla 8.
Pantalla 8. Diagrama de Paquetes El paquete de Gestionar Hospedaje utilizar el Paquete de Seguridad. El paquete de Seguridad utilizar el de Administrar. El paquete de Jefe de Cocina utilizar el de Seguridad y el de Administrar. Si la aplicacin es grande, se recomienda realizar varios diagramas de paquetes para su mejor comprensin, otro motivo es que existan varios equipos de desarrollo apara realizar un conjunto de paquetes.
254
CAPTULO III
DISEO DE APLICACIONES WEB
Objetivo Profundizar en las tcnicas de diseo de aplicaciones de cualquier tipo (clsicas y Web).
255
DEFINICIN DE LA ARQUITECTURA Se ha pasado toda la fase de anlisis, la cual permite refinar los requisitos y traducir la interaccin del usuario con la aplicacin a un lenguaje del programador. Se seala en documentos anteriores que no es necesario realizar el anlisis, por este motivo la plantilla que nos presenta Rational Rose para el desarrollo de la parte de anlisis no tiene una estructura, sin embargo en el diseo nos presenta una estructura como se puede ver en la Pantalla 1.
Pantalla 1. Estructura del Diseo Cada una de estas carpetas se explicar a medida que se avance en el desarrollo de la aplicacin de ejemplo. El Diseo de una aplicacin es una etapa muy difcil, ya que deben participar distintos especialistas para obtener una solucin que cumpla con los requisitos no funcionales y para que la tecnologa sea utilizada en su totalidad. Recordar que el Anlisis se debe realizar solo cuando sea necesario, como por ejemplo: 1. Para facilitar planificacin de Diseo e implementacin. 2. Para facilitar visin general rigurosa ante recin llegados que deben unirse al desarrollo. 3. Dado que algunas partes de la aplicacin requieren diseo e implementacin alternativos o diferentes (Facilidad de transporte). 4. Cundo ms de una empresa de software vaya a hacer ofertas sobre una misma especificacin. 5. Cuando la aplicacin se construye en base a una aplicacin heredada compleja. 256
La arquitectura es uno de los pasos ms importantes del desarrollo de software, implica estar reunido con varios especialistas para armar el esqueleto de la aplicacin y las bases fundamentales en las cuales se va a desarrollar cumpliendo con los requisitos. Un punto muy importante, es que el desarrollo de la arquitectura es iterativo e incremental, a medida que se realizan los ciclos de desarrollo se va completando y hacindose ms precisa. A continuacin veremos algunas definiciones antes de desarrollar la arquitectura. DEFINICIN DE LA ARQUITECTURA La arquitectura debe mostrar los elementos ms significativos de alto nivel de la aplicacin, es decir, que debe describir de forma completa las caractersticas ms importantes de la aplicacin, ya que servir para distintos participantes, tanto para los usuarios, diseadores, diseadores grficos, analista, contratistas, diseadores de base de datos, administradores de seguridad, administradores de informacin, probadores de aplicacin, entre otros. Por este motivo es uno de los pasos ms importantes para el desarrollo de la aplicacin. La arquitectura se vincula de distintas formas: uso, funcionalidad, desempeo, la facilidad de reutilizacin, la facilidad de comprensin, la esttica en los componentes grficos, restricciones tecnolgicas y econmicas, entre otras. El propsito de la arquitectura se da en varios sentidos: El control intelectual, permite describir el conocimiento necesario para todos los involucrados y sobre todo a las personas que se incluyan en el desarrollo. El administrar la complejidad y mantener la integridad. Las bases de reutilizacin, establece como se puede reutilizar los componentes u otros subsistemas. Las bases de administrar el proyecto, permite establecer cambios en la planificacin tanto para las personas que participan del proyecto como para el tiempo de ejecucin. El manejo adecuado de los riegos al momento de las iteraciones
Una de las decisiones ms importantes que debe tomar un arquitecto de aplicaciones consiste en determinar el lugar donde se implementarn los componentes de la aplicacin. Al igual que sucede en todos los aspectos de la arquitectura de aplicaciones, las decisiones de implementacin fsica implican un equilibrio entre el rendimiento, la reutilizacin y la seguridad, entre otros factores. Las directivas organizativas relativas a la seguridad, las comunicaciones y la administracin operativa tambin afectan a las decisiones de implementacin que se lleven a cabo. Por todos estos puntos introductorios se puede definir la Arquitectura de Software como: Una descripcin simplificada (una abstraccin) de un sistema desde una perspectiva particular o punto de vista superior, cubriendo un asunto particular y omitiendo entidades que no son relevantes a esa perspectiva
257
Una definicin que est ligada a la arquitectura es Diseo arquitectnico, este es el proceso de diseo inicial para identificar los subsistemas y establecer un marco de trabajo para el control y la comunicacin de los subsistemas dando como resultado la Arquitectura de Software.
DEFINICIN DEL PATRN DE LA ARQUITECTURA La definicin del patrn de arquitectura requiere de un anlisis de las diferentes variantes disponibles y de los requisitos no funcionales de la aplicacin. Existen dos variantes generales y son: Cliente Servidor. Se basa en un conjunto de nodos que realizan la funcin clientes y de otros que realizan la funcin de servidores. La lgica del negocio est distribuida entre clientes y el servidor. Los clientes llaman a los servicios. Es un modelo de sistemas distribuido que muestra como los datos y el procesamiento se distribuyen a lo largo de varios procesadores. Esta compuesto por: o Conjunto de Servidores independientes. Ofrecen servicios a otros subsistemas. Servidor de la BD, servidor de las reglas del negocio o Conjunto de clientes. Llaman a los servicios de los servidores. Por lo general son subsistemas. Existen varias ocurrencias de un programa cliente. Concurrencia. o Red de Datos. Permite a los clientes acceder a estos servicios Aplicaciones Web. Las aplicaciones Web se clasifican en: o Cliente Web Delgado: Toda la lgica en el servidor. Cliente con mnima potencia de clculo o no se tiene control de la configuracin. Ejemplo, Aplicaciones de correo electrnico. o Cliente Web Grueso: Significativa cantidad de la lgica del negocio se realiza en el cliente. Apropiada para cuando se puede suponer cierta configuracin en el cliente y versin del navegador. El propsito fundamental es la mejora de la interfaz usuario para ejecutar lgica del negocio en el cliente. Ejemplo. Validacin de Campos de un Formulario utilizando Applet o controles ActiveX para la lgica. o Web Distribuido (Web Delivery): Recibe es nombre porque la Web es usada como un mecanismo de distribucin para un tradicional sistema cliente servidor de objetos distribuidos. Es apropiado si hay un significativo control sobre la configuracin de la red y el cliente o Su mayor fortaleza es la habilidad de utilizar objetos del negocio existentes en el contexto. Adems de HTTP usa otros protocolos como IIOP y DCOM para los objetos distribuidos, adicionalmente SOAP Se entiende como Aplicacin Web como: Software que utiliza protocolos e interfaz web que cambian el estado del negocio. Dentro de la aplicacin de ejemplo utilizaremos un Cliente Web Delgado juntamente con una Web Distribuida. Utilizaremos aplicaciones web que utilizarn Servicios Web. Un trmino que ha aparecido con mayor fuerza desde fines de los aos 90s es la Arquitectura Basada en Servicios, la cual permite el uso de cualquier componente de software externo a la aplicacin que brinde 258
servicios. La tecnologa de los Servicios Web es uno de los ejemplo. Los Servicios desde el punto informticos est compuesto por: Interfaz: A la cual los mensajes inboind son enviados. Fachada que muestra la lgica del negocio implementada en el servicio a los clientes potenciales. Contrato: Conjunto de mensajes que pueden ser intercambiados con un servicio para desarrollar una tarea especfica del negocio. Un Servicio Web no es ms que un componente tradicional que se puede incluir a la aplicacin tomando en cuenta que: Encapsulan sus propios datos. No son parte de la aplicacin. Permite la integracin con otras tecnologas y aplicaciones Existen muchos patrones de arquitectura, ya sea de Microsoft, como de IBM o J2EE, cada una de estas tratan de solucionar un problema especfico dentro del desarrollo de software, adicionalmente debe cumplir los requisitos no funcionales. Veremos de manera general la arquitectura de desarrollo que propone Microsoft, la informacin completa se la puede ver en la siguiente direccin http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/Esp.asp. Cada una de estas arquitecturas est dividida en diferentes capas, que son agrupaciones lgicas de los componentes de software que constituye una aplicacin o negocio Microsoft inicia explicando la arquitectura, definiendo y explicando las capas en las cuales se puede dividir la aplicacin, estas capas sirven para encapsular componentes de acuerdo con el comportamiento que tendrn al momento de la ejecucin de la aplicacin. Esto se puede observar en la Figura 1.
259
Figura 1. Definicin de las tres capas. La Capa de Presentacin define la interfaz y la lgica de la interfaz. La Capa de Negocio (Domain Layer) define la lgica de comportamiento de la aplicacin, esta capa debe contener la lgica del negocio y las tareas, incluyendo a los servicios necesarios para la aplicacin y otras aplicaciones, en esta capa deben definirse a los Servicios Web. La ltima capa, Capa de Acceso a los Datos es la encargada de realizar la logia de acceso a los datos, datos que pueden estar almacenados en una base de datos o archivos XML, esta capa incluye la configuracin del acceso a otros Servicios Web o a otras aplicaciones (Agentes de Servicio). Cada una de las imgenes que se presentan en la Pantalla 2 explican de manera completa las distintas capas en las cuales se debe de dividir la aplicacin, cada una de estas tiene un propsito, uno de estos, que es el ms importante, es el desarrollo en paralelo, ya que cada capa es independiente, lo cual permite dividir el desarrollo de software. Esta arquitectura que define Microsoft ser la que se utilizar para el desarrollo de la aplicacin de ejemplo, se dividir en tres capas las cuales cumplirn con la definicin anteriormente descrita. Para configurar el Rational Rose y poder trabajar con el patrn de arquitectura de tres capas, se debe activar el diagrama con el nombre de Three-Tier Diagram, el cual permitir incluir dentro de la plantilla de modelaje tres carpetas adicionales y un diagrama de clases con una estructura especial que involucra las tres capas. Para activar se debe hacer un clic en la opcin del men principal Tools y Options como se puede ver en la Pantalla 2. 260
Pantalla 2. Configurar Modelo de Tres Capas Una vez hecha esta actividad aparecer una ventana con varias pestaas, de las cuales se debe seleccionar Diagram, se podr visualizar varias configuraciones de los distintos diagramas que se pueden realizar en el Rational Rose. De todas estas opciones se debe activar la opcin de Three-Tier Diagram ubicada en la parte inferior del marco con el nombre de Display, como se puede ver en la Pantalla 3.
Pantalla 3. Seleccionar el Diagrama de Tres Capas Luego, se debe realizar un clic en el botn de aceptar. Para que se active correctamente las tres capas se debe salir del Rational Rose y volver a ingresar, cuando se realice esta actividad el entorno de modelaje variar como se puede ver en la Pantalla 4.
261
Pantalla 4. Entorno de Modelaje para el Patrn de Tres Capas Como se puede ver existe un diagrama que clases que contiene una estructura de tres capas. La primera que aparece es la de User Services, la cual corresponde a la capa de presentacin, la segunda es Business Services, la cual corresponde a la capa del negocio, y por ltimo Data Services que corresponde a la capa de Acceso a los Datos. DEFINICIN DEL MODELO DE LA MINI ARQUITECTURAN O MARCO DE TRABAJO El marco de trabajo define la utilizacin de las tres capas y la divisin de cada una de estas. Cada una de las capas son simplemente agrupaciones lgicas de los componentes de software que conforman a la aplicacin o servicio. Cada una de estas debe ayudar a diferenciar entre los distintos tipos de componentes respecto a las tareas que realizan, esto facilitar al diseo en relacin de la reutilizacin en la solucin. El Marco de Trabajo (Framework) de la aplicacin debe describir a los componentes que se utilizarn para el desarrollo de la aplicacin, de esta forma se tiene un orden para el desarrollo y se incrementa el entendimiento de todos los desarrolladores. Existen distintos tipos de Marcos de trabajo, veremos algunos de estos como ejemplo:
262
Figura 2. Diagrama de tres capas para J2EE El marco de trabajo de la Figura 2 ha sido utilizado para desarrollar una aplicacin con Java.
Figura 3. Diagrama de tres Capas La Figura 3 muestra una estructura completa de la planificacin de un marco de trabajo para J2EE.
263
Figura 4. Marco de Trabajo propuesto por .NET La Figura 4 muestra, de forma completa el marco de trabajo que propone .NET para el desarrollo de aplicaciones. De esta ltima seleccionaremos algunas de las carpetas para del desarrollo de la aplicacin de ejemplo. Cada carpeta tiene un propsito para la aplicacin. Una de las importantes es la de Interfaces de los Servicio, esta carpeta debe contener a las interfaces de los Servicios Web, las cuales deben de interactuar con la Capa de Presentacin. En el primer ejemplo, que se ha desarrollado en el primer captulo, la interfaz del Servicio Web estaba compuesta por un archivo con la extencin .asmx, el cual representa a un Servicio Web en .NET
Figura 5. Marco de Trabajo para un Proyecto de Desarrollo con NET
264
La Figura 5 muestra un nuevo marco de trabajo que ha sido utilizado para realizar una aplicacin de auditora financiera. La aplicacin tena que estar en Web, lo cual debera permitir la comunicacin de los distintos auditores que podan estar en distintas partes de la empresa realizando la auditora, adicionalmente se tena que tener una reutilizacin de cdigo ya que se deba de desarrollar una aplicacin WIN32 para los resultados de la aplicacin y escribir el acta final de la auditora y la importacin de los datos analizados para encontrar evidencias de las transacciones realizadas por los funcionarios de contabilidad y administracin. Para la aplicacin de ejemplo se tendrn: Capa de Presentacin (User Services) WebForm. Contendr las paginas Web con la configuracin bsica de la interfaz. ControlesUsurio. Contendr Controles de Usuario (User Control) los cuales nos ayudarn a capturar los datos en distintos formularios. MasterPage. Contendr a las pginas de configuracin para los WebForm. ControlInterfaz. Contendr a las controladoras de interfaz, las cuales tendrn la responsabilidad de proporcionar los datos y una lgica de estos realizando consultas a Servicios Web. Capa de Negocio (Business Services). ServiciosWeb. Contendr a la interfaz de los distintos Servicios Web de la Aplicacin. Entidades. Contendr a las Clases entidad o persistentes de la aplicacin. Controladoras. Contendr a las controladoras del negocio, las cuales tendr un roles para acceder, filtrar, buscar, entre otros. Reutilizables. Contendr a objetos que pueden ser reutilizados, como por ejemplo los DataSet definidos o el patrn DTO (Data Tranfer Object), los cuales permitirn manipular los datos de manera off line (Fuera de conexin) del Gestor de base de datos. Capa de Acceso a los Datos (Data Services) Agentes de Servicio. Contendr a controladoras que permitan acceder a otros Servicios Web que no pertenecen a la aplicacin en desarrollo pero necesitan datos de estas. Tambin se puede utilizar para realizar la comunicacin entre subsistemas de la aplicacin. SQLHelper. Es una clase ya creada que permite el acceso al gestor de base de datos. Sern componentes fronteras. Para poder documentar en el Rational Rose estas distintas capas determinadas se debe seguir varios pasos que se describen a continuacin. Una vez visualizada la plantilla del Modelo se Servicio de Tres Capas que permite describir a las distintas capas de desarrollo se debe crear carpetas en cada una de estas. Para esto se debe hacer un clic en el botn de Package y luego en la capa donde se incluir la carperta como se puede ver en la Pantalla 5. A la carpeta se le debe cambiar de nombre, en este caso, el nombre ser WebForm.
265
Pantalla 5. Adicin de una carpeta De la misma forma se debe crear cada una de las carpetas que ayudarn a organizar la aplicacin, el resultado final de la creacin de las carpetas (capas) est en la Pantalla 6. El marco de trabajo que se ha definido no es el nico adecuado para la aplicacin de ejemplo, puede incrementarse otras carpetas o tambin eliminarlas. Se quiere explicar que est de acuerdo a los requisitos funcionales y no funcionales, adems de la tecnologa que puede disponer la institucin a la cual se le va a implantar la aplicacin. De todas formas, en el marco de trabajo, propuesto, se cumple con algunas de las recomendaciones de Microsoft.
Pantalla 6. Diagrama de Tres Capas sin relaciones Para finalizar correctamente con el diagrama se debe adicionar las dependencias entre las carpetas. Esto se hace por medio del botn Dependency or Instantiates , se debe realizar un clic en una de las carpetas, arrastrar el mouse hasta la carpeta de la cual depender la primera. De esta forma se finalizar la definicin del Marco de trabajo para la aplicacin. El resultado se puede ver en la Pantalla 7.
266
Pantalla 7. Marco de Trabajo final Las dependencias son muy importantes ya que dan una idea general de cmo se relacionarn los componentes (Clases) dentro de la aplicacin. Como por ejemplo, la carpeta de ControlInterfaz tendr instancias de componentes (Clases) de los ServiciosWeb, de la misma forma para la carpeta de Controladoras, esta tendr la responsabilidad de manipular instancias de varias carpetas como se puede ver en la Pantalla 7. IDENTIFICAR SUBSISTEMAS Se debe entender como Subsistema como una aplicacin cuya operacin no depende de los servicios brindados por otros subsistemas. Los subsistemas se descomponen en opciones y tienen interfaces definidas para la comunicacin con otros subsistemas. Los subsistemas deben ser: Comprensibles. Fcil de entender su semntica, su razn de existencia, responsabilidades, caractersticas, entre otros. Cohesivos. Las clases deben conformar un grupo natural Poco acoplado. Las clases deben estar poco relacionadas con externas Aunque se tiene una vista general de las clases que participarn en la aplicacin se debe discutir la relacin de los subsistemas, no se debe olvidar que la definicin de la arquitectura es iterativa incremental. En esta oportunidad se da pautas generales para iniciar el diseo y la implementacin. Los subsistemas nacen de los paquetes que se han determinado en el Anlisis, se debe tomar en cuenta que los paquetes no son subsistemas, para que logren ser subsistemas debe analizarse su comportamiento y discutir si cumple con la arquitectura, en aplicaciones pequeas es fcil determinar si un paquete ser un subsistema. Para aplicaciones que tienen ms de 10000 lneas de cdigo, lo cual implica una administracin distinta a las pequeas, se hace difcil determinar los subsistemas, por este motivo el equipo de desarrollo debe reunirse a discutir hasta definir los subsistemas. No se debe olvidar que en aplicaciones grandes se desarrolla por ciclo, cada ciclo tiene que ser analizado para determinar los subsistemas, es muy importante que el equipo de desarrollo sea futurista, es decir, que vea un poco los ciclos de desarrollo posteriores para determinar los subsistemas. 267
Para la aplicacin de ejemplo los subsistemas sern los siguientes: Seguridad. Ser un subsistema que permita autenticar y dar autorizacin a los usuarios. Entendiendo Autenticar como: verificar que la persona es quien dice ser y Autorizacin como: verificar que la persona tiene permitido o denegado el acceso a un determinado recursos. Cocina. Ser un subsistema que permitir el registro de los servicios de comida y bebida solicitados por el cliente que se aloja en el hotel. Hospedaje. Ser un subsistema que permita ayudar a registrar y administrar el ingreso de los clientes hacia el hotel. Administracin. Ser un subsistema que permita gestionar las distintas entidades que participan en la aplicacin, adems de permitir definir la autorizacin de las distintas personas que usarn la aplicacin.
Para definir dentro de Rational Rose se debe seguir las siguientes actividades. Se debe realizar un clic en la carpeta de Design Model, las carpetas de Layer ha sido substituida por las capas de User Services, Busness Services y Data Services, por lo tanto se debe eliminar. La carpeta de Use-Case Realitations se debe eliminar para luego crearas en cada carpeta de los subsistemas que se determinen. Para crear a los Subsistemas se debe hacer un clic derecho en la carpeta de Design Model, de inmediato aparecern varias opciones de las cuales se debe seleccionar New y Package, como se puede ver en la Pantalla 8.
Pantalla 8. Crear Carpeta para un Subsistema Esta actividad crear una carpeta, a esta se le debe cambiar de nombre por uno de los subsistemas, en el caso del ejemplo ser Seguridad, como se puede ver en la Pantalla 9.
268
Pantalla 9. Primer paso para crear un Subsistema Una vez creada la carpeta se tiene que definir el estereotipo de Subsistema, para realizar esta tarea se debe realizar doble clic sobre la carpeta de Seguridad, aparecer la Pantalla 10, de la cual se debe seleccionar el estereotipo de Subsystem dentro del campo de Stereotype. Como se puede ver en la Pantalla 10. Esta actividad servir para definir un Subsistema.
Pantalla 10. Definir un Subsistema De esta misma forma se puede adicionar los subsistemas restantes que se han determinado, el resultado de esta actividad se puede ver en la Pantalla 11.
269
Pantalla 11. Definicin de los Subsistemas Cada subsistema puede contener realizaciones de diseo que correspondan a una realizacin de anlisis o, como se ha explicado anteriormente se puede obviar el anlisis y directamente se puede pasar al diseo, por este motivo una carpeta que representa a un subsistema puede contener realizaciones de casos de uso. Adems de las realizaciones, puede contener al Diagrama de Navegacin, Diagrama de Clases Web, a los Diagramas de Interaccin por cada realizacin de diseo, entre otros. No se debe olvidar que un subsistema puede ser una aplicacin independiente. DEFINICIN DE LOS SERVICIOS WEB Es recomendable tener un Servicio Web por cada Subsistema, sin embargo se debe realizar un anlisis antes de definirlos. El anlisis se refiere a ver la re utilidad del cdigo respecto a aplicacin y no repetir el cdigo. Existe un tema que est en consideracin dentro de los investigadores de software respecto a la utilizacin y organizacin del cdigo, el nombre de esta rama que pertenece a la ingeniera de software es Refactorizacin (Refactoring). Para el ejemplo se utilizar un servicio web para cada subsistema. Para documentar esta actividad se debe realizar un clic derecho en la carpeta de ServiciosWeb en la carpeta que pertenece a la capa de Business Services, se debe seleccionar la opcin de New y Class como se puede ver en la Pantalla 12.
270
Pantalla 12. Definir un Servicio Web Se utilizar las letras de SW para representar a un Servicio Web. De esta forma tendremos cuatro clases como se puede ver en la Pantalla 13.
Pantalla 13. Definicin de los Servicios Web Un Servicio Web debe ser considerado como una frontera, es decir, como una interfaz. Entonces, se debe cambiar el estereotipo a boundary. El resultado de este cambio se puede ver en la Pantalla 14.
271
Pantalla 14. Definicin de los Servicios Web terminada DIAGRAMA DE SUBSISTEMAS El diagrama de subsistemas es similar al diagrama de paquetes, pero es importante desarrollar nuevamente ya que pueden existir cambios dentro de los subsistemas, no debe olvidarse que al definir los subsistemas se debe pensar en la tecnologa de software, hardware y el marco de trabajo que se definan. Para definir el diagrama de subsistemas se debe utilizar el diagrama por defecto con el nombre de Architecture Overview - Package and Subsystem Layering como se puede ver en la Pantalla 15.
Pantalla 15. Diagrama para describir las asociaciones de los Subsistemas Para desarrollar el diagrama de subsistemas se debe realizar doble clic sobre Architecture Overview Package and Subsystem Layering, aparecer una plantilla en la cual se debe arrastrar los subsistemas definidos y realizar las asociaciones. El resultado de esta actividad se puede ver en la Pantalla 16.
272
Pantalla 16. Diagrama de Subsistemas DEFINICIN DE LAS CLASES MS SIGNIFICATIVAS Para terminar con la definicin de la arquitectura de software se debe determinar las clases persistentes ms significativas para la aplicacin. Se debe entender como Clase Persistente a una clase que perdure en el tiempo a pesar de la eliminacin de la aplicacin. Generalmente, se compara con una tabla que pertenezca a una base de datos. La definicin de estas clases se ir perfeccionando a medida se vayan completando los ciclos de desarrollo, no olvidar que la definicin de la arquitectura se ira completando a medida que el desarrollo de la aplicacin se termine. Para describir a las clases ms significativas se debe utilizar el diagrama de clases con el nombre de Architecturally Significant Model Element. Por qu colocar en estos lugares?, Rational tiene otra aplicacin que ayuda a elaborar la documentacin denominada Rational SODA. En la Pantalla 17 se puede observar el diagrama.
Pantalla 17. Diagrama de Clases para los elementos ms significativos Se debe realizar doble clic a este diagrama, lo cual mostrar una plantilla para describir el diagrama de clases. Las clases que se determinen debes de estar ubicadas en la carpeta de Business Services y Entidades, ya que cada una de estas ser una entidad dentro de la aplicacin, como se puede ver en la 273
Pantalla 18. Una vez creadas las clases se las debe arrastrar al diagrama de Architecturally Significant Model Element.
Pantalla 18. Crear una clase Entidad Se crearn las siguientes entidades para el ejemplo: Habitacin. Esta entidad representa a un cuarto disponible para el Cliente. Reservacin. Esta entidad representa a la contratacin sin confirmacin de un cliente con el hotel. Cliente. Esta entidad representa a la persona que est interesada en hospedaje dentro del hotel. Bebida. Esta entidad significa las posibles bebidas que puede solicitar el cliente. Comida. Esta entidad significa las posibles comidas que pude solicitar el cliente. Recepcionista. Esta entidad significa una posible persona que atienda la confirmacin de una habitacin o la salida del hotel del cliente OrdenServicio. Esta entidad significa el registro de una orden de servicio ya sea a la habitacin como un servicio bsico. Se debe tratar que no existan caracteres especiales o poco comunes dentro de los lenguajes de desarrollo. Como por ejemplo las vocales con acento. Una ayuda para encontrar estas entidades es el diagrama de colaboracin que se ha desarrollado en la etapa de anlisis, si es que no se ha desarrollado el anlisis de debe descubrir las clases con la ayuda de la descripcin de los casos de uso. En la Pantalla 19 se puede ver a las clases mencionadas en la carpeta que representa la capa del negocio.
274
Pantalla 19. Entidades (Clases) para la arquitectura Una vez creadas se debe arrastrar cada una de estas hacia el diagrama de elementos ms significativos. Como se puede ver en la Pantalla 20.
Pantalla 20. Diagrama de elementos significativos sin asociacin No se debe colocar en esta etapa los posibles atributos que pude tener una clase, ya que no se conoce correctamente a estos. Solo se debe colocar el tipo de asociacin que tienen entre cada una. Una vez realizada esta actividad se debe colocar las asociaciones de forma bsica con la ayuda del botn Unidirectional Association . Se debe realizar un clic sobre el botn sobre una de las Entidades (Clases) y luego arrastrar hacia otra Entidad. El resultado de esta actividad se la puede ver en la Pantalla 21.
275
Pantalla 21. Diagrama de Elementos Significativos con asociacin Como se puede observar, dentro del diagrama, existe una navegabilidad la cual se la debe eliminar. Para eliminar la navegabilidad se debe realizar un clic derecho sobre la direccin de la asociacin como se puede ver en la Pantalla 22. Al realizar esta actividad se visualizar una ventana con varias opciones de las cuales se debe seleccionar Navigable, esta opcin permite determinar si existe una navegabilidad entre las clases, esta se debe utilizar cuando sea necesario, es decir, cuando no es clara la asociacin.
Pantalla 22. Determinando la navegabilidad entre clases De esta forma se debe eliminar la navegabilidad entre las otras clases. El resultado de esta actividad se puede ver en la Pantalla 23.
276
Pantalla 23. Asociaciones entre clases La asociacin entre clases tiene muchas caractersticas, estas se las ver de forma completa en otro documento, sin embargo, se tomar en cuenta la multiplicidad. Para realizar esta actividad se debe tomar en cuenta los dos extremos de la lnea de asociacin, tomaremos de ejemplo las clases de Recepcionista y Reservacin. Se debe realizar un clic derecho en la asociacin en la parte izquierda, de inmediato aparecer una ventana con varias opciones de las cuales se debe seleccionar Multiplicity, por anlisis se debe seleccionar entre las opciones que aparecen en la Pantalla 24.
Pantalla 24. Determinando la multiplicidad en la parte izquierda de la asociacin En el caso del ejemplo un Recepcionista registra de una a muchas reservaciones. Para determinar la otra relacin de una muchas se debe realizar clic derecho en la parte derecha de la relacin como se puede ver en la Pantalla 25. 277
Pantalla 25. Determinando la multiplicidad en la parte derecha de la asociacin De esta forma se debe realizar para las otras asociaciones. El resultado se puede observar en la Pantalla 26.
Pantalla 26. Diagrama de elementos ms significativos De esta forma se ha desarrollo la arquitectura de la aplicacin. Como sea dicho anteriormente para la determinacin de la arquitectura debe participar personas con conocimiento especfico. No se debe olvidar que se realiza un ejemplo para una aplicacin pequea.
278
MAPA DE NAVEGACIN En este documento se inicia el Diseo de la aplicacin construyendo el Mapa de Navegacin, el cual permitir describir de forma general la navegacin de la aplicacin web se va a desarrollar. Antes de iniciar se ver algunos de los estereotipos que permiten describir una aplicacin web. Se debe diferenciar un Sitio Web de una Aplicacin Web. El primero solo publica informacin, el cual no cambia su estructura ni su contenido. Una Aplicacin Web es capaz de cambiar el estado de una organizacin o negocio, slo se instala en un servidor para que el usuario obtenga toda la potencialidad de la aplicacin, se necesita de http para la comunicacin, este protocolo es robusto y tolerante a fallos. Tambin, el servidor de la aplicacin gira alrededor de pginas web, las cuales tienen incluidas el flujo de trabajo de la organizacin o el negocio resolviendo peticiones del los usuarios. Cada pgina web se considera como un objeto, es decir, que se al momento de implementar ser una clase. El cambio de la tecnologa y la poltica de Acercamiento al Cliente que disponen las organizaciones han sido las que han permitido el surgimiento de las Aplicaciones Web, entre las ventajas de este nuevo paradigma estn: No se instala en el Cliente. Solo se necesita un servidor que aloje a todas las pginas web que conforman a la aplicacin para que el usuario pueda realizar su trabajo. Acceso Universal. No es necesario tomar en cuenta la plataforma que tiene el usuario respecto al sistema operativo que utilice, solo es necesario que exista en la maquina del usuario un Navegador de Internet (Browser) que permita interpretar HTML. Existencia de muchas plataformas para el desarrollo. Las empresas que se han dedicado a desarrollar software, por le general han logrado ofrecer una plataforma para el desarrollo de las aplicacin es web, entre algunas de estas se encuentran Microsoft con Fontpage y el Visual Studio que utilizan ASP y ASP.NET. Otra de las empresas es IBM con su tecnologa de WebSphear, la cual nos permite desarrollar aplicaciones web con la tecnologa JSP.
Las aplicaciones web deben lograr capturar la lgica del negocio que garantice su cambio de estado, para esto los investigadores han presentado muchas sugerencias para el desarrollo de la interfaz y de su estructura interna para hacerlas ms tiles y eficaces, una de las recomendaciones es que se debe tomar ms importancia a la lgica del negocio que a los aspecto de presentacin, en otras palabras, debe ser prioritaria la funcionalidad de la aplicacin web y que el diseo de la interfaz no sea complejo. Por este motivo, la lgica y la interfaz deben llevarse por separado. Una pgina web puede contener script que se ejecutan en el servidor y/o script que se ejecutan en el cliente, dentro de la modelacin se debe diferenciar cada uno de estos. Para modelar las aplicaciones web se deben tomar en cuenta las siguientes caractersticas de las pginas: Los enlaces de unas a otras Todo el contenido dinmico asociado a cada solicitud hacia el servidor. Todo el contenido dinmico asociado a las pginas del cliente. 279
Entre la modelacin orientada a objetos y el desarrollo de la aplicacin es Web se toman las siguientes equivalencias: Cada Pgina ser representada por medio de una Clase. Los link entre pginas sern representados por medio de asociaciones entre clases. Los script de las pginas sern representados por medio de las responsabilidades de las clases (mtodos). Las variables en el script sern los atributos de las clases.
Estas cuatro equivalencias servirn para interpretar y abstraer la aplicacin hacia el paradigma orientado a objetos. Se debe sealar que las nuevas plataformas de desarrollo han separado en gran medida estas equivalencias, esta separacin se pondr en prctica de forma fsica en el captulo de implementacin. Dentro de la modelacin del negocio se han creado estereotipos que permitan representar y desarrollar una aplicacin web, entre estos tenemos los siguientes:
NewClass
Client Page (Pagina Cliente). 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 pginas cliente pueden tener asociaciones con otras pginas cliente o servidor. Representar a una pgina Web como .ASPX, .JSP, .ASP, .PHP
(f rom WebForm)
NewClass
HTML Form (Formulario HTML). Una clase estereotipada como HTML 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 esta clase representan los campos de entrada del formulario HTML (input boxes, text areas, radio buttons, check boxes, y campos hidden). Un HTML 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.
(f rom WebForm)
NewClass
Server Page (Pgina Servidora). Una pgina de servidora representa una pgina web que tiene scripts que son ejecutados por el servidor. Estos scritps interactan con recursoss del servidor como bases de datos, lgica de negocio y sistemas externos. Las operaciones del objeto 280
(f rom WebForm)
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). Entre estos estereotipos existirn tipos de asociaciones que se describen a continuacin: link. 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 directamente con la etiqueta HTML ancla. built. 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. submit. 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. redirect. 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 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 HTTP-EQUIV el valor de "Refresh". include. Indica que la pgina en el servidor incluye un objeto al construir la pgina en el cliente. Object. Representa a una asociacin de composicin entre una pgina en el cliente a una clase lgica que representa un componente embebido, que puede ser un ActiveX, un Applet u otro componente.
Con los conceptos anteriormente descritos se puede desarrollar el diagrama de navegacin. Para este propsito utilizaremos el Rational Rose. El Diagrama de Mapa de Navegacin representa una idea general de la navegacin entre pginas de la aplicacin web. Este Mapa de Navegacin se debe crear por subsistema o bien, si es que es pequea la aplicacin, un solo Mapa de Navegacin. Este mapa es de gran ayuda para identificar con mucha rapidez la ubicacin de las opciones dentro del sistema y de las caractersticas de cada subsistema.
281
El primer Mapa de Navegacin que se desarrolla para ejemplificar es el de Seguridad. Para esto se debe realizar un clic derecho sobre la carpeta que representa al subsistema de Seguridad, de inmediato aparecer una ventana con varias opciones de las cuales se debe seleccionar New y Class Diagram, como se puede ver en la Pantalla 1, lo cual permitir crear un diagrama de clases que servir para alojar al Mapa de Navegacin.
Pantalla 1. Crear el Mapa de Navegacin Una vez hecha esta operacin se debe crear clases que formaran parte del Mapa de Navegacin. No se debe olvidar que se ha determinado una arquitectura, la cual se debe obedecer para el entendimiento del desarrollo. Las clases que se crearan deben estar en la carpeta de User Services, ya que corresponden a la capa de presentacin. Adicionalmente, las clases deben llevar el estereotipo de Client Page, descrito anteriormente. Para crear una clase se debe realizar un clic en la carpeta que representa a la capa de presentacin que es User Services, luego, un clic derecho en la carpeta de WebForm, inmediatamente se visualizar una ventana con opciones de las cuales se debe seleccionar New y Class, esta opcin crear una clase, el nombre de esta ser PInicio, donde la letra P significar Pgina e Inicio el nombre de la Clase, como se puede ver en la Pantalla 2.
282
Pantalla 2. Crear una clase que representa a un WebForm Una vez creada la clase se debe cambiar el estereotipo a Client Page, para esto se debe realizar clic derecho y seleccionar Open Standard Specification, como se puede ver en la Pantalla 3.
Pantalla 3. Especificaciones de la Clase Al realizar clic se visualizar una ventana con varias opciones, de las cuales se debe seleccionar la opcin General, luego se debe escribir o seleccionar el nombre del estereotipo que es Client Page como se pude ver en la Pantalla 4. Una vez hecha esta actividad se debe realizar un clic en el botn OK para completar con la definicin de tipo de clase para la aplicacin.
283
Pantalla 4. Definiendo el estereotipo de Pgina Cliente Esta creacin de clases est en funcin de los diagramas de colaboracin que se ha desarrollado en la parte de anlisis, si no se ha realizado los diagramas de colaboracin del anlisis se aconseja realizar primero los diagramas de secuencia por cada realizacin de diseo, para tener una idea general de las pginas (Clases Client Page) bsicas para la aplicacin. Esta primera clase, que se ha creado, es la pgina inicio de la aplicacin de ejemplo, ahora crearemos un mapa de navegacin sencillo para el subsistema de Seguridad, las clases Client Page sern las siguientes: - PAutenticar. Pgina Web que permitir autenticar al usuario. - PCambiarContrasena. Pgina Web que permitir cambiar contrasea de los usuarios. El resultado de esta actividad se puede ver en la Pantalla 5.
Pantalla 5. Creacin de las Client Page de Subsistema Seguridad
284
Luego de crear a las clases se debe crear un diagrama de clases dentro del subsistema de Seguridad. Para realizar esta actividad se debe realizar un clic derecho en la carpeta que representa a al subsistema de Seguridad como se pude ver en la Pantalla 6.
Pantalla 6. Crear un diagrama de Clases para el Mapa de Navegacin de Seguridad El nombre del nuevo diagrama de clases ser Mapa de Navegacin de Seguridad. Una vez introducido el nombre se debe realizar doble clic a este para poder acceder a la plantilla que permitir describir la asociacin entre las clase anteriormente descritas. Para realizar esta actividad, una vez visualizada la plantilla se debe arrastrar cada una de las clases Client Page, el resultado se puede ver en la Pantalla 7.
285
Pantalla 7. Creacin del Mapa de Navegacin de Seguridad sin Asociaciones Para terminar con mapa de navegacin se debe determinar las asociaciones entre cada una de estas. Para esto realizar se debe utilizar el botn de Uniderectional Association , el cual permitir definir la asociacin. Para el ejemplo tendremos las siguientes asociaciones entre las clases: - PInicio con PAutenticar. Asociacin de tipo Link. - PAutenticar con PCambiarContrasena. Asociacin e tipo Link El resultado de esta definicin determinar el tipo de Asociacin se puede ver en la Pantalla 8.
286
Pantalla 8. Mapa de Navegacin de Seguridad sin el tipo de asociacin. Para determinar el tipo de asociacin, que debe ser Link, se debe realizar un clic derecho sobre la flecha que determina la asociacin, inmediatamente se visualizar una ventana con varias opciones como se puede ver en la Pantalla 9.
Pantalla 9. Opciones para determinar el tipo de relacin en un mapa de navegacin
287
Se debe seleccionar la opcin de Open Standard Specification, la cual permitir visualizar una ventana la cual se puede ver en la Pantalla 10. Dentro de esta ventana se de seleccionar en el campo de Stereotype el Link.
Pantalla 10. Seleccin del tipo de Relacin para la asociacin dentro del mapa de navegacin Para finalizar con la determinacin del tipo de asociacin entre clases Client Page se debe realizar un clic en el botn OK. De la misma formase debe determinar el tipo de relacin para la asociacin entre PAutenticar y PCambiarContrasena. El resultado de esta actividad se puede ver en la Pantalla 11.
288
Pantalla 11. Mapa de Navegacin de Seguridad El diagrama describe que existir un enlace para ir desde PIncio a PAutenticar, esa ltima permitir autenticar y determinar las autorizaciones que tiene el usuario respecto a su cuenta y contrasea. Una vez autenticado tendr la autorizacin para cambiar su contrasea para esto podr acceder a una nueva interfaz con el nombre de PCambiarContrasena. De esta misma forma se puede realizar para los dems subsistemas, no se debe olvidar que est en funcin de los diagramas de colaboracin que se han desarrollado en la fase anlisis, si no se ha realizado estar en funcin de los diagramas de secuencia de diseo por cada realizacin de diseo. Ahora se muestra una propuesta de navegacin para los otros subsistemas. Todas las clases deben ser creadas en la carpeta de WebForm dentro de la capa de User Services. La Pantalla 12, muestra el mapa de navegacin para el subsistema de Administracin.
289
Pantalla 12. Mapa de Navegacin de Administracin La Pantalla 13, muestra el mapa de navegacin para el subsistema de Cocina.
Pantalla 13. Mapa de Navegacin de Cocina La Pantalla 14, muestra el mapa de navegacin para el subsistema de Hospedaje.
290
Pantalla 14. Mapa de Navegacin de Hospedaje Para finalizar con el ejemplo se realiza un mapa de navegacin de forma general que se puede ver en la Pantalla 15. Este mapa no es necesario para aplicaciones relativamente grandes ya que ser su visualizacin muy compleja.
291
Pantalla 15. Mapa de Navegacin General de la Aplicacin. De esta forma se ha terminado de desarrollar el Mapa de Navegacin. Mencionar que es muy importante desarrollar antes el diagrama de colaboracin o el diagrama de secuencia para determinar las clases Client Page. Estas clases servirn para iniciar el Diagrama de Clases Web, como se podr estudiar en el prximo documento.
292
DIAGRAMA DE CLASES WEB Hasta ahora se ha utilizado un solo estereotipo para la modelacin de aplicaciones Web, en este documento veremos los restantes, es decir: HTML Form y el Server Page, cada uno de estos tendr una funcin especfica dentro de la aplicacin en desarrollo. El Diagrama de Clases Web no es ms que una representacin de clases y asociaciones. Los tipos de clases que se utilicen describirn la relacin que tendrn al momento de la ejecucin de la aplicacin y como ser su comunicacin entre estas. Para determinar del diagrama de clases web se debe utilizar los diagramas de colaboracin que se han desarrollado en la fase de anlisis, si no se ha desarrollado los diagramas de colaboracin es necesario desarrollar los diagramas de secuencia de diseo respecto a las realizaciones de diseo. Una Realizacin de Diseo tiene el mismo concepto que una realizacin de anlisis, sin embargo se tiene que aclarar dos puntos importantes: Una Realizacin de Anlisis puede tener de una a muchas Realizaciones de Diseo. Por lo general, por cada realizacin de anlisis existir una realizacin de Diseo Una Realizacin de Diseo debe estar descrita con un Diagrama de Clases Web, Diagrama de Secuencia y (opcional) un diagrama de clases persistente. La creacin de estas realizaciones se debe realizar en un subsistema.
No debe olvidarse que el ejemplo que se desarrolla pertenece a un producto pequeo, cuando se presenta un desarrollo de ms de 25 casos de uso se debe estudiar las realizaciones de forma que exista una divisin correcta para la descripcin, el entendimiento de los desarrolladores y de los involucrados. Es muy posible que al momento de traducir los requisitos de un lenguaje de usuario a un lenguaje de programador, utilizando el marco de trabajo y los aspectos de una arquitectura de desarrollo, aparezcan realizaciones de diseo que permitan un ptimo entendimiento de la aplicacin a implementar. Se debe recordar que la fase de diseo es como para el arquitecto el plano para construir una casa. El primer paso para iniciar la creacin de las realizaciones de diseo es crear una carpeta, para continuar con el ejemplo, crearemos una carpeta con el nombre de Realizaciones de Seguridad dentro del subsistema de Seguridad. Para realizar es operacin se debe realizar un clic derecho sobre la carpeta del subsistema de Seguridad, inmediatamente se visualizar carias opciones, como se puede ver en la Pantalla 1, de las cuales se debe seleccionar las opciones de New y Packege
293
Pantalla 1. Crear una carpeta para Realizaciones Una vez introducido el nombre a la carpeta se debe crear carpetas que correspondan a cada una de las realizaciones de anlisis. El ejemplo que se desarrolla obliga a crear carpetas por cada realizacin de anlisis, sin embargo si no se realiza el anlisis se debe crear carpetas por cada caso de uso. Todos estos pasos recomienda realizar Rational Unified Process, desarrollar cada uno de estos pasos garantiza un completo orden y, sobre todo, el entendimiento rpido de cualquier persona que se incluya al desarrollo o para realizar el mantenimiento de la aplicacin. Se puede encontrar ms ventajas al aplicar esta estructura y estos pasos ya que son descritos dentro de una de las mejores prcticas internacionales de desarrollo. Como se puede ver en la Pantalla 2, se ha creado una carpeta que representa a la realizacin de diseo para el caso de uso de Autenticar Empleado
294
Pantalla 2. Carpeta para una realizacin de diseo Dentro de esta carpeta se debe crear carpetas por cada realizacin de anlisis o por cada caso de uso, esto est en funcin a la realizacin del anlisis. Se crear una carpeta con el nombre de Autenticar que representar a la realizacin de anlisis de Autenticar. Para realizar esta actividad se debe realizar las mismas operaciones para crear un nueva carpeta. El resultado de esta operacin se puede ver en la Pantalla 3.
Pantalla 3. Crear la capeta para la realizacion de diseo de autenticar Debemos aclarar, esta operacin se la realiza por varios motivos, el principal es que puede la realizacin de anlisis dividirse en varias realizaciones de diseo, esto est en funcin del marco de trabajo, del refinamiento del anlisis, la tecnologa de hardware, la plataforma de desarrollo, entre otras. Es muy posible que se encuentre varias interacciones del usuario, un ejemplo clsico para explicar esta situacin de las realizaciones de diseo es la creacin de una cuenta de correo electrnico, dentro del anlisis solo se describir la introduccin de los datos del solicitante a un correo electrnico, sin embargo dentro del diseo se describirn pasos para registrar al solicitante. Usted se ha registrado algunas vez a un correo electrnico y se da cuenta que ha estado en varias interfaces que han registrado su solicitud de correo electrnico, cada una de estas interfaces se las puede tomar como una realizacin de diseo dentro de la 295
descripcin de la aplicacin. Por este motivo se debe separar el software. No olvidar que el diseo es el refinamiento del anlisis para prepararse para la implementacin. Para describir las realizaciones de diseo en funcin de las realizaciones de anlisis se debe realizar un diagrama de casos de uso, como se ha hecho para las realizaciones de anlisis. Se debe realizar un clic derecho en la carpeta de Autenticar y seleccionar las opciones de New y Use Case Diagram, el nombre para este diagrama de casos de uso ser Realizaciones de Diseo Autenticar. El resultado de esta operacin se puede ver en la Pantalla 4.
Pantalla 4. Creacin de un diagrama de casos de uso para las realizaciones de diseo Una vez creado el diagrama de casos de uso se debe realizar doble clic sobre, inmediatamente se visualizar una plantilla al lado derecho, esta plantilla como en la creacin de las realizaciones de anlisis nos permitir describir la s realizaciones de diseo. Primero se debe arrastrar la realizacin de Anlisis con el nombre de Autenticar, como se puede ver en la Pantalla 5.
296
Pantalla 5. Definir las realizaciones de diseo de una realizacin de anlisis Una vez realizada esta operacin se debe determinar las realizaciones de diseo para la realizacin de anlisis, para esto se debe realizar un clic en el botn de Use Case y otro el diagrama de casos de uso de la Realizacin de Diseo Autenticar, esta operacin permitir crear un caso de uso al cual se debe dar un estereotipo de realization, determinar la asociacin con la otra realizacin en el caso del ejemplo y un mombre el cual ser RD Autenticar, RD significa realizacin de diseo. No olvidar que la realizacin debe llevar el estereotipo de realice. Para realizar estas operaciones se debe realizar derecho en el caso de uso, seleccionar la opcin de Open Specification, como se puede ver en la Pantalla 6.
Pantalla 6. Definir el estereotipo de realizacin
297
De inmediato se visualizar una ventana con varias opciones de las cual se debe seleccionar General, Stereotype y seleccionar use-case realization, como se puede ver en Pantalla 7.
Pantalla 7. Definir el estereotipo de realizacin Una vez determinado el estereotipo se debe realizar un clic en el botn OK para definir en el diagrama el estereotipo de realizacin. Luego, se debe realizar un clic en el botn de Unidirectional Association , para determinar la asociacin entre la realizacin de anlisis y la realizacin de diseo, esta se realiza haciendo un clic en la realizacin de diseo y arrastrar hasta a la realizacin de anlisis, el resultado se puede ver en la Pantalla 8.
Patalla 8. Determinar la asocicin entre realizaciones Una vez hecha esta actividad se debe determinar el estereotipo de la asociacin entre realizaciones, para esto se debe realizar un clic derecho en la asociacin y seleccionar Open Specification, como se puede ver en la Pantalla 9. 298
Pantalla 9. Determinar el estereotipo para la asociacin entre realizaciones Esta actividad llevar a una ventana de la cual se debe seleccionar la opcin General y Stereotype, lo cual permitir seleccionar el estereotipo para la asociacin. El resultado se puede ver en la Pantalla 10.
Pantalla 10. Definicin del estereotipo de asociacin De este modo se ha creado un ejemplo de creacin de realizaciones de diseo, este ejemplo es muy sencillo, sin embargo es ilustrativo para realizar realizaciones ms complejas. Ahora se realiza el diagrama de clases web para el caso de uso de Autenticar Empleado, en si para la realizacin de diseo RD Autenticar. Dentro del Diagrama de Clases Web no se especifica los mtodos de cada una de las clases que participan en el diagrama.
299
Se puede ver en la Figura 1 el diagrama de colaboracin, el cual corresponde a la realizacin del caso de uso de Autenticar Empleado. Este diagrama es el inicio del diagrama de clases Web, la interfaz se convertir en un Client Page y en un HTML Form, la controladora se convertir en una Clase Server Page, las clases Entidad no se las tomara en cuenta, en remplazo de estas ir la interfaz del servicio web que se ha definido en la arquitectura para el subsistema de Seguridad.
3: Encriptar(Contrasena)
1: Autenticar(Cuenta, Contrasena)
2: Autenticar(Cuanta, Contrasena)
: Empleado
: AutenticarEmpleado
: C Autenticar 5: Obtener Autorizacion(IdentificadorEmpleado)
4: Autenticar(Cuenta, ContrasenaEncriptada)
: Empleado
: Autorizacion
Figura 1. Diagrama de Colaboracin para la realizacin de Autenticar Empleado Para poder convertir el diagrama de colaboracin de la Figura 1 a un diagrama de clases web, primero se debe tomar en cuenta la arquitectura y el marco de trabajo, adems del mapa de navegacin, el cual se ha creado en el anterior documento. Para iniciar la creacin del Diagrama de Clases Web se debe realizar un clic derecho en a la realizacin de diseo RD Autenticar, como se puede ver en la Pantalla 11, se debe seleccionar la opcin de New y Class Digram, esta plantilla nos permitir desarrollar un diagrama de clases web.
Pantalla 11. Crear un diagrama de clases web 300

Una vez realizada la actividad se debe cambiar de nombre al diagrama de clases, para el ejemplo se introducir el nombre de Clases Web Autenticar, como se puede ver en la Pantalla 12.
Pantalla 12. Determinar el nombre al diagrama de clases web No olvidar que por cada realizacin de diseo se tendr un diagrama de clases web, como tambin, un diagrama de secuencia. Una vez realizada la actividad anterior se debe realizar doble clic en el nuevo diagrama de clases, lo cual permitir visualizar una nueva plantilla. Dentro de esta plantilla se debe desarrollar un diagrama de clases web. Para la creacin se debe tener en cuenta: La interfaz de la Figura 1 con el nombre de AutenticarEmpleado, cambiar de Nombre por PAutenticar, lo cual corresponde al nombre de la clase Client Page del Mapa de Navegacin del subsistema Seguridad. Se visualiza, en la Figura 1, un envo de datos por parte del actor Empleado y una respuesta por parte de la aplicacin, lo cual se convertir en un clase HTML Form con el nombre de C_Autenticar, esta estar asociada con la clase Client Page PAutenticar, entre estas tendrn una relacin de composicin (este termino se ver en el diagrama de clases de diseo). Se visualiza en la Figura 1, una controladora con el nombre de C Autenticar, la cual se convertir en una clase Server Page con el nombre de CIUAutenticar, donde CIU representar a Controladora de Interfaz de Usuario (estas abreviaciones deben ser discutidas por el grupo de desarrollo antes de desarrollar el diseo, es una forma de estandarizar el desarrollo) Por ltimo, se visualiza dos entidades con el nombre de Empleado y Autorizacion, a las cuales se les solicita informacin. Dentro del diseo y siguiendo con el marco de trabajo la solicitud de informacin se hace a travs del servicio web, este se encargar de proporcionar la informacin (esta actividad se describir en el diagrama de secuencia). Cuando se realice los diagramas de secuencia se crearn las clases de entidad.
Ahora se debe crear cada una de las clases descritas anteriormente. La clase de PAutenticar, ya se la ha creado en el Mapa de Navegacin. Se crear la clase con un estereotipo de HTML Form con el nombre de C_Autenticar, donde C_ significa Control de Usuario, no debe confundirse con la controladora d e interfaz. Adems, C_Autenticar debe llevar el estereotipo de HTML Form. 301
Para crear esta clase se debe realizar un clic derecho en la carpeta de ControlesUsuario que se encuentra en la carpeta de User Services que corresponde con la capa de presentacin. Esta operacin se la puede ver en la Pantalla 13.
Pantalla 13. Inicio de crear una clase HTML Form Se debe seleccionar la opcin New y Class, para luego cambiar el nombre de la nueva clase a C_Autenticar. Para terminar se debe cambiar el estereotipo a HTML Form, para esto se debe entrar a Open Specification y realizar un clic en el campo de Stereotype para seleccionar HTML Form, como se puede ver en la Pantalla 14.
Pantalla 14. Definir el estereotipo para la clase de HTML Form 302

Una vez seleccionado el estereotipo se debe realizar un clic en el botn de OK, el resultado de estas actividades debe ser igual a la Pantalla 15.
Pantalla 15. Clase HTML Form C_Autenticar Ahora se crear la clase controladora CIUAutenticar, para esto se debe realizar un clic derecho en la carpeta de ControlInterfaz que pertenece a la capa de User Services. Esta operacin har a parecer una ventana, de la cual se debe seleccionar las opciones de New y Class, para luego cambiar el nombre a la clase con el CIUAutenticar, el resultado de estas actividades se la puede ver en la Pantalla 16.
Pantalla 16. Crear una Clase de Server Page Una vez creada la clase se debe cambiar el estereotipo a Server Page, para esto se debe hacer doble clic en la clase, lo cual har visualizar una ventana, que se puede ver en la Pantalla 17, dentro de esta ventana se debe seleccionar, dentro del campo de Stereotype el nombre de Server Page.
303
Pantalla 17. Definicin del estereotipo de Server Page Una vez seleccionado el tipo de estereotipo se debe realizar un clic en el botn OK, el resultado de esta actividad se puede ver en la Pantalla 18.
Pantalla 18. Clase CIUAutenticar Ahora, iniciaremos el desarrollo del diagrama de clases web para la realizacin de diseo de Autenticar. Se debe realizar un clic en la realizacin de diseo con el nombre de RD Autenticar, ubicada en la carpeta del subsistema de Seguridad, RCU y autenticar, una vez ubicada la realizacin se debe realizar doble clic sobre el diagrama de clases web con el nombre de Clases Web Autenticar, esta actividad nos permitir visualizar una plantilla la cual nos permitir describir la realizacin. Una vez visualizada la plantilla se debe arrastrar las clases que se han creado anteriormente, el resultado de esta actividad se la puede ver en la Pantalla 19.
304
Pantalla 19. Diagrama de Clases sin Asociaciones Ahora, se debe definir las asociaciones entre estas clases, se inicia con la clase de PAutenticar y C_Autenticar. Para esto debe realizar un clic en el botn de Uniditectional Association y realizar un clic en la clase PAutenticar y arrastrar hasta la clase de C_Autenticar, tambin se debe quitar la navegabilidad y dar a la asociacin el estereotipo de Link, el resultado se puede ver en la Pantalla 20.
Pantalla 20. Determinar el estereotipo de la Asociacin Estas dos clases tienen una asociacin de Composicin, esta relacin se determina por que al eliminar la clase de PAutenticar se eliminar C_Autenticar. No debe olvidarse que C_Autenticar en una clase de tipo HTML Form, es decir un formulario que muestra o solicita datos. Para determinar la asociacin de composicin se debe seguir los siguientes pasos. 305
Se debe realizar un clic derecho en la parte izquierda de la lnea de asociacin, esta actividad hara visualizar una ventana con varias opciones ya conocidas, pero ahora se debe seleccionar Aggregate que significa Agregacin, este trmino significa una relacin dbil entre las clases, como se puede ver en la Pantalla 21.
Pantalla 21. Definir la el Tipo de Asociacin El resultado de esta actividad se puede visualizar en la Pantalla 22. Se puede ver un rombo en la parte izquierda de la lnea de Asociacin.
Pantalla 22. Asociacin de tipo Agregacin Para determinar la Composicin se debe realizar un clic derecho sobre la derecha de la lnea de asociacin y seleccionar Open Standar Specification, lo cual llevar a una ventana donde se debe seleccionar la opcion de Rol B Detail y activar By Value, como se puede ver en la Pantalla 23.
306
Pantalla 23. Definir una asociacin de Composicin Para terminar, se debe realizar un clic en el botn de OK. Esta operacin har que el rombo de agregacin se pinte totalmente cambiando el concepto de la asociacin, el resultado se puede ver en la Pantalla 24.
Pantalla 24. Asociacin de Composicin La clase C_Autenticar ser la encargada de enviar datos que permitan autenticar a un usuario esto significa que enviar a la clase CIUAutenticar. Esto significa que existir una asociacin entre las clases de C_Autenticar y CIUAutenticar. Esta asociacin ser de tipo Submit y no ser de tipo composicin ya que al desaparecer la clase C_Autenticar la clase CIUAutenticar no ser eliminada porque puede ser que otra clase la utilice. Para definir esta asociacin se debe realizar las mismas actividades que en la Pantalla 20, solo se debe cambiar el estereotipo de la asociacin a Submit, el resultado se puede ver en la Pantalla 25.
307
Pantalla 25. Asociacin Submit Un detalle que se puede observar es la direccin de la flecha de la asociacin, esta est apuntando hacia CIUAutenticar, esto significa que la clase C_Autenticar enviar datos hacia CIUAutenticar. Como se ha dicho antes, se debe solicitar al servicio web los datos necesarios para cumplir con las solicitudes de los usuarios de la aplicacin, adems esto obliga el marco de trabajo que se ha definido. Para cumplir con el marco de trabajo se debe arrastrar al diagrama de clases web la clase que representa al servicio web de Seguridad, este servicio web est en la ubicacin de Business Service, esta es la carpeta que representa a la capa de negocio, dentro de esta se encuentra la carpeta de ServiciosWeb y el servicio web con el nombre de SWSeguridad como se puede ver en la Pantalla 26.
Pantalla 26. Ubicacin del Servicio Web de Seguridad Este servicio web se debe arrastrar hacia el diagrama de clases web que se est desarrollando, para luego definir una asociacin con la clase de CIUAutenticar, esta asociacin debe llevar un nombre, generalmente se coloca Controla y se debe quitar la direccin de la asociacion, no lleva ningn estereotipo como Submit, Link u otro, solo es una asociacin entre clases, el resultado de estas actividades se la puede ver en la Pantalla 27.
308
Pantalla 27. Definir la asociacin con un servicio Web Para colocar el nombre de Controla se deb realizar doble clic en la asociacin y dentro de Open Specification introducir el nombre de la asociacin en el campo de Name. De esta forma se ha terminado el desarrollo de un Diagrama de Clases Web. A continuacin, se podr visualizar varios ejemplos de este tipo de diagrama. Estos ejemplos con de la aplicacin de ejemplo.
Figura 2. Caso de Uso Gestionar Bebidas En la Figura 2, representa a las tres realizaciones de diseo del caso de uso de Gestionar Bebidas.
309
<<Link>>
PPersonal
(f rom WebForms)
<<Link>>
PModificarPersonal
(f rom Controles de Usuario)
<<Link>>
PAdicionar
<<Submit>> <<Link>> <<Submit>> <<Submit>> PEliminar

Controla
<<Build>> CPersonal
(f rom Controladoras)
SWSeguridad
(f rom Serv icios Web)
PMensage
310
DIAGRAMA DE SECUENCIA En este documento se describir la importancia de los diagramas de secuencia, estos sern los que permitan introducir a la implementacin, en si sern los que nos guen como un plano de construccin a un arquitecto. En el anterior documento se ha descrito el diagrama de clases web, el cual describe la dependencia entre clases que representan pginas y formularios web, adems de cmo interactuar con los servicios web definidos en la arquitectura. Ahora se inicia la descripcin de las llamadas a eventos de las clases que participan o participaran. Esta etapa es la final para descubrir las clases persistente en su totalidad, no debe olvidarse que se desarrolla por ciclos de desarrollo, en cada ciclo se incluir clases persistentes. El trmino de Clase Persistente se debe entender como la capacidad de un objeto de trascender en el espacio y tiempo. Este trmino se aclarar con detalle en el prximo documento. Los diagramas de Secuencia pueden ser usados para: Representar la dinmica del sistema. Se logra con el diagrama de secuencia del sistema (DSS) en el cual se representa la interaccin de un actor con el sistema como una caja negra. Representar la interaccin entre los objetos del sistema. Este diagrama de secuencia muestra los objetos y clases envueltas en el escenario y la secuencia de mensajes intercambiados entre los objetos necesarios para realizar la funcionalidad del escenario. Un diagrama de secuencia tpicamente es asociado con un caso de uso en el modelo del sistema bajo desarrollo. Los diagramas de secuencia tienen dos ejes: el eje vertical muestra el tiempo y el eje horizontal un conjunto de objetos. Cada objeto tiene una lnea de vida donde se sita su foco de control. El foco de control es un rectngulo que representa el tiempo durante el que un objeto est activo ejecutando una accin. Como se puede ver en la Figura 1.
Figura 1. Ejes del Diagrama de Secuencia
311
Con este sencillo esquema podemos visualizar la comunicacin y sincronizacin bajo un estricto orden temporal de los objetos implicados en las distintas funcionalidades de un sistema. Una clase que se utilice dentro de un diagrama de secuencia se la debe estudiar como un objeto ya que cada clase crea un objeto al momento de llamar a un mtodo, como se puede ver en la Figura 1. La Clase PAutenticar crear una instancia de la clase CAutenticar convirtindose esta ltima en un objeto, del cual se puede utilizar los mtodos definidos. Dentro del diagrama de secuencia se debe estudiar varios conceptos y estereotipos, se ve los siguientes: - Objeto. Un objeto es representado por medio de un rectngulo, dentro de este se debe
introducir un nombre. . Un objeto puede ser descrito de tres formas: Nombre del Objeto, Nombre del Objeto mas la clase o solamente la clase que representar a un objeto annimo Solicitudes. Una solicitud es una comunicacin entre objetos que lleva informacin con la esperanza de que sea tomada. La recepcin de una solicitud se la considera como un evento. Los mensajes entre objetos estn representados por fechas que van desde el objeto emisor hasta el objeto receptor. Cada mensaje puede tener un nombre, parmetros y una respuesta. Los tipos de mensajes. Dentro de Racional Rose para el diagrama de secuencia se tiene los siguientes tipos de mensajes: o Simple (Simple): Para mensajes con un solo hilo de control, un objeto enva una solicitud a un objeto pasivo. o Synchronous (Sincrnico): La operacin solo procede cuando el objeto solicitante le enva una solicitud al objeto receptor y este acepta la solicitud. o Balking: El objeto emisor solo puede pasar la solicitud si el objeto receptor est listo para aceptar el mensaje, si no abandona la solicitud. o Timeout (Interrupcin): El objeto emisor abandona la solicitud si el objeto receptor no puede responder dentro del tiempo especificado. o Asynchronous (Asincrnico): El objeto emisor le enva una solicitud al objeto receptor y contina ejecutando acciones sin esperar una respuesta que le indique si el objeto receptor recibi o no la solicitud. o Procedure Call (Llamada a un procedimiento): El objeto emisor le enva una solicitud al objeto receptor y debe esperar hasta que la secuencia de mensajes anidados sea procesada. o Return (Retorno): Esta opcin indica el retorno de una solicitud a un procedimiento. Solicitud a si mismo. Un objeto puede solicitar un evento a s mismo, ser tanto el emisor como el
receptor.
312
Condiciones en las Solicitudes. Una solicitud puede tener condiciones e iteraciones. Una condicin debe ser cierta para que sea la solicitud se realice. Las condiciones son mostradas para modelar ramificaciones o para decidir si enviar o no la solicitud. o Condicin que debe ser cierta antes de llamar a la solicitud. Algunas veces la condicin que permite llamar a un mtodo de un objeto es compleja, cuando existe este comportamiento se debe describir de diferente forma para que el diagrama sea comprensible. Recomienda Rational que por cada clase y objeto se realice una descripcin de utilizacin incluyendo a sus atributos y mtodos. Cuando se desarrolla un diagrama de secuencia y se necesita describir a una solicitud solo se debe realizar doble clic sobre la flecha de la solicitud, esta operacin permitir visualizar una pantalla donde el desarrollador podr documentar y explicar el por qu se realiza la solicitud. Tambin, esta condicin permite describir ramificacin es de solicitudes, es decir que sin no cumple una se solicita otra.
o Mensajes de Iteracin. Estos son enviados varias veces, pudiendo especificar adems la cantidad de veces.
Un punto que se debe tomar en cuenta, que deja claro Rational, es que en esta etapa de desarrollo van apareciendo detalles de las clases persistentes, estas clases conformarn en gran medida al diseo de almacenamiento, a la base de datos. Es muy importante llegar a esta etapa para determinar las clases, su asociacin, dependencia entre estas y sus atributos. No debe olvidarse que los atributos estn descritos en la Descripcin de los Casos de Uso, esto se vio en el documento que hace de introduccin al Anlisis. Hay muchos desarrolladores que realizan primero el diagrama de clases e incluso otro diagrama que permite describir el diseo de almacenamiento antes de la descripcin de los casos de uso. Esto es un error, ya que no se tiene de forma exacta lo que necesita un objeto para ser til en la aplicacin e incluso se repite cdigo. Se debe evitar este tipo decisiones y tener paciencia para determinar el diagrama de clases. Se utiliza la realizacin de diseo con el nombre de RD Autenticar, que se encuentra en el subsistema de seguridad para realizar un ejemplo de desarrollo de un diagrama de secuencia. El diagrama de secuencia que se desarrolla a continuacin est en funcin del diagrama de colaboracin, el marco de trabajo, el diagrama de clases web y por supuesto por la descripcin del caso de uso de Autenticar Empleado.
313
El primer paso es realizar un clic derecho sobre la realizacin RD Autenticar, lo cual desplegar varias opciones de las cuales se debe seleccionar New y Sequence Diagram como se puede ver en la Pantalla 1.
Pantalla 1. Crear un Diagrama de Secuencia Una vez realizada la actividad se debe cambiar de nombre al nuevo diagrama de secuencia, el nombre ser Autenticar, como se pude ver en la Pantalla 2.
Pantalla 2. Diagrama de Secuencia creado Se debe realizar doble clic sobre el nuevo diagrama de secuencia, lo cual mostrar una plantilla para desarrollar. Para iniciar el desarrollo del diagrama de de secuencia se deben arrastrar las clases que participarn en este. Para el ejemplo se iniciar al actor con el nombre de Empleado, el cual se encuentra en Use Case View, Use-Case Model y Actors. Algunos modeladores de diseo no incluyen actor dentro del diagrama de secuencia, este punto no es un error, sin embargo la descripcin de la secuencia siempre toma en cuenta al actor, debido a que el diagrama de secuencia parte del diagrama de casos de uso. Luego de arrastrar al actor se necesita una clase Client Page o un HTML Form, depende del desarrollador o de la empresa de desarrollo, tambin el desarrollador decidir manejar variables de seccin u otro tipo de envo de informacin a travs de las pginas. Se utilizar un objeto con el nombre de Session, ya que en la implementacin se utilizar es objeto. 314
Para el ejemplo se utilizar la clase de Cliente Page con el nombre de PAutenticar, la ubicacin de esta clase es Local View, User Services y WebForm, el resultado de estas actividades se puede ver en la Pantalla 3.
Pantalla 3. Inicio del Diagrama de Secuencia Como se puede ver en el diagrama de colaboracin para la realizacin de anlisis y la descripcin del caso de uso Autenticar Empleado, existe una interaccin entre el actor y la aplicacin de solicitud de autenticacin, como describe el caso de uso se enva una Cuenta y una Contrasea, adems dentro de los requisitos no funcionales para el caso de uso se indica que la contrasea tiene que estar encriptado al momento de la transmisin a travs del protocolo de http. Para iniciar con la descripcin de las solicitudes entre las clases primero se debe crear una sesin que ayude a guardar datos. La sesin debe ser igual a la clase controladora, esto significa que se necesita una instancia de la controladora de interfaz. Para esto, se debe arrastrar la clase controladora de interfaz con el nombre de CIUAutenticar, ubicada en Logical View, User Services y ControlInterfaz, hacia la plantilla del diagrama de secuencia. Como se puede ver en la Pantalla 4.
Pantalla 4. Arrastrar Controladora de interfaz Cada pgina tiene un evento de PageLoad predeterminado que se activa cada vez que se carga en un navegador la pagina, dentro de este evento se debe crear el objeto de sesin para poder guardar los datos. Para determinar esto se debe realizar un clic en el botn Message to Self , el cual nos permitir describir la solicitud de PageLoad, el resultado de esta actividad se puede ver en la Pantalla 5.
315
Pantalla 5. Definicin de una Solicitud as misma Una de las caractersticas de este evento es que debe ser de tipo Procedure Call, antes de seleccionar este tipo de solicitud se crear la solicitud de PageLoad. Se debe realizar un clic derecho sobre la solicitud recin creada, lo cual desplegar un conjunto de opciones de las cuales se debe seleccionar <new operation>. Como se puede ver en la Pantalla 6.
Pantalla 6. Crear una Solicitud El nombre de esta nueva solicitud ser PageLoad, para cambiar el nombre de esta nueva operacin se debe realizar un clic derecho sobre opname() y seleccionar Open Specification, lo cual mostrar una ventana. De esta ventana se debe seleccionar la opcin de Browse Selection, como se puede ver en la Pantalla 7.
316
Pantalla 7. Cambiar de nombre a la Solicitud Esta actividad desplegar una nueva ventana con el nombre de Operation Specification, de la cual se debe cambiar el campo de Name por PageLoad y Return Type por void, este ltimo significa que no devolver ningn dato la solicitud. Dentro del C#.NET void, de la misma manera, determina que una solicitud no devolver ningn dato. El resultado de esta actividad se puede ver en la Pantalla 8.
Pantalla 8. Determinar el Nombre de la Solicitud 317

Una vez hecha esta actividad se debe realizar un clic en el botn OK hasta salir de las ventanas. El resultado de estas actividades se puede ver en la Pantalla 9.
Pantalla 9. Resultado de la creacin de una solicitud Ahora, se debe determinar el tipo de solicitud para PageLoad, para esto se debe realizar un clic derecho y seleccionar Open Specification, ya dentro de la ventana se debe seleccionar la pestaa Detail, la cual desplegar un conjunto de opciones que describen a cada tipo de solicitud, se debe seleccionar Procedure Call, como se puede ver en la Pantalla 10.
Pantalla 10. Definir el tipo de solicitud Una vez hecha esta actividad se debe realizar un clic en el botn OK. La flecha que pertenece a la solicitud cambiar de aspecto. Ahora se debe crear una nueva solicitud que permita crear una instancia de la clase de CIUAuteniticar. Para esto se debe utilizar el botn de Object Message , luego de realizar un clic en el botn de Objet Message se debe realizar un clic en la clase de PAutenticar, dentro del rectngulo de tiempo, y arrastrar hasta la clase de CIUAuenticar. El resultado se puede ver en la Pantalla 11.
318
Pantalla 11. Crear una nueva solicitud Una vez hecha estas actividades se debe introducir un nombre a la nueva solicitud, el cual ser el mismo nombre de la clase, ya que ser el nombre del constructor de la clase. Para esto se debe realizar las mismas actividades que se han descrito para crear la solicitud de PageLoad. El resultado se puede ver en la Pantalla 12.
Pantalla 12. Creacin de la solicitud CUIAutenticar Dentro de la solicitud de PageLoad se crear la sesin que permita almacenar datos mientras este activa la pagina. Una vez creada la sesin se puede describir la interaccin del actor con la aplicacin. Para describir esta interaccin se debe realizar un clic en el botn Object Message , dentro de la barra de herramientas de la plantilla del diagrama de secuencia, realizar un clic sobre el Empleado y arrastrar hasta C_Autenticar que es una clase de tipo HTML Form. Esta ltima clase de la debe arrastrar hacia la plantilla de desarrollo del diagrama de secuencia. Como se puede ver en la Pantalla 13.
319
Pantalla 13. Primera Solicitud de interaccin con el actor Como en le diagrama de colaboracin se debe realizar clic derecho sobre la flecha de la solicitud, esta enviar dos parmetros de tipo carcter, se debe seleccionar la opcin de <new operation> como se puede ver en la Pantalla 14.
Pantalla 14. Crear una solicitud Una vez hecha esta actividad aparecer una ventana con varias opciones con el nombre de Operation Specification, esta solicitar el nombre de la solicitud en el campo de Name, el nombre ser Autenticar, adicionalmente se debe definir el tipo de dato que devolver la solicitud, se debe tomar en cuenta los tipos de datos que maneja el lenguaje de programacin, con el cual se implementar los diagramas de secuencia, ya que Rational Rose puede generar cdigo. El tipo de dato que devolver la solicitud ser de tipo string, este tipo de dato debe estar en minsculas, ya que en C#.NET este tipo de dato pertenece a una cadena de caracteres. El resultado se puede ver en la Pantalla 15.
320
Pantalla 15. Definir el Nombre y el Tipo de dato de la solicitud Para ingresar los parmetros, los cuales sern utilizados por la solicitud se debe ir a la opcin de Detail dentro de la ventana de Operation Specification, realizar clic sobre la columna Name y seleccionar Insert como se puede ver en la Pantalla 16.
Pantalla 16. Crear un Parmetro El nombre de este nuevo parmetro ser Cuenta y de tipo string. El resultado se puede ver en la Pantalla 17.
321
Pantalla 17. Definir el nombre y el tipo para el Parmetro De esta misma forma se puede adicionar un nuevo parmetro que ser Contrasena de tipo string. El resultado de esta operacin se puede ver en la Pantalla 18.
Pantalla 18. Definir otro parmetro para la solicitud Como se puede ver en la ventana de Operation Specification existen distintas pestaas, adicionalmente a las dos que se ha visto, las pestaas Preconditions y Postconditions son importantes ya que en estas se puede describir las caractersticas de la solicitud, claro est que depende del grupo de desarrollo o del desarrollador llenarlas.
322
Una vez hecha las actividades se debe realizar un clic en el botn OK. El resultado se puede ver en la Pantalla 19.
Pantalla 19. Solicitud de definida de Autenticar El siguiente paso es solicitar a la controladora de interfaz que autentique al empleado, para esto se debe crear una nueva solicitud que vaya desde c_Autenticar hasta CIUAutenticar, con el nombre de Autenticar, esta solicitud devolver un dato de tipo string. Adicionalmente se deben describir los parmetros de Cuenta de tipo string y Contrasena de tipo string. El resultado se puede ver en la Pantalla 20.
Pantalla 20. Solicitud de Autenticar de CIUAutenticar CIUAutenticar debe tener una solicitud que permita cifrar la contrasea, para esto se debe crear una nueva solicitud con el nombre de CifrarContrasena que devolver un string y con un parmetro con el nombre de Contrasena. El resultado de esta actividad se puede ver en la Pantalla 21.
323
Pantalla 21. Solicitud CifrarContrasea. Una vez que se tiene cifrada la contrasea se puede enviar hacia el servicio web del subsistema de Seguridad para que pueda autenticar al Empleado, el nombre del servicio web es SWSeguridad y est ubicado en Bussiness Services y ServiciosWeb. Para esto se debe arrastrar a la interfaz del servicio web hacia la plantilla, luego crear una solicitud que vaya desde CIUAutenticar hasta SWSeguridad, con el nombre de Autenticar y parmetro de Cuenta de tipo string y ContrasenaCifrada de tipo string, esta nueva solicitud debe devolver un dato de tipo string, que permita describir el tipo de error o conformidad de accin de autenticar. El resultado se puede ver en la Pantalla 22.
Pantalla 22. Creacin de una solicitud para el Servicio Web de Seguridad Como se puede observar se est asociando dos capas que son la Capa de Pesentacin y la Capa de Negocio estas dos capas interactuaran a travs de la controladora de interfaz y del Servicio Web. Ahora, se debe crear una clase controladora del negocio para el servicio Web, debe crearse en la ubicacin Business Service y Controladoras, son el nombre de CSW_Seguridad, donde CSW significa Contoladora del Servicio Web, esto se puede ver en la Pantalla 23. 324
Pantalla 23. Crear una controladora del negocio. Una vez creada la clase se debe arrastrar hacia la plantilla del diagrama de secuencia, luego se debe crear una nueva solicitud que vaya desde SWSeguridad hasta CSW_Seguridad, con el nombre de Autenticar que devolver un dato de tipo string, adicionalmente se debe incluir los parmetros de Cuenta y ContrasenaCifrada de tipo string. El resultado se puede ver en la Pantalla 24.
Pantalla 24. Crear una Solicitud en CSW_Autenticar Antes de continuar se debe aclarar que no se utilizar procedimientos almacenados para la bsqueda de una determinada tupla dentro de la base de datos. Se recomienda, solo utilizar procedimientos almacenados sencillos que no contenga ms de una sentencia. Esta recomendacin est dada por no conocer el administrador de base de datos que se utilizar. La controladora del servicio web realizar varias tareas, son las siguientes: - Solicitar a la base de datos informacin para poder autenticar al Empleado - Almacenar en un objeto el conjunto de informacin que devuelva la base de datos - Realizar la autenticacin utilizando al objeto
325
Para esto se necesita definir el patrn Data Transfer Object (Objeto de Transferencia de Datos - DTO). El objeto DTO se utilizar para la transferencia de datos a travs de capas mltiples, es un objeto serializable simple. Mayor informacin sobre este patrn en http://msdn2.microsoft.com/enus/library/ms978717.aspx Problema a resolver por el DTO Cmo en una aplicacin distribuida se disminuye el tiempo de respuesta? Solucin Crear un Data Transfer Object (DTO) que contenga los datos requeridos de la llamada remota. Una sola llamada remota. Tambin, se utilizar un objeto, ya creado por Microsoft con el nombre de SQLHelper, el cual permitir el acceso a los datos, este objeto es recomendado por Microsoft para la capa de acceso a los datos. Mayor informacin en http://msdn2.microsoft.com/en-us/practices/bb190359.aspx . Ahora, se crear dos clases que representarn a estos dos patrones. La primera clase ser un DTO con el nombre de DTOEmpleado. Para esto se debe crear una clase en la ubicacin Logical View, Business Service y Reutilizables. Se debe hacer un clic derecho en la carpeta de Reutilizables y seleccionar new y la opcin Class, se debe dar el nombre de DTOEmpleado, adicionalmente se debe cambiar el estereotipo a Table. El resultado se puede ver en la Pantalla 25.
Pantalla 25. Creacin de un DTO Una vez creada la clase DTO se debe crear la clase que nos permitir acceder a los datos, tendr el nombre de SQLHelper, esta estar ubicada en Logical View, Data Service, SQLHelper. Esta clase ser la frontera de la aplicacin con el gestor de base de datos. A esa clase se le puede dar el estereotipo de <<data access>>. El resultado de esta actividad se puede ver en la Pantalla 26.
326
Pantalla 26. Crear una clase para el acceso a los datos Una vez creada esas dos clases se debe arrastrar a la plantilla del diagrama de secuencia de ejemplo. Una vez ubicadas, como se puede ver en la Pantalla 27, se debe hacer lo siguiente: Crear una solicitud desde CSW_Seguridad hasta el DTOEmpleado con el nombre de DTOEmpleado, para crear una instancia del DTO. La solicitud es el constructor de la clase no debe llevar parmetros. Esta solicitud devolver un DTOEmpleado. Crear una solicitud desde CSW_Seguridad hasta la SQLHelper son el nombre de FillDataset, este mtodo permitir obtener los datos de los Empleados y colocarlos en el objeto DTO instanciado anteriormente. Este mtodo tendr los siguientes parmetros: o Cadena de conexin hacia el administrador de la base de datos, tendr el nombre de Cadena y ser de tipo string o El tipo de comando, que puede ser un procedimiento almacenado o un texto SQL, tendr el nombre de TipoComando y ser de tipo CommandType. o El nombre del procedimiento almacenado o el texto SQL, tendr el nombre de PANombre y de tipo string. Este servir para hacer referencia al nombre del procedimiento almacenado dentro de la base de datos. o El nombre del DTO instanciado, tendr del nombre de dtoEmpleado y de tipo DTOEmpleado. o Un vector con el nombre de las tablas, tendr el nombre de arrayTablas y ser de tipo array. Esta solicitud no devolver ningn valor, solo permitir llenar el DTO instanciado. Crear una solicitud a si misma de CSW_Seguridad con el nombre de AutenticarEmpleado, donde los parmetros sern: dtoEmpleado, Cuenta y ContrasenaCifrada. Esta solicitud permitir autenticar al Empleado. Esta solicitud devolver un string, la cual permitir devolver los siguientes valores: Autenticado, No coincide la cuenta de usuario y/o La contrasea.
El resultado de estas actividades se puede ver en la Pantalla 27.
327
Pantalla 27. Final del Diagrama de Secuencia Autenticar Una de las observaciones que se puede hacer al diagrama de secuencia creado en este documento es que se pueden separar las solicitudes de creacin de sesin en una realizacin de diseo aparte de la que se ha hecho. Como se ha podido observar el diagrama de secuencia es muy descriptivo y debe ser muy completo, no debe olvidarse que es uno de los artefacto principales para la implementacin, adicionalmente a este artefacto se debe tomar en cuenta la descripcin del caso de uso. Se puede ver el ejemplo de HotelBeto2.mdl, el cual describe de forma completa el caso de uso Registrar Solicitud de Servicio Bsico. Un punto importante que se debe tomar en cuenta es la transformacin de las realizaciones de anlisis para este casos de uso en realizaciones de diseo, como se puede observar se ha dividido en pequeos diagramas de secuencia que representan a realizaciones de diseo, esto en software de tamao mediano incrementar la productividad del equipo de desarrollo, desde que se ha aprendido a desarrollar software se recomienda divide y vencers. Otro punto importante es el manejo de las entidades, estas entidades (Clases Persistentes), estarn siendo transmitidas por el protocolo http hasta la aplicacin cuando se necesiten, de esta forma se tendr un orden en la captura de los datos que el actor introduce a la aplicacin. Para realizar el diagrama de secuencia se necesita tener una buena experiencia en la tecnologa y entorno de desarrollo, ya que el modelador necesitar abstraerse tomando en cuenta el marco de trabajo, la relacin entre las clases, el lenguaje de programacin, el entorno de desarrollo, tecnologa de interfaz (ejemplo, AJAX, javascript), seguridad, entre otros.
328
DIAGRAMA DE CLASES En documentos anteriores se tocaron algunas de las caractersticas de las clases, como los tipos de asociacin composicin y agregacin. En este documento se profundiza el desarrollo del diagrama de clases. Para el desarrollo de este diagrama se debe tomar en cuenta a los diagramas de secuencia, de los cuales se deben determinar a las clases persistentes, las cuales conformarn el diagrama de clases. No debe olvidase que el Diagrama de Secuencia est en funcin de la descripcin de los casos de uso, si no se ha hecho el Anlisis. Una clase tiene las siguientes caractersticas, como se puede ver en la Figura 1:
Figura 1. Caracteristicas de una Clase En distintos libros puede varias los estereotipos de visibilidad, sin embargo el Nombre, Atributos y Operaciones no deben variar. Donde las operaciones son ocurrencias internas y externas que causan alguna accin en el sistema. Las operaciones ayudan a determinar las clases activas. Cada evento tiene para su descripcin los siguientes puntos: - Interno o Externo. Se debe especificar si va hacer Interno (solo se ejecutar en la clase) o si se ejecutar fuera de la clase (externo a la Clase). - Prioridad. Se debe especificar si los eventos inferiores (La suspensin de otro evento para ser manejado) - Frecuencia. Se debe determinar cuan frecuente ocurre el evento - Distribucin de la frecuencia. Se debe especificar si el evento ocurre en intervalos regulares o hay picos. - Requisitos de respuesta. Se debe especificar el tiempo promedio para la respuesta del evento. Una lista de operaciones externas puede ser derivada del modelo de Casos de Uso, de las interacciones de los actores con los Casos de Uso o pueden ser identificados en el desarrollo del diseo. Un atributo es una propiedad de un objeto, como tamao, posicin, nombre, precio, fuente, tasa de inters, o muchas otras. En UML, cada atributo puede ser convertido a un tipo, el cual es una clase o primitiva. Si se elige un tipo especfico, ste debera ser mostrado a la derecha del nombre del atributo (se puede decidir no especificar los tipos de los atributos durante el anlisis, esto porque los tipos son obvios o porque no se desea definirlos todava.) 329
Los atributos pueden ser mostrados en un diagrama de clases agregando un compartimento debajo del nombre de la clase. Para economizar espacio, se puede documentarlos de manera separada en lugar de una lista de atributos, completa con descripciones. Si se utiliza una herramienta de desarrollo, se puede esperar poder hacer un acercamiento para mirar los atributos (y sus descripciones) o un alejamiento para ver slo los nombres de las clases. Tan pronto como se empiece a mostrar y definir el tipo de dato de los atributos, se generan dudas: es una cadena?, Es un booleano? Si el tipo es el nombre de alguna de las propias clases, no existe problema, adems que para el diseo se tiene definido el lenguaje de implementacin. Aunque UML permite definir propios tipos datos base en notacin independiente al lenguaje. Se puede tambin desear evitar usar los tipos de datos array, que son usualmente una mezcla entre un objeto y una primitiva, an cuando la mayora de los lenguajes orientados a objetos lo soportan. La razn es que las clases que se crean son probablemente ms elegantes que usar una coleccin de clases como listas y conjuntos exclusivamente. Durante la fase de diseo, puede encontrarse usando arrays, pero debe ser cuidadoso en no comprometer el buen estilo de programacin por un poco de rendimiento. En cuanto a UML concierne, los atributos y asociaciones SON SLO PROPIEDADES DE UNA CLASE. En otras palabras, cada atributo puede ser mostrado como un atributo o una asociacin con el nombre de atributo como el rol (aunque una asociacin a un valor primitivo o a un arreglo podra lucir fuera de lugar). Esto significa que se puede agregar multiplicidad a los atributos, despus del nombre del tipo, como entero, para atributos multi-valor, o [0...1], para un valor opcional. El primer paso para desarrollar el diagrama de clases (Modelo Esttico) es realizar un listado de las posibles clases, que se convierten en clases candidatas, por cada una de estas se debe realizar una breve descripcin explicando el propsito para el diagrama, si es que el grupo o la empresa de desarrollo de software determine. La descripcin que se realice servir para determinar si existen clases adicional que dependa de la que se est describiendo. Es aconsejable que al momento de determinar las clases est reunido el equipo de desarrollo, los responsables de cada disciplina o de cada rol. Cada clase debe ser entendida por completo, de esta forma se evita la omisin de alguna de estas, logrando una robustez en el diagrama de clases. Los principales roles que debe participar son: Arquitectos, Analistas y los Especificadores de los Casos de Uso. Las clases candidatas generalmente son identificadas por palabras que aparecen en la descripcin de los casos de uso. Con un poco de prctica se podrn identificar rpidamente las palabras que representan a las clases. La descripcin de la clase debe ser completa, es decir, describir a los atributos y a los mtodos u operaciones. Estos, atributos y mtodos, estn presentes en los diagrama de secuencia. Este es otro motivo para que el diagrama de secuencia est desarrollado forma correcta y completa. Se debe entender por clases como un conjunto de responsabilidades que en conjunto conformarn parte de la aplicacin. Se da un conjunto de sugerencias para determinar algunas de las clases: - Los actores (Asistente o Jefe de cocina), se identifican que son clases cuando se necesita almacenar la informacin de una actor, para el Jefe de Cocina se necesita guardar la cuenta y la contrasea para acceder a la aplicacin.
330
Objetos relacionados con el negocio con informacin y comportamiento de inters, cada uno de estos objetos son consultados por los actores para obtener informacin. Grupos de cadenas de caracteres o nmeros que se puedan identificar en la descripcin de los casos de uso.
Algunas veces es muy difcil encontrar un nombre correcto para una clase, si existe este problema se puede dar un nombre abstracto, que no represente la funcin dentro de la aplicacin, PERO, se debe describir en un glosario de trminos la funcin que tendr la clase. Se debe aclarar el trmino de Clases Interfaces, las cuales representarn declaraciones abstractas de responsabilidades dadas por una clase o subsistema. Esta permitir abstraer las responsabilidades de una clase. Interfaces permite capturar y examinar las similitudes de la aplicacin, definidas de forma precisa con las partes de la aplicacin que interactan al momento de ejecutarse. Puede haber composicin (termino que se ver ms adelante) entre estas. Las clases y grupos permiten agrupar relaciones y responsabilidades en unidades que pueden ser desarrolladas con relativa independencia. Las clases llenan un conjunto de responsabilidades atmicas mientras que los subsistemas estn compuestos de bloques que a su vez estn compuestos de clases u otros subsistemas. Cada subsistema debe comunicarse por medio de una clase interfaces, la cual permitir definir un conjunto de operaciones hacia el exterior del subsistema, esto se entiende como la separacin de la declaracin del comportamiento (las especficas clases en el subsistema que realizan el comportamiento de este). Un ejemplo de una clase interfaces se puede ver en la Figura 2. Ya que un Servicio Web puede ser considerado como un subsistema.
Es una clase Interfaces
Figura 2. Ejemplo de una Clase Interfaces Un servicio web puede encapsular el comportamiento de varias clases Controladoras.
331
Otro ejemplo de este tipo de clases son las clases frontera de cada capa que se determine en el marco de trabajo e incluso clases que realizan la conexin a la base de datos, clases que realizan operaciones como por ejemplo bsqueda, filtro de datos, operaciones matemticas, entre otras. Para el ejemplo se crear un diagrama de clases para los subsistemas de Seguridad y luego para Cocina, para esto realizaremos un clic derecho en la carpeta del subsistema Seguridad, inmediatamente aparecer varias opciones de las cuales se debe seleccionar New y Class Diagram, esta actividad har aparecer un nuevo diagrama de clases al cual se le debe cambiar de nombre a Diagrama de Clases Seguridad, el resultado se puede observar en la Pantalla 1.
Pantalla 1. Crear un diagrama de clases Para iniciar el desarrollo del nuevo diagrama de clases se debe realizar doble clic sobre este, lo cual har aparecer un nueva plantilla al lado derecho de la ventana activa. El primer paso es identificar a las clases persistentes que participan en los distintos diagramas de secuencia que correspondan al subsistema de Seguridad. La nica clase que se puede identificar en este subsistema es Empleado, la cual est representada por DTOEmpleado. Por lo tanto el diagrama de clases contendr una clase. Para colocar la clase en el diagrama de clases solo se debe arrastrar hacia la plantilla. La clase Empleado est ubicada en Bussiness Services y Entidades. El resultado de este diagrama de clases para el subsistema de Seguridad se puede ver en la Pantalla 2.
Pantalla 2. Diagrama de Clases del subsistema Seguridad El diagrama anterior es muy simple, ahora se realizar el diagrama de clases del subsistema de Cocina. De igual forma se debe crear un nuevo diagrama de clases con el nombre de Diagrama de Clases de 332
Cocina. Como se puede ver en la Pantalla 3. Como se puede observar el nuevo diagrama est ubicado en la carpeta que representa al subsistema Cocina.
Pantalla 3. Crear el Diagrama de Clases de Cocina Una vez creado el diagrama de clases se debe arrastrar a este todas las clases persistentes que participan en los distintos diagramas de secuencia y las que se puedan identificar en la descripcin de los casos de uso. El resultado de esta actividad se puede ver en la Pantalla 4.
Pantalla 4. Diagrama de Clases de Cocina La multiplicidad y las asociaciones que se visualizan en la Pantalla 4 se las determin el inicio del Captulo III al momento de determinar los elementos ms significativos. Sin embargo algunas de las clases no estn con sus respectivos atributos como por ejemplo Cliente, Orden de Servicio y Habitacin, estos deben ser identificados primero en la descripcin de los casos de uso y luego en el diagrama de secuencia. Est claro que si se encuentra un atributo nuevo en el diagrama de secuencia se debe adicionar a la descripcin del caso de uso. Clase Cliente: Nombre, ApellidoPaterno, ApellidoMaterno, Direccin, CarnetIdentidad, LugarOrigen, LugarDestino, Pasaporte, Nacionalidad, este ltimo atributo se puede convertir en una nueva clase, ya que existen un nmero de considerable de nacionalidades, dentro de este subsistema que se est describiendo no se toma en cuenta. 333
Clase OrdenServicio. FechaOrden, MontoPagado, MontoTotal. Se debe tener mucho cuidado en colocar un cdigo identificador como atributo, generalmente se encuentra en trabajos este tipo de defecto, este cdigo por lo general no pertenece a la clase y no es necesario colocar. Pero, como por ejemplo, el atributo Carnet de Identidad en una clase Persona, si debe ser incluido, adems es un identificador.
Un punto importante, es la asociacin que se pude ver entre Comida, OrdenServicio y Bebida, esta relacin tiene una Multiplicidad de muchos a muchos, si existe una relacin de este tipo, pero se necesita datos adicionales que van a pertenecer a la asociacin se debe adicionar una Clase Asociacin como se puede ver en la Figura 3, este ejemplo es clsico.
Figura 3. Clase Asociacin Para realizar este tipo de asociacin se debe utilizar el botn Association Class , dentro de Rational Rose. Entre otros detalles de este ejemplo esta la Asociacin Direccional, la cual va desde Empresa a Empleado. En la Figura 4 se puede ver las dos clases de asociaciones. A todas las asociaciones se les debe colocar un nombre para el mejor entendimiento de la asociacin, como est en el ejemplo de la Figura 3: Empresa tiene 1 o muchos Empleados.
Figura 4. Navegabilidad Como se puede ver en la Figura 3, se define por cada asociacin una multiplicidad, las cuales se clasifican en: n: Exactamente n. mn: Cualquier nmero en el rango de m a n (inclusive). 0...*: Cualquier nmero en el rango de 0 a infinito. *: Cualquier nmero entre 0 e infinito. 0...1: Opcional.
La nica asociacin que no lleva una multiplicidad es la de Herencia (Generalizacin). Para la composicin, la multiplicidad del elemento compuesto es siempre 1 debido a que, de acuerdo a las reglas de UML, un objeto compositor no puede ser compartido entre objetos compuestos por lo tanto la multiplicidad sera redundante en ste caso. En otras clases, si la multiplicidad no se muestra, se debe asumir que esta no est especificada, o que simplemente no se conoce hasta este punto. Sera 334
incorrecto asumir que una multiplicidad no enunciada implica algn valor por defecto, como 1. Se puede ver en la Figura 5 un ejemplo de Composicin. Es una forma fuerte de agregacin donde el tiempo de vida de la parte coincide con el todo. La multiplicidad en el lado del agregado (todo) debe ser menor igual a 1. El objeto compuesto no se puede compartir por otros objetos y muere con el que lo compone. Forma fuerte de agregacin. Relacin del tipo es parte de.
Figura 5. Asociacin de Composicin Todo esto parece un tanto confuso. La existencia de composicin en UML es realmente solo el resultado de las propiedades de lenguajes de programacin como C++. En C++, un objeto puede ser parte del mismo espacio de memoria que otro objeto: en ste caso, el sub-objeto efectivamente muere con el objeto ms grande. Estas propiedades del lenguaje tambin permiten la segunda parte de la regla: un objeto compositor no puede ser parte de dos objetos al mismo tiempo. Debido a que si los objetos compuestos son separados no se tiene un recolector de basura en C++, entonces el objeto compuesto puede querer eliminar al objeto compositor cuando el compuesto mismo es eliminado, lo que refuerza el peligro de compartir. Por propsitos de diseo, la composicin es tambin til cuando se desea agregar comportamiento a un objeto escondiendo el objeto delegado dentro, en lugar de heredarlo de otra clase. La agregacin es otro tipo de asociacin que se la puede ver en la Figura 6. Agregacin dbil una instancia de una clase est hecha de instancias de otra clase.
Figura 6. Asociacin Agregacin Una clase de asociacin es la denominada O que significa que solo una de las varias asociaciones potenciales pueden ser instanciadas en cada momento para cualquier objeto, como se puede ver en la Figura 7.
Figura 7. Asociacin tipo O
335
Otro tipo de asociacin es de generalizacin especializacin. Es la relacin taxonmica entre un elemento ms general y un elemento ms especfico. Es usado para clases, casos de uso y otros elementos. Una subclase hereda todos los atributos y el comportamiento de su(s) superclase(s). La Herencia es un tipo diferente de relacin que las otras tres: la herencia describe una relacin entre clases en tiempo de compilacin mientras que las otras describen una conexin entre los objetos en tiempo de ejecucin. De acuerdo al estndar UML, todas las relaciones en tiempo de ejecucin vienen bajo el trmino asociacin. Escoger entre las relaciones puede ser difcil, se necesita usar la intuicin, experiencia y deduccin. Durante el anlisis, se debe esperar que la frecuencia de estas relaciones sea: Asociacin > agregacin> herencia> composicin. Se puede ver un ejemplo de Generalizacin en la Figura 8.
Persona
Funcionario
Docente
Estudiante
Figura 8. Ejemplo de Generalizacin Luego de ver un poco de teora se continuar, ahora el ejemplo. Para adicionar los atributos se debe realizar doble clic en la clase, esta actividad mostrar una pantalla con el nombre de Class Specification, de la cual se debe seleccionar la pestaa Attributes. Como se puede ver en la Pantalla 5, dentro de esta pestaa adicionaremos los atributos de la clase orden de servicio.
Pantalla 5. Adicionar Atributos Para adicionar un atributo solo se debe presionar la tecla Insertar o Insert, lo cual adicionar un nuevo atributo. A este nuevo atributo se le debe cambiar de nombre, solo se debe hacer doble clic sobre este, 336
lo cual permitir ver una nueva ventana con el nombre de Class Attribute Specification, como se puede ver en la Pantalla 6.
Pantalla 6. Crear atributo Dentro de esta pantalla se pude ver un marco con el nombre de Export Control, el cual permite definir el tipo de atributo, ya sea Public (Pblico, se podr acceder sin un mtodo get y set), Protected (que solo se utilizar dentro de la clase), Private (que solo se tendr acceso a este por medio de get y set) y Implementation (La operacin es visible solamente dentro de la clase misma). Para este atributo se utilizar Private. Adicionalmente, se debe definir el tipo de dato el cual ser DateTime. El resultado de esta actividad se puede ver en la Pantalla 7.
337
Pantalla 7. Definir un Atributo De la misma forma se de definir los otros atributos de la Clase Orden de servicio, el resultado final se puede ver en la Pantalla 8.
Pantalla 8. Resultado final de la definicin de los atributos de OrdenServicio De la misma forma de puede definir los atributos para la Clase Cliente, el resultado de esta actividad se puede ver en la Pantalla 9.
Pantalla 9. Resultado final de la definicin de los atributos de la Clase Cliente. El siguiente paso es definir si existen asociaciones de Agregacin, Composicin y de Generalizacin. Estas operaciones se han descrito en anteriores documentos. Para finalizar se debe determinar el nombre de las asociaciones que participan en el diagrama de clases. El resultado final se puede ver en la Pantalla 10.
338

Comida
(from Entidades)
OrdenServicio 1..* est 0..*

(from Entidades)
Bebida
(from Entidades)
- Nombre : string - Identificador : int - Descripcion : string
- FechaOrden : DateTime - MontoPago : float - MontoTotal : float
est 0..* 1..*
- Identificador : int - NombreBebida : string - Caracteristicas : string - CantidadDisponible : int
0..* registra 1 Cliente

(from Entidades)
- Nombre : string - ApellidoPaterno : string - ApellidoMaterno : string - Direccion : string - CarnetIdentidad : string - LugarOrigen : string - LugarDestino : string - Pasaporte : string - Nacionalidad : string
Pantalla 10. Diagrama de clases del subsistema de Cocina Es bueno desarrollar diagramas de clases en perfecta notacin UML. Es de la misma manera bueno poder encontrar buenos objetos, atributos y relaciones. El punto de partida para desarrollar un diagrama de clases, como se ha dicho anteriormente, es utilizar la descripcin de los casos de uso. Detrs de esto, vendr un arduo anlisis y la experiencia. Expertos del dominio del negocio (Clientes y colegas) pueden ayudar en este punto, ellos puedan ser invitados a comentar el modelo de clases. Usar iteraciones tambin puede ayudar. El nombre un una clase no debe ir en plural ya que representa un solo objeto en un tiempo determinado. Algunas veces se presenta la duda, al momento de determinar un objeto, si es o no debe ser, los objetos deben ser sencillos y si se piensa en un posible objeto es mejor escribir el nombre en un papel ya que es muy probable que sea un objeto. Otro truco, si no puede encontrarse los objetos correctos en los casos de uso, es hablar con personas en el rea, pero independientes, acerca del negocio o de la aplicacin en cuestin. Esta persona debe registrar todo lo que se mencione que le parezca un concepto importante, exactamente de la misma manera que si se estuvieran tomando notas de lectura. Algunos ejemplos de diagramas de Clases
339
Diagrama de clases para Inventario de Computadoras
Diagrama de Clases de Inventario 340

Diagrama de Clases de Inscripciones
Diagrama de Clases de Reservar Pasaje 341

CAPITULO IV
IMPLEMENTACIN
342
ESTNDARES DE IMPLEMENTACIN El primer paso para iniciar la implementacin es definir un conjunto de estndar, que formaran parte de las reglas que se establecen para el desarrollo de software, cada grupo de desarrollo, persona o institucin debe definir un conjunto de estndares. Estos estndares permitirn a los Programadores entender el cdigo y sobre todo entenderse. Es muy importante que estos programadores cumplan al 100% el estndar planificado por los diseadores y jefes de implementacin. Para la metodologa XP, es extrema importancia y cumplimiento de un estndar de programacin. La descripcin del documento de Estndares de Implementacin debe ser discutido por varios roles dentro del desarrollo de software. El ms importante de los roles que deben participar en la reunin de definicin de estndares es el Arquitecto de la Aplicacin, luego est el diseador, el jefe de implementacin y un representante del grupo de calidad. Cada uno de estos dar su visin de la aplicacin y como ser implementada. En este documento se definir un conjunto de estndares, puede que el grupo de desarrollo decida incluir otros tipos de estndares. Este documento servir como una propuesta para cualquier grupo de desarrollo que este implementando con .NET y el lenguaje de programacin C#. Este documento de estndares es iterativo incremental, esto implica que existir de una a muchas reuniones para determinar el conjunto de estndares de implementacin. Controles de Usuario Web: Los controles que se describen a continuacin pertenecen la interfaz de usuario, representarn a los componentes prefabricados que ofrece Visual Studio .NET, en la plataforma de desarrollo Web. Para: - TextBoxt: TXT_Nombre - Label: LBLNombre (Para etiquedas) - Label: LBLMensajeX (Para mensajes en los formularios, X ser un nmero) - Button: BTNNombre - ImageButton: IBTNombre - LinkButton: LKBNombre - DropDownList: DDLNombre - ListBox: LBXNombre - CheckBox: CKBNombre - RadioButton: RBTNombre - Panel: PNLNombre - GridView: GVWNombre - TreeView: TVWNombre Componentes AJAX - AJXYYYNombre: Donde YYY son las primeras letras del nombre de tipo de componente. El Nombre descrito en cada componente debe ir expresar el tipo de informacin se quiere capturar o mostrar. Clases Internas de tipo de datos Estas clases internas se utilizarn dentro de una solicitud o evento. Para el rpido reconocimiento del tipo de clase dentro de los eventos se debe utilizar el siguiente estndar. DataRow: row_Nombre 343
DataTable: t_Nombre DataSet tipeado: DTONombre DataSet no tipeado: DSTNombre Cada una de estas variables, excepto DataRow, se debe instanciar para su utilizacin. Si existen otros tipos de variables debe seguir el patrn de las descritas. Variables normales: Las variables tambin deben llevar un estndar establecido por el grupo de desarrollo, en este caso se muestra algunas de las variables las cuales pertenecen a un tipo de dato dentro del lenguaje de C#. string: str_nombre int: int_nombre boolean: b_nombre Double: dou_nombre Aplicaciones WEB Al momento de crear una aplicacin Web se debe tomar en cuenta las siguientes caractersticas: - Nombre de la Aplicacin: NombreDepartamento _NombreSubsistema - Control: En esta carpeta van todas las clases controladoras de formularios o CIUNombre (CIU quiere decir controladora de Interfaz de usuario). - WebForm: Aqu deben ir todas las clases WebForm de la aplicacin. Estas tendrn una extensin .aspx o PNombre (P quiere decir pgina) - ControlesUsuario: En esta carpeta van todas las clases de controles de usuario. Estas tendrn una extensin de .ascx o CUNombre (CU quiere decir Control de Usuario) - Reutilizables: Aqu van todos los Typed DataSet que se crean especialmente para la aplicacin. Generalmente se crean estos para los reportes dentro de la aplicacin. - MasterPage: Aqu van todas las clases que se crean especialmente para heredar sus propiedades hacia los WebForm. Estas clases tendrn una extensin .master o MPNombre (MP quiere decir Master Page o Pgina Principal) - Cuando se adicione el Web Service a la aplicacin el nombre de la referencia debe ponerse WSNombre (Donde WS quiere decir WebService). Estas caractersticas tienen que ser similares al Marco de Trabajo que se ha definido en la Arquitectura de Software. Control, WebForm y los otros, sern carpetas para colocar las diferentes clases. Debe notarse que cada una de las clases que conforman la aplicacin tienen responsabilidades las cual no debe ser diferente, es decir, por ejemplo, que una clase formulario no puede ser una clase control. La Figura 1, que se muestra a continuacin, pertenece a la Arquitectura y es el Marco de Trabajo definido para la aplicacin.
344
Figura 1. Marco de Trabajo de la Aplicacin Servicios WEB Al momento de crear un Servicio Web se debe tomar las siguientes caractersticas: - Nombre del Servicio Web: WSNombreSubsistema (donde SW quiere decir ServicioWeb). Estas clases tendrn una extensin .asmx. - Reutilizables: En esta carpeta estarn todos los DTO que se diseen. Estas clases llevarn la extensin .xsd o DTONombre (DTO quiere decir Data Tranfer Object o Objeto de Trasferencias de Datos) - Controladoras: En esta carpeta estarn las clases control, las cuales se comunicarn con el SQLHelper o con los Agentes de Servicio. Estas clases tendrn una extensin .cs que pertenece a la una clases en el lenguaje C#. o CNombre (C quiere decir Controladora) - Entidades: En esta carpeta irn todas las clases entidades que salieron de la etapa de anlisis y diseo y que sean persistentes. Estas clases se usarn, por ejemplo, para identificar los datos propios de la entidad al momento de capturar o mostrar en la aplicacin web. Estas clases deben estar serializadas para transportarlas por el servicio web y que la aplicacin las pueda utilizar. Estas clases tendrn una extensin .cs que pertenece a la una clases en el lenguaje C#. - AgentesServicio: En esta carpeta estarn las clases que van a interactuar con servicios web externos. Esto es para encapsular al servicio web. Estas clases tendrn una extensin .cs que pertenece a la una clases en el lenguaje C#. o ASNombre (AS quiere decir Agente de Servicio) SQLHelper ser una referencia que se incluya al servicio Web. Archivo Web.Config (Para Web Services o Aplicaciones Web ) : La configuracin local de los servicios web empleando el fichero de configuracin web.config posee gran cantidad de parmetros. Se vern a continuacin algunas de las caractersticas. 345
En el archivo web.config, cuya estructura es la de un fichero XML, se agrega tags como por ejemplo <appSettings> y </appSettings> para delimitar la definicin de los parmetros. En esta regin se guardar la siguiente informacin: Nombre genrico de servicios web utilizados. Cadena de conexin a la base de datos del servicio web Nombre de procedimientos almacenados usados por el SW Constantes inherentes al SW como pueden ser cantidad de reintentos de una operacin.
No confundir las definiciones de estas constantes con los valores a ser almacenados en la configuracin general del sistema. Aqu solo se almacena aquello que afecta directamente el desempeo fsico del SW. Ejemplo de web.config <?xml version="1.0" encoding="utf-8"?> <configuration> <appSettings> <add key="CODWS" value="CODIGO DEL SERVICIO WEB" /> <add key="WSGNAME" value="NOMBRE GENERICO DEL SERVICIO WEB" /> <connectionStrings> <add name="CCImpresionesConnectionString" connectionString="Data Source=angerona;Initial Catalog=CCImpresiones;User ID=sa;password=lafuente" providerName="System.Data.SqlClient"/> </connectionStrings>  <add key="AdicionarCliente" value="PAICliente" /> <!Procedimiento Almacenado --> </configuration> Ya sea una aplicacin web o un servicio web deben llevar comentarios que expliquen la responsabilidad de un evento o el objetivo de la sentencia dentro de un evento. Dentro de cada clase: Un resumen del para qu es la clase Un comentario por cada mtodo Si el mtodo es muy complejo comentar las partes.
346
IMPLEMENTACIN DE LA CAPA DE PRESENTACIN Se inicia en este documento la etapa de implementacin de la aplicacin, esta implementacin est en funcin de la arquitectura y de la descripcin de las realizaciones de diseo. Esta ltima est representada por medio de los diagramas de secuencia. En este documento se implementar la realizacin de Autenticar, para ejemplificar como se deben crear las clases en cada una de las carpetas y adems cumpliendo con el estndar de implementacin. Para iniciar se presenta a manera de recordar la descripcin del caso de uso de autenticar, Mapa de Navegacin, realizaciones de diseo, diagrama de clases web y los diagramas de secuencia. DESCRIPCIN DEL CASO DE USO AUTENTICAR. Caso de Uso Autenticar Empleado Actores Resumen Empleado (Jefe de Cocina, Recepcionista) El caso de uso se inicia cuando el Empleado quiere ingresar a la aplicacin, para esto debe introducir su cuenta y contrasea de acceso a una interfaz que le proporciona la aplicacin. Verificar si el actor tiene autorizacin para ingresar al manejo de la aplicacin.
Descripcin Accin del Actor(es) Pantalla 1

Autenticar Empleado
Nombre de Cuenta
Escriba texto
Respuesta del Sistema
A B
Contrasea
1. El caso de uso se inicia cuando el Empleado necesita ingresar a la aplicacin 2. Presenta una interfaz (Pantalla 1), en la cual debe ingresar el Empleado el Nombre de Cuenta (A) y la Contrasea (B) 3. Ingresa el Nombre de Cuenta (A) y la Contrasea (B) 4. Realiza un clic en el botn Autenticar (C) 5. Valida internamente comparando el 347
Nombre de Cuenta y la Contrasea 6. Direcciona al men principal de la aplicacin para los Empleados Cursos Alternos Paso 5. Si la validacin es incorrecta la aplicacin presenta un mensaje de texto (D) con las siguientes palabras El Nombre de Cuenta o la Contrasea es Incorrecta Paso 5. Si la validacin del Nombre de cuenta no coincide con seis caracteres al inicio ms dos nmeros, la aplicacin debe presentar un mensaje de texto con las siguientes palabras Verifique el Nombre de Cuenta (seis caracteres ms dos nmeros) Requisitos no Funcionales Seguridad. El Nombre de Cuenta debe contener un total de 8 caracteres, los seis primeros deben ser letras, los dos ltimos nmeros. La contrasea, luego de realizar un clic en el botn de Autenticar (C) debe aplicarse, sobre esta, un algoritmo de cifrado, para lograr una ptima integridad Facilidad de Uso Los mensajes relacionados a la utilizacin de la interfaz deben ser legibles, explicativos y de un color llamativo, para lograr un corto tiempo de aprendizaje en la utilizacin de la interfaz y una ptima comprensin. El Empleado tendr una autorizacin para la utilizacin de la aplicacin
Postcondiciones
MAPA DE NAVEGACIN AUTENTICAR
DIAGRAMA DE REALIZACIONES DE DISEO DE AUTENTICAR
348
Autenticar
(from Autenticar Empleado)
<<realize>>
RD Autenticar
DIAGRAMA DE CLASES WEB
DIAGRAMA DE SECUENCIA
349
: Empleado
: PAutenticar PageLoad( )
: C_Autenticar
: CIUAutenticar
: SWSeguridad
: CSW_Seguridad
: DTOEmpleado
: SQLHelper
CUIAutenticar( ) Autentcar(Cuenta, Contrasena) Autenticar(Cuenta, Contrasena) CifrarContrasena(Contrasena)
Autenicar(Cuenta, ContrasenaCifrada) Autenticar(Cuenta, ContrasenaCifrada) DTOEmpleado( )
FillDataset(Cadena, TipoComando, PANombre, dto, arrayTablas) AutenticarEmpleado(dtoEmpleado, Cuenta, ContrasnaCifrada)
Se debe tomar en cuenta estas descripciones para la implementacin. Se aprecia que desde la descripcin del caso de uso hasta el diagrama de secuencia, la existencia de una traduccin de un lenguaje del usuario a un lenguaje del programador. Se inicia implementar la capa de presentacin. Ya estando en el Visual Studio 2005, se puede crear una aplicacin Web, para esto se debe hacer un clic en la opcin del men principal Archivo, luego Nuevo y Sitio Web como se puede ver en la Pantalla 1.
Pantalla 1. Crear una aplicacin Web Esta actividad mostrar una ventana, la cual se pude ver en la Pantalla 2. 350
Pantalla 2. Definir el tipo de Aplicacin Web Dentro de la Pantalla 2 se pude ver un tipo de proyecto con el nombre de ASP.NET AJAX-Enabled Web Site, este tipo de proyecto permite construir aplicaciones con la tecnologa AJAX (acrnimo de Asynchronous Java Script and XML en ingls Java Script y XML asncronos). Esta tecnologa ha permitido mejorar en gran medida la interfaz Web. Para utilizar AJAX en aplicaciones futuras se debe instalar la Extensin AJAX para ASP.NET (dentro de directorio del Captulo IV se encuentra esta extensin con el nombre de ASPAJAXExtSetup.rar), una vez instada la extensin se debe realizar la actividad descrita para la Pantalla 1, debe visualizarse la opcin marcada en al Pantalla 2. Para ms informacin sobre AJAX para ASP.NET se puede visitar http://www.asp.net/ajax/. En este curso no se estudiarn los componentes incluidos en Ajax Control Tool Kit, los cuales son componentes gratuitos ofrecidos por Microsoft. Siguiendo el estndar definido en el anterior documento, el nombre de la aplicacin Web a crear ser Seguridad como se puede ver en la Pantalla 3.
351
Pantalla 3. Crear la Aplicacin Web para el Subsistema Seguridad Una vez introducido el nombre y seleccionar el lenguaje de desarrollo se debe realizar un clic en el botn Aceptar. Esta actividad permitir crear la aplicacin web. La Pantalla 4 muestra la estructura del entorno de desarrollo para la nueva aplicacin.
352
Pantalla 4. Entorno de Desarrollo de la Aplicacin Como se puede observar en la Pantalla 4, existe en la parte superior izquierda del formulario un componente con el nombre de ScriptManager, este componente permite utilizar cualquier componte de AJAX para ASP.NET. Los componentes necesitan de este componente para visualizar sus funcionalidades en la interfaz. Adicionalmente, se tiene la ventana Explorador de Soluciones ubicada en la parte superior derecha y bajo de esta, est la ventana de Propiedades, esta ltima visualizar las caractersticas y los eventos posibles para cada componente que est seleccionado. El primer paso es crear las carpetas que alojarn a las distintas clases diseadas en la etapa de diseo. Para crear una carpeta se debe realizar un clic derecho sobre del nombre de la aplicacin, en este caso Seguridad, de inmediato se visualizar varias opciones de las cuales se debe seleccionar Nueva Carpeta, como se puede ver en la Pantalla 5.
Pantalla 5. Crear una Carpeta Una vez hecha la actividad se debe cambiar el nombre a la nueva carpeta, este nombre debe ser igual al marco de trabajo que se ha definido en el documento de la Arquitectura. La creacin de las carpetas est en funcin del Marco de Trabajo definido en el documento de Definicin de la Arquitectura de la Aplicacin. Este Marco de Trabajo se puede visualizar en la Figura 1.
353
Figura 1. Marco de Trabajo Las cuatro carpetas que se visualizan en la capa de User Services deben estar presentes en al aplicacin Web como se puede ver en la Pantalla 6.
Pantalla 6. Subcapas de User Services Existen otras carpetas que se deben crear que no pertenecen a la capa de presentacin, estas son: - Imgenes. Permitir almacenar las imgenes necesarias para la vistosidad de la aplicacin. - Estilos. Permitir almacenar archivos de tipo CSS, hojas de estilo para la configuracin de las pginas web que se utilicen en la interfaz. Pueden existir otras como Scripts o componentes COM, API, Active X, entre otros. En esta aplicacin no se utilizar ninguna de estas. Adicionalmente se debe activar la carpeta de App_Code, carpeta por defecto del ASP.NET, para activar esta carpeta se debe realizar un clic derecho en el nombre de la aplicacin y seleccionar las opciones de Agregar capetas ASP.NET y App_Code como se puede ver en la Pantalla 7.
354
Pantalla 7. Agregar la Carpeta App_Code La carpeta de ControlInterfaz debe estar ubicada en la carpeta de App_Code, ya que sern clases que controlarn el comportamiento de la interfaz. El resultado final de la configuracin de las carpetas definidas en Marco de Trabajo se puede ver en la Pantalla 8.
Pantalla 8. Carpetas configuradas de la capa de presentacin Ahora se crear una pgina web con las caractersticas de MasterPage, la cual ser la que nos defina el estilo de diseo para las otras pginas. Se debe realizar un clic derecho sobre la carpeta MasterPage, seleccionar la opcin de Agregar nuevo elemento. Como se puede ver en la Pantalla 9. 355
Pantalla 9. Crear un nuevo elemento para la aplicacin Esta actividad har visualizar una ventana, en la cual se debe seleccionar, entre las muchas opciones, Pgina Principal, esta actividad har que en la parte inferior de la ventana aparezca el nombre de MasterPage.master, el cual se debe cambiar a MPSeguridad.master, no debe olvidarse que se tiene un conjunto de estndares para la implementacin y el Marco de Trabajo. Esto se puede ver en la Pantalla 10.
Pantalla 10. Crear una Pgina Principal 356

Una vez introducido el nombre se debe verificar el lenguaje de implementacin que en este caso es C# y luego realizar un clic en el botn Agregar ubicado en la parte inferior derecha. El resultado de esta actividad se puede ver en la Pantalla 11.
Pantalla 11. Pgina Principal creada Como se puede ver en la Pantalla 11 se ha creado un nuevo formulario el cual contiene un componente con el nombre de ContentPlaceHolder, este componente permitir contener a todas las pginas (Clases) de tipo aspx que hereden sus caractersticas. A esta pgina principal se debe adicionar el componente AJAX ScriptManager, para que todas las pginas creadas puedan utilizar los componentes AJAX. Adicionalmente se debe eliminar la pgina con el nombre de Defauld.aspx, para luego crear otra, ya que esta no servir en la aplicacin que se desarrolla. Para adicionar el ScriptManager, se debe visualizar el cuadro de herramientas, si est correctamente instalada la extensin AJAX para ASP.NET, se podr ver la papeleta de componentes con el nombre de AJAX Extensions, de esta papeleta se debe seleccionar el componente con el nombre de ScriptManager, como se puede ver en la Pantalla 12.
357
Pantalla 12. Componentes bsicos de AJAX ASP.NET Un punto importante es que el componente debe estar antes del ContentPlaceHolder, ya que lo contrario no permitir el trabajo correcto de los componentes AJAX. La otra papeleta, con el nombre de MS Ajax contiene a los componentes adicionales que ofrece Microsoft. Dentro del curso en los documentos del Capitulo IV estn los archivos para instalar estos componentes. El archivo con el nombre de AJAXDLLs.rar contiene las libreras de todos los componentes AJAX Control Tool Kit. El archivo con el nombre de AjaxControlToolkit.zip contiene ejemplos de manejo y configuracin de cada uno de los componentes. Adicionalmente, en el sitio de AJAX de Microsoft se tiene un conjunto de videos que explican el funcionamiento y la configuracin de cada uno de los componentes inmersos en el AJAX Control Tool Kit. Se da ms explicacin sobre los componentes de AJAX de ASP.NET en esta direccin: http://www.asp.net/learn/videos/. La utilizacin de estos componentes debe describirse en la modelacin, por lo menos en el Diagrama de Clases Web, para el conocimiento de los desarrolladores, se puede considerar a cada uno de estos componentes como clases de tipo .js. Como se puede ver en la Pantalla 13.
358
Pantalla 13. Descripcin de la Utilizacin de ScripManager Como se puede observar se ha modificado el Diagrama de Clases Web para la realizacin de diseo RD Autenticar. Una vez seleccionado el ScriptManager solo se debe arrastrar al inicio del formulario PMSeguridad, como se puede ver en la Pantalla 14.
359
Pantalla 14. Utilizacin del ScriptManager Ahora se debe crear una pgina web con la extensin de aspx, para esto se debe realizar un clic derecho la carpeta de WebForm y seleccionar la opcin de Agregar nuevo elemento. Como se puede ver en la Pantalla 15.
360
Pantalla 15. Agregar nuevo elemento. Esta actividad permitir visualizar una nueva ventana, de la cual se debe seleccionar Web Forms, adicionalmente se debe activar la opcin de Seleccionar la pgina Principal ubicada en al parte inferior cerca el botn Agregar. Como se puede ver en la Pantalla 16.
361
Pantalla 16. Crear una Pgina Web Como se puede ver en la Pantalla 16, se ha introducido el nombre de PAutenticar para esta nueva Pgina Web, este nombre debe ser igual al descrito en el Mapa de Navegacin para el subsistema de Autenticar, la primera pgina tiene el nombre de PInicio, esta no ser tomada en cuenta ya que en el Diagrama de Clase Web la que inicia la interaccin con el usuario es PAutenticar. Una vez introducido el nombre se debe realizar un clic en el botn Agregar. Como se ha activado la opcin de Seleccionar la pgina principal, se visualizar una nueva ventana que se la puede ver en la Pantalla 17.
Pantalla 17. Seleccionar una Pgina principal Como se puede ver en la Pantalla 17, se debe seleccionar a MPSeguridad.master ya que es la pgina principal creada anteriormente. Una vez seleccionada se debe realizar un clic en el botn de Aceptar, de este modo se crear una nueva pgina web con las caractersticas de la pgina principal, el resultado de esta actividad se puede ver en la Pantalla 18.
362
Pantalla 18. Creacin de una pgina web con el nombre de PAutenicar Como se puede ver en la Pantalla 18, en segundo plano est el componente AJAX con el nombre de ScriptManager, esto asegura que se puede utilizar los componentes AJAX. Por otro lado, se encuentra un nuevo componente con el nombre de Content, el cual permitir contener los distintos componentes de ASP.NET. Ahora se crear un archivo de estilo tipo CSS, para esto se debe realizar un clic derecho sobre la carpeta Estilo y seleccionar la opcin de Agregar un nuevo elemento. Una vez que se visualice la ventana que se ven en la Pantalla 19, se debe seleccionar el tipo de archivo con el nombre de Hoja de Estilos. El nombre del archivo ser ESTSeguridad.css.
363
Pantalla 19. Crear un Archivo de Estilo Este archivo permitir configurar la interfaz, ya sea un control de usuario TextBox, un Label o incluso un GridView. Para finalizar la creacin se debe realizar un clic en el botn Agregar. El resultado se puede ver en la Pantalla 20.
364
Pantalla 20. Archivo Estilo tipo CSS A continuacin se presenta la estructura del archivo css, para el diseo de la interfaz. BODY { background-color: #dfdbdb; color: black; font-family: Tahoma; background-attachment: fixed; background-repeat: repeat-x; } .Titulo { font-size: 18px; color: gray; font-family: Tahoma; font-weight: bold; font-style: normal; font-variant: normal; } .Texto { font-weight: bold; font-size: 9pt; color: black; font-family: Tahoma; } .Datos { font-weight: bold; font-size: 10pt; color: black; font-family: Tahoma; } .LabelDato { font-size: 10pt; color: black; font-family: Tahoma; } .Boton { background-position: center; background-repeat: repeat-x; border-top-style: none; border-right-style: none; border-left-style: none; 365
border-bottom-style: none; font-size: 10pt; background-attachment: scroll; font-family: Tahoma; background-color: silver; } .GRVDatos { font-size: 8pt; font-family: Tahoma; color: black; } .MensajeError { color: #ff0033; font-family: Tahoma; font-size: 12px; font-variant: small-caps; } .MensajeAyuda { color: #009933; font-size: 8pt; font-family: Tahoma; text-transform: uppercase; } .Titulo2 { font-size: 15px; color: black; font-family: Tahoma; font-weight: bold; font-style: normal; font-variant: small-caps; } .Titulo3 { font-size: 14px; color: gray; font-family: Tahoma; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: underline; } 366
Para agregar una nueva regla de estilo solo se debe realizar un clic derecho en la plantilla de estilos, lo cual desplegar varias opciones, de las cuales se debe seleccionar Agregar regla de estilo. Como se puede ver en la Pantalla 21.
Pantalla 21. Crear una regla de estilo. El resultado de estas actividades se puede ver en la Pantalla 22.
Pantalla 22. Archivo de estilo configurado
367
Para utilizar el archivo de estilo se debe realizar doble clic sobre la pgina principal MPSeguridad, una vez visualizada el formulario solo resta arrastrar el archivo .css hasta el formulario, esta operacin har incluir los estilos definidos en la pgina principal. El resultado se puede ver en la Pantalla 23.
Pantalla 23. Aplicacin del archivo .css a la pgina principal. Para confirmar que la pgina principal tiene registrado el archivo estilo se puede realizar un clic en el botn Cdigo, ubicado en el parte inferior izquierda, al lado del botn Diseo. Se puede ver en la Pantalla 24, la lnea nmero 8 con la referencia de ubicacin el archivo de estilo, de esta forma se confirma que est incluido el archivo .css.
368
Pantalla 24. Verificacin de la referencia al archivo .css Ahora, que se ha configurado en gran parte la interfaz de usuario es momento de iniciar el desarrollo de las solicitudes que participan en la interaccin con el usuario. El primer paso es estudiar la descripcin del caso de uso a implementar, en este caso solo se debe realizar una interfaz con dos datos a enviar por la aplicacin, que son Nombre de Cuenta y Contrasea, este detalle se puede ver en el tercer paso de la descripcin del caso de uso. Se crear un control de usuario que permita disear la interfaz prototipo. Para esto se debe realizar un clic derecho en la carpeta ControlesUsuario, ubicada en el Explorador de Soluciones. La opcin que se debe seleccionar es Adicionar un Nuevo Elemento. Una vez visualizada la Pantalla 25, se debe seleccionar la opcin Control de Usuario Web. El nombre de este nuevo control de usuario debe ser el mismo de se describe en el Diagrama de Clases Web y en el Diagrama de Secuencia, en este caso debe ser C_Autenticar.
369
Pantalla 25. Crear un Control de Usuario Hecha esta actividad solo queda realizar un clic en el botn Agregar, el resultado de estas actividades se puede ver en la Pantalla 26.
Pantalla 26. Resultado de la creacin de un Control de Usuario Si se realizar doble clic sobre el control C_Autenticar se abrir un formulario en la parte izquierda a la ventana de Explorador de Soluciones. Este formulario servir para desarrollar la interfaz. El primer paso para iniciar el desarrollo de la interfaz es insertar una tabla de 9 filas y 1 columna. Para esto se debe realizar un clic en la opcin Diseo, del men principal, luego a la opcin de Insertar Tabla, como se puede ver en la Pantalla 27.
370
Pantalla 27. Crear una Tabla Esta opcin dar lugar a una ventana con el nombre de insertar tabla, la cual se puede ver en la Pantalla 28.
Pantalla 28. Definir Columnas y Filas Luego de definir el nmero de columnas y de filas se debe realizar un clic en el botn Aceptar, de inmediato, dentro del formulario aparecer una tabla con las caractersticas sealadas como se puede ver en la Pantalla 29.
371
Pantalla 29. Tabla Insertada para el diseo de la interfaz Ahora se debe arrastrar varios componentes desde el cuadro de herramientas. Se necesita cuatro componentes de tipo Label, dos de tipo TextBox y uno de tipo Button. El resultado de esta actividad se puede ver en la Pantalla 30.
Pantalla 30. Componentes para la Interfaz Ahora, se debe dar formato a cada uno de componentes. Para el primer componente Label que est insertado en la interfaz, en su propiedad de Text se debe introducir el siguiente texto Autenticar Empleado, adicionalmente a la propiedad CssClass se le debe asignar la clase definida en el archivo de tipo css con el nombre de Ttulo y la pro piedad ID debe cambiarse a LBLPantalla. Para el segundo Label se debe cambiar la propiedad Text a Nombre de Cuenta y el ID a LBLCuenta, para el tercer Label la propiedad Label ser Contrasea y el ID ser LBLContrasea, para el ltimo Label se cambiar la 372
propiedad Text y el ID, la propiedad Text no contendr ninguna letra, para la otra propiedad ser LBLMensaje1. El nombre de cada uno de los componentes esta en funcin del estndar de implementacin definido en el anterior documento. El resultado de estas actividades se puede ver en la Pantalla 31.
Pantalla 31. Configurando los Label Para cada uno de los TextBox, la propiedad de CssClass tendr la clase css con el nombre de Datos, para el primer componente TextBox el ID cambiar a TXT_Cuenta y para el segundo ser TXT_Contrasena. La Pantalla 32 muestra las propiedades que deben cambiarse.
Pantalla 32. Propiedades que deben ser cambiadas para los TextBox Por ltimo se debe cambiar las propiedades del botn con el nombre de Text y ID, la primera tendr el valor de Autenticar y el segundo de BTNAutenticar. El resultado de la definicin de la interfaz se puede ver en la Pantalla 33.
373
Pantalla 33. Interfaz definida para Autenticar. Dentro de la descripcin del diagrama de secuencia para la realizacin de diseo de autenticar se puede ver que el Empleado por medio de una solicitud con el nombre de Autenticar enva la Cuenta y Contrasea hacia la Clase C_Autenticar. Esta solicitud est representada por el evento del botn BTNAutenticar, el cual solicitar a la clase CIUAutenticar autenticar al empleado. Para definir estas solicitudes dentro de la aplicacin el primer paso es crear la Clase CIUAutenticar. Para esto se debe realizar un clic derecho cobre la carpeta con el nombre de ControlInterfaz ubicada en la Carpeta App_Code dentro del Explorador de Soluciones, esta actividad mostrar varias opciones que se pueden ver en la Pantalla 34, de las cuales se debe seleccionar la opcin Agregar Nuevo Elemento.
Pantalla 34. Crear una clase Controladora de Interfaz Esta ltima actividad mostrar una ventana con el nombre de Agregar Nueva elemento, la cual mostrar varias opciones, de las cuales se debe seleccionar Clase, como se puede ver en la Pantalla 35, adicionalmente se debe cambiar el nombre de la Clase a CIUAutenticar. Se debe tener cuidado con definir el lenguaje de programacin.
374
Pantalla 35. Crear una Clase de tipo cs para el control de la interfaz Esta clase ser un puente entre el Servicio Web y la aplicacin Web, tendr la responsabilidad de la comunicacin con el servicio web. Se puede ver en la Figura 2 los mtodos que deben ser implementados en esta clase.
Figura 2. Vista de la Clase CIUAutenticar Una vez que se ha hecho un clic en el botn de aceptar de la Pantalla 35, aparecer una nueva plantilla con la estructura de una clase, como se puede ver en la Pantalla 36.
375
Pantalla 36. Estructura de la Clase CIUAutenticar Ahora se crear los mtodos de CifrarContrasea y Autenticar. Estos mtodos pertenecen a esta clase, el primero servir para cifrar la contrasea, se utilizara para esto el algoritmo de encriptacin MD5. El mtodo autenticar servir para recibir la cuenta y la contrasea, dentro de este debe llamarse al mtodo de cifrar y adems al servicio web que ayudar a autenticar al empleado. Se puede ver en la Pantalla 37 la implementacin de estos mtodos.
376
Pantalla 37. Mtodos implementados de la Clase CIUAutenticar Dentro del mtodo de Autenticar existen varias lneas que no estn implementadas, estas se harn al momento de integrar las capas de la aplicacin. Ahora, se ver cmo utilizar los mtodos implementados anteriormente en la interfaz. El primer paso es crear una sesin, esto se hace por medio de una variable con el nombre de session, con la cual se puede recuperar datos en cualquier parte de la aplicacin, es decir en cualquier interfaz de usuario. Para mayor informacin sobre esta variable ver esta direccin http://msdn2.microsoft.com/eses/library/87069683(VS.80).aspx. Para configurar una sesin utilizaremos el mtodo Page_Load de la clase PAutenticar, esta clase est ubicada en la WebForm, como se puede ver en la Pantalla 38. Se debe realizar doble clic sobre esta clase, de inmediato se podr visualizar un formulario ya conocido, sin embargo, se necesita visualizar el mtodo de Page_Load, para visualizar este mtodo se debe presionar la tecla F7, el resultado se puede ver en la Pantalla 38.
377
Pantalla 38. Visualizacin del mtodo Page_Load de un clase tipo .aspx El cdigo que se presenta en la Pantalla 38, permite crear una sesin respecto a una clase definida, en este caso la clase es CIUAutenticar, la cual se ha determinado que es una controladora de interfaz. El primer paso es preguntar si es la primera vez que se interpreta la pagina Web, si fuera el caso se pregunta si la sesin con el nombre de Autenticar es nula, si es nula se crea una instancia de la clase CIUAutenticar con el nombre de MiAutenticar luego se iguala la sesin son la instancia de la clase CIUAutenticar. Con estos pasos aseguramos crear una sesin. Una vez creada la sesin se debe colocar cdigo en la clase con el nombre de C_Autenticar, la cual es un control de usuario, anteriormente se ha desarrollado la interfaz dentro de esta clase. Para poder visualizar la interfaz solo se debe realizar doble clic sobre la clase, de esta forma se puede ver la interfaz que se ha desarrollado, esto se muestra en la Pantalla 39.
378
Pantalla 39. Interfaz para Autenticarse Para poder colocar cdigo dentro del botn Autenticar se debe realizar doble clic sobre este, esto permitir visualizar el mtodo BTNAutenticar_Click, dentro de este se colocar el siguiente cdigo que se puede ver en la Pantalla 40.
Pantalla 40. Cdigo del botn Autenticar Las dos primeras lneas de cdigo permiten captar en variables de tipo cadena la cuenta y la contrasea que introducir el usuario. La ltima lnea es la que permite utilizar la instancia de la clase CIUAutenticar, que se ha descrito en la Pantalla 38. De esta forma podemos acceder a los diferentes mtodos de una clase controladora. 379
Para finalizar con el desarrollo se debe arrastrar el control de usuario hasta la hasta la pagina web de tipo aspx, dando como resultado la Pagina 41. Para realizar esta actividad, se debe estar visualizando el formulario de PAutenticar.
Pantalla 41. Control de Usuario en un aspx. Dentro de una aplicacin se puede utilizar cuantas veces sea necesario un control de usuario, e incluso dentro de un ascx, cada vez que se utilice el control de usuario se ir numerando para no confundirse con otros similares. En este caso se tiene un C_Autenticar1, este control tendr varios atributos, el ms utilizado es el Visible que por defecto esta en true, esto quiere decir que el componente se visualizar al momento de la ejecucin. De esta forma se ha terminado de desarrollar una pequea parte de la interfaz de usuario, la capa de presentacin. Esta capa como se ha podido estudiar est en funcin del diagrama de Secuencia descrito en la parte de diseo. No debe olvidarse que se necesita el servicio web para poner en ejecucin la aplicacin web.
380
IMPLEMENTACIN DE LA CAPA DE NEGOCIO Y DATOS En este documento se describir como implementar la Capa de Negocio y la de Acceso a los Datos. Como en el anterior documento la implementacin debe basarse en el diagrama de secuencia de las realizaciones de diseo. Para iniciar la implementacin se crear el servicio web con el nombre de Seguridad, como se puede ver en la Figura 1.
: Empleado : PAutenticar PageLoad( ) CUIAutenticar( ) Autentcar(Cuenta, Contrasena) Autenticar(Cuenta, Contrasena) CifrarContrasena(Contrasena) : C_Autenticar : SWSeguridad : CSW_Seguridad : DTOEmpleado : SQLHelper
: CIUAutenticar
Autenicar(Cuenta, ContrasenaCifrada) Autenticar(Cuenta, ContrasenaCifrada) DTOEmpleado( )
FillDataset(Cadena, TipoComando, PANombre, dto, arrayTablas) AutenticarEmpleado(dtoEmpleado, Cuenta, ContrasnaCifrada)
Figura 1. Diagrama de Secuencia de la Realizacin de Diseo Autenticar En el anterior documento se ha implementado solo la capa de presentacin, sin tomar en cuenta las otras capas. Las clases que participaron en el anterior documento son: - PAutenticar que es una clase Client Page. - C_Autenticar que es una clase html_form. - CIUAutenticar que es una clase Server Page. Con estas clases se ha implementado la capa de datos, adicionalmente cada clase se creado en una determinada carpeta definida en el marco de trabajo. Ahora bien, corresponde crear las carpetas de las otras capas definidas en el marco de trabajo. El primer paso es crear un servicio web, para luego crear el resto de las carpetas. Para crear el servicio web se debe hacer un clic en la opcin Archivo del men principal del Visual Studio, luego seleccionar la opcin Nuevo y Sitio Web, como se puede ver en la Pantalla 1.
381
Pantalla 1. Iniciar la creacin del Servicio Web Esta actividad har aparecer una nueva ventana de la cual se debe seleccionar la opcin de Servicio Web ASP.NET, como se puede ver en la Pantalla 2. Adicionalmente se debe verificar el lenguaje de programacin y seleccionar un directorio, el cual contendr todos los archivos que se creen para el servicio web.
Pantalla 2. Descripcin del Servicio Web WSSeguridad Como se puede observar en la Pantalla 2, se ha definido el Lenguaje de Programacion C# y se ha introducido el nombre del servicio web, este nombre debe ser igual a la clase que representa al servicio web dentro del diagrama de secuencia, adicionalmente se debe seguir el estndar de implementacin definido. Una vez realizado estos pasos se debe realizar un clic en el botn Aceptar, el resultado de estas actividades se puede ver en la Pantalla 3. 382
Pantalla 3. Entorno de Desarrollo para el Servicio Web de Seguridad El siguiente paso es crear las distintas carpetas que se han descrito en el marco de trabajo, para esto se debe hacer clic derecho sobre la carpeta de App_Code y seleccionar la opcin Nueva Carpeta, como se pude ver en la Pantalla 4.
Pantalla 4. Crear nueva carpeta. 383

Antes de dar el nombre a la carpeta se puede ver en la Figura 2, el marco de trabajo definido en el documento de la arquitectura.
Figura 2. Marco de trabajo de la Aplicacin de Ejemplo Como se puede observar en la Figura 2, el Servicio Web se comunicar con clases que corresponden a las controladoras, en este caso son controladoras del servicio web. El nombre de la nueva carpeta ser Controladoras. Adicionalmente se debe crear las otras carpetas que son: Entidades, Reutilizables y Agentes de Servicio, la carpeta de SQLHelper su creacin se explicara mas adelante. El resultado de esta actividad se puede ver en al Pantalla 5.
Pantalla 5. Carpetas del Marco de Trabajo Creadas Ahora se necesita crear una clase con el nombre de SWSeguridad, esta es la que permitir realizar contratos con la aplicacin web y la capa de negocio. Para esto se debe realizar un clic derecho en el nombre de la aplicacin, como se puede ver en la Pantalla 6 y seleccionar la opcin de Agregar Nuevo Elemento.
384
Pantalla 6. Crear una nueva clase Esta operacin har aparecer una nueva ventana de la cual se debe seleccionar las opciones de Servicio Web, adicionalmente se debe introducir el nombre de la clase, como se puede ver en la Pantalla 7.
Pantalla 7. Definir el nombre del Servicio Web Seguridad Lo que har esta actividad es crear dos archivos, uno con el tipo de .asmx, el cual permitir mostrar en un navegador los mtodos del servicio web y la otra un archivo de tipo .cs, que permitir determinar los mtodos del servicio web. Estas dos clases se pueden ver en la Pantalla 8.
385
Pantalla 8. Clases que se han creado para representar al Servicio Web de Seguridad Las clases con el nombre de Service se deben eliminar ya que no se utilizarn. El siguiente paso es crear una clase de tipo .cs dentro de la carpeta de Controladoras con el nombre de CSWSeguridad como describe la Figura 1, que es el diagrama de secuencia. Para esto se debe realizar clic derecho sobre la carpeta de Controladoras seleccionara la opcin de Agregar Nuevo Elemento. Esta actividad har aparecer un nueva ventana similar a la Pantalla 7, en la cual se debe seleccionara la opcin de Clase, para luego introducir el nombre de la clase que en este caso ser CSWSeguridad y por ltimo seleccionar el lenguaje de programacin. Una vez descrita la clase se debe realizar un clic en el botn de Aceptar, el resultado de este conjunto de actividades se puede ver en la Pantalla 9.
Pantalla 9. Creacin de una clase Controladora de Servicio Web Siguiendo con la especificacin del diagrama de secuencia para la realizacin de diseo de autenticar, se debe crear una clase con el nombre de DTOEmpleado. Esta clase debe ser creada en la carpeta de Reutilizables, para hacer esto se debe realizar clic derecho en al carpeta de Reutilizables y seleccionar la opcin de Agregar nuevo elemento, esto har aparecer una nueva ventana de la cual se debe seleccionar la opcin de DataSet, luego introducir el nombre y realizar un clic en el Botn de Aceptar, este tipo de archivo tendr una extensin .xsd. El resultado de este conjunto de actividades se puede ver en la Pantalla 10.
386
Pantalla 10. Crear un DataSet tipeado Este tipo de clase no es un DataSet, en la Figura 3 se puede ver la estructura de una DataSet que determina ADO.NET para este tipo e clase, en este momento no existe ninguna coleccin de tablas.
Figura 3. Estructura de un DataSet Un DataSet ser como un contenedor de datos, los cuales sern tomados de una base de datos, es un de los componentes importantes en toda la tecnologa .NET, no necesariamente contendr una sola tabla de una base de datos, sino de una a muchas e incluso se puede determinar entre estas relaciones de dependencia relacional, para determinar esto se debe utilizar la propiedad de RelationsColection. Se 387
debe aclarar que, no necesariamente debe ser una tabla de una base de datos, puede que el desarrollador necesite una estructura de almacenamiento temporal para su aplicacin, como por ejemplo, el clsico ejemplo del Carrito de Compras. Es muy importante estudiar las propiedades de este componente ya que permite solucionar muchos de los problemas complejos que se tuvieron en anteriores tecnologas, para mayor informacin de este tipo de clase se puede ver en esta direccin: http://msdn.microsoft.com/library/spa/default.asp?url=/library/SPA/cpref/html/frlrfsystemdatadataset memberstopic.asp En la Figura 4 se muestra la clase persistente de Empleado, la cual ha sido descrita en el diagrama de clases de diseo dentro del subsistema de Seguridad.
Figura 4. Clase Persistente Empleado La clase empleado se ha convertido en una tabla dentro de una base de datos, como se puede ver en la Pantalla 11, se ha utilizado el MS-SQL Server 2000 para su implementacin.
Pantalla 11. Implementacin de una tabla. Una vez creada la base de datos con sus respectivas clases y relaciones es relativamente fcil incluir a un DataSet la configuracin de una tabla de una base de datos. Para esto se debe realizar un clic en el Explorador de Servidores, para luego realizar un clic derecho en Conexiones de datos y seleccionar la opcin de Agregar conexin, como se puede ver en la Pantalla 12.
388
Pantalla 12. Crear una conexin a la base de datos Realizada l actividad anterior se visualizar la ventana con el nombre de Agregar conexin como se puede ver en la Pantalla 13. En esta se debe introducir en Nombre del Servidor la palabra entre parntesis y minsculas local, si es que la base de datos est en la misma computadora, si no es as se debe introducir el nombre del servidor. Luego se debe seleccionar la Base de datos, en la parte de la ventana con el nombre de Establecer conexin con una base de datos. Una vez seleccionada la base de datos solo queda realizar un clic en el botn de Aceptar, como se puede ver en la Pantalla 13.
389
Pantalla 13. Crear una conexin a una base de datos El resultado de la anterior actividad permitir ver las tablas que contiene la base de datos. Como se puede ver en la Pantalla 14.
Pantalla 14. Vista de las Conexiones y tablas de la Base de Datos Para poder insertar una tabla a un DataSet solo se debe arrastrar la tabla que se desea, en el ejemplo sea tbEmpleado hacia el DTOEmpleado, el resultado de esta actividad se pude ver en la Pantalla 15.
390
Pantalla 15. Vista de un tabla dentro de un DTO De esta forma se puede introducir una definicin de una tabla a un DTO, como se ha dicho anteriormente un DataSet puede contener de una a varias tablas, sin embargo se recomienda que por cada tabla se cree una DataSet, en este caso un DTO. Cundo introducir dos o ms tablas a un DTO? Se recomienda que cuando existe una asociacin fuerte entre dos tablas o, si existe una asociacin de composicin dentro de un diagrama de clases de diseo. Al momento de introducir una tabla a un DataSet, la definicin de esta se podr ver al hacer un clic sobre esta y otro clic sobre los campos, como se puede ver en la Pantalla 15 en la ventana de Propiedades. El desarrollador pude necesitar crear un tabla que no sea persistente, es decir que no necesite realizar la conexin a una base de datos para obtener datos. Dentro el cuadro de herramientas existe un componente con el nombre de DataTable, el cual permitir al desarrollador definir una tabla. En la Pantalla 16, se puede ver este componente, solo se debe arrastrar hacia el DataSet para iniciar la definicin.
391
Pantalla 16. Componente DataTable Volviendo al diagrama de secuencia nos queda realizar la configuracin de la clase SQLHelper, dentro del directorio del Captulo IV, en el curso se encuentra un archivos con el nombre de DataAccessApplicationBlock.rar, el cual contiene un archivo ejecutable este debe ser instalado. Al finalizar la instalacin, dentro del men Inicio y Todos los programas aparecer una carpeta con el nombre de Microsoft Application Block for .NET, dentro de esta est el Data Access v2, Source Code (C#) y Data Access Aplication Block, como se puede ver en la Pantalla 17.
Pantalla 17. Directorios de la ubicacin del SQLHelper Como se puede observar en la Pantalla 17, existe para los dos lenguajes ms populares de la tecnologa .NET para C# y para Visual Basic el Data Access Aplication Block. Una vez seleccionada la opcin aparecer un nuevo entorno de desarrollo de Visual Studio 2005, con los archivos que contiene la definicin de esta clase de SQLHelper, lo que queda por hacer es ejecutar la aplicacin, esto crear un .dll el cual podremos utilizar dentro de la aplicacin que se esta desarrollando. La ubicacin de este archivo .dll se pude ver en la Pantalla 18.
392
Pantalla 18. Ubicacin de la clase SQLHelper Para poder utilizar el SQLHelper se debe hacer un clic derecho sobre el nombre del Servicio Web y seleccionar la opcin con el nombre de Agregar referencia, como se puede ver en la Pantalla 19.
Pantalla 19. Agregar una Referencia Luego de hacer un clic en Agregar referencia se visualizar una ventana con el nombre de Agregar referencia. Se debe localizar el archivo del SQLHelper, la ubicacin donde se encuentra se pude ver en la Pantalla 20. 393
Pantalla 20. Ubicacin del archivo SQLHelper Una vez que se visualice el archivo con el nombre de Microsoft.ApplicationBlocks.Data.dll, se debe hacer un clic en el botn Aceptar, esta actividad adicionar los tres archivos como se puede ver en la Pantalla 21, con los cuales se podr utilizar la clase de SQLHelper.
Pantalla 21. Adicin de los Archivos de SQLHelper Ahora se iniciar la implementacin de los mtodos de la clase controladora del servicio web. Se necesita implementar un mtodo con el Nombre de Autenticar que recibir dos datos con los cuales identificar un aun empleado. adicionalmente, tiene que crear una instancia de un DTOEmpleado, llamar al mtodo FillDataset del SQLHelper y por ltimo solicitar implementar un mtodo con el nombre de Autenticar Empleado. A continuacin se coloca el cdigo de la clase CSW_Seguridad.
1 using System; 2 using System.Data;
394
3 using System.Configuration; 4 using System.Web; 5 using System.Web.Security; 6 using System.Web.UI; 7 using System.Web.UI.WebControls; 8 using System.Web.UI.WebControls.WebParts; 9 using System.Web.UI.HtmlControls; 10 using Microsoft.ApplicationBlocks.Data; /// <summary> /// Descripcin breve de CSWSeguridad /// </summary> 11 public class CSWSeguridad 12 { 13 DTOEmpleado dtoEmpleado; //Se define una instacia de la clase DTOEmpleado 14 public CSWSeguridad() 15 { 16 dtoEmpleado = new DTOEmpleado(); //Se crea la Instancia del la clase DTOEmpleado 17 } 18 //Mtodo para Autenticar a un Empleado de la institucin 19 public string Autenticar(string Cuenta, string ContrasenaCifrada) 20 { 21 string autorizado="El Empleado no est Autorizado"; 22 //Se recupera la cadena de conexion del archivo Web.config 23 string Cadena = ConfigurationManager.ConnectionStrings[1].ConnectionString; 24 //Se llena el dtoEmpleado llamando a metodo FillDataset del SQLHelper 25 SqlHelper.FillDataset(Cadena, CommandType.StoredProcedure, "PAS_tbEmpleado", dtoEmpleado, new string[] { "tbEmpleado" }); 26 //Se solicita la autenticacion por medio del metodo AutenticarEmpleado 27 int Autenticado = AutenticarEmpleado(Cuenta, ContrasenaCifrada); 28 //Se pregunta se el valor Autenticado es igual a 1, lo cual significa que esta Autorizado el Empleado 29 if (Autenticado==1) 30 { 31 //Se cambia el valor de la variable Autoriado 32 autorizado="S"; //Este Valor significa que el empleado esta autorizado 33 } 34 //Retorna el valor de la variable autorizado; 35 return autorizado; 36 } 37 int AutenticarEmpleado(string Cuenta, string ContrasenaCifrada) 38 { 39 //Se crea una variable que dara el resultado si el Empleado es autorizado 40 int autenticado = 0; 41 //Se determina la condicion que nos permite autenticar a un Empleado 42 string condicion = dtoEmpleado.tbEmpleado.CuentaColumn.ToString()+ " = '"+Cuenta+ "' and "; 43 condicion+=dtoEmpleado.tbEmpleado.ContrasenaColumn.ToString()+" = '"+ContrasenaCifrada+"'"; 44 //Se seleccionan las filas que coincide con la condicion (debe existir una sola) 45 DTOEmpleado.tbEmpleadoRow[] rowEmpleado = (DTOEmpleado.tbEmpleadoRow[]) 46 dtoEmpleado.tbEmpleado.Select(condicion); 47 //Se pregunta si el resultado de la consulta ha devuelto una sola fila 48 if (rowEmpleado.Length == 1) 49 { 50 //Si el resultado de la seleccion tiene una sola fila se cambia de estado a la variable autenticado 51 autenticado = 1; //Este resultado significa que el Empleado esta Autorizado 52 } 53 return autenticado; 54 } 55 }
La primera lnea del cogido presentado que debe comentarse es la nmero 10, esta hace referencia a la clase SQLHelper, sin esta lnea no se podr utilizar los mtodos de esta clase. 395
La lnea 13, es muy importante ya que se define un objeto para luego crear su instancia en la lnea 16, esto puede llevar a una confusin, respecto al diagrama de secuencia y la implementacin, como se ha dicho anteriormente la implementacin debe ser similar a los diagramas de secuencia. Sin embargo se tiene el mtodo de DTOEmpleado() que en si es el constructor de la clase DTOEmpleado. La lnea 23 es la que permite recuperar la cadena de conexin del archivo Web.Config, este debe estar con las siguientes lneas:
<?xml version="1.0" encoding="utf-8"?> <!-Nota: como alternativa para editar manualmente este archivo puede utilizar la herramienta Administracin de sitios Web para configurar los valores de la aplicacin. Utilice la opcin Sitio Web->Configuracin de Asp.Net en Visual Studio. Encontrar una lista completa de valores de configuracin y comentarios en machine.config.comments, que se encuentra generalmente en \Windows\Microsoft.Net\Framework\v2.x\Config --> <configuration> <appSettings/> <connectionStrings> <add name="HotelBetoConnectionString" connectionString="Data Source=angerona;Initial Catalog=HotelBeto;User ID=sa;password=lafuente" providerName="System.Data.SqlClient"/> </connectionStrings> <system.web> <!-Establezca debug="true" en la compilacin para insertar smbolos de depuracin en la pgina compilada. Dado que este proceso afecta al rendimiento, debe establecer este valor como true durante la depuracin. --> <compilation debug="false" /> <!-La seccin <authentication> permite configurar el modo de autenticacin de seguridad utilizado por ASP.NET para identificar a un usuario entrante. --> <authentication mode="Windows" /> <!-La seccin <customErrors> permite configurar las acciones que se deben llevar a cabo/cuando un error no controlado tiene lugar durante la ejecucin de una solicitud. Especficamente, permite a los desarrolladores configurar pginas de error html que se mostrarn en lugar de un seguimiento de pila de errores. <customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm"> <error statusCode="403" redirect="NoAccess.htm" /> <error statusCode="404" redirect="FileNotFound.htm" /> </customErrors> --> </system.web> </configuration>
La lnea 25 del cdigo de autenticacin utiliza la clase SQLHelper y su mtodo FillDatase, el objetivo de este mtodo es llenar un DataSet a travs de un procedimiento almacenado o una sentencia SQL. El primer parmetro que se debe definir es la cadena de conexin, el siguiente es el tipo CommandType, existen tres opciones, CommandType.Text (Permite escribir entre comillas una sentencia de SQL), CommandType.StoredProcedure (Permite colocar un nombre de procedimiento almacenado de seleccin) y CommandType.TableDirect (Permite colocar el nombre de una Tabla de una base de datos). El siguiente parmetro del mtodo FillDataset es el nombre de una instancia de un DataSet, en el caso 396
del ejemplo que se est desarrollando es dtoEmpleado. Por ltimo, se determina un vector de tipo string, el cual tendr el nombre de la tabla que se est llenando en el DataSet en el caso del ejemplo ser tbEmpleado. El cdigo del procedimiento almacenado ser:
CREATE PROCEDURE PAS_tbEmpleado AS Select * from tbEmpleado
Las dems lneas de cdigo son comprensibles para el lector. Ahora, se utilizar el mtodo de autenticar en el servicio web para esto se debe hacer un clic sobre la clase SWSeguridad.cs, el cdigo se pude ver a continuacin.
using System; using System.Web; using System.Collections; using System.Web.Services; using System.Web.Services.Protocols;
/// <summary> /// Descripcin breve de SWSeguridad /// </summary> [WebService(Namespace = "http://tempuri.org/")] [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] public class SWSeguridad : System.Web.Services.WebService { public SWSeguridad () { //Eliminar la marca de comentario de la lnea siguiente si utiliza los componentes diseados //InitializeComponent(); } [WebMethod] public string Autenticar(string Cuenta, string ContrasenaCifrada) { //Se crea una instancia de la Controladora de servicio web CSWSeguridad seguridad = new CSWSeguridad(); //Se utilizar el mtodo Autenticar por medio de la instancia creada string autenticado = seguridad.Autenticar(Cuenta, ContrasenaCifrada); return autenticado; } }
De esta forma se ha terminado la implementacin de la capa de negocio y de acceso de los datos. En el prximo documento se integrar la aplicacin web y el servicio web.
397
INTEGRANDO CAPAS Una vez que se implementado las capas de Presentacin, Negocio y de Acceso a los Datos se debe integrar cada una de estas, como se pude ver en la Figura 1, que representa al Marco de Trabajo, se pude ver que la capa de Presentacin tiene comunicacin con la capa de Negocio a travs de las controladoras de interfaz y los Servicios Web. Esto es lo que se har en este documento.
Figura 1. Marco de Trabajo El primer paso que se debe realizar es publicar el servicio web, como se ha visto en el documento de Implementar un Servicio Web. El resultado que debe lograrse se puede ver en la Pantalla 1.
398
Pantalla 1. Servicio Web publicado para autenticar empleado Una vez que el servicio web de seguridad este publiado se debe adicionar la referencia a la aplicacin web . Para realizar esta actividad se debe cargar la aplicacin al Visual Studio y realizar un clic derecho sobre el nombre de la solucin, en la parte del Explorador de soluciones, luego se debe seleccionar la opcin de Agregar referencia Web como se puede ver en la Pantalla 2.
399
Pantalla 2. Agregar una referencia Web Una vez seleccionada la opcin se podr visualizar la ventana con el nombre de Agregar referencia Web, como se puede ver en la Pantalla 3.
400
Pantalla 3. Agregar referencia Web a a Aplicacin Una vez visualizada la vantana, para agregar la referencia web, solo se debe realizar un clic en el link Servicios Web del equipo local, esta operacin har aparecer una lista de servicios web que se encuentren publicados, como se puede ver en la Pantalla 4. Se bede seleccionar de la lista el servicio Web el que corresponde al sub sistema de Seguridad como se puede ver en la Patantalla 4. El nombre del servicio Web es SWSeguridad.
Pagina 4. Lista de Servicios Web 401

Una vez identificado y seleccionado el servicio web en la parte de Nombre de referencia Web se debe intoducir el nombre de SWSeguridad, ya que ser el nombre de referencia para la aplicacin web. Esto se pude ver en la Pantalla 5.
Pantalla 5. Definir el Nombre del Servicio Web Para finalizar, se debe realizar un clic en el botn de Agregar referencia, esto agregar el servicio web a la apliacacin. Se puede comprobar la adicin en el Explorador de Soluciones, como se puede ver en la Pantalla 6.
402
Pantalla 6. Servicio Web de Seguridad adicionado a la aplicacin Web Una vez hecha esta ltima actividad, ya se puede tener acceso a los mtodos del sevicio web, lo que queda por hacer es terminar el cdigo del boton de autenticar. Para esto se debe realizar doble clic sobre el control de usuario con el nombre de C_Autenticar.ascx, el cual permitir autienticar a un empleado. Esta actividad se puede ver Pantalla 7.
Pantalla 7. Control de Usuario C_Autenticar Ahora, para teminar el cdigo del botn de Auenticar se debe realizar doble clic sobre este, esto har apareser una nueva ventana que permitir editar el codigo del evento click del botn. Esto se puede ver en la Pantalla 8.
403
Pantalla 8. Cdigo del botn Autenticar Como se puede ver, se tiene una solicitud hacia la clase CIUAutenticar con el nombre de Autenticar pasando los datos de Cuenta y Contrasena. Se debe hacer un clic derecha en la solicitud y apareser una ventana emergente como se puede ver en la Pantalla 9.
Pantalla 9. Ventan energente de una solicitud De esta ventana se debe seleccionar la opcin de Ir a definicin, esta permite ir al codigo de la solicitud definida en la clase. El resultado de seleccionar esta opcin se puede ver en la Pantalla 10. 404
Pantalla 10. Utilizar el Servicio Web En la Pantalla 10 se ha introducido tres lineas de codigo que permiten utilizar el servicio web de SWSeguridad, estas lineas estn en el mtodo de Autenticar. Una vez, introducido el cdigo se debe terminar del boton de autenticar, esto se puede ver en la Pantalla 11.
405
Pantalla 11. Cdigo Final para autenticar. Este es el ltimo cdigo que se debe introducir, luego se debe ejecutar la aplicacin, el resultado se puede ver en la Pantalla 12.
Pantalla 12. Ventana para Autenticar Empleado 406

Con esta ltima pantalla se ha terminado de implemetar la realizacion del caso de uso Autenticar. La parte ms importante para la implementacin es el Estandar de Implemantacin y sobre todo el Marco de Trabajo, este ltimo debe ser TOMADO EN CUENTA POR TODOS LOS DESARROLLADORES, este permitir una capacitacin con mayor rapides de personas que se incluyan al desarrollo. A continuacin se ver y explicar cdigo para la adicin modificacin y busqueda. Como se ha explicado anteriormente se debe tratar de tener procedimientos alamacenados que solo tengan una sola sentencia. Procedimientos almacenados que contengan ms de dos lneas de cdigo sern dificiles de mantener. Por ejemplo, si se determina la migracin de un gestor de base de datos a otro, existen todabia gestores de base de datos que no permiten implementar procedimientos almacenados, eso ser un impedimiento para la migracin. Esta situacin es extrema, pero se debe tomar en cuenta al momento de definir la arquitectura, sobre todo cuando exista la posibilidad de migrar los datos a un gestor de base de datos. El marco de trabajo que se ha estudiado recomienda que exista dentro de los procedimientos almacenados una sola sentecia, justamente est pensado para una migracion de base de datos, para esto solo se debe cambiar los archivos que pertenesen al SQLHelper. Existe en internet SQLHelper para MySQL, SQL Progress, Oracle, entre otros. Solo debe cambiarse los archivos de SQLHelper para que la aplicacin funcione.
Cdigo para insertar un Empleado

1 public int Adicionar_Empleado(string Nombre, string ApellidoPaterno, string ApellidoMaterno, string Direccion, string CedulaIdentidad, string Telefono, string Cuenta, string ContrasenaCifrada) 2 { 3 string cadena = ConfigurationManager.ConnectionStrings[1].ConnectionString; 4 DTOEmpleado dtotbEmpleado = new DTOEmpleado(); 5 SqlParameter[] parametros; 6 parametros = SqlHelperParameterCache.GetCachedParameterSet(cadena, "PAI_tbEmpleado"); 7 if (parametros == null) 8 { 9 parametros = new SqlParameter[] { 10 new SqlParameter("@" + dtotbEmplaedo.tbPersona.CodigoEmpleadoColumn.ToString(), SqlDbType.Int, 0, ParameterDirection.Output, false, 0, 0, "@"+ dtotbPersona.tbEmpleado.CodigoPersonaColumn.ToString(), DataRowVersion.Current, null), 11 new SqlParameter("@" + dtoEmpleado.tbEmpleado.NombreColumn.ToString(), SqlDbType.NVarChar,50), 12 new SqlParameter("@" + dtoEmpleado.tbEmpleado.ApellidoPaternoColumn.ToString(), SqlDbType.NVarChar,50), 13 new SqlParameter("@" + dtoEmpleado.tbEmpleado.ApellidoMaternoColumn.ToString(), SqlDbType.NVarChar,50), 14 new SqlParameter("@" + dtoEmpleado.tbEmpleado.DireccionColumn.ToString(), SqlDbType.NVarChar,50), 15 new SqlParameter("@" + dtoEmpleado.tbEmpleado.CedulaIdentidadColumn.ToString(), SqlDbType.NVarChar,50), 16 new SqlParameter("@" + dtoEmpleado.tbEmpleado.TelefonoColumn.ToString(), SqlDbType.Int,0), 17 new SqlParameter("@" + dtoEmpleado.tbEmpleado.CuentaColumn.ToString(), SqlDbType.Int,0), 18 new SqlParameter("@" + dtoEmpleado.tbEmpleado.ContrasenaColumn.ToString(), SqlDbType.Int,0) }; 19 SqlHelperParameterCache.CacheParameterSet(cadena, "PAI_tbEmpleado", parametros); 20 } 21 parametros[0].Value = 0; 22 parametros[1].Value = Nombre; 23 parametros[2].Value = ApellidoPaterno; 24 parametros[3].Value = ApellidoMaterno; 25 parametros[4].Value = Direccion; 26 parametros[5].Value = CedulaIdentidad; 27 parametros[6].Value = Telefono; 28 parametros[7].Value = Cuenta; 29 parametros[8].Value = ContraseaCifrada; 30 SqlHelper.ExecuteNonQuery(cadena, CommandType.StoredProcedure, "PAI_tbPersona", parametros); 31 int CODIGO = (Int32)parametros[0].Value; 32 return CODIGO; 33 }
407
La lnea 1 define el nombre u los parmetros del mtodo de Adicionar_Empleado, el cual permitir adicionar a la base de datos a un empleado con el Nombre, Apellido Paterno, Apellido Materno, Direccin, CedulaIdentidad, Telefono, Cuenta y Contrasea, esta ltima debe estar cifrada. En la lnea 3 se recupera la cadena de conexin. En la lnea 4 se crear una instancia del DataSet DTOEmpleado. Esta instancia permitir recuperar el nombre de las columnas del DataSet, como se puede ver en las lneas 10 hasta 16. En la lnea 5 se crear un objeto de tipo SqlParameter con las caractersticas de un arreglo, el cual permitir definir los parmetros del procedimiento almacenado. Las lneas de cdigo que definen a estos parmetros se pueden ver desde la lnea 10 hasta 18. En la lnea 6 el objeto se iguala a un mtodo del DataAplicacionBlock con el nombre de SqlHelperParameterCache, el cual recupera del cache el servidor web la definicin de los parmetros de un procedimiento almacenado, el primer parmetro que debe incluirse a este mtodo es la cadena de conexin, el segundo es el nombre que servir para identificar la informacin de los parmetros en el cache, puede ser cualquier nombre pero no igual a otros definidos en el cdigo, en el caso del ejemplo se coloco el nombre del procedimiento almacenado al cual se har referencia. En la lnea 7 se pregunta si el objeto parmetros es nulo, si fuera as debe definirse cada uno de los parmetros que participan el procedimiento almacenado a referirse. La lnea 9 es la encargada de crear una instancia de SqlParameter. A partir de la lnea 10 hasta 18 son las que definen los parmetros de un procedimiento almacenado. La lnea 10 es la que permite capturar un parmetro de retorno de un procedimiento almacenado. Las otras lneas, de la 11 a la 18 permiten definir los parmetros de entrada. La lnea 19 es importante, ya que esta se pone en cache los parmetros definidos, la prxima vez que se solicite a este mtodo no ser necesario definir nuevamente los parmetros. Para el mtodo CacheParameterSet se debe definir la cadena de conexin, el nombre del cache y por ltimo el conjunto de parmetros del procedimiento almacenado. Desde la lnea 21 a la lnea 29, se asigna los valores a cada uno de los parmetros definidos para luego ejecutar el mtodo ExecuteNonQuery, el cual permite ejecutar, ya sea, un procedimiento almacenado o una sentencia de SQL, este mtodo solo permite ejecutar una sentencia que sea Insertar (insert), actualizar (update) o borrar (delete) y no as una seleccin (select). Esto ocurre en la lnea 30. La lnea 31 permite captar el valor de retorno en un parmetro de salida de un procedimiento almacenado. A continuacin se presenta el procedimiento almacenado que corresponde a este mtodo explicado para adicionar a un empleado.
Create Procedure PAI_tbEmpleado @CodigoEmpleado as int = NULL output, @Nombre as varchar(50) = NULL, @ApellidoPaterno as varchar(50) = NULL, @ApellidoMaterno as varchar(50) = NULL, @Direccion as varchar(50) = NULL, @CedulaIdentidad as varchar(50) = NULL, @Telefono as varchar(50) = NULL, @Cuenta as varchar(50)=NULL, @Contrasena as varchar(50)=NULL AS insert into tbPersona(Nombre, ApellidoPaterno, ApellidoMaterno, Carnet, NombreFotografia, CantidadHojasDisponibles) values (@Nombre, @ApellidoPaterno, @ApellidoMaterno, @Carnet, @NombreFotografia, @CantidadHojasDisponibles) set @CodigoPersona= @@identity GO
408
Cdigo para modificar los datos de un Empleado

1 public DTOEmpleado Modificar_tbEmpleado( int CodigoEmpleado, string Nombre, string ApellidoPaterno, string ApellidoMaterno, string Direccion, string CedulaIdentidad, string Telefono, string Cuenta, string Contrasena) 2 { 3 SqlParameter[] parametros; 4 string cadena = ConfigurationManager.ConnectionStrings[1].ConnectionString; 5 DTOEmpleado dtoEmpleado = new DTOEmpleado(); 6 parametros = SqlHelperParameterCache.GetCachedParameterSet(cadena, "Modificar_tbEmpleado"); 7 if (parametros == null) 8 { 9 parametros = new SqlParameter[] { 10 new SqlParameter(), 11 new SqlParameter(), 12 new SqlParameter(), 13 new SqlParameter(), 14 new SqlParameter(), 15 new SqlParameter(), 16 new SqlParameter(), 17 new SqlParameter(), 18 new SqlParameter() 19 }; 20 SqlHelperParameterCache.CacheParameterSet(cadena, "ModificartbEmpleado", parametros); 21 parametros[0].ParameterName = "@" + dtoEmpleado.tbEmpleado.CodigoEmpleadoColumn.ToString(); 22 parametros[0].SqlDbType = SqlDbType.Int; 23 parametros[1].ParameterName = "@" + dtoEmpleado.tbEmpleado.NombreColumn.ToString(); 24 parametros[2].ParameterName = "@" + dtoEmpleado.tbEmpleado.ApellidoPaternoColumn.ToString(); 25 parametros[3].ParameterName = "@" + dtoEmpleado.tbEmpleado.ApellidoMaternoColumn.ToString(); 26 parametros[4].ParameterName = "@" + dtoEmpleado.tbEmpleado.DireccionColumn.ToString(); 27 parametros[5].ParameterName = "@" + dtoEmpleado.tbEmpleado.CedulaIdentidadColumn.ToString(); 28 parametros[6].ParameterName = "@" + dtoEmpleado.tbEmpleado.TelefonoColumn.ToString(); 29 parametros[7].ParameterName = "@" + dtoEmpleado.tbEmpleado.CuentaColumn.ToString(); 30 parametros[8].ParameterName = "@" + dtoEmpleado.tbEmpleado.ContrasenaColumn.ToString(); 31 } 32 parametros[0].Value = CodigoEmpleado; 33 parametros[1].Value = Nombre; 34 parametros[2].Value = ApellidoPaterno; 34 parametros[3].Value = ApellidoMaterno; 35 parametros[4].Value = Direccion; 36 parametros[5].Value = CedulaIdentidad; 37 parametros[6].Value = Telefono; 38 parametros[7].Value = Cuenta; 39 parametros[8].Value = Contrasena; 40 SqlHelper.ExecuteNonQuery(cadena, CommandType.StoredProcedure, "PAU_tbEmpleado", parametros); 41 return Llenar_DTOEmpleado(); 42 }
Este mtodo que debe estar ubicado en la controladora de la capa de negocio con el nombre de CSW_Administradocion, ya que esta ser la clase controladora del subsistema de administracin, de igual forma es el anterior cdigo de adicin de Empleado. De igual forma que en el anterior cdigo se define, en la lnea 1, un mtodo que devolver un DTOEmpleado, adicionalmente se debe enviar el CodigoEmpleado, el cual servir para buscar y actualizar los datos del empleado, juntamente con el cdigo del empleado van el Nombre, Apellido Paterno, Apellido Materno, Direccion, Cedula de Identidad, Telefono, Cuenta, Contrasea. Estos datos deben de estar descritos en el caso de uso, se recomienda no inventar estos datos, siempre se debe hacer referencia al caso de uso, como se ha dicho anteriormente la descripcin del los casos de uso son muy importantes y servirn para todo el desarrollo de la aplicacin.
409
En la lnea 3 se define un objeto de tipo SqlParameter con el nombre de parametros, este permitir definir un conjunto de parmetros para un procedimiento almacenado, esta definicin se la puede ver en las lneas 21 hasta 30. La lnea 4 recupera la cadena de conexin del archivo Web.config La lnea 5 crea un objeto de la clase DTOEmpleado, que en si es un DataSet, el cual permitir almacenar y recuperar los datos, as como la configuracin del DataTable configurada en este. La lnea 6 permite recuperar los parmetros definidos con anterioridad, si es que han sido definidos, si es la primera vez que es utilizado este mtodo el valor de parametros ser nulo. La lnea 7 pregunta si el valor de parametros es nulo, si es as entra a definir el nmero de parmetros como se puede ver en las lneas 9 hasta 18, si el valor no es nulo significa que ya se ha definido los parmetros y solo se tiene que asignar los valores. La lnea 20 permite grabar en cache los parmetros, esto se explic en el anterior cdigo con el nombre de Adicin de Empleado, lo nico que cambia es el segundo parmetro ahora es ModificartbEmpleado. Desde la lnea 21 hasta la 30 se asignan los nombres a cada espacio de la variable parametros. Desde la lnea 32 hasta la 39 se asignan los datos de los parmetros. En la lnea 40 se utiliza nuevamente el mtodo del SQLHelper con el nombre de ExecuteNonQuery para modificar los datos, ya que este llama al procedimiento almacenado con el nombre de PAU_tbEmpleado. A continuacin se presenta el procedimiento almacenado que corresponde a este mtodo explicado para la modificacin de un empleado.
create procedure PAU_tbPersona @CodigoPersona as int = NULL, @Nombre as varchar(30) = NULL, @ApellidoPaterno as varchar(30) = NULL, @ApellidoMaterno as varchar(30) = NULL, @Carnet as varchar(15) = NULL, @NombreFotografia as varchar(25) = NULL, @CantidadHojasDisponibles as int = NULL AS begin tran update tbPersona set Nombre=@Nombre, ApellidoPaterno=@ApellidoPaterno, ApellidoMaterno=@ApellidoMaterno, Carnet=@Carnet, NombreFotografia=@NombreFotografia, CantidadHojasDisponibles=@CantidadHojasDisponibles where CodigoPersona=@CodigoPersona commit
Se ha culminado la implementacin, no debe olvidarse que es importante tener correctamente desarrollados los diagramas de secuencias y determinar el marco de trabajo, son las piedras fundamentales para una implementacin exitosa. Para lograr el correcto desarrollo de los distintos artefactos debe existir un proceso de verificacin (Revisiones e Inspecciones), estas permitirn encontrar defectos dentro de los artefactos. Este es un tema que ser abordado en otro curso programado por SynerDynE, CONTROL DE CALIDAD. He encontrado muchas personas que hablan de metodologas y un proceso definido de software tomando en cuenta lo que es RUP (Rational Unified Process), lastimosamente, muchas personas, no cumplen con las recomendaciones que hace este proceso de desarrollo de software para crear una aplicacin. Como se ha visto en el transcurso del curso cada diagrama, flujo, objeto, documento, entre otros, tiene un por qu, un propsito y un para qu, estos deben tomarse en cuenta y muchas detalles ms (que no se han visto en el curso) para desarrollar una aplicacin de acuerdo a RUP. En el siguiente captulo se podr ver la utilizacin de los casos de uso de la aplicacin para desarrollar los casos de uso de prueba, algo muy importante para validar los objetivos de la aplicacin.
410
CAPITULO V
PRUEBA
Objetivo Validar la aplicacin desarrollada y ver si cumple con los requisitos utilizando una tcnica de prueba
411
DISEO DE CASOS DE USO DE PRUEBA.

Se considera a esta disciplina como un acto que provee distintas observaciones y defectos para las otras disciplinas o fases. Es una de las que permite evaluar la calidad del producto usando numerosas prcticas para esto. Adicionalmente es uno de los procesos que ayuda a la empresa o persona que desarrolla software a controlar la calidad y conforma uno de los cuatro procesos para este fin. Se presentan brevemente los procesos que ayudan a establecer la calidad del desarrollo y del producto: Verificacin. Bsicamente revisiones y auditorias de configuracin. Validacin. Todos los niveles y fases de prueba de ejecucin de software. Gestin de Configuracin. Como medio de control de los productos generados. Medicin de software. Contempla la necesidad de marcar objetivos y asociar mtricas a los objetivos
Cada uno de estos procesos debe ser llevado a cabo en el transcurso del desarrollo del producto. Es muy importante iniciar con alguno de estos y paulatinamente introducir los restantes. Como se puede ver en la Figura 1, existen distintas maneras de mejorar el proceso de desarrollo, hay que aclarar que mejorar el proceso es desarrollar de tal forma que se cumpla lo definido y establecido para el desarrollo de una aplicacin, tomando en cuenta al cliente, a los desarrolladores y la futura tecnologa. Para demostrar que se ha desarrollado de forma definida, se debe documentar todo el proceso.
Figura 1. Distintos Procesos que mejoran la calidad y el desarrollo de software Como se puede ver en la Figura 1, el proceso de prueba es uno que aparece en la literatura para la mejora del proceso de desarrollo y adems es una de las disciplinas recomendadas de RUP (Rational Unified Proccess) para validar la implementacin. Existen varios objetivos que menciona la documentacin de RUP para la disciplina de prueba, estos son algunos: Encontrar y documentar las faltas en el producto de software: defectos y problemas. Notificar al jefe de proyecto la calidad percibida en el producto.
412
Evaluar el diseo y la descripcin de los requisitos, que es la parte lgica del producto, con la demostracin concreta del funcionamiento de la aplicacin. Validar que el producto de software trabaje segn lo diseado. Validar que los requisitos han sido cumplidos apropiadamente.
La disciplina de prueba de RUP se centra en cul es la falla o el defecto, mientras que los otros procesos estn dedicados a la completitud de los artefactos, consistente y a la correccin. La disciplina de prueba debe considerar las siguientes preguntas: Cmo se puede probar eficientemente el software? Cul es la situacin o las condiciones para que el software no trabaje?
Se dice que una prueba es exitosa cuando se ha encontrado defectos o fallas. La prueba debe desafiar las suposiciones, riesgos en los requisitos, la incertidumbre en los artefactos desarrollados, el Hardware, entre otros. Este desafo se realiza a travs de la demostracin y la evaluacin imparcial. La informacin que se logra con la prueba implica un esfuerzo de 30% a un 50% de todo el desarrollo del software. Por este motivo muchas de las empresas o personas que desarrollan software no logran probar el software correctamente antes de la entrega. La flexibilidad y la complejidad hacen que la prueba sea un meta imposible a logar, por esta razn se debe tener una estrategia bien definida para lograr un apropiado y eficaz proceso de prueba. La estrategia que se logre definir debe garantizar que la organizacin a la cual se implantar el software no corra con posibles costos legales y/o prdidas masivas de dinero y de tiempo. La prueba debe servir, en futuros desarrollos, para reducir los defectos y sobre todo el costo que implica el desarrollo. Otro punto de vista, es que logre reducir los riesgos en el mantenimiento del software. La prueba debe garantizar la calidad, este trmino se refiere a varios aspectos: La ausencia de defectos Hace lo que quisiramos que hiciera. Est libre de defectos Gerald Weinberg dice: La calidad est en el valor que le da una persona al producto.
La responsabilidad de cada persona que conforma el equipo de desarrollo es la calidad. Cada una de las personas que participa debe disear y planificar la calidad, sin estos dos puntos es difcil conseguir el objetivo de conformidad, ya sea del cliente, usuario y/o de los involucrados. RUP seala que la disciplina de prueba no es la que alcanzar en su totalidad la calidad, sino el conjunto de cumplimiento y seguimiento de las otras disciplinas adicionales. En otras palabras, es muy importante cumplir la definicin del proceso o metodologa que se aplique para el desarrollo de esta forma se cumplir satisfactoriamente con la calidad. Muchos de los requisitos no funcionales que se determinen en la Ingeniera de Requisitos, ya sea globales o de cada caso de uso se pueden evaluar a travs de los distintos tipos de prueba, como por ejemplo: Confiabilidad: La aplicacin permanece fiable y constantemente; es resistente a los defectos durante la ejecucin, muestra mensajes como: falla de Hardware, Se par la ejecucin de la aplicacin, se ha desbordado la memoria, entre otros. Funcionalidad: La aplicacin ejecuta con xito los casos de uso de la aplicacin.
413
Funcionamiento: La aplicacin responde de una manera oportuna y contina siendo aceptable cuando se ejecuta con caractersticas operacionales del mundo real (ej. perodos muy largos de la operacin). La prueba de funcionamiento se centra en asegurarse de que la funcionalidad de la aplicacin puede ser proporcionada mientras que satisface los requisitos no funcionales del sistema. Utilidad: La aplicacin es conveniente para los usuarios finales que la usen; la atencin se centra en los factores humanos, estticos, entre otros.
No necesariamente, se debe ejecutar varios tipos de prueba para cada requisito no funcional que se determine, esto est en funcin del nivel, grado del requisito y algunas veces al riesgo del Caso de Uso de la Aplicacin. Si bien, se desarrolla en ciclos de desarrollo que cada vez incrementa la completitud de la aplicacin, es necesario probar toda la aplicacin y no as el desarrollo nuevo que se incluye. Para esta situacin, donde se debe probar las nuevas funcionalidades ms la anterior se recomienda desarrollar un nuevo plan de pruebas (Conjunto de casos de prueba) que no incluya el conjunto de pruebas definido para la anterior. Niveles de la prueba Existe cinco niveles de prueba con distintos propsitos son los siguientes: 1. Prueba de la unidad. Los elementos ms pequeos de la aplicacin son probados. 2. Prueba de la integracin. Se prueba la integracin de los subsistemas, mdulo, servicios web, entre otros. 3. Prueba del sistema. En el paso anterior se prob el software pero el sistema incluye otros elementos (hardware, personas, bases de datos, etc.). Esta prueba por sus caractersticas no puede realizarse slo por el analista. Se realiza en los siguientes pasos: Prueba de recuperacin. La prueba de recuperacin es una prueba que fuerza el fallo del software de muchas formas y verifica que la recuperacin se lleva a cabo adecuadamente. Si la recuperacin es automtica hay que evaluar la correccin de la reinicializacin, de los mecanismos de recuperacin de estado del sistema, de la recuperacin de datos y del rearranque. Si la recuperacin requiere intervencin humana hay que evaluar los tiempos de reparacin para ver si estn dentro de los lmites aceptables. Prueba de seguridad. La prueba de seguridad intenta verificar que los mecanismos de proteccin incorporados al sistema lo protegern de hecho de la penetracin impropia. El encargado de la prueba debe desempear el papel de un individuo que desea penetrar el sistema usando cualquier medio. Una buena prueba debe penetrar el sistema, el problema est en que sea costoso y requiera mucho tiempo. Prueba de resistencia. Las pruebas de resistencia estn diseadas para enfrentar al software a situaciones anormales. La prueba de resistencia ejecuta un sistema de forma que demande recursos en cantidad, frecuencia y volmenes anormales. Prueba de rendimiento. Para una aplicacin en tiempo real o empotrado es inaceptable el software que proporciona las respuestas requeridas pero que no se ajusta a los rendimientos. La prueba de rendimiento se desarrolla para probar el rendimiento del software en tiempo de ejecucin dentro del contexto de un sistema integrado. 4. Prueba de aceptacin. El uso completo de la aplicacin es probado por los usuarios finales o los representantes para determinar la preparacin para el despliegue. 5. Prueba de validacin del software. La validacin se logra cuando el software funciona de acuerdo a los intereses del usuario. . Para esto se revisa si el software cumple con: Los casos de uso definidos en la ingeniera de requisitos. Los requisitos de rendimiento definidos en el estudio preliminar. Otros requisitos como portabilidad, posibilidad de recuperarse ante errores, facilidad de mantenimiento, entro otros. Se debe tener presente que estos niveles ocurren a travs del ciclo de vida, pueden llevarse a cabo en orden o en paralelo. Por ejemplo, un prototipo conceptual usado en una de las fases de inicio (Casos de Uso descritos)
414
servirn para determinar la viabilidad de la visin del producto, estos estarn sujetos a las pruebas de aceptacin, que pueden ser informales. Antes de iniciar con el desarrollo de los casos de uso de prueba se ve las siguientes caractersticas, las cuales sirven para tomar polticas de prueba: Es el requisito comprobable? Requisitos no funcionales (incluso los requisitos de la aplicacin) deberan ser examinados por una persona con experiencia y conocimientos en las pruebas. Si el requisito no es fcil de probar, ser difcil demostrar que ha sido implementado correctamente. Por ejemplo, un requisito que establece que "El sistema deber estar disponible las 24 horas del da, 365 das al ao" se tendra que probar durante un ao. Si el requisito est descrito en porcentaje de disponibilidad, tales como "El sistema deber estar disponible para su uso el 99% del tiempo", puede medirse por perodos cortos de tiempo y extrapolarse a perodos ms largos. El requisito es objeto de mltiples interpretaciones? Se debe considerar la posibilidad de la exigencia para cada uno de los requisitos que se han implementado, por ejemplo: "El sistema deber soportar conexiones simultneas de 500 usuarios y el tiempo de respuesta debe ser menor a los 2 segundos." Este requisito puede interpretarse de mltiples maneras. Una interpretacin pasiva seria: Los 500 usuarios estn conectados. Una interpretacin agresiva seria: los 500 usuarios solicitan informacin al mismo tiempo. Una interpretacin intermedia seria: el 10% de los 500 usuarios se desconectar, un 20% utilizar las funciones de bsqueda, un 10% adicionar un registro, un 30% correr los informes, un 20% solo navegar por la aplicacin y un 10% solo est conectado (sin actividad).
Se debe explicar que al momento de describir las polticas de prueba o el conjunto de casos de prueba se tiene que tener una gran experiencia o una muy buena orientacin, ya que se puede cometer errores que pueden causar una mala interpretacin. La piedra fundamental para disear los casos de uso de prueba es la descripcin de los casos de uso de la aplicacin. Dentro del ejemplo que se ha llevado en el transcurso de la documentacin se utilizar para esta etapa, el caso de uso Autenticar Empleado, del cual se disearn casos de uso de prueba, estos nos darn una perspectiva de cmo realizar la prueba de validacin. Caso de Uso Actores Resumen Autenticar Empleado Empleado (Jefe de Cocina, Recepcionista) El caso de uso se inicia cuando el Empleado quiere ingresar a la aplicacin, para esto debe introducir su cuenta y contrasea de acceso a una interfaz que le proporciona la aplicacin. Verificar si el actor tiene autorizacin para ingresar al manejo de la aplicacin.
Descripcin Accin del Actor(es) Pantalla 1 Respuesta del Sistema
415
Autenticar Empleado
Nombre de Cuenta
Escriba texto
A B
Contrasea
1. El caso de uso se inicia cuando el Empleado necesita ingresar a la aplicacin 2. Presenta una interfaz (Pantalla 1), en la cual debe ingresar el Empleado el Nombre de Cuenta (A) y la Contrasea (B) 3. Ingresa el Nombre de Cuenta (A) y la Contrasea (B) 4. Realiza un clic en el botn Autenticar (C) 5. Valida internamente comparando el Nombre de Cuenta y la Contrasea 6. Direcciona al men principal de la aplicacin para los Empleados Cursos Alternos Paso 5. Si la validacin es incorrecta la aplicacin presenta un mensaje de texto (D) con las siguientes palabras El Nombre de Cuenta o la Contrasea es Incorrecta Paso 5. Si la validacin del Nombre de cuenta no coincide con seis caracteres al inicio ms dos nmeros, la aplicacin debe presentar un mensaje de texto con las siguientes palabras Verifique el Nombre de Cuenta (seis caracteres ms dos nmeros) Requisitos no Funcionales Seguridad. El Nombre de Cuenta debe contener un total de 8 caracteres, los seis primeros deben ser letras, los dos ltimos nmeros. La contrasea, luego de realizar un clic en el botn de Autenticar (C) debe aplicarse, sobre esta, un algoritmo de encriptacin, para lograr una ptima integridad Facilidad de Uso Los mensajes relacionados a la utilizacin de la interfaz debe ser legibles, explicativos y de un color llamativo, para lograr un corto tiempo de aprendizaje en la utilizacin de la interfaz y una ptima comprensin. El Empleado tendr una autorizacin para la utilizacin de la aplicacin
Postcondiciones
Los casos de uso de prueba se deben describir de tal forma que validen el caso de uso de la aplicacin, para cumplir este objetivo se aplica una plantilla que ayuda a desarrollar los casos de uso de prueba, es la siguiente:
416
Nombre de Referencia del Caso de uso: Iteracin (Ciclo): DESCRIPCIN DEL CASO DE USO REQUISITOS
Nombre de Caso de uso como Archivo:
Nombre del Archivo con Guion:
Nombre del Archivo de Resultados y conclusiones: GUIN DE PRUEBA DE CORRIDA MANUAL ID TIPO NOTA DESCRIPCIN RESULTADO ARCHIVO RESULTADO DETALLE ESPERADO ESPERADO DEL RESULTADO
BREVE DESCRIPCIN DEL CASO DE USO PRECONDICIONES FLUJO BSICO SECCIN FLUJOS ALTERNOS POS CONDICIONES REQUISITOS NO FUNCIONALES Como se puede ver, la plantilla est en funcin de la descripcin del caso de uso de la aplicacin. Cada una de las partes describe la interaccin del actor con la aplicacin debe ser validada (probada) de forma manual. Se ve a continuacin como se llena la plantilla utilizando el caso de uso Autenticar Empleado. - Nombre de Referencia del Caso de Uso: Autenticar Empleado - Nombre del Caso de Uso como Archivo: algunas de las empresas que desarrollan software documentan separadamente los casos de uso, Rational RequisitePro permite gestionar un caso de uso de la aplicacin, adicionalmente utiliza el Microsoft Word para describir, a travs de una plantilla, el caso de uso. En esta oportunidad no se introduce el nombre del archivo para el caso de uso. - Nombre de Archivo con Guin: Se utiliza cuando el caso de uso esta fusionado con una escena o escenas de un software multimedia, sin embargo se puede utilizar para referirse a un conjunto de escenarios para el caso de uso. En este caso no se introduce ningn nombre de archivo con guion. - Iteracin (Ciclo): Se debe describir el ciclo de desarrollo que se lleva a cabo. En este caso es la Primera Iteracin denominada Administracin y Autorizacin. - Nombre del Archivo de Resultados y Conclusiones: Se debe introducir el nombre del archivo que contiene el resultado de las pruebas de este caso de uso. Cada nombre de archivo debe incluir la ubicacin fsica. - Descripcin del caso de uso y Guin de Prueba de Corrida Manual, solo son ttulos, los cuales representan el conjunto de interaccin y las actividades que se van a realizar al momento de llevar a cabo el caso de uso de prueba. - Requisitos: En esta columna hace una introduccin a la descripcin del caso de uso, en las siguientes filas de esta columna estar la descripcin de los casos de uso. - ID: Esta columna ser un nmero correlativo de las actividades que se harn por cada interaccin de los casos de uso. - Tipo: Esta columna est relacionada con la columna de Resultado. Existe dos posibles datos que se pueden introducir. Si va a ser un Paso o si ser Verificable (PV). Paso se colocar, si se va a realizar un clic por las opciones que presenta la aplicacin en sus diferentes interfaz hasta llegar a una donde se llevar a cabo la
417
actividad de verificacin y Verificable se colocar, si la operacin ha sido planificada en el descripcin del caso de uso de prueba, es decir se espera un resultado al momento de realizar el caso de prueba. Nota: Esta columna se puede utilizar de diferentes formas, una de estas es colocar una de las precondiciones descritas en el caso de uso, otra utilizacin es describir brevemente el funcionamiento de la aplicacin o su responsabilidad. Descripcin: Esta columna es la ms importante, ya que en esta se describe que es lo que se va a probar, es decir se debe describir el dominio de la prueba. Por ejemplo, si el probador est en una interfaz donde tiene que registrar un Producto a la venta, se debe describir el conjunto de datos que se introducirn que sean validos o incorrectos esto para ver el comportamiento de la aplicacin. Resultado Esperado: En esta columna se debe describir los posibles resultados esperados por el probador respecto a la columna de Descripcin. Est claro que esta columna ser llenada de acuerdo a los posibles resultados que el probador pueda definir. Archivo Esperado: Si dentro de la descripcin del caso de uso se describe la generacin de un archivo, este archivo debe ser evaluado y debe existir una conformidad, si no existiera una conformidad esta columna permitir describir los defectos o errores el archivo generado. Resultado: Se debe describir, en esta columna, el resultado que da la aplicacin o seleccionar entre Correcto o Defecto, para luego describir en la siguiente columna. Detalle del Resultado: Esta columna ser utilizada cuando exista una no conformidad con el comportamiento de la aplicacin, donde el resultado esperado sea insatisfactorio.
El primer paso es llenar la columna de DESCRIPCIN DEL CASO DE USO, como se puede ver a continuacin.
Nombre de Caso de uso como Archivo: Autenticar Nombre de Referencia del Caso de uso: Autenticar Empleado.doc Empleado Iteracin (Ciclo): Primer Ciclo DESCRIPCIN DEL CASO DE USO REQUISITOS GUIN DE PRUEBA DE CORRIDA MANUAL ID TIP O NOTA DESCRIPCIN RESULTADO ESPERADO ARCHIVO ESPERAD O RESULTAD O DETALLE DEL RESULTAD O Nombre del Archivo con Guion: No existe
Nombre del Archivo de Resultados y conclusiones: Autenticar Empleado (resultados) .doc
El caso de uso se inicia cuando el Empleado quiere ingresar a la aplicacin, para esto debe introducir su cuenta y contrasea de acceso a una interfaz que le proporciona la aplicacin. No tiene PRECONDICIONES 1. El caso de uso se inicia cuando el Empleado necesita ingresar a la aplicacin 2. La Aplicacin Presenta una interfaz (Pantalla 1), en la cual debe ingresar el Empleado el Nombre de Cuenta (A) y la Contrasea (B) 3. Ingresa el Nombre de Cuenta (A) y la Contrasea (B) 4. Realiza un clic en el botn Autenticar (C) 5. La Aplicacin Valida internamente comparando el Nombre de Cuenta y la Contrasea 6. La Aplicacin Direcciona al men principal de la
Paso
Se debe visualizar una interfaz que permita introducir una cuenta y una contrasea
Se visualiza correctamente los campos de Cuenta y Contrasea?
La visualizacin debe ser clara, sin abreviaciones ni en otro idioma que sea el castellano
Paso
Se debe permitir introducir letras y nmeros en el campo de Cuenta No sebe permitir introducir el campo cuenta caracteres que no sean letras ni nmeros. La aplicacin debe derivar al men principal
El campo Cuenta acepta letras y nmeros?
EL campo de Cuenta debe permitir la introduccin de letras y nmeros
Paso
El Campo Cuenta acepta caracteres que no sean letras y nmeros?
El campo Cuenta solo debe permitir introducir letras y nmeros
Paso
La Aplicacin deriva a una interfaz con opciones que permitan al actor realizar su
La Aplicacin muestra una interfaz con opciones estructuradas para el manejo
418
Universidad Privada del Valle Bolivia Unidad Acadmica Sucre aplicacin Empleados para los trabajo? del actor
No tiene SECCIN Paso 5. Si la validacin es incorrecta la aplicacin presenta un mensaje de texto (D) con las siguientes palabras El Nombre de Cuenta o la Contrasea es Incorrecta Paso 5. Si la validacin del Nombre de cuenta no coincide con seis caracteres al inicio ms dos nmeros, la aplicacin debe presentar un mensaje de texto con las siguientes palabras Verifique el Nombre de Cuenta (seis caracteres ms dos nmeros)
PV
Se debe introducir una cuenta que no est registrada
La Aplicacin visualiza un mensaje de error que identifica que la cuenta no existe? La aplicacin no visualiza ningn mensaje?
La aplicacin debe visualizar un mensaje identificando que la cuenta no existe. La aplicacin debe visualizar una imagen de conformidad de la estructura de la cuenta. La aplicacin debe visualizar un mensaje identificando que la estructura no es la correcta con el mensaje de Verifique el Nombre de Cuenta. La aplicacin debe mostrar un mensaje de autorizacin para la utilizacin de la aplicacin.
PV
PV
Se debe introducir una cuenta con seis caracteres al inicio ms dos nmeros: Robert12 Se debe introducir una cuenta errnea que no cumpla la estructura definida: Ro123ber
La aplicacin visualiza un mensaje de error que indica que la cuenta no tiene una estructura adecuada?
El Empleado tendr una autorizacin para la utilizacin de la aplicacin
Paso
Seguridad. El Nombre de Cuenta debe contener un total de 8 caracteres, los seis primeros deben ser letras, los dos ltimos nmeros. La contrasea, luego de realizar un clic en el botn de Autenticar (C) debe aplicarse, sobre esta, un algoritmo de encriptacin, para lograr una ptima integridad Facilidad de Uso Los mensajes relacionados a la utilizacin de la interfaz deben ser legibles, explicativos y de un color llamativo, para lograr un corto tiempo de aprendizaje en la utilizacin de la interfaz y una ptima comprensin.
PV
La aplicacin debe visualizar un mensaje de conformidad y de autorizacin para la utilizacin Debe verificarse en la base de datos la contrasea est cifrar.
La aplicacin visualiza un mensaje de conformidad que significa la autorizacin a la utilizacin de la aplicacin? La aplicacin debe cifrar la contrasea de acuerdo a un algoritmo HASH?
Dentro de la base de datos debe visualizarse la contrasea cifrar con el algoritmo HASH Se visualiza correctamente los mensajes y textos que describen los campos de forma ptima. Se visualiza correctamente la interfaz en los distintos navegadores.
10
PV
11
PV
Debe verificarse que los mensajes, descripcin de los campos, nombre de los botones sean legibles Debe verificarse la interfaz en entornos distintos a los que se ha desarrollado
La aplicacin visualiza de forma correcta y legible todas las palabras que se incluyen en los mensajes y campos? La aplicacin funciona en Internet Exploer, Mozzilla, Opera y FireFox?
En la descripcin de un Caso de Uso de Prueba se debe tomar en cuenta la funcionalidad (hace lo que debe), la fiabilidad (resistente a fallos) y el rendimiento (Lleva a cabo su trabajo de forma efectiva), con estos tres puntos de vista, el probador debe enfocarse para describir el caso de uso de prueba y sea un xito la prueba. La descripcin puede ser ms extensa y complicada, esto es depende de la experiencia del 419
probador y como se puede ver, esta etapa es una de las ms morosas y complicadas dentro del desarrollo de software. No debe olvidarse que solo se ha descrito, brevemente, una de las fases de prueba. El siguiente documento describir la captura de los defectos al momento de utilizar la aplicacin y el caso de uso de prueba descrito anteriormente.
420
EXAMEN DE FACILIDAD DE USO Luego de disear los casos de uso, los cuales permitirn validar la aplicacin desarrollada se puede planificar una verificacin de algunos de los requisitos no funcionales como la Facilidad de Uso, este atributo es uno de los ms importantes a cumplir. En este documento se da una breve propuesta para la revisin de este atributo. La Facilidad de Uso se ha convertido, hoy en da, en una de las caractersticas ms importantes en el desarrollo de software, la cual debe ser llevada juntamente con el ciclo de vida tradicional de desarrollo de software. La Facilidad de Uso por su importancia a llegado a ser una rama de la ingeniera denominada Ingeniera de Usabilidad, esta se encarga de proporcionar mtodos estructurados para lograr la Facilidad de Uso en el diseo de la interfaz de usuario, cuya principal idea es determinar objetivos, que se puedan medir repetidamente durante todo el desarrollo de software y evaluarlos, de esa forma asegurar que se hayan conseguido. La facilidad de uso, es la que da una visin sobre como el usuario final utilizar la interfaz de un determinado software. La interfaz ser la parte fundamental para que el usuario interacte y utilice de forma eficaz y eficiente el software que se desarrolle. Es necesario sealar, que la interfaz juega un papel importante entre la tecnologa y el usuario, debe da r la posibilidad que el usuario utilice la tecnologa en toda su capacidad [3]. Definiciones de la Facilidad de Uso Antes de iniciar con las caractersticas fundamentales, se dan tres definiciones de la Facilidad de Uso en distintos modelos de calidad: - La capacidad del software que permite que este sea comprendido, aprendido, utilizado y que garantice que este sea amigable para el usuario, cuando se emplee bajo las condiciones especificadas (ISO- 9126). - El esfuerzo necesario para aprender, operar, preparar entradas e interpretar la salida de un programa (McCall). - La medida en la cual un producto puede ser usado por usuarios especficos para conseguir objetivos especficos con efectividad, eficiencia y satisfaccin. Atributos de la Facilidad de Uso Existen distintos atributos y conceptos relacionados que describen la importancia de la calidad de la Facilidad de Uso, los cuales son complejos de medir y demostrar que se cumplen en un determinado software. Por ejemplo (Basado en la ISO-9126): - La Efectividad, se entiende como la precisin y la plenitud con las que los usuarios alcanzan los objetivos especificados. - La Facilidad de Aprendizaje, se entiende como la facilidad de ser recordado y la tasa de errores en el uso de los usuarios (en la medida en que este sea utilizado de forma amplia y profunda).
421
- La Eficiencia, se entiende por la relacin entre los recursos empleados y la precisin y plenitud con que los usuarios alcanzan los objetivos especificados. - Facilidad de Comunicacin, se entiende como un atributo del software que proporciona una interfaz de entrada y salida fciles de utilizar y amigables. - La Facilidad de Operacin, se entiende como la capacidad del producto del software para permitirle al usuario operarlo y controlarlo. - La Facilidad de Comprensin, se entiende como la capacidad del producto de software para permitirle al usuario entender si el software es conveniente, y cmo puede usarse para las tareas particulares y condiciones de uso. - La Atraccin, se entiende como la capacidad del software de ser amigable para el usuario. - Formacin, se entiende como la capacidad del software a brindar ayuda y permitir que nuevos usuarios apliquen el sistema. - Visibilidad, se entiende por la existencia de vinculacin entre cada accin y un objeto visible. - Comprensin Intuitiva, se entiende por la propiedad de que el objeto de una accin sea evidente y se explique as mismo. La Facilidad de Uso, es un factor muy importante que afecta a muchas etapas del desarrollo de software, incluso, Gadner Group indica que un 70% del esfuerzo en un proyecto est destinado a la Facilidad de Uso. Concepto de Interfaz de Usuario Todas estas caractersticas y atributos se utilizan para poder medir la calidad de la interfaz, propsito fundamental de la Facilidad de Uso. Se entiende por la palabra Interfaz como: Una superficie de contacto que refleja las propiedades fsicas de los que interactan, donde se realiza o instruye las funciones y se da el poder y el control sobre la tecnologa y los datos. La interfaz al ser pobre puede ocasionar muchos problemas al momento de utilizarla, podr reducir la productividad de los involucrados en su manejo, como tambin, un incremento en el tiempo de aprendizaje, llegando a cometer errores inaceptables respecto al manejo y al objetivo del trabajo. Debe ser diseada para todos los tipos de usuario que la imaginacin permita, no debe marginarse a ninguna de las personas que interactan con esta, incluso a algn usuario incapacitado fsicamente. Debe cumplir con los conceptos de ergonoma (adaptacin del hombre a la maquina), aspectos culturales de la empresa o nacionales y debe existir un lenguaje comn en todas las partes de esta. La interfaz es para el usuario el todo del sistema, no le interesa a este el cmo realiza el trabajo, en el caso del software, no le interesa que algoritmo se aplica para un clculo matemtico, como interacta con una red, ni con otro hardware, ni siquiera como el software asegura la integridad de los datos o como se manipulan internamente.
422
Para maximizar el cumplimiento de estas caractersticas generales descritas para la interfaz existen distintos modelos con el propsito de implementar y desarrollar la Facilidad de Uso como factor principal en el Software. Entre los modelos se encuentran: - Ingeniera de Usabilidad de Nielsen: Jacob Nielsen fue el primero que escribi un modelo sobre la Facilidad de Uso. Este modelo se divide en capas que representan un ciclo de vida para este atributo. - Modelo DUTCH (Designing for Users and Tasks from Concepts to Handles): Este modelo se basa en utilizar prototipos incrementales, donde al iniciar se presentan varios prototipos, se selecciona uno como partida para ser mejorado a medida que el software va desarrollndose, la seleccin y las mejoras deben ser evaluadas. - El Ciclo de Vida de la Ingeniera de la Usabilidad: D.J. Mayhew, detalla un modelo de ingeniera de la Usabilidad, dividido en tres fases; la primera se refiere al anlisis de requisitos, la segunda al diseo, prueba y desarrollo y la ltima a la instalacin. Estos modelos dan como resultado distintos beneficios al momento de llevarlos a cabo en el desarrollo de software, se puede sealar entre esos beneficios los siguientes: - Reduccin del tiempo de desarrollo. - Reduccin de los costes de mantenimiento. - Aumento de la productividad de los usuarios y la eficiencia de los procesos. - Mayor calidad del producto final. - Menor nmero de reclamaciones por parte de los usuarios. - Aumento de la satisfaccin de los usuarios y disminucin del estrs. - Reduccin del tiempo de ejecucin de tareas por parte de los usuarios y del nmero de errores en estas. - Mayores ventas y beneficios Normar ISO que referencian a la Facilidad de Uso Los beneficios, anteriormente citados, reflejan que la Facilidad de Uso no es un atributo que hay que cumplir sino que debe ser una manera distinta de pensar y desarrollar, debe estar incluida en el ciclo de vida de desarrollo. Por este motivo, la International Organization for Standardization (ISO), tiene publicaciones de normas que definen y establecen los esquemas para la evaluacin e inclusin en el ciclo de vida de desarrollo, como por ejemplo: - ISO 9241-11: Requisitos Ergonmicos para el Trabajo en Oficina con Monitores Visuales (VDTs)-Parte 11: Gua en la Facilidad de Uso. Describe un marco de trabajo para el proceso de diseo de un sistema basado en ordenadores centrado en el usuario para conseguir un sistema fcil de utilizar y de aprender. - ISO 9126: Especifica un modelo de calidad que clasifica los atributos de la calidad del software en seis caractersticas, que son adems divididas en sub-caractersticas. Estas sub-caractersticas se manifiestan externamente cuando el software se usa como una parte del sistema de cmputo (computadora), y son un resultado de los atributos internos del software. - ISO 19112: Es aplicable a los paquetes de software. Establece los requisitos para un paquete de software, as como la introduccin del como verificar el cumplimiento de esta serie de requisitos. Cada paquete de software debe estar terminado para poder aplicar esta norma.
423
- ISO 13407: Proporciona una orientacin sobre las actividades de diseo centradas en la persona a lo largo del ciclo de vida de sistemas interactivos basados en el ordenador. Describe el diseo centrado en el usuario como una actividad multidisciplinar que incorpora factores humanos. - ISO 9241-11: Explica que los beneficios de la Facilidad de Uso de los sistemas se miden fundamentalmente por el grado de consecucin de los objetivos previstos en relacin a la utilizacin de los recursos empleados para alcanzar esos objetivos y por el grado de aceptacin del producto por parte del usuario. - ISO 16071: Gua sobre accesibilidad para interfaces humanocomputadora, proporciona orientacin en el diseo de software que sea accesible y se conecte e interaccione con herramientas de apoyo tales como lectores de pantalla, el Braille y el software de amplificacin de pantalla. Luego de justificar la importancia de la Facilidad de Uso, se describen a continuacin pasos para realizar un examen de Facilidad de Uso, estos pasos forman parte de un conjunto de pasos que facilitan la revisin de este atributo Pasos para realizar el examen de Facilidad de Uso Paso 1. Se debe Describir de forma simplificada los alcances y funcionalidades de la aplicacin que se va a verificar. Paso 2. Realizar una encuesta y entrevista a los usuarios finales, con el propsito de obtener informacin de lo que esperan que realice la aplicacin. Se da un ejemplo de preguntas que pueden estar en la encuesta o para realizar una entrevista. Encuesta 1. A su parecer el usuario qu nivel de experiencia debe tener?, explique. 2. A su parecer cules son las tareas que debe hacer el usuario con la aplicacin?, explique. 3. Usted piensa que para interactuar con la aplicacin el usuario debe recibir un adiestramiento,
explique por qu? 4. Comparado con el sistema de informacin actual, qu nivel le da de complejidad a la nueva aplicacin? a. Muy simple b. Simple c. Media d. Compleja e. Muy compleja 5. Qu operaciones cree usted que pueden ser implementadas a futuro en la aplicacin? Paso 3. El usuario con la ayuda de una lista de comprobacin debe revisar las distintas caractersticas de la aplicacin Lista de Comprobacin Marcar con X dependiendo la respuesta SI o un NO. Sin embargo, el evaluador puede considerar que la pregunta No Corresponda a esta aplicacin (NC) con la aplicacin. VISIBILIDAD DE OBJETOS Nro PREGUNTAS SI NO NC OBSERVASIONES 1 Las imgenes que se utilizan llevan un mensaje
424
que aclara la imagen cuando el explorador tiene bloqueada la visibilidad de las imgenes? 2 Cada imagen, botn o mensaje est correctamente escrito? 3 Cada imagen, botn o mensaje est correctamente redactado? LENGUAJE 4 Botones, etiquetas y mensajes estn en el idioma Castellano? 5 Botones, mensajes y etiquetas no tienen abreviaciones? MENSAJES DE AYUDA 6 Existen mensajes dentro de cada interfaz diseada que ayuden a la lgica de la interfaz? 7 Existen mensajes que ayuden a determinar el error que comete el usuario? 8 Los mensajes de error aclaran y muestran la ubicacin del error? 9 Existen mensajes de error que tengan abreviaciones? 10 Existen mensajes que permitan recordar el manejo de la aplicacin? UNIFORMIDAD DEL DISEO GRFICO 11 Los botones en las distintas interfaces tienen el mismo aspecto (tamao, forma, tipo de letra, visibilidad)? 12 Se ha utilizado un banner superior que identifica a la aplicacin? EFICIENCIA 13 El tiempo de espera para recibir una respuesta no es ms de un Segundo? 14 Los usuarios se sienten con el control de la aplicacin?
Paso 5. Captar todos los defectos, ya sea con, los casos de uso de prueba y el examen de facilidad de uso. Para este paso de da una plantilla para registrar el defecto.
Solicitud de Cambio
Nombre de proyecto: <Nombre del Proyecto> Versin del Artefacto: Descripcin General del Artefacto: <Se debe describir las caracterisiticas, objetivos, propositos del artefacto. No debe olvidarse que un artefacto es cualquier cosa que se desarrolle. En esta explicacion, por ejemplo puede entrar incluso una interfaz de usuario dentro de la cual existe un defecto o un diagrama de casos de uso> Numero: <Numero de Estado del Artefacto: <Propuesto/ Aprobado/ Planificado/ Solicitud> implantado/ Cancelado> 425
Resumen del Defecto: <Explicar brevemente el objetivo y propsito de cambio> Tipo de Defecto: <Seleccionar el tipo de defecto> Descripcin Detallada: <Explicar de forma ordenada y de la mejor forma el defecto, se debe tratar de describir la posible causa> Impacto: <Explicar el impacto que produce y producir el defecto> Esfuerzo Estimado: <Estimar recursos (tiempo, costo y nmero de personas) y seleccione las herramientas que ayudaran a corregir el defecto> Planificacin de la correccin: <Planificar el tiempo estimado para la correccin del defecto y el como se la realizar> Descripcin de la correccin: <Explicar de que manera se ha corregido el defecto sealando la causa> Observaciones: <Si es necesario, redactar los detalles que puedan aparecer en el transcurso de la correccin del defecto>
La Facilidad de Uso de un software es un atributo de gran importancia que ha alcanzado una mayor connotacin con el surgimiento de las aplicaciones Web. Obtener una buena facilidad de uso en una aplicacin es necesario, ya que es un atributo que se debe construir a lo largo del ciclo de vida del producto de software, segn se mostr en los modelos existentes para este fin. La Facilidad de Uso debe controlarse en todo el ciclo de desarrollo, para as, asegurar que los objetivos y las normas se cumplan y no solo en el producto final como habitualmente se hace.
426
BIBLIOGRAFA
MSDN TRANING, Introduction to C# Programming for the Microsoft .NET Platform (Prerelease), 2001 Jos Antonio Gonzlez Seco, El lenguaje de programacin C#, 2002 Richard Anderson, Brian Francis, Alex Homer, Rob Howard, David Sussman, Karli WatsonProfessional ASP.NET 1.0 Special Edition, 2002 John Erik Hansen, Carsten Thomsen Enterprise Development with Visual Studio .NET UML and MSF, 2004 Division of Microsoft Corporation Developing Web Applications with Microsoft Visual Basic .NET and Microsoft Visual C# .NET, 2002 Jeff Ferguson, Brian Petterson, Jason Beres, Pierre Boutquin, Meeta Gupta, La Biblia de C#, 2003 Ramon Duraes, ASP.NET 2.0 - Visual Studio 2005, 2004 Danny Ryan y Tommy Ryan, ASP.NET, 2002 Adrian Turtschi, Jason Werry, Greg Hack, Joseph Albahari, C# . N ET Web Developers Guide 2002 Scott Mitchell, Bill Anders, Rob Howard, Doug Seven, Stephen Walther, Christop Wille y Don Wolthuis ASP.NET: Tips, Tutorials and Code, 2001 Mike Gunderloy, Developing and Implementing Web Applications with Visual Basic .NET and Visual Studio.NET, 2003 John Sharp, Microsoft C# 2005, step by step, 2006 Scott Short, Building XML Web Services for the Microsoft .NET Platform, 2002 By Stephen C. Perry, Core C# and .NET, 2005 Mike Gunderloy, Developing and Implementing Web Applications with Visual Basic.NET and Visual Studio .NET, 2003 Philippe Kruchten, The Rational Unified Process: An Introduction, 2004 Third UML Distilled: A Brief Guide to the Standard Object Modeling Language, 2003 Eric J. Naiburg, Robert A. Maksimchuk, UML for Database Design, 2001 Suzanne Robertson, James Robertson, Mastering the Requirements Process, 2006 Doug Rosenberg, Kendall Scott, Applying Use Case Driven Object Modeling with UML: An Annotated e-Commerce Example Cal Henderson, Building Scalable Web Sites, 2006 Raul Alarcon, Diseo Orientado a Objetos con UML, 2000 Ivar Jacobson, Grady Booch, James Rumbaugh, El Proceso Unificado de Rational, Addison Wesley, 2000 Kendall Scott, Fast Track UML 2.0, Apress, 2004. Michael Jesse Chonoles, James A. Schardt, UML 2 for Dummies, Wiley Publishing, 2003 Liliana Favre, UML and the Unified Process, IRM Press, 2003 Bhuvan Unhelkar, Process quality assurance for UML-based projects, Addison-Wesley, 2003 Dean Leffingwell, Don Widrig, Managing Software Requirements, Addison Wesley Longman, 2000 Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David Fado, UML 2 Toolkit, Wiley Publishing, 2004 Craig Larman, Applying UML and Patterns in OOA/D, 2001 Scott W. Ambler, John Nalbone, Michael J. Vizdos, The Enterprise Unified Process, Prentice Hall, 2005 427
Per Kroll, Philippe Kruchten, Rational Unified Process Made Easy, Addison Wesley, 2003 Joseph Schmuller, Sams Teach Yourself UML in 24 Hours, Sams Publishing, 2004 Tim Kasse, Practical Insight into CMMI, Artech House, 2004 Mary Beth Chrissis, Mike Konrad, Sandy Shrum, CMMI: Guidelines for Process Integration and Product Improvement, Addison Wesley, 2003
428

Desarrollo de Aplicaciones Web en MicroSoft C Modeladas en UML

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Desarrollo de Aplicaciones Web en MicroSoft C Modeladas en UML

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PRIVADA DEL VALLE DEPARTAMENTO DE SISTEMAS Y TECNOLOGA INFORMTICA

INGENIERA DE SISTEMAS INFORMTICOS CENTRO DE CMPUTO

DESARROLLO DE APLICACIONES WEB EN MICROSOFT C# .NET MODELADAS EN UML

Universidad Privada del Valle Bolivia Unidad Acadmica Sucre

Universidad Privada del Valle Bolivia Unidad Acadmica Sucre

APRENDA A DESARROLLAR UNA APLICACIN EN 48 HORAS

Grupo de Investigacin Univalle - 2006

Universidad Privada del Valle Bolivia Unidad Acadmica Sucre

Visual Studio .NET MS-SQL Server 2000 Lenguaje C# Rational Software

Grupo de Investigacin Univalle - 2006

Contenido Del Documento

I: Introduccin a la programacin en Microsoft C#.NET

Grupo de Investigacin Univalle - 2006

Contenido Del Documento

I: Introduccin a la programacin en Microsoft C#.NET

Grupo de Investigacin Univalle - 2006

Universidad Privada del Valle Bolivia Unidad Acadmica Sucre

Contenido Del Documento

II: : Ingeniera de Requisitos

Introducir y conocer la filosofa de las etapas de Ingeniera de Requisitos y Anlisis

Grupo de Investigacin Univalle - 2006

Contenido Del Documento

Grupo de Investigacin Univalle - 2006

aplicaciones de cualquier tipo (clsicas y Web)

Grupo de Investigacin Univalle - 2006

Universidad Privada del Valle Bolivia Unidad Acadmica Sucre

Contenido Del Documento

Grupo de Investigacin Univalle - 2006

Grupo de Investigacin Univalle - 2006

Grupo de Investigacin Univalle - 2006

Universidad Privada del Valle Bolivia Unidad Acadmica Sucre

Contenido Del Documento

Grupo de Investigacin Univalle - 2006

Contenido Del Documento

Grupo de Investigacin Univalle - 2006

Introduccin al Desarrollo de Software

Grupo de Investigacin Univalle - 2006

Universidad Privada del Valle Bolivia Unidad Acadmica Sucre

Introduccin al Desarrollo de Software

futuro para la aplicacin a desarrollar

Introduccin al Desarrollo de Software

Grupo de Investigacin Univalle - 2006

Universidad Privada del Valle Bolivia Unidad Acadmica Sucre

Introduccin al Desarrollo de Software

Grupo de Investigacin Univalle - 2006

Grupo de Investigacin Univalle - 2006

Grupo de Investigacin Univalle - 2006

Universidad Privada del Valle Bolivia Unidad Acadmica Sucre

Universidad Privada del Valle Bolivia Unidad Acadmica Sucre

Grupo de Investigacin Univalle - 2006

Grupo de Investigacin Univalle - 2006

Introduccin al Desarrollo de Software

Universidad Privada del Valle Bolivia Unidad Acadmica Sucre

Introduccin al Desarrollo de Software

Grupo de Investigacin Univalle - 2006

Grupo de Investigacin Univalle - 2006

Universidad Privada del Valle Bolivia Unidad Acadmica Sucre

Introduccin al Desarrollo de Software

Introduccin al Desarrollo de Software

Grupo de Investigacin Univalle - 2006

Universidad Privada del Valle Bolivia Unidad Acadmica Sucre

Cuatro puntos de la Calidad de Software

Grupo de Investigacin Univalle - 2006