METODOLOGÍA ORIENTADA A OBJETOS

 METODOLOGÍA ORIENTADA A OBJETOS

La metodología orientada a objetos ha derivado de las metodologías anteriores a éste. Así como los métodos de diseño estructurado realizados guían a los desarrolladores que tratan de construir sistemas complejos utilizando algoritmos como sus bloques fundamentales de construcción, similarmente los métodos de diseño orientado a objetos han evolucionado para ayudar a los desarrolladores a explotar el poder de los lenguajes de programación basados en objetos y orientados a objetos, utilizando las clases y objetos como bloques de construcción básicos.

Actualmente el modelo de objetos ha sido influenciado por un número de factores no sólo de la Programación Orientada a Objetos, POO (Object Oriented Programming, OOP por sus siglas en inglés). Además, el modelo de objetos ha probado ser un concepto uniforme en las ciencias de la computación, aplicable no sólo a los lenguajes de programación sino también al diseño de interfaces de usuario, bases de datos y arquitectura de computadoras por completo. La razón de ello es, simplemente, que una orientación a objetos nos ayuda a hacer frente a la inherente complejidad de muchos tipos de sistemas.

Se define a un objeto como "una entidad tangible que muestra alguna conducta bien definida". Un objeto "es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los métodos que controlan dichos datos".

Los objetos tienen una cierta "integridad" la cual no deberá ser violada. En particular, un objeto puede solamente cambiar estado, conducta, ser manipulado o estar en relación con otros objetos de manera apropiada a este objeto.

Actualmente, el Análisis Orientado a Objetos (AOO) va progresando como método de análisis de requisitos por derecho propio y como complemento de otros métodos de análisis. En lugar de examinar un problema mediante el modelo clásico de entrada-proceso-salida (flujo de información) o mediante un modelo derivado exclusivamente de estructuras jerárquicas de información, el AOO introduce varios conceptos nuevos. Estos conceptos nuevos le parecen inusuales a mucha gente, pero son bastante naturales.

Ventajas de la metodología orientada a objetos

En síntesis, algunas ventajas que presenta son:

• Reutilización. Las clases están diseñadas para que se reutilicen en muchos sistemas. Para maximizar la reutilización, las clases se construyen de manera que se puedan adaptar a los otros sistemas. Un objetivo fundamental de las técnicas orientadas a objetos es lograr la reutilización masiva al construir el software.

• Estabilidad. Las clases diseñadas para una reutilización repetida se vuelven estables, de la misma manera que los microprocesadores y otros chips se hacen estables.

• El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo nivel. El encapsulamiento oculta los detalles y hace que las clases complejas sean fáciles de utilizar.

• Se construyen clases cada vez más complejas. Se construyen clases a partir de otras clases, las cuales a su vez se integran mediante clases. Esto permite construir componentes de software complejos, que a su vez se convierten en bloques de construcción de software más complejo.
• 

METODOLOGIAS ESTRUCTURADAS

METODOLOGIAS ESTRUCTURADAS

En definitiva la metodología de desarrollo lo que pretende es resolver un problema o necesidad, y para

ello parte de la petición del cliente y con sucesivas fases obtiene una solución informática.

Ya vimos que en las metodologías estructuradas se realiza una aproximación a la resolución del

problema descendente. Es decir, se pasa de una visión más general del problema con un nivel de

abstracción alto (cercano a las personas), a un nivel de abstracción más bajo (cercano a la máquina).

Para ello, estas metodologías proponen la creación de modelos que representen los procesos o

acciones a realizar, los flujos de información y las estructuras de datos necesarias para almacenar la

información.

El modelo general que representa a un sistema informático consta de

Entrada-Proceso-Salida. Los datos se introducen en el sistema, el cual los

procesa para obtener unos resultados a la salida. Las metodologías

estructuradas utilizan este esquema para realizar su enfoque del desarrollo

del software.

Clasificación de las metodologías.

2.- Clasificación de las metodologías.
Cuando estudiamos nuevos conceptos o ideas, siempre tendemos a establecer clasificaciones para
entender mejor su naturaleza. Clasificamos grupos de música, modelos de coches, tipos de ordenadores,
etc. En esta línea nosotros vamos a intentar clasificar las metodologías de desarrollo según el enfoque
que utilizan y su uso. Así, como podemos ver en la imagen siguiente tenemos metodología.

METODOLOGÍAS DE DESARROLLO PARA SISTEMAS DE TIEMPO REAL. UN ESTUDIO COMPARATIVO

Este trabajo incentiva el uso de las metodologías de desarrollo de software de Tiempo Real. Se facilita una herramienta de soporte a los desarrolladores para determinar la metodología mas adecuada de acuerdo a las necesidades del problema. Se establecen un conjunto de criterios para comparar metodologías de desarrollo de software: COMET, Octopus/UML y ROPES, y en base a estos resultados se logra seleccionar entre ellas la más apropiada a un problema en particular. Durante la investigación, expertos y desarrolladores revisan y ratifican cada uno de estos criterios. Finalmente, se identifican las ventajas de aplicar en un proceso de desarrollo de un sistema de tiempo real los conceptos de calidad de software y evaluación arquitectónica, como herramientas para garantizar características de calidad en el sistema. Se utiliza como metodología de investigación la Investigación-Acción.

I. INTRODUCCIÓN

En los últimos años en Venezuela, como consecuencia de las políticas de estado en lo referente al desarrollo endógeno, existe actualmente una orientación estratégica hacia el desarrollo de software de Tiempo Real, tomando en cuenta las necesidades de automatización de procesos, robótica, inteligencia artificial, entre otros.

En este sentido, es importante resaltar que el desarrollo de software en el dominio de Tiempo Real puede llegar a ser un proceso complejo, por lo tanto es fundamental aplicar metodologías y herramientas del área de la ingeniería del software adecuadas, para orientar el proceso de desarrollo. Actualmente, existen una amplia variedad de metodologías y notaciones que se han desarrollado para el análisis y diseño de sistemas de Tiempo Real, de las cuales los desarrolladores deben seleccionar la más adecuada, según el contexto del problema. 

II. DESARROLLO

1. Metodología

La investigación fue desarrollada utilizando la Metodología Investigación-Acción propuesta por Susman y Evered (1978) [1], dada su adaptación en el contexto de la Ingeniería de Software y Sistemas de Información. A continuación se detallan las cinco fases presentes en el proceso iterativo:

a. Fase de Diagnóstico: Corresponde a la identificación y descripción de la situación actual.

b. Fase de Planificación de la Acción: Especifica las acciones que deben ser ejecutadas para mejorar el problema.

c. Fase de Implementación de la Acción: Se implementa la acción planificada. Los investigadores y participantes colaboran generando cambios que mejoren la situación actual.

d. Fase de Evaluación: Después de ser completadas las acciones, los investigadores evalúan las salidas, utilizando técnicas apropiadas que aporten evidencia de la calidad de las acciones emprendidas.

e. Fase de Especificación del Aprendizaje: en esta fase se reflexiona sobre los resultados de la fase de evaluación.

2. Conceptos fundamentales

En esta sección se presenta una breve revisión de los conceptos fundamentales relacionados con el desarrollo de esta investigación.

• Sistemas de Tiempo Real (STR)

Un Sistema de Tiempo Real, se define como: “Un sistema en el que el tiempo en que se produce su salida es significante.  Esto es debido a que generalmente la entrada corresponde a algún instante del mundo físico y la salida tiene relación con ese mismo instante" [2]. Entre los elementos principales de un STR, se encuentran un sistema de control, interactuando con el mundo físico a través los sensores, quienes capturan datos para ser procesados y enviar la respuesta de retorno al mundo físico a través de los actuadores.

Por otra parte, dentro de las características propias del dominio de STR se encuentran los requisitos de tiempo, de seguridad y fiabilidad, que vistos desde el modelo de calidad estándar ISO 9126-1 corresponderían con las características de calidad: Eficiencia, Funcionalidad y Fiabilidad, respectivamente.

• Metodologías de Desarrollo de Software para Aplicaciones de Tiempo Real

Una metodología puede definirse como "Una versión ampliada del ciclo de vida completo del desarrollo de sistemas, que incluyen tareas o pasos para cada fase, funciones desempeñadas en cada tarea, productos resultantes, normas de calidad y técnicas de desarrollo que se utilizan en cada tarea" [3]. En los últimos años se han desarrollado diversas metodologías de aplicación específica del diseño de STR, entre ellas se pueden encontrar ROOM/UML-RT, HRT-HOOD, OOHARTS, SiMOO-RT, ACCORD/UML COMET, Octopus/UML, ROPES [4]. Para esta investigación, se seleccionaron las tres últimas de las metodologías mencionadas, tomando en cuenta características comunes tales como, basadas en notaciones estándares como UML y enfocadas bajo el paradigma orientado a objetos, utilizan la definición arquitectura de software. A continuación, se presenta una descripción breve de cada una de ellas.

• COMET (Concurrent Object Modeling and architectural design mEThod)

COMET [4, 5] es una metodología que emplea notación UML, y está basada en un ciclo de desarrollo iterativo, con las siguientes fases: modelado de requisitos, análisis , diseño, construcción e integración incremental del software y validación del sistema (ver Figura 1).

MÉTODOS ORIENTADOS A DATOS

Se pueden clasificar en:

• Orientados a Datos Jerárquicos
• Orientados a Datos No Jerárquicos

1. Orientados a Datos Jerárquicos: La estructura de control del programa debe ser jerárquica y debe derivarse de la estructura de datos. El proceso de diseño consiste en definir primero las estructuras de entrada y salida, para posteriormente combinarlas con el fin de obtener la estructura del programa. Finalmente se ordena la lógica procedimental para que se ajuste a esta estructura. El diseño lógico debe preceder y estar separado del diseño físico Métodos:

• JSP (Jackson Structured Programming) y JSD (Jackson Structured Design) de Jackson (1975)
• LCP (Logical Construction Program) de Warnier (1974)
• LCS (Logical Construction Systems) de Warnier y Orr (1981)

2. Orientados a Datos No Jerárquicos: Los datos son la parte esencial del sistema porque son más estables que los procesos que actúan sobre ellos. Son una representación de un modelo de datos de la organización formado por un conjunto de entidades de datos básicas y las relaciones entre ellas. Los procesos derivan de una definición inicial de los datos.Métodos:

• Metodología Ingeniería de la Información (Information Engineering - IE) de J. Martin y C. Finkelstein [Martin,1986.

– Planificación: Se construye una arquitectura de la información y una estrategia que soporte los objetivos de la organización – Análisis: Se comprenden las áreas de negocio y se determinan los requisitos del sistema – Diseño: Se establece el comportamiento del sistema deseado por el usuario y que sea alcanzable por la tecnología

– Construcción: Se construye el sistema que cumpla los tres niveles anteriores

METODOLOGIAS DE DESARROLLO DEL SOFTWARE

´En la unidad anterior vimos el ciclo de vida del software y sus diferentes modelos de desarrollo de

´software asociados. El ciclo de vida del software indica qué es lo que hay que obtener a lo largo del

´proceso de desarrollo del proyecto pero no muestra cómo hacerlo

Fundamentos:

´• Conseguir aplicaciones informáticas de calidad que den respuesta a las necesidades de los clientes y estén libres de errores. El aplicar de una metodología experimentada debe ayudarnos a alcanzar software de calidad con éxito.

• Un buen control de los proyectos para evitar retrasos, desarrollar más rápido y ajustarse al presupuesto. Sin una Metodología es fácil que en un proyecto se nos dispare el presupuesto y no se cumplan los plazos. Por ejemplo, si no hay una planificación no sabremos en qué fases debemos detenernos más o menos.

Sabemos que las metodologías descomponen el proceso. Pero, ¿en qué elementos lo
descomponemos?:

• El proceso queda descompuesto en tareas, que son actividades elementales en que se dividen los procesos.

• Para cada tarea definimos un procedimiento, que es la forma en que ejecutaremos la tarea.

´Ejemplo

´Veamos un ejemplo sobre algo tan cotidiano como es el hacer una tortilla de patata:

´Metodología 􀃆 Receta.

´Tareas 􀃆 Pelar y picar patatas, batir huevos, freír patatas, mezclar y hacer.

´Para la tarea batir huevos

´Procedimiento􀃆 Abrir los huevos, echarlos en un recipiente, quitar restos de cáscara, batir

´hasta bien mezclados.

´Técnicas 􀃆 Ilustraciones del libro de recetas.

Herramientas 􀃆 Tenedor, batidora

´En esta etapa inicial de desarrollo del software los desarrolladores estaban más centrados en la codificación del código que en comprender las necesidades de los usuarios.

Estado iniciaL

´Esto provocaba que los sistemas desarrollados fuesen difíciles de mantener, y en muchas ocasiones los clientes no quedasen satisfechos con el resultado porque no se cumplía con sus necesidades

Desarrollo ágil de software

El desarrollo ágil de software envuelve un nuevo enfoque radical para la toma de decisiones en los proyectos de software, refiere a métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan con el tiempo según la necesidad del proyecto, así el trabajo es realizado mediante la colaboración de equipos auto-organizados y multidisciplinarios, inmersos en un proceso de toma de decisiones a corto plazo compartido. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en lapsos cortos. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requisitos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, sino que la meta es tener una «demo» (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.

Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés). La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica.

La definición moderna de desarrollo ágil de software evolucionó a mediados de la década de 1990 como parte de una reacción contra los métodos de "peso pesado", muy estructurados y estrictos, extraídos del modelo de desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como burocrático, lento, degradante e inconsistente con las formas de desarrollo de software que realmente realizaban un trabajo eficiente.

Los métodos de desarrollo ágiles e iterativos pueden ser vistos como un retroceso a las prácticas observadas en los primeros años del desarrollo de software (aunque en ese tiempo no había metodologías formales). Inicialmente, los métodos ágiles fueron llamados métodos de "peso liviano".

En el año 2001, miembros prominentes de la comunidad se reunieron en Snowbird, Utah, y adoptaron el nombre de "métodos ágiles". Poco después, algunas de estas personas formaron la "alianza ágil", una organización sin fines de lucro que promueve el desarrollo ágil de aplicaciones. Muchos métodos similares al ágil fueron creados antes del 2000. Entre los más notables se encuentran: Scrum (1986), Crystal Clear (cristal transparente), programación extrema (en inglés eXtreme Programming o XP, 1996), desarrollo de software adaptativo, feature driven development, Método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems Development Method o DSDM, 1995).

Kent Beck creó el método de Programación Extrema (usualmente conocida como XP) en 1996 como una forma de rescatar el proyecto del Sistema exhaustivo de compensaciones de Chrysler (C3). Mientras Chrysler cancelaba ese proyecto, el método fue refinado por Ron Jeffries.

VENTAJAS:

• La primera y la que, a mi parecer es la más importante, es que estas metodologías ofrecen una rápida respuesta a cambios de requisitos a lo largo del desarrollo del proyecto gracias a su proceso iterativo, es tan importante realizar una buena recolecta de requisitos, como después poder modificarlos evitando grandes pérdidas en cuanto a costes, motivación, tiempo…
• El cliente, si quiere colaborar, puede observar como va avanzando el proyecto, y por supuesto, opinar sobre su evolución gracias a las numerosas reuniones que realiza el equipo con el cliente. Esto le da tranquilidad.
• Uniendo las dos anteriores, se puede deducir que al utilizar estas metodologías, los cambios que quiera realizar el cliente van a tener un menor impacto, ya que se va a entregar en un pequeño intervalo de tiempo un pequeño “trozo” del proyecto al cliente, y si éste quiere cambiarlo, solo se habrá perdido unas semanas de trabajo. Con las metodologías tradicionales las entregas al cliente se realizaban tras la realización de una gran parte del proyecto, eso quiere decir que el equipo ha estado trabajando meses para que luego un mínimo cambio que quiera realizar el cliente, conlleve la pérdida de todo ese trabajo.
• Importancia de la simplicidad al eliminar trabajo innecesario.
• DESVENTAJAS:
• Falta de documentación del diseño. Al no haber documentación es el código (junto con sus comentarios) lo que se toma como documentación.
• Problemas derivados de la comunicación oral. No hace falta decir que algo que está escrito “no se puede borrar”, en cambio, algo dicho es muy fácil crear ambigüedad.
• Fuerte dependencia de las personas.
• Falta de reusabilidad derivada de la falta de documentación
• Restricciones en cuanto a tamaño de los proyectos
• Problemas derivados del fracaso de los proyectos ágiles. Si un proyecto ágil fracasa no hay documentación o hay muy poca; lo mismo ocurre con el diseño. La comprensión del sistema se queda en las mentes de los desarrolladores.
•