UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS Fundada en 1551
FACULTAD DE NGENERA NDUSTRAL
E.A.P DE NGENERA NDUSTRAL DesarroIIo de sistemas de software con patrones de diseo orientado a objetos TESS para optar el Titulo Profesional de: NGENERO NDUSTRAL AUTOR JANE PAUL LORENA LAZO ASESOR NG. EDGAR RUZ LZAMA LIMA - PER 2004
A MIS PADRES
1
RESUMEN El objetivo del presente trabajo, es aplicar patrones de diseo orientados a objetos, para el anlisis y desarrollo de una Arquitectura de Software en la Facultad de Ingeniera Industrial Universidad Nacional Mayor de San Marcos el cual se denomina INTRANET INDUSTRIAL, y medir el impacto en el costo de desarrollar el sistema con patrones y el costo de hacerlo sin patrones. En la primera parte del trabajo, se define los conceptos tericos y el escenario en el que se aplican los patrones de diseo, adems se incluye una categorizacin de los patrones mas conocidos en la industria del software. En la segunda parte del trabajo se hace referencia a los patrones de diseo utilizados para el desarrollo del sistema de software INTRANET INDUSTRIAL, donde se procede a esquematizarlos y clasificarlos formalmente. En la ltima parte del trabajo, se hace una descripcin del sistema desarrollado, los mdulos que lo componen, las herramientas necesarias para su desarrollo. Adems se incluye una estimacin del costo del sistema de software, utilizando el Patrn Informador, y sin su utilizacin, para esta estimacin se utiliza el mtodo de COCOMO (Modelo Constructivo de Costos). Se incluye, en un anexa, toda la documentacin tcnica detallada del sistema de software de la INTRANET INDUSTRIAL de la Facultad de Ingeniera Industrial Universidad Nacional Mayor de San Marcos.
2 NDICE DE CONTENIDO Dedicatoria ii Resumen iii ndice Contenido iv ndice De Figuras v ndice De Cuadros vii ndice De Cdigos viii Introduccin 1 Capitulo I: El Problema 2 1.1. Formulacin Del Problema 2 1.2. J ustificacin 2 1.3. Objetivos 3 1.4 Hiptesis 3 Capitulo ii: Fundamentos Tericos 4 2. Bases Tericas 4 Capitulo iii: Arquitectura Del Sistema 23 3. Arquitectura Del Sistema 23 3.1. Patrones De Software Utilizados 23 3.2. Patrn Arquitectnico De 3 Capas 23 3.3. Patrn Informador 26 3.4. Patrn Sensor 35 3.5. Comparacin: Operacin Tpica De Base De Datos Sin Patrn Y Con Patrn Informador 38 Capitulo iv: Desarrollo Sistema Intranet Industrial 40 4. Introduccin 40 4.1. Requerimientos 40 4.2. Visin Del Proyecto 41 4.3. Misin De Proyecto 41 4.4. Alcances Del Proyecto 41 4.5. Especificaciones Lenguaje. 43 4.6. Funcionalidad Del Sistema 43 4.7. Metodologa 43 4.4. Herramientas Para El Anlisis Y Diseo 46 4.5. Herramientas Para Desarrollo Del Sistema 48 4.6. Cronograma De Trabajo 54 Capitulo V: Costo De Utilizar Patrn Informador 59 5. Introduccin 59 5.3. Explicacin 76 5.4. Interpretacin 78 Capitulo Vi: Conclusiones Y Recomendaciones 79 Conclusiones 79 Recomendaciones 81 Bibliografa 82 Glosario De Trminos 84
3
NDICE DE FIGURAS
Figura 2.1. Framework conceptual. 5 Figura 2.2. Ciclo de Vida del Software orientado a objetos 6 Figura 2.3. Patrn Arquitectnico. 10 Figura 2.4. Usuarios FII UNMSM. 12 Figura 2.5. Patrn Singleton. 13 Figura 2.6. Ejecucin Patrn Singleton 14 Figura 2.7. Patrn Faade. 16 Figura 2.8. Ejecucin Faade. 18 Figura 2.9. Patrn Observer. 19 Figura 2.10. Patrn Observer 22 Figura 3.1. Patrn Arquitectnico FII UNMSM. 24 Figura 3.2. Figura de Clases de Patrn Informador 27 Figura 3.3. Base de Datos de Mdulo Biblioteca FII UNMSM 30 Figura 3.4. Figura de Clases de Patrn Sensor 36 Figura 4.1. Interaccin de Usuario con la INTRANET INDUSTRIAL 42 Figura 4.2 Metodologa RUP. 44 Figura 4.3. Desarrollo Iterativo 45 Figura 4.4. Modelamiento de Clases. 47 Figura 4.5. Modelamiento de Casos de Uso (XDE for .NET). 47 Figura 4.6. Desarrollo de Cdigo en .NET (Visual Studio 2003). 48 Figura 4.7. Modelamiento de Entidad Relacin (Erwin). 49 Figura 4.8. Codificacin de Base de Datos (Toad). 50
4 Figura 4.9. Vista de pgina de Login Intranet Industrial 51 Figura 4.10. Vista de Home de la Intranet Industrial 51 Figura 4.11. Detalle de Noticias 52 Figura 4.12. Visualizacin de Contenido de Carpeta 52 Figura 4.13. Cronograma de Trabajo 53 Figura 5.5. Semanas Necesarias para completar las operaciones Bsicas 68 Figura 5.6. Costos Desarrollo Mdulos Intranet 71 Figura 5.7. Comparacin Plazos Estimados Desarrollo Mdulos Intranet 72 Figura 5.8. Comparacin Costos Estimados Desarrollo Mdulos Intranet 73
5
NDICE DE CUADROS
Tabla 2.1. Patrones de Diseo 12 Tabla 3.1. Participantes Patrn Informador 29 Tabla 3.2. Colaboraciones Patrn Informador 30 Tabla 3.3. Participantes Patrn Sensor 34 Tabla 3.4. Colaboraciones Patrn Sensor 40 Tabla 4.1. Distribucin de Plazos y Recursos segn el RUP 53 56 Tabla 5.1. Factores en estimacin de esfuerzo 58 Tabla 5.2. Atributos de Costo 60 Tabla 5.3.: ndice de Costos de Software 61 Tabla 5.4. Lneas de Cdigo por Mdulos (Con Patrn) 63 Tabla 5.5. Lneas de Cdigo por Mdulos (Sin Patrn) 64 Tabla 5.6. Cuadro Comparativo de lneas de Cdigo Con Uso y Sin Uso de Patrn Informador 65 Tabla 5.7. Factores de Costo 66 Tabla 5.8. Consideraciones de Tiempos 66 Tabla 5.9. Clculo de Esfuerzo Ajustado y Productividad 67 Tabla 5.10. Clculo de Esfuerzo Ajustado y Productividad 69 Tabla 5.11. Clculo de Esfuerzo Ajustado y Productividad 69 Tabla 5.14. Tabla Comparativa de Sin Patrn versus Uso de Patrn 76
6
NDICE DE CDIGOS
Cdigo 2.1. Implementacin Patrn Singleton 15 Cdigo 2.2. Implementacin Patrn Faade 19 Cdigo 2.3. Implementacin Patrn Observer 23 Cdigo 3.1. Refactorizacin Patrn Informador 33 Cdigo 3.2. Refactorizacin en Capa Business Patrn Informador 34 Cdigo 3.3. Uso Patrn Informador 35 Cdigo 3.4. Uso Patrn Sensor 38 Cdigo 3.5. Sin Uso de Patrn Informador 39 Cdigo 3.6. Sin Uso de Patrn Informador 39 Cdigo 3.7. Uso Patrn Informador 40
7
INTRODUCCIN De la misma manera como se hizo con la introduccin de partes y patrones reutilizables en el mbito industrial con el uso de estndares, patrones, partes reutilizables y lneas de montaje que incrementaron la productividad industrial a inicios del siglo XX, el uso de patrones y estructuras recurrentes en el desarrollo de software se constituye como la mejor forma de reutilizacin sistemtica de estructuras lgicas. Para llevar a cabo la reutilizacin de software, se requiere un proceso de diseo que considere como reutilizar los diseos existentes y que organice explcitamente el diseo alrededor de componentes de software existentes. La programacin orientada a objetos satisface los requerimientos para el desarrollo de estructuras lgicas reutilizables. Dentro de las bondades del uso de patrones en principio, se puede indicar, que su uso simplifica drsticamente el proceso de construccin de un sistema de software, reduce los costos de implementacin a travs de una infraestructura reutilizable y mejorar la integridad del sistema as como las verificaciones especficas propias de cada sistema.
8
CAPITULO I: EL PROBLEMA 1.1. FORMULACIN DEL PROBLEMA Aunque ha existido inters en la reutilizacin de software desde principios de los 80, hasta hace pocos aos ha sido aceptado como un enfoque prctico para el desarrollo de sistemas de software [SOMMERVILLE02] Los analistas y desarrolladores de sistemas de software, tienen que disear y construir sistemas ms complejos, escalables, y hacerlos en menores plazos de tiempo. Es posible el desarrollo de sistemas de software por medio de la reutilizacin sistemtica de patrones de software? De que manera afecta al costo, y a los plazos de entrega del sistema? 1.2. JUSTIFICACIN Los costos operativos para el diseo, anlisis y desarrollo de sistemas de software complejos son altos, por esa razn es necesario orientar la
9 investigacin al desarrollo de aplicaciones de software, haciendo uso de tcnicas que posibiliten la reutilizacin de estructuras de software. 1.3. OBJETIVOS 1.3.1. OBJETIVO GENERAL Definir estructuras lgicas recurrentes bajo un patrn, estableciendo de esta manera macro esquemas para su reutilizacin durante el desarrollo de un sistema, de forma tal que se incremente la productividad en el desarrollo de software. 1.3.2. OBJETIVOS ESPECFICOS 1. Validar patrones, y lineamientos definidos, mediante el desarrollo del sistema de la Intranet de la Facultad de Ingeniera Industrial Universidad Nacional Mayor de San Marcos. 2. Evaluar y comparar el desarrollo de un sistema de software, con el uso de patrones y sin su uso, para ponderar el impacto econmico y ahorro de plazos en proyectos similares. 3. Desarrollar un sistema de software escalable, consistente, integrado y modular bajo la reutilizacin de patrones de software. 1.4 HIPTESIS Probar que el desarrollo de un sistema complejo de software con patrones arquitectnicos, y de diseo, es una opcin tcnica viable, en el desarrollo de una Intranet para Facultad de Ingeniera Industrial UNMSM.
10
CAPITULO II: FUNDAMENTOS TERICOS
2. BASES TERICAS Para entrar al tema de los patrones en software, es necesario definir el escenario en el que stos se ubican e interactan. 2.1. ARQUITECTURA
Un concepto, de carcter vinculante con los patrones, es el concepto de arquitectura. Segn la IEEESTD-1471-2000 (Practica Recomendada Para La Descripcin Arquitectnica De Sistemas De Software Intensivos) la arquitectura es la organizacin fundamental de un sistema integrado en sus componentes, la relacin entre ellos y el medio, y los principios que establecen su desarrollo y evolucin [IEEE-1471]
11
Figura 2.1 Framework Conceptual. Fuente: [IEEE-1471]
La recomendacin IEEE Std 1471-2000 procura establecer una base comn para la descripcin de arquitecturas de sistemas de software, e implementa para ello dos trminos bsicos, que son: - Arquitectura, y - Clientes De all la importancia de esta definicin que incluye a la arquitectura como un conjunto de estructuras recurrentes (Ver Figura 2.1.).
12 2.2. CICLO DE VIDA DE SISTEMAS DE SOFTWARE ORIENTADO A OBJETOS Los objetos, tienen mayor potencial de reutilizacin que los tradicionales componentes de Software. El POLIMORFISMO permite trabajar el mismo componente en diferentes contextos, y la HERENCIA permite la reutilizacin de propiedades y mtodos de una clase abstracta, sin afectar a la clase original. La ENCAPSULACIN asla la complejidad de un subsistema del sistema que lo contiene. Los investigadores, quienes han explorado objetos, han observado, que estos surgen de un proceso altamente iterativo. El modelo fractal trata de describir las fases de esta actividad iterativa, y describe como madurar y reutilizar componentes de software resultado de esta iteracin [FOOT92].
Figura 2.2. Ciclo de Vida del Software orientado a objetos Fuente: A fractal model of the lifecycles of reusable objects [FOOT92].
13 En el Figura 2.2 se describe el proceso de evolucin del software, desde el prototipado hasta la consolidacin del software, y es en el punto de la consolidacin que la evolucin del software es dirigida por dos necesidades en conflicto: (1) el software debe satisfacer ms requerimientos (2) el software debe ser ms reutilizable [GOF95]. Los nuevos requerimientos de parte del cliente, segn la [IEEE-1471] (ver figura 2.1), aaden nuevas clases y operaciones y talvez todo un conjunto nuevo de clases heredadas, el software pasa a travs de un proceso de expansin hasta satisfacer los nuevos requerimientos. 2.3. PATRONES DE SOFTWARE No es nueva la analoga que se establece entre la arquitectura tradicional y la arquitectura de software. Christopher Alexander en 1977 public su libro A Pattern Language (Oxford University Press 1977), este libro trata sobre planificacin urbana y arquitectura de edificios, e introdujo un concepto particular del patrn. Escribe Alexander: ...Como un elemento en el mundo, cada patrn es una relacin entre cierto contexto, cierto sistema de fuerzas que ocurre repetidas veces en ese contexto y cierta configuracin espacial que permite que esas fuerzas se resuelvan. El patrn es, en suma, al mismo tiempo una cosa que pasa en el mundo y la regla que nos dice cmo crear esa cosa y cundo debemos crearla. [ALE77].
14 2.3.1. DEFINICION El patrn es una descripcin del problema y la esencia de su solucin de tal forma que sta se pueda reutilizar en diferentes casos. Es, por lo tanto, una solucin dada a un problema comn. [SOMMER02] Si se utilizan patrones en las etapas tempranas del ciclo de vida del software orientado a objetos, disminuyendo el ciclo de iteraciones en el ciclo de vida del software orientado a objetos. [GOF95]. Es necesario indicar, que los acadmicos de las ciencias de la computacin sealan, que el ciclo de vida del software nunca termina [FOO&YODER95] 2.3.2. BENEFICIOS - Disminuir nmero de iteraciones en el ciclo de vida del software [GOF 95]. - Ayuda a los desarrolladores y analistas de sistemas de software a resolver problemas, en una estructura dada. - Recoge toda la experiencia de desarrolladores a un problema, y se le asigna un sentido literal [BRAD99]. 2.3.3. REQUISITOS Los patrones tienen los siguientes elementos [GOF95]: Nombre y Clasificacin: Una palabra que resuma y describa el patrn. Intencin: Describe el problema que resuelve Alias: Otros nombres por el que es conocido este patrn
15 Motivacin: Describe el ambiente en el cual se aplica este patrn, definiendo un problema y como el patrn lo resuelve. Estructura. Representacin Grfica del patrn, en el ampliamente conocido UML (Unified Modeling Language) Participantes. Clases y objetos del patrn y sus responsabilidades. Colaboraciones: Describe la interaccin entre las clases y objetos para realizar sus responsabilidades. Consecuencias: Describe como el patrn cumple los objetivos definidos Implementacin: Cuales son los cuidados, y trucos a tomar en cuenta cuando se utiliza este patrn. Cdigo de Uso: Muestra fragmentos del cdigo que sirva de referencia tcnica, al momento de implementarlo Usos conocidos: Describe como se ha utilizado este patrn en casos prcticos Patrones Relacionados: Seala los patrones, con los que tienen algn grado de asociacin. 2.3.4. CLASIFICACIN Los patrones, han sido agrupados y clasificados por su nivel de abstraccin: PATRONES ARQUITECTNICOS Un patrn Arquitectnico, que expresa el esquema fundamental de estructura organizacional para los sistemas de software. Proveyendo un conjunto de subsistemas predefinidos, especifica
16 sus responsabilidades, e incluye las reglas y los lineamientos, para las organizaciones y las relaciones entre ellas [BMR96] (Ver Figura 2.3.). layer Capa Business layer Capa de Presentacin layer Capa de Datos 1..* 1..* 1..* 1..* Provee la interface de usuario (UI) que hace posible que el cliente interacte con el Sistema Contiene la "Lgica del Negocio" de la organizacin en componentes reusables y distribuidos Provee acceso a sistemas externos, como Base de Datos. PATRN DE ARQUITECTONICO: MODELO DE 3 CAPAS
Figura 2.3. Patrn Arquitectnico. Fuente: Elaboracin Propia
PATRONES DE DISEO En 1995 Erich Gamma, Richard Helm, Ralph J ohnson y J ohn Vlissides [GOF95], plasman los conceptos de Christopher Alexander en el libro Design Patters Elements of Reusable Object-Oriented Software. El aporte de este libro es importante ya que estableci los requisitos que debe poseer un patrn de
17 diseo orientado a objetos, y recopil los patrones de diseo ms bsicos. Es en este libro que definen 23 patrones de diseo, y los clasifican en tres categoras: Clasificacin Patrones de Diseo Patrones de Creacin Patrones de Comportamiento Patrones Estructurales Abstract Factory Chain of Responsibility Adapter Builder Commander Bridge Factory Method Interpreter Composite Prototype Iterator Decorator Singleton Mediator Faade Memento Flyweight Observer Proxy State Strategy Template Method Visitor Tabla 2.1. Patrones de Diseo Fuente: Desig Pattern Elements of Reusable Object-Oriented Software [Gof95]
A continuacin, se explica 3 de los 23 patrones de diseo, segn su clasificacin: PATRN CREACIONAL SINGLETON Su papel es la de crear una nica instancia, y provee un punto global de acceso a ella [GOF95]. La ventaja que el patrn Singleton ofrece es que permite instanciar una sola vez cualquier clase, u objeto, y controlar en el
18 mbito global la creacin de nuevas instancias, con el consecuente ahorro de recursos de memoria en tiempo de ejecucin. Por ejemplo: Tenemos una clase Usuario de la FII, este usuario puede ser un docente, un estudiante o un empleado administrativo, los tres ltimos heredan toda funcionalidad y potencia de la clase Usuario FII (Ver Figura 2.4.), para instanciar por medio de un solo punto global a las otras clases se usa el patrn Singleton. Se adjunta el diagrama UML del patrn (Ver Figura 2.5.), el cdigo de implementacin en C# (ver Cdigo 2.1), y la figura de la ejecucin del programa (Ver Figura 2.6.). Usuario FII UNMSM Docente Estudiante Personal Administrativo
Figura 2.4. Usuarios FII UNMSM. Fuente: Elaboracin Propia
Figura 2.5. Patrn Singleton. Fuente: Elaboracin Propia usi ng Syst em; usi ng Syst em. Col l ect i ons;
namespace Si ngl et on { / / / <summar y> / / / Descr i pci n de Pat r n de Di seo Cr eaci onal Si ngl et on / / / Desar r ol l ado por : Paul Lor ena / / / Cr eado: 24/ 09/ 2004 / / / </ summar y> cl ass Usuar i o { / / Mi embr os Pr i vados pr i vat e st at i c Usuar i o _gener ador ; pr i vat e Ar r ayLi st _var i abl es = new Ar r ayLi st ( ) ; pr i vat e i nt _cont ador = - 1;
/ / Const r uct or es pr ot ect ed Usuar i o( ) { / / Li st a de Var i abl es t hi s. _var i abl es. Add( " Al umno de l a FI I UNMSM" ) ; t hi s. _var i abl es. Add( " Docent e de l a FI I UNMSM" ) ; t hi s. _var i abl es. Add( " Per sonal de l a FI I UNMSM" ) ; }
/ / Mt odos publ i c st at i c Usuar i o Get I nst anci a( ) {
i f ( _gener ador == nul l ) { _gener ador = new Usuar i o ( ) ; } r et ur n _gener ador ; }
/ / Pr opi edades publ i c st r i ng _var
20 { get { / / Devuel ve i nst anci as _cont ador += 1; r et ur n t hi s. _var i abl es [ _cont ador ] . ToSt r i ng( ) ; } } } / / / Apl i caci n que ut l i za Pat r n de Di seo " Si ngl et on" publ i c cl ass Si ngl et onApp { publ i c st at i c voi d Mai n( st r i ng[ ] ar gs ) { Usuar i o _a1 = Usuar i o. Get I nst anci a( ) ; Usuar i o _a2 = Usuar i o. Get I nst anci a( ) ; Usuar i o _a3 = Usuar i o. Get I nst anci a( ) ;
Consol e. Wr i t eLi ne( " ******Pat r n Si ngl et on*******" ) ; Consol e. Wr i t eLi ne( " ***Cr eado: Por Paul Lor ena***" ) ; Consol e. Wr i t eLi ne( " " ) ; / / Eval uamos si es l a mi sma i nst anci a i f ( ( _a1 == _a2) && ( _a3 == _a1) ) Consol e. Wr i t eLi ne( " Es l a mi sma i nst anci a! ! ! ! " ) ; el se Consol e. Wr i t eLi ne( " No es l a mi sma i nst anci a! ! ! ! " ) ; / / Ver i f i camos l a cr eaci n de l as i nst anci as Consol e. Wr i t eLi ne( " " ) ; Consol e. Wr i t eLi ne( _a1. _var ) ; Consol e. Wr i t eLi ne( _a2. _var ) ; Consol e. Wr i t eLi ne( _a3. _var ) ; Consol e. Read( ) ; } } } Cdigo 2.1. Implementacin Patrn Singleton Fuente: Elaboracin Propia
Figura 2.6. Ejecucin Patrn Singleton. Fuente: Elaboracin Propia
21 PATRN DE COMPORTAMIENTO FAADE Provee una interfase unificada a un conjunto de interfaces en un subsistema. Este patrn define una interfase a alto nivel que hace al sistema, ms fcil de utilizar. [GOF95] Dividir un sistema intensivo en subsistema ayuda a disminuir la complejidad. Uno de los principales objetivos de los patrones del diseo es disminuir la comunicacin y la dependencia entre los subsistemas. El Patrn Faade provee una simple interfase para mayor facilidad a los dems subsistemas. Por ejemplo: Para un mdulo de eLearning en la Facultad de Ingeniera Industrial, un estudiante desea saber si un curso virtual esta habilitado. Para realizar esto, el Sistema debe validar a travs de otros subsistemas (que constituyen en si mismos otros mdulos) la identidad y el ciclo del usuario (subsistemas de Usuarios), que el alumno no adeude libros (subsistema de Biblioteca), y obtener la lista de documentos disponibles para el alumno y para un determinado curso. A travs del patrn Faade se puede definir una sola interfase para invocar a todos los sistemas involucrados con una simple lnea de cdigo. f i i Vi r t ual . per mi soLect ur a( _al umno) ; Se adjunta el diagrama UML del patrn (Ver Figura 2.7.), el cdigo de implementacin en C# (ver Cdigo 2.2), y la figura de la ejecucin del programa (Ver Figura 2.8.).
22 Mdulo de e Learning FII UNMSM Faade subsystem Mdulo Usuarios subsystem Mdulo Documentacin subsystem Mdulo Biblioteca Estudiante
Figura 2.7. Patrn Faade. Fuente: Elaboracin Propia
usi ng Syst em; namespace Faade { / / / <summar y> / / / Descr i pci n de Pat r n de Di seo Faade / / / Desar r ol l ado por : Paul Lor ena / / / Cr eado: 24/ 10/ 2004 / / / </ summar y> / / " SubSi st ema Usuar i os" cl ass Usuar i os { / / Mt odos publ i c bool Ver i f i caI dent i dad( Al umno a ) { Consol e. Wr i t eLi ne( " Ver i f i ca i dent i dad par a {0}" , a. nombr e ) ; r et ur n t r ue; } } / / " SubSi st ema Bi bl i ot eca" cl ass Bi bl i ot eca { / / Mt odos publ i c bool NoDebeLi br o( Al umno a ) { Consol e. Wr i t eLi ne( " Ver i f i ca l i br os adeudados par a" + a. nombr e ) ; r et ur n t r ue; } } / / " SubSi st ema Document aci n" cl ass Document aci on { / / Mt odos publ i c bool Separ at asVi r t ual es( Al umno a )
23 { Consol e. Wr i t eLi ne( " Obt i ene separ at as par a {0} " , a. nombr e ) ; r et ur n t r ue; } } cl ass Al umno { / / Dat os Pr i vados pr i vat e st r i ng Nombr e;
/ / Const r uct or es publ i c Al umno( st r i ng nombr e ) { t hi s. Nombr e = nombr e; }
/ / Pr opi edades publ i c st r i ng nombr e { get { r et ur n Nombr e; } } } / / " Pat r n Faade" cl ass eLear ni ng { / / Campos publ i c st r i ng nombr e_cur so; pr i vat e Usuar i os usuar i o = new Usuar i os( ) ; pr i vat e Bi bl i ot eca bi bl i ot eca = new Bi bl i ot eca( ) ; pr i vat e Document aci on document aci on = new Document aci on( ) ; / / Const r uct or es publ i c eLear ni ng( st r i ng _nombr e_cur so ) { t hi s. nombr e_cur so = _nombr e_cur so; } / / Mt odos publ i c bool per mi soLect ur a( Al umno a ) { / / Ver i f i ca ahor r os i f ( ! usuar i o. Ver i f i caI dent i dad ( a ) ) r et ur n f al se; i f ( ! bi bl i ot eca. NoDebeLi br o ( a ) ) r et ur n f al se; i f ( ! document aci on. Separ at asVi r t ual es ( a ) ) r et ur n f al se; r et ur n t r ue; } publ i c st r i ng _nombr e_cur so { get {r et ur n nombr e_cur so ; } } } / / / <summar y> / / / Cl i ent e Faade / / / </ summar y> publ i c cl ass FacadeApp { publ i c st at i c voi d Mai n( st r i ng[ ] ar gs) {
24 Consol e. Wr i t eLi ne( " ******Pat r n Faade*******" ) ; Consol e. Wr i t eLi ne( " ***Cr eado: Por Paul Lor ena***" ) ; Consol e. Wr i t eLi ne( " " ) ; / / Cr eaci on Pat r n Facade eLear ni ng f i i Vi r t ual = new eLear ni ng( " Mant eni mi ent o Mec" ) ; Al umno _al umno = new Al umno ( " Paul Lor ena" ) ; / / Ll amada de ot r os Susbsi st ema por Faade f i i Vi r t ual . per mi soLect ur a( _al umno) ; Consol e. Read ( ) ; } } } Cdigo 2.2. Implementacin Patrn Faade Fuente: Elaboracin Propia
Figura 2.8. Ejecucin Patrn Faade. Fuente: Elaboracin Propia
PATRN DE COMPORTAMIENTO OBSERVER Define una dependencia uno a muchos entre los objetos, de tal forma que cuando uno de los objetos cambia de estado, todas sus dependencias son actualizadas y notificadas automticamente [GOF95]. Este patrn de diseo en el mbito de comportamiento, es una herramienta muy til para la comunicacin de cambio de estado entre los objetos y los componentes. Por ejemplo: Si la Panadera de la FII UNMSM, ha decidido hacer una modificacin en el precios de los panetones, o en los plazos de entrega de producto finales, es necesario que todos los componentes (clases, y otros subsistemas) sean notificados
25 rpidamente, sin que el desarrollador se preocupe de implementar estas comunicaciones a bajo nivel (en el mbito de cdigo), estructuralmente el patrn Observer, notifica a todos los Sistemas de la Universidad (Rectorado y Facultades relacionadas) el cambio de estado o precio (cambio de lgica de negocio, etc.) Se adjunta el diagrama UML del patrn (Ver Figura 2.9.), el cdigo de implementacin en C#(ver Cdigo 2.3), y la figura de la ejecucin del programa (Ver Figura 2.10.). PATRN OBSERVER PROYECTO:FII-UNMSM ELABORADO: PAUL LORENA FECHA: 11/05/2004 MODIFICADO: 11/05/2004 Item + Notificar ( ) ControlItem + getState ( ) + setState ( ) EstadoItem + getAtributo ( ) + setAtributo ( ) ObservadorConcreto + EstadoObservador + Update ( ) Observador + Update ( ) Usa Usa 0..1
Figura 2.9. Patrn Observer. Fuente: Elaboracin Propia
26 usi ng Syst em; usi ng Syst em. Col l ect i ons;
namespace Obser ver { / / / <summar y> / / / Descr i pci n de Pat r n de Di seo Compor t ami ent o Obser ver / / / Desar r ol l ado por : Paul Lor ena / / / Cr eado: 24/ 09/ 2004 / / / </ summar y> abst r act cl ass St ock { / / Dat os Pr i vados pr ot ect ed st r i ng symbol ; pr ot ect ed doubl e pr eci o; pr i vat e Ar r ayLi st agent es = new Ar r ayLi st ( ) ;
/ / Const r uct or publ i c St ock( st r i ng symbol , doubl e pr eci o ) { t hi s. symbol = symbol ; t hi s. pr eci o = pr eci o; }
/ / Mt odos publ i c voi d At t ach( I nvest or i nvest or ) { agent es. Add( i nvest or ) ; }
publ i c voi d Det ach( I nvest or i nvest or ) { agent es. Remove( i nvest or ) ; }
publ i c voi d Not i f y( ) { f or each( I nvest or i i n agent es ) i . Updat e( t hi s ) ; }
/ / Pr opi edades publ i c doubl e Pr eci o { get { r et ur n pr eci o; } set { pr eci o = val ue; Not i f y( ) ; } }
publ i c st r i ng Symbol { get { r et ur n symbol ; } set { symbol = val ue; } } }
/ / " Concr et eSubj ect "
27
cl ass Panet on : St ock { / / Const r uct or publ i c Panet on( st r i ng symbol , doubl e pr eci o ) : base( symbol , pr eci o ) {} }
/ / " Pat r n Obser ver "
i nt er f ase I I nvest or { / / Mt odos voi d Updat e( St ock st ock ) ; }
/ / " Concr et eObser ver "
cl ass I nvest or : I I nvest or { / / Dat os Pr i vados pr i vat e st r i ng name; pr i vat e st r i ng obser ver St at e; pr i vat e St ock st ock;
/ / Const r uct or es publ i c I nvest or ( st r i ng name ) { t hi s. name = name; }
/ / Mt odos publ i c voi d Updat e( St ock st ock ) { Consol e. Wr i t eLi ne( " Compr ador {0} not i f i cado cambi o de pr eci o {1} {2: C}" , name, st ock. Symbol , st ock. Pr eci o ) ; Consol e. Wr i t eLi ne( " " ) ; }
/ / Pr opi edades publ i c St ock St ock { get { r et ur n st ock; } set { st ock = val ue; } } }
/ / / <summar y> / / / Obser ver App t est / / / </ summar y> publ i c cl ass Obser ver App { publ i c st at i c voi d Mai n( st r i ng[ ] ar gs ) { / / Cr ea Agent es I nvest or s = new I nvest or ( " Rect or ado UNMSM" ) ; I nvest or b = new I nvest or ( " FAC. Admi ni st r aci n" ) ;
28 Consol e. Wr i t eLi ne( " ******Pat r n Obser ver *******" ) ; Consol e. Wr i t eLi ne( " ***Cr eado: Por Paul Lor ena***" ) ; Consol e. Wr i t eLi ne( " " ) ; / / Cr eaci n Pat r n Obser ver / / Cr eat e st ock Panet on y adj unt a Agent es Panet on panet on = new Panet on( " Panet on" , 120. 00 ) ; panet on. At t ach( s ) ; panet on. At t ach( b ) ;
/ / Cambi o de Pr eci os, se not i f i ca a Agent es panet on. Pr eci o = 120. 10; panet on. Pr eci o = 121. 00; panet on. Pr eci o = 120. 50; panet on. Pr eci o = 120. 75; Consol e. Read( ) ; } }
} Cdigo 2.3. Implementacin Patrn Observer Fuente: Elaboracin Propia
Figura 2.10. Ejecucin de Programa con Patrn Observer. Fuente: Elaboracin Propia
29
CAPITULO III: ARQUITECTURA DEL SISTEMA
3. ARQUITECTURA DEL SISTEMA 3.1. PATRONES DE SOFTWARE UTILIZADOS Para el desarrollo del sistema de la Intranet Industrial de la Facultad de Ingeniera Industrial Universidad Nacional Mayor de San Marcos, se hace uso de los siguientes patrones de software: - Patrn Arquitectnico de 3 Capas - Patrn Informador, y - Patrn Sensor A continuacin se procede a describir cada uno de los patrones utilizados. 3.2. PATRN ARQUITECTNICO DE 3 CAPAS Para el desarrollo de la arquitectura del sistema Intranet Industrial se utiliza, el patrn arquitectnico de las 3 capas (ver figurar 3.1.).
30 Este patrn permite una visin amplia y flexible de toda la distribucin de los componentes que poseen la capa de interfase, separada de la lgica de negocio, a su vez existe la capa de datos. La ventaja de este esquema arquitectnico es que permite agrupar los componentes del sistema, en diferentes unidades lgicas funcionales durante el anlisis, el desarrollo, la implementacin y el mantenimiento. De esta forma la propia arquitectura, determina la distribucin de los componentes, y su agrupacin en capas lgicas [BMR96]. layer Capa de Presentacin layer Capa Business layer Capa de Datos Patron Sensor Refactoring Patron Informador Mdulo 1 Mdulo N ComponenteUI 1 ComponenteUI 2 Asociacin Asociado Utiliza Clases Comunes Capa de Business: Capa de Datos: Patrn Arquitectnico Creado por: Paul Lorena L. Fecha: 21/05/2004 Modificado: 24/05/2004 Capa de Presentacin: Paginas ASPX, grficos de presentacin Patron Informador
Figura 3.1. Patrn Arquitectnico FII UNMSM. Fuente: Elaboracin Propia
31 En la figura 3.1., se define la estructura del Sistema Arquitectnico definido por el patrn arquitectnico de 3 capas. Se puede distinguir tambin la existencia de componentes o subsistemas contenidos por las capas [MPLATT02]. Obsrvese la presencia de los subsistemas de Patrn Informador y el Patrn Sensor en la capa de datos y en la capa de Negocios respectivamente. Estos patrones se encuentran documentados ampliamente en el documento ARQUITECTURA EMPRESARIAL FII UNMSM, en la DOCUMENTACIN TCNICA del Sistema de la Intranet Industrial.
32 3.3. PATRN INFORMADOR Nombre Patrn: Informador Intencin: Proveer un conjunto de mtodos y propiedades para acceder a una Base de Datos, evitando rescribir cdigo, y encapsulando la complejidad de operaciones necesarias para las conexiones y procesos transaccionales. Alias: Capa de Datos, Capa Persistente. Motivacin: En una aplicacin de software se realizan operaciones tpicas de consultas y actualizaciones de una Base de Datos, estos procesos pueden incluir operaciones transaccionales. La cantidad de lneas necesarias para realizar estas operaciones es considerablemente alta, ocasionando prdida de tiempo al rescribir cdigo, y al momento de la depuracin. El patrn Informador, recopila y organiza todas las operaciones recurrentes, y las ordena dentro de una clase permitiendo a otras clases heredar y acceder a dichas funciones, evitando volver a escribir ese cdigo Estructura En la Figura 3.2., se observa, la distribucin de las clases y su interdependencia para formar el patrn Informador.
33 clsDataPrimitiveEntity + _package + _name # _store_recordset # _store_insert # _store_update ... + New ( ) # GetParameter ( ) # AddParameterInput ( ) # AddParameterOutput ( ) # Insert ( ) # ConfigUpdate ( ) # ConfigDelete ( ) clsDataPrimitiveSql + property Text + property Name - _text - _name + New ( ) + get Text ( ) + get Name ( ) clsDataPrimitiveHelper + BeginTransaction ( ) + BuildParameterInput ( ) + BuildParameterOutpu ( ) + ExecuteDataSet ( ) + ExecuteNonQuery ( ) clsDataPrimitiveTable + New ( ) + GetParameter ( ) + AddParameterInput ( ) + AddParameterOutput ( ) + ExcuteDataSet ( ) + ExecuteNonQuery ( ) clsDataPrimitiveConnection + property ConecctionString - ConnectionString + get ConecctionString ( ) clsDataPrimitiveProcedure + property Package + property Store + property Name - _package - _store - _name + New ( ) + get Package ( ) + get Store ( ) + get Name ( ) clsDataPrimitiveTransaction + property Transaction : OracleTransaction + BeginTransaction ( ) + Commit ( ) + RollBack ( ) + get Transaction ( ) 0..1 Utiliza 1..* Utiliza 1 Utiliza 1 Utiliza 1 Utiliza MANEJ ADOR DE BASE DE DATOS INTRANET FII UNMSM Creado Por: Paul Lorena L Fecha: 10/05/2004 Modificado:12/05/2004
Figura 3.2. Patrn Informador. Fuente: Elaboracin Propia
34
Participantes Clase Responsabilidad clsDataPrimitiveConnection Obtiene o define la cadena de conexin a la Base de Datos clsDataPrimitiveHelper Construye los Parmetros de acceso a la base de datos, definiendo los tipos especficos para cada proveedor clsDataPrimitiveTable Define los mtodos y operaciones (genricamente) de la clase para el ingreso de los parmetros clsDataPrimitiveProcedure Esta es una clase genrica que me permite armar los nombres de los packages y/o store procedures en la Base de Datos clsDataPrimitiveEntity Clase que establece los nombres fsicos de los packages y store procedures en la Base de Datos, adems es el punto donde se define el tamao de los parmetros de entrada clsDataPrimitiveSql Clase genrica para definir Nombre y Valor (Tipo, y variable) de ingreso clsDataPrimitiveTransaction Habilita los procedimientos transaccionales en las operaciones tpicas de Base de Datos clsDataPrimitiveTypeCLOB Clase especifica para definir la longitud del tipo CLOB Tabla 3.1. Participantes Patrn Informador Fuente: Elaboracin Propia Colaboraciones Clase Relaciones clsDataPrimitiveConnection Clase que exhibe un mtodo publico que provee la cadena de conexin a la base de datos clsDataPrimitiveHelper Esta clase es la que tiene el encargo de ejecutar todas las operaciones con la base de datos, es la nica que tiene un contacto lgico con la base de datos, es invocada por todas las dems clsDataPrimitiveTable Recoge los parmetros del Cliente y los ordena en una lista hash, y los entrega a la clase clsDataPrimitiveHelper clsDataPrimitiveProcedure Clase invocada por la clsDataPrimitiveEntity para armar los nombres de packages y store procedures
35 clsDataPrimitiveEntity Clase que exhibe sus mtodos a la ClsDataPrimitive Procedure para que arme los nombres de los objetos en la Base de datos (especificando el tamao de estos) clsDataPrimitiveSql Clase genrica para definir Nombre y Valor (Tipo, y variable) de ingreso clsDataPrimitiveTransaction Esta clase es invocada por la clase clsDataPrimitiveHelper, que define si la operacin es transaccional o no clsDataPrimitiveTypeCLOB Clase invocada por la clsDataPrimitiveTable para establecer el tamao del tipo CLOB Tabla 3.2. Colaboraciones Patrn Informador Fuente: Elaboracin Propia
CONSECUENCIAS El cdigo necesario para realizar una operacin en la base de datos es un cdigo mas compacto y claro, con menos lneas de cdigo, y haciendo uso de operaciones y mtodos con funcionalidad ya conocida. La depuracin es ms simple ya que al reutilizar clases se procede a aislar el error, al eliminar la posibilidad de hallar un error en las clases reutilizadas. Es decir hacemos que el error puntual se convierta en un error sistemtico, de esta manera es ms fcil repararlo, o detectarlo, y las modificaciones afectaran a todos las clases que hereden dicha funcionalidad. IMPLEMENTACIN Una vez implementado en el lenguaje escogido, se debe incorporar una capa adicional que permita interactuar con el patrn. Por ejemplo en la Figura 3.3, se observa 4 tablas relacionadas, para implementar el patrn Informador. En esta configuracin se procede a formar la capa adicional, de tal forma que para cada tabla se debe crear
36 una clase, y de preferencia agruparla en un dominio especifico - Namespace en C++[BSTROUSTRUP97], para este caso se establece que el dominio es igual al nombre del mdulo al cual pertenecen estas tablas: Biblioteca.
Figura 3.3. Base de Datos de Mdulo Biblioteca FII UNMSM Fuente: Elaboracin Propia
' / / Pr oyect o: I nt r anet I NDUSTRI AL FI I - UNMSM ' / / Capa de Dat os par a Tabl a Sol i ci t ud ' / / Cr eado por : Paul Lor ena ' / / Cr eado el : 08/ 10/ 2004
' / / Def i no el Domi ni o o Mdul o al que per t enece Namespace I nt r anet . FI I . Dat a. Bi bl i ot eca ' / / Def i no nombr e de Cl ase Publ i c Cl ass cl sDat asol i ci t ud ' / / Her edo f unci onal i dad del pat r n I nf or mador I nher i t s cl sDat aPr i mi t i veEnt i t y
37
#Regi on " Pr oper t i es" ' ' / / Def i no cada uno de l os campos de l a t abl a Pr i vat e _c_user As I nt eger Publ i c Pr oper t y C_User ( ) As I nt eger Get Ret ur n Me. _c_user End Get Set ( ByVal Val ue As I nt eger ) Me. _c_user = Val ue End Set End Pr oper t y Pr i vat e _c_l i br o As I nt eger Publ i c Pr oper t y C_Li br o( ) As I nt eger Get Ret ur n Me. _c_l i br o End Get Set ( ByVal Val ue As I nt eger ) Me. _c_l i br o = Val ue End Set End Pr oper t y Pr i vat e _t _cl asi f i caci on As St r i ng Publ i c Pr oper t y T_Cl asi f i caci on( ) As St r i ng Get Ret ur n Me. _t _cl asi f i caci on End Get Set ( ByVal Val ue As St r i ng) Me. _t _cl asi f i caci on = Val ue End Set End Pr oper t y Pr i vat e _c_sol i ci t ud As I nt eger Publ i c Pr oper t y C_Sol i ci t ud( ) As I nt eger Get Ret ur n Me. _c_sol i ci t ud End Get Set ( ByVal Val ue As I nt eger ) Me. _c_sol i ci t ud = Val ue End Set End Pr oper t y Pr i vat e _f _f ec_sol i ci t ud As Dat e Publ i c Pr oper t y F_Fec_Sol i ci t ud( ) As Dat e Get Ret ur n Me. _f _f ec_sol i ci t ud End Get Set ( ByVal Val ue As Dat e) Me. _f _f ec_sol i ci t ud = Val ue End Set End Pr oper t y Pr i vat e _b_at endi do As St r i ng Publ i c Pr oper t y B_At endi do( ) As St r i ng Get Ret ur n Me. _b_at endi do End Get Set ( ByVal Val ue As St r i ng) Me. _b_at endi do = Val ue End Set End Pr oper t y #End Regi on ' / / Const r uct or - Cr eo l a cl ase
38 ' / / Asi gno a mi cl ase her edada cl sDat aPr i mi t i veEnt i t y ' / / l os par met r os const r uct or es Sub New( ) MyBase. New( " bi bl i ot eca" , " sol i ci t ud" ) End Sub ' / / Modi f i co l a f unci on Conf i gI nser t de l a cl ase Base Pr ot ect ed Over r i des Sub Conf i gI nser t ( ) Me. AddPar amet er I nput ( " v_c_l i br o" , Me. _c_l i br o) Me. AddPar amet er I nput ( " v_c_user " , Me. _c_user ) Me. AddPar amet er I nput ( " v_t _cl asi f i caci on" , Me. _t _cl asi f i caci on, 30) Me. AddPar amet er I nput ( " v_c_sol i ci t ud" , Me. _c_sol i ci t ud) Me. AddPar amet er I nput ( " v_f _f ec_sol i ci t ud" , Me. _f _f ec_sol i ci t ud) Me. AddPar amet er I nput ( " v_b_at endi do" , Me. _b_at endi do, 1) End Sub ' ' / / Modi f i co l a f unci on Conf i gUpdat e de l a cl ase Base Pr ot ect ed Over r i des Sub Conf i gUpdat e( ) Me. AddPar amet er I nput ( " v_c_sol i ci t ud" , Me. _c_sol i ci t ud) Me. AddPar amet er I nput ( " v_c_l i br o" , Me. _c_l i br o) Me. AddPar amet er I nput ( " v_c_user " , Me. _c_user ) Me. AddPar amet er I nput ( " v_t _cl asi f i caci on" , Me. _t _cl asi f i caci on, 30) Me. AddPar amet er I nput ( " v_c_sol i ci t ud" , Me. _c_sol i ci t ud) Me. AddPar amet er I nput ( " v_f _f ec_sol i ci t ud" , Me. _f _f ec_sol i ci t ud) Me. AddPar amet er I nput ( " v_b_at endi do" , Me. _b_at endi do, 1)
End Sub ' / / Modi f i co l a f unci on Conf i gDel et e de l a cl ase Base Pr ot ect ed Over r i des Sub Conf i gDel et e( ) Me. AddPar amet er I nput ( " v_c_sol i ci t ud" , Me. _c_sol i ci t ud) End Sub End Cl ass End Namespace Cdigo 3.1. Refactorizacin Patrn Informador Fuente: Elaboracin Propia
Luego se procede a implementar la clase Data ' / / Pr oyect o: I nt r anet I NDUSTRI AL FI I - UNMSM ' / / Cl ase de Bi bl i ot eca ' / / Cr eado por : Paul Lor ena ' / / Cr eado el : 08/ 10/ 2004 ' / / Modi f i cado el : 10/ 10/ 2004 ' / / Cr eo l a Cl ase Bi bl i ot eca Publ i c Cl ass cl sBi bl i ot eca ' / / Def i no como mi embr o pr i vado a l a var i abl e _sol i ci t ud ' / / del t i po I nt r anet . FI I . Dat a. Bi bl i ot eca. cl sDat asol i ci t ud Pr i vat e _sol i ci t ud As I nt r anet . FI I . Dat a. Bi bl i ot eca. cl sDat asol i ci t ud ' / / cr eo l a cl ase Sub New( ) ' / / i nst anci o a _sol i ci t ud
39 Me. _sol i ci t ud = New I nt r anet . FI I . Dat a. Bi bl i ot eca. cl sDat asol i ci t ud End Sub ' / / Def i no l a oper aci n de i nser ci n Sub f unc_i ns_sol i ci t ud( _ ByVal v_c_l i br o As I nt eger , _ ByVal v_c_user As I nt eger , _ ByVal v_t _cl asi f i caci on As St r i ng) Me. _sol i ci t ud. C_Li br o = v_c_l i br o Me. _sol i ci t ud. C_User = v_c_user Me. _sol i ci t ud. T_Cl asi f i caci on = v_t _cl asi f i caci on Me. _sol i ci t ud. I nser t ( ) End Sub ' / / Def i no l a oper aci n de act ual i zaci n Sub f unc_upd_sol i ci t ud( _ ByVal v_c_sol i ci t ud As I nt eger , _ ByVal v_b_at endi do As Char ) Me. _sol i ci t ud. C_Sol i ci t ud = v_c_sol i ci t ud Me. _sol i ci t ud. C_Li br o = v_c_l i br o Me. _sol i ci t ud. C_User = v_c_user Me. _sol i ci t ud. T_Cl asi f i caci on = v_t _cl asi f i caci on Me. _sol i ci t ud. Updat e( ) End Sub ' / / Def i no l a oper aci n de bor r ado Sub f unc_del _sol i ci t ud( ByVal v_c_sol i ci t ud As I nt eger ) Me. _sol i ci t ud. C_Sol i ci t ud = v_c_sol i ci t ud Me. _sol i ci t ud. Del et e( ) End Sub ' / / Def i no l a oper aci n de Li st ado Publ i c Funct i on f unc_l st _sol i ci t ud( ) As Dat aSet Ret ur n Me. _sol i ci t ud. Recor dSet ( ) End Funct i on ' / / Def i no l a oper aci n de obt ener un sol o r egi st r o Publ i c Funct i on f unc_get _sol i ci t ud( ByVal v_c_sol i ci t ud As I nt eger ) As Dat aSet Me. _sol i ci t ud. C_Sol i ci t ud = v_c_sol i ci t ud Ret ur n Me. _sol i ci t ud. OneRecor d( ) End Funct i on Cdigo 3.2. Refactorizacin en Capa Business Patrn Informador Fuente: Elaboracin Propia CDIGO DE USO Para utilizar el Patrn Informador para la tabla Solicitud, una vez implementada la clase clsDataSolicitud. Se procede a utilizar la clase, siguiendo las siguientes lneas de cdigo:
40
Cdigo 3.3. Uso Patrn Informador Fuente: Elaboracin Propia
41 3.4. PATRN SENSOR Nombre Patrn Sensor Intencin Provee un control sistemtico de toda la aplicacin cuado se generan excepciones. Proveer un conjunto de mtodos y propiedades para almacenar y/o canalizar los mensajes de error de toda la aplicacin Alias Exception Management Motivacin En una aplicacin de software los errores, se generan, aun cuando el producto final ha sido entregado, segn el lenguaje que se utilice se podra utilizar localmente un controlador de excepciones, que da un control til, pero muy puntual sobre un error. El patrn Sensor, provee un control en el mbito de toda la aplicacin para detectar y canalizar al error de diferentes maneras: - Por la muestra de una pagina de error tpico - Almacenado toda la informacin del error en una base de datos - Proveer otro tipo de log o almacenamiento del error (envo de mail al administrador del sistema, etc.) como una alternativa del clsico Windows Application Event Log (sin excluirlo) - Provee toda la infraestructura para que el desarrollador construya su propia forma de manejar los errores de su aplicacin.
Figura 3.4. Figura de Clases Patrn Sensor Fuente: Elaboracin Propia
Participantes Clase o Interfaces Responsabilidad BaseApplicationException Esta es la clase base de excepcin usada para asegurar que todas las excepciones proveen un mnimo nivel de informacin contextual ExceptionManagerSectionHandler Esta clase es usada para recuperar los parmetros del Patrn Sensor (de un archivo XML). Estos parmetros son usados para definir el comportamiento del patrn Sensor. ExceptionManager. Clase encargada de publicar los errores del Sistema DefaultPublisher Esta clase establece una funcionalidad bsica de almacenamiento de errores IExceptionPublisher Interfaces implementadas por la clase DefaultPublisher IExceptionXmlPublisher Interfaces implementadas por la clase DefaultPublisher Tabla 3.3. Participantes Patrn Sensor Fuente: Elaboracin Propia
43 Colaboraciones Clase o Interfaces Colaboraciones BaseApplicationException Esta clase hereda todas sus propiedades y mtodos a todas las dems clases que se implementan en este patrn. ExceptionManagerSectionHandler Esta clase es invocada por ExceptionManager para heredar sus propiedades, donde se obtiene los parmetros definidos por el usuario ExceptionManager. Clase encargada de publicar los errores del Sistema DefaultPublisher Esta clase almacena los errores en el Windows Application Evento Log IExceptionPublisher. Exposicin de mtodos y propiedades del Patrn Sensor IExceptionXmlPublisher Exposicin de mtodos y propiedades del Patrn Sensor en XML Tabla 3.4. Colaboraciones Patrn Sensor Fuente: Elaboracin Propia
Consecuencias: El cdigo necesario para manejar los errores es definido en una sola lnea de cdigo. Implementacin: Incluir en el proyecto la DLL ExceptionManagement.dll, y en cada pgina de cdigo incluir la siguiente lnea: I mpor t s Mi cr osof t . Appl i cat i onBl ocks. Except i onManagement Cdigo de Uso: Para utilizar el Patrn Sensor, se procede a hacer la captura de errores en manera tradicional, y luego agregar la lnea ExceptionManage.Publish(Error)
Cdigo 3.4. Uso Patrn Sensor Fuente: Elaboracin Propia
44 3.5. COMPARACIN: OPERACIN TPICA DE BASE DE DATOS SIN PATRN Y CON PATRN INFORMADOR A continuacin se demuestra como es proceso de implementar una operacin bsica de insertar un nuevo registro, sin el uso del Patrn Informador y con su uso. Se utilizas la tabla Solicitud del Mdulo de la Biblioteca de la Intranet Industrial. SIN PATRN INFORMADOR. Este proceso se define todos los procesos necesarios para lograr la conexin con la Base de Datos (Oracle 9i) y pasar los parmetros necesarios para completar la transaccin.
Cdigo 3.5. Sin Uso de Patrn Informador Fuente: Elaboracin Propia Cdigo 3.6. Sin Uso de Patrn Informador Fuente: Elaboracin Propia
45 Un desarrollador tiende a escribir este cdigo habitualmente. Estando ms expuesto a que producir errores, adems su legibilidad es afectada, si otra persona se hace cargo del mantenimiento, el cdigo adems nos muestra que hay mucha redundancia y reescritura de cdigo. USO DE PATRN INFORMADOR Con el uso del Patrn Informador, el desarrollador solo utiliza 2 lneas de cdigo para realizar la insercin de un nuevo registro en la tabla solicitud de la Base de Datos. Ver cdigo 3.6. El cdigo resultado es mucho ms compacto y legible.
Cdigo 3.7. Uso Patrn Informador Fuente: Elaboracin Propia
46
CAPITULO IV: DESARROLLO SISTEMA INTRANET INDUSTRIAL 4. INTRODUCCIN La Intranet Industrial de la FII UNMSM, ha sido desarrollada sobre la base de los conceptos, patrones arquitectnicos y de diseos anteriormente definidos. Ya que se trata de un sistema de software complejo, el anlisis y desarrollo se encuentra documentada detalladamente en la DOCUMENTACIN TCNICA del Sistema de la Intranet Industrial, presentado al final del trabajo. 4.1. REQUERIMIENTOS Todos los Requerimientos del Sistema de la INTRANET INDUSTRIAL estn recopilados en el documento REQUERIMIENTOS INTRANET INDUSTRIAL de la DOCUMENTACIN TCNICA del Sistema de la Intranet Industrial. Los requerimientos por mdulos, estn especificados en la documentacin tcnica de cada mdulo.
47
4.2. VISIN DEL PROYECTO La Intranet de la Facultad de Ingeniera Industrial UNMSM, es un a herramienta de comunicacin y colaboracin entre todos los integrantes de la organizacin, docentes, alumnos, personal administrativo, y exalumnos. 4.3. MISIN DE PROYECTO Establecer la Arquitectura Empresarial (AE) de la Facultad de Ingeniera Industrial, as como la metodologa, patrones y lineamientos a observar para los futuros desarrollos e implementaciones de sistemas de software. 4.4. ALCANCES DEL PROYECTO La INTRANET INDUSTRIAL es un sistema que ser utilizado por: Docentes, Estudiantes, Personal Administrativos, y Ex alumnos, de la Facultad de Ingeniera Industrial UNMSM. La Intranet es un sistema que tiene, inicialmente, los siguientes mdulos funcionales: - Mdulo de Usuarios - Mdulo de Contactos - Mdulo de Repositorio de Documentacin - Mdulo de Noticias - Mdulo de Auditorio
48 - Mdulo de Empresas - Mdulo de Bolsa de Trabajo - Mdulo de Mailing - Mdulo de una Tienda En Lnea - Mdulo de Encuestas - Mdulo de Administracin Futuras implementaciones sern soportadas por el Sistema si se observan la arquitectura, y los lineamientos definidos. En la figura 4.1 se observa la interaccin de los usuarios con los mdulos de la INTRANET INDUSTRIAL. Usuario Mdulo de Auditorio Mdulo de Bolsa de Trabajo Mdulo de Contactos Mdulo de Documentacin Mdulo de Empresas Mdulo de Encuestas Mdulo de Mailing Mdulo de Noticias Mdulo de Administracin Mdulo de Tienda En Linea Mdulo de Usuarios access access access access access access access access access access CASO DE USO: MDULOS INTRANET INTRANET FII UNMSM Creado Por: Paul Lorena L Fecha: 07/05/2004 Modificado: 07/05/2004 Logearse
49 Figura 4.1. Interaccin de Usuario con la INTRANET INDUSTRIAL 4.5. ESPECIFICACIONES LENGUAJE. El Sistema de la Intranet Industrial ser desarrollada en Visual Basic .NET, Framework versin 1.1. La aplicacin ser soportada por la siguiente infraestructura tcnica: Software Version Proveedor Observaciones Windows 2000 Microsoft SP2 IIS 5.0 Microsoft .Net Framework 1.1.4 Microsoft
4.6. FUNCIONALIDAD DEL SISTEMA La INTRANET INDUSTRIAL, ser un sistema que tendr la siguiente funcionalidad: - Acceso a mdulos a travs de roles y permisos - Repositorio nico de Datos, integracin total. - Modularidad, la arquitectura debe permitir acoplar otros mdulos. - Disponibilidad 24/7 - Seguridad en el manejo de la informacin sensible.
4.7. METODOLOGA La metodologa a utilizar para el desarrollo de la intranet, es la establecido por los lineamientos del Rational Unified Process (RUP), (ver figura 4.1.)
50
Figura 4.2 Metodologa RUP. Fuente: Rational Software Corp.
RUP, es una metodologa, de desarrollo de sistemas complejos, que se basa en las siguientes practicas: - Desarrollo iterativo. El producto en el mbito del anlisis, diseo, codificacin, y documentacin iterativa. Estas iteraciones disminuyen los riesgos. Cada iteracin es una entrega del producto (release) [RUP03]. (Ver figura 4.2.).
51
Figura 4.3. Desarrollo Iterativo. Fuente: Rational Software Corp.
- Administracin de Requerimientos. Mantener en estricto control y seguimiento todo el cambio de versiones a nivel de cdigo fuente, requerimientos, etc. [RUP03]. Para el desarrollo de la Intranet Industrial, se hace un control estricto de los requerimientos, ver en la DOCUMENTACIN TCNICA del Sistema de la Intranet Industrial. - Uso de componentes arquitectnicos. En RUP las actividades de diseo, estn centralizadas en el mbito de nociones del concepto de arquitectura de software. Los componentes arquitectnicos estn integrados por componentes independientes, modulares, y reemplazables ayudan a administrar la complejidad del sistema y alientan el concepto de reutilizacin [RUP03]. - Modelamiento visual con UML. Modelamiento visual es el uso de la notacin semntica rica a nivel visual y de texto, para
52 capturar y esquematizar los procesos de una organizacin [RUP03]. (Ver figura 4.3). Adems: Ayuda a comprender sistemas complejos Explorar y analizar alternativas a bajos costos Capturar los requerimientos de los clientes Comunicar especificaciones tcnicas sin ambigedades. Administracin del Cambio. Para el diseo y el desarrollo de sistemas intensivos de software, es necesario contar con diferentes versiones de documentacin, programas, prototipos, se debe llevar control de todos estos cambios, por lo que para la documentacin es controlada por versiones (Ver en la DOCUMENTACIN TCNICA del Sistema de la Intranet Industrial) 4.4. HERRAMIENTAS PARA EL ANLISIS Y DISEO Para Anlisis y Diseo del sistema, se hace uso del Software Rational XDE Version 2003.06.00 de Rational Corporation (plug in en Visual Studio 2003) [RXDE03]. Este es un producto ideal que permite el modelamiento visual en UML vara las fases de anlisis y diseo. Tiene toda la potencia y funcionalidad del producto de modelamiento del producto Rational Rose, la ventaja que XDE se integra al IDE (Interfase Development Environment) de Visual Studio.NET (Ver figura 4.3). Esta es una herramienta sofisticada de
53 modelamiento y anlisis, existe documentacin disponible para el entrenamiento en el uso del XDE para NET [EGXDE02].
Figura 4.4. Modelamiento de Clases. Fuente: Elaboracin Propia
54
Figura 4.5. Modelamiento con XDE Fuente: Elaboracin Propia
4.5. HERRAMIENTAS PARA DESARROLLO DEL SISTEMA 4.5.1. HERRAMIENTAS PARA EL DESARROLLO DEL CDIGO (APLICACIN) Para el desarrollo y construccin de clases y cdigo, se utiliza el Microsoft Visual Studio 2003. (Ver figura 4.5).
55
Figura 4.6. Desarrollo en Visual Studio 2003 Fuente: Elaboracin Propia
56 4.5.2. HERRAMIENTAS PARA EL ANLISIS Y DESARROLLO EN EL MBITO DE BASE DE DATOS Para el anlisis y diseo de la Base de Datos se usa el paquete All Fusion Data Modeler Erwin Version 4.1.2208 (Computer Associates CA), que permite realizar Figuras de Entidad Relacin a alto nivel, antes de materializarlo en la Base de datos. (Ver figura 4.6). Esto es importante porque disminuye los costos de anlisis, al existir una etapa previa de evaluacin y modelamiento antes de llevarlo a la base de datos.
Figura 4.7. Modelamiento de Entidad Relacin (Erwin). Fuente: Elaboracin Propia
57
Para el manejo de la Base de Datos Oracle 9i (especificado en el documento de Requerimientos), puede utilizar la propia herramienta que brinda el suite Oracle (SQL PLUS, de Oracle Corporation), para este proyecto se utiliza el software Toad Version 7.6.0.11 (Quest software) (Ver figura 4.7).
Figura 4.8. Codificacin de Base de Datos (Toad). Fuente: Elaboracin Propia
A continuacin se muestran algunas vistas del sistema de la INTRANET INDUSTRIAL
58
Figura 4.9. Vista de pgina de Login Intranet Industrial
Figura 4.10. Vista de pgina de pgina de inicio Home de la Intranet Industrial
59
Figura 4.11. Detalle de Noticias
Figura 4.12. Visualizacin de Contenido de Carpeta
60 4.6. CRONOGRAMA DE TRABAJO
Figura 4.13. Cronograma de Trabajo Fuente: Elaboracin Propia ID Tarea Duracin Fecha Inicio Fecha Fin Nota Recursos 1 Fase de Concepcin 74 das 10/05/04 19/08/04 La Fase de Concepcin es importante para los objetivos de desarrollo del Sistema, porque es la fase en la cual se define los lineamientos de negocio y los requerimientos, que el Sistema de la Intranet Industrial FII UNMSM debe resolver.
2 Misin y Visin del Proyecto 2 das 10/05/04 11/05/04 Se definen cuales es el objetivo del Proyecto, cuales son las metas, que es lo que se quiere demostrar al desarrollar el Sistema de La Intranet Industrial. Ing.Ruiz, Paul Lorena 3 Alcances 1 da 12/05/04 12/05/04 Se define cual es el mbito y los subsistemas que sern afectados por el Sistema. Ing.Ruiz, Paul Lorena 4 Requerimientos del Sistema 4,5 das 13/05/04 19/05/04 Una vez definida, los alcances y los mdulos del sistema, el Ing. Ruiz redacta todos los requerimientos que debe tener cada uno de los subsistemas (Mdulos de la Intranet). Paul Lorena 5 Modelamiento 1 da 19/05/04 20/05/04 El modelamiento comienza una vez que se ha definido a muy alto nivel, la misin, la visin, los alcances y requerimientos del Sistema. Paul Lorena 6 Documentacin 74 das 10/05/04 19/08/04 La documentacin del todo el proyecto es un proceso importante tanto para los desarrolladores y analistas, para los usuarios especializados y bsicos, sino que constituye un documento fundamental en el mantenimiento y escalabilidad posterior del sistema. Paul Lorena 7 Fase de Elaboracin 54,5 das 24/05/04 06/08/04 La meta de la Fase de Elaboracin es definir los lineamientos de la arquitectura del Sistema, para proveer una base estable que sea el marco de referencia para el diseo y la implementacin. La estabilidad de la arquitectura es evaluada a travs de uno o ms prototipo arquitectnico.
8 Anlisis del Sistema 54,5 das 24/05/04 06/08/04 Se realiza un anlisis del sistema en el mbito lgico, si el sistema involucra procesos ms sensibles organizacionalmente, se debe hacer un seguimiento mas profundo del workflow. Ing.Ruiz, Paul Lorena 9 Diseo del Sistema 53 das 24/05/04 04/08/04 Se procede a levantar los diagramas UML, el diseo de la Entidad Relacin (ER) de la Intranet Industrial. Paul Lorena 10 Diseo Visual 21 das 31/05/04 28/06/04 Sobre la base de los requerimientos visuales del Sistema (Ver adjunto DEV ESTRUCTURA VISUAL INTRANET INDUSTRIAL FII UNMSM) se realiza los primeros prototipos de diseo visual, de acuerdo al look and feel definido en el documento. David Rodriguez 11 Implementacin 30,5 das 16/06/04 28/07/04 Se procede a preparar todo el marco de desarrollo necesario para la etapa Paul Lorena
de la Fase de Construccin, es decir se instala los scripts en la Base de Datos, el esbozo de las clases utilizadas y su distribucin segn lineamientos del Patrn Arquitectnico. 12 Fase de Construccin 48,5 das 07/06/04 12/08/04 La meta de la fase de Construccin es clarificar los requerimientos y completar el desarrollo del sistema basados en el Esquema Arquitectnico (definido por el patrn arquitectnico y los patrones de diseo). La fase de Construccin, es en alguna forma parecida a un proceso de manufactura, donde se pone nfasis al control de recursos, control de operaciones, optimizar los costos, plazos y la calidad.
13 Desarrollo Mdulo Administracin 7,5 das 07/06/04 16/06/04 En este mdulo se desarrolla todo lo relacionado a la Administracin de Permisos, seguridad, roles tablas Maestras, control de Usuarios. Esto incluye la codificacin en la Base de Datos (Capa de Datos) y la codificacin en la Capa de Negocios, y la Interfase (Capa de Presentacin). Paul Lorena 14 Desarrollo Mdulo Usuarios 4,5 das 16/06/04 22/06/04 En este mdulo se desarrolla todo lo relacionado al control de Usuarios. Esto incluye la codificacin en la Base de Datos (Capa de Datos) y la codificacin en la Capa de Negocios, y la Interfase (Capa de Presentacin). Paul Lorena 15 Desarrollo Mdulo Empresas 8 das 22/06/04 01/07/04 En este mdulo se desarrolla todo lo relacionado al Control de Empresas, este modulo es un modulo fundamental para otros mdulos. Esto incluye la codificacin en la Base de Datos (Capa de Datos) y la codificacin en la Capa de Negocios, y la Interfase (Capa de Presentacin). Paul Lorena 16 Desarrollo Mdulo Encuestas 4,5 das 06/07/04 12/07/04 En este mdulo se desarrolla todo lo relacionado a las encuestas que tendrn los alumnos, docentes, personal administrativo y exalumnos de la FII UNMSM. Esto incluye la codificacin en la Base de Datos (Capa de Datos) y la codificacin en la Capa de Negocios, y la Interfase (Capa de Presentacin). Paul Lorena 17 Desarrollo Mdulo Noticias 1 da 12/07/04 12/07/04 En este mdulo se desarrolla todo lo relacionado a las Noticias dela FII UNMSM. Esto incluye la codificacin en la Base de Datos (Capa de Datos) y la codificacin en la Capa de Negocios, y la Interfase (Capa de Presentacin). Paul Lorena 18 Desarrollo Mdulo Bolsa de Trabajo 3,5 das 13/07/04 16/07/04 En este mdulo se desarrolla todo lo relacionado a la Administracin de la Bolsa de Trabajo de la FII UNMSM. Este es un Mdulo que interacta con el Mdulo de Empresas y Contactos. Esto incluye la codificacin en la Base de Datos (Capa de Datos) y la codificacin en la Capa de Negocios, Paul Lorena
63
y la Interfase (Capa de Presentacin). 19 Desarrollo de Mdulo Mailing 3,5 das 16/07/04 21/07/04 En este mdulo se desarrolla todo lo relacionado al envo de Mail a los contactos empresariales o contactos institucionales de la FII UNMSM. Esto incluye la codificacin en la Base de Datos (Capa de Datos) y la codificacin en la Capa de Negocios, y la Interfase (Capa de Presentacin). Paul Lorena 20 Desarrollo de Mdulo de Tienda en Lnea 8,5 das 22/07/04 03/08/04 En este mdulo se desarrolla todo lo relacionado a la Administracin de la Tienda en Lnea para exhibir los productos y servicios de la FII. Esto incluye la codificacin en la Base de Datos (Capa de Datos) y la codificacin en la Capa de Negocios, y la Interfase (Capa de Presentacin). Paul Lorena 21 Desarrollo de Mdulo de Biblioteca 7,5 das 03/08/04 12/08/04 En este mdulo se desarrolla todo lo relacionado al control, y bsqueda de Material Bibliogrfico de la FII UNMSM. Esto incluye la codificacin en la Base de Datos (Capa de Datos) y la codificacin en la Capa de Negocios, y la Interfase (Capa de Presentacin) Paul Lorena 22 Testing 48,5 das 07/06/04 12/08/04 Se controla la solidez del sistema, es un proceso continuo, que persiste hasta el final del proyecto. Ing.Ruiz, Paul Lorena 23 Transicin 8 das 10/08/04 19/08/04 La fase de Transicin se ocupa en asegurar que el software sea disponible a los usuarios finales. En esta etapa tambin se optimiza, se configura y perfecciona el producto con el feedback del usuario Final.
24 Instalacin 8 das 10/08/04 19/08/04 Se realiza la primera instalacin del Sistema en la FII UNMSM. Se denomina Versin 1.0.2. Paul Lorena, Brack Hernandez 25 Optimizacin del Producto 7 das 11/08/04 19/08/04 Los usuarios finales deben dar su feedback o sus observaciones acerca del Sistema de la Intranet, esto constituye el final de la 1era. Iteracin. Paul Lorena
Tabla 4.1. Distribucin de Plazos y Recursos segn el RUP Fuente: Elaboracin Propia
64
CAPITULO V: COSTO DE UTILIZAR PATRON INFORMADOR
5. INTRODUCCIN Para evaluar el impacto econmico en el uso del Patrn Informador, es importante ponderar los costos en los que se incurre al desarrollar el sistema de la Intranet Industrial con el Patrn y evaluar el costo de hacerlo sin Patrn. El Modelo Constructivo de Costos, o ms conocido por CoCoMo por Constructive Cost Model, fue desarrollado por Barry. W. Boehm a finales de los 70, exponindolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981). COCOMO [BOEHM81] es una jerarqua de modelos de estimacin de costos software, de naturaleza emprica, desarrollada a partir de 71 proyectos de software. 5.1. MODELO COCOMO En este modelo se introducen 15 atributos de costo para tener en cuenta el entorno de trabajo. Estos atributos se utilizan para ajustar el costo
nominal del proyecto al entorno real, incrementando la precisin de la estimacin. Las ecuaciones de estimacin del esfuerzo de desarrollo tienen la siguiente forma [BOEHM81] EAF EDSI a PM b * * = Ecuacin 5.1 Donde: EDSI el nmero de miles de lneas de cdigo fuente EAF es un multiplicador que depende de 15 atributos PM Personal Mensual necesario para el desarrollo de lneas
Intermedio Modo a b Orgnico 3.2 1.05 Semiencajado 3.0 1.12 Empotrado 2.8 1.2
Tabla 5.1. Factores en estimacin de esfuerzo Fuente: [BOEHM81]
Para realizar el clculo de la duracin del desarrollo de las lneas en meses Boehm propone la siguiente ecuacin emprica:
38 . 0 * 5 . 2 PM ses DuracionMe = Ecuacin 5.2 Donde: PM (Personal Mensual) =obtenido de la ecuacin 5.1
5.1.2. Atributos de costo. Estos atributos tratan de capturar el impacto del entorno del proyecto en el costo de desarrollo. De un anlisis estadstico de ms de 100 factores que influencian el costo, Boehm retuvo 15 de ellos para COCOMO.
66
Estos atributos se agrupan en cuatro categoras: atributos del producto, atributos del ordenador, atributos del personal y atributos del proyecto. (1) Atributos del producto RELY: garanta de funcionamiento requerido al software DATA: tamao de la base de datos CPLX: complejidad del producto (2) Atributos del ordenador TIME: restriccin de tiempo de ejecucin STOR: restriccin del almacenamiento principal VIRT: volatilidad de la mquina virtual TURN: tiempo de respuesta del ordenador (3) Atributos del personal ACAP: capacidad del analista AEXP: experiencia en la aplicacin PCAP: capacidad del programador VEXP: experiencia en mquina virtual LEXP: experiencia en lenguaje de programacin (4) Atributos del proyecto MODP: prcticas de programacin modernas TOOL: utilizacin de herramientas software SCED: plan de desarrollo requerido. Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo -- bajo -- nominal -- alto -- muy alto -- extremadamente alto.
67
En la tabla 5.1., se muestran los valores del multiplicador para cada uno de los 15 atributos. Estos 15 valores se multiplican al K n , y nos proporciona el esfuerzo ajustado al entorno. VL LO NM HI VH XH uAtributos de Sistema RELY Confiabilidad de Software Requerida 0,75 0,88 1,00 1,15 1,40 1,40 DATA Tamao de Base de Datos 0,94 0,94 1,00 1,08 1,16 1,16 CPLX Complejidad del Sistema 0,70 0,85 1,00 1,15 1,30 1,65 Atributos Computacionales TIME Restriccin de Tiempo de Ejecucin 1,00 1,00 1,00 1,11 1,30 1,66 STOR Restriccin en Almacenamiento 1,00 1,00 1,00 1,06 1,21 1,56 VIRT Volatilidad de Maquina Virtual 0,87 0,87 1,00 1,15 1,30 1,30 TURN Tiempo de Respuesta del Sistema 0,87 0,87 1,00 1,07 1,15 1,15 Atributos de Personal ACAP Capacidad de Analista 1,46 1,19 1,00 0,86 0,71 0,71 AEXP Experiencia de Aplicacin 1,29 1,13 1,00 0,91 0,82 0,82 PCAP Capacidad del Programador 1,42 1,17 1,00 0,86 0,70 0,70 VEXP Experiencia en Maquina Virtual 1,21 1,10 1,00 0,90 0,90 0,90 LEXP Experiencia en Programacin OO 1,14 1,07 1,00 0,95 0,95 0,95 Atributos de Proyecto MODP Practicas Modernas de Programacin 1,24 1,10 1,00 0,91 0,82 0,82 TOOL Herramientas de Software 1,24 1,10 1,00 0,91 0,83 0,83 SCED Plazo Requerido de Desarrollo 1,23 1,08 1,00 1,04 1,10 1,10
Tabla 5.2. Atributos de Costo Fuente: [BOEHM81]
68
ndices Parmetros de Costo Very Low Low Nominal High Very High Extra High VL LO NM HI VH XH RELY Efecto ligero, sin inconvenientes Bajo, fcilmente Recuperable Moderado, prdidas recuperables Altas prdidas financieras Riesgo de vida humana DATA No Data Data en archivos de texto Base de Datos Relacional BD con integridad relacional y vistas BD con integridad relacional y vistas y procesos transaccionales CPLX Formularios Simples Formulario Simple con complejas Funciones Mltiples formularios nico usuario Mltiples formularios, multihilo o multiusuario Ambos Formularios con funciones complejas Sistemas Crticos TIME <50% uso CPU 70% 85% 95% STOR <50% uso de DISCO 70%, espacio de disco limitado 85%, espacio de disco limitado 95% VIRT Cambio Mnimo Cambio poco frecuente Cambio Frecuente Cambio muy frecuente TURN Interactivo <4 horas 4-12 Horas >12 horas ACAP 15 % 35 % 55 % 75 % 90 % AEXP <4 meses 1 ao 3 aos 6 aos 12 aos PCAP 15% 35% 55% 75% 90% VEXP <1 mes 4 meses 1 ao 3 aos LEXP <1 mes 5 meses 2 ao 4 aos MODP No Usado Comenzando a usar Algn Uso Uso General Uso de Rutina TOOL Pequeas herramientas 2 GL IDE con herramientas de Depuracin Lenguajes, POO, y componentes Herramientas adicionales de trabajo SCHED 70% Nom 85% 100% 130% 160%
Tabla 5.3.: ndice de Costos de Software Fuente: Boehm, Barry. "Software Engineering Economics" [BOEHM81]
69
5.2. Clculo de costos del sistema de la Intranet Industrial al utilizar Patrn Informador Para evaluar el ahorro que se incurre al utilizar el patrn informador, se procede a realizar un clculo aproximado del costo del Sistema de la Intranet industrial, utilizando el Modelo Constructivo de Costos (CoCoMo), anteriormente expuesto. 5.2.1. Procedimiento Experimental Se procede a realizar al conteo de las lneas de cdigo involucradas en las 3 operaciones bsicas de todo sistema de Software con la Base de Datos (Insercin, Actualizacin, y Eliminacin), las muestras se agrupan de la misma forma que los subsistemas o mdulos del sistema, escogiendo una tabla de cada tabla. Para comparar las mismas operaciones sin el uso del Patrn Informador, se procede a hacer el cdigo necesario para realizar las mismas operaciones bsicas con la base de datos pero, esta vez sin aplicar el Patrn informador.
Tabla 5.4.: Muestreo de Lneas de Cdigo Usando Patrn Informador Fuente: Elaboracin Propia
Muestreo de Nmero de Lneas Para Operaciones con Base de Datos en Intranet Industrial FII UNMSM SIN USO DE PATRN INFORMADOR Nmero de Lneas Mdulo Tabla Insercin Actualizacin Eliminacin Total LDC Administracin Actividad 24 23 14 61 Auditorio SalaReserva 59 59 14 132 Biblioteca Prstamo 64 69 14 147 Bolsa de Trabajo Oferta_Laboral 81 85 14 180 Contactos Contactos 105 106 14 225 Empresa Tipo_Doc 24 23 14 61 Encuesta Enc_Det_Vot 24 23 14 61 Noticia Noticia 81 85 14 180 Usuarios Emp_Idioma 41 46 14 101 Repositorio Documento 50 51 14 115 Tienda en Lnea Categora 42 42 14 98
Tabla 5.5.: Muestreo de Lneas de Cdigo Sin Patrn Informador Fuente: Elaboracin Propia
72
Comparacin de Nmero de Lneas Para Operaciones con Base de Datos en Intranet Industrial FII UNMSM CON USO Y SIN USO DE PATRN INFORMADOR Nmero de Lneas De Cdigo (LDC) Insercin Actualizacin Eliminacin Mdulo Tabla Con Patrn Sin Patrn Con Patrn Sin Patrn Con Patrn Sin Patrn Administracin Actividad 16 24 16 23 12 14 Auditorio SalaReserva 33 59 32 59 12 14 Biblioteca Prestamo 26 64 14 69 12 14 Bolsa de Trabajo Oferta_Laboral 30 81 31 85 12 14 Contactos Contactos 51 105 52 106 12 14 Empresa Tipo_Doc 14 24 14 23 12 14 Encuesta Enc_Det_Vot 16 24 16 23 12 14 Noticia Noticia 40 81 40 85 12 14 Usuarios Emp_Idioma 18 41 20 46 12 14 Repositorio Documento 26 50 26 51 12 14 Tienda en Lnea Categoria 20 42 21 42 12 14
Tabla 5.6.: Cuadro Comparativo de lneas de Cdigo Con Uso y Sin Uso de Patrn Informador Fuente: Elaboracin Propia
73
Factores de Costo (Constructive Cost Model) Intranet Industrial UNMSM Con Patrn Sin Patrn ndice Valor ndice Valor RELY LO 0,88 LO 0,88 DATA VH 1,16 VH 1,16 CPLX NM 1,00 NM 1,00 TIME HI 1,11 HI 1,11 STOR NM 1,00 NM 1,00 VIRT LO 0,87 LO 0.87 TURN VL 0,87 VL 0,87 ACAP NM 1,00 NM 1,00 AEXP LO 1,13 LO 1,13 PCAP NM 1,00 NM 1,00 VEXP NM 1,00 NM 1,00 LEXP NM 1,00 NM 1,00 MODP HI 0,91 VL 1,24 TOOL HI 0,91 NM 1,00 SCHED HI 1,04 HI 1,04
Tabla 5.7.: Factores de Costo Fuente: Elaboracin Propia Semanas /Mes 4,17 Das / Semana 5 Hora / Da 8
Tabla 5.8.: Consideraciones de Tiempos Fuente: Elaboracin Propia
74
Formulario Comparativo de Nivel de Estimacin por Mdulo (Constructive Cost Model) Intranet Industrial UNMSM EDSI EAF PM Nominal PM Ajustado Productividad Semanas Das
Miles de Lneas de Cdigo Factor de Esfuerzo Ajustado Personal Mensual Personal Mensual PMA / EDSI Productividad*Mes Mes*Das/Mes
Con Patrn Sin Patrn Con Patrn Sin Patrn Con Patrn Sin Patrn Con Patrn Sin Patrn Con Patrn Sin Patrn Con Patrn Sin Patrn Con Patrn Sin Patrn Administracin 0,034 0,061 0,959 1,437 0,08814 0,24382 0,085 0,350 2,487 5,742 10,37 23,94 51,85 119,72 Auditorio 0,067 0,132 0,959 1,437 0,17968 0,54836 0,172 0,788 2,573 5,968 10,73 24,89 53,64 124,43 Biblioteca 0,038 0,147 0,959 1,437 0,09906 0,61397 0,095 0,882 2,501 6,000 10,43 25,02 52,14 125,10 Bolsa de Trabajo 0,062 0,180 0,959 1,437 0,16563 0,75946 0,159 1,091 2,563 6,061 10,69 25,27 53,44 126,37 Contactos 0,104 0,225 0,959 1,437 0,28511 0,95997 0,274 1,379 2,630 6,129 10,97 25,56 54,84 127,79 Empresa 0,030 0,061 0,959 1,437 0,07729 0,24382 0,074 0,350 2,472 5,742 10,31 23,94 51,53 119,72 Encuesta 0,034 0,061 0,959 1,437 0,08814 0,24382 0,085 0,350 2,487 5,742 10,37 23,94 51,85 119,72 Noticia 0,082 0,180 0,959 1,437 0,22214 0,75946 0,213 1,091 2,599 6,061 10,84 25,27 54,19 126,37 Usuarios 0,040 0,101 0,959 1,437 0,10454 0,41400 0,100 0,595 2,507 5,888 10,46 24,55 52,28 122,77 Repositorio 0,054 0,115 0,959 1,437 0,14327 0,47446 0,137 0,682 2,545 5,927 10,61 24,71 53,07 123,57 Tienda en Lnea 0,043 0,098 0,959 1,437 0,11279 0,40110 0,108 0,576 2,516 5,880 10,49 24,52 52,47 122,59 Totales 1,502 8,134 27,880 65,139 116,259 271,630 581,297 1358,148 Duracin (meses)* 2,918 5,544 *Clculo Duracin 2,5*PM^0,38 Tabla 5.9.: Clculo de Esfuerzo Ajustado y Productividad Fuente: Elaboracin Propia Para el clculo del esfuerzo ajustado (EAF) se utiliza los ndices de costos, y las Consideraciones de Tiempo indicadas en las Tablas 5.7 y 5.8 respectivamente. PM (Personal Mensual) =3.2 * EAF * EDSI ^1.05 (Ecuacin 5.1) PMA (Personal Mensual Ajustado) =PM * EAF
75
Figura 5.5.: Semanas Necesarias para completar las operaciones Bsicas Fuente: Elaboracin Propia
76
Costos con Patrn (Constructive Cost Model) Intranet Industrial UNMSM
Tabla 5.12.: Clculo de Costos sin Patrn Informador Fuente: Elaboracin Propia
Plazos Sin Patrn (Constructive Cost Model II) Intranet Industrial UNMSM
Meses Semanas Das Horas Fases RUP Distribucin 1 4.17 6 6.50 Concepcin 10% 0.55 2.31 13.86 90.10 *No Includo en el Clculo Elaboracin 10% 0.55 2.31 13.86 90.10 Construccin 75% 4.16 17.33 103.96 675.73 Transicin 5% 0.28 1.16 6.93 45.05 Total 4.99 20.79 124.75 810.87
Tabla 5.13.: Clculo de Plazos con Patrn Informador Fuente: Elaboracin Propia
78
COSTOS DESARROLLO MDULOS INTRANET INDUSTRIAL FII CON PATRN (CONSTRUCTIVE COST MODEL) $4,956.65 $915.37 $61.02 $122.05 $122.05 $660.89 $660.89 $330.44 $- $1,000.00 $2,000.00 $3,000.00 $4,000.00 $5,000.00 $6,000.00 Concepcin Elaboracin Construccin Transicin Fases Rational Unified Process U S
$ Costos Con Patrn Costos Sin Patrn
Figura 5.6.: Costos Desarrollo Mdulos Intranet Fuente: Elaboracin Propia
79
Plazos Estimados en Meses (Modelo Constructivo de Costos) INTRANET FII UNMSM 4.99 2.63 0.00 1.00 2.00 3.00 4.00 5.00 6.00 Sin Patrn Con Patrn M e s e s
Figura 5.7.: Comparacin Plazos Estimados Desarrollo Mdulos Intranet Fuente: Elaboracin Propia
80
Costo Estimado en US $ (Modelo Constructivo de Costos) INTRANET FII UNMSM 1098.44 5947.98 0.00 1000.00 2000.00 3000.00 4000.00 5000.00 6000.00 7000.00 Sin Patrn Con Patrn M e s e s
Figura 5.8.: Comparacin Costos Estimados Desarrollo Mdulos Intranet Fuente: Elaboracin Propia
81 5.3. EXPLICACIN Tabla 5.4, y 5.5 se recolecta el nmero de lneas, agrupados por los mdulos del sistema de la Intranet Industrial, y diferenciadas por las operaciones bsicas de la base de datos (Insercin, Actualizacin, y Eliminacin). En la tabla 5.6 se muestra la comparacin de las 2 tablas anteriores. Tabla 5.7. En esta tabla se definen los valores para cada uno de los 15 parmetros, que constituyen la variable EAF (Factor de Esfuerzo Ajustado) en la ecuacin 5.1. Observar que se han modificado 2 parmetros para ambos escenarios, para obtener el EAF: MODP: Toma un valor de HIGH (HI=0.91) para el clculo de costo con uso de patrones, y para el clculo sin uso de patrones toma el valor de LOW (LO=1.10). Esto se explica, porque MODP es un factor, dentro de la categora de Atributos de Proyecto (ver tabla 5.2), y su ndice indica el grado de utilizacin de tcnicas modernas de programacin. Utilizamos HIGH porque cuando se hace uso de Patrones se utiliza toda la riqueza y la potencia de la programacin orientada a objetos, herencia, interfaces, y encapsulacin. En cambio cuando no se utiliza patrones no se hace uso de ninguna de estas propiedades de la herramienta, por esta razn se aplica el ndice LOW. TOOL: Toma un valor de HIGH (HI=0.91) para el clculo de costo con uso de Patrn, y para el clculo sin uso de patrones toma el valor de Nominal (NM=1.00). Esto se explica, porque TOOL es un factor, dentro de la categora de Atributos de Proyecto (ver tabla 5.2), y su ndice indica el grado de utilizacin de la herramienta (en esta caso el lenguaje de programacin).
Utilizamos HIGH porque cuando se hace uso de Patrones se utiliza toda la riqueza y la potencia de la programacin orientada a objetos, herencia, interfaces, y encapsulacin. En cambio cuando no se utiliza patrones no se hace uso de ninguna de estas propiedades de la herramienta, por esta razn se aplica el ndice NM. Tabla 5.8. En sta tabla se define, los parmetros de tiempo, para los clculos respectivos. Obviamente, estos parmetros pueden ser modificados, pero deben ser iguales para ambos escenarios, a fin de establecer resultados coherentes. Semanas / Mes: que est referido a la cantidad real de semanas que hay por un mes. Das / Semana: Indica la cantidad de das laborables por semana Hora / Da: Indica cuantas horas se trabaja por da. Como se puede observar estos, valores pueden ser modificados, pero permanecen idnticos en ambos escenarios (Con y sin Patrn) a fin de comparar los costos en los que se incurren. Tabla 5.9. En la tabla 5.9, se hace el clculo de Esfuerzo ajustado y Productividad, segn indica la ecuacin 5.1. Es necesario, convertir el nmero de lneas de cdigo (LDC) a miles de lneas de cdigo (KLDC). Obsrvese en la tabla 5.9 que el PM Nominal (Personal Nominal Mensual Necesario), es mayor que en el escenario Sin Patrn. Tabla 5.10. y Tabla 5.12. Establece los costos en los que se incurre al desarrollar el sistema Con patrn y Sin Patrn. Observar que se alinea la
83
distribucin de los costos con las fases del RUP, otorgndole un porcentaje a cada fase: Concepcin: 10% Elaboracin: 10% Construccin: 75% Transicin: 5% Estos porcentajes son dados por el Dr. Boehm [BOEHM81], han sido definidos, por ser la fraccin de tiempo utilizado en proyectos de software similares. Tablas 5.11, 5.13. Se indica los plazos de tiempos en los que incurre, en ambos escenarios, al igual que en las tablas 5.10 y 5.12, se distribuye los plazos de acuerdo las fases del RUP. 5.4. INTERPRETACIN
El Costo econmico, que implica la utilizacin de un patrn en la capa de datos y la capa de Business (Patrn Informador), significa un ahorro del 81,53% versus la no-utilizacin de algn patrn. En Plazos de entrega, el uso del patrn, implica una disminucin del 47,37% en trmino de tiempos de entrega.
Tabla Comparativa de Sin Patrn versus Uso de Patrn (Constructive Cost Model) Intranet Industrial UNMSM
Sin Patrn Con Patrn % Plazos (Meses) 4.99 2.63 47,37 Costos (US $) 5947.98 1098.44 81.53
Tabla 5.14.: Tabla Comparativa de Sin Patrn versus Uso de Patrn Fuente: Elaboracin Propia
84
CAPITULO VI: CONCLUSIONES Y RECOMENDACIONES
CONCLUSIONES 1. Los patrones de diseo orientados a objetos, son una alternativa tcnica para el desarrollo de sistemas de software, promoviendo la reutilizacin, y haciendo posible la modularidad de los sistemas de software. 2. El uso sistemtico del Patrn Informador en el desarrollo de la Intranet Industrial, constituye un ahorro econmico aproximado del 80%, y una disminucin de alrededor del 48% en trminos de meses necesarios para concluir el proyecto, segn la aproximacin emprica CoCoMo (Constructive Cost Modeling). 3. El Patrn Informador es una capa abstracta que provee acceso a diferentes bases de datos, el sistema de software realiza operaciones tpicas con la base de datos a travs de esta capa abstracta, estas operaciones pueden ser transaccionales.
85
4. El Patrn Sensor, son interfases de clases abstractas que monitorean continuamente el sistema de software, reportando cualquier error cada del sistema de software. 5. El Patrn de 3 Capas, es una distribucin arquitectnica de los componentes de negocio, capa de datos y presentacin. El uso de ste patrn proporciona flexibilidad y encapsula la complejidad de cada una de las capas en macro mdulos fcilmente administrables. 6. El Patrn Informador, el Patrn Sensor, y el Patrn de 3 capas constituyen macro estructuras lgicas reutilizables en el desarrollo de un sistema de software complejo, independientemente del lenguaje o del sistema de software, estos patrones ofrecen un vocabulario con mayor valor semntico, que permite poder transmitir estructuras lgicas en vez de ideas solamente, proporcionando otro nivel de comunicacin entre los desarrolladores y analistas de software. 7. El Sistema de la Intranet Industrial, es un sistema modular, dbilmente acoplado, provee un completo conjunto de objetos y los patrones para su reutilizacin posterior en el proceso de escalabilidad del sistema. Este sistema es escalable, es decir puede soportar el crecimiento lgico (nuevos mdulos o subsistemas complejos), y el crecimiento fsico (mayor nmero de usuarios, mayor trfico en las transacciones). 8. Los patrones de diseo, son posibles, gracias al uso de lenguajes de programacin orientados a objetos: .NET, J ava, Delphi, entre otros, estos patrones no se pueden implementar con lenguajes que no
86
posean los conceptos fundamentales de objetos, herencia, polimorfismo, y encapsulamiento. RECOMENDACIONES 1. El esquema arquitectnico de la Facultad de Ingeniera Industrial UNMSM, que se propone con la INTRANET INDUSTRIAL, busca la integracin de toda la informacin en la organizacin, y el desarrollo coherente de futuras implementaciones de software, por ejemplo: un mdulo de control de personal, mdulo de economa, entre otros. 2. El Crculo de Investigacin y Desarrollo de Software de la Facultad de Ingeniera Industrial CIDESOFT, actualmente posee la ltima versin en ambiente de desarrollo de la INTRANET INDUSTRIAL, es necesario proveer de mayor equipamiento de cmputo, para que los integrantes continen con el mantenimiento y ampliacin del proyecto de la INTRANET INDUSTRIAL. 3. El sistema de la INTRANET INDUSTRIAL, puede ser acondicionado fcilmente para su uso en otras facultades, organizaciones y empresas, al ser escalable y proveer un conjuntos de patrones, puede satisfacer nuevos requerimientos en menor tiempo. 4. Es necesario que cualquier implementacin de software en la Facultad de Ingeniera industrial, sea acompaada de una detallada documentacin, tcnica. Esto asegura su mantenimiento y ampliacin a largo plazo.
87
BIBLIOGRAFA [ALE77] CHRISTOPHER ALEXANDER (1977) A Pattern Language (Oxford University Press 1977). [ALE77-1] CHRISTOPHER ALEXANDER (1977) EL Modo Intemporal De Construir (Oxford University Press 1985), [ANTIPAT98] The Software Patterns Criteria (Proposed Definitions for Evaluating Software Pattern Quality) Version 10.2 J une 2, 1998 http://www.antipatterns.com/whatisapattern/ [BSTROUSTRUP97] BJ ARNE STROUSTRUP The C++ Programming Language Addison Wesley 3era Edition 1997. [BRAD99] DONALD BRADLEY ROBERTS (1999) Practical Analysis For Refactoring University of Illinois at Urbana-Champaign [BMR96] FRANK BUSCHMANN, REGINE MEUNIER, HANS ROHNERT, PETER SOMMERLAD Y MICHAEL STAL. Pattern-Oriented Software Architecture - A System Of Patterns. J ohn Wiley & Sons, 1996. [BOEHM81] B. W. BOEHM " Software Engineering Economics" Prentice- Hall, 1981. [COPLIEN00] J AMES O. COPLIEN (2000) Software Patterns Lucent Technologies, Bell Labs Innovations [EGXDE02] EVALUATORS GUIDE (2002) Rational XDE Professional v2002 Release 2.1 .NET Edition Rational Software White Paper [FOOT92] BRIAN FOOTE. (1992) A Fractal Model Of The Lifecycles Of Reusable Objects. (Abstract) http://www.laputan.org/frameworks/fractal.html
88
[FOO&YODER95] BRIAN FOOTE AND J OSEPH YODER. (1995) Evolution, Architecture, and Metamorphosis http://www.joeyoder.com/papers/patterns/Evolution/plop95.pdf [GOF95] ERICH GAMMA, RICHARD HELM, RALPH J ONHSON, J HON VLISSIDES (1995) Design Patters Elements of Reusable Object-Oriented Software Addison Wesley [IEEE-1471] RICH HILLIARD IEEE-1471 Recommended Practice for Recommended Practice for Architectural Description of Software- Intensive Systems. www.enterprise- architecture.info/Images/Documents/IEEE%201471-2000.pdf [MPLATT02] MICHAEL PLATT (2002) Microsoft Architecture Overview Executive Summary July 2002 Microsoft Corporation [OPDY95] BRIAN FOOTE AND WILLIAM F. OPDYKE (1994) Lifecycle And Refactoring Patterns That Support Evolution And Reuse. UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN and AT&T Bell Laboratories [RUP03] RATIONAL UNIFIED PROCESS (2003) Documentacin Version 2003.06.00.65 [RXDE03] "Rational XDE Model Structure Guidelines for Microsoft .NETwww.128.ibm.com/developerworks/rational/library/content/03J uly/2500/25 54/2554_net.pdf [SOMMER02] IAN SOMMERVILLE (2002) Ingeniera de Software Addison Wesley