2. MARCO TEORICO
2.1. Paradigma orientado
a objetos
El origen del Paradigma Orientado a Objetos impuesto
por el marketing del software, se remonta a los años sesenta, cuando es
concebido como un método que trata de emular en el ordenador, el funcionamiento
del mundo real.
-
Esta gran idea parte del hecho, que para resolver
tus problemas cotidianos no necesitas recurrir a la aplicación de algoritmos o
heurísticas estructuradas con listas, colas, pilas, árboles, registros, etc.;
pues solo recurres a utilizar algunas acciones con los objetos que tienes a tu
alcance.
-
Como nuestro ámbito cotidiano está constituido por
objetos, estamos rodeados de ellos, convivimos con ellos; ineludiblemente los
usamos para encarar nuestros problemas y por ello, no te parece genial adoptar
esta realidad, como modelo para diseñar nuestras heurísticas informáticas.
-
El POO, que implica ser codificada mediante la
Programación orientada a objetos, representa el "Antes y el después de la
programación informática", que factiblemente te acompañará por mucho
tiempo.
Esta filosofía de
diseño avanzado de software, se remonta al lenguaje SmallTalk, quién guiado por
las pautas del paradigma orientado a objetos, propone soluciones a los típicos
problemas de la programación, tales como:
- La falta de reusabilidad del código, en desmedro de la rentabilidad.
- La dificultad de modificar, actualizar o efectuar reingeniería de sistemas, minimizando así su vida útil.
- Los laboriosos, traumáticos y extensos procesos de desarrollo, carentes de codificación no intuitiva.
- La falta de portabilidad.
El POO, enfrenta
estos inconvenientes adoptando la idea natural tomada de la existencia de
nuestro mundo conformado de objetos reales, con los cuales podemos resolver
tales problemas. Así, emulando tal realidad cotidiana del hombre, recurre al
concepto de OBJETO, como una estructura compleja que pretende representar otra
similar del mundo real, basada en las siguientes características que definen su
propia naturaleza:
Un lenguaje de computación está orientado a los
objetos si soporta las cuatro propiedades específicas de los objetos, llamadas:
- abstracción,
- polimorfismo,
- herencia, y
- encapsulamiento.
ABSTRACCION DE DATOS
Permite diferenciar
entre el comportamiento de un objeto o, la acción que es capaz de realizar y
cómo lleva a cabo este comportamiento. Esta abstracción de datos se implementa
a través de una interface de objeto, que permite a un objeto emisor
comunicarse con otro objeto receptor, pero el objeto emisor desconoce la forma
en que se lleva a cabo la acción solicitada (mensaje).
Es la propiedad que
destaca las características esenciales del objeto, distinguiéndola de otros
tipos de objetos y según la perspectiva del que efectúa la abstracción, muestra
su límite, así, los principales elementos del Diseño Orientado a Objetos
consiste en componer niveles y conjuntos adecuados de abstracciones.
El planteo de una
correcta abstracción genera la amigabilidad del sistema, así por ejemplo,
cuando decimos “soporte expeditivo de información interactiva para evaluativos”
estamos planteando un nivel de abstracción elevada del “machete de examen”.
Una analogía que permite conceptualizar el polimorfismo, es observar en la vida diaria cómo los alumnos responden al timbre de la escuela. Todos los alumnos conocen el significado del timbre. Cuando el timbre (mensaje) suena, sin embargo, tiene su propio significado para cada alumno (objeto). Algunos alumnos irán a casa, otros a la biblioteca, y otros irán a clases. Cada alumno responde al timbre, pero su respuesta puede ser diferente.
En la POO, esta
característica que permite diseñar métodos para que las clases derivadas,
adquieran comportamientos distintos; así, una misma operación puede cambiar
entre las distintas clases derivadas de una clase base, de modo que, dos
objetos que sean instancias de distintas clases, generarán resultados
diferentes a pesar de que la operación requerida por ambos tenga la misma denominación.
El polimorfismo
permite que un mismo mensaje global enviado a objetos de clases diferentes,
estos, actúen de formas diferentes; así por ejemplo, un mensaje "+" a
un objeto entero producirá una suma de dígitos, mientras que para un objeto
cadena, generaría una concatenación.
Este beneficio que
surge al separar la implementación del comportamiento permite a dos o más
objetos responder al mismo mensaje. Un método llamado nombre también podría ser
implementado en un objeto de la clase Curso.
Aunque la
implementación de este mensaje nombre devolvería el número de curso y su
nombre, su protocolo es el mismo que el mensaje nombre del objeto Alumno. El
polimorfismo permite a un objeto emisor comunicarse con diferentes objetos de
una manera consistente sin tener que preocuparse sobre las diferentes
implementaciones de un mensaje.
Otro ejemplo del
polimorfismo es la función de imprimir. Cada objeto que puede ser impreso debe
conocer como imprimirse. El mensaje es el mismo a todos los diferentes objetos:
print, pero la implementación sobre qué deben hacer para imprimirse a sí mismos
varía.
El objeto emisor no
necesita conocer cómo el objeto receptor implementa el mensaje. Sólo el objeto
receptor se preocupa de ello. Suponga que existe un método printPage en un
objeto Documento que tiene la responsabilidad de imprimir una página. Para
imprimir una página, el método printPage envía el mensaje print a cada objeto
de página. El objeto Documento no necesita conocer qué tipos de objetos están
en la página, sólo que cada uno soporta el comportamiento de la impresión.
Nuevos objetos
pueden ser agregados a la página sin afectar el método printPage. Este método
sigue enviando el mensaje print y el nuevo objeto provee su propio método print
en respuesta a ese mensaje.
El polimorfismo
permite al objeto emisor comunicarse con los objetos receptores sin tener que
comprender qué tipo de objeto es, siempre y cuando el objeto receptor soporte
los mensajes.
Este concepto muy vinculado con el anterior, consiste en esa ventaja en que la clase derivada, hereda características de los atributos y métodos de su clase primigenia; potenciando así su capacidad de simplificar la correspondiente codificación.
Por ejemplo, gracias
a la herencia, tanto motocicletas como automóviles, poseerán automáticamente
los mismos atributos y métodos de la clase automotor, razón por la cual al
codificar la esta última clase, luego solo será necesario codificar las
características particulares de las subclases motocicletas y automóviles.
El grado de dividir
una clase en subclases, más la característica de la herencia permite extender
con simplicidad y seguridad la definición primigenia de una clase, hasta
cualquier nivel de detalle requerido para un sistema en particular
Cada objeto creado
por un programador puede ser reaprovechado por otro, sin agregar modificaciones
y si tal objeto no se ajuste a sus necesidades, podrá aprovechar la alternativa
de generar una subclase del objeto con las características requerida,
aprovechando las heredadas por el objeto original.
La herencia permite
a una clase tener el mismo comportamiento que otra y extender o limitar ese
comportamiento para proveer una acción especial a una necesidad específica.
Suponga la siguiente
aplicación. La clase Graduado y la clase SinGraduar tienen comportamiento
similar, como por ejemplo, el manejo de nombre, dirección, carrera, promedio,
etc. En vez de colocar este comportamiento en ambas clases, el comportamiento
es colocado en una nueva clase llamada Alumno. Ambas clases Graduado y
SinGraduar se vuelven subclases de la clase Alumno, y ambas heredan
el comportamiento de Alumno.
Ambas clases
Graduado y SinGraduar pueden agregar comportamiento adicional que sea único a
ellas. Por ejemplo, Graduado puede ser tanto para un doctorado o una carrera de
postgrado. Por otro lado, la clase SinGraduar puede querer conocer cómo un
cierto alumno va en la carrera.
Las clases que
heredan de otras clases se llaman subclases. La clase, de la que una
subclase hereda, es llamada superclase. En el ejemplo, Alumno es una
superclase de Graduado y SinGraduar. Graduado y SinGraduar son subclases de
Alumno.
Esta propiedad
denominada también ocultación de la información, se refiere a la arquitectura
compleja del objeto, que integra en una unidad o cápsula, datos y programas
relacionados entre sí; haciéndolo inaccesible e impide que otros objetos,
usuarios, u otros programadores conozcan cómo está organizada la información
disponible.
Sin embargo, no es
imposible conocer lo necesario respecto del objeto y su contenido, puesto que,
para un programador autorizado, las peticiones de información al objeto podrán
efectuarse recurriendo a mensajes dirigidos a él, con la orden de realizar la
operación pertinente, de modo que la respuesta será la información buscada.
El encapsulamiento
hace que la POO sea apta para la reutilizar programas; pues, su estructura de
cápsula facilita enormemente que el objeto sea transportado a cualquier
ubicación diferente que precise de él y si su diseño fue eficiente, sus métodos
seguirán funcionando normalmente en su nuevo destino.
Es la forma en que
tanto los atributos, como los métodos se encuentran encerrados dentro de la
estructura del objeto, con apariencia no visibles desde el exterior. Y así al
estar ocultos, resultará que:
-
Una clase contiene
un número de variables que son interdependientes y deben tener un estado
consistente, luego, si un programador manipular esas variables directamente la
clase puede entrar en un estado inconsistente y funcionar inapropiadamente.
-
Cuando todas las
variables de la clase están ocultas y los métodos son la única posibilidad para
cambiar los valores de las variables -ocultas- en objetos de la clase todo
funciona bien.
-
Si mediante un
método tratamos de cambiar un valor para una variable y el valor no es correcto
el método tiene la facultad para rechazarlo.
-
Si las variables son
directamente manipuladas, sin intervención de los métodos de la clase, el
número de posibilidades que tienes que comprobar se vuelve inmanejable.
2.2. Metodologías de
desarrollo
2.2.1. RUP
El Proceso
Unificado de Rational (Rational Unified Process en inglés,
habitualmente resumido como RUP) es un proceso de desarrollo de software
desarrollado por la empresa Rational Software, actualmente propiedad de IBM.
Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología
estándar más utilizada para el análisis, diseño, implementación y documentación
de sistemas orientados a objetos.El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
También se conoce por este nombre al software, también desarrollado por Rational, que incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente.
Principios de desarrollo
El RUP está basado en 6 principios clave que son los siguientes:Adaptar el proceso
El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto u organización, el tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área subformal para hacer un proceso de satisfacción del software.Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados.Colaboración entre equipos
El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea Base) de la arquitectura.
Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requisitos.
En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura.
En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.
Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementación de la nueva versión del producto.
En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina varía.
Principales características
-
Forma
disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y
cómo)
-
Pretende
implementar las mejores prácticas en Ingeniería de Software
-
Desarrollo
iterativo
-
Administración
de requisitos
-
Uso
de arquitectura basada en componentes
-
Control
de cambios
-
Modelado
visual del software
-
Verificación
de la calidad del software
El RUP es un
producto de Rational (IBM). Se caracteriza por ser iterativo e incremental,
estar centrado en la arquitectura y guiado por los casos de uso. Incluye
artefactos (que son los productos tangibles del proceso como por ejemplo, el
modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña
una persona en un determinado momento, una persona puede desempeñar distintos
roles a lo largo del proceso).Fases
-
Establece
oportunidad y alcance
-
Identifica
las entidades externas o actores con las que se trata
-
Identifica
los casos de uso
RUP
comprende 2 aspectos importantes por los cuales se establecen las disciplinas:Proceso: Las etapas de esta sección son: (Revise nuevamente la gráfica)
-
Modelado
de negocio
-
Requisitos
-
Análisis
y Diseño
-
Implementación
-
Pruebas
-
Despliegue
Soporte: En esta parte nos
encontramos con las siguientes etapas:
-
Gestión
del cambio y configuraciones
-
Gestión
del proyecto
-
Entorno
La
estructura dinámica de RUP es la que permite que éste sea un proceso de
desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4
fases descritas anteriormente:
-
Inicio
(también llamado Incepción o Concepción).
-
Elaboración.
-
Desarrollo
(también llamado Implementación, Construcción).
-
Cierre
(también llamado Transición).
Fase de
Inicio: Esta fase tiene como propósito definir y acordar el alcance del
proyecto con los patrocinadores, identificar los riesgos asociados al proyecto,
proponer una visión muy general de la arquitectura de software y producir el
plan de las fases y el de iteraciones posteriores.Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.
Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.
Fase de Transición: El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.
Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura dinámica) realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:Inicio:
-
Documento
Visión
-
Diagramas
de caso de uso
-
Especificación
de Requisitos
-
Diagrama
de Requisitos
Elaboración:
-
Documento
Arquitectura que trabaja con las siguientes vistas:
-
Vista
Lógica
-
Diagrama
de clases
-
Modelo
E-R (Si el sistema así lo requiere)
-
Vista
de Implementación
-
Diagrama
de Secuencia
-
Diagrama
de estados
-
Diagrama
de Colaboración
Vista
Conceptual
-
Modelo
de dominio
Vista
física
-
Mapa
de comportamiento a nivel de hardware.
-
Diseño
y desarrollo de casos de uso, o flujos de casos de uso arquitectónicos
-
Pruebas
de los casos de uso desarrollados, que demuestran que la arquitectura
documentada responde adecuadamente a requerimientos funcionales y no
funcionales.
Construcción:
-
Especificación
de requisitos faltantes
-
Diseño
y desarrollo de casos de uso y/o flujos de acuerdo con la planeación iterativa
-
Pruebas
de los casos de uso desarrollados, y pruebas de regresión según sea el caso
Transición:
-
Pruebas
finales de aceptación
-
Puesta
en producción
-
Estabilización
2.2.2. XP
La
programación extrema o eXtreme Programming (XP) es una
metodología de desarrollo de la ingeniería de software formulada por Kent Beck,
autor del primer libro sobre la materia, Extreme Programming Explained:
Embrace Change (1999). Es el más destacado de los procesos ágiles de
desarrollo de software. Al igual que éstos, la programación extrema se
diferencia de las metodologías tradicionales principalmente en que pone más
énfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP
consideran que los cambios de requisitos sobre la marcha son un aspecto
natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que
ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la
vida del proyecto es una aproximación mejor y más realista que intentar definir
todos los requisitos al comienzo del proyecto e invertir esfuerzos después en
controlar los cambios en los requisitos.
Se
puede considerar la programación extrema como la adopción de las mejores
metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el
proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.
VALORES
-
Simplicidad
La
simplicidad es la base de la programación extrema. Se simplifica el diseño para
agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del
código junto a sucesivas modificaciones por parte de diferentes desarrolladores
hacen que la complejidad aumente exponencialmente.
Para
mantener la simplicidad es necesaria la refactorización del código, ésta es la
manera de mantener el código simple a medida que crece.
También
se aplica la simplicidad en la documentación, de esta manera el código debe
comentarse en su justa medida, intentando eso sí que el código esté
autodocumentado. Para ello se deben elegir adecuadamente los nombres de las
variables, métodos y clases. Los nombres largos no decrementan la eficiencia
del código ni el tiempo de desarrollo gracias a las herramientas de
autocompletado y refactorización que existen actualmente.
Aplicando
la simplicidad junto con la autoría colectiva del código y la programación por
parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo
conocerá más y mejor el sistema completo.
-
Comunicación
La
comunicación se realiza de diferentes formas. Para los programadores el código comunica
mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para
hacerlo inteligible. El código autodocumentado es más fiable que los
comentarios ya que éstos últimos pronto quedan desfasados con el código a
medida que es modificado. Debe comentarse sólo aquello que no va a variar, por
ejemplo el objetivo de una clase o la funcionalidad de un método.
Las
pruebas unitarias son otra forma de comunicación ya que describen el diseño de
las clases y los métodos al mostrar ejemplos concretos de cómo utilizar su
funcionalidad. Los programadores se comunican constantemente gracias a la
programación por parejas. La comunicación con el cliente es fluida ya que el
cliente forma parte del equipo de desarrollo. El cliente decide qué
características tienen prioridad y siempre debe estar disponible para
solucionar dudas.
-
Retroalimentación (feedback)
Al
estar el cliente integrado en el proyecto, su opinión sobre el estado del
proyecto se conoce en tiempo real.
Al
realizarse ciclos muy cortos tras los cuales se muestran resultados, se
minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda
a los programadores a centrarse en lo que es más importante.
Considérense
los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden
tirarse por la borda debido a cambios en los criterios del cliente o
malentendidos por parte del equipo de desarrollo. El código también es una
fuente de retroalimentación gracias a las herramientas de desarrollo. Por
ejemplo, las pruebas unitarias informan sobre el estado de salud del código.
Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos
a cambios recientes en el código.
-
Coraje o valentía
Muchas
de las prácticas implican valentía. Una de ellas es siempre diseñar y programar
para hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el
diseño y requerir demasiado tiempo y trabajo para implementar el resto del
proyecto. La valentía le permite a los desarrolladores que se sientan cómodos
con reconstruir su código cuando sea necesario. Esto significa revisar el
sistema existente y modificarlo si con ello los cambios futuros se
implementaran más fácilmente. Otro ejemplo de valentía es saber cuando desechar
un código: valentía para quitar código fuente obsoleto, sin importar cuanto
esfuerzo y tiempo se invirtió en crear ese código. Además, valentía significa
persistencia: un programador puede permanecer sin avanzar en un problema
complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, sólo
si es persistente.
-
Respeto
El
respeto se manifiesta de varias formas. Los miembros del equipo se respetan los
unos a otros, porque los programadores no pueden realizar cambios que hacen que
las pruebas existentes fallen o que demore el trabajo de sus compañeros. Los
miembros respetan su trabajo porque siempre están luchando por la alta calidad
en el producto y buscando el diseño óptimo o más eficiente para la solución a
través de la refactorización del código. Los miembros del equipo respetan el
trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo
y elevando el ritmo de producción en el equipo.
CARACTERISTICAS
-
Las
características fundamentales del método son:
-
Desarrollo
iterativo e incremental:
pequeñas mejoras, unas tras otras.
-
Pruebas
unitarias continuas,
frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se
aconseja escribir el código de la prueba antes de la codificación. Véase, por
ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a
Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas
inspiradas en JUnit, la cual, a su vez, se inspiró en SUnit, el primer
framework orientado a realizar tests, realizado para el lenguaje de
programación Smalltalk.
-
Programación
en parejas: se
recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un
mismo puesto. La mayor calidad del código escrito de esta manera -el código es
revisado y discutido mientras se escribe- es más importante que la posible pérdida
de productividad inmediata.
-
Frecuente
integración del equipo de programación con el cliente o usuario. Se
recomienda que un representante del cliente trabaje junto al equipo de
desarrollo.
-
Corrección
de todos los errores
antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
-
Refactorización
del código, es decir,
reescribir ciertas partes del código para aumentar su legibilidad y
mantenibilidad pero sin modificar su comportamiento. Las pruebas han de
garantizar que en la refactorización no se ha introducido ningún fallo.
-
Propiedad
del código compartida:
en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos
de trabajo distintos, este método promueve el que todo el personal pueda
corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de
regresión garantizan que los posibles errores serán detectados.
-
Simplicidad
en el código: es la
mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir
funcionalidad si es necesario. La programación extrema apuesta que es más
sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si
se requiere, que realizar algo complicado y quizás nunca utilizarlo.
La
simplicidad y la comunicación son extraordinariamente complementarias. Con más
comunicación resulta más fácil identificar qué se debe y qué no se debe hacer.
Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que
lleva a una comunicación más completa, especialmente si se puede reducir el
equipo de programadores.
2.2.3. SCRUM
Scrum es un marco de
trabajo para la gestión y desarrollo de software basada en un proceso iterativo
e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de
software.Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums.
Características de Scrum
Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.
Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.
Roles en Scrum
Roles Principales
Product Owner
El
Product Owner representa la voz del cliente. Se asegura de que el equipo
Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product
Owner escribe historias de usuario, las prioriza, y las coloca en el Product
Backlog.
ScrumMaster
(o Facilitador)
El
Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es
eliminar los obstáculos que impiden que el equipo alcance el objetivo del
sprint. El ScrumMaster no es el líder del equipo (porque ellos se
auto-organizan), sino que actúa como una protección entre el equipo y cualquier
influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum
se utiliza como es debido. El ScrumMaster es el que hace que las reglas se
cumplan.
Equipo de
desarrollo
El
equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3
a 9 personas con las habilidades transversales necesarias para realizar el
trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).
Roles Auxiliares
Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.
Stakeholders
(Clientes, Proveedores, Vendedores, etc)
Se
refiere a la gente que hace posible el proyecto y para quienes el proyecto
producirá el beneficio acordado que justifica su producción. Sólo participan
directamente durante las revisiones del sprint.
Administradores
(Managers)
Es
la gente que establece el ambiente para el desarrollo del producto.
Reuniones en Scrum
Daily Scrum o Stand-up meeting
Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama daily standup o Stand-up meeting. El scrum tiene unas guías específicas:
-
La
reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por
el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, etc).
-
Todos
son bienvenidos, pero sólo los responsables pueden hablar.
-
La
reunión tiene una duración fija de 15 minutos, de forma independiente del
tamaño del equipo.
-
Todos
los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)
-
La
reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
-
Durante
la reunión, cada miembro del equipo contesta a tres preguntas:3
-
¿Qué
has hecho desde ayer?
-
¿Qué
es lo que harás hasta la reunión de mañana?
-
¿Has
tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel
del ScrumMaster recordar estos impedimentos).
Scrum de Scrum
Cada día normalmente después del “Daily Scrum”:
-
Estas
reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose
especialmente en áreas de solapamiento e integración.
-
Asiste
una persona asignada por cada equipo.
La agenda
será la misma que la del Daily Scrum, añadiendo además las siguientes cuatro
preguntas:
-
¿Qué
ha hecho tu equipo desde nuestra última reunión?
-
¿Qué
hará tu equipo antes que nos volvamos a reunir?
-
¿Hay
algo que demora o estorba a tu equipo?
-
¿Estás
a punto de poner algo en el camino del otro equipo?
Reunión de Planificación del Sprint (Sprint Planning Meeting)
Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo.
-
Seleccionar
qué trabajo se hará
-
Preparar,
con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará
hacer el trabajo.
-
Identificar
y comunicar cuánto del trabajo es probable que se realice durante el actual
Sprint
-
Ocho
horas como límite
Al final del
ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint”
y la “Retrospectiva del Sprint”Reunión de Revisión del Sprint (Sprint Review Meeting)
-
Revisar
el trabajo que fue completado y no completado
-
Presentar
el trabajo completado a los interesados (alias “demo”)
-
El
trabajo incompleto no puede ser demostrado
-
Cuatro
horas como límite
Retrospectiva del Sprint (Sprint Retrospective)
Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.Sprint
El Sprint es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que la duración de los sprints sea constante y definida por el equipo con base en su propia experiencia. Se puede comenzar con una duración de sprint en particular (2 o 3 semanas) e ir ajustándolo con base en el ritmo del equipo, aunque sin relajarlo demasiado. Al final de cada sprint, el equipo deberá presentar los avances logrados, y el resultado obtenido es un producto potencialmente entregable al cliente. Asimismo, se recomienda no agregar objetivos al sprint o sprint backlog a menos que la falta de estos objetivos amenace al éxito del proyecto. La constancia permite la concentración y mejora la productividad del equipo de trabajo.Documentos
Product backlog
El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas según su retorno sobre la inversión (ROI). Es el qué va a ser construido. Es abierto y cualquiera puede modificarlo. Contiene estimaciones realizadas a grandes rasgos, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera menor tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto.Sprint backlog
El sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser divida en otras menores. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno.Burn down
La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.Scrum aplicado al desarrollo de software
Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1995 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 95. Más tarde, en 2001 serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de software scrum está considerado como modelo ágil por la Agile Alliance.
2.3. UML
Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language)
es el lenguaje de modelado de sistemas de software más conocido y utilizado en
la actualidad; está respaldado por el OMG (Object Management Group). Es un
lenguaje gráfico para visualizar, especificar, construir y documentar un
sistema. UML ofrece un estándar para describir un "plano" del sistema
(modelo), incluyendo aspectos conceptuales tales como procesos de negocio,
funciones del sistema, y aspectos concretos como expresiones de lenguajes de
programación, esquemas de bases de datos y compuestos reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se
puede aplicar en el desarrollo de software gran variedad de formas para dar
soporte a una metodología de desarrollo de software (tal como el Proceso
Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o
proceso usar.
UML
no puede compararse con la programación estructurada, pues UML significa
Lenguaje Unificado de Modelado, no es programación, solo se diagrama la
realidad de una utilización en un requerimiento. Mientras que, programación
estructurada, es una forma de programar como lo es la orientación a objetos,
sin embargo, la programación orientada a objetos viene siendo un complemento
perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a
objetos.
UML
cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos
de las entidades representadas.
Aunque
UML 2.1 nunca fue lanzado como una especificación formal, las versiones 2.1.1 y
2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML 2.3
fue lanzado oficialmente en mayo de 2010. UML 2.4.1 fue lanzado oficialmente en
agosto de 2011. UML 2.5 fue lanzado en octubre de 2012 como una versión
"En proceso" y todavía tiene que ser formalmente liberada.xcvb
Tipos de Diagramas de
UML
Estructura
-
Diagrama de clases
Es un diagrama de
estructura estática que describe la estructura de un sistema en el nivel de los
clasificadores (clases, interfaces, etc.) Muestra algunos clasificadores del
sistema, subsistema o componente, las relaciones entre los diferentes
clasificadores, sus atributos y operaciones, las limitaciones.
-
Diagrama de objetos
Se
define en el ahora obsoleto UML 1.4.2 especificación como "un gráfico de
los casos, incluso los objetos y valores de datos un diagrama de objeto
estático es un ejemplo de un diagrama de clases. Muestra una instantánea del
estado detallado de un sistema en un punto en el tiempo. “Asimismo, señaló que
el diagrama objeto es "un diagrama de clases con los objetos y las clases
no". Especificación UML 2.4, simplemente no da ninguna definición de los
diagramas de objetos.
Algunos
de los elementos principales de diagramas de objetos son nombrados y
especificaciones anónimos instancia de los objetos, las franjas horarias con
las especificaciones de valor, y enlaces (instancias de la asociación).
-
Diagrama de componentes
Un
diagrama de componentes muestra los
componentes y las dependencias entre ellos. Este tipo de diagramas se utiliza
para el Desarrollo basado en componentes (CBD), para describir los sistemas con
arquitectura orientada a servicios (SOA).
-
Diagrama de estructura compuesta
Se
utiliza para mostrar el resultado de:
-
Estructura
interna de un clasificador
-
Un
comportamiento de una colaboración
-
Estructura
Interna diagramas muestran la estructura interna de un clasificador - una
descomposición del clasificador en sus propiedades, partes y relaciones.
-
Diagrama
de colaboración uso muestra los objetos en un sistema de cooperar entre sí para
producir un comportamiento del sistema.
Diagrama
de paquetes
Muestra
los paquetes y las relaciones entre los paquetes.
Diagrama
de modelo UML es diagrama de la estructura auxiliar que muestra una cierta
abstracción o punto de vista específico de un sistema, para describir los
aspectos arquitectónicos, lógicos o de comportamiento del sistema. Se podría
mostrar, por ejemplo, la arquitectura de un multi-capa (también conocido como
de varios niveles) la aplicación - de varias capas del modelo de aplicación.
Diagrama de despliegue
Un
diagrama de despliegue muestra la arquitectura del sistema de despliegue
(distribución) de los artefactos de software a los objetivos de despliegue.
Teniendo
en cuenta que los componentes fueron enviados directamente a los nodos de
diagramas UML 1.x de implementación. En UML artefactos 2.x se implementan en
los nodos, y los componentes de artefactos manifestar podrían: poner en
práctica). Los componentes se implementan en los nodos de forma indirecta a
través de artefactos.
Nivel
de especificación de diagrama de implementación (también llamado nivel de tipo
de) muestra una cierta visión general de despliegue de artefactos a los
destinos de implementación, sin hacer referencia a casos específicos de
artefactos o nodos.
Nivel
de la instancia diagrama de despliegue muestra el despliegue de los casos de
artefactos a los casos específicos de los objetivos de despliegue. Podría ser
utilizado, por ejemplo, para mostrar las diferencias en las implementaciones de
los entornos de desarrollo, ensayo o de producción con los nombres / IDS de
construcción específica o los servidores o dispositivos de despliegue.
Aunque
los diagramas de componentes muestran los componentes y las relaciones entre
los componentes y los clasificadores y los diagramas de despliegue
implementaciones de los artefactos a los destinos de implementación, en algunos
diagramas falta intermedia es el diagrama de la manifestación que se utilizará
para mostrar la manifestación (la aplicación) de los componentes de los
artefactos y la estructura interna de los artefactos.
Debido
a que los diagramas de la manifestación no están definidos por UML 2.4 pliego
de condiciones, la manifestación de los componentes de los artefactos se pudo
demostrar ya sea utilizando diagramas de componentes o diagramas de despliegue.
Diagramas
de despliegue también se podría utilizar para mostrar la arquitectura de red
lógica o física del sistema. Este tipo de diagramas de despliegue - no es
formalmente definido en UML 2.4 - que se podría llamar diagramas de
arquitectura de red.
Comportamiento
Diagrama
de casos de uso
En
el Lenguaje de Modelado Unificado, un diagrama
de casos de uso es una especie de diagrama de comportamiento UML
mejorado. El Lenguaje de Modelado Unificado (UML), define una notación gráfica
para representar casos de uso llamada modelo de casos de uso. UML no define
estándares para que el formato escrito describa los casos de uso, y así mucha
gente no entiende que esta notación gráfica define la naturaleza de un caso de
uso; sin embargo una notación gráfica puede solo dar una vista general simple
de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos
de uso. Mientras los dos conceptos están relacionados, los casos de uso son
mucho más detallados que los diagramas de casos de uso.
-
La
descripción escrita del comportamiento del sistema al afrontar una tarea de
negocio o un requisito de negocio. Esta descripción se enfoca en el valor
suministrado por el sistema a entidades externas tales como usuarios humanos u
otros sistemas.
-
La
posición o contexto del caso de uso entre otros casos de uso. Dado que es un
mecanismo de organización, un conjunto de casos de uso coherente y consistente
promueven una imagen fácil de comprender del comportamiento del sistema, un
entendimiento común entre el cliente/propietario/usuario y el equipo de
desarrollo.
La
interacción entre actores no se ve en el diagrama de casos de uso. Si
esta interacción es esencial para una descripción coherente del comportamiento
deseado, quizás los límites del sistema o del caso de uso deban de ser
re-examinados. Alternativamente, la interacción entre actores puede ser parte
de suposiciones usadas en el caso de uso. Sin embargo, los actores son una
especie de rol, un usuario humano u otra entidad externa puede jugar varios
papeles o roles.
Relaciones de Casos de Uso
Las
tres relaciones principales entre los casos de uso son soportadas por el
estándar UML, el cual describe notación gráfica para esas relaciones. Veamos
una revisión de ellas a continuación:
Inclusión (include o use)
Es
una forma de interacción o creación, un caso de uso dado puede
"incluir" otro caso de uso. El primer caso de uso a menudo depende
del resultado del caso de uso incluido. Esto es útil para extraer
comportamientos verdaderamente comunes desde múltiples casos de uso a una
descripción individual, desde el caso de uso. El estándar de Lenguaje de
Modelado Unificado de OMG define una notación gráfica para realizar diagramas
de casos de uso, pero no el formato para describir casos de uso. Mucha gente
sufre la equivocación pensando que un caso de uso es una notación gráfica (o es
su descripción). Mientras la notación gráfica y las descripciones esto no
sirve.
Extensión (Extend)
Es
otra forma de interacción, un caso de uso dado (la extensión) puede extender
a otro. Esta relación indica que el comportamiento del caso de la extensión se
utiliza en casos de uso, un caso de uso a otro caso siempre debe tener
extensión o inclusión. El caso de uso extensión puede ser insertado en el caso
de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta
abierta con línea discontinua, desde el caso de uso extensión al caso de uso
extendido, con la etiqueta «extend». Esto puede ser útil para
lidiar con casos especiales, o para acomodar nuevos requisitos durante el
mantenimiento del sistema y su extensión.
"La
extensión, es el conjunto de objetos a los que se aplica un concepto. Los
objetos de la extensión son los ejemplos o instancias de los conceptos."
Que documentan el comportamiento de un sistema desde el punto de vista de un
usuario
Generalización
"Entonces
la Generalización es la actividad de identificar elementos en común entre
conceptos y definir las relaciones de una superclase (concepto general) y
subclase (concepto especializado). Es una manera de construir clasificaciones
taxonómicas entre conceptos que entonces se representan en jerarquías de
clases. Las subclases conceptuales son conformes con las superclases
conceptuales en cuanto a la intención y extensión."
En
la tercera forma de relaciones entre casos de uso, existe una relación
generalización/especialización. Un caso de uso dado puede estar en una forma
especializada de un caso de uso existente. La notación es una línea sólida
terminada en un triángulo dibujado desde el caso de uso especializado al caso
de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases,
en la práctica puede ser útil factorizar comportamientos comunes, restricciones
al caso de uso general, describirlos una vez, y enfrentarse a los detalles
excepcionales en los casos de uso especializados.
Diagrama
de actividades
El diagrama
de flujo o diagrama de actividades es la representación gráfica del
algoritmo o proceso. Se utiliza en disciplinas como programación, economía,
procesos industriales y psicología cognitiva.En Lenguaje Unificado de Modelado (UML), un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un diagrama de actividades muestra el flujo de control general.
En SysML el diagrama de actividades ha sido extendido para indicar flujos entre pasos que mueven elementos físicos (e.g., gasolina) o energía (e.g., presión). Los cambios adicionales permiten al diagrama soportar mejor flujos de comportamiento y datos continuos.
Estos diagramas utilizan símbolos con significados definidos que representan los pasos del algoritmo, y representan el flujo de ejecución mediante flechas que conectan los puntos de inicio y de fin de proceso.
Diagrama
de estado
Los diagramas
de estado muestran el conjunto de estados por los cuales pasa un objeto
durante su vida en una aplicación en respuesta a eventos (por ejemplo, mensajes
recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones.
También ilustran qué eventos pueden cambiar el estado de los objetos de la
clase. Normalmente contienen: estados y transiciones. Como los estados y las
transiciones incluyen, a su vez, eventos, acciones y actividades, vamos a ver
primero sus definiciones.Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas explicativas y restricciones.
Interacción
Diagrama
de secuencia
El
diagrama de secuencia es un tipo de diagrama usado para modelar interacción
entre objetos en un sistema según UML.
Un
diagrama de secuencia muestra la interacción de un conjunto de objetos en una
aplicación a través del tiempo y se modela para cada caso de uso. Mientras que
el diagrama de casos de uso permite el modelado de una vista business del
escenario, el diagrama de secuencia contiene detalles de implementación del
escenario, incluyendo los objetos y clases que se usan para implementar el
escenario y mensajes intercambiados entre los objetos.
Típicamente
se examina la descripción de un caso de uso para determinar qué objetos son
necesarios para la implementación del escenario. Si se dispone de la
descripción de cada caso de uso como una secuencia de varios pasos, entonces se
puede "caminar sobre" esos pasos para descubrir qué objetos son
necesarios para que se puedan seguir los pasos. Un diagrama de secuencia
muestra los objetos que intervienen en el escenario con líneas discontinuas
verticales, y los mensajes pasados entre los objetos como flechas horizontales.
Tipos
de mensajes
Existen
dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se
corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto
que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de
mensajes se representan con flechas con la cabeza llena. Los mensajes
asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro
de la secuencia. Se representan con flechas con la cabeza abierta.
También
se representa la respuesta a un mensaje con una flecha discontinua.
Pueden
ser usados en dos formas
De instancia: describe un escenario
específico (un escenario es una instancia de la ejecución de un caso de uso).
Genérico: describe la interacción para
un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y
bucles.
Estructura
Los
mensajes se dibujan cronológicamente desde la parte superior del diagrama a la
parte inferior; la distribución horizontal de los objetos es arbitraria.
Durante el análisis inicial, el modelador típicamente coloca el nombre
'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño,
el nombre 'business' es reemplazado con el nombre del método que está siendo
llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la
definición de la clase instanciada por el objeto en la recepción final del
mensaje.
Diagrama
de colaboración
Un diagrama
de colaboración en las versiones de UML 1.x es esencialmente un diagrama
que muestra interacciones organizadas alrededor de los roles. A diferencia de
los diagramas de secuencia, los diagramas de colaboración, también llamados
diagramas de comunicación, muestran explícitamente las relaciones de los roles.
Por otra parte, un diagrama de comunicación no muestra el tiempo como una
dimensión aparte, por lo que resulta necesario etiquetar con números de
secuencia tanto la secuencia de mensajes como los hilos concurrentes.
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. Dicha implementación es llamada "enlace".
Un diagrama
de comunicación es también un diagrama de clases que contiene roles de
clasificador y roles de asociación en lugar de sólo clasificadores y
asociaciones. Los roles de clasificador y los de asociación describen la
configuración de los objetos y de los enlaces que pueden ocurrir cuando se
ejecuta una instancia de la comunicación. Cuando se instancia una comunicación,
los objetos están ligados a los roles de clasificador y los enlaces a los roles
de asociación. El rol de asociación puede ser desempeñado por varios tipos de
enlaces temporales, tales como argumentos de procedimiento o variables locales
del procedimiento. Los símbolos de enlace pueden llevar estereotipos para
indicar enlaces temporales.
2.4. MySQL
MySQL es un sistema de gestión de bases de datos relacional,
multihilo y multiusuario con más de seis millones de instalaciones. MySQL AB —desde
enero de 2008 una subsidiaria de Sun Microsystems y ésta a su vez de Oracle
Corporation desde abril de 2009— desarrolla MySQL como software libre en un
esquema de licenciamiento dual.
Por
un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta
licencia, pero para aquellas empresas que quieran incorporarlo en productos
privativos deben comprar a la empresa una licencia específica que les permita
este uso. Está desarrollado en su mayor parte en ANSI C.
Al
contrario de proyectos como Apache, donde el software es desarrollado por una
comunidad pública y los derechos de autor del código están en poder del autor
individual, MySQL es patrocinado por una empresa privada, que posee el
copyright de la mayor parte del código.
Esto
es lo que posibilita el esquema de licenciamiento anteriormente mencionado.
Además de la venta de licencias privativas, la compañía ofrece soporte y
servicios. Para sus operaciones contratan trabajadores alrededor del mundo que
colaboran vía Internet. MySQL AB fue fundado por David Axmark, Allan Larsson y
Michael Widenius.
Características
Inicialmente,
MySQL carecía de elementos considerados esenciales en las bases de datos
relacionales, tales como integridad referencial y transacciones. A pesar de
ello, atrajo a los desarrolladores de páginas web con contenido dinámico,
justamente por su simplicidad.
Poco
a poco los elementos de los que carecía MySQL están siendo incorporados tanto
por desarrollos internos, como por desarrolladores de software libre. Entre las
características disponibles en las últimas versiones se puede destacar:
-
Amplio
subconjunto del lenguaje SQL. Algunas extensiones son incluidas igualmente.
-
Disponibilidad
en gran cantidad de plataformas y sistemas.
-
Posibilidad
de selección de mecanismos de almacenamiento que ofrecen diferente velocidad de
operación, soporte físico, capacidad, distribución geográfica, transacciones...
-
Transacciones
y claves foráneas.
-
Conectividad
segura.
-
Replicación.
-
Búsqueda
e indexación de campos de texto.
MySQL
es un sistema de administración de bases de datos. Una base de datos es una
colección estructurada de tablas que contienen datos. Esta puede ser desde una
simple lista de compras a una galería de pinturas o el vasto volumen de
información en una red corporativa. Para agregar, acceder a y procesar datos
guardados en un computador, usted necesita un administrador como MySQL Server.
Dado que los computadores son muy buenos manejando grandes cantidades de
información, los administradores de bases de datos juegan un papel central en
computación, como aplicaciones independientes o como parte de otras
aplicaciones.
MySQL
es un sistema de administración relacional de bases de datos. Una base de datos
relacional archiva datos en tablas separadas en vez de colocar todos los datos
en un gran archivo. Esto permite velocidad y flexibilidad. Las tablas están
conectadas por relaciones definidas que hacen posible combinar datos de
diferentes tablas sobre pedido.
MySQL
es software de fuente abierta. Fuente abierta significa que es posible para
cualquier persona usarlo y modificarlo. Cualquier persona puede bajar el código
fuente de MySQL y usarlo sin pagar. Cualquier interesado puede estudiar el
código fuente y ajustarlo a sus necesidades. MySQL usa el GPL (GNU General
Public License) para definir qué puede hacer y qué no puede hacer con el
software en diferentes situaciones. Si usted no se ajusta al GPL o requiere
introducir código MySQL en aplicaciones comerciales, usted puede comprar una
versión comercial licenciada.
2.5. SQL Server
Microsoft
SQL Server es un
sistema para la gestión de bases de datos producido por Microsoft basado en el
modelo relacional. Sus lenguajes para consultas son T-SQL y ANSI SQL. Microsoft
SQL Server constituye la alternativa de Microsoft a otros potentes sistemas
gestores de bases de datos como son Oracle, PostgreSQL
o MySL.
Características de Microsoft SQL Server
-
Soporte
de transacciones.
-
Soporta
procedimientos almacenados.
-
Incluye
también un entorno gráfico de administración, que permite el uso de comandos
DDL y DML gráficamente.
-
Permite
trabajar en modo cliente-servidor, donde la información y datos se alojan en el
servidor y los terminales o clientes de la red sólo acceden a la información.
-
Además
permite administrar información de otros servidores de datos.
Este sistema
incluye una versión reducida, llamada MSDE con el mismo motor de base de datos
pero orientado a proyectos más pequeños, que en sus versiones 2005 y 2008 pasa
a ser el SQL Express Edition, que se distribuye en forma gratuita.Es común desarrollar completos proyectos complementando Microsoft SQL Server y Microsoft Access a través de los llamados ADP (Access Data Project). De esta forma se completa la base de datos (Microsoft SQL Server), con el entorno de desarrollo (VBA Access), a través de la implementación de aplicaciones de dos capas mediante el uso de formularios Windows.
En el manejo de SQL mediante líneas de comando se utiliza el SQLCMD
Para el desarrollo de aplicaciones más complejas (tres o más capas), Microsoft SQL Server incluye interfaces de acceso para varias plataformas de desarrollo, entre ellas .NET, pero el servidor sólo está disponible para Sistemas Operativos
Programación
T-SQL
Artículo
principal: T-SQL.
T-SQL
(Transact-SQL) es el principal medio de interacción con el Servidor. Permite
realizar las operaciones claves en SQL Server, incluyendo la creación y
modificación de esquemas de la base de datos, la introducción y edición de los
datos en la base de datos, así como la administración del servidor como tal. Esto
se realiza mediante el envío de sentencias de T-SQL y declaraciones que son
procesadas por el servidor y los resultados (o errores) regresan a la
aplicación cliente.Cliente Nativo de SQL
Cliente Nativo de SQL es la biblioteca de acceso a datos para los clientes de Microsoft SQL Server versión 2005 en adelante. Implementa nativamente soporte para las características de SQL Server, incluyendo la ejecución de la secuencia de datos tabular, soporte para bases de datos en espejo de SQL Server, soporte completo para todos los tipos de datos compatibles con SQL Server, conjuntos de operaciones asíncronas, las notificaciones de consulta, soporte para cifrado, así como recibir varios conjuntos de resultados en una sola sesión de base de datos. Cliente Nativo de SQL se utiliza como extensión de SQL Server plug-ins para otras tecnologías de acceso de datos, incluyendo ADO u OLE DB. Cliente Nativo de SQL puede también usarse directamente, pasando por alto las capas de acceso de datos.Desventajas
-
MSSQL
usa Address Windowing Extension (AWE) para hacer el direccionamiento de
64-bit. Esto le impide usar la administración dinámica de memoria, y sólo le
permite alojar un máximo de 64 GB de memoria compartida.
-
MSSQL
no maneja compresión de datos (excepto la versión 2008 Enterprise Edition, que
sí lo hace), por lo que las bases de datos pueden llegar a ocupar mucho espacio
en disco.
-
MSSQL
requiere de un sistema operativo Microsoft Windows, por lo que no puede
instalarse, por ejemplo, en servidores Linux, por esta razón.
2.6. PostgreSQL
PostgreSQL es un SGBD
relacional orientado a objetos y libre, publicado bajo la licencia BSD.Como muchos otros proyectos de código abierto, el desarrollo de PostgreSQL no es manejado por una empresa y/o persona, sino que es dirigido por una comunidad de desarrolladores que trabajan de formas desinteresadas, altruistas, libres y/o apoyadas por organizaciones comerciales. Dicha comunidad es denominada el PGDG (PostgreSQL Global Development Group).
Características
Algunas de sus principales características son, entre otras:Alta concurrencia
Mediante un sistema denominado MVCC (Acceso concurrente multiversión, por sus siglas en inglés) PostgreSQL permite que mientras un proceso escribe en una tabla, otros accedan a la misma tabla sin necesidad de bloqueos. Cada usuario obtiene una visión consistente de lo último a lo que se le hizo commit. Esta estrategia es superior al uso de bloqueos por tabla o por filas común en otras bases, eliminando la necesidad del uso de bloqueos explícitos.Amplia variedad de tipos nativos
PostgreSQL provee nativamente soporte para:
-
Números
de precisión arbitraria.
-
Texto
de largo ilimitado.
-
Figuras
geométricas (con una variedad de funciones asociadas).
-
Direcciones
IP (IPv4 e IPv6).
-
Bloques
de direcciones estilo CIDR.
-
Direcciones
MAC.
-
Arrays
Adicionalmente
los usuarios pueden crear sus propios tipos de datos, los que pueden ser por
completo indexables gracias a la infraestructura GiST de PostgreSQL. Algunos
ejemplos son los tipos de datos GIS creados por el proyecto PostGIS.Otras características
-
Claves
ajenas también denominadas Llaves ajenas o Claves Foráneas (foreign keys).
-
Disparadores
(triggers): Un disparador o trigger se define como una acción
específica que se realiza de acuerdo a un evento, cuando éste ocurra dentro de
la base de datos. En PostgreSQL esto significa la ejecución de un procedimiento
almacenado basado en una determinada acción sobre una tabla específica. Ahora
todos los disparadores se definen por seis características:
-
El
nombre del disparador o trigger
-
El
momento en que el disparador debe arrancar
-
El
evento del disparador deberá activarse sobre...
-
La
tabla donde el disparador se activará
-
La
frecuencia de la ejecución
-
La
función que podría ser llamada
-
Entonces
combinando estas seis características, PostgreSQL le permitirá crear una amplia
funcionalidad a través de su sistema de activación de disparadores (triggers).
-
Vistas.
-
Integridad
transaccional.
-
Herencia
de tablas.
-
Tipos
de datos y operaciones geométricas.
-
Soporte
para transacciones distribuidas. Permite a PostgreSQL integrarse en un sistema
distribuido formado por varios recursos (p.ej, una base de datos PostgreSQL,
otra Oracle, una cola de mensajes IBM MQ JMS y un ERP SAP) gestionado por un
servidor de aplicaciones donde el éxito ("commit") de la transacción
globlal es el resultado del éxito de las transacciones locales.
Funciones
Bloques de código que se ejecutan en el servidor. Pueden ser escritos en varios lenguajes, con la potencia que cada uno de ellos da, desde las operaciones básicas de programación, tales como bifurcaciones y bucles, hasta las complejidades de la programación orientada a objetos o la programación funcional.Los disparadores (triggers en inglés) son funciones enlazadas a operaciones sobre los datos.
-
Algunos
de los lenguajes que se pueden usar son los siguientes:
-
Un
lenguaje propio llamado PL/PgSQL (similar al PL/SQL de oracle).
-
C.
-
C++.
-
Java
PL/Java web.
-
PL/Perl.
-
plPHP.
-
PL/Python.
-
PL/Ruby.
-
PL/sh.
-
PL/Tcl.
-
PL/Scheme.
-
Lenguaje
para aplicaciones estadísticas R por medio de PL/R.
PostgreSQL
soporta funciones que retornan "filas", donde la salida puede
tratarse como un conjunto de valores que pueden ser tratados igual a una fila
retornada por una consulta (query en inglés).Las funciones pueden ser definidas para ejecutarse con los derechos del usuario ejecutor o con los derechos de un usuario previamente definido. El concepto de funciones, en otros DBMS, son muchas veces referidas como "procedimientos almacenados" (stored procedures en inglés).
sarrollo de PostgreSQL no es manejado por una empresa y/o persona, sino que es dirigido por una comunidad de desarrolladores que trabajan de forma desinteresada, altruista, libre y/o apoyados por organizaciones comerciales. Dicha comunidad es denominada el PGDG (PostgreSQL Global Development Group).
