Ombú / Wbs (Web based Systems)

Transcripción

1 Ombú / Wbs (Web based Systems) Tecnología de Desarrollo Empresa Argentina Organización y Gestión SRL San Jose 83 Piso 8 (C1076AAA) Buenos Aires Argentina Tel.: (5411)

2 INDICE 1. Metodología de Desarrollo Pág Metodología de Análisis y Diseño Pág Metodología para la Implementación y Prueba Pág Metodología de Programación Pág Framework de Desarrollo Pág Implementación Física Pág Servidores y Software de Base Pág. 20 2

3 1. Metodología de Desarrollo Orientada a Objetos Diferencias entre la construcción de software orientado a objetos y los desarrollos de software tradicional Mayor esfuerzo en el análisis Un enfoque orientado a objetos mueve el esfuerzo del desarrollo del software a la fase de análisis dentro del ciclo de vida. Es a veces desconcertante pasar mas tiempo durante el análisis y el diseño, pero este esfuerzo extra es mas que compensado por una implementación más rápida y simple. Como el resultado del diseño es claro y adaptable, los futuros cambios son mucho más fáciles de realizar. Énfasis en la estructura de los datos antes que la función Un enfoque orientado a objetos focaliza la atención en la estructura de datos mas que en las funciones a ser realizadas. Este cambio de énfasis da al proceso de desarrollo una base más estable y permite el uso de un concepto de software unificado simple: el concepto de objeto. Todos los otros conceptos, tales como funciones, relaciones, y eventos, son organizados alrededor de los objetos, de modo que esta información grabada durante el análisis, no es perdida ni transformada cuando el diseño y la implementación toman lugar. La estructura de datos de una aplicación y las relaciones entre ellas son mucho menos vulnerables a los requerimientos de cambio que a las operaciones realizadas sobre los datos. Organizar un sistema alrededor de objetos mas que alrededor de funciones ofrece al proceso de desarrollo cierta estabilidad que es escasa en un enfoque orientado a funciones. Los objetos encapsulados, con interfaces públicas que ocultan su implementación interna, son protegidos ante posibles efectos de cambios. Proceso de desarrollo sin costura Como un enfoque orientado a objetos define fácilmente un conjunto de objetos orientados al problema dentro del proyecto y continua usando y extendiendo estos objetos a través del ciclo de desarrollo, la separación de las fases del ciclo de vida es mucho menos distintiva. El proceso es sin costura porque no hay interrupciones, en las cuales la notación de una fase es reemplazada por una diferente notación en otra fase. Proceso Iterativo mas que secuencial Aunque la descripción de la Técnica de Modelar Objetos es por necesidad lineal, el proceso de desarrollo actual es iterativo. El desarrollo orientado a objetos sin costura, hace más fácil repetir los pasos de desarrollo progresivamente en niveles de detalle más finos. Cada iteración adiciona o clarifica características mas que modificar el trabajo que ya fue hecho, por lo tanto hay menos chance de introducir inconsistencias y errores. 3

4 2. Metodología para el Análisis y Diseño 1. Descripción del Proyecto El primer paso en el desarrollo de cualquier proyecto es plantear los requerimientos. La declaración del problema debe indicar que se hará y no como se hará. Debe ser una declaración de necesidades no una proposición de una solución. El usuario debe indicar que características son obligatorias y cuales son opcionales, para evitar demasiadas decisiones de diseño forzadas. El usuario debe evitar descripciones internas del sistema, ya que estas restringen flexibilidad de la implementación. Especificaciones de performance y protocolos para interactuar con sistemas externos son requerimientos legítimos. Planteo de Requerimientos Alcance del Sistema Que es necesario Contexto de la Aplicación Suposiciones Necesidades de Performance 2. Análisis de Riesgos En esta etapa el objetivo es hacer una lista de cosas que no aparecen en la descripción, pero que se conocen y se deben analizar para llevar a cabo el proyecto. Buscar factores de mercado que pueden influenciar el proyecto, buenos o malos, y cosas que son requeridas pero que no aparecen en la descripción. Posibles factores de riesgo: Falta de aceptación de los usuarios Dependencia sobre una tecnología que cambia No suficiente rápido para el mercado Demasiados usuarios Equipo poco experimentado Cronograma muy corto Crecimiento de la empresa bastante rápido Demasiado rápido para el mercado Documento: Matriz de Evaluación de Riesgo Es una matriz que enuncia los riesgos que corre el proyecto y como van siendo canalizados. Por cada uno de ellos se detalla el tipo de riesgo (Técnico, del Negocio o Humano), la posible causa, la probabilidad de que ocurra, el grado de impacto si ocurriera, el plan de acción y la persona responsable de seguirlo. La matriz es continuamente actualizada durante el ciclo de vida del proyecto. 4

5 3. Identificación de Actores Los actores representan cualquier cosa que interactúa con el sistema. Algunos ejemplos lo constituyen las personas, otros softwares, dispositivos de hardware, almacenamiento de datos o redes. Cada actor define un rol particular. Cada entidad externa al sistema puede ser representada por uno o mas actores. Por lo tanto una persona física puede ser representada por varios actores porque esta persona toma diferentes roles con respecto al sistema. Documento: Diagrama de Contexto Es un diagrama que contiene un círculo (o elipse), el cual representa el sistema, que es ubicado en el centro del diagrama, los rectángulos se usan para representar las entidades externas al sistema a ser desarrollado; y finalmente, un par de líneas dobles representan cualquier almacenamiento de datos que es requerido o producido. 4. Descripción de los requerimientos del sistema El objetivo es generar una matriz que contiene la totalidad de los requerimientos extractados de la especificación del sistema. Los requerimientos son clasificados por tipo, es decir HW o SW y priorizados según la release en que van a ser desarrollados. Documento: Matriz de Requerimientos (RTM) Es una matriz que inicialmente contiene el conjunto de requerimientos para un sistema. El RTM es continuamente actualizado durante el ciclo de vida de un proyecto. Contiene tanto los requerimientos de software como de hardware. 5. Transformación de los requerimientos en Casos de Uso La idea es extractar los requerimientos de software desde el RTM y formatearlos para descubrir potenciales Clases. Para lograrlo se deben reescribir los requerimientos, en un formato de caso de uso. Es una sentencia de un requerimiento de software funcional. El formato específico para nombrar un caso de uso es: Actor Acción Sujeto Cada Caso de Uso va acompañado con su correspondiente Interfaces de Usuario Gráfica. Documento: Caso de Uso Cada Caso de Uso debe considerar las funcionalidades básicas, las alternativas posibles, las condiciones de error, las condiciones que deben cumplirse antes de empezar y las condiciones que deben ser verdades después de ocurrido el caso de uso. Además el caso de uso puede incluir condicionales, ramificaciones y loops. El formato básico de una planilla que describe un caso de uso, esta compuesta por tres partes, a saber, precondiciones, flujo de eventos (básicos y alternativos) y post-condiciones. Dibujo de las Pantallas (GUI) GUI es el término usado para los diálogos que realiza la interfase entre el software y el usuario del software. 5

6 Las pantallas son dibujadas de acuerdo al formato elegido para toda la aplicación. 6. Descripción de los Escenarios para cada Caso de Uso Si se elige un camino en particular a través del caso de uso, este es llamado Escenario. Un Caso de Uso esta completo cuando se describen todos los escenarios posibles. Se consideran los escenarios en dos partes. El escenario primario describe la funcionalidad básica del caso de uso. Hay un escenario primario por cada caso de uso. Los escenarios secundarios describen las alternativas y las condiciones de error para el caso de uso. Documento: Planilla de Escenario por cada Caso de Uso Un escenario consiste de texto que representa el concepto de cómo un Operador interactúa con el software para obtener el resultado deseado. Para un Escenario que no tiene interacción de un Operador, el escenario describe la secuencia de acciones de software necesarias para completar la funcionalidad especifica. 7. Desarrollo del Modelo de Objetos El modelo de objetos captura la estructura estática del sistema exponiendo los objetos en el sistema, las relaciones entre los objetos, y los atributos y operaciones que caracterizan cada clase de objetos. Se empieza por identificar categorías, y luego se las va desglosando. Una categoría es una colección de clases relacionadas lógicamente. Por cada objeto se describe su identidad, sus relaciones con otros objetos, sus atributos y operaciones. Documentos: Modelo de Objetos, Bblioteca de Clases y Diagrama de Entidad Relación 8. Definición del Modelo Dinámico El propósito es detallar el comportamiento dinámico del sistema, especificando el comportamiento individual de clases y el de colaboración entre clases, que son requeridos para satisfacer los distintos requerimientos. Para armar el modelo, se toma cada caso de uso, con su correspondiente escenario e interface gráfica, y se analiza el comportamiento de las distintas clases que participan en el requerimiento. Documentos: Diagrama de Transición de Estados Es un diagrama que representa el comportamiento interno de una clase. Describe los aspectos del sistema concernientes con el tiempo y la secuencia de operaciones. Un DTE detalla las fases del ciclo de vida de una clase y los eventos que causan la transición de una instancia de un estado a otro. Acciones en el diagrama de estados corresponden a acciones en el modelo funcional. Eventos en un diagrama de estados corresponden a operaciones sobre objetos en el modelo de objetos. Diagrama de Interacción de Clases Un DI refleja la funcionalidad de un hilo de control (Caso de Uso) a un nivel de software, en un modo que identifica cuales clases, y cuales métodos de cada clase, son requeridos para satisfacer un Caso de Uso. 6

7 3. Metodología para la Implementación y Prueba Implementación En la implementación se empezará con el resultado del diseño y se implementará el sistema en términos de componentes. La mayor parte de la arquitectura del sistema es capturada durante el diseño, siendo el propósito principal de la implementación el desarrollar la arquitectura y el sistema como un todo. De forma mas específica, los propósitos de la implementación son: Planificar las integraciones de sistema necesarias en cada iteración. Se sigue para ello un enfoque incremental, lo que da lugar a un sistema que se implementa en una sucesión de pasos pequeños y manejables. Distribuir el sistema asignando componentes ejecutables a nodos en el diagrama de despliegue. Esto se basa fundamentalmente en las clases activas encontradas durante el diseño. Implementar las clases y subsistemas encontrados durante el diseño. Probar los componentes individualmente, y a continuación integrarlos compilándolos y enlazándolos en uno o más ejecutables, antes de ser enviados para ser integrados y llevar a cabo las comprobaciones del sistema. Prueba En el flujo de trabajo de la prueba se verificará el resultado de la implementación probando cada construcción, así como las versiones finales del sistema a ser entregadas. Mas concretamente los objetivos de la prueba son: Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de integración y las pruebas de sistema. Las pruebas de integración son necesarias para cada construcción dentro de la iteración, mientras que las pruebas de sistema son necesarias solo al final de la iteración. Diseñar e implementar las pruebas creando los casos de prueba que especifican que probar, creando los procedimientos de prueba que especifican como realizar las pruebas. Realizar las diferentes pruebas y manejar los resultados de cada prueba sistemáticamente. Las construcciones en donde se detectan defectos son probadas de nuevo y posiblemente devueltas a otro flujo de trabajo, como diseño o implementación, de forma que los defectos importantes puedan ser arreglados. 7

8 4. Metodología de Programación 1. Programación en Capas Un proyecto estructurado para DNA está organizado en tres capas independientes e interrelacionadas. Éstas son: La capa del usuario, la capa del negocio y la capa de Base de Datos. Capa del Usuario Capa del Negocio Capa de Base de Datos 1.1 Capa de Base de datos: Administra el acceso a la base de datos, aislando a las capas superiores de las características particulares de cada motor. Cada componente de acceso a la base de datos, expone una interfaz común (herencia de interfaz), siendo un requisito de cada componente respetar la declaración de los métodos que lo componen. Esto permite que, mientras se mantenga la interfaz, que cada método pueda implementarse de la forma más óptima según el motor. Implementación para SQL Implementación para Informix Implementación para Oracle Interfaz Otras implementaciones Si en un proyecto, se decidiera cambiar el motor (por ejemplo, de DB/2 a MS. SQL Server), bastaría con rescribir en el componente de acceso a datos, los métodos que no fueran estándares, respetando la misma interfaz. 1.2 Capa de Negocio: Es donde se encuentra la lógica del negocio, es decir las relaciones entre las distintas entidades que conforman un proyecto. Ésta capa está formada por componentes COM, que se relacionan entre sí, con relaciones previamente tipificadas (FK, Padre-Hijo, n-n, etc...) Los componentes de ésta capa no conocen la interfaz del usuario, y para ellos, acceder a la base de datos es simplemente invocar a un método, dejando toda la complejidad (sentencias SQL, Stores Procedures, etc...) a la capa de base de datos. En éstos componentes se encuentra la semántica del negocio. Aquí se validan los datos de una forma lógica. Ejemplos de validación serían: La fecha contable debe ser menor o igual que la fecha del sistema. Si el concepto del detalle trata formulario 3419, entonces... 8

9 Capa de Interfaz con el usuario Capa de acceso a la base de d t Reglas del negocio Componentes transaccionales y no transaccionales En la capa de negocio, cada entidad lógica (cliente, factura, ect.) es un componente. Dichos componentes acceden, por medio de la última capa, a la base de datos, tanto para realizar consultas, como para efectuar modificaciones. Las modificaciones (insert, update o delete) necesitan estar contempladas dentro de un manejador de transacciones (Distributed Transaction Cordinator), mientras que dicha consideración es innecesaria para las consultas (select). De esta diferencia surge la necesidad de una subidivisión en la capa de negocio: Capa de Negocio Transaccional (Actualización): Administra el contexto transaccional de las operaciones de modificación del soporte de datos. Capa de Negocio propiamente dicha: Son las reglas del negocio en sí.. Capa de Usuario: Es la capa de interacción con el usuario. La interfaz del usuario está montada sobre tecnología intranet - Internet. Es decir, el cliente requiere únicamente un browser (Microsoft Internet Explorer 5 o superior), el cual se conecta con el servidor a través del protocolo http. Capa de Interfaz: Se puede dividir a su vez en tres partes: Páginas del cliente: Son documentos DHTML. Contienen los controles (cajas de texto, combos, etc...) y código vbscript, encargados de comunicarse con las páginas del server y de cierto manejo de los controles, para hacer la página más inteligente Páginas del servidor: Son documentos ASP (Active Server Pages). Sirven de generadores de páginas del cliente, y como servidores en métodos de Remote Scripting Componentes de Interfaz: Es una serie de componentes, genéricos y particulares, desarrollados en Visual Basic, que son quienes, en definitiva, terminan accediendo a las clases del negocio. La comunicación entre éstas subcapas está coordinada por el Internet Information Server. 9

10 DHTML ASP VB VB Páginas del cliente Páginas del Servidor Compon entes de Interfaz Capa del Negocio Microsoft Internet Information Server Esta tecnología centralizada ataca, básicamente, dos típicos problemas; el deployment de la aplicación y los requerimientos en los puestos de trabajo. A. Deployment: A.1. Problemas de versiones: Éste problema no existe, ya que todos los clientes acceden remotamente al mismo programa. A.2. Instalación puesto por puesto: El programa se instala únicamente en un servidor (o un conjunto de servidores), y los clientes simplemente acceden al webserver (IIS). B. Capacidad de los clientes Los puestos de trabajo pueden ser mucho más livianos, ya que la mayor parte del trabajo se realiza en los servidores, los cuales tienen la capacidad de reutilizar recursos de una manera más eficiente. Para evitar problemas de sobrecarga en los servidores, toda la metodología está orientada a la escalabilidad de la aplicación. La escalabilidad se logra, a partir del uso que se le da a los componentes de las distintas capas (generalmente state-less) y a la ausencia de sesiones de bases de datos por usuario (pool de conexiones). La infraestructura necesaria para realizar esto, está proveída por COM+, quien brinda los servicios de pool de conexiones y pool de threads. 10

11 Implementación del Modelo Los puntos explicados anteriormente, se podrían resumir en el siguiente gráfico: Usuario Negocio Base Datos Actualizador EntidadAct Cliente Server Component es de Interfaz A S P Genera Transacción Modifica el contenido de la BD EntidadLec Lector Usa Transacción Obtiene Datos de la BD Negocio propiamente dicho Persistencia de Objetos No modifica la base de datos Contiene las validaciones Entidad 11

12 5. Framework de Desarrollo Capa Interfase Usuario Capa Web OyG (DHTML, ASP, XML) - Arma y muestra el menú principal. - Muestra el formulario a utilizar y genera la botonera. - Genera el código dinámico para las paginas ASP. - Activa el ingreso del login en caso de trabajar con varias empresas. - Identifica el usuario logueado en Windows en el equipo cliente. - Maneja los métodos genéricos para la carga de grillas de Administración y particulares. - Las paginas ASP se comunican con objetos de esta capa y esta deriva a las demás capas según corresponda. - Maneja la vinculación de archivos a las operaciones del sistema. - Permite el acceso a herramientas Office. - Contiene los formularios correspondientes a las funciones de seguridad como sincronización de usuarios, relación nivel-funcion, etc. Capa Form OyG (VB6) Capa Negocio - Arma y muestra el menú principal. - Muestra el formulario a utilizar y genera la botonera. - Activa el ingreso del login en caso de trabajar con varias empresas. - Identifica el usuario logueado en Windows - Maneja los métodos genéricos para la carga de grillas de Administración y particulares. - Valida y carga los controles de un formulario. - Contiene los formularios correspondientes a las funciones de seguridad como sincronización de usuarios, relación nivel-funcion, etc. Capa Negocio Seguridad - Provee de un objeto que brinda la sincronización de usuarios de Windows NT o Windows 2000 con las tablas de seguridad correspondientes. - Provee de un objeto Entidad que contiene métodos reutilizables y métodos intermediarios para la comunicación con Capa Base de datos OyG. - Provee de un objeto ABMOyG, para un ABM básico sin validaciones. - Provee de un objeto para el envío de mails. - Contiene otros objetos para el acceso a métodos particulares de la seguridad como ser: consulta y actualización de numeradores, obtención del menú, etc. Capa Base de Datos Capa Base de Datos OyG - Establece la conexión con las bases de datos. - Provee de métodos de actualización y consultas genéricos. Capa Base de Datos Seguridad 12

13 Interfaz OyG - Tiene métodos de consultas y actualizaciones particulares para las tablas de seguridad. Están las distintas interfaces usadas por los objetos. Controles OyG Contiene controles genéricos con la funcionalidad necesaria para ser utilizados en cualquier proyecto. Los controles creados hasta el momento son: texto, combo, lista, opciones, grilla y botones. 13

14 6. Implementación física de una solución de tres capas Un proyecto estructurado para DNA está organizado en tres capas independientes e interrelacionadas. Éstas son: La capa del usuario, la capa del negocio y la capa de Base de Datos. Esto no implica que dichas capas deban implementarse por separado, esta es solo una división lógica. Llegado el momento de realizar la implementación física de la solución se deberán tener en cuenta una serie de factores que dependen del volumen de información, de la cantidad de usuarios y del tipo de aplicación que se este implementado. Para poder explicar con mayor facilidad las diversas posibilidades que se podrían plantear en un implementación veremos a continuación tres escenarios posibles: 1. Una empresa con hasta 20 usuarios que acceden a la aplicación en forma local (vía Intranet). 2. Una empresa con hasta 50 usuarios que acceden a la aplicación en forma local (vía Intranet) y además consideran la posibilidad de que dichos usuarios puedan operar el sistema vía Internet. 3. Una empresa con mas de 100 usuarios que acceden a la aplicación en forma local (vía Intranet) o remota (vía Internet) y además tienen interacciones con clientes o proveedores utilizando Internet (Ej: Consultas de saldos de cuentas corrientes, ingreso de pedidos, etc). 14

15 Escenario 1 Empresa Un único servidor que cumpla con todas las funciones Usuario OLAP Capa del Usuario IIS Capa del Negocio COM+ Internet Explorer 5 Capa de Base de Datos Transaccional 15

16 Escenario 2 Internet Usuario Explorer 5 Empresa VPN Internet Usuario OLAP Capa del Usuario IIS Capa del Negocio COM+ Internet Explorer 5 Capa de Base de Datos Transaccional Servidor de Aplicaciones Servidor de Base de 16

17 Escenario 3 Cliente o Proveeedor 5 Usuario Internet Internet Explorer Internet Explorer 5 Empresa VPN WWW Web Server - IIS Zona de FireWall Servidores OLAP Usuario OLAP Capa del Usuario IIS Capa del Negocio COM+ Internet Explorer 5 Capa de Base de Datos Transaccional Servidores de Aplicaciones Servidores de Base de Datos Para poder comprender la magnitud de este escenario en necesario profundizar en el concepto de granjas de servidores. Este concepto nace de la necesidad de implementar soluciones que sean totalmente escalables (Se entiende por escalable a una solución que mantiene constante su tiempo respuesta si el hardware se aumente en relación a la cantidad de usuarios y no es necesario modificar el código de la aplicación para implementar los cambios). Es por esto que nos referimos a Servidores de.. en plural, ya que funcionan como una unidad pero están implementados con dos o mas equipos. Dicha implementación es conocida como granja. 17

18 El gráfico que está a continuación muestra como se implementa físicamente las diferentes granjas de servidores: 18

19 Además esta arquitectura puede ser utilizada para realizar un balanceo de carga de los servidores mediante el uso de agentes que analizan el estado de cada servidor dentro de la granja y asignan las tareas en relación a dicho análisis. La implementación seria la siguiente: 19

20 7. Requerimientos de los Servidores (Plataforma para 50 usuarios con un factor de concurrencia del 40 %) Servidor de base de datos Transaccional SQL Server Sistema Operativo Windows 2000 Hardware Servidor Pentium III 800 Mhz o superior Disk Array en Mirror y/o RAID ( 9 Gb o Mas ) Un mínimo de 256 Mb de Memoria RAM ( Recomendado 512 Mb ) Unidad de Backup ( DAT, DLT, etc) Software de base Microsoft Windows 2000 Microsoft SQL Server 2000 Informix u Oracle Sistema Operativo Unix o Linux Hardware Servidor Pentium III 800 Mhz o superior Disk Array en Mirror y/o RAID ( 9 Gb o Mas ) Un mínimo de 256 Mb de Memoria RAM ( Recomendado 512 Mb ) Unidad de Backup ( DAT, DLT, etc) Software de base Sistema operativo Unix ( AIX, HP-UX, SCO o Linux ) Motor de base de datos Informix u Oracle Servidor de base de datos OLAP SQL Server Sistema Operativo Windows 2000 Hardware Servidor Pentium III 800 Mhz o superior Disco Rígido SCSI de 9 Gb o Mas Un mínimo de 512 Mb de Memoria RAM Software de base Microsoft Windows 2000 Microsoft Office 2000 Microsoft SQL Server 2000 ( En caso de aplicaciones que accedan al OLAP vía Internet en necesario instalar la versión Enterprise ) 20

21 Servidor de aplicaciones (IIS y COM+) Internet Information Server y COM + Sistema Operativo Windows 2000 Hardware Servidor Pentium III 800 Mhz o superior Disk Array en Mirror y/o RAID ( 9 Gb o Mas ) Un mínimo de 256 de Memoria RAM ( Recomendado 512 Mb ) Software de base Microsoft Windows

22 Requerimientos del Cliente Según el Sistema Operativo Microsoft Windows 98 Hardware PC IBM o Compatible con: Procesador Pentium 200 Mhz o superior Un mínimo de 64 Mb de memoria RAM Placa de video con definición 800x600 o superior Software de Base Microsoft Windows 98 Microsoft Office 2000 o superior Microsoft Windows NT Workstation, Windows Me, Windows XP o Windows 2000 Profesional Hardware PC IBM o Compatible con: Procesador Pentium 200 Mhz o superior Un mínimo de 128 Mb de memoria RAM Placa de video con definición 800x600 o superior Software de Base Microsoft Windows NT Workstation, Windows Me, Windows XP o Windows 2000 Profesional Microsoft Office 2000 o superior 22