Un wiki es un sitio web cuyas páginas pueden ser editadas por múltiples usuarios a través del navegador. Los wikis permiten la co-autoría de documentos mediante un lenguaje de marcado sencillo y facilitan la creación de hipervínculos entre páginas. El wiki más grande es la Wikipedia, pero los wikis también se usan para documentación de software y colaboración dentro de grupos.

1. Wiki
De Wikipedia, la enciclopedia libre
Saltar a navegación, búsqueda
Un wiki o una wiki (del hawaiano wiki, ‘rápido’)[1] es un sitio web cuyas páginas pueden ser editadas
por múltiples voluntarios a través del navegador web. Los usuarios pueden crear, modificar o borrar un
mismo texto que comparten. Los textos o «páginas wiki» tienen títulos únicos. Si se escribe el título de
una «página wiki» en algún lugar del wiki entre dobles corchetes (...), esta palabra se convierte en un
«enlace web» a la página wiki.
En una página sobre «alpinismo», por ejemplo, puede haber una palabra como «piolet» o «brújula» que
esté marcada como palabra perteneciente a un título de página wiki. La mayor parte de las
implementaciones de wikis indican en el URL de la página el propio título de la página wiki (en
Wikipedia ocurre así: http://es.wikipedia.org/wiki/Alpinismo), facilitando el uso y comprensibilidad del
link fuera del propio sitio web. Además, esto permite formar en muchas ocasiones una coherencia
terminológica, generando una ordenación natural del contenido.
La aplicación de mayor peso y a la que le debe su mayor fama hasta el momento ha sido la creación de
enciclopedias colectivas, género al que pertenece la Wikipedia. Existen muchas otras aplicaciones más
cercanas a la coordinación de informaciones y acciones, o la puesta en común de conocimientos o
textos dentro de grupos.
La mayor parte de los wikis actuales conservan un historial de cambios que permite recuperar
fácilmente cualquier estado anterior y ver qué usuario hizo cada cambio, lo cual facilita enormemente
el mantenimiento conjunto y el control de usuarios nocivos. Habitualmente, sin necesidad de una
revisión previa, se actualiza el contenido que muestra la página wiki editada.
historia
El origen de los wikis está en la comunidad de patrones de diseño, cuyos integrantes los utilizaron para
escribir y discutir patrones de programación. El primer WikiWikiWeb fue creado por Ward
Cunningham, quien inventó y dio nombre al concepto wiki, y produjo la primera implementación de un
servidor WikiWiki para el repositorio de patrones del Portland (Portland Pattern Repository) en 1995.
En palabras del propio Cunningham, un wiki es «la base de datos en línea más simple que pueda
funcionar» (the simplest online database that could possibly work).[2] El wiki de Ward aún es uno de
los sitios wiki más populares.
En enero de 2001, los fundadores del proyecto de enciclopedia Nupedia, Jimbo Wales y Larry Sanger,
decidieron utilizar un wiki como base para el proyecto de enciclopedia Wikipedia. Originalmente se
usó el software UseMod, pero luego crearon un software propio, MediaWiki, que ha sido adoptado
después por muchos otros wikis.
Actualmente, el wiki más grande que existe es la versión en inglés de Wikipedia, seguida por varias
otras versiones del proyecto. Los wikis ajenos a Wikipedia son mucho más pequeños y con menor
participación de usuarios, generalmente debido al hecho de ser mucho más especializados. Es muy
frecuente, por ejemplo, la creación de wikis para proveer de documentación a programas informáticos,

2. especialmente los desarrollados en software libre.
Ventajas
La principal utilidad de un wiki es que permite crear y mejorar las páginas de forma instantánea, dando
una gran libertad al usuario, y por medio de una interfaz muy simple. Esto hace que más gente participe
en su edición, a diferencia de los sistemas tradicionales, donde resulta más difícil que los usuarios del
sitio contribuyan a mejorarlo.
Dada la gran rapidez con la que se actualizan los contenidos, la palabra «wiki» adopta todo su sentido.
El «documento» de hipertexto resultante, denominado también «wiki» o «WikiWikiWeb», lo produce
típicamente una comunidad de usuarios. Muchos de estos lugares son inmediatamente identificables
por su particular uso de palabras en mayúsculas, o texto capitalizado - uso que consiste en poner en
mayúsculas las iniciales de las palabras de una frase y eliminar los espacios entre ellas - como por
ejemplo en EsteEsUnEjemplo. Esto convierte automáticamente a la frase en un enlace. Este wiki, en sus
orígenes, se comportaba de esa manera, pero actualmente se respetan los espacios y sólo hace falta
encerrar el título del enlace entre dos corchetes.
Características
Un wiki permite que se escriban artículos colectivamente (co-autoría) por medio de un lenguaje de
wikitexto editado mediante un navegador. Una página wiki singular es llamada «página wiki», mientras
que el conjunto de páginas (normalmente interconectadas mediante hipervínculos) es «el wiki». Es
mucho más sencillo y fácil de usar que una base de datos.
Una característica que define la tecnología wiki es la facilidad con que las páginas pueden ser creadas y
actualizadas. En general no hace falta revisión para que los cambios sean aceptados. La mayoría de
wikis están abiertos al público sin la necesidad de registrar una cuenta de usuario. A veces se requiere
hacer login para obtener una cookie de «wiki-firma», para autofirmar las ediciones propias. Otros wikis
más privados requieren autenticación de usuario.
Páginas y edición
En un wiki tradicional existen tres representaciones por cada página:
• El «código fuente», que pueden editar los usuarios. Es el formato almacenado localmente en el
servidor. Normalmente es texto plano, sólo es visible para el usuario cuando lo muestra la
operación «Editar».
• Una plantilla (en ocasiones generada internamente) que define la disposición y elementos
comunes de todas las páginas.
• El código HTML, puesto en tiempo real por el servidor a partir del código fuente cada vez que
la página se solicita.
El código fuente es potenciado mediante un lenguaje de marcado simplificado para hacer varias
convenciones visuales y estructurales. Por ejemplo, el uso del asterisco «*» al empezar una línea de
texto significa que se generará una lista desordenada de elementos (bullet-list). El estilo y la sintaxis
pueden variar en función de la implementación, alguna de las cuales también permite etiquetas HTML.

3. ¿Por qué no HTML?
La razón de este diseño es que el HTML, con muchas de sus etiquetas crípticas, no es fácil de leer por
usuarios no técnicos. Hacer visibles las etiquetas de HTML provoca que el texto en sí sea difícil de leer
y editar para la mayoría de usuarios. Por lo tanto, se promueve el uso de edición en texto llano con
convenciones para la estructura y el estilo fáciles de comprender.
A veces es beneficioso que los usuarios no puedan usar ciertas funcionalidades que el HTML permite,
tales como JavaScript, CSS y XML. Se consigue consistencia en la visualización, así como seguridad
extra para el usuario. En muchas inserciones de wiki, un hipervínculo es exactamente tal como se
muestra, al contrario de lo que ocurre en el HTML.
Estándar
Durante años el estándar de facto fue la sintaxis del WikiWikiWeb original. Actualmente las
instrucciones de formateo son diferentes dependiendo del motor del wiki. Los wikis simples permiten
sólo formateo de texto básico, mientras que otros más complejos tienen soporte para cuadros,
imágenes, fórmulas e incluso otros elementos más interactivos tales como encuestas y juegos. Debido a
la dificultad de usar varias sintaxis, se están haciendo esfuerzos para definir un estándar de marcado
(ver esfuerzos de Meatball y Tikiwiki).
Vincular y crear páginas
Los wikis son un auténtico medio de hipertexto, con estructuras de navegación no lineal. Cada página
contiene un gran número de vínculos a otras páginas. En grandes wikis existen las páginas de
navegación jerárquica, normalmente como consecuencia del proceso de creación original, pero no es
necesario usarlas. Los vínculos se usan con una sintaxis específica, el «patrón de vínculos».
CamelCase
Originalmente gran parte de wikis usaban CamelCase como patrón de vínculos, poniendo frases sin
espacios y poniendo la primera letra de cada palabra en mayúscula (por ejemplo, la palabra
«CamelCase»). Este método es muy fácil, pero hace que los links se escriban de una manera que se
desvía de la escritura estándar. Los wikis basados en CamelCase se distinguen instantáneamente por los
links con nombres como: «TablaDeContenidos», «PreguntasFrecuentes». Por consiguiente,
comenzaron a desarrollarse otras soluciones.
Vínculos libres
Los «vínculos libres», usados por primera vez por Cliki, usan un formato tipo _(vínculo). Por ejemplo,
_(Tabla de contenidos), _(Preguntas frecuentes). Otros motores de wiki usan distintos signos de
puntuación.
Interwiki
Interwiki permite vínculos entre distintas comunidades wiki.
Las nuevas páginas se crean simplemente creando un vínculo apropiado. Si el vínculo no existe, se
acostumbra a destacar como «vínculo roto». Siguiendo el vínculo se abre una página de edición, que
permite al usuario introducir el texto para la nueva página wiki. Este mecanismo asegura que casi no se
generen páginas huérfanas (es decir, páginas que no tienen ningún vínculo apuntando a ellas). Además

4. se mantiene un nivel alto de conectividad.
Búsqueda
La mayoría de wikis permite al menos una búsqueda por títulos, a veces incluso una búsqueda por texto
completo. La escalabilidad de la búsqueda depende totalmente del hecho de que el motor del wiki
disponga de una base de datos o no: es necesario el acceso a una base de datos indexada para hacer
búsquedas rápidas en wikis grandes. En Wikipedia el botón «Ir» permite a los lectores ir directamente a
una página que concuerde con los criterios de búsqueda. El motor de MetaWiki se creó para habilitar
búsquedas en múltiples wikis.
Control de cambios
Los wikis suelen diseñarse con la filosofía de aumentar la facilidad de corrección de los errores, y no la
de reducir la dificultad de cometerlos. Los wikis son muy abiertos, pero aun así proporcionan maneras
de verificar la validez de los últimos cambios al contenido de las páginas. En casi todos los wikis hay
una página específica, «Cambios recientes», que enumera las ediciones más recientes de artículos, o
una lista con los cambios hechos durante un período. Algunos wikis pueden filtrar la lista para deshacer
cambios hechos por vandalismo.
Desde el registro de cambios suele haber otras funciones: el «Historial de revisión» muestra versiones
anteriores de la página, y la característica «diff» destaca los cambios entre dos revisiones. Usando el
historial, un editor puede ver y restaurar una versión anterior del artículo, y la característica «diff» se
puede usar para decidir cuándo eso es necesario. Un usuario normal del wiki puede ver el «diff» de una
edición listada en «Cambios recientes» y, si es una edición inaceptable, consultar el historial y restaurar
una versión anterior. Este proceso es más o menos complicado, según el software que use el wiki.
En caso de que las ediciones inaceptables se pasen por alto en «Cambios recientes», algunos motores
de wiki proporcionan control de contenido adicional. Se pueden monitorizar para asegurar que una
página o un conjunto de páginas mantienen la calidad. A un usuario dispuesto a mantener esas páginas
se le avisará en caso de modificaciones, y así se le permitirá verificar rápidamente la validez de las
nuevas ediciones.
Vandalismo
Consiste en hacer ediciones (generalmente hechas por desconocidos) que borran contenido importante,
introducen errores, agregan contenido inapropiado u ofensivo (por ejemplo, insultos) o simplemente
incumplen flagrantemente las normas del wiki. También son frecuentes los intentos de spam, por
ejemplo:
• La introducción de enlaces en un wiki con el fin de subir en los buscadores de Internet (véase
PageRank).
• Los intentos de publicitarse o hacer proselitismo (de su ideología, religión u otros) a través del
wiki.
• Ingresar material que viola derechos de autor.
Algunas soluciones que se utilizan para luchar contra el vandalismo son:
• Revertir rápidamente sus cambios, para que así se desanimen.
• Bloquearlos temporalmente por su nombre de usuario o dirección IP, de tal forma que no
puedan seguir editando. Esta solución se ve dificultada por las IPs dinámicas y el uso de proxies
abiertos, que, al ser bloqueados, pueden afectar también a personas inocentes.

5. • Si se produce siempre en una misma página, la protección de esa página.
• No permitir que editen páginas usuarios que no estén registrados en la wiki.
• En casos extremos (generalmente, ataques por medio de herramientas automáticas), bloquear la
base de datos del wiki, sin permitir ningún tipo de edición.
Software
Existen varios programas, generalmente scripts de servidor en Perl o PHP, que implementan un wiki.
Con frecuencia, suelen utilizar una base de datos, como MySQL.
Suelen distinguirse por:
• Destino: para uso personal, para intranets, para la web, etc.
• Funcionalidad: pueden o no mantener historiales, tener opciones de seguridad, permitir subir
archivos, tener editores WYSIWYG, etc.
Algunos de los más utilizados son:
• UseModWiki: el más antiguo, escrito en Perl.
• MediaWiki: utilizado en todos los proyectos de Wikimedia. Basado en PHP y MySQL.
• PhpWiki: basado en UseMod. Escrito en PHP, puede utilizar distintas bases de datos.
• TikiWiki: CMS completo, con un wiki muy desarrollado, usando PHP y MySQL.
• DokuWiki: Un wiki completo escrito en PHP sin necesidad de bases de datos (usa sólo ficheros
de texto)
• WikkaWiki: basado en WakkaWiki, un wiki muy ligero. Usa PHP y MySQL
• MoinMoin: Modular. Escrito en Python.
• OpenWiking: Wiki programado en ASP.
• Swiki: Wiki programado en Squeak
Utilidades
• Pueden realizarse búsquedas en varios wikis a la vez, incluso en esta web y en la de Ward,
utilizando un MetaWiki.
• El wiki es una práctica innovadora que ha expandido su uso, por ejemplo, a las empresas, las
cuales utilizan este medio para que el conocimiento adquirido por los trabajadores pueda ser
compartido y complementado por todos, se utiliza como una herramienta que favorece la
innovación.

6. Diferencias entre los Blogs y los Wikis:
Blogs Wikis
- Normalmente un sólo - Muchos autores al mismo nivel
autor/editor + comentarios - La estructura puede ser variada,
- Estructura cronológica sustituyéndose las versiones a
empezando por la última medida que se modifica.
"entrada" - Links externos e internos
- Links externos
Fuente: Wikinomics
Quizás la utilidad más destacada de una wiki empresarial es el fomento de la colaboración, tanto
interna (entre los empleados) como externa (con proveedores y clientes). El hecho que haya una
plataforma editable e intuitiva para compartir documentos y realizar ediciones colaborativas, estimula
mucho a que esta colaboración se perciba como algo factible.
A continuación se describen los principales usos, tanto a nivel interno como externo, que pueden tener
las Wikis:
1) Creación colectiva entre los empleados
La wiki interna puede funcionar como una útil herramienta de colaboración para compartir
conocimiento entre personas de diferentes departamentos. Al ser un "espacio abierto" donde se puede
crear y editar contenidos por varios usuarios, facilita la participación y el acceso al trabajo compartido
en tiempo real.
Esa colaboración puede manifestarse en forma de múltiples resultados. Por ejemplo: a) para crear
colectivamente un "kit de bienvenida" a los nuevos trabajadores en el que se les explique cómo

7. funciona la empresa, o b) para redactar "normas de funcionamiento" que regulen la actividad de una
comunidad de innovadores. En este sentido la Wiki funciona como una herramienta que potencia la
Inteligencia Colectiva.
2) Información sobre los productos de la empresa
La Wiki es una buena herramienta para generar información actualizada sobre un producto, que
incluya sus funcionalidades, características, precios, opiniones de clientes, etc. Puede tener una parte de
acceso interno, como repositorio ordenado de conocimiento vital sobre el producto; y una parte pública
que haga la función de "portal del producto" o incluso, de "manual del usuario".
Lo más valioso de esta utilidad es que el repositorio de conocimiento sobre el producto se construye
de manera colectiva, aprovechando información de distintas fuentes, lo que aporta una riqueza y
diversidad al resultado final que terminan agradeciendo los clientes.
3) Espacio colaborativo para evaluar nuevos productos
Las empresas usan wikis como un "espacio social de innovación", donde se comparten las opiniones
entre los "beta-testers" que prueban los nuevos productos, bien sean los propios empleados de la
empresa, o bien usuarios seleccionados.
4) Gestión de proyectos
También puede servir para la gestión de proyectos en los que intervienen profesionales de distintos
departamentos e incluso de distintos países. Se puede crear un wiki por proyecto para que los
miembros del equipo puedan generar y actualizar documentos relacionados con el proyecto, y que toda
esta información esté concentrada en el mismo lugar. Con esto se puede acabar con el desorden que
implica el envío colectivo de e-mails en distintos formatos.
5) Espacio de creatividad bottom-up
Algunas empresas están usando las wikis para impulsar dinámicas de creatividad con un fuerte acento
bottom-up (de-abajo-a-arriba), democratizando la participación de los empleados de cualquier nivel
en los procesos de innovación.
La wiki permite que las ideas de los empleados de los niveles inferiores tengan un espacio donde
proyectarse, y no pasen desapercibidas, ni se queden atrapadas por barreras jerárquicas o trabas
burocráticas.
6) Atención al cliente
Una Wiki se puede convertir en una sólida herramienta para el Departamento de Atención al cliente.
Los empleados pueden ir creando una entrada para cada tipo de problema o incidencia que se les vaya
presentando y mostrar la solución dada. Es muy típico, por ejemplo, que las Wikis sirvan para redactar
colectivamente las útiles FAQ ("Preguntas más frecuentes") sobre un producto o servicio.
7) Agenda de reuniones
Pueden usarse las wikis para conocer las agendas de los demás empleados y poder concertar una
reunión que venga bien a todos sin necesidad, de nuevo, del envío de múltiples e-mails confirmando la
disponibilidad de los asistentes.
EL LENGUAJE UNIFICADO DE MODELADO (UML)
En todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos ya que describen el
aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado de desarrollo o estar, todavía,
en un estado de planeación. Es en este momento cuando los diseñadores del modelo deben investigar los
requerimientos del producto terminado y dichos requerimientos pueden incluir áreas tales como funcionalidad,

8. performance y confiabilidad. Además, a menudo, el modelo es dividido en un número de vistas, cada una de las
cuales describe un aspecto específico del producto o sistema en construcción.
El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeño tamaño se
obtienen beneficios de modelado, sin embargo es un hecho que entre más grande y más complejo es el
sistema, más importante es el papel de que juega el modelado por una simple razón: "El hombre hace modelos
de sistemas complejos porque no puede entenderlos en su totalidad".
UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los aspectos
principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch,
autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos
OOSE y Objectory. La versión 1.0 de UML fue liberada en Enero de 1997 y ha sido utilizado con éxito en
sistemas construidos para toda clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones,
aeronáutica, finanzas, etc.
Los principales beneficios de UML son:
• Mejores tiempos totales de desarrollo (de 50 % o más).
• Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
• Establecer conceptos y artefactos ejecutables.
• Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
• Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
• Mejor soporte a la planeación y al control de proyectos.
• Alta reutilización y minimización de costos.
UML, ¿Método o Lenguaje de Modelado?
UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen
diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de
estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer,
cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas
instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar
los resultados del uso del método.
Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas,
elementos de modelo  los símbolos utilizados en los modelos  y un conjunto de mecanismos generales o
reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas (figura 1).
figura 1
Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una
abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía"
completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para
el desarrollo. Las diferentes vistas que UML tiene son:
• Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores
externos.
• Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura
estática y la conducta dinámica del sistema.
• Vista de Componentes: Muestra la organización de los componentes de código.
• Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la
comunicación y sincronización que están presentes en un sistema concurrente.
• Vista de Distribución: muestra la distribución del sistema en la arquitectura física con computadoras y
dispositivos llamados nodos.

9. Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de
diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso
de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de
distribución.
Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo
que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las
relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de
modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.
Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento
de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso
específico, organización o usuario.
FASES DEL DESARROLLO DE UN SISTEMA
Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño,
Programación y Pruebas.
Análisis de Requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado de
casos de uso, los actores externos que tienen interés en el sistema son modelados con la funcionalidad que
ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son modelados con relaciones y
tienen asociaciones entre ellos o éstas son divididas en jerarquías. Los actores y casos de uso son descritos en
un diagrama use-case. Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que él
(o ella) espera del sistema sin considerar la funcionalidad que se implementará. Un análisis de requerimientos
puede ser realizado también para procesos de negocios, no solamente para sistemas de software.
Análisis
La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en
el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un
diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso también se consideran
en esta fase a través de los modelos dinámicos en UML. Es importante notar que sólo se consideran clases que
están en el dominio del problema (conceptos del mundo real) y todavía no se consideran clases que definen
detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos,
comunicaciones, concurrencia, etc.
Diseño
En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases
que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para almacenar
objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del
análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de
programación.
Programación
En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a
objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar
mentalmente esos modelos a código.
Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema,
pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y
son típicamente ejecutadas por el programador. Las pruebas de integración integran componentes y clases en
orden para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al sistema como una "caja
negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de
aceptación conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las
pruebas de sistema.
CONCEPTOS DE LA METODOLOGÍA ORIENTADA A OBJETOS

10. La metodología orientada a objetos ha derivado de las metodologías anteriores a éste. Así como los métodos de
diseño estructurado realizados guían a los desarrolladores que tratan de construir sistemas complejos utilizando
algoritmos como sus bloques fundamentales de construcción, similarmente los métodos de diseño orientado a
objetos han evolucionado para ayudar a los desarrolladores a explotar el poder de los lenguajes de
programación basados en objetos y orientados a objetos, utilizando las clases y objetos como bloques de
construcción básicos.
Actualmente el modelo de objetos ha sido influenciado por un número de factores no sólo de la Programación
Orientada a Objetos, POO (Object Oriented Programming, OOP por sus siglas en inglés). Además, el modelo de
objetos ha probado ser un concepto uniforme en las ciencias de la computación, aplicable no sólo a los
lenguajes de programación sino también al diseño de interfaces de usuario, bases de datos y arquitectura de
computadoras por completo. La razón de ello es, simplemente, que una orientación a objetos nos ayuda a hacer
frente a la inherente complejidad de muchos tipos de sistemas.
Se define a un objeto como "una entidad tangible que muestra alguna conducta bien definida". Un objeto "es
cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los métodos que controlan dichos
datos".
Los objetos tienen una cierta "integridad" la cual no deberá ser violada. En particular, un objeto puede
solamente cambiar estado, conducta, ser manipulado o estar en relación con otros objetos de manera
apropiada a este objeto.
Actualmente, el Análisis Orientado a Objetos (AOO) va progresando como método de análisis de requisitos por
derecho propio y como complemento de otros métodos de análisis. En lugar de examinar un problema mediante
el modelo clásico de entrada-proceso-salida (flujo de información) o mediante un modelo derivado
exclusivamente de estructuras jerárquicas de información, el AOO introduce varios conceptos nuevos. Estos
conceptos nuevos le parecen inusuales a mucha gente, pero son bastante naturales.
Una clase es una plantilla para objetos múltiples con características similares. Las clases comprenden todas
esas características de un conjunto particular de objetos. Cuando se escribe un programa en lenguaje orientado
a objetos, no se definen objetos verdaderos sino se definen clases de objetos.
Una instancia de una clase es otro término para un objeto real. Si la clase es la representación general de un
objeto, una instancia es su representación concreta. A menudo se utiliza indistintamente la palabra objeto o
instancia para referirse, precisamente, a un objeto.
En los lenguajes orientados a objetos, cada clase está compuesta de dos cualidades: atributos (estado) y
métodos (comportamiento o conducta). Los atributos son las características individuales que diferencian a un
objeto de otro (ambos de la misma clase) y determinan la apariencia, estado u otras cualidades de ese objeto.
Los atributos de un objeto incluyen información sobre su estado.
Los métodos de una clase determinan el comportamiento o conducta que requiere esa clase para que sus
instancias puedan cambiar su estado interno o cuando dichas instancias son llamadas para realizar algo por
otra clase o instancia. El comportamiento es la única manera en que las instancias pueden hacerse algo a sí
mismas o tener que hacerles algo. Los atributos se encuentran en la parte interna mientras que los métodos se
encuentran en la parte externa del objeto .
Representación visual de un objeto como componente de software
Para definir el comportamiento de un objeto, se crean métodos, los cuales tienen una apariencia y un
comportamiento igual al de las funciones en otros lenguajes de programación, los lenguajes estructurados, pero
se definen dentro de una clase. Los métodos no siempre afectan a un solo objeto; los objetos también se
comunican entre sí mediante el uso de métodos. Una clase u objeto puede llamar métodos en otra clase u
objeto para avisar sobre los cambios en el ambiente o para solicitarle a ese objeto que cambie su estado.
Cualquier cosa que un objeto no sabe, o no puede hacer, es excluida del objeto. Además, como se puede
observar de los diagramas, las variables del objeto se localizan en el centro o núcleo del objeto. Los métodos
rodean y esconden el núcleo del objeto de otros objetos en el programa. Al empaquetamiento de las variables
de un objeto con la protección de sus métodos se le llama encapsulamiento. Típicamente, el encapsulamiento
es utilizado para esconder detalles de la puesta en práctica no importantes de otros objetos. Entonces, los
detalles de la puesta en práctica pueden cambiar en cualquier tiempo sin afectar otras partes del programa.

11. Esta imagen conceptual de un objeto —un núcleo de variables empaquetadas en una membrana protectora de
métodos— es una representación ideal de un objeto y es el ideal por el que los diseñadores de sistemas
orientados a objetos luchan. Sin embargo, no lo es todo: a menudo, por razones de eficiencia o la puesta en
práctica, un objeto puede querer exponer algunas de sus variables o esconder algunos de sus métodos.
El encapsulamiento de variables y métodos en un componente de software ordenado es, todavía, una simple
idea poderosa que provee dos principales beneficios a los desarrolladores de software:
• Modularidad, esto es, el código fuente de un objeto puede ser escrito, así como darle mantenimiento,
independientemente del código fuente de otros objetos. Así mismo, un objeto puede ser transferido
alrededor del sistema sin alterar su estado y conducta.
• Ocultamiento de la información, es decir, un objeto tiene una "interfaz publica" que otros objetos pueden
utilizar para comunicarse con él. Pero el objeto puede mantener información y métodos privados que
pueden ser cambiados en cualquier tiempo sin afectar a los otros objetos que dependan de ello.
Los objetos proveen el beneficio de la modularidad y el ocultamiento de la información. Las clases proveen el
beneficio de la reutilización. Los programadores de software utilizan la misma clase, y por lo tanto el mismo
código, una y otra vez para crear muchos objetos.
En las implantaciones orientadas a objetos se percibe un objeto como un paquete de datos y procedimientos
que se pueden llevar a cabo con estos datos. Esto encapsula los datos y los procedimientos. La realidad es
diferente: los atributos se relacionan al objeto o instancia y los métodos a la clase. ¿Por qué se hace así? Los
atributos son variables comunes en cada objeto de una clase y cada uno de ellos puede tener un valor
asociado, para cada variable, diferente al que tienen para esa misma variable los demás objetos. Los métodos,
por su parte, pertenecen a la clase y no se almacenan en cada objeto, puesto que sería un desperdicio
almacenar el mismo procedimiento varias veces y ello va contra el principio de reutilización de código.
Otro concepto muy importante en la metodología orientada a objetos es el de herencia. La herencia es un
mecanismo poderoso con el cual se puede definir una clase en términos de otra clase; lo que significa que
cuando se escribe una clase, sólo se tiene que especificar la diferencia de esa clase con otra, con lo cual, la
herencia dará acceso automático a la información contenida en esa otra clase.
Con la herencia, todas las clases están arregladas dentro de una jerarquía estricta. Cada clase tiene una
superclase (la clase superior en la jerarquía) y puede tener una o más subclases (las clases que se encuentran
debajo de esa clase en la jerarquía). Se dice que las clases inferiores en la jerarquía, las clases hijas, heredan
de las clases más altas, las clases padres.
Las subclases heredan todos los métodos y variables de las superclases. Es decir, en alguna clase, si la
superclase define un comportamiento que la clase hija necesita, no se tendrá que redefinir o copiar ese código
de la clase padre
De esta manera, se puede pensar en una jerarquía de clase como la definición de conceptos demasiado
abstractos en lo alto de la jerarquía y esas ideas se convierten en algo más concreto conforme se desciende por
la cadena de la superclase.
Sin embargo, las clases hijas no están limitadas al estado y conducta provistos por sus superclases; pueden
agregar variables y métodos además de los que ya heredan de sus clases padres. Las clases hijas pueden,
también, sobreescribir los métodos que heredan por implementaciones especializadas para esos métodos. De
igual manera, no hay limitación a un sólo nivel de herencia por lo que se tiene un árbol de herencia en el que se
puede heredar varios niveles hacia abajo y mientras más niveles descienda una clase, más especializada será
su conducta.
La herencia presenta los siguientes beneficios:
• Las subclases proveen conductas especializadas sobre la base de elementos comunes provistos por la
superclase. A través del uso de herencia, los programadores pueden reutilizar el código de la
superclase muchas veces.
• Los programadores pueden implementar superclases llamadas clases abstractas que definen conductas
"genéricas". Las superclases abstractas definen, y pueden implementar parcialmente, la conducta pero
gran parte de la clase no está definida ni implementada. Otros programadores concluirán esos detalles
con subclases especializadas.
Ventajas de la metodología orientada a objetos

12. En síntesis, algunas ventajas que presenta son:
• Reutilización. Las clases están diseñadas para que se reutilicen en muchos sistemas. Para maximizar la
reutilización, las clases se construyen de manera que se puedan adaptar a los otros sistemas. Un
objetivo fundamental de las técnicas orientadas a objetos es lograr la reutilización masiva al construir el
software.
• Estabilidad. Las clases diseñadas para una reutilización repetida se vuelven estables, de la misma
manera que los microprocesadores y otros chips se hacen estables.
• El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo nivel. El
encapsulamiento oculta los detalles y hace que las clases complejas sean fáciles de utilizar.
• Se construyen clases cada vez más complejas. Se construyen clases a partir de otras clases, las cuales
a su vez se integran mediante clases. Esto permite construir componentes de software complejos, que a
su vez se convierten en bloques de construcción de software más complejo.
• Calidad. Los diseños suelen tener mayor calidad, puesto que se integran a partir de componentes
probados, que han sido verificados y pulidos varias veces.
• Un diseño más rápido. Las aplicaciones se crean a partir de componentes ya existentes. Muchos de los
componentes están construidos de modo que se pueden adaptar para un diseño particular.
• Integridad. Las estructuras de datos (los objetos) sólo se pueden utilizar con métodos específicos. Esto
tiene particular importancia en los sistemas cliente-servidor y los sistemas distribuidos, en los que
usuarios desconocidos podrían intentar el acceso al sistema.
• Mantenimiento más sencillo. El programador encargado del mantenimiento cambia un método de clase
a la vez. Cada clase efectúa sus funciones independientemente de las demás.
• Una interfaz de pantalla sugestiva para el usuario. Hay que utilizar una interfaz de usuario gráfica de
modo que el usuario apunte a iconos o elementos de un menú desplegado, relacionados con los
objetos. En determinadas ocasiones, el usuario puede ver un objeto en la pantalla. Ver y apuntar es
más fácil que recordar y escribir.
• Independencia del diseño. Las clases están diseñadas para ser independientes del ambiente de
plataformas, hardware y software. Utilizan solicitudes y respuestas con formato estándar. Esto les
permite ser utilizadas en múltiples sistemas operativos, controladores de bases de datos, controladores
de red, interfaces de usuario gráficas, etc. El creador del software no tiene que preocuparse por el
ambiente o esperar a que éste se especifique.
• Interacción. El software de varios proveedores puede funcionar como conjunto. Un proveedor utiliza
clases de otros. Existe una forma estándar de localizar clases e interactuar con ellas. El software
desarrollado de manera independiente en lugares ajenos debe poder funcionar en forma conjunta y
aparecer como una sola unidad ante el usuario.
• Computación Cliente-Servidor. En los sistemas cliente-servidor, las clases en el software cliente deben
enviar solicitudes a las clases en el software servidor y recibir respuestas. Una clase servidor puede ser
utilizada por clientes diferentes. Estos clientes sólo pueden tener acceso a los datos del servidor a
través de los métodos de la clase. Por lo tanto los datos están protegidos contra su corrupción.
• Computación de distribución masiva. Las redes a nivel mundial utilizarán directorios de software de
objetos accesibles. El diseño orientado a objetos es la clave para la computación de distribución
masiva. Las clases de una máquina interactúan con las de algún otro lugar sin saber donde residen
tales clases. Ellas reciben y envían mensajes orientados a objetos en formato estándar.
• Mayor nivel de automatización de las bases de datos. Las estructuras de datos (los objetos) en las
bases de datos orientadas a objetos están ligadas a métodos que llevan a cabo acciones automáticas.
Una base de datos OO tiene integrada una inteligencia, en forma de métodos, en tanto que una base de
datos relacional básica carece de ello.
• Migración. Las aplicaciones ya existentes, sean orientadas a objetos o no, pueden preservarse si se

13. ajustan a un contenedor orientado a objetos, de modo que la comunicación con ella sea a través de
mensajes estándar orientados a objetos.
• Mejores herramientas CASE. Las herramientas CASE (Computer Aided Software Engineering,
Ingeniería de Software Asistida por Computadora) utilizarán las técnicas gráficas para el diseño de las
clases y de la interacción entre ellas, para el uso de los objetos existentes adaptados a nuevas
aplicaciones. Las herramientas deben facilitar el modelado en términos de eventos, formas de
activación, estados de objetos, etc. Las herramientas OO del CASE deben generar un código tan pronto
se definan las clases y permitir al diseñador utilizar y probar los métodos recién creados. Las
herramientas se deben diseñar de manera que apoyen el máximo de creatividad y una continua
afinación del diseño durante la construcción.
Es indudable que el ambiente competitivo en el que se vive en el ámbito empresarial actualmente,
requiere de promover los procesos y actividades de negocio que generan las ventajas competitivas de
las compañías ante sus más fuertes competidores.
Por esto, desde hace ya varios años, se ha dado mayor importancia a las Tecnologías de Información y
su alineación con las estrategias del negocio para mejorar sus procesos clave de negocio. Prueba de
ello, es el incremento tan sustancial de adquisiciones de paquetes de software empresariales tales como
el ERP (Enterprise Resource Planning), con el cual los directivos de las compañías esperan tener
integradas todas las áreas o departamentos de la compañía que apoyan para la generación de sus
productos y servicios.
Hoy más que nunca las empresas requieren de herramientas que les proporcionen control y
centralización de su información, esto con el fin tomar las mejores decisiones para sus procesos y
estrategias de negocios. Los ERP son una solución robusta para aquellas empresas que buscan una
solución universal a la centralización de su información.
La implementación de un sistema de ERP por lo general es largo y complejo, ya que implica rediseñar
los esquemas de trabajo. Su implementación es de alto riesgo, ya que envuelve complejidad, tamaño,
altos costos, un equipo considerable de desarrollo, además de inversión de tiempo.
En la mayoría de las empresas, se requiere remplazar la infraestructura existente, lo que implica
inversión de capital adicional, especialización y hasta la posibilidad de parar el negocio temporalmente
para la implementación: por otra parte es importante señalar que el grado de experiencia de los
proveedores es un factor importante para el buen funcionamiento del sistema.
Metodología
Para el desarrollo de este artículo, se tomaron en cuenta varias fuentes bibliográficas como son:
biblioteca digital del Instituto Tecnológico y de Estudios Superiores de Monterrey (ITESM), biblioteca
de ITESM Campus Monterrey, revistas electrónicas y diversas consultas de la Web. Se analizaron los
diversos puntos de vista de cada uno de los autores consultados y se tomó lo más importante de sus
puntos de vista.
¿Qué es un ERP?
El ERP es un sistema integral de gestión empresarial que está diseñado para modelar y automatizar la
mayoría de procesos en la empresa (área de finanzas, comercial, logística, producción, etc.). Su misión
es facilitar la planificación de todos los recursos de la empresa (www.adpime.com).

14. Por otro lado, Kumar y Hillengersberg (2000) definen al Enterprise Resource Planning (ERP) como
"paquetes de sistemas configurables de información dentro de los cuales se integra la información a
través de áreas funcionales de la organización". Los sistemas ERP son extremadamente costosos, y una
vez que los sistemas ERP se implantan con éxito trae una serie de beneficios importantes para las
empresas.
Orton y Marlene (2004) definen a los sistemas de planeación de recursos empresariales (ERP) como un
sistema que permite coleccionar y consolidar la información a través de la Empresa.
Reuther,D. (2004) en su artículo "Critical Factors for Enterprise Resources Planning System Selection
and Implementation Projects within Small to Médium Enterprise" menciona que K.C. Laundon y J.P.
Laundon, (2000) definen los sistemas de planeación de recursos empresariales (ERP) como un sistema
de administración de negocios que integra todas las facetas del negocio, incluyendo planeación,
manufactura, ventas y finanzas (esto lo podemos representa en Fig. 1) El software ERP planea y
automatiza muchos procesos con la meta de integrar información a lo largo de la empresa y elimina los
complejos enlaces entre los sistemas de las diferentes áreas del negocio.