Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. INDICE DE CONTENIDO INTRODUCCIN MARCO DE TRABAJO

Rev. Fecha 18/04/2006

FASE I: PLANIFICACIN Y ANALISIS DE REQUERIMIENTO (DPTO. PROCESOS) durante el levantamiento de informacin. grupos. FASE II: DISEO DE DIAGRAMAS UML Y PROTOTIPO (DPTO. DESARROLLO y PROCESOS) Diseo de Casos de Uso. Diseo de Diagrama de Clases Diseo de Diagrama Entidad-Relacin Verificacin de diseos UML con Dpto. de Procesos Diseo de prototipo Verificacin del prototipo con Dpto. de Procesos Entrega al usuario del prototipo. Ajustes a los resultados del prototipo. FASE III: CODIFICACIN (DPTO. DESARROLLO) pantallas en XHTML y CSS. Base de Datos. del sistema. FASE IV: PRUEBAS DEL SISTEMA (DPTO. DESARROLLO Y PROCESOS) XHTML y CSS por el estndar W3C. Validacin de cdigo Desarrollo de la lgica Implementacin de la Codificacin total de Funciones importantes. Aproximacin por Mtodos. Lineamiento a segur

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. Procesos.

Rev. Fecha 18/04/2006

Pruebas Parciales de Pruebas Usuario.

INTRODUCCIN La presente metodologa a desarrollar durante la realizacin de cualquier proyecto que involucre el desarrollo de software, tiene por objeto; el seguimiento de un estndar. El estndar a seguir est divididos en cuatro grandes fases, la primera se refiere a los procesos de requerimiento de informacin, esta es una de las tareas que establece una estrecha relacin con el cliente para estimar los parmetros del producto que requiere. En la fase dos se desarrollan todas las estructuras del sitio, sta permite llevar un plan esquematizado de toda la estructura a elaborar, mediante un lenguaje de comunicacin visual como lo son los diagramas UML. Seguidamente se encuentra la fase de codificacin que consiste en plasmar en lenguajes de programacin procesada en las fases anteriores. La siguiente fase es la de las pruebas, donde nos aseguramos que el software cumpla con los requerimientos del cliente y el nivel de calidad ofrecido por el equipo de trabajo. El propsito de manejar los estndares establecidos es para dar respuesta en tiempo real a los proyectos trazados por la empresa y as garantizar la entrega del producto final al cliente.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

CAPITULO I: MARCO DE TRABAJO Una vez definido y concretado el proyecto a desarrollar con el personal de mercadeo a cualquier cliente, se hace una reunin entre la Gerente de Operaciones, Mercadeo, Coordinadora de Procesos y Desarrollo, donde se realiza una planificacin estimada, para involucrar las etapas de normalizacin, desarrollo y operatividad del proyecto, para entregar al cliente. Recomendaciones para la elaboracin del plan de trabajo 1.-) Mantenerlo simple: Cada programa tiene varias caractersticas y cada caractersticas implica varias tareas, Una caracterstica es, por ejemplo, aadir un corrector ortogrfico al programa. Aadir un corrector ortogrfico consiste en un pequeo nmero de tareas bien definidas que el programador debe realizar. La parte ms importante de hacer un plan de trabajo es hacer esta lista de tareas. De ah la regla principal: Slo el programador que va a escribir el cdigo puede hacer su calendario. Cualquier sistema en el que el gerente crea el plan de trabajo y lo entrega a los programadores est condenado al fracaso. Slo el programador que va a realizar el trabajo puede darse cuenta de qu pasos necesitar para implementar esa caracterstica. Y slo el programador puede estimar cunto tiempo le llevar realizar cada uno. 2.-) Las tareas deben ser medidas en horas, no das. Cuando tienes que definir tareas muy granulares, tienes que forzarte a realmente pensar qu pasos tendrs que tomar. Escribir la subrutina xyz. Crear el dilogo tal y tal. Leer el archivo wawa. Estos pasos son sencillos de estimar, porque has escrito subrutinas, creado dilogos y ledo archivos wawa antes.
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Si se es descuidado, y se eligen tareas en bloques ("implementar correccin gramatical"), entonces no se ha pensado realmente acerca de lo que se va a hacer. Y cuando no se ha pensado en lo que se va a hacer, simplemente no se puede saber cunto tiempo va a tomar. Como regla general, cada tarea debe tomar de 2 a 16 horas. Si se tiene una tarea de 40 horas (una semana) en el plan de trabajo, no se est dividiendo suficientemente. He aqu otro motivo para escoger tareas granuladas: obliga a disear la caracterstica. Si se tiene una alegre caracterstica llamada "Integracin para Internet" y se planifica 3 semanas para ella, ests condenado, amigo. Si tienes que calcular qu subrutinas vas a tener que escribir, te obligas a definir la caracterstica. Al ser forzado a planificar de antemano a este nivel, se elimina mucha de la inestabilidad en un proyecto de software. 3.-) Tomar en cuenta los tiempos por Vacaciones, Asuetos, etc. Si el plan de trabajo va a durar cerca de un ao, cada programador probablemente tomar de 10 a 15 das de vacaciones. Se debe tener un rubro llamado vacaciones, uno asuetos y cualquier otra cosa que consume el tiempo de la gente. 4.-) Incluir el tiempo de correccin de errores en el plan. La correccin de errores es el tiempo ms difcil de estimar. Las probabilidades son que la correccin de errores tome de 100% a 200% del tiempo que tom escribir el cdigo en un inicio. Este debe ser un rengln ms en el plan de trabajo, y probablemente ser el ms largo. En principio, los desarrolladores deben corregir el cdigo conforme lo escriben. Un programador nunca, jams debera trabajar en cdigo nuevo si pudiera estar corrigiendo errores. La cuenta de errores debe mantenerse tan baja como sea posible todo el tiempo, por dos razones: 4.1) Es ms fcil corregir errores el mismo da que se hizo el cdigo. Puede ser muy difcil y tardado corregir problemas un mes despus cuando has olvidado exactamente cmo funciona el cdigo. 4.2) Corregir errores es como la ciencia. Es imposible estimar cundo realizars el descubrimiento y corregirs el error. Si slo estn pendientes dos errores en cualquier momento, es fcil estimar cundo se entregar el producto, porque no hay mucho de ciencia inestimable en el futuro. Por otro lado, si hay cientos o miles de errores pendientes, es imposible predecir cundo sern corregidos todos.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Si los programadores corrigen errores mientras avanzan, cul es el punto en tener un rengln para correccin de errores? Bien, an si intentas corregir todos los errores mientras avanzas, al final del proyecto hay inevitablemente una gran cantidad de correccin de errores cuando los encargados de las pruebas (internas y finales) encuentren los errores realmente difciles. 5.-) Incluir el tiempo de integracin en el plan de trabajo. Si se tiene ms de un programador, inevitablemente habr cosas que dos de ellos hacen de forma inconsistente y tendrn que ser reconciliadas. Ambos pueden implementar ventanas de dilogo para cosas similares que son innecesariamente inconsistentes. Alguien tendr que revisar todos los mens, teclas rpidas (Ctrl + A, Shift + C), barras de herramientas, etc., limpiando y organizando todos los nuevos elementos de men que todos han estado aadiendo alegremente. Habr errores de compilacin que surgirn hasta que dos personas hagan "check-in" de cdigo. Esto tiene que ser corregido, y debe ser un rengln ms en el plan de trabajo. 6.-) Nunca permitir que los administradores del proyecto pidan a los programadores reducir un tiempo estimado. Algunos administradores sin mucha experiencia piensan que pueden "motivar" a sus programadores a trabajar ms rpido dndoles planes de trabajo bonitos, "apretadamente" (irrealmente) cortos. Este tipo de motivacin es inefectiva, Cuando se est retrasado en un tiempo de entrega, la persona se siente condenada, deprimida y desmotivada. Cuando se est trabajando adelantado al plan de trabajo, el desarrollador se siente alegre y productivo. Cuando el proyecto inicia, los administradores tcnicos salen, hacen juntas con la gente del negocio, y regresan con una lista de caractersticas que ellos piensan debera tomar unos 3 meses, pero que en realidad tomara 9. Cuando piensas en crear cdigo sin pensar en todos los pasos que tienes que tomar, siempre parece que toma n tiempo, cuando en realidad probablemente tomar 3n tiempo. Cuando se hace un verdadero plan de trabajo, se suman todas las tareas y se dan cuenta de que el proyecto tomar mucho ms que lo originalmente planificado. La realidad sale a flote. Los administradores inexpertos tratan de solucionar esto descubriendo cmo hacer que la gente trabaje ms rpido. Esto no es muy realista. Probablemente se puedan contratar ms recursos, pero stos necesitan ponerse al corriente y probablemente estarn trabajando con una eficiencia del 50% durante varios meses (y disminuyendo la productividad de los que tienen que hacer de mentores.) De cualquier modo, en este mercado, aadir buenos programadores toma 6 meses.
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Es posible que puedas sacar un 10% de cdigo extra de la gente, temporalmente, con el costo de "quemarlos" en un 100% durante un ao. No es una gran ganancia, y es un poco como comerte la semilla de tu propio maz. Es posible que puedas obtener un 20% de cdigo extra de la gente suplicndoles que trabajen sper duro, sin importarles qu tan cansados terminen. Bum, el tiempo de correccin de errores se duplica. Una decisin idiota que rebota de vuelta en una forma esplndidamente krmica. 7.-) Un plan de trabajo es como bloques de madera. Si tienes un montn de bloques, y no puedes hacerlos entrar en una caja, se tienen dos opciones: obtener una nueva caja o quitar algunos bloques. Si se pensaba que era posible lanzar el producto en 6 meses, pero tienes 12 meses en el plan de trabajo, vas a tener que retrasar el lanzamiento o encontrar algunas caractersticas que quitar. Simplemente no se puede encoger los bloques, y si puedes fingir que puedes, entonces ests meramente privndote de la til oportunidad de realmente ver el futuro al mentirte a ti mismo acerca de lo que ves ah. Y ya se sabe, el otro gran subproducto de mantener un plan de trabajo de esta forma es que ests forzado a quitar caractersticas. Por qu es bueno esto? Supn que tienes dos caractersticas: una que es realmente til y har tu producto realmente bueno (ejemplo: tablas en Netscape 2.0), y otra que es realmente sencilla y los programadores adoraran desarrollar (ejemplo: la etiqueta BLINK), pero que no tiene ningn propsito til o de mercadotecnia. Si no haces un plan de trabajo, los programadores harn primero la caracterstica ms fcil/divertida. Despus empezarn a retrasarse, y no tendrs ms remedio que ajustar el plan para poder realizar la caracterstica til/importante. Si haces un plan de trabajo, an antes de empezar a trabajar, notars que hay que cortar alguna caracterstica, as que lo hars con la fcil/divertida y no con la til/importante. Al forzarte a escoger algunas caractersticas para quitar, terminas haciendo un mejor y ms poderoso producto con una mezcla mejor de buenas caractersticas que es lanzado antes. Dicha planificacin puede someterse a cambios debido a varios factores que pueden presentarse durante la ejecucin de cada una de las etapas del proyecto. En este momento es que se debe empezar a desarrollar la metodologa para el desarrollo de aplicaciones en software.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. FASE I: REQUERIMIENTO DE LA INFORMACIN

Rev. Fecha 18/04/2006

La presente fase indica los mtodos a seguir para levantar informacin de los procesos, tomando en cuenta todas aquellas brechas, cambios entre los procesos al momento de la automatizacin y discusin de los mismos durante las mesas de trabajo conjuntamente con los usuarios estratgicos de cada rea y los analistas involucrados durante el desarrollo del producto.

METODOS Para el desarrollo del levantamiento de la informacin se debe basar el analista de procesos en aplicar el MTODO DE INDAGACIN, cual trata en identificar los requerimientos del o los usuarios y del producto para satisfacer las necesidades de los mismos en el proceso de desarrollo, dentro de este mtodo de indagacin se encuentran la siguiente forma de aproximacin al usuario, descrita a continuacin. APROXIMACIN CONCEPTUAL Trata bsicamente en una entrevista, dada la necesidad de comprender el contexto y de incluir los requerimientos de los usuarios en el producto de diseo planteando un objetivo en su aplicacin. En este punto el formato aplicar es: FORMATO A APLICAR
Usuarios Estratgicos: Debe contener los nombres de las

personas encargadas por departamento o direccin en facilitar la informacin a documentar por procesos o tareas. Observacin al Natural: Se debe tener mayor inters en las tareas y procesos que involucren los requerimientos del cliente a automatizar, definiendo los procesos a documentar durante el levantamiento de los mismos. FORMATO A APLICAR
Procesos a Documentar: Debe contener los nombres de los

procesos a documentar por departamento o direccin. LINEAMINETOS A SEGUIR DURANTE EL LEVANTAMIENTO DE INFORMACIN

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Durante el proceso de levantamiento de informacin por parte del personal del Dpto. de Procesos, se debe llevar control de las visitas y procesos o tareas levantadas a travs de los puntos que se describen a continuacin. Realizar el llenado de una serie de formatos descritos que definen en forma general el proyecto, para hacer entrega al cliente en la primera visita que se realice. Documentar y ordenar en una carpeta con el nombre del proyecto.

Project Chartr: Es el acta constitutiva del proyecto, donde se indica Enunciado del Alcance: Describe los recursos y situaciones que el Matriz de roles y Responsabilidades: Permite identificar quienes Restricciones: Descripcin de los factores que limitarn la Matriz de Riesgos: Describir en forma general los riesgos que

los responsables, alcance, metas entre otros.

proyecto requiere para terminarlo exitosamente, es el Lmite del Proyecto.

son los responsables directos del equipo del proyecto.

ejecucin del proyecto.

puede presentar el proyecto. Documentacin detallada del proyecto de acuerdo a cada visita que se realice al cliente. Por cada proyecto se debe llevar una carpeta que debe contener La carpeta debe llevar una identificacin, que es el nombre del Durante cada mesa de trabajo que involucre la discusin de los tres divisiones: Documentacin, Minutas, Procesos con soporte. proyecto con el nombre del organismo. procesos se debe entregar al usuario una carpeta con la informacin correspondiente a la descrita anteriormente. Se debe manejar cada uno de los reportes descritos a continuacin, por proyecto y llevados ordenadamente en la carpeta correspondiente.

Minuta: Manejar este formato por cada visita y reunin al organismo

o institucin, firmado por las personas involucradas, con todos los acuerdos a que se llegue.

Usuarios Estratgicos: Debe contener los nombres de las

personas encargadas por departamento o direccin en facilitar la informacin a documentar por procesos o tareas.
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Procesos a Documentar: Identificar los procesos por departamento Etapas de Proyecto: Debe contener en forma general las etapas

o direccin.

del proyecto hasta la operatividad del mismo, con sus respectivo objetivos y fecha de inicio y terminacin de cada una, con a finalidad de que el usuario visualice y tenga conocimiento de las etapas que abarca el proyecto a desarrollar. Las fechas se toman sobre la base de la negociacin que llegue el personal de mercadeo.

Registro de Informacin Detallada: Realizar el levantamiento de

informacin de cada uno de los procesos, dicho formato destaca las etapas que debe seguir todo proceso como son: Entradas, Desarrollo y salida. De manera exhaustiva y ordenada con su respectivo soporte, que valide las entradas y salidas del proceso. (Reportes, ordenanzas o cualquier documento que soporte o emita el proceso.)

Control de Riesgos: Eventos que tienen la probabilidad de ocurrir

durante el proyecto y que su impacto puede ser medido, tomando como oportunidades los resultados positivos, dependiendo de la receptividad que se tenga por parte del cliente durante las visitas realizadas.

Status de Procesos: Formato que indica el porcentaje de avance Mesa de Trabajo: Este Formato debe contener por cada proceso

que se tiene de cada proceso durante el levantamiento de informacin.

las dudas, falta de informacin y soporte, que se deben comentar y solicitar durante el desarrollo de la mesa de trabajo con los usuarios involucrados, para completar la informacin por cada proceso en el caso que haya falta. FUNCIONES IMPORTANTES Comunicar a la Gerente de Operaciones, Coordinadora de Procesos o Desarrollo cualquier eventualidad presentada durante el levantamiento de informacin. Reunirse con la coordinadora para mantenerla al da con el desarrollo del proyecto.
Ser comunicativa para crear un ambiente de trabajo basado en el concepto

EQUIPO. Implementar mtodos o tcnicas que nos permitan mejorar la forma de trabajo. Visitar al cliente o estar en contacto para garantizar el xito del proyecto. Conocer los procesos de manera que cualquiera te pregunte y ests al da.
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Ser detallista ante las necesidades que manifiesta el cliente, para mantenerlo contento. Percatarse de estar al da en todos los movimientos que puedan ocurrir, para no perder de vista la meta a alcanzar. Ser clara y precisa al momento de comunicarse, demostrando seguridad ante el cliente. Llevar el control diario de sus actividades a travs de los reportes Informe de avance mensual.

APROXIMACIN POR GRUPOS Se realiza mediante el sometimiento de los usuarios representativos del proyecto a formular sus experiencias e impresiones con respecto a lo que se quiere como producto final proporcionando datos. Reunin Analistas Procesos con Analista de Desarrollo. En esta parte se revisa cada uno de los procesos levantados por mdulos, llamando mdulos cada uno de los departamentos, analizando las entradas, salidas, validaciones de datos, puntos de control de cada proceso, generando crticas de la situacin e ideas para la implementacin de las mismas, obteniendo al final un prototipo estructurado segn formato establecido. FASE II: DISEO DE DIAGRAMAS UML Y PROTOTIPO (DPTO. DESARROLLO y PROCESOS) El Lenguaje Unificado de Modelado (Unified Modeling Languaje, UML) es el lenguaje estndar para realizar el modelado de los sistemas de software y es independiente del lenguaje de programacin utilizado. Para facilitar la elaboracin de estos diagramas se cuenta con la herramienta Poseidn en su edicin Comunitaria, la cual permite el desarrollo de los diagramas UML de manera mucho ms sencilla que las herramientas graficas comunes. Diseo de Casos de Uso:

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Casos de Uso es una tcnica para capturar informacin de cmo un sistema o negocio trabaja, o de cmo se desea que trabaje. No pertenece estrictamente al enfoque orientado a objeto, es una tcnica para captura de requisitos.

Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y Permiten definir los lmites del sistema y las relaciones entre el sistema y el Los Casos de Uso son descripciones de la funcionalidad del sistema Comparacin con respecto a los Diagramas de Flujo de Datos del Enfoque Los Casos de Uso cubren la carencia existente en mtodos previos (OMT, Los Casos de Uso particionan el conjunto de necesidades atendiendo a la Estn basados en el lenguaje natural, es decir, es accesible por los

reacciones el comportamiento de un sistema desde el p.d.v. del usuario. entorno. independientes de la implementacin. Estructurado. Booch) en cuanto a la determinacin de requisitos. categora de usuarios que participan en el mismo. usuarios. Actores

Principales: personas que usan el sistema. Secundarios: personas que mantienen o administran el sistema. Material externo: dispositivos materiales imprescindibles que forman parte Otros sistemas: sistemas con los que el sistema interacta.

del mbito de la aplicacin y deben ser utilizados.

La misma persona fsica puede interpretar varios papeles como actores distintos, el nombre del actor describe el papel desempeado. Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interaccin, los escenarios, desde el punto de vista del usuario. Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estar dirigido por los casos de uso. Un escenario es una instancia de un caso de uso.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

UML define cuatro tipos de relacin en los Diagramas de Casos de Uso:

Comunicacin Inclusin : una instancia del Caso de Uso origen incluye tambin el

comportamiento descrito por el Caso de Uso destino. include reemplaz al denominado uses . Se suele utilizar para encapsular un comportamiento parcial comn a varios casos de uso. En la Figura se muestra cmo el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso Autorizacin.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Extensin : el Caso de Uso origen extiende el comportamiento del Caso de

Uso destino. extend . Cuando un caso de uso base tiene ciertos puntos (puntos de extensin) en los cuales, dependiendo de ciertos criterios, se va a realizar una interaccin adicional. El caso de uso que extiende describe un comportamiento opcional del sistema (a diferencia de la relacin incluye que se da siempre que se realiza la interaccin descrita) En la Figura se muestra como el caso de uso Comprar Producto permite explcitamente extensiones en el siguiente punto de extensin: info regalo. La interaccin correspondiente a establecer los detalles sobre un producto que se enva como regalo estn descritos en el caso de uso Detalles Regalo.

Herencia : el Caso de Uso origen hereda la especificacin del Caso de Uso

destino y posiblemente la modifica y/o ampla. Parmetros para la construccin de un caso de uso: Un caso de uso debe ser simple, inteligible, claro y conciso. Generalmente hay pocos actores asociados a cada Caso de Uso. Preguntas clave: 1. 2. 3. 4. Cules son las tareas del actor? Qu informacin crea, guarda, modifica, destruye o lee el actor? Debe el actor notificar al sistema los cambios externos? Debe el sistema informar al actor de los cambios internos?

La descripcin del Caso de Uso comprende:

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. 1. 2. 3. 4. 5. 6. 7. El inicio: Cundo y qu actor lo produce? El fin: Cundo se produce y qu valor devuelve?

Rev. Fecha 18/04/2006

La interaccin actor-caso de uso: Qu mensajes intercambian ambos? Objetivo del caso de uso: Qu lleva a cabo o intenta? cronologa y origen de las interacciones Repeticiones de comportamiento: Qu operaciones son iteradas? Situaciones opcionales: Qu ejecuciones alternativas se presentan en el

caso de uso? Diseo de Diagrama de Clases: 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. El mundo real puede ser visto desde abstracciones diferentes (subjetividad) Mecanismos de abstraccin: 1. 2. 3. 4. Clasificacin / Instanciacin Composicin / Descomposicin Agrupacin / Individualizacin Especializacin / Generalizacin

La clasificacin es uno de los mecanismos de abstraccin ms utilizados. La clase define el mbito de definicin de un conjunto de objetos, y cada objeto pertenece a una clase, Los objetos se crean por instanciacin de las clases. Cada clase se representa en un rectngulo con tres compartimientos:

nombre de la clase atributos de la clase operaciones de la clase

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Los atributos de una clase no deberan ser manipulables directamente por el resto de objetos. Por esta razn se crearon niveles de visibilidad para los elementos que son:

(-) Privado : Es l ms fuerte. Esta parte es totalmente invisible (excepto (#) Los atributos/operaciones protegidos estn visibles para las clases (+) Los atributos/operaciones pblicos son visibles a otras clases (cuando se

para clases friends en terminologa C++) friends y para las clases derivadas de la original. trata de atributos se est transgrediendo el principio de encapsulacin) Relaciones entre clases: Los enlaces entre objetos pueden representarse entre las respectivas clases y sus formas de relacin son:

Asociacin y Agregacin (vista como un caso particular de asociacin) Generalizacin/Especializacin.

Las relaciones de Agregacin y Generalizacin forman jerarquas de clases. Asociacin: La asociacin expresa una conexin bidireccional entre objetos. Una asociacin es una abstraccin de la relacin existente en los enlaces entre los objetos. Puede determinarse por la especificacin de multiplicidad (mnima...mxima)

Uno y slo uno 0..1 Cero o uno M..N Desde M hasta N (enteros naturales) * Cero o muchos 0..* Cero o muchos 1..* Uno o muchos (al menos uno)

Agregacin:

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

La agregacin representa una relacin parte_de entre objetos. En UML se proporciona una escasa caracterizacin de la agregacin. Esta relacin puede ser caracterizada con precisin determinando las relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos componentes. Una agregacin se podra caracterizar segn: Puede el objeto parte comunicarse directamente con objetos externos al objeto agregado? No => inclusiva Si => no inclusiva Puede cambiar La composicin del objeto agregado? Si => dinmica No => esttica Diagrama de Clases y Diagramas de Objetos pertenecen a dos vistas

complementarias del modelo. Un Diagrama de Clases muestra la abstraccin de una parte del dominio. Un Diagrama de Objetos representa una situacin concreta del dominio. Las clases abstractas no son instanciadas. Generalizacin: Permite gestionar la complejidad mediante un ordenamiento taxonmico de clases, se obtiene usando los mecanismos de abstraccin de Generalizacin y/o Especializacin. La Generalizacin consiste en factorizar las propiedades comunes de un conjunto de clases en una clase ms general. Los nombres usados: clase padre - clase hija. Otros nombres: superclase - subclase, clase base - clase derivada. Las subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) de la clase padre estn disponibles en sus clases hijas. La Generalizacin y Especializacin son equivalentes en cuanto al resultado: la jerarqua y herencia establecidas. Generalizacin y Especializacin no son operaciones reflexivas ni simtricas pero s transitivas. La especializacin es una tcnica muy eficaz para la extensin y reutilizacin. La nocin de clase est prxima a la de conjunto. Dada una clase, podemos ver el conjunto relativo a las instancias que posee o bien relativo a las propiedades de la
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

clase. Generalizacin y especializacin expresan relaciones de inclusin entre conjuntos Desarrollo de Diagramas de Clase durante el anlisis Aproximacin a un Caso de Uso guiado En una aproximacin a un Caso de Uso guiado hacia el anlisis orientado a objetos, el diagrama de clases se desarrolla a travs de informacin obtenida en los Casos de Uso, Diagramas de Secuencia y Diagramas de Colaboracin. Los objetos encontrados durante el anlisis son modelados en trminos de la clase a la que instancian, y las interacciones entre objetos son referenciados a relaciones entre las clases instanciadas.

Figura 7: Diagrama de Clase durante la fase de anlisis Extensin guiada por la responsabilidad La tcnica de la tarjeta CRC se usa a veces como una extensin a UML para anlisis guiados por la responsabilidad. Las definiciones de clase son refinadas basndose en las responsabilidades de clase y en otras clases con las que colabora para completar sus responsabilidades.
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Cada clase se representa en una tarjeta ndice (index card), y los diseadores establecen los papeles (roles) de las clases en el sistema para definir su trabajo, y con qu otras necesitan colaborar para completar sus responsabilidades. Esta informacin se pasa directamente a un diagrama de clase; las responsabilidades coinciden con los mtodos de clase, las colaboraciones se traducen en asociaciones entre clases.

Figura 8: Extensin informal de UML -- Tarjetas CRC para anlisis guiados por la responsabilidad. Diseo del sistema con Diagramas de Clase Durante el diseo, el Diagrama de Clase se elabora para tener en cuenta los detalles concretos de la implementacin del sistema. Arquitecturas Multicapas

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Una vez concienciados del diseo, estableceremos la arquitectura del sistema. Esto incluye establecer si ser un sistema simple diseado para correr en una sola mquina, un sistema 'two-tiered' consistente en un cliente y un servidor, o un sistema 'multi-tiered' con objetos interfaz de usuario separados de los objetos 'business', separado de la base de datos, cada uno corriendo en plataformas distintas. Una aproximacin a dirigir el diagrama de clase para un sistema complejo es separar el diagrama en secciones que muestren la lgica de la aplicacin, el diseo de la interfaz de usuario, y las clases implicadas con el almacenamiento de los datos. Esto se puede hacer fsicamente segmentando el diagrama de clase, usando diagramas separados para cada seccin, o simplemente aadiendo una propiedad a cada clase que 'tracks' cada 'tier' al cual pertenece. Diseo de Componentes Un componente es un grupo de objetos o componentes ms pequeos que interaccionan entre ellos y se combinan para dar un servicio. Un componente es similar a una caja negra, en la cual los servicios del componente se especifican por su interface o interfaces, sin ofrecer conocimiento del diseo e implementacin internas del componente. El desarrollo basado en componentes es el proceso de ensamblar la combinacin correcta de componentes en la configuracin correcta para llevar acabo la funcionalidad deseada para un sistema. Los componentes se representan en el diagrama de clases de UML especificando la interfaz de una clase o paquete. Hay dos notaciones para mostrar una interfaz - una es mostrar la interfaz como una 'regular class symbol' con el estereotipo "interfaz", con una lista de operaciones soportadas por esta interfaz, detalladas en el 'operation department' (departamento de operacin). 'The alternate, shortcut notation' es mostrar la interfaz como un circulo pequeo junto con la clase con una lnea slida, con el nombre de la interfaz en el crculo. El ejemplo de la Figura 9 muestra que la clase 'Pasajero' ofrece la operacin move(x coord, y coord) para su apariencia en un GUI, a travs de su interfaz 'Displayable'. Ambas notaciones UML de interfaz, se muestran en la figura. Adems, la clase Pasajero tambin ofrece una opcin save(store at) a travs de su interfaz Persistente. Una clase de o componente para conectar con una base de datos podra usar esta interfaz.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Figura 9: Diseo de Componentes: Especificando la Interfaz de la Clase Anlisis y diseo 'Iterative' El diagrama de clase se puede desarrollar en una 'iterative fashion', a travs de un ciclo repetido de anlisis, diseo e implementacin, y despus vuelta al anlisis, para empezar el ciclo de nuevo. Este proceso se suele llamar 'round-trip engineering'. El modelado de herramientas como System Architect 2001 puede facilitar este proceso permitindote implementar el diseo en un lenguaje como C++ o Java, y despus traer de vuelta al cdigo a al diagrama de clase, automticamente actualizando la informacin contenida en el diagrama y en el 'underlying repository'.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Figura 10: Anlisis, diseo y documentacin 'Iterative' con el Diagrama de Clase

Diseo de Diagrama Entidad-Relacin: Tcnica de anlisis basada en la identificacin de las entidades y de las relaciones que se dan entre ellas en la parte de realidad que pretendemos modelar. El modelo E/R permite representar de forma abstracta los datos que se pretenden almacenar en la base de datos. Elementos del modelo E/R Entidad: Objeto, real o abstracto, distinguible de otros objetos. Al grupo de entidades con cualidades similares acerca de los cuales se almacena informacin se le denomina TIPO (o, simplemente, conjunto de entidades). p.ej. Un libro concreto o un escritor Atributo: Propiedad asociada a un conjunto de entidades (esto es, mediante los atributos representamos propiedades de los objetos). Para cada atributo hay un conjunto de valores permitidos llamado DOMINIO. p.ej. Del libro: Ttulo, ISBN, edicin, nmero de pginas Del escritor: Nombre, apellidos, fecha de nacimiento Clave: Conjunto de atributos que permite identificar unvocamente a una entidad
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. dentro de un conjunto de entidades. p.ej. Del libro: ISBN Del escritor: (nombre, apellidos, fecha de nacimiento) Relacin (conexin o asociacin): Conexin semntica entre dos conjuntos de entidades. p.ej. Relacin entre los escritores y los libros que han escrito. Bases de Datos 5 Fernando Berzal Ejemplo de diseo

Rev. Fecha 18/04/2006

Diseo conceptual de la estructura de la base de datos de una Facultad NOTA: No existe una forma nica de modelar un problema. Requerimientos (restricciones semnticas) - Cada profesor pertenece a un solo departamento. - Todo profesor pertenece a algn departamento. - Todo departamento debe tener un director, que es un profesor. - Un profesor puede impartir varios grupos de la misma o diferentes asignaturas. - Un grupo de una asignatura ha de estar impartido por, al menos, un profesor. - Las asignaturas se imparten en clases en das, horas y aulas determinadas. - Los alumnos se matriculan de varias asignaturas (al menos una). - Una asignatura puede tener varios alumnos matriculados. - Los atributos de cada entidad son los habituales.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Tipo de entidad Grupo de objetos que tienen las mismas propiedades y que en la organizacin para la
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

que va a servir la BD tienen una existencia independiente, bien sea fsica o abstracta.

Representacin de la cardinalidad mxima de una relacin

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Relacin involutiva Relacin de un tipo consigo mismo E/R clsico Notacin UML
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. Atributos

Rev. Fecha 18/04/2006

Claves o Superclave: Conjunto de atributos que permite identificar unvocamente a una entidad dentro de un conjunto de entidades. o Clave candidata: Superclave con un nmero mnimo de atributos.
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

o Clave primaria: Clave candidata elegida por el diseador de la base de datos para identificar unvocamente a las distintas entidades de un tipo. o Clave alternativa: Cualquiera de las claves candidatas no elegidas por el diseador de la base de datos.

Claves de una relacin Las claves nos permiten diferenciar entre s las distintas entidades concepto que podramos aplicar de la siguiente forma a las relaciones: Las claves de las relaciones vienen definidas por las claves de las entidades relacionadas: - Relaciones muchos a muchos (N:M): La clave primaria ser la unin de las claves primarias de las entidades participantes en la relacin. - Relaciones uno a muchos (1:N): La clave primaria de la entidad que interviene en la relacin con aridad N. - Relaciones uno a uno (1:1): Las claves primarias de las entidades participantes son claves candidatas de la relacin entre entidades. Bases de Datos 11 Fernando Berzal Entidades fuertes y entidades dbiles Un tipo de entidad es fuerte si la existencia de sus ocurrencias no depende de ningn otro tipo. En caso contrario, se dice que el tipo de entidad es dbil.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Un apunt(entidad dbil) slo puede existir asociado a una cuenta (entidad fuerte). ave primaria entidad dbil = Clave primaria entidad fuerte + Discriminante Especializacin y generalizacin Supertipo Tipo de entidad que incluye uno o ms subgrupos distintos de ocurrencias que deben ser representados en el modelo de datos. Subtipo Cada uno de los subgrupos de ocurrencias de un tipo de entidad que se han de representar en el modelo de datos. Especializacin Proceso de extraer diferencias entre las ocurrencias de un tipo de entidad para distinguir los subtipos que lo forman. Generalizacin Proceso de encontrar la parte comn de las ocurrencias de distintos tipos de entidad para extraer el supertipo que los engloba. Relacin de especializacin (relacin ES-UN) Relacin que se establece en un diagrama E/R entre un supertipo y sus subtipos.

- Los subtipos heredan los atributos de los supertipos: Los subtipos poseen todos los atributos del supertipo ms algunos propios. - La clave primaria de los subtipos es la clave primaria del supertipo. Restricciones en las relaciones de herencia
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

- Participacin: Determina si un miembro de la superclase debe obligatoriamente ser un miembro de una subclase. - Exclusividad: Determina si un miembro de una subclase puede ser a la vez miembro de otras subclases. Verificacin de diseos UML con Dpto. de Procesos: Una vez desarrollados los diagramas UML, se procede a discutirlos con los analistas del Departamento de Procesos para verificar si la informacin ha sido comprendida correctamente. Diseo de prototipo: En base a los resultados obtenidos en la verificacin de diseos UML hecha con el Departamento de Procesos, el analista de desarrollo procede a disear el prototipo que ver el cliente. Este diseo debe ser implementado en XHTML 1.0 Transitional, ya que esta definicin es compatible con antiguos navegadores, en el futuro se debe utilizar XHTML 1.0 Strict, para manejar los estilos del sitio se debe utilizar CSS 2.0 o superior, se debe ser cuidadoso en chequear que nuestro cdigo cumpla con los estndares de calidad brindados por la World Wide Web Consortium1, de ahora en adelante nos referiremos a ella como la W3C. XHTML XHTML, acrnimo ingls de eXtensible Hypertext Markup Language (lenguaje extensible de marcado de hipertexto), es el lenguaje de marcado pensado para sustituir a HTML como estndar para las pginas web. XHTML es la versin XML de HTML, por lo que tiene, bsicamente, las mismas funcionalidades, pero cumple las especificaciones, ms estrictas, de XML. Su objetivo es avanzar en el proyecto del World Wide Web Consortium de lograr una web semntica, donde la informacin, y la forma de presentarla estn claramente separadas. En este sentido, XHTML servira nicamente para transmitir la informacin que contiene un documento, dejando para hojas de estilo (como las hojas de estilo en cascada) y JavaScript su aspecto y diseo en distintos medios (ordenadores, PDAs, telfonos mviles, impresoras).
1

http://www.w3.org
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Ventajas Las principales ventajas del XHTML sobre otros formatos son: Compatibilidad parcial con navegadores antiguos: la informacin se visualiza, aunque sin formato. Apuntar que el XHTML 1.0 fue diseado expresamente para ser mostrado en navegadores que soportan HTML de base.

Un mismo documento puede adoptar diseos radicalmente distintos en diferentes aparatos, pudiendo incluso escogerse entre varios diseos para un mismo medio. Facilidad de edicin directa del cdigo y de mantenimiento. Formato abierto, compatible con los nuevos estndares que actualmente est desarrollando el W3C como recomendacin para futuros agentes de usuario o navegadores. Los documentos escritos conforme a XHTML 1.0 pueden potencialmente presentar mejor rendimiento en las actuales herramientas web que aquellos escritos conforme a HTML.

Inconvenientes Algunos navegadores antiguos no son totalmente compatibles con los estndares, lo que hace que las pginas no siempre se muestren correctamente. Esto cada vez es menos problemtico, al ir cayendo en desuso.

Muchas herramientas de diseo web an no producen cdigo XHTML correcto.

Diferencias entre HTML y XHTML Al ser XML, se exige: Incluir siempre la etiqueta "doctype" apropiada. Todas las etiquetas deben cerrarse, aunque sea poniendo una barra "/", como, por ejemplo: <br> pasa a ser <br />.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

No se permite abreviar los atributos, por lo que todos los atributos deben tener un valor y este debe de estar entrecomillado. El cdigo es sensible a maysculas y minsculas. Los nombres y atributos de todas las etiquetas deben estar escritos en minsculas.

Para cumplir con el objetivo de lograr una web semntica se desaprueba el uso de elementos y atributos de formato a favor de utilizar hojas de estilo en cascada. En este aspecto, la especificacin 2 del estndar no admite las etiquetas <center> ni <font>. Hojas de estilo en cascada (CSS) Las hojas de estilo en cascada (Cascading Style Sheets, CSS) son un lenguaje formal usado para definir la presentacin de un documento estructurado escrito en HTML o XML (y por extensin en XHTML). El W3C (World Wide Web Consortium) es el encargado de formular la especificacin de las hojas de estilo que servir de estndar para los agentes de usuario o navegadores. La idea que se encuentra detrs del desarrollo de CSS es separar la estructura de un documento de su presentacin. Por ejemplo, el elemento de HTML <H1> indica que un bloque de texto es un encabezamiento y que es ms importante que un bloque etiquetado como <H2>. Versiones ms antiguas de HTML permitan atributos extra dentro de la etiqueta abierta para darle formato (como el color o el tamao de fuente). No obstante, cada etiqueta <H1> deba disponer de la informacin si se deseaba un diseo consistente para una pgina, y adems, una persona que lea esa pgina con un navegador pierde totalmente el control sobre la visualizacin del texto. Cuando se utiliza CSS, la etiqueta <H1> no debera proporcionar informacin sobre como va a ser visualizado, solamente marca la estructura del documento. La informacin de estilo separada en una hoja de estilo, especifica cmo se ha de mostrar <H1> : color, fuente, alineacin del texto, tamao, y otras caractersticas no visuales como definir el volumen de un sintetizador de voz, por ejemplo.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

La informacin de estilo puede ser adjuntada tanto como un documento separado o en el mismo documento HTML. En este ltimo podran definirse estilos generales en la cabecera del documento o en cada etiqueta particular mediante el atributo "style". Las ventajas de utilizar CSS (u otro lenguaje de estilo) son: Control centralizado de la presentacin de un sitio web completo con lo que se agiliza de forma considerable la actualizacin del mismo.

Los Navegadores permiten a los usuarios especificar su propia hoja de estilo local que ser aplicada a un sitio web remoto, con lo que aumenta considerablemente la accesibilidad. Por ejemplo, personas con deficiencias visuales pueden configurar su propia hoja de estilo para aumentar el tamao del texto o remarcar ms los enlaces. Una pgina puede disponer de diferentes hojas de estilo segn el dispositivo que la muestre o incluso a eleccin del usuario. Por ejemplo, para ser impresa, mostrada en un dispositivo mvil, o ser "leda" por un sintetizador de voz. El documento HTML en s mismo es ms claro de entender y se consigue reducir considerablemente su tamao.

Cada una de las pantallas del prototipo, se harn tomando como base formularios ya diseados por el equipo de desarrollo y diseo de la empresa, con el fin de facilitar y agilizar la construccin de prototipos, estos formularios se apegan a los estndares anteriormente discutidos y pueden ser descargados en el servidor de versiones (Subversion) svn://subversion/prototipo

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Verificacin del prototipo con Dpto. de Procesos El prototipo, una vez terminado debe ser verificado con el departamento de procesos para validar que no se estn omitiendo detalles importantes para la funcionalidad requerida por el cliente. Entrega al usuario del prototipo. En esta etapa se revisa el prototipo conjuntamente con el usuario realizando una corrida en fri de cmo seria el proceso automatizado. Obteniendo del usuario crticas e ideas de la situacin presentada para la mejora del prototipo presentado. Ajustes a los resultados del proceso y prototipo Realizar las respectivas correcciones del proceso y prototipo en el caso que las haya conjuntamente con el equipo de trabajo, para luego realizar entrega formal de toda la documentacin por parte de procesos al personal de desarrollo para la ejecucin del proyecto. FASE III: CODIFICACIN (DPTO. DESARROLLO) Codificacin total de pantallas en XHTML y CSS Las pantallas principales del sistema son diseadas en la fase II junto con el prototipo del sistema, sin embargo en esta fase se complementan con las otras pantallas que forman el total del sistema para complementar la etapa de diseo grfico, para un diseo ptimo del sistema es importante la semntica en la web, como veremos a continuacin. Web Semntica Al trabajar con xhtml y css, la idea es poder separar el contenido de la presentacin. Por eso es especialmente importante que el cdigo est bien estructurado y describa el contenido, es decir, que sea semnticamente correcto. Semntica Proviene del griego "semantikos", que quera decir "significado relevante", derivada de "sema", lo que significaba "signo") Se dedica al estudio del significado de los signos
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

lingsticos y de sus combinaciones, desde un punto de vista sincrnico o diacrnico. (definicin de wikipedia) O sea que la semntica, aplicada a la web, tendra que ver con el significado de las cosas, y de las relaciones de unas con otras. Parecera que esto no tiene nada que ver con un diseador o desarrollador, sino de quien se encargue del contenido. Pero el contenido no es lo nico que tiene un significado. El cdigo que usado para estructurar y presentar este contenido tambin lo tiene, y es importante que est de acuerdo con el contenido. El html es un lenguaje que da estructura a un documento a travs de etiquetas. Por ejemplo, al poner las etiquetas <p> y </p> alrededor de un texto, estamos designando ese texto como un prrafo. Al usar las etiquetas <em> y </em> denotamos nfasis. Entre las buenas prcticas del uso de cdigo semntico podemos encontrar: Para un ttulo, utiliza encabezados (headings), tales como h1, h2, h3... Para prrafos, utiliza el elemento <p> Para listas, el elemento <li> Utiliza tablas solamente para informacin tabular, no para acomodar elementos de tu pgina.

Utiliza siempre hojas de estilo para definir tu presentacin. Trata de usar las imgenes que no sean contenido como fondo de tus elementos, definidos en hojas de estilo. En tus hojas de estilo, nombra tus ids y clases de una manera clara, de acuerdo al contenido y no a la presentacin. Por ejemplo, #pr1 no tiene ningn valor semntico, mientras que #tituloprincipal si; si nombras una clase .azul qu pasa el dia que lo quieres cambiar por rojo? .enfasis, por ejemplo, funciona mejor.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. Maquetado de XHTML y CSS Por qu maquetar con estndares? Tablas

Rev. Fecha 18/04/2006

Las tablas existan como el resto de etiquetas HTML, pero la introduccin de "border=0" hizo posible que los diseadores de pginas web contran con una rejilla para organizar texto e imgenes y maquetar nuestras pginas. Hasta entonces las tablas se haban utilizado para lo que haban nacido: para organizar datos tabulares. Posteriormente y gracias a las imgenes transparentes se podan fijar tamaos, posicionar celdas, prrafos, imgenes y una serie de trucos destinados a que la pgina se "viese bien" en todos los navegadores. La "guerra de navegadores" supuso el alejamiento de los estndares marcados por la W3C, all por 1999. Lo que complicaba an mas el cdigo y en ocasiones se acuda a distintas versiones para distintos navegadores. Qu tiene de malo maquetar con tablas? Se puede afrontar desde varios puntos de vista, el primero puede ser el semntico: sencillamente no es lo correcto, no se crearon para eso y no se deben utilizar para eso. Trabajando de esta forma mezclamos presentacin y contenido. De esta forma las tablas deben dejarse para lo que sirven: presentacin de datos tabulares. Si queremos fijarnos en objetivos para la empresa: trabajando con estndares un rediseo, un cambio, una modificacin a nivel de diseo grfico es ms rpido y por tanto menos costoso. Las pginas sern ms accesibles. Los archivos son menos pesados con lo que ser menor el tiempo de descarga, menor el consumo de ancho de banda y menor espacio en el servidor. Por qu utilizar CSS y XHTML?

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Porque los navegadores actuales van teniendo soporte para estndares, con diferencias, pero se han acercado al estndar. Una vez te acostumbras a sus peculiaridades se puede trabajar para todos ellos. Por otro lado, la diversidad de dispositivos actuales y futuros desde los que nos podemos conectar (telfonos mviles, PDAs. Tablet PC, TV) hace que sea necesario separar estructura y contenido, siempre y cuando queramos llegar a cubrir todos los mbitos. De esta forma con simples cambios en las hojas de estilo, podremos visualizar nuestra aplicacin web en todos los dispositivos, adaptando su apariencia al dispositivo. Garantizar la accesibilidad de un sitio es ms fcil si cumplimos estndares. Ventajas Accesibilidad. Separar forma y contenido permite hacer llegar la informacin a diferentes dispositivos, navegadores, lectores de pantalla. Posibilitando en buena medida el acceso a personas con discapacidad. Ancho de banda. Para sitios con muchas visitas trabajar con estndares puede representar un ahorro muy grande. Reduciendo costes con el envo de informacin innecesaria al usuario. Pginas construidas con XHTML y CSS pueden llegar a reducir un 50% el tamao de la pgina original. Tiempos de carga. Menos cdigo hace que las pginas tarden menos en cargar mejorando la experiencia de usuario. La cualidad ms apreciada por los usuarios en un site es la velocidad de descarga. Un usuario medio tarda 10 segundos en perder la atencin en la mquina. Buscadores. Una pgina diseada con estndares aparecer en mejor posicin en los resultados de bsqueda debido a que el cdigo es ms limpio, las pginas slo llevan contenido (no diseo), semnticamente es ms correcto. La accesibilidad est ligada al posicionamiento en buscadores, google navega como si fuese "ciego".

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Independencia del dispositivo. El uso de estndares facilita el acceso al contenido de las pginas Web a travs de diferentes navegadores y dispositivos. Por lo tanto el mismo sitio Web puede usarse tanto en un telfono mvil como en el PC, TV, impresora, slo tocando un archivo (CSS) Utilizar estndares puede significar llegar al 100% de los usuarios que visitan la red. Mantenimiento. Al separar estructura y presentacin se permite realizar cambios en todo el sitio editando un nico archivo. Cuando se requiera un cambio de aspecto tiempo y coste sern muy reducidos. No es necesario tocar las pginas desarrolladas ni cambiar contenido del sitio. Control por parte del usuario. El usuario del sitio tiene el control sobre la pgina, independientemente del dispositivo con el que se conecte. La personalizacin de su navegador le ser til para visitar el sitio. El usuario puede modificar a su antojo tamaos de letra, colores, botones. Futuro. Los Navegadores se estn adaptando a los estndares, de esta forma se garantiza la viabilidad de los proyectos a largo plazo. CSS 2.0 es compatible con el 99% de los navegadores y, si se usa bien, sirve para cualquier plataforma. Un sitio desarrollado con estndares utiliza una tecnologa fcilmente compatible con otros productos. Gestin. Las partes de la pgina pueden ser cambiadas de disposicin, diseo, tamao en funcin del dispositivo, la pgina. Por lo que ya no hace falta montar pginas para imprimir, para PDAs.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. Patrones de Diseo

Rev. Fecha 18/04/2006

Un patrn describe una solucin ptima a un problema comn dentro de un contexto especfico. El arquitecto Christopher Alexander fue el primero en nombrar este fenmeno con respecto a espacios vivos. l y sus co-escritores introdujeron el concepto de los patrones de la arquitectura para describir las caractersticas que los espacios vivos comparten, ya sean cuartos, edificios o ciudades. Los patrones son atmicos y pueden ser agrupados para formar patrones ms complejos: un patrn silla jerarquiza dentro de un patrn comedor, este jerarquiza dentro de un patrn casa, el mismo jerarquiza dentro de un patrn ciudad. Cada patrn tiene cuatro componentes primarios: 1. Un ttulo 2. Un problema 3. Un contexto 4. Una solucin La empresa Yahoo Inc. ha liberado sus patrones de diseo de sitios web. Aprovechando la experiencia y conocimiento generado por el transcurso de varios aos de esta empresa, utilizamos como base estos patrones de diseo. Entre los Patrones tenemos los siguientes: Transicin Animada Resumen del Problema: El diseador necesita comunicar que un objeto esta cambiando su relacin espacial dentro de la pgina.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Use When A direct remove and appear in another place on the page would be a jarring or confusing way to show what just happened. To show how an object has changed places or containment on a page. Solution Move an object across the page animating the in-between positions (tweening). Moving an object can communicate: Its relative importance has changed (depends on where it is moved to). The object is now related to something else (as in dropping in a list, scheduling on a calendar day, etc.)

Animate the object itself moving into place; or Animate zoom rectangles showing where the object is moving.

The function of the object has changed (based on what it is now associated with spatially).

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Be careful not to overuse animated moves -- especially when the move is not initatited by a user action.

Examples Drop an object and it moves into the correct location (animates the move). A live feed dynamically tracks the most important stories. As new items come in, older stories move down in priority.

Closing/Opening a window animates a moving zoom box to indicate where the object is going or coming from.

Rationale In our everyday world, objects occupy real space and don't normally instantly appear and disappear. We throw a piece of trash into the trashcan and see it leave our hand and go through the air into the trashcan. In our interfaces, we do not need to mimic every movement from the real world. Interfaces would be dreadfully slow. But by using animation to show where an object came from or is going we can make it easier for the user to find the object again or feel confident in putting the object away in the future. Using animation to position an object in a grid confirms that it went into the slot. This type of feedback clarifies the user interaction. For more information, see the rationale for Transition patterns. Arquitectura de una Resea Resumen del problema A product or website needs to present ratings and reviews with a variety of informational elements.

Ejemplo:

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Use When Use the architecture guidelines to help group related information and diffuse user confusion. Use to enable scanning and quick consumption of the rating and relevance to a user. Solution The elements inside a review should be grouped according to: Target Elements (T1-T5) Review Elements (R1-R9) Form Elements (F1-F3)

Target Elements (T1-T5) This group displays the Target's information.

T1 Target Name (link) Name of Target that links to the detailed target page. T2 Target Attribute List: A list of Target's brief description. T3 Target Image: A Target's picture with width of between 40-90px (standard: 70px) and a proportionate height. T4 Target's Review (link): A link to view all the reviews for the Target. T5 Target Class: The category name of a Target.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. Review Elements (R1-R9) This group displays the author's input about the Target.

Rev. Fecha 18/04/2006

R1 Review Title: The full title created by the author. R2 Review Date Stamp: The date of submission of the review. R3 Author Profile: To identify the author. R3.1 Graph (link set): Display the 360 relationship rating between the author and visitor. Use a ">" symbol to separate each person. R3.2 Author's Reviews (link): Link to see all the reviews created by an author. R4 Helpfulness Ratio: A ratio (e.g. N of N) voted by visitors on how helpful an review is. R5.1 Rating Attribute List: The label of a rating value. R5.1.1 Rating Value List: The value of a rating (star- or bar-scale.) R6.1 Comment Attribute List: First group of labels for a text review value. R6.1.1 Comment Value List: First group of value for a text review. R7 Comment Posting: The body of comment. R8.1 Secondary Comment Attribute List: Second group of labels for a text review value. R8.1.1 Secondary Comment Value List: First group of value for a text review. R.9 Disclosure options: Toggle to show/hide the remaining R7 when R7 is restricted to display N amount of text.

Form Elements (F1-F4) Illustration of Form Elements (F1-F4) This group allows users to act on the review.

F1 Helpfulness Input (link): Visitors can vote (e.g. Yes - No) on how helpful a review is. F2 Report Abuse (link): Allows users to report reviews that appear abusive, offtopic, or otherwise objectionable may violate Yahoo!'s Guidelines and/or Terms of Service. Currently, it is also used for author to edit/delete own reviews. F3 Call to Action (link): A property's action that would like the visitor to perform as the next step. E.g. Write your own review for $TargetTitle

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. Auto completar Resumen del Problema

Rev. Fecha 18/04/2006

El usuario necesito introducir un item a una caja de texto el cual podra ser ambiguo o dificil de recordar y por ende es potencialmente posible que sea mal tipeado. Ejemplo:

Auto completion of contacts in Yahoo! Mail Beta Use When The suggestions can be pulled from a manageable set of data. The input item can be entered in multiple ways. The input item can be matched with a specific data item in the system. Speed and accuracy of entry is an important goal. The total number of items would be too large or inconvenient for displaying in a standard drop down box.

Bsqueda por Paginacin Resumen del problema El usuario necesita ver una cantidad de registros, los cuales son muchos para mostrarlos en usa sola pgina.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. selos cuando

Rev. Fecha 18/04/2006

Muestre un resultado de una bsqueda Haya mas resultados de los que puedan caber en la pantalla

Solucin

Separe la informacin en una secuencia de pginas ordenadas por relevancia. Provea un control de pagineo para darle al usuario acceso al contenido paginado.

Control de Pagineo Muestra los controles de navegacin en una fila de vnculos. Presentar vnculos en el siguiente orden: Anterior, vnculos de paginas, Siguiente.

Muestre una flecha despues de la etiqueta Anterior. Muestre una flecha antes de la etiqueta Siguiente. Haga la flecha cliqueable. Los vnculos de las pginas deben contener un mximo de 10 vnculos

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. Implementacin de la Base de Datos

Rev. Fecha 18/04/2006

A partir del diagrama entidad-relacin, se procede a la creacin de la base de datos. Desarrollo de la lgica del sistema Ruby Ruby es un lenguaje de scripts para una programacin orientada a objetos rpida y sencilla. Fue creado en Japn en el ao 1993 por Yukihiro "Matz" Matsumoto. Ruby es un lenguaje de programacin interpretado, de muy alto nivel y orientado a objetos. En este lenguaje, hasta los nmeros y los caracteres literales son objetos, y tienen los mtodos de su clase, que pueden llamarse normalmente. Caractersticas Posibilidad de realizar directamente llamadas al sistema operativo. Potentes operaciones sobre cadenas de caracteres y expresiones regulares. Retroalimentacin inmediata durante el proceso de desarrollo. Son innecesarias las declaraciones de variables. Todo es un objeto Las variables son de tipo dinmico. La sintaxis es simple y consistente. La gestin de la memoria es automtica. Enteros de precisin mltiple. Modelo de procesamiento de excepciones. Carga dinmica. Hilos.

Sitio Oficial: http://www.ruby-lang.org/ Ruby on Rails

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Ruby on Rails, tambin conocido como RoR o Rails es un framework de aplicaciones web de cdigo abierto escrito en el lenguaje de programacin Ruby, siguiendo el paradigma de la arquitectura Modelo-Vista-Controlador (MVC). Trata de combinar la simplicidad con la posibilidad de desarrollar aplicaciones del mundo real escribiendo menos cdigo que con otros frameworks y con un mnimo de configuracin. El lenguaje de programacin Ruby permite la metaprogramacin, de la cual Rails hace uso, lo que resulta en una sintaxis que muchos de sus usuarios encuentran muy legible. Rails se distribuye a travs de RubyGems, que es el formato oficial de paquete y canal de distribucin de libreras y aplicaciones Ruby. Filosofa Los principios fundamentales de Ruby on Rails incluyen No te repitas (del ingls, Don't repeat yourself, DRY) y Convencin sobre configuracin. No te repitas significa que las definiciones deberan hacerse una sola vez. Dado que Ruby on Rails es un framework de pila completa, los componentes estn integrados de manera que no hace falta establecer puentes entre ellos. Por ejemplo, en ActiveRecord, las definiciones de las clases no necesitan especificar los nombres de las columnas; Ruby puede averiguarlos a partir de la propia base de datos, de forma que definirlos tanto en el cdigo como en el programa sera redundante. Convencin sobre configuracin significa que el programador slo necesita definir aquella configuracin que no es convencional. Por ejemplo, si hay una clase Historia en el modelo, la tabla correspondiente de la base de datos es historias, pero si la tabla no sigue la convencin (por ejemplo blogposts) debe ser especificada manualmente (set_table_name "blogposts"). As, cuando se disea una aplicacin partiendo de cero sin una base de datos preexistente, el seguir las convenciones de Rails significa usar menos cdigo (aunque el comportamiento puede ser configurado si el sistema debe ser compatible con un sistema heredado anterior)

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. Historia

Rev. Fecha 18/04/2006

Ruby on Rails fue escrito por David Heinemeier Hansson a partir de su trabajo en Basecamp, una herramienta de gestin de proyectos, por 37signals. [http://dev.mysql.com/tech-resources/interviews/david-heinemeier-hansson-rails.html Fue liberado al pblico por primera vez en Julio de 2004. Ruby on Rails 1.0 fue publicado el 13 de diciembre de 2005. Ruby on Rails 1.1 fue publicado el 28 de Marzo de 2006. Arquitectura MVC de Rails Las piezas de la arquitectura Modelo-Vista-Controlador en Ruby on Rails son las siguientes: Modelo En las aplicaciones web orientadas a objetos sobre bases de datos, el Modelo consiste en las clases que representan a las tablas de la base de datos. En Ruby on Rails, las clases del Modelo son gestionadas por ActiveRecord. Por lo general, lo nico que tiene que hacer el programador es heredar de la clase ActiveRecord::Base, y el programa averiguar automticamente qu tabla usar y qu columnas tiene. Las definiciones de las clases tambin detallan las relaciones entre clases con secciones de mapeo objeto relacional. Por ejemplo, si la clase Imagen tiene una definicin has_many :comentarios, y existe una instancia de Imagen llamada a, entonces a.commentarios devolver un array con todos los objetos Comentario cuya columna imagen_id sea igual a a.id. Las rutinas de validacin de datos (p.e. validates_uniqueness_of :checksum) y las rutinas relacionadas con la actualizacin (p.e. after_destroy :borrar_archivo,

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

before_update :actualizar_detalles) tambin se especifican e implementan en la clase del modelo. Vista En MVC, Vista es la lgica de visualizacin, o cmo se muestran los datos de las clases del Controlador. Con frecuencia en las aplicaciones web la vista consiste una cantidad mnima de cdigo includo en HTML Existen en la actualidad muchas maneras de gestionar las vista. El mtodo que se emplea en Rails por defecto es usar Ruby Embebido (archivos .rhtml), que son bsicamente fragmentos de cdigo HTML con algo de cdigo en Ruby, siguiendo una sintaxis similar a JSP. Tambin pueden construirse vistas en HTML y XML con Builder o usando el sistema de plantillas Liquid. Es necesario escribir un pequeo fragmento de cdigo en HTML para cada mtodo del controlador que necesita mostrar informacin al usuario. El maquetado de la pgina se describe separadamente de la accin del controlador, y los fragmentos pueden invocarse unos a otros. Controlador En MVC, las clases del Controlador responden a la interaccin del usuario e invocan a la lgica de la aplicacin, que a su vez manipula los datos de las clases del Modelo y muestra los resultados usando las Vistas. En las aplicaciones web basadas en MVC, los mtodos del controlador son invocados por el usuario usando el navegador web. La implementacin del Controlador se encuentra en ActionPack, que contiene la clase ApplicationController. Una aplicacin Rails simplemente hereda de esta clase y define las acciones necesarias como mtodos, que pueden ser invocados desde la web, por lo general en la forma http://aplicacion/ejemplo/metodo, que invoca a EjemploController#metodo, y presenta los datos usando el archivo de plantilla /app/views/ejemplo/metodo.rhtml, a no ser que el mtodo redirija a algn otro lugar.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

Rails tambin proporciona andamiaje (scaffold), que puede construir rpidamente la mayor parte de la lgica y vistas necesarias para realizar las operaciones ms frecuentes. Otros mdulos Adems, Rails tambin ofrece otros mdulos, como Action Mailer (para enviar correo electrnico) y Action Web Service para dar soporte a SOAP y XML-RPC. Ajax on Rails Ajax es una tcnica que permite usar Javascript y XML para procesar peticiones de un navegador web a un servidor web como procesamiento en segundo plano sin cargar otras pginas web adicionales. Rails proporciona diferentes facilidades que hacen ms fcil implementar aplicaciones Ajax. Rails es anfitrin tanto del framework Prototype en Javascript (una serie de herramientas que proporcionan llamadas Ajax y otra funcionalidad habitual en las tareas cliente-servidor) y script.aculo.us, una librera en Javascript con mejoras en la interfaz de usuario (controles avanzados en los formularios, efectos visuales, arrastrar y soltar) Soporte de servidores Web Para desarrollo y pruebas, se utiliza el servidor web ligero WEBrick, includo con Ruby. Para su uso en produccin se usan Apache o Lighttpd con FastCGI. Sobre Apache, mod_ruby puede mejorar considerablemente el rendimiento, aunque su uso no se recomienda porque no es seguro utilizar mltiples aplicaciones RoR sobre Apache. Soporte de Bases de Datos Dado que la arquitectura Rails favorece el uso de bases de datos se recomienda usar un SGBD para almacenamiento de datos. Rails soporta la librera SQLite si no es posible emplear una base de datos. El acceso a la base de datos es totalmente
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

abstracto desde el punto de vista del programador, y Rails gestiona los accesos a la base de datos automticamente (aunque, si se necesita, se pueden hacer consultas directas en SQL) Rails intenta mantener la neutralidad con respecto a la base de datos, la portabilidad de la aplicacin a diferentes sistemas de base de datos, y la usabilidad de bases de datos preexistentes. Sin embargo, debido a la diferente naturaleza y prestaciones de los SGBDs el framework no puede garantizar la compatibilidad completa. Se soportan diferentes SGBDs, incluyendo MySQL, PostgreSQL, SQLite, IBM DB2, Oracle Y Microsoft SQL Server. Plugins Son extensiones de Ruby on Rails que amplan el framework aadiendo o modificando cierta funcionalidad usando tcnicas parecidas a las que hemos visto ms arriba. Los plugins fueron introducidos oficialmente en Rails en la versin 1.0RC1. Para informacin detallada de como descargar, instalar y utilizar los plugins visite el siguiente vnculo http://wiki.rubyonrails.org/rails/pages/Plugins Qu plugins hay disponibles? Hay casi de todo. Desde extensiones para hacer ms fcil definir restricciones o relaciones entre entidades de nuestro modelo (act_as_taggable, por ejemplo, promete ayudarnos a implementar folksonomas), hasta amplicaciones del sistema de vistas de RoR que integran Google Maps o generan PDFs. Cada uno de ellos trata de ser una solucin autocontenida a una necesidad especfica. Una advertencia: instalar y usar un plugin en cierto modo es casarse con l. Deberamos escoger usar extensiones que estn siendo usadas por un nmero de usuarios, lo que nos debera garantizar un mnimo de madurez y estabilidad en el cdigo que estamos metiendo en nuestra aplicacin. En caso contrario, deberamos estar dispuestos a resolver cualquier incidencia, en caso de que la extensin quede sin soporte.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. Estndares de codificacin en Ruby on Rails

Rev. Fecha 18/04/2006

Con la finalidad de mantener un cdigo uniforme al momento de desarrollar utilizando el framework RoR debemos las siguientes normas: Convenciones de Nombres Utilice solo letras maysculas en las constantes Ejemplo: Math:PI, Curses::KEY_DOWN, OTRA_CONSTANTE Las clases utilizan el caso camello Use las palabras de nombres de clase con la capitalizacin de la primera letra de cada ah,palabra. Lo mismo se hace para los nombres de mdulos. Ejemplo: NombreDeUnaClase Los nombres de mtodos y variables usan underscores Una palabras con underscores. Ejemplo: variable_nueva nombre_de_metido_de_una_clase Mantenga capitalizados los acrnimos en los nombres de clases Mal Ejemplo

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A. MiClaseXml En su lugar se debe hacer lo siguiente MiClaseXML Las variables deben estar en minsculas.

Rev. Fecha 18/04/2006

Parmetros de mtodos Solo omita parntesis cuando el primer parmetro es una cadena o un smbolo algun_metodo una cadena algun_metodo :simbolo algun_metodo :simbolo, :foo => 'bar' algun_metodo("una cadena") || true algun_metodo(un_objeto) Bloques Bloques de una sola linea deben definirse utilizando llaves. Ejemplo: log(sql, nombre, @connection) { |connection| connection.query(sql) } Bloques de multiples lineas deben ser definidos utilizando doend con la variable del bloque en la misma linea donde se encuentra el do algun_metodo do |i| puts "una cadena" puts "otra cadena" end
Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por:

Cdigo

METODOLOGA PARA EL DESARROLLO DE APLICACINES EN SOFTWARE TECHNOLOGIES CONSULTING C.A.

Rev. Fecha 18/04/2006

FASE IV: PRUEBAS DEL SISTEMA (DPTO. DESARROLLO Y PROCESOS) Validacin del cdigo XHTML y CSS siguiendo los lineamientos de la W3C Con la finalidad de mantener estandarizado el cdigo en todos los niveles del sistema, as como la correcta funcionalidad del comportamiento visual del mismo independientemente del navegador con el que se trabaje, el cdigo debe ser validado en la pgina http://validator.w3.org y de esta manera cerciorarnos de que el sistema si cumple con los estndares oficiales. PRUEBAS PARCIALES Una vez obtenido parte del producto ya desarrollado, el personal de procesos procede a realizar las pruebas al mismo, con la finalidad de verificar los puntos de control y validaciones que se determinaron realizar durante el desarrollo del prototipo. Si existen detalles o puntos que no se realizaron se debe llenar Formato de Requerimiento, firmado por la analista de procesos que realizo las pruebas y entregado al analista de desarrollo el cual debe firmar el formato una vez solventado los detalles y entregado a procesos para una segunda prueba, esto con la finalidad de llevar soporte de las veces que se probo el mdulo antes de llegar al usuario final. PRUEBAS USUARIO Una vez obtenido parte del producto ya desarrollado, el personal de procesos conjuntamente con los analistas y usuario procede a realizar las pruebas al mismo, con la finalidad de satisfacer las necesidades del usuario indicadas durante la revisin del prototipo. Si existen detalles o puntos que no satisfacen al usuario se deben plasmar en el Formato de Requerimiento, firmado por las personas involucradas, con la finalidad de solventar para una segunda revisin en el caso que lo amerite. Caso contrario se escribe en la minuta la satisfaccin del cliente con respecto al producto. Fin de la documentacin y entrega del producto final al cliente.

Fecha de Creacin

18/04/2006 Dpto. Procesos

Fecha de Revisin

Fecha de Aprobacin

Preparado por:

Revisado por:

Aprobado Por: