Please use this identifier to cite or link to this item: https://repositorio.utn.edu.ec/handle/123456789/584
Citar este ítem

Full metadata record
DC FieldValueLanguage
dc.contributor.advisorJaramillo Vinueza, Edgar Daniel-
dc.contributor.authorTito Quintana, Carlos Andrés-
dc.date.accessioned2011-06-06T17:46:56Z-
dc.date.available2011-06-06T17:46:56Z-
dc.date.issued2011-06-06T17:46:56Z-
dc.identifier.urihttp://repositorio.utn.edu.ec/handle/123456789/584-
dc.description.abstractLa Metodología de Reingeniería de Software con Orientación a Objetos (MRSOO), nace como una necesidad de controlar y actualizar los procesos manejados por una organización a través de la tecnología informática, con el propósito de crear aplicaciones evolutivas en que las diferentes áreas de la organización se integren al mundo cambiante de los negocios y se obtenga de esta manera una gestión administrativa eficiente, efectiva y económica. Inicia con una descripción de la Situación Actual de la Organización (Capítulo 1), en donde se recopila toda la información de la empresa, esta parte constituye una ayuda para poder familiarizarse con el entorno y manejo de la empresa a la cual se la aplicará la metodología MRSOO. Seguidamente, se determina la Metodología de Reingeniería de Software con Orientación a Objetos (Capítulo 2), basándose en un análisis de metodologías como: la del desarrollo de un proyecto informático y de la reingeniería, se establece cuatro fases: el fijar los principios generales de la reingeniería de procesos del negocio, el modelo de la reingeniería de procesos del negocio, de la reingeniería de software y la ingeniería progresiva, cada una con sus respectivas etapas. Antes de aplicar la metodología orientada a objetos se deben tener claros los Conceptos y Principios Orientados a Objetos (Capítulo 3). Las tecnologías de objetos encierran todos los aspectos de una visión orientada a objetos e incluye el análisis, diseño y métodos de prueba, lenguajes de programación, herramientas, base de datos y las aplicaciones que son creadas usando el enfoque orientado a objetos. La clase contiene un conjunto de atributos que la describen y un conjunto de operaciones que definen su comportamiento. Los objetos modelan casi todo aspecto identificable del dominio del problema: entidades externas, cosas, ocurrencias, roles, unidades organizacionales. Un objeto accede a otro a través del envío de mensajes. Un mensaje consiste en el nombre de la operación y sus argumentos. Tres conceptos importantes diferencian el enfoque Orientado a Objetos del software convencional. El encapsulamiento empaqueta datos (colección de atributos) y operaciones (algoritmos) que manejan estos datos en un objeto. La herencia permite que los atributos y operaciones de una clase sean heredados por todas las subclases y objetos que instancian de ella. El polimorfismo permite que una cantidad de operaciones diferentes posean el mismo nombre, reduciendo la cantidad de líneas de código necesarias para implementar un sistema y facilita los cambios en caso que se produzcan. Un programa en un lenguaje orientado a objetos se construye definiendo nuevas clases y enriqueciendo las existentes. Debido a que el estudio emplea un análisis y diseño orientado a objeto, se establece una Metodología Orientada a Objetos (Capítulo 4). El método de análisis orientado a objetos (AOO) permite modelar un problema a través de la representación de objetos, atributos y operaciones como las componentes primarias del modelado. Una amplia variedad de métodos de análisis orientado a objetos han sido propuestos por diferentes autores, pero todos poseen un conjunto de características comunes como: la representación de clases o jerarquías de clase, creación de modelos de objeto – relación, y la derivación de modelos objeto – comportamiento. El proceso de AOO comienza obteniendo los requisitos del cliente para el sistema orientado a objetos, luego se definen casos de uso o escenarios que describen cómo debe usar el sistema orientado a objetos. Identificar clases, atributos y operaciones para cada objeto del sistema, se aplica entonces la técnica de modelado clase – responsabilidad – colaborador (CRC) a las clases, también aporta una vista inicial de las colaboraciones que ocurren entre los objetos. Las etapas siguientes en el AOO es la clasificación de los objetos y la creación de una jerarquía de clases. El modelo objeto – relación proporciona una indicación acerca de cómo están interconectadas unas clases con otras, y el modelo objeto – comportamiento indica el comportamiento de objetos individuales y global del sistema orientado a objetos. El diseño orientado a objetos (DOO) traduce el modelo de AOO del mundo real en un modelo específico de implementación que puede realizarse en software. El proceso de DOO comienza con la determinación de la arquitectura a emplearse, se diseñan los objetos con sus atributos y operaciones. Se realiza una correspondencia entre un modelo de objetos y una base de datos relacional. Como en el AOO, existen varios métodos diferentes de DOO. Aunque cada uno difiere del otro a partir de sus componentes, todos están de acuerdo con el proceso de diseño a través de dos niveles de abstracción: diseño del sistema y los subsistemas, y del diseño de objetos individuales. El objetivo general de las pruebas orientadas a objetos es encontrar el número de errores máximo con el mínimo de esfuerzo. La atención de las pruebas se aparta de la componente procedimental (el módulo) y se mueve hacia la base. Como los modelos de análisis, diseño y el código fuente resultante, están semánticamente enlazados, las pruebas comienzan durante estas actividades de ingeniería. Por esta razón, la revisión de los modelos CRC, objeto – relación y objeto – comportamiento puede verse como una primera etapa de las pruebas. Una vez que se ha realizado la programación orientada a objeto, la prueba de unidad se aplica a cada clase. Las pruebas de clases usan una variedad de métodos: pruebas basadas en errores, pruebas aleatorias y de partición. Cada uno de estos métodos ejercitan las operaciones encapsuladas por la clase. Se diseñan secuencias de pruebas para asegurar que se ejerciten operaciones relevantes. El estado de una clase, representado por los valores de sus atributos, se examina para determinar si existen errores. Una vez determinada la metodología orientada a objetos se detallan las Fases de la Metodología de Reingeniería de Software con Orientación a Objetos (Capítulo 5), que consta de: el fijar los principios generales de la reingeniería de procesos del negocio, el modelo de la reingeniería de procesos del negocio inicia con la definición de los objetivos del negocio, identificación y evaluación de los procesos del negocio, se concluye con la especificación, diseño y refinamiento de los nuevos procesos del negocio. El modelo de procesos de reingeniería de software consta de las siguientes etapas: el análisis de inventario de software, análisis costo – beneficio de la reingeniería de software, la reingeniería inversa y la reestructuración de datos. La ingeniería progresiva permite integrar las nuevas tecnologías en el desarrollo de aplicaciones. A continuación se desarrollan cada una de las Fases y Etapas de la Metodología de Reingeniería de Software con Orientación a Objetos (Capítulo 6). Una vez que se tienen las herramientas para el empleo de la MRSOO, se procede a su aplicación en el sistema administrativo financiero de la empresa EQUINORTE Talleres. Para terminar, se evalúa a la metodología MRSOO (Capítulo 7) dentro del contexto de calidad y del aporte a la gestión empresarial. Finalmente, la realización de la presente tesis proporcionará una base sólida para el desarrollo de aplicaciones de calidad comercial, de acuerdo a las exigencias de los negocios y le preparará para sacar partido a las técnicas orientadas a objetos.es_ES
dc.language.isospaes_ES
dc.rightsopenAccesses_ES
dc.subjectSOFTWARE CON ORIENTACIÒN A OBJETOSes_ES
dc.titleMETODOLOGÌA DE REINGENIERÌA DE SOFTWARE CON ORIENTACIÒN A OBJETOSes_ES
dc.typebachelorThesises_ES
Appears in Collections:Ing. en Sistemas Computacionales

Files in This Item:
File Description SizeFormat 
CapI.docCAPITULO I226 kBMicrosoft WordView/Open
CapII.docCAPITULO II130.5 kBMicrosoft WordView/Open
CapIII.docCAPITULO III479 kBMicrosoft WordView/Open
CapIV.docCAPITULO IV465.5 kBMicrosoft WordView/Open
CapV.docCAPITULO V141 kBMicrosoft WordView/Open
CapVI.docCAPITULO VI406 kBMicrosoft WordView/Open
CapVII.docCAPITULO VII145.5 kBMicrosoft WordView/Open


This item is protected by original copyright



Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.