Desarrollo de Sistemas Orientados a Objetos

CONTEXTO

El mundo en el que vivimos hoy en día está lleno de diferentes tipos de soluciones tecnológicas para prácticamente cualquier situación que nos podamos imaginar, se tienen desde las más simples hasta las más complejas, como puede ser un simple editor de texto como Microsoft Word hasta soluciones empresariales gigantescas como es el software ERP SAP.

Esto presenta un desafío muy grande para todo desarrollador, ya que, si este desea innovar en este mundo se le hará muy difícil porque el auge tecnológico que existe desde aproximadamente los años 60s, ha sido muy grande y se ha inventado prácticamente de todo. Eso quiere decir que los desarrolladores para poder encontrar un espacio de mercado a sus productos deben innovar, e hacerlo a día de hoy está un poco difícil por lo anterior mencionado.

Una forma que es muy útil para llamar la atención, es que un sistema abarque un área y cubra todas las necesidades de la misma, ya sea de forma automática o manual, pero que termine abarcando un campo grande de opciones que estén dentro de un contexto. Es decir, que un sistema que sea amplio puede hacer que sea llamativo para algún área en específico.

Pero presentar un sistema que sea amplio puede presentar problemas para los desarrolladores porque esto aumenta la complejidad del mismo, y un sistema más complejo hace que aumente el trabajo que se necesita hacer para terminarlo. Es por ello que se han desarrollador desde que comenzó a aumentar la complejidad de los sistemas, una basta cantidad de metodologías para desarrollar dichos sistemas de forma organizada, y es importante que todo desarrollador las conozca.

EDITORIAL

Este libro se consiguió gracias a la Universidad Bicentenaria de Aragua, mediante el uso de las plataformas en línea junto a las metodologías que aplican de aprender haciendo. Todo ello para el beneficio del estudiante.

Este libro es una actividad presentada en la materia Análisis y Diseño de Sistemas III.

AUTOR

Mi nombre es Jorge Ramírez, estoy actualmente estudiando la carrera de Ingeniería de Sistemas, cursando actualmente el 8vo trimestre de mi carrera, en la Universidad Bicentenaria deAragua.

INTRODUCCIÓN

Las metodologías para desarrollar sistemas de información se vinieron a dar gracias a la amplitud con la que se empezó a utilizar la tecnología (sabemos que hoy en día se utiliza para absolutamente todo), esto debido a que con el pasar del tiempo se comenzaron a desarrollar sistemas que abarcaban una amplitud de opciones y operaciones, es decir, poco a poco se desarrollaron sistemas más complejos.

Esta complejidad poco a poco comenzó a ser un reto para el equipo de desarrollo, ya que, debían abastecer una amplia gama de campos en un tiempo determinado, por lo que debían recurrir a sistemas de organización de todo el proyecto para poder cumplir con las expectativas planteadas. Esto supuso que diversos autores comenzaran a desarrollar sus formas de gestionar proyectos de forma que se puedan: establecer requisitos, construir modelos, codificar y mantener. Además para poder abastecer necesidades más complejas, se inventó lo que hoy en día se conoce como POO (Programación Orientada a Objetos), lo que le permitió a los equipos de desarrollo crear estructurar más complejas con mayor facilidad en sus sistemas.

El desarrollo de sistemas debe tener varias áreas a tomar en cuenta, las más esenciales son: el dominio del problema, proceso de desarrollo de un sistema de información (y en este caso, se especificará del proceso orientado a objetos) y el modelo de las especificaciones.Además de todo ello se debe conocer la metodología con la que se trabajará durante todo el desarrollo, en este caso particular, hablaremos de la más utilizada porque no es una metodología que contiene una serie de pasos, si no una metodología que va en conjunto de más metodologías y su nombre es RUP (Rational Unified Process, o en español, Proceso Racional Unificado)

CAPÍTULO 1: Dominio del problema

El problema, es básicamente la situación que se le presenta al usuario y que el desarrollador debe solucionar mediante la aplicación de la tecnología en diversas tareas. El dominio del problema incluye a todos aquellos objetos o elementos conceptuales que forman parte del entorno en donde se presenta la situación, es decir, que son los elementos conceptuales que son necesarios para entender el negocio o el entorno del usuario para poder desarrollar la solución.

Este es el artefacto clave para el análisis orientado a objetos por el hecho que, como se mencionó, son los elementos conceptuales que forman parte del entorno del cliente y dichos elementos suelen ser objetos que poseen un grupo de características y comportamiento determinado que cobran sentido dentro del dominio del problema.

En resumen, el modelo del dominio del problema son aquel grupo de objetos que tienen correspondencia directa con el entorno en donde se encuentra la situación, y a su vez, se aplicará la solución. La representación de este modelo viene dada por el Lenguaje de Modelado Unificado, o mejor conocido como UML (Unified Model Language), el cual es una forma de representar a las abstracciones que se identifican que son necesarias para la elaboración de la solución.

Esta forma de representación es, como su nombre lo indica, unificada. Con lo que quiere transmitir el mismo mensaje a todo el mundo independientemente de quien lo lea, claramente para entenderle hay que conocer sobre él, de otra forma sería como intentar leer inglés sin saber lo más básico.

Por ende, el UML se diseñó para que cualquiera que desee entender como funciona un sistema y como están representadas las partes en el código, pueda acceder a dicho diagrama y entender un poco mejor el funcionamiento

interno del mismo. Porque eso si, este es un requisito en la documentación a la hora de desarrollar software.

Generación del modelo

A la hora de tener una situación en la que se deba desarrollar un software para su solución, primeramente se debe escuchar atentamente al problema planteado para identificar a todos los actores y sus acciones. Se establecen los siguientes pasos:

1. Identificación de clases candidatas: en este paso se buscan identificar aquellos posibles elementos que sean las clases del sistema a desarrollar. Se identifican las clases distinguiendo aquellas que son físicas de las conceptuales; al igual que una vez que se tiene identificadas, se eliminan aquellas redundantes, irrelevantes e imprecisas.

2. Identificación de asociaciones: es la relación que tienen dos clases, esta debe diferenciarse entre: asociaciones de agregación, asociaciones de agregación (el ciclo de vida del objeto no depende de otro objeto), asociación de composición (el ciclo de vida del objeto depende de otro objeto), generalización (relación de herencia entre dos clases) y clase de asociación (es cuando la asociación entre clases puede tener propiedades).

3. Identificación de roles: es el papel que juega cada clase desde el punto de vista de la otra clase en una relación, si el nombre o la asociación es muy descriptiva, el rol puede omitirse.

4. Identificación de multiplicidad: es cuando los atributos de una clase se encuentran en otra.

5. Identificación de atributos: estos pueden ser seleccionados en base al conocimiento de la clase o descripción de la situación, en caso de ser la primera opción, solo deben colocarse aquellos relevantes para el sistema.

6. Generación de diccionarios de clases: este describe las clases identificadas en el dominio del problema, es una especie de glosario de términos.

CAPÍTULO 2: Proceso de Desarrollo

Esta es la descripción de las actividades que va a desarrollar cada uno de los integrantes del equipo de desarrollo para en conjunto terminar realizando un producto coherente. El objetivo principal de esta fase es: predecir el costo, mantener la calidad, predecir el tiempo de desarrollo.

Al momento de llegar a esta fase del desarrollo se debe tener claro que no existe una metodología universal que pueda aplicar a todos los proyectos, si es verdad que existen múltiples metodologías para la amplia cantidad de situaciones que pueden presentarse, pero a fin de cuentas es importante resaltar que las diferentes metodologías pueden adaptarse a diversas situaciones.

Ya eso queda a disposición de quien dirige el proyecto, escoge la metodología según el análisis que haya realizado de la situación presentada. Esta metodología claramente debe adaptarse a la experiencia que tenga el equipo de trabajo, esto es porque se obtienen mejores resultados porque el equipo de trabajo ya estará acostumbrado, además de adaptarse a los métodos de trabajo del cliente.

Aparte de los objetivos ya establecidos, esta fase tiene como objetivo el mejorar la reusabilidad del producto, es decir, se puede extender la usabilidad del mismo haciendo que las tareas que realiza puedan ampliar su rango de alcance, es decir, que puedan abarcar mayores áreas. Claro está que esta no es la única manera de mejorar la resuabilidad, ya que, también pudieran ser agregando funciones que permitan mejorar la productividad a la hora de que el cliente esté utilizando el producto, o que este tenga un rendimiento tal que no le cause ningún tipo de incomodidad al cliente, generando un sentimiento de satisfacción en este y que se sienta bien

utilizando el producto. Existen múltiples formas de aumentar la reusabilidad de un producto.

Elementos básicos

De los elementos más importantes que se encuentran a la hora de entrar en esta fase del proyecto es la ocupación que tiene cada trabajador, de forma que las tareas que realiza cada uno se sincronice con el aporte que realice el resto y que al final de todo se pueda ir estructurando el producto de forma consistente con el aporte de cada uno.

Las tareas que se desarrollan en el proyecto pueden clasificarse en: alto y bajo nivel. Las de alto nivel son aquellas tareas generales que abarcan grandes campos del proyecto, como pueden ser las de desarrollar la estructura inicial, o el núcleo del sistema, o módulos que en conjunto realicen una tarea amplia; en cambio las tareas de bajo nivel son aquellas tareas sumamente específicas que tiene cada uno de los trabajadores.

En estas tareas de bajo nivel se pueden encontrar objetivos como el desarrollar una única aplicación que sea un elemento de un pequeño sistema dentro del sistema que seria el producto completo, o desarrollar una única parte de código de alguna aplicación para que funcione adecuadamente.

Otro elemento importante del desarrollo de software son los documentos que deben generarse para las actividades, estos permiten un mejor entendimiento de como funciona el sistema. En los sistemas orientados a objetos, esto es sumamente importante por el nivel de complejidad que puede llegar a tener todo el sistema.

El documentar adecuadamente cada una de las tareas que se realizan va a ahorrar dolores de cabeza en el futuro, porque le permite a futuros trabajadores entender con claridad el funcionamiento del código y tener la posibilidad de mejorar su rendimiento o ampliar la funcionalidad, o simplemente actualizarlo a requisitos nuevos, ya sea por cambio de arquitectura o plataforma.

También terminará siendo útil para los mismos trabajadores que desarrollaron ese proyecto, porque si estos no se acuerdan de cómo se codificó alguna parte o como funciona realmente algún subsistema o el sistema completo, estamos hablando de que pueden perder desde horas o días hasta meses o años, nada más intentando comprender el código en su totalidad.

Y por último, pero no menos importante, son los procesos que se utilizan para desarrollar el producto que deben ser amoldados a la situación que se presente porque, cómo se menciono previamente, no existe una metodología universal para desarrollar los proyectos. Solo existen los cambios de formas que se le pueden otorgar a los métodos, esto trae beneficios como: si el equipo del proyecto esta acostumbrado a trabajar con estructuras de trabajo parecida, existirá una mayor efectividad a la hora de realizar las tareas, por lo que aumenta la productividad de todo el equipo.

Esto trae beneficios a la calidad del producto final y a los tiempos de entrega, sin contar la cantidad de beneficios que se le pueden llegar a presentar a la parte económica del proyecto. Otro beneficio de amoldar las metodologías a la situación, es que pueden adaptarse a los requerimientos, métodos de trabajo y solicitudes del cliente, en consecuencia, otorgándole mayor satisfacción al mismo con el producto.

Escalabilidad

Esta es un elemento fundamental a la hora de desarrollar un proyecto, la escalabilidad es hacer que la dimensión de un proyecto sea variable, es decir, que puede que mientras se desarrolle tenga la capacidad de ampliar el rango funciones que abarca el sistema.

La escalabilidad tiene una particularidad importante, y es que mientras mayor sea esta mayor llega a ser la complejidad. Mientras mayor sea la complejidad, aumentan los niveles de abstracción que se utilizan, incrementa la comunicación entre los módulos y llega a ser más difícil localizar los errores porque existen mayor cantidad de componentes.

Otro detalle importante es que mientras la escalabilidad aumenta, el esfuerzo debe crecer linealmente. Esto permitira tener un riitmo de trabajo adecuado en todas las fases del proyecto, sin llegar sobrecargar de trabajo a todo el equipo y evitar que el esfuerzo disminuya a largo plazo. La forma de conseguir la escalabilidad es estableciendo escalas temporales para hacer las actividades.

Modelos de proceso

Existen diversos modelos que permiten estructurar el desarrollo del proyecto, estos son:

 Modelo de Túnel: este es el más básico, ya que se aplica a los proyectos pequeños. Se caracteriza por no tener un modelo de desarrollo.

 Modelo en cascada: el primer paso es análisis de los requisitos, luego el análisis general, diseño del sistema, codificación, pruebas de módulos, integración, prueba del sistema y mantenimiento. Este es el proceso normal que se sigue cuando se está avanzando en el desarrollo, ahora bien, para la eliminación de errores deben recorrer los pasos de forma inversa. Esta metodología llega a funcionar en proyectos que ya tienen todo diseñado pero cuando se presenta un problema en la última fase, se debe adaptar el problema a la aplicación y no al revés.

 Procedimiento en espiral: esta metodología se cataloga como iterativa, consiste en diseñar desde los diseños más pequeños a los más grandes. Las fases son: análisis de requisitos, análisis y diseño, codificación e implantación, y las pruebas y validación. La última fase permite que el usuario esté involucrado en el desarrollo del proyecto, reduciendo riesgos y permite reunir métricas a lo largo de cada iteración.

Este puede decirse que es como el proceso en cascada pero en versiones más pequeñas, con objetivos más simples y que se realiza la cantidad de veces que sean necesarias.

CAPÍTULO 3: Modelaje de Especificaciones

Los requerimientos son la parte más importante de todo sistema, ya que sin estos no se tiene ningún sistema a desarrollar porque no hay necesidades que satisfacer. Luego también está que analizarlos es fundamental para poder entender con mejor precisión aquello que quiere el cliente y poder tomar en cuenta lo que es factible y lo que no.

Al realizar el análisis de los requisitos se puede realizar una descripción más detallada de lo que son los requerimientos de funcionalidad y de la calidad del producto final. La tarea del análisis de los requisitos se necesita que el cliente y el desarrollador estén en comunicación para poder entenderse claramente, el desarrollador realiza preguntas y obtiene información más precisa acerca de lo que quiere el cliente, y el cliente entiende la forma de trabajar con la que se llevará a cabo el producto.

Todo ello se realiza con la finalidad de ir puliendo el producto final a lo que el cliente realmente necesita y quiere. Los principales aspectos del análisis de los requisitos son: identificar los paquetes de funcionalidad y detallarlos hasta que no exista ambigüedad, determinar los límites de la aplicación, identificando agentes externos con los que se deben interactuar, y por último, identificar las características de las interacciones, para ello se realiza un catálogo de términos.

El modelaje de las necesidades no es una opción para el desarrollador, es una necesidad; este proceso puede resumirse en que es básicamente entender y documentar la aplicación. Es sumamente útil utilizar diagramas de contexto porque permite capturar el contexto en el que opera el sistema, permite identificar los mensajes y eventos que ocurren en el sistema y su entorno; utilizar diagramas de casos de uso son un método alternativo y complementario a los diagramas de contexto.

Proceso

El proceso para modelar los requerimientos es:

1. Identificar al cliente: consiste en identificar quien será el usuario del sistema a desarrollar, es decir, quien tiene un problema a resolver.

2. Entrevista al cliente: este consiste en conocer los deseos y necesidades del cliente, para ello se utilizan herramientas de expresión, se bosquejan interfaces y se identifica la plataforma de hardware.

3. Documento de los requisitos: se realiza un documento en el que se encuentre toda la información obtenida del cliente, de esta forma todos poseen la misma información y se deja plasmado, básicamente, los objetivos del sistema.

4. Inspección a los requisitos: esto es como hacer un repaso de los mismos por si llegase a existir ambigüedades, tenga errores, haya faltado algo, esté escrito algo no hablado, etc. En fin, es con la finalidad de filtrar algún error que pueda existir.

5. Especificaciones detalladas: y por último, se elaboran los requerimientos más específicos para desarrollar el sistema, para ello son sumamente útiles los documentos gráficos y textuales.

CAPÍTULO 4: RUP

La metodología RUP consiste en la utilización de diversos métodos, es decir, que es como una metodología que contiene diversas metodologías en su interior. Cuando estamos hablando de los sistemas orientados a objetos, es la estructura de trabajo que se define para el proyecto, con el objetivo del producto y basado en UML.

Esta metodología se basa en los casos de uso, lo que quiere decir que se enfoca en el punto de vista del usuario y la forma en que el sistema será utilizado por el mismo. Un caso de uso define un fragmento de funcionalidad del sistema que le otorgará valor añadido para el usuario, los casos de uso guían el diseño, la implementación y las pruebas.

Este proceso está enfocado en la arquitectura, esto es debido a que tiene foco en las partes más relevantes del sistema. Permitiendo tener una visión común entre todos los involucrados y una perspectiva más clara del sistema completo

El enfoque que tiene hacia la arquitectura es beneficioso porque cuando se establece una arquitectura robusta desde un inicio, o desde lo más temprano posible, esta suele ser receptiva con los cambios, es decir, que no se ve directamente afectada negativamente y tiene receptividad a los cambios.

Los casos de uso y la arquitectura tienen una relación especial en este ámbito, que además es importante a tomar en cuenta. La arquitectura debe poder permitir que los casos de uso tengan lugar y los casos de uso deben estar estructurados de forma tal que se puedan implementar en la arquitectura. Es una relación que siempre debe existir en estos sistemas.

Artefactos

Los artefactos de la metodología también pueden ser vistos como sus fases, estos son:

• Inicio: es cuando la planificación del proyecto tiene lugar y los requisitos se recaudaron del cliente, esta etapa no toma mucho tiempo. Aquí se incluye el documento de visión y la especificación de los requerimientos.

• Elaboración: en esta fase se crean los modelos que guiarán todo el desarrollo del proyecto, luego de ello se elabora un plan de proyecto incluyendo las características y especificaciones. Aquí se incluyen los diagramas de casos de uso. Además, se incluye el documento de arquitectura que incluirá las siguientes vistas: lógica (diagrama de clases), de implementación (diagramas de estado, secuencia y colaboración), conceptual (describe los modelos de dominio) y física (mapa de comportamiento de hardware).

• Construcción: esta parte es la del desarrollo del software en sí. Se especifican requisitos faltantes, se diseñan, desarrollan y prueban los casos de uso.

• Transición: esta fase va desde las pruebas hasta la implementación del sistema. En esta fase se incluye la capacitación del usuario final y el equipo de desarrollo se asegura que se cumpla con el objetivo final solucione el problema del usuario

Importancia en el diseño orientado a objetos

Este nace por la necesidad de crear sistemas que puedan responder a una mayor complejidad de operaciones, lo cual si analizamos un poco sabemos que está bien y que trae beneficios a todo tipo de industrias para que se apoyen con la tecnología. Pero si observamos todo ellos desde el punto de vista del desarrollador, tenemos que tiene un reto intelectual cada vez que desarrolla un sistema nuevo, porque debe conocer sobre el área donde se aplicará el sistema, además de las herramientas de software que le permitan satisfacer los requerimientos y conocer el funcionamiento del lenguaje de programación con el que realizará el proyecto.

Aplicar metodología como la mencionada, RUP, permite al equipo de desarrollo tener un orden a la hora de llevar a cabo el desarrollo del proyecto, permite manejar diversas situaciones que a simple vista vemos que son altamente complejas. Pero el llevar a cabo metodologías permite subdividir aquellas estructuras complejas en otras más sencillas y pequeñas.

Esto es la importancia que tiene en los sistemas orientados a objetos, que lo mencionado, hace que el equipo de desarrollo pueda cumplir con las expectativas del cliente y poder hacerse un hueco en el mercado de desarrollo actual. Porque a día de hoy existen muchas compañías que se dedican a la entrega de software, y eso hace que cada vez sea más difícil destacar.

REFERENCIAS

colaboradores de Wikipedia. (2022). Proceso Unificado de Rational. Wikipedia Recuperado 3 de marzo de 2023 en:

https://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

Drake, J. M. (2008). Especificaciones de una aplicación. Universidad de Cantabria. Recuperado 28 de febrero de 2023 en:

https://www.ctr.unican.es/asignaturas/mpestr/doc/m2_especificacion.p df

Drake, J. M. (2008b). Proceso de desarrollo de aplicaciones software. Universidad de Cantabria. Recuperado 28 de febrero de 2023 en:

https://www.ctr.unican.es/asignaturas/MC_OO/Doc/OO_08_I2_Proces o.pdf

García, F. J., & García H., A. (2017). MODELO DE DOMINIO. Universidad de Salamanca. Recuperado 27 de febrero de 2023 en:

https://repositorio.grial.eu/bitstream/grial/1153/1/8.%20Modelo%20de %20dominio.pdf

López R, R. A., & Pech M, J. A. (2015). Desarrollo de herramientas de gestión de proyectos RUP usando metodología SCRUM + XP: Pruebas. Universidad Politécnica de Madrid. Recuperado 28 de febrero de 2023 en:

https://oa.upm.es/44208/3/TFM_RODRIGO_ANTONIO_LOPEZ_ROS CIANO_JOSE_ALFREDO_PECH_MONTEJO.pdf

Madeja. (s. f.). Estudiar el dominio del problema. Junta de Andalucía Recuperado 27 de febrero de 2023 en:

https://www.juntadeandalucia.es/servicios/madeja/contenido/libropautas/175

Ortega, L. (2022). Metodología RUP: ¿Qué es, cúal es su objetivo y cómo se utiliza? . Lean Managemente.Recuperado 28 de febrero de 2023 en:

https://lean-management.site/rup/

Universidad Autónoma Metropolitana. (s. f.). Modelo del Dominio del Problema y Representación en UML. Universidad Autónoma Metropolitana. Recuperado 27 de febrero de 2023 en:

https://academicos.azc.uam.mx/jfg/diapositivas/adsi/Unidad_6.pdf