Академический Документы
Профессиональный Документы
Культура Документы
-3-
propusieron construir un nuevo lenguaje de modelado, UML, cuya primera versión (1.1) se
presentó para su estandarización al OMG (Object Management Group) en 1997 y que fue
aceptada.
-4-
UML, la Web y el comercio electrónico
Uno de los grandes anuncios del año 2000 en el mundo de UML, se ha producido el pasado 17 de
mayo con el anuncio conjunto de Rational Software (empresa cradora de UML y de Rational
CASES) y Commerce One (líder mundial en soluciones globales de comercio electrónico) de
colaboración mutua para crear la especificación de la primera versión UML para la industria, que
siga las especificacioens XML para el desarrollo del comercio electrónico. Es decir, se han unido
dos grandes empresas con el objeto de construir un método estánddar que reduzca drásticamente el
tiempo de desarrollo e incremento la calidad de las aplicaciones de comercio electrónico basadas en
XML.
Se trata de alcanzar la máxima de que el cambio rápido de Internet ha creado una paradoja para el
desarrollo del conocido como e-software para las organizaciones que requieren la entrega de
software de un modo mucho más rápido pero conservando una calidad alta. La versión de UML
para especificaciones XML esta disponible en el sitio Web de Commerce One
(www.commerceone.com/xml/sox/index.html) y en el sitio Web de Rational
(www.rational.com/uml/index.jtmpl).
Otra gran ventaja que está ofreciendo UML se refiere al desarrollo de aplicaciones globales para la
Web, no sólo para comercio electrónico. UML está siendo utilizado por los gerentes de proyectos,
desarrolladores y arquitectos de la Web que aplican técnicas orientadas a objetos para construir
aplicaciones Web robustas, escalables y eficientes. UML permite a los desarrolladores modelar sus
aplicacioens Web como parte de un sistema completo y la lógica de negocios que se debe reflejar en
las aplicaciones.
Buena prueba de que este entusiasmo es una realidad creciente, se puede ver en la inmensa cantidad
de bibliografía que ha generado y sigue generando UML, así como en los numerosos eventos de
todo tipo (congreso, seminarios, simposium, jornada, etc.) que se celebran a lo largo y ancho del
mundo tecnológico y en los que brilla con luz propia UML.
Objetivos de UML
Hubo varios objetivos detràs del desarrollo de UML. El primero y màs importante, UML es
un lenguaje de modelado de propópisto general que puede usar todos los modeladores.
No tiene propietario y está basado en el común acuerdo de gran parte de la comunidad
informática. Esto siginifica incluir conceptos de los métodos líderes para que UML pueda
-5-
usarse como su lenguaje de modelado. Está pensado para reemplzar al menos los
modelos OMT, Booch y Objectory, así como aquéllos de otros participantes de la
propuesta. Se pensó para ser tan familiar como sea posible, usar la notación de OMT,
Booch, Objectory y otros métodos importantes. Esto significa incorporar buenas prácticas
de diseño, tales como la encapsulación, separación de los temas, y la captura de la
intención del modelo construido. Pretende abordar los problemas actuales del desarrollo
de software, tales como gran tamaño, distribución, concurrencia, patrones, y desarrollo en
equipo.
UML pretende trabajar correctamente con todos, o al menos con la mayorìa de los
procesos de desarrollo existente. UML incluye todos los conceptos que consieramos
necesarios para utilizar proceso moderno iterativo, basado en construir una sólida
arquitectura para resolver requisitos dirigidos por casos de uso.
Un objetivo final del UML era ser tan simple como fuera posible pero manteniendo la
capacidad de modelar toda gama de sistemas que se necesita construir. UML necesita ser
lo suficientemente expresivo para manejar todos los conceptos que se originan en un
sistema moderno, tales como la concurrencia y distribución, así como también los
mecanismos de la ingeniería de software, tales como encapsulación y componentes.
Debe ser un lenguaje universal, como cualquier lenguaje de programación de propósito
general. Desafortunadamente eso significa que no puede ser pequeño si quiere manejar
cosas que no san sistemas de juguete. Los leguanjes modernos y los sistemas operativos
modernos, son mucho más complicados hoy que hace 40 años, por que nosotros
esperamos mucho más de ellos. UML tiene varios tipos de modelos; no es algo que una
pueda dominar en un dia. Es más complicado que algunos de sus antecesores por que
intenta ser más amplio. Pero no es necesario aprenderlo todo a la vez, no más que lo que
exige un lenguaje de programación, un sistema operativo o una compleja aplicación de
usuario.
Los conceptos y modelos de UML puedn agruparse en las siguientes áreas conceptuales.
Estructura estática. Cualquier modelo preciso debe primero definr el universo del discurso, esto es,
los conceptos clave de la aplicación, sus propiedades internas, y las relaciones entre cada una. Este
conjunto de construcciones es la vista estática. Los conceptos de la aplicación son modelados como
clases, cada una de las cuales describe un conjunto de objetos discretos que almacenan información
y se comunica para implementar un comportamiento. La información que almacenan es modelada
como atributos; el comportamiento que realizan es modelado como operaciones. Varias clases
pueden compartir una estructura común usando generalización. Una clase hija añade nuevas
estructuras y comportamientos a las estructuras y comportamientos que obtiene por herencia de la
clase padre. Los objetos también tienen conexión durante la ejecución con otros objetos
-6-
individuales. Tales relaciones “Objeto a Objeto” son modeladas como asociaciones entre clases.
Algunas relaciones entre elementos se agrupan como relaciones de dependencia, incluyendo las
relaciones para modelar desplazamientos en los niveles de abstración, enlace de parámetros del
modelo, concesión de permisos, y uso de un elemento por parte de otro. Otras relaciones son la
combinacionón de casos de uso y el flujo de datos. La vista estática se expresa con diagramas de
clases y puede usarse par agenerar la mayoría de las declaraciones de estructuras de datos en un
programa. Hay muchos tipos de elementos en los diagramas UML, tales como interfaces, tipos de
datos, casos de uso y señales. En conjunto, se les llama clasificadores, y se comportan de forma
muy parecida a las clases, con ciertas restricciones en cada tipo de clasificador.
La visión de un objeto aislado es una máquina de estados –una vista de un objeto que muestra la
forma en que responde a los eventos en función de su estado actual, realiza acciones como parte de
su respuesta y transiciones a un nuevo estado–. Las máquinas de estado se representan en un
diagrama de estados.
La visión de la interacción de los objetos de un sistema es una colaboración: una vista, dependiente
de contexto, de los objetos y los enlaces entre ellos, junto con el flujo de mensajes entre los objetos
mediante los enlaces de datos. Este punto de vista unifica la estructura de los datos, el control de
flujo y el flujo de datos en una sola vista. Las colaboraciones e interacciones se muestran mediante
los diagramas de secuencia y los diagramas de colaboración. Guiando todas las vistas de
comportamiento se encuentra un conjunto de casos de uso. Cada uno es una descripción de una
porción de la funcionalidad del sistema como la percibe un actor, un usuario externo del sistema.
Contrucciones de implementación. Los modelos de UML tienen significado para el análisis lógico
y para la implementación física. Ciertos constructores representan elementos de implementación.
Un componente es una parte física reemplazable de un sistema y es capaz de responder a las
peticiones descritas por un conjunto de interfaces. Se pretende que sea fácilmente sustituible por
otro componente que cumpla la misma especificación. Un nodo es un recurso computacional que
define una localización durante la ejecución del sistema. Pueden contener componentes y objetos.
La vista de despliegue describe la configuración de los nodos de un sistema en ejecución y la
organización de los componentes y objetos en él, incluyendo posible migraciones de contenido
entre nodos.
Organización del modelo. Los ordenadores pueden manejar grandes modelos “plano”, pero los
humanos no. En un sistema grande, la información del modelo debe ser dividida en piezas
coherentes, para que los equipos puedan trabajar en las diferentes partes de forma concurrente.
Incluso en un sistema más pequeño, el conocimiento humano requiere que se organice el contenido
del modelo en paquetes de tamaño modesto. Los paquetes son unidades organizativas, jerárquicas, y
de propósito general de los modelos UML. Pueden usarse para almacenamiento, control de acceso,
gestión de la configuración, y construcción de bibliotecas que contengan fragmentos de código
reutilizable. Una dependencia entre paquetes resume las dependencia entre los contenidos del
paquete. Una dependencia entre paquetes puede ser impuesta por la arquitectura global del sistema.
Por lo tanto, los contenidos de los paquetes deben adaptarse a las dependencias del paquete y a las
impuestas por la arquitectura del sistema.
-7-
Mecanismos de extensión. No importa cuan completo sea el conjunto de “facilidades” de un
lenguaje, la gente querrá hacer extensiones. Hemos dotado a UML de una limitada capacidad de
extensión, que creemos suficiente para la mayoría de las extensiones que requiere el “DÍA A DÍA”,
sin la necesidad de un cambio en el lenguaje básico. Un estereotipo es una nueva clase de elemento
de modelado con la misma estructura que un elemento existente pero con restricciones adicionales,
una interpretación diferente de un icono, y un tratamiento diferente por los generadores de código y
otras herramientas de bajo nivel. Un valor etiquetado es un par arbitrario de cadenas etiqueta-valor,
que pueden enlazarse a cualquier tipo de elemento de modelado, para almacenar información
arbitraria, como información de gestión de proyecto, guías para los generadores de código, y
valores requeridos por los estereotipos. La etiqueta y el valor son representadas como cadenas. Una
restricción es una condición “bien formada” expresada en una cadena de texto en algún lenguaje
restringido, tal como un lenguaje de programación, un lenguaje especial limitado, o lenguaje
natural. UML incluye un lenguaje de restricciones llamado OCL(Object Constraint Language,
“Lenguaje de Restricción de Objetos”, N. del T.). Como con cualquier mecanismo de extensión,
estos mecanismos deben usarse con cuidado debido al riesgo de producir un dialecto privado
ilegible por los demás. Pero a la vez pueden evitar la necesidad de cambios más radicales.
¿Qué es un modelo?
Un modelo es una representación, en cierto medio, de algo en el mismo u otro medio. El modelo
capta los aspectos importantes de lo que estamos modelando, desde cierto punto de vista, y
simplifica u omite el resto. La ingeniería, la arquitectura y muchos otros campos creativos usan
modelos.
Un modelo se expresa en medio adecuado para el trabajo. Los modelos de construcciones pueden
dibujarse en papel, las figuras tridimensionales son construidas con cartón y papel cartón, o las
ecuaciones de elementos finitos en un computador. Un modelo de construcción de un edificio
muestra la apariencia del edificio pero también puede usarse para hacer ingeniería y cálculos de
coste.
Los diversos modelos de un sistema de software pueden capturar requisitos sobre su dominio de
aplicaciòn, las formas en que los usuarios lo utilizarán, su división en módulos, los patrones
comunes usados en su construcción, y otras cosas. Los implicados incluyen al arquitecto, a los
-8-
analistas, a los programadores, al encargado del proyecto, a los clientes, a inversores, a los usuarios
finales, y a los operadores. Se utilizan los diferentes tipos de modelos de UML.
Para pensar del diseño de un sistema. Un arquitecto utiliza modelos en papel, sobre un
computador, o como construcciones tridimensionales, para visualizar y experimentar con posibles
diseños. La simplicidad de crear y de modificar modelos pequeños permite pensamiento creativo e
innovación con poco coste.
Para capturar decisiones del diseño en una forma mutable a partir de los requisitos. Un modelo
de un edificio muestra el aspecto externo convenido con el cliente. Otro modelo muestra el
encaminamiento interno de cables, de tuberías, y de conductos de ventilación. Hay muchas maneras
de implementar estos servicios. El modelo final muestra un diseño que el arquitecto cree que es
bueno. El cliente puede verificar esta información, pero, a menudo, los clientes no se preocupan por
los detalles mientras funcionen.
Para generar productos aprovechables para el trabajo. Un modelo de un edificio se puede utilizar
para generar varias clases de productos. Éstos incluyen una cuenta de materiales, una simulación
animada de un paseo, una tabla de desviaciones a varias velocidades del viento, o una visualización
de la tensión en varios puntos en el armazón.
Un modelo de un sistema software se puede utilizar para generar las declaraciones de clase, los
cuerpos de procedimiento, las interfaces de usuario, las bases de datos, los escenarios de uso válidos
o los guiones de configuración .
-9-
etc.
Para explorar económicamente múltiples soluciones. Las ventajas y los riesgos de diversos
métodos de diseño para edificios, pueden no estar claros al principio. Por ejemplo, diversas
subestructuras pueden interactuar de forma complicadas, que no se pueden evaluar en la cabeza de
un ingeniero. Los modelos pueden explorar los diversos diseño y permitir cálculos de costes y de
riesgos, antes de que se construya el edificio real.
Los modelos de un sistema de software grande permiten que se propongan y comparen varios
diseño. Los modelos no se construyen al detalle, por supuesto, pero incluso un modelo rudimentario
puede exponer muchas cuestiones que el diseño final debe tener en cuenta. Modelar permite
considerar varios diseños, con un coste pequeño al implementar cualquiera de ellos.
-10-
Adaptación del UML en un proceso de desarrollo
El UML es una herramienta maravillosa, pero no la utilizará de manera aislada. El UML
tiene la itención de impulsar el desarrollo de software, por ello, es necesario aprender los
proceso y metodologías de desarrollo como un vehículo para comprender el uso del UML
en un contexto.
Antes de comenzar a programar, los desarrolladors tienen que comprender con claridad el
problema. Esto requiere que alguien analice sus requerimientos. Una vez hecho ese
análisis. ¿se podrá iniciar la codificación? No. alguien tiene que convertir tal análisis a
diseño. De esta manera, los codificadores comenzarán a producir el código a partir del
diseño, después de probar y distribuir el código se convertirá en un sistema.
El método antiguo
Esta idea demasiado simplificada del proceso de desarrollo podrá darle una idea de que
las etapas deberán sucederse en lapsos claramente definidos, una después de otra. De
hecho, las metodologías de desarrollo iniciales se estructuraban de esa manera. La figura
###, le muestra una forma de pensar cuya influencia trascendió por varios años. Éste es
el método “en casacada”, y establece que el análisis, diseño, codificación y distribución
van uno después de otro como las actividades en un diagrama de actividades: solamente
cuando se hay completado uno se podrá iniciar el otro.
Análisis
Diseño
Codificación
-11-
Distribución
Otro problema con este método es que reduce el impacto de la compresión obtenida en el
proyecto. (No se equivoque, la compresión evoluciona durante la vida de un proyecto –
aun después de que un análisis se haya volcado en un diseño–). Si el proceso no puede
retroceder y volver a ver los primeros estados, es posible que las ideas desarrolladas no
sean utilizadas. Intentar introducir con calzador nuevos puntos de vista durante el
desarrollo es, cuando menos, bastante difícil. La revisión de un análisis y diseño –y la
ulterior incorporación de una idea desarrollada– establece una mayor oportunidad de
éxito.
El método reciente
En contraste con el método de cascada, la moderna ingeniería de programas tiende a la
colaboración entre las fases del desarrollo. Los analistas y los deseñadores, por dar un
ejemplo, hacen revisiones para desarrollar un sólido fundamento para los desarrolladores.
Éstos, a su vez, interactúan con los analistas y los diseñadores para compartirles sus
punto de vista, modificar los diseño y fortalecer su código.
La ventaja es que conforme crece la compresión, el equipo incorpora nuevas ideas y
genera un sistema más confiable. La desventaja (en caso de haberla) es que algunas
personas no son muy participativas y pueden mantenerse al margen. En ocaciones, los
gerentes de proyectos quisieran decirle a sus clientes: “Ya se finalizó el análisis y ahora
continuaremos con el diseño. Luego de unos dos o tres días de diseño, empezaremos a
codificar”.
Tal mentalidad es peligrosa. Establecer barreras artificiales entre las fases podría dar por
resultado un sistema que no haga exactamente lo que los clientes desean.
El método antiguo fomenta otro problema: es común el caso de que los partidarios al
método “en casacada” reparten el tiempo del proyecto en la codificación. El verdadero
efecto de esto es que se quita un tiempo valioso al análisis y diseño.
-12-
cuenta todos los procesos anteriores, utilizarlos adecuadamente y asignar la cantidad de
tiempo necesaria para cada fase. El proceso también debe dar por resultado diversos
productos del trabajo que den indicios de progreso y conformar una estela de
esponsabilidad.
Finalmente, el proceso, existe la tentación de generar una serie de fases que podrían
traer una gran cantidad de papeleo. Algunas metodologías que están disponibles de forma
comercial lo hacen, con lo que hacen que los gerentes de proyectos llenen interminables
formularios. El papeleo se complica por sí mismo.
Una razón de esto es la idea errónea de que la metodología de la “unitalla” es posible:
cada empresa es única. Una empresa tiene su propia cultura, normatividad, historia y
personal. La metodología del desarrollo que pueda aplicarse a un consorcio internacional
posiblemente fallará en una pequeña empresa y viceversa. Al intentar meter con calzador
una metodología en una empresa, se tendrá la mala impresión de que un papeleo
extremo podrá ayudar.
Así que aquí está el reto. Un equipo de desarrollo deberá:
− Asegurar que el equipo de desarrollo cuenta con una firme compresión del
problema que se intenta resolver.
− Dar pie a un equipo que conste de una colección de responsabilidades
− Fomentar la comunicación entre los miembros del equipo que ostentan tales
responsabilidades
− Dar pie a la intercomunicación entre las fases del proceso de desarrollo
− Desarrollar productos de trabajo que comuniquen el progreso al cliente, y eliminar
el papeleo superfluo
-13-
GRAPPLE
Recopilación de necesidades
Si itenta asignar una importancia relativa a cada segmento, éste es un buen candidato
apara ser el número uno. Si no comprende lo que desea el cliente, nunca podrá generar el
sistema adecuado. Todos los análisis de casos de uso en el mundo no le ayudarán si no
comprende las bases del dominio del cliente y el problema que quiera que usted resuelva.
Descubrir las necesidades es muy importante, ya que en esta acción, el equipo realiza su
primera sesión de JAD (Desarrollo conjunto de aplicaciones). Habrá otras más en el curso
del GRAPPLE.
Una sesión JAD reúne a quienes toman las decisiones en la empresa del cliente, a los
usuarios potenciales y a los miembros del equipo de desarrollo. Debe haber alguien que
modere la sesión; el trabajo del moderador es obtener una respuesta de quienes toman
las decisiones y de los usuarios acerca de lo que esperan que haga el sistema. Al menos
deberá haber dos miembros del equipo que tomene notas, y el modelador de objetos
deberá refinar el diagrama de clases que se obtuvo previamente.
El producto del trabajo es un diagrama de paquetes. Cada paquete representa a un área
de alto nivel de funcionalidad del sistema (por ejemplo: “ayuda con el servicio a clientes”).
Cada paquete agrupa un conjunto de casos de uso (por ejemplo: “obetener el historial del
cliente” o “tratar con el cliente”).
La complejidad del sistema será lo que determine la duración de la sesión. Casi nunca
será menor a medio dia laboral, y podría durar hasta toda una semana laborarl. La
empresa del cliente debe hacer el compromiso de invertir el tiempo que sea necesario.
¡Para qué acceder a una sesión JAD para desarrollr los requerimientos del sistema? ¡Por
qué no sólo entrevistar a cada individuo? Como podrá recordar, dije que la última parte del
reto de un proceso de desarrollo es generar un sistema en un corto lapso. Las entrevistas
individuales pueden tardar semanas, mucho más si existen conflictos en los itinerarios de
las personas. La espera de entrevistas individuales puede ocupar mucho tiempo y, con él,
puede irse por tierra la supuesta ventaja competitiva de completar rápidamente el sistema.
La entrevistas individuales posiblemente contendrán puntos de vista conflictivos, y se
perdería tiempo en intentar resolverlos. Agruparlos a todos crea una expectativa general,
en la que los participantes podrían hacer una simbiosis de sus puntos de vista en
beneficio de todos.
Análisis
En este segmento, el equipo profundiza en los resultados del segmento Necesidades y
aumentará su compresión del problema. De hecho, partes de este segmento empezarán
durante el segmento de Necesidades, conforme el modelador de objetos empieza a
depurar el diagrama de clases durante la sesión JAD de Necesidades.
Esta acción es un análisis de casos de uso de alto nivel. En una sesión JAD con usuarios
potenciales, el equipo de desarrollo trabaja con los usuarios para descubrir a los actores
que iniciarán cada caso de uso, y los actores que serán beneficiados. (Recuerde que un
actor puede ser un sistema o una persona). Un moderador interviene en la sesión, y dos
miembros del equipo toman notas. Luego de algunos proyectos, el moderador de esta
sesión podría convertirse en el analista de casos de uso.
El equipo también intentarán desarrollar nuevos casos de uso y casos de uso abstractos.
El producto del trabajo será un conjunto de diagramas de casos de uso que muestren a
los actores y las dependencias estereotipadas (“extender” e ”incluir”) entre los casos de
uso.
En esta acción, el equipo de desarrollo continúa su trabajo con los usuarios. El objetivo es
analizar la secuencia de pasos en cada caso de uso. Esta sesión JAD puede ser la
continuación de la sesión previa. Cuidado: ésta es, por lo general, la sesión JAD mas
compleja para los usuarios. Tal vez no estén acostumbrados a dividir una operación en los
pasos que la conforman y, a su vez, tampoco puédan enumerarlos. El producto del trabajo
es una descripción textual de los pasos en cada caso de uso.
Durante las sesiones JAD, el modelador de objeto escuchará todos los debates y
continuará con su depuración del diagrama de clases. En este punto, el modelador de
objetos deberá rellenar los nombres de las asociaciones, clases abstractas,
multiplicidades, generalizaciones y agragaciones. El producto del trabajo es un diagrama
de clases depurado.
Ahora que el equipo cuenta con un conjunto de diagramas de casos de uso y un diagrama
depurado de clases, se definirá la forma en que los objetos se comunican. El modelador
de objetos desarrollará un conjunto de diagramas de secuencias y de colaboraciones para
delinear la comunicación. Deberán incluirse los cambios de estado. Estos diagramas
conforman el producto del trabajo de esta acción.
Al tiempo de realizar los pasos anteriores, el diseñador del sistema descubre los detalles
específicos de la integración con los sistemas cooperativos. ?Qué tipo de comunicación
está envuelto?. ?Cuál es la arquitectura de red? Si el sistema tendrá que utilizar bases de
datos, un analista de bases de datos determinará la arquitectura (física o lógica) de ellas.
Los productos del trabajo son diagramas de distribución detallados y (de ser necesario)
modelos de datos.
Diseño
En este segmento, el equipo trabajará con los resultados del segmento de Análisis para
diseñar solución. En el diseño y en el análisis se harán las revisiones pertinentes hasta
que el diseño se haya completado. De hecho, algunas de las metodologías combinan al
Análisis y al Diseño en una sola fase.
1. Desarrollo y depuración de los diagramas de objetos
Los programadores serán quienes jueguen un importante papel en esta acción. La tárea
será visualizar los componentes que resultarán del siguiente segmento y mostrar las
dependencias entre ellos. Los diagramas de componentes serán el producto del trabajo.
Esto trae consigo otra sesión JAD con los usuarios. Aunque esto es parte del Diseño, esta
sesión puede ser la continuación de anteriores sesiones JAD con los usuarios –un indicio
de la interacción entre el Análisis y el Diseño–.
La interfaz del usuario debería permitir la consumación de todos los casos de uso. Para
ello, un analista de GUI deberá trabajar con los usuarios para desarrollar prototipos, en
papel, de las pantallas que corresponderán a grupos de casos de uso. Los usuarios
pegarán papeletas removibles que representen los componentes de la pantalla (botones,
casillas de verificacioón, listas de desplegables, menús, y cosas así). Cuando los usuarios
queden satisfechos de la posición de los componentes, los desarrolladores generarán
prototipos de las pantallas para que sean aprobados por los usuarios. Los productos del
trabajo serán capturas de pantalla de los prototipos resultantes.
5. Pruebas de diseño
Los casos de uso permiten el diseño de pruebas del software. El objetivo es evaluar si el
software hace lo que se supone que debería (esto es, que hace lo que se especifica en
los casos de uso). Preferentemente, un desarrollador o especialista de pruebas externo al
equipo de desarrollo deberá utilizar los diagramas de casos de uso para crear secuencias
de comandos en herramientas automatizadas de pruebas. Tales secuencias de comandos
conformarán el producto del trabajo.
6. Iniciar la documentación.
Nunca es demasiado pronto para empezar a documentar el sistema para los usuarios
finales y gerentes de sistemas. Los especialistas en la documentación trabajarán en
conjunto con los diseñadores para empezar a generar un panfleto de la documentación y
llegar a una estructura de alto nivel para cada documento. Tal estructura es el producto
del trabajo.
Desarrollo
De este segmento se encargan los programadores. Con suficiente análisis y diseño, este
segmento debería realizarse con rapidez y sin problemas.
4. Consumación de la documentación
Durante el segmento de desarrollo, los especialistas en documentación trabajan en
paralelo con los desarrolladores para asegurar la entrega oportuna de toda la
documentación, la cual es el producto del trabajo de esta acción.
Distribución
Cuando un sistema se ha finalizado, se distribuye en el hardware adecuado y se integra
con los sistemas cooperativos. No obstante, la primera acción en este segmento puede
iniciar antes de que el segmento de Desarrollo comience.
4. Celebración.
Sin mayor explicación, el equipo de desarrollo podrá inventar los productos del trabajo de
esta acción.
Resumen
Una metodología de desarrollo estructura los segmentos y actividades en un proyecto de
desarrollo de sistemas. Sin una metodología habría un caos y los desarrolladores no
comprenderían el problema que se supone deberían resolver, así como los sistemas no
cumplirían con las necesidades de los usuarios. Las metodologías de antaño forzaban a
una secuencia “en casacada” de análisis, diseño, codificación y distribución.
Este tipo de metodología secuencial podía fragmentar el desarrollo, de modo que un
equipo de desarrollo podría no aprovechar la mejor asimilación que se obtiene durante la
vida de un proyecto. Por lo general, también distribuye la mayor parte del tiempo en la
codificación, y esto resta una enorme cantidad de tiempo al análisis y diseño.
GRAPPLE (Directivas para el Rápido Diseño de Aplicaciones), un patrón para el proceso
de desarrollo, GRAPPLE consta de cinco segmentos: Recopilación de Necesidades,
Análisis, Diseño, Desarrollo y Distribución. Cada segmento consta de diversas acciones, y
cada una de ellas da por resultado un producto del trabajo. Los diagramas UML
constituyen productos del trabajo para varias de las acciones.
Fuentes Consultadas
WIKIPEDIA, La enciclopedia Libre(http://es.wikipedia.org/wiki/UML)
MANUAL DE REFERENCIA, EL LENGUAJE UNIFICADO DE MODELADO,
PEARSON EDUCACIÓN S.A., J. Rumbaugh, I. Jacobson, G. Boock. , Madrid 2000.
Avances en Informática y Sistema Computacionales, Hector Garcia Molina,
CONAIS Mexico 2006.
Aprendiendo UML en 24 Horas. Joseph Shmuller. Prentice Hall