





Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Prepara tus exámenes con los documentos que comparten otros estudiantes como tú en Docsity
Los mejores documentos en venta realizados por estudiantes que han terminado sus estudios
Estudia con lecciones y exámenes resueltos basados en los programas académicos de las mejores universidades
Responde a preguntas de exámenes reales y pon a prueba tu preparación
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Comunidad
Pide ayuda a la comunidad y resuelve tus dudas de estudio
Descubre las mejores universidades de tu país según los usuarios de Docsity
Ebooks gratuitos
Descarga nuestras guías gratuitas sobre técnicas de estudio, métodos para controlar la ansiedad y consejos para la tesis preparadas por los tutores de Docsity
Buenas practicas en el desarrollo de software
Tipo: Apuntes
1 / 9
Esta página no es visible en la vista previa
¡No te pierdas las partes importantes!
La construcción de un sistema software, con independencia de su tamaño, de sus características funcionales y de la tecnología elegida, consta de una serie de fases que abarcan desde su concepción hasta su retirada, definiendo un espacio temporal que recibe el nombre de ciclo de vida del software. Existen diferentes modelos de ciclo de vida, cada uno con sus propias peculiaridades, adaptándose unos mejor que otros a los distintos paradigmas o estilos de programación. Pero, lo que sí se puede afirmar es que en ninguno de estos modelos de desarrollo se comienza un proyecto software por la fase de implementación. Comenzar un proyecto software por la fase de implementación, esto decir, colocarse inmediatamente delante del ordenador y comenzar a generar código fuente, es desgraciadamente una forma de trabajo bastante extendida, que toma sus tintes más preocupantes cuando sale del entorno del programador ocasional o aficionado, para convertirse en la forma de trabajo de la inmensa mayoría de las empresas de construcción de software dentro y fuera de nuestras fronteras. Por tanto, puede parecer utópico y dar la sensación de predicar en el desierto, el dedicar un artículo al análisis y el diseño en la orientación a objeto, cuando prácticamente nadie se molesta en seguir unos principios metodológicos básicos en sus desarrollos y, además, la orientación a objeto en nuestro país no acaba de convertirse en una alternativa completamente aceptada. No obstante, desde nuestra modesta posición vamos a intentar aportar nuestro granito de arena en favor de lo que sería una forma más correcta de realizar la construcción de una aplicación software desde el prisma de la orientación a objetos.
Nada más lejos de la intención de este artículo que realizar la descripción de ningún modelo de ciclo de vida del software, ya que para este fin el lector puede recurrir a cualquiera de los textos clásicos sobre ingeniería del software, por ejemplo [1] y [2], donde encontrará una información más amplia y precisa. Pero, dado que se ha comenzado el artículo criticando la construcción de las aplicaciones que empiezan directamente por la codificación, se va a dar un marco muy general de lo que sería un desarrollo software, marco que en su generalidad es perfectamente válido para cualquier tipo de desarrollo, independientemente que sea orientado a objeto o no. El marco de desarrollo de una aplicación software estaría formado por las tres fases tradicionales: análisis, diseño e implementación. El análisis es la fase cuyo objetivo es estudiar y comprender el dominio del problema, es decir, el análisis se centra en responder al interrogante ¿QUÉ HACER? El diseño, por su parte, dirige sus esfuerzos en desarrollar la solución a los requisitos planteados en el análisis, esto es, el diseño se haya centrado en el espacio de la solución, intentando dar respuesta a la cuestión ¿CÓMO HACERLO? Por último, la fase de implementación sería la encarga de la traducción del diseño de la aplicación al lenguaje de programación elegido, adaptando por tanto la solución a un entorno concreto.
Que este marco de desarrollo sea válido tanto para los desarrollos tradicionales ( desarrollos estructurados ) como para los desarrollos orientados a objeto, no significa que la realización de las actividades propias de cada fase se lleve a cabo de la misma manera. De hecho, en los desarrollos estructurados hay mucha distancia entre las fases de análisis de diseño, e incluso entre los diferentes modelos generados en una misma fase. Esta separación se conoce con el nombre de gap semántico , y es la barrera que la orientación a objeto intenta eliminar difuminando la frontera entre las diferentes fases. Los métodos orientados a objeto acortan la distancia existente entre el espacio de conceptos ( lo que los expertos o usuarios conocen ) y el espacio de diseño ( lo que conocen los desarrolladores ) e implementación, ya que los objetos del mundo real tienen una correspondencia bastante clara con los objetos del sistema informático, evitando así los grandes abismos existentes entre el análisis y el diseño en el enfoque estructurado, esto es la falta de continuidad en la representación de los conceptos en una y otra fase, por ejemplo los DFDs y los diagramas de estructura, como muestra la Figura 1. Figura 1. Desarrollos estructurados. Por su parte, en los desarrollos orientados al objeto se tiene una mayor continuidad entre las diferentes fases, con unas fronteras entre fases muy poco marcadas que dan lugar a desarrollos más iterativos e incrementales. Todo esto es posible gracias a una característica de vital importancia, el modelo subyacente a todas las fases es el mismo, el modelo objeto, que tiene como elemento central al objeto, que es la entidad que encapsula elementos estructurales y de comportamiento. De esta forma, los objetos semánticos identificados en la fase de análisis se refinarán durante la fase de diseño e implementación, a la vez que se añaden objetos de interfaz y de utilidad para constituir la aplicación final, como se puede apreciar en la Figura 2. Figura 2. Desarrollos orientados a objeto. AnálisisAnálisis DiseñoDiseño^ ImplementaciónImplementación DFD DE PROGRAMA P ROCESOS DATOS^ DER^ RELACIONAL^ TABLAS
BJETOS
La identificación de objetos es la clave o el cuello de botella a la hora de aplicar tanto el diseño como el análisis orientados al objeto. Existen varios enfoques en cuanto a las técnicas a aplicar para identificar cuales son las abstracciones que mejor representan o recogen la semántica del problema que se desea resolver. Aquí se van a comentar brevemente las tres técnicas más difundidas para llevar a cabo esta actividad. Estas son:
Tarjetas CRC Las tarjetas CRC ( Class, Responsability and Collaboration- Clases, Responsabilidades, y Colaboraciones ), también denominadas tarjetas de clase, constituyen una forma simple y efectiva de analizar escenarios. Esta técnica consiste en elaborar una ficha o tarjeta por cada clase en la que se anotan los siguientes datos: el nombre de la clase, la lista de sus superclases, la lista de sus subclases, sus responsabilidades y sus colaboraciones , como se puede apreciar en la Figura 4. Figura 4. Tarjeta de clase. Las responsabilidades de una clase son todos los servicios que proporciona la clase a sus clientes potenciales. Por su parte, las colaboraciones de una clase representan las peticiones que hace una clase a ciertos servidores para poder cumplir sus responsabilidades. La forma de trabajo con las tarjetas de clase consiste en identificar las primeras clases semánticas. Estas clases se examinan para determinar cómo envían mensajes a otras y cuáles son sus responsabilidades, comprobando si cada clase posee todas las características necesarias para atender las peticiones que le llegan. Para la validación de las clases, cada miembro del equipo de desarrollo toma el papel de una o varias clases realizando una simulación de las responsabilidades y colaboraciones de éstas. Formas de utilización Las formas de utilización o casos de uso se deben a Ivar Jacobson y fueron presentadas en el OOPSLA’87. Un caso de uso es una forma, patrón o ejemplo concreto de utilización, un escenario que comienza con algún usuario del sistema que inicia alguna transacción o secuencia de eventos interrelacionados [6]. Las formas de utilización se introducen en la etapa de análisis para representar escenarios concretos que ayudan a identificar los objetos que intervienen en dichos escenarios. Una forma de utilización consta de dos elementos principales, los actores y las formas de utilización. Un actor representa cualquier elemento que intercambia información con el sistema, por lo que está fuera del sistema, y se representan por el típico monigote. Una forma de utilización representa Clase: nombre de la clase (Abstracta o concreta) Lista de superclases Lista de subclases Responsabilidad Colaboración Figura 5. Elementos de una forma de utilización
Los diagramas de clases representan un esquema conceptual que describe muchas instancias de datos posibles, por tanto, los diagramas de clases van a describir clases de objetos. Durante el análisis se usan los diagramas de clase para indicar los roles comunes y las responsabilidades de las entidades que sustentan el comportamiento del sistema, mientras que durante el diseño, se utilizan para capturar la estructura de las clases que forman la arquitectura del sistema. Por su parte un diagrama de objetos estático es una instancia del diagrama de clases, mostrándose como una instantánea del estado del sistema en un momento dado. Los diagramas de objetos describen, por tanto, la forma en que un cierto conjunto de objetos se relacionan entre sí. De lo expresado aquí se puede afirmar que un diagrama de clases dado se corresponde con un conjunto infinito de diagramas de objetos que serían instancias de dicho diagrama de clases. Diagramas de formas de utilización Ya presentamos anteriormente las formas de utilización como una forma de identificación de objetos en el análisis orientado a objetos. UML 1.1 tiene soporte para las formas de utilización, y dado que su inventor Ivar Jacobson es uno de los creadores destacados de UML, la notación de estos diagramas es muy similar a la notación original. Como resumen de lo qué es un diagrama de formas de utilización, podíamos decir que se trata de un diagrama donde una serie de entidades externas al sistema ( los actores ) interacciona con el sistema, comunicándose con una cierta forma de utilización. Diagramas de interacción Los diagramas de interacción son modelos que describen como grupos de objetos colaboran para conseguir algún fin. Se pueden distinguir los dos siguientes tipos: diagramas de secuencia y diagramas de colaboración. Un diagrama de secuencia muestra las interacciones expresadas en función de secuencias de tiempo. En concreto muestra los objetos participantes y los mensajes que intercambian entre ellos a lo largo del tiempo. Un diagrama de secuencias tiene dos dimensiones, la vertical que representa el tiempo, y la horizontal que representa los distintos objetos. El tiempo avanza desde el comienzo hasta el final de la página, aunque se puede tomar el sentido contrario. Un ejemplo de un diagrama de secuencias se puede ver en la Figura 6. Un diagrama de colaboración muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común. Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. La diferencia entre un diagrama de secuencias y un diagrama de colaboraciones es que este último muestra las relaciones sobre los objetos sin mostrar la dimensión temporal de dichas relaciones. Diagramas de transición de estados Un diagrama de transición de estados representa los estados que puede tomar un objeto mostrando, además, los eventos o circunstancias que implican el cambio de un estado a otro.
En UML, un estado es una condición que se verifica durante la vida de un objeto o de una interacción. Durante este período de tiempo se satisface alguna otra condición, se ejecuta alguna acción o se espera a la ejecución de algún evento. Un objeto permanece en un estado por un espacio finito y no instantáneo de tiempo. Cuando un objeto cambia de estado por la ocurrencia de un evento, se dice que se ha producido una transición. Figura 6. Ejemplo de un diagrama de secuencias de UML. Diagramas de actividad Los diagramas de actividad es una de las partes más inesperadas de UML. A diferencia del resto de las técnicas, los diagramas de actividad no tienen un origen claro en los trabajos previos de los creadores de UML. Este diagrama combina las ideas de varias técnicas: los diagramas de eventos de Jim Odell, las técnicas de modelado de estados de SDL, Redes de Petri. Un diagrama de actividad es un tipo especial de diagrama de estados en el que todos o la mayoría de los estados son estados de acción, y todas o la mayoría de las transiciones son disparadas porque se ha completado la acción de los estados fuente. El diagrama de actividad se adjunta a través del modelo a una clase, a un método o a una forma de utilización. El propósito de estos diagramas es centrarse en el flujo de los procesos internos, con independencia de los eventos externos. Por ello los utilizaremos fundamentalmente para flujos de operaciones, mientras que los diagramas de estado ordinarios serán más propios de sistemas donde puedan ocurrir eventos asíncronos. Diagramas de implementación Estos diagramas muestran los aspectos físicos del sistema, diferenciándose dos tipos: los diagramas de componentes y los diagramas de despliegue. Los diagramas de componentes representan las relaciones de dependencia entre el código fuente, componentes binarios y ejecutables. comprobar() [comprobar=TRUE] eliminar() Ventana de entrada de orden Orden^ Línea de Orden Elemento de stock prepar()