esta es una prueba
Estoy enviando datos directamente a publicarlos desde mi correo al blog
Windows Live y Samsung equipan tu casa. Participa y gana!
Windows Live y Samsung equipan tu casa. Participa y gana!
UNIDAD II.- Programación Orientada a Objetos, conceptos y características.
La Programación Orientada a Objetos (OOP por sus siglas en inglés de Object Oriented Programming) como paradigma, "es una forma de pensar, una filosofía, de la cual surge una cultura nueva que incorpora técnicas y metodologías diferentes. Pero estas técnicas y metodologías, y la cultura misma, provienen del paradigma, no lo hacen. La OOP como paradigma es una postura ontológica: el universo computacional está poblado por objetos, cada uno responsabilizándose por sí mismo, y comunicándose con los demás por medio de mensajes" [Greiff 1994].
Se debe distinguir que la OOP como paradigma (enfoque o manera de visualizar la realidad) y como metodología (colección de características para la ingeniería de software) no son la misma cosa. Sin embargo, la publicidad nos confunde asociando la OOP más a una metodología, que al paradigma. De aquí que "el interés en la OOP radica más en los mecanismos que aporta para la construcción de programas que en aprovechar un esquema alterno para el modelado de procesos computacionales" [Greiff 1994].
La Programación Orientada a Objetos desde el punto de vista computacional "es un método de implementación en el cuál los programas son organizados como grupos cooperativos de objetos, cada uno de los cuales representa una instancia de alguna clase, y estas clases, todas son miembros de una jerarquía de clases unidas vía relaciones de herencia" [Greiff 1994].
Fundamentos de lo Orientado a Objetos
El paradigma OO se basa en el concepto de objeto. Un objeto es aquello que tiene estado (propiedades más valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los demás objetos). La estructura y comportamiento de objetos similares están definidos en su clase común; los términos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento común.
La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstracción, la "esencia" de un objeto, tal como son. De aquí que un objeto no es una clase, sin embargo, una clase puede ser un objeto.
En el enfoque OO las propiedades del objeto son claves. Los principios del modelo OO son: abstracción, encapsulación, modularidad y jerarquía, fundamentalmente, y en menor grado tipificación (typing), concurrencia, persistencia. [Booch 1986] dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO.
Abstracción. Es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros.
Encapsulación. En el proceso de ocultar todos los detalles de un objetoque no contribuyen a sus características esenciales.
Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes.
Jerarquía o herencia. Es el orden de las abstracciones organizado por niveles.
Tipificación. Es la definición precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida.
Concurrencia . Es la propiedad que distingue un objeto que está activo de uno que no lo está.
Persistencia. Es la propiedad de un objeto a través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado).
Según [Booch 1986], los beneficios del enfoque OO son:
Primero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos los lenguajes de programación basados en objetos y los orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada, [ y recientemente Java] .
Segundo, el uso del modelo OO alienta el reuso no solo del software, sino de diseños completos.
Tercero, produce sistemas que están construidos en formas intermedias estables y por ello son más resistentes al cambio en especificaciones y tecnología.
El mismo autor considera que el principal beneficio del OOD es que da un mecanismo para formalizar el modelo de la realidad.
Las relaciones entre objetos definen el comportamiento del sistema. Se dice que un objeto es un actor, si su única función es operar sobre otros objetos. El objeto es un servidor si solo es manejado por otros objetos y es un agente si tiene ambas propiedades. Se dice que los objetos actúan entre sí mediante mensajes, es decir, acciones que pide el objeto transmisor que ejecute el objeto receptor. Dependiendo del comportamiento definido para un objeto, éste tomará las acciones para ejecutar o no el mensaje, de manera apropiada.
[Greiff 1994] comenta que el Análisis Orientado a Objetos (OOA por sus siglas en inglés de Object Oriented Analysis) "es un método de análisis que examina los requerimientos desde la perspectiva de las clases y objetos encontrados en el vocabulario de del dominio del problema".
Según [Booch 1986], el Diseño Orientado a Objetos "es un método de diseño abarcando el proceso de descomposición orientado a objetos y una notación para representar ambos modelos lógico y físico tal como los modelos estáticos y dinámicos del sistema bajo diseño".
En cuanto a las metodologías OO, diremos que hay un gran número de métodos orientado a objetos actualmente. Muchos de los métodos pueden ser clasificados como orientados a objetos porque soportan de manera central los conceptos de la orientación a objetos. Algunos de las metodología más conocidas y estudiadas hasta antes del UML según [Jacobson 1992] son:
Object-Oriented Design (OOD), Booch.
Object Modeling Technique (OMT), Rumbaugh.
Object Oriented Analysis (OOA), Coad/Yourdon.
Hierarchical Object Oriented Design (HOOD), ESA.
Object Oriented Structured Design (OOSD), Wasserman.
Object Oriented Systems Analysis (OOSA), Shaler y Mellor.
Responsibility Driven Design (RDD), Wirfs-Brock, entre otros.
Actualmente las metodologías más importantes de análisis y diseño de sistemas han confluido en lo que se es el UML, bajo el respaldo del Object Management Group
http://galeon.com/gpw/aficiones75346.html
Los sistemas de información, sistemas informáticos y las organizaciones son elementos cuyo desarrollo o desempeño están notablemente ligados, de allí que su éxito esté estrechamente vinculado, de tal forma que el éxito de uno incide notablemente en el éxito del otro. Según Jonas Montilva en su libro titulado "Desarrollo de sistemas de información", un sistema "es un conjunto de partes, elementos o cosas interdependientes e interrelacionadas para la consecución de un fin". Para James Senn en su libro titulado "Análisis y diseño de sistemas de información" un sistema: "es considerar como un todo unitario y organizado de procesos, procedimientos, tareas, métodos y recursos materiales, tecnológicos y humanos interdependientes, de que se vale una organización para alcanzar un objetivo, y es fácilmente identificable por los límites de su medio ambiente".
De manera tal se puede decir que las organizaciones son sistemas abiertos, cada uno a su vez constituido por subsistemas de mayor o menor tamaño o complejidad, cada uno con límites claramente definidos, y todos con funciones y objetivos particulares, que unidos forman las funciones y objetivos de la empresa u organización; de igual manera están conformados o estructurados los sistemas informáticos, también sujetos al correcto desempeño de las funciones de cada subsistema, para lograr así el buen funcionamiento del sistema y la consecución de todas sus metas. Los sistemas de información según James Senn en su libro titulado "Análisis y Diseño de Sistemas de Información" "es definido como un medio organizado de proporcionar información pasada, presente y hasta futura (proyecciones) relacionada con las operaciones internas y el conocimiento externo de la organización". Esto quiere decir que un sistema de información es un ente que sigue una estructura bien organizada y claramente planteada con el fin de emitir y generar información histórica, actual y proyecciones futuras inclusive, todo esto con la espina vertebral de las operaciones llevadas a cabo por la organización. Tanto los sistemas informáticos como los sistemas de información están visiblemente signados por la complejidad, en tal sentido se cita a continuación una historia popular que trata acerca de la complejidad inherente a la informática, un médico , un ingeniero civil y un informático estaban discutiendo acerca de cual era la profesión más antigua del mundo.
El médico señaló: "Bueno, en la Biblia dice que Dios creó a Eva de una costilla que le quitó a Adán. Evidentemente, esto requirió cirugía, es por eso que bien puedo asegurar que la mía es la profesión más antigua del mundo". El ingeniero interrumpió y dijo: "Pero incluso antes, en el Génesis, se dice que Dios creó el orden de los cielos y la tierra a partir del caos. Está fue la primera y desde luego la más espectacular aplicación de la ingeniería civil. Por tanto, querido doctor, está usted equivocado: la mía es la profesión más antigua del mundo". El Informático se reclinó en su silla, sonrió, y dijo tranquilamente: "Pero bueno, ¿Quién piensan ustedes que creó el caos?". Esto nos da una idea de que toda organización es compleja por naturaleza, todo sistema informático es complejo mas por esencia que por accidente, de tal manera que el desarrollo de cualquiera, y posteriormente su supervisión constante, es una tarea compleja que debe, en todos los casos, tener apariencia de simplicidad, es decir, que deben ofrecer ilusión de simplicidad aún cuando no lo sean. Existen diversas metodologías para la creación de sistemas informáticos, estos enfocan diversas formas o teorías que permiten tratar de manera exitosa la complejidad inherente al desarrollo de software; los métodos de diseño estructurado surgieron para guiar a los desarrolladores que intentaban construir sistemas complejos utilizando algoritmos como bloques fundamentales para la construcción de estos sistemas. El sistema expuesto en la presente investigación ha sido basado en el Análisis, Diseño y Programación Orientado a Objetos (AOO Análisis Orientado a Objetos, DOO Diseño Orientado a Objetos y POO Programación Orientado a Objetos) diseñado por Grady Booch en su libro de nombre "Análisis y Diseño Orientado a Objetos". Los métodos de diseño orientado a objetos han surgido para ayudar a los desarrolladores a explotar la potencia expresiva de los lenguajes de programación basados en objetos y orientados a objetos, utilizando las clases y los objetos como bloques básicos de construcción, la metodología orientado a objetos es un principio de desarrollo evolutivo, no revolucionario, es decir, que mas que revolucionario es evolucionario debido a que tal metodología no rompe con los avances del pasado, sino que los reestructura y los afianza de una forma que el desarrollo de aplicaciones o sistemas es mucho mas sencillo y su proceso de desarrollo mucho más dinámico que con otras metodologías estructuradas. Booch define al Análisis Orientado a Objetos (AOO) como "un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema", de los objetos Booch dice "son entidades tangibles que muestran un comportamiento bien definido". Todo esto quiere decir que el análisis orientado a objetos parte de entidades tangibles halladas en el problema, tales entidades varían dependiendo de los diversos casos prácticos, pero en todos los casos son elementos reales que toman parte del problema de forma directa. Para Booch el Diseño Orientado a Objetos (DOO) "es el método que lleva a una descomposición Orientado a Objetos. Aplicando DOO, se crea software resistente al cambio y escrito con economía de expresión. Se logra un mayor nivel de confianza en la corrección del software a través de la división inteligente de su espacio de estados. En última instancia, se reducen los riesgos inherentes al desarrollo de sistemas". Los modelos del diseño orientado a objetos reflejan la importancia de plasmar explícitamente las jerarquías de clases y objetos del sistema que se diseña. Estos modelos cubren también el espectro de las decisiones de diseño relevantes que hay que considerar en el desarrollo de un sistema complejo, y así animan a construir implantaciones que posean los atributos de los sistemas complejos bien formados. También se dice del DOO que es un método que abarca el proceso de descomposición orientada a objetos y una notación para describir los modelos lógico y físico, así como los modelos estático y dinámico, tal como aparecen en el anexo 1, del sistema que se diseña; el soporte para la descomposición orientada a objetos es lo que hace al diseño orientada a objetos diferente del diseño estructurado, el primero, utiliza abstracciones de clases y objetos para estructurar lógicamente los sistemas, y el segundo, utiliza abstracciones algorítmicas.
La programación orientada a objetos (POO) es, para Booch, "un método de implementación en el que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de alguna clase, y cuyas clases son, todas ellas, miembros de una jerarquía de clases unidas mediante relaciones de herencia".
Básicamente, los resultados obtenidos durante el análisis orientado a objetos sirven como modelo o punto de partida para realizar el diseño orientado a objetos del sistema, luego de ello se procede en base al modelo realizado en el DOO a desarrollar el sistema computacional utilizando para tal fin la metodología de programación orientado a objetos suministrada por determinado lenguaje de programación orientado a objetos. Entonces se puede concluir que se ha decidido trabajar mediante la metodología orientada a objetos según Grady Booch en "Análisis y Diseño Orientado a Objetos" debido no solo a la modernidad del enfoque de Booch, sino también a la practicidad del mismo, análisis, diseño y programación orientada a objetos (AOO, DOO y POO respectivamente) son métodos eficaces y actuales, fácilmente adaptables a los cambios surgidos durante el desarrollo de cualquiera de ellos.
Finalmente se expondrá el modelo orientado a objetos con la finalidad de aclarar y esquematizar de forma completa la metodología orientada a objetos diseñada por Grady Booch, y que sirvió de base para desarrollar la presente investigación; el modelo de desarrollo orientado a objetos, tal como se puede observar en el anexo 1, está formado por los modelos lógico y físico, así como estos a su vez por los modelos estático y dinámico. Tal como lo explica Booch el "modelo lógico sirve para describir la existencia y significado de las abstracciones principales y los mecanismos que forman el espacio del problema, o para definir la arquitectura del sistema". El modelo lógico detalla las características primordiales de las entidades principales (clases y objetos), así como la forma de trabajo de estos, estructurando de esta manera lo límites pros y contras del problema planteado para, de esta forma, definir o identificar la arquitectura del sistema. Para representar gráficamente al modelo lógico, existen dos diagramas, a saber: * Diagrama de Clases: Se utiliza para mostrar la existencia de clases y sus relaciones en la visión lógica de un sistema. Durante el análisis, se utiliza para indicar las misiones y responsabilidades comunes de las entidades que caracterizan el comportamiento de un sistema. Durante el diseño, se utilizan para plasmar la estructura de las clases que forman la arquitectura del sistema. * Diagrama de Objetos: Se utilizan para mostrar la existencia de objetos y sus relaciones en el diseño lógico de un sistema, es decir, representa las interacciones o relaciones estructurales que pueden darse entre un conjunto de instancias (objetos) de clases. Un diagrama de objetos representa una vista estructurada de objetos de un sistema. Durante el análisis, se usa para indicar la semántica de escenarios primarios y secundarios que proporcionan una traza del comportamiento del sistema. Durante el diseño, se usan para ilustrar la semántica de los mecanismos en el diseño lógico de un sistema. Del modelo físico por su parte, Booch explica que "describe la composición concreta en cuanto a hardware y software del contexto o implantación del sistema". Esto no es mas que la descripción de la estructura física, o sea el hardware (procesos) y lógica o software (módulos) que componen al sistema. Para representar gráficamente al modelo físico, existen dos diagramas, a saber: * Diagrama de Procesos: Se usan para mostrar la asignación de procesos a procesadores, valga la redundancia, y dispositivos en el diseño físico de un sistema. El diagrama de procesos representa una vista de la estructura de procesos de un sistema. Durante el desarrollo, se usan para indicar la colección física de procesadores y dispositivos que sirven como plataforma de ejecución del sistema. * Diagrama de Módulos: Se utiliza para mostrar la asignación de clases y objetos a módulos en el diseño físico de un sistema.
Un diagrama de módulos representa una vista de la estructura física de módulos que componen un sistema. Durante el desarrollo, se usan para indicar la disposición en capas y la participación física de la arquitectura. Ahora bien, es relevante destacar que el diseño lógico se lleva a cabo, básicamente, durante las fases de análisis y diseño del sistema, mientras que el modelo físico, se desarrolla, mas bien durante la fase de programación. Tal como se mencionó anteriormente el modelo de desarrollo orientado a objetos está conformado por los modelos lógico y físico, así como también por los modelos estático y dinámico, estos modelos explican que, algunos diagramas son estáticos mientras que otros son de carácter dinámico.
Por ejemplo, los diagramas implementados en el modelo físico son fuertemente estáticos, es decir, que no representan o simbolizan ningún tipo de relaciones que involucren el movimiento o flujo de acciones que disparen eventos, lo que genera una visión sumamente estática del sistema, mientras que los diagramas del modelo lógico amplían la visión del modelo físico, generando de esta forma una visión sumamente amplia de cómo acciona el sistema, es decir, que genera una visión dinámica del mismo, y esto, muy a pesar de que tal visión esté representada en papel, en un diagrama, que en todos los casos, será estático, por lo que se asume o se toma, las acciones que representa un diagrama, la visión del sistema que este genere o exprese.
Se debe distinguir que la OOP como paradigma (enfoque o manera de visualizar la realidad) y como metodología (colección de características para la ingeniería de software) no son la misma cosa. Sin embargo, la publicidad nos confunde asociando la OOP más a una metodología, que al paradigma. De aquí que "el interés en la OOP radica más en los mecanismos que aporta para la construcción de programas que en aprovechar un esquema alterno para el modelado de procesos computacionales" [Greiff 1994].
La Programación Orientada a Objetos desde el punto de vista computacional "es un método de implementación en el cuál los programas son organizados como grupos cooperativos de objetos, cada uno de los cuales representa una instancia de alguna clase, y estas clases, todas son miembros de una jerarquía de clases unidas vía relaciones de herencia" [Greiff 1994].
Fundamentos de lo Orientado a Objetos
El paradigma OO se basa en el concepto de objeto. Un objeto es aquello que tiene estado (propiedades más valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los demás objetos). La estructura y comportamiento de objetos similares están definidos en su clase común; los términos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento común.
La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstracción, la "esencia" de un objeto, tal como son. De aquí que un objeto no es una clase, sin embargo, una clase puede ser un objeto.
En el enfoque OO las propiedades del objeto son claves. Los principios del modelo OO son: abstracción, encapsulación, modularidad y jerarquía, fundamentalmente, y en menor grado tipificación (typing), concurrencia, persistencia. [Booch 1986] dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO.
Abstracción. Es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros.
Encapsulación. En el proceso de ocultar todos los detalles de un objetoque no contribuyen a sus características esenciales.
Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes.
Jerarquía o herencia. Es el orden de las abstracciones organizado por niveles.
Tipificación. Es la definición precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida.
Concurrencia . Es la propiedad que distingue un objeto que está activo de uno que no lo está.
Persistencia. Es la propiedad de un objeto a través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado).
Según [Booch 1986], los beneficios del enfoque OO son:
Primero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos los lenguajes de programación basados en objetos y los orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada, [ y recientemente Java] .
Segundo, el uso del modelo OO alienta el reuso no solo del software, sino de diseños completos.
Tercero, produce sistemas que están construidos en formas intermedias estables y por ello son más resistentes al cambio en especificaciones y tecnología.
El mismo autor considera que el principal beneficio del OOD es que da un mecanismo para formalizar el modelo de la realidad.
Las relaciones entre objetos definen el comportamiento del sistema. Se dice que un objeto es un actor, si su única función es operar sobre otros objetos. El objeto es un servidor si solo es manejado por otros objetos y es un agente si tiene ambas propiedades. Se dice que los objetos actúan entre sí mediante mensajes, es decir, acciones que pide el objeto transmisor que ejecute el objeto receptor. Dependiendo del comportamiento definido para un objeto, éste tomará las acciones para ejecutar o no el mensaje, de manera apropiada.
[Greiff 1994] comenta que el Análisis Orientado a Objetos (OOA por sus siglas en inglés de Object Oriented Analysis) "es un método de análisis que examina los requerimientos desde la perspectiva de las clases y objetos encontrados en el vocabulario de del dominio del problema".
Según [Booch 1986], el Diseño Orientado a Objetos "es un método de diseño abarcando el proceso de descomposición orientado a objetos y una notación para representar ambos modelos lógico y físico tal como los modelos estáticos y dinámicos del sistema bajo diseño".
En cuanto a las metodologías OO, diremos que hay un gran número de métodos orientado a objetos actualmente. Muchos de los métodos pueden ser clasificados como orientados a objetos porque soportan de manera central los conceptos de la orientación a objetos. Algunos de las metodología más conocidas y estudiadas hasta antes del UML según [Jacobson 1992] son:
Object-Oriented Design (OOD), Booch.
Object Modeling Technique (OMT), Rumbaugh.
Object Oriented Analysis (OOA), Coad/Yourdon.
Hierarchical Object Oriented Design (HOOD), ESA.
Object Oriented Structured Design (OOSD), Wasserman.
Object Oriented Systems Analysis (OOSA), Shaler y Mellor.
Responsibility Driven Design (RDD), Wirfs-Brock, entre otros.
Actualmente las metodologías más importantes de análisis y diseño de sistemas han confluido en lo que se es el UML, bajo el respaldo del Object Management Group
http://galeon.com/gpw/aficiones75346.html
Los sistemas de información, sistemas informáticos y las organizaciones son elementos cuyo desarrollo o desempeño están notablemente ligados, de allí que su éxito esté estrechamente vinculado, de tal forma que el éxito de uno incide notablemente en el éxito del otro. Según Jonas Montilva en su libro titulado "Desarrollo de sistemas de información", un sistema "es un conjunto de partes, elementos o cosas interdependientes e interrelacionadas para la consecución de un fin". Para James Senn en su libro titulado "Análisis y diseño de sistemas de información" un sistema: "es considerar como un todo unitario y organizado de procesos, procedimientos, tareas, métodos y recursos materiales, tecnológicos y humanos interdependientes, de que se vale una organización para alcanzar un objetivo, y es fácilmente identificable por los límites de su medio ambiente".
De manera tal se puede decir que las organizaciones son sistemas abiertos, cada uno a su vez constituido por subsistemas de mayor o menor tamaño o complejidad, cada uno con límites claramente definidos, y todos con funciones y objetivos particulares, que unidos forman las funciones y objetivos de la empresa u organización; de igual manera están conformados o estructurados los sistemas informáticos, también sujetos al correcto desempeño de las funciones de cada subsistema, para lograr así el buen funcionamiento del sistema y la consecución de todas sus metas. Los sistemas de información según James Senn en su libro titulado "Análisis y Diseño de Sistemas de Información" "es definido como un medio organizado de proporcionar información pasada, presente y hasta futura (proyecciones) relacionada con las operaciones internas y el conocimiento externo de la organización". Esto quiere decir que un sistema de información es un ente que sigue una estructura bien organizada y claramente planteada con el fin de emitir y generar información histórica, actual y proyecciones futuras inclusive, todo esto con la espina vertebral de las operaciones llevadas a cabo por la organización. Tanto los sistemas informáticos como los sistemas de información están visiblemente signados por la complejidad, en tal sentido se cita a continuación una historia popular que trata acerca de la complejidad inherente a la informática, un médico , un ingeniero civil y un informático estaban discutiendo acerca de cual era la profesión más antigua del mundo.
El médico señaló: "Bueno, en la Biblia dice que Dios creó a Eva de una costilla que le quitó a Adán. Evidentemente, esto requirió cirugía, es por eso que bien puedo asegurar que la mía es la profesión más antigua del mundo". El ingeniero interrumpió y dijo: "Pero incluso antes, en el Génesis, se dice que Dios creó el orden de los cielos y la tierra a partir del caos. Está fue la primera y desde luego la más espectacular aplicación de la ingeniería civil. Por tanto, querido doctor, está usted equivocado: la mía es la profesión más antigua del mundo". El Informático se reclinó en su silla, sonrió, y dijo tranquilamente: "Pero bueno, ¿Quién piensan ustedes que creó el caos?". Esto nos da una idea de que toda organización es compleja por naturaleza, todo sistema informático es complejo mas por esencia que por accidente, de tal manera que el desarrollo de cualquiera, y posteriormente su supervisión constante, es una tarea compleja que debe, en todos los casos, tener apariencia de simplicidad, es decir, que deben ofrecer ilusión de simplicidad aún cuando no lo sean. Existen diversas metodologías para la creación de sistemas informáticos, estos enfocan diversas formas o teorías que permiten tratar de manera exitosa la complejidad inherente al desarrollo de software; los métodos de diseño estructurado surgieron para guiar a los desarrolladores que intentaban construir sistemas complejos utilizando algoritmos como bloques fundamentales para la construcción de estos sistemas. El sistema expuesto en la presente investigación ha sido basado en el Análisis, Diseño y Programación Orientado a Objetos (AOO Análisis Orientado a Objetos, DOO Diseño Orientado a Objetos y POO Programación Orientado a Objetos) diseñado por Grady Booch en su libro de nombre "Análisis y Diseño Orientado a Objetos". Los métodos de diseño orientado a objetos han surgido para ayudar a los desarrolladores a explotar la potencia expresiva de los lenguajes de programación basados en objetos y orientados a objetos, utilizando las clases y los objetos como bloques básicos de construcción, la metodología orientado a objetos es un principio de desarrollo evolutivo, no revolucionario, es decir, que mas que revolucionario es evolucionario debido a que tal metodología no rompe con los avances del pasado, sino que los reestructura y los afianza de una forma que el desarrollo de aplicaciones o sistemas es mucho mas sencillo y su proceso de desarrollo mucho más dinámico que con otras metodologías estructuradas. Booch define al Análisis Orientado a Objetos (AOO) como "un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema", de los objetos Booch dice "son entidades tangibles que muestran un comportamiento bien definido". Todo esto quiere decir que el análisis orientado a objetos parte de entidades tangibles halladas en el problema, tales entidades varían dependiendo de los diversos casos prácticos, pero en todos los casos son elementos reales que toman parte del problema de forma directa. Para Booch el Diseño Orientado a Objetos (DOO) "es el método que lleva a una descomposición Orientado a Objetos. Aplicando DOO, se crea software resistente al cambio y escrito con economía de expresión. Se logra un mayor nivel de confianza en la corrección del software a través de la división inteligente de su espacio de estados. En última instancia, se reducen los riesgos inherentes al desarrollo de sistemas". Los modelos del diseño orientado a objetos reflejan la importancia de plasmar explícitamente las jerarquías de clases y objetos del sistema que se diseña. Estos modelos cubren también el espectro de las decisiones de diseño relevantes que hay que considerar en el desarrollo de un sistema complejo, y así animan a construir implantaciones que posean los atributos de los sistemas complejos bien formados. También se dice del DOO que es un método que abarca el proceso de descomposición orientada a objetos y una notación para describir los modelos lógico y físico, así como los modelos estático y dinámico, tal como aparecen en el anexo 1, del sistema que se diseña; el soporte para la descomposición orientada a objetos es lo que hace al diseño orientada a objetos diferente del diseño estructurado, el primero, utiliza abstracciones de clases y objetos para estructurar lógicamente los sistemas, y el segundo, utiliza abstracciones algorítmicas.
La programación orientada a objetos (POO) es, para Booch, "un método de implementación en el que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de alguna clase, y cuyas clases son, todas ellas, miembros de una jerarquía de clases unidas mediante relaciones de herencia".
Básicamente, los resultados obtenidos durante el análisis orientado a objetos sirven como modelo o punto de partida para realizar el diseño orientado a objetos del sistema, luego de ello se procede en base al modelo realizado en el DOO a desarrollar el sistema computacional utilizando para tal fin la metodología de programación orientado a objetos suministrada por determinado lenguaje de programación orientado a objetos. Entonces se puede concluir que se ha decidido trabajar mediante la metodología orientada a objetos según Grady Booch en "Análisis y Diseño Orientado a Objetos" debido no solo a la modernidad del enfoque de Booch, sino también a la practicidad del mismo, análisis, diseño y programación orientada a objetos (AOO, DOO y POO respectivamente) son métodos eficaces y actuales, fácilmente adaptables a los cambios surgidos durante el desarrollo de cualquiera de ellos.
Finalmente se expondrá el modelo orientado a objetos con la finalidad de aclarar y esquematizar de forma completa la metodología orientada a objetos diseñada por Grady Booch, y que sirvió de base para desarrollar la presente investigación; el modelo de desarrollo orientado a objetos, tal como se puede observar en el anexo 1, está formado por los modelos lógico y físico, así como estos a su vez por los modelos estático y dinámico. Tal como lo explica Booch el "modelo lógico sirve para describir la existencia y significado de las abstracciones principales y los mecanismos que forman el espacio del problema, o para definir la arquitectura del sistema". El modelo lógico detalla las características primordiales de las entidades principales (clases y objetos), así como la forma de trabajo de estos, estructurando de esta manera lo límites pros y contras del problema planteado para, de esta forma, definir o identificar la arquitectura del sistema. Para representar gráficamente al modelo lógico, existen dos diagramas, a saber: * Diagrama de Clases: Se utiliza para mostrar la existencia de clases y sus relaciones en la visión lógica de un sistema. Durante el análisis, se utiliza para indicar las misiones y responsabilidades comunes de las entidades que caracterizan el comportamiento de un sistema. Durante el diseño, se utilizan para plasmar la estructura de las clases que forman la arquitectura del sistema. * Diagrama de Objetos: Se utilizan para mostrar la existencia de objetos y sus relaciones en el diseño lógico de un sistema, es decir, representa las interacciones o relaciones estructurales que pueden darse entre un conjunto de instancias (objetos) de clases. Un diagrama de objetos representa una vista estructurada de objetos de un sistema. Durante el análisis, se usa para indicar la semántica de escenarios primarios y secundarios que proporcionan una traza del comportamiento del sistema. Durante el diseño, se usan para ilustrar la semántica de los mecanismos en el diseño lógico de un sistema. Del modelo físico por su parte, Booch explica que "describe la composición concreta en cuanto a hardware y software del contexto o implantación del sistema". Esto no es mas que la descripción de la estructura física, o sea el hardware (procesos) y lógica o software (módulos) que componen al sistema. Para representar gráficamente al modelo físico, existen dos diagramas, a saber: * Diagrama de Procesos: Se usan para mostrar la asignación de procesos a procesadores, valga la redundancia, y dispositivos en el diseño físico de un sistema. El diagrama de procesos representa una vista de la estructura de procesos de un sistema. Durante el desarrollo, se usan para indicar la colección física de procesadores y dispositivos que sirven como plataforma de ejecución del sistema. * Diagrama de Módulos: Se utiliza para mostrar la asignación de clases y objetos a módulos en el diseño físico de un sistema.
Un diagrama de módulos representa una vista de la estructura física de módulos que componen un sistema. Durante el desarrollo, se usan para indicar la disposición en capas y la participación física de la arquitectura. Ahora bien, es relevante destacar que el diseño lógico se lleva a cabo, básicamente, durante las fases de análisis y diseño del sistema, mientras que el modelo físico, se desarrolla, mas bien durante la fase de programación. Tal como se mencionó anteriormente el modelo de desarrollo orientado a objetos está conformado por los modelos lógico y físico, así como también por los modelos estático y dinámico, estos modelos explican que, algunos diagramas son estáticos mientras que otros son de carácter dinámico.
Por ejemplo, los diagramas implementados en el modelo físico son fuertemente estáticos, es decir, que no representan o simbolizan ningún tipo de relaciones que involucren el movimiento o flujo de acciones que disparen eventos, lo que genera una visión sumamente estática del sistema, mientras que los diagramas del modelo lógico amplían la visión del modelo físico, generando de esta forma una visión sumamente amplia de cómo acciona el sistema, es decir, que genera una visión dinámica del mismo, y esto, muy a pesar de que tal visión esté representada en papel, en un diagrama, que en todos los casos, será estático, por lo que se asume o se toma, las acciones que representa un diagrama, la visión del sistema que este genere o exprese.
UNIDAD I Conceptos Generales
La arquitectura software trata el diseño e implementación de la estructura de alto nivel del software. Es el resultado de ensamblar un cierto número de elementos arquitectónicos para satisfacer la funcionalidad y ejecución de los requisitos del sistema; así como los requisitos no funcionales del mismo: fiabilidad, escalabilidad, portabilidad, disponibilidad, etc. Perry y Wolf (1992) describen una arquitectura software como:
Arquitectura Software = {Elementos, Formas, Fundamento/Restricciones}
Es muy complejo capturar la arquitectura software en un sólo modelo (o diagrama). Para manejar esta complejidad se representan diferentes aspectos y características de la arquitectura en múltiples vistas. Una vista es “una presentación de un modelo, la cual es una descripción completa de un sistema desde una particular perspectiva” (Kruchten, 1995). El modelo más aceptado a la hora de establecer las vistas necesarias para describir una arquitectura software es el modelo 4+1 (Kruchten, 1995).
Este modelo define 4 vistas principlaes:
* Vista Lógica (Logical View), modelo de objetos, clases, entidad – relación, etc.
Vista de Proceso (Process View), modelo de concurrencia y sincronización.
-Vista de Desarrollo (Development View), organización estática del software en su entorno de desarrollo (librerías, componentes, .ear, .jar, etc.).
-Vista Física (Physical View), modelo de correspondencia software - hardware (aspectos de distribución en máquinas, por ejemplo)
Suscribirse a:
Entradas (Atom)
