Metodologas de

desarrollo de software

Introduccin
Ms all de los trabajos que puedan existir a nivel de comparacin de
metodologas para el desarrollo de sistemas de informacin existe una discusin
relacionada con la evolucin histrica de estas.
En la actualidad nos encontramos en una era posterior al desarrollo de varios
enfoques metodolgicos, donde se est tendiendo a regresar a la poca
formalidad en el desarrollo en pro de la agilidad para obtener sistemas
funcionales.

Desarrollo histrico
El avance en las metodologas de desarrollo puede ser visto desde una
perspectiva ms general dividiendo la historia en eras de la siguiente manera:

Desarrollo histrico

Era previa a las metodologas

En las dcadas de 1960 y 1970, a pesar de haberse dado los primeros avances
tecnolgicos hacia la digitalizacin de la informacin se tenan grandes limitaciones
para el desarrollo de los sistemas de informacin de forma exitosa, ya que el enfoque
era meramente tecnolgico y no se haca nfasis en el entendimiento del negocio.

Era inicial de las metodologas

A partir de los problemas de la era previa, se evidenci la necesidad de pensar en el
concepto de un Ciclo de Vida del Desarrollo de Sofware (CVDS), en donde se
desarrollaran los sistemas de informacin en etapas y fases. Esta etapa se desarroll
en las dcadas de 1970 y 1980, caracterizndose por este esquema tambin conocido
como cascada, que adems impuls el uso de tcnicas como diagramas de flujo para
modelar los procesos de cada sistema.

Desarrollo histrico

Era de las metodologas

Una metodologa se define como una coleccin recomendada de fases,
procedimientos, reglas, tcnicas, herramientas, documentacin,
administracin y entrenamiento usado para desarrollar un sistema.
Algunas interpretaciones con respecto a las ventajas de seguir una
metodologa dieron origen a algunos enfoques metodolgicos a finales de los
aos 80 y comienzos de los 90, como son:

Desarrollo histrico

Estructuracin, donde los conceptos de la programacin estructurada se aplicaban al anlisis y diseo

del sistema y sus procesos.

Orientacin a los datos, donde el entendimiento de los datos es el eje central del desarrollo.

Prototipado, para darle al usuario una aproximacin al sistema al final del desarrollo, antes de
comenzar a implementarlo.

Orientacin a objetos, aplicando los conceptos de la programacin con el mismo nombre, para
identificar objetos, sus atributos y comportamientos.

Enfoque participativo, involucrando usuarios e interesados con el desarrollo.

Enfoque estratgico, para que el sistema de informacin cumpla con los objetivos de negocio.

Enfoque sistmico, para dar una visin ms holstica del sistema de informacin y la interaccin con el
usuario.

Desarrollo histrico

Era posterior a las metodologas

Esta era se inicia a finales de los aos 90 y se caracteriza principalmente por el abandono de las
metodologas formales por parte de las organizaciones, y ms bien la tendencia hacia
aproximaciones poco formales. Esto se produce luego de que las organizaciones probaron una o
varias metodologas de desarrollo y se produce un efecto de desilusin y desencanto con estas,
por una o varias razones como complejidad, falta de coherencia con el modelo de organizacin,
carencia de sentido en trminos de resultados esperados, etc. Todo esto ocurre dado que
frecuentemente las metodologas no consideran aspectos del negocio en particular, sino que se
centran nicamente en la dimensin del desarrollo.
Por otra parte, la dificultad para adoptar una metodologa ocasiona resistencia al interior de la
organizacin, desencadenando el fenmeno de abandono a la formalidad antes detallada,
ayudado tambin por el auge de tecnologas que no exigen dicha formalidad y requieren ms
bien de un desarrollo ms gil.

Alternativas y diversidad
Aunque existes diversas metodologas de desarrollo de sistemas, el problema con el
que se encuentran algunos desarrolladores radica en el hecho que no existe una
metodologa que se adapte completamente a la solucin que estn ofreciendo a sus
clientes. Puede que ciertas etapas de la metodologa sean apropiadas o no, dados los
recursos, las fuentes, la comunicacin entre usuarios y desarrolladores, entre otros
factores, para llevar acabo actividades caractersticas del desarrollo de sistemas.
De esta forma, algunos se concentran en buscar las mejores metodologas, teniendo
en cuenta las buenas prcticas que la describen, y para otros, sencillamente se
traduce en encontrar una alternativa al desarrollo que se ha venido practicando.
Dentro de las metodologas actuales que son adoptadas regularmente , de acuerdo
con las caractersticas de los proveedores y los clientes, se tienen las siguientes:

Alternativas y diversidad

El desarrollo de aplicaciones usando herramientas generadoras de cdigo de forma automtica.

Aplicaciones con enfoque orientado a objetos con lo que se busca reutilizacin de objetos y
componentes existentes.

El desarrollo incremental para reducir el tiempo requerido en la construccin de una aplicacin.

El desarrollo externo o paquetes adquiridos que soportan algunas funcionalidades de las

organizaciones.

En algunos casos, se contratan proveedores que desarrollen las aplicaciones que se requieren
centrndose en el negocio ms no en la forma en que lo desarrollen, esto conocido como
outsourcing.

y por ltimo se tiene como metodologa un plan de contingencia, esto es, diferentes enfoques
desde el punto de vista de las tcnicas y herramientas a utilizar para una misma aplicacin,

METODOLOGIAS AGILES

Este tipo de modelos confan en los prototipos y dan un mejor

resultado en los proyectos pequeos a diferencia que los modelos
estructurados.

Tambin son muy tiles debido a que se adaptan ms rpido y

mejor a los cambios en los requerimientos, pero su documentacin
esmnima.

Scrum

El scrum esta basado en Sprints, que son los trabajos o tareas a realizar por el
equipo por un tiempo, generalmente por mes. Podemos definir que este modelo
esta basado en Roles, Artefactos y Reuniones

Roles
Scrum

Master

Administra

Product

todas las actividades, gente dentro del Sprint

Owner

Mejor

conocido como el cliente, el cual es el que necesita su

producto en los proximos 30 dias o ciclo de Sprint

Team
La

gente que desarrolla la aplicacin.

Scrum
Artefactos
Los artefactos es mejor entenderlos en este modelo como los documentos necesarios o
que se realizan durante el desarrollo del producto.
Backlog de Producto
En

este documento se vacian todos los requerimientos del sistema prioritizados. Este
documento es creado durante la reunion de la planeacion del Sprint

Backlog de Sprint
En

este documento de vacian los requerimientos a trabajar durante el Sprint en curso

Burn Down Chart

Este

documento es creado diario, ya que en este se vacian todos los problemas

detectados para darle el seguimiento necesario. Tambien se vacian las tareas
realizadas, inconclusas o no realizadas

Scrum
Reuniones

Reunion de la planeacion del Sprint (Scrum Planning Meeting)

Reunion donde se decide como distribuir las tareas y como se realizaran

los sprints

Reunion diaria (Daily Standup Meeting)

Reunion donde se da el estatus de lo que se realizo en todo el dia

Revicion de Sprint (Sprint Review)

Reunion para revizar los problemas encontrados durante el Sprint

Retrospectiva de Sprint (Sprint Retrospective)

VENTAJAS DEL SCRUM

Flexibilidad a cambios

Reduccin del tiempo

Mayor calidad del software

Mayor productividad

Maximiza el retorno de la inversin

Predicciones de tiempos

Reduccin de riesgos

RUP

Es una metodologa cuyo fin es entregar un

producto de software. Se estructura todos los
procesos y se mide la eficiencia de la organizacin,
el cual utiliza el lenguaje unificado de modelado
UML, constituye la metodologa estndar ms
utilizada para el anlisis, implementacin y
documentacin de sistemas orientados a objetos.

Principales caractersticas

Forma disciplinada de asignar tareas y responsabilidades

(quin hace qu, cundo y cmo)

Pretende implementar las mejores prcticas en Ingeniera de

Software

Desarrollo iterativo

Administracin de requisitos

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual del software

Verificacin de la calidad del software

La metodologa RUP tiene 6 principios clave:

1.Adaptacin del proceso:El proceso debe adaptarse a las caractersticas de la
organizacin para la que se est desarrollando el software.
2.Balancear prioridades:Debe encontrarse un balance que satisfaga a todos los
inversores del proyecto.
3.Colaboracin entre equipos:Debe haber una comunicacin fluida para coordinar
requerimientos, desarrollo, evaluaciones, planes, resultados, entre otros.
4.Demostrar valor iterativamente:Los proyectos se entregan, aunque sea de una
forma interna, en etapas iteradas. En cada iteracin se evaluar la calidad y estabilidad
del producto y analizar la opinin y sugerencias de los inversores.
5.Elevar el nivel de abstraccin:Motivar el uso de de conceptos reutilizables.
6.Enfocarse en la calidad:La calidad del producto debe verificarse en cada aspecto
de la produccin.

Elementos del RUP

Actividades: Procesos que se han de realizar en

cada etapa/iteracin.

Trabajadores: Personas involucradas en cada

actividad del proyecto.

Artefactos: Herramientas empleadas para el

desarrollo del proyecto. Puede ser un documento,
un modelo, un elemento del modelo.

eXtreme Programming o XP

Es el ms destacado de losprocesos gilesde desarrollo de

software. Al igual que stos, la programacin extrema se diferencia
de las metodologas tradicionales principalmente en que pone ms
nfasis en la adaptabilidad que en la previsibilidad.

Caractersticas fundamentales

Desarrollo iterativo e incremental: pequeas mejoras, unas tras

otras.

Pruebas unitariascontinuas, frecuentemente repetidas y

automatizadas, incluyendopruebas de regresin. Se aconseja
escribir el cdigo de la prueba antes de la codificacin.

Programacin en parejas: se recomienda que las tareas de

desarrollo se lleven a cabo por dos personas en un mismo puesto.

Frecuenteintegracin del equipo de programacin con el

clienteo usuario. Se recomienda que un representante del cliente
trabaje junto al equipo de desarrollo.

Correccin de todos loserroresantes de aadir nueva

funcionalidad. Hacer entregas frecuentes.

Refactorizacindel cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su
legibilidad y mantenibilidad pero sin modificar su comportamiento.

Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de

cada mdulo en grupos de trabajo distintos, este mtodo promueve el que todo el personal
pueda corregir y extender cualquier parte del proyecto.

Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo
funcione se podr aadir funcionalidad si es necesario.

La programacin extrema apuesta que es ms sencillo hacer algo simple y tener un poco de
trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca utilizarlo.

Roles
Programador

Escribe las pruebas unitarias y produce el cdigo del sistema.

Cliente
Escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Asigna la
prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en
aportar el mayor valor de negocio.
Tester
Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los
resultados en el equipo y es responsable de las herramientas de soporte para pruebas.
Tracker
Es el encargado de seguimiento. Proporciona realimentacin al equipo. Debe verificar el grado de
acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para
mejorar futuras estimaciones.
Entrenador (coach)
Responsable del proceso global. Gua a los miembros del equipo para seguir el proceso
correctamente.
Consultor
Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el
proyecto. Ayuda al equipo a resolver un problema especfico.
Gestor (Big boss)

METODOLOGIAS ESTRUCTURADAS

se basan en la estructuracin y descomposicin funcional de problemas en

unidades ms pequeas interrelacionadas entre s. Representan los procesos,
flujos y estructuras de datos, de una manera jerrquica y ven el sistema como
entradas-proceso-salidas.

Estas metodologas funcionan muy bien con los lenguajes de programacin

estructurados, como por ejemplo el COBOL.

Las metodologas estructuradas hacen fuerte separacin entre los datos y los
procesos. Producen una gran cantidad de modelos y documentacin y se
basan en ciclos de vida en cascada.

MODELO DE DATOS

Un modelo de datos define las reglas por las

cuales los datos son descritos. Esta
descripcin, sin embargo, da una
descripcin completa acerca del significado
de los datos y la forma en que sern usados.
Las operaciones que se permiten efectuar
con los datos deben ser establecidas por los
algoritmos de la aplicacin.

Generalmente las operaciones estn

relacionadas con la estructura de los datos
y tienen validez en el contexto en que
fueron definidos.

MODELO DE DATOS

Los modelos de datos permite realizar abstracciones del mundo, permitiendo

centrarse en los grandes aspectos, sin preocuparse de los detalles
particularidades; as nuestra preocupacin se centra en generar un esquema
de representacin, y no en los valores de los datos.

Los modelos de datos nos permiten capturar parcialmente el mundo, ya que

es improbable generar un modelo que lo capture totalmente.

ELEMENTOS DE UN MODELO DE DATOS

Los elementos de un modelo de datos son los que van a permitir disear un
modelo de datos adecuado para una Base de Datos y estos sirvan para la
definicin de las tablas y su contenido, como tambin como estos se van a
vincular entre s.

ELEMENTOS DE UN MODELO DE DATOS

ATRIBUTO

Losatributosse utilizan para definir a las entidades asignndoles propiedades

descriptivas tales como id, edad o peso. No solo es posible definir atributos en
las entidades sino tambin en las relaciones.
En particular, los atributos identificativos o claves son aquellos que permiten
diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el
atributo identificativo que distingue a un alumno de otro es su cdigo de alumno.

ELEMENTOS DE UN MODELO DE DATOS

ENTIDAD

Lasentidadesson los objetos que existen en el mundo real en forma fsica o

abstracta y se les considera objetos principales sobre los que recogen algn tipo
de informacin y generalmente denotan personas, tem, lugares, cosas o eventos
de inters.
Algunos Ejemplos de entidades:

Una persona. (Se diferencia de cualquier otra persona, incluso siendo

gemelos).

Un automvil. (Aunque sean de la misma marca, el mismo modelo, tendrn

atributos diferentes, por ejemplo, el nmero de placa).

ELEMENTOS DE UN MODELO DE DATOS

RELACION

La relacin entre entidades establece el rea comn en donde dos o ms

entidades comparten el mismo tipo de informacin a travs de sus atributos
comunes. Lasrelaciones representan asociaciones de las entidades en el mundo
real entre una o ms de ellas.
Esto se puede expresar de la siguiente manera; dos personas son amigas o
comparte gusto preferencias, porque a ambos les gusta las mismas cosas o tiene
las misma preferencia, por eso mantiene una relacin de amista, de
compaerismo, de colega, de trabajo, etc. Y de esta forma es como se puede
definir la relacin entre las entidades.

Herramientas CASE para el proceso de

desarrollo de Software
Las Herramientas de Ayuda al Desarrollo deSistemasdeInformacin, surgieron
para intentar dar solucin a losproblemasinherentes a losproyectosde
generacin de aplicaciones informticas: plazos ypresupuestosincumplidos,
insatisfaccin del usuario, escasaproductividady bajacalidadde los desarrollos,
entre otros.
Algunas de estas herramientas se dirigen principalmente a mejorar la calidad,
como es el caso de las herramientas CASE.
Actualmente existe un gran desarrollo y una gran cantidad de este tipo de
herramientas, por lo que se hace difcil la eleccin de una de ellas parael
trabajo, tantopersonalcomo corporativo.

Herramientas CASE para el proceso de

desarrollo de Software

Se puede definir a las Herramientas CASE como

un conjunto deprogramasy ayudas que dan
asistencia a los analistas, ingenieros de software
y desarrolladores, durante todos los pasos
delCiclo de Vidade desarrollo de un Software.

Las Herramientas CASE son un conjunto

demtodos, utilidades ytcnicasque facilitan
laautomatizacindel ciclo de vida del
desarrollo desistemas de informacin,
completamente o en alguna de sus fases.

Herramientas CASE para el proceso de

desarrollo de Software
Tecnologa Case
La tecnologa CASE supone laautomatizacindel desarrollo del software, contribuyendo a mejorar
lacalidady la productividad en el desarrollo de sistemas de informacin y se plantean los siguientes
objetivos:

Permitir la aplicacin prctica de metodologas estructuradas, las cuales al ser realizadas con una
herramienta se consigue agilizar eltrabajo.

Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones.

Simplificar elmantenimientode los programas.

Mejorar y estandarizar ladocumentacin.

Aumentar la portabilidad de las aplicaciones.

Facilitar la reutilizacin de componentes software.

Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilizacin degrficos.

Herramientas CASE para el proceso de

desarrollo de Software
Automatizar:

El desarrollo del software

La documentacin
La generacin del cdigo
El chequeo de errores
Lagestindel proyecto

Permitir:

La reutilizacin del software

La portabilidad del software
La estandarizacin de la documentacin

Herramientas CASE para el proceso de

desarrollo de Software
Componentes de una herramienta case
De una forma esquemtica podemos decir que una herramienta CASE se compone
de los siguientes elementos:
Repositorio

(diccionario) donde se almacenan los elementos definidos o creados por

la herramienta, y cuya gestin se realiza mediante el apoyo de un Sistema de Gestin
de Base de Datos (SGBD) o de un sistema de gestin de ficheros.

Meta

modelo (no siempre visible), que constituye el marco para la definicin de las
tcnicas y metodologas soportadas por la herramienta.

Herramientas CASE para el proceso de

desarrollo de Software

Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la

herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir
de la propia herramienta esquemas de base de datos, programas, etc. que pueden,
a su vez, alimentar otros sistemas.

Comprobacin de errores, facilidades que permiten llevar a cabo un anlisis de la

exactitud, integridad y consistencia de los esquemas generados por la herramienta.

Interfaz de usuario, que constar de editores detextoy herramientas de diseo

grfico que permitan, mediante la utilizacin de un sistema de ventanas, iconos y
mens, con la ayuda del ratn, definir losdiagramas,matrices, etc. que incluyen
las distintas metodologas

Herramientas CASE para el proceso de

desarrollo de Software

Clasificacin de las herramientas case

No existe una nica clasificacin de herramientas CASE y, en ocasiones, es difcil

incluirlas en unaclasedeterminada.
Podran clasificarse atendiendo a:
-

Las plataformas que soportan.

Las fases del ciclo de vida del desarrollo de sistemas que cubren.
La arquitectura de las aplicaciones que producen.
Su funcionalidad.

Herramientas CASE para el proceso de

desarrollo de Software

CASE es una combinacin de herramientas software (aplicaciones) y de

metodologas de desarrollo :

1. Las herramientas permiten automatizar el proceso de desarrollo del

software.

2. Las metodologas definen losprocesosautomatizar.

Herramientas CASE para el proceso de

desarrollo de Software

Una primera clasificacin del CASE es considerando su amplitud :

TOOLKIT: es una coleccin de herramientas integradas que permiten automatizar

un conjunto de tareas de algunas de las fases del ciclo de vida del sistema
informtico: Planificacin estratgica, Anlisis, Diseo, Generacin de programas.

WORKBENCH: Sonconjuntosintegrados de herramientas que dan soporte a la

automatizacin del proceso completo de desarrollo del sistema informtico.
Permiten cubrir el ciclo de vida completo. El producto final aportado por ellas es
un sistema en cdigo ejecutable y su documentacin.

Herramientas CASE para el proceso de

desarrollo de Software

Una segunda clasificacin es teniendo en cuenta las fases (y/o tareas) del
ciclo de vida que automatizan:

UPPER CASE: Planificacin estratgica, Requerimientos de Desarrollo Funcional de

Planes Corporativos.

MIDDLE CASE: Anlisis y Diseo.

LOWER CASE: Generacin de cdigo,teste implantacin

Herramientas CASE para el proceso de

desarrollo de Software
Ejemplos de Herramientas CASE
Las herramientas CASE se han venido ampliando y desarrollando, existe una gran
variedad de estas con caractersticas especficas, a continuacin describiremos
algunas de ellas, desde las ms actuales hasta otras ya no tanto.

Herramientas CASE para el proceso de

desarrollo de Software
MicrosoftProject
Microsoft Project es un software deadministracindeproyectosdiseado,
desarrollado y comercializado por Microsoft para asistir a administradores de
proyectos en el desarrollo de planes, asignacin derecursosa tareas, dar
seguimiento al progreso, administrarpresupuestoy analizar cargas
detrabajo.

Herramientas CASE para el proceso de

desarrollo de Software
Racional Rose
Rational Rose es una herramienta
deproduccinycomercializacinestablecidas por
Rational Software Corporation (actualmente parte de
IBM). Rose es un instrumento operativo conjunto que
utilizael LenguajeUnificado (UML) como medio para
facilitar la captura dedominiode lasemntica,
laarquitecturay el diseo.

Este software tiene la capacidad de:

Herramientas CASE para el proceso de

desarrollo de Software
Microsoft Visio

Microsoft Visio es un software de diagramas

para Microsoft Windows.
Usagrficosdevectorespara crear diversos
diagramas.

Facilita a los profesionales empresariales y de

Tecnologas de la Informacin la visualizacin,
el anlisis y lacomunicacinde informacin
compleja. Los diagramas de Visio comunican
informacin de un vistazo, conectados a datos
muestran informacin, son fciles de actualizar
y pueden aumentar espectacularmente
laproductividad..

EL LENGUAJE UNIFICADO DE MODELADO (UML)

El modelado sirve no solamente para los grandes

sistemas, aun en aplicaciones de pequeo
tamao se obtienen beneficios de modelado, sin
embargo es un hecho que entre ms grande y
ms complejo es el sistema, ms importante es
el papel de que juega el modelado por una
simple razn: "El hombre hace modelos de
sistemas complejos porque no puede entenderlos
en su totalidad".

EL LENGUAJE UNIFICADO DE
MODELADO (UML)

UML es una tcnica para la especificacin de

sistemas en todas sus fases. Naci en 1994
cubriendo los aspectos principales de todos los
mtodos de diseo antecesores y,
precisamente, los padres de UML son Grady
Booch, autor del mtodo Booch; James
Rumbaugh, autor del mtodo OMT e Ivar
Jacobson, autor de los mtodos OOSE y
Objectory.

La versin 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, aeronutica, finanzas, etc.

EL LENGUAJE UNIFICADO DE
MODELADO (UML)
Los principales beneficios de UML son:

Mejores tiempos totales de desarrollo (de 50 % o ms).

Modelar sistemas (y no slo de software) utilizando conceptos orientados a objetos.

Establecer conceptos y artefactos ejecutables.

Encaminar el desarrollo del escalamiento en sistemas complejos de misin crtica.

Crear un lenguaje de modelado utilizado tanto por humanos como por mquinas.

Mejor soporte a la planeacin y al control de proyectos.

Alta reutilizacin y minimizacin de costos.

EL LENGUAJE UNIFICADO DE
MODELADO (UML)
UML, Mtodo o Lenguaje de Modelado?

UML es un lenguaje para hacer modelos y es independiente de los mtodos de

anlisis y diseo. Existen diferencias importantes entre un mtodo y un
lenguaje de modelado. Unmtodoes una manera explcita de estructurar el
pensamiento y las acciones de cada individuo. Adems, el mtodo le dice al
usuario qu hacer, cmo hacerlo, cundo hacerlo y por qu hacerlo; mientras
que el lenguaje de modelado carece de estas instrucciones. Los mtodos
contienen modelos y esos modelos son utilizados para describir algo y
comunicar los resultados del uso del mtodo.

EL LENGUAJE UNIFICADO DE
MODELADO (UML)

Un modelo es expresado en unlenguaje de modelado. Un lenguaje de

modelado consiste de vistas, diagramas, elementos de modelolos smbolos
utilizados en los modelosy un conjunto de mecanismos generales o reglas
que indican cmo utilizar los elementos. Las reglas son sintcticas,
semnticas y pragmticas

Vistas:

Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una
grfica, pero s una abstraccin que consiste en un nmero de diagramas y todos esos
diagramas juntos muestran una "fotografa" completa del sistema. Las vistas tambin
ligan el lenguaje de modelado a los mtodos 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 Lgica: Muestra cmo se disea la funcionalidad dentro del sistema, en trminos
de la estructura esttica y la conducta dinmica del sistema.

Vista de Componentes: Muestra la organizacin de los componentes de cdigo.

Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los

problemas con la comunicacin y sincronizacin que estn presentes en un sistema
concurrente.

Vista de Distribucin: muestra la distribucin del sistema en la arquitectura fsica con

computadoras y dispositivos llamadosnodos.

Diagramas

Los diagramas son las

grficas que describen el
contenido de una vista. UML
tiene nueve tipos de
diagramas que son
utilizados en combinacin
para proveer todas las vistas
de un sistema: diagramas de
caso de uso, de clases, de
objetos, de estados, de
secuencia, de colaboracin,
de actividad, de
componentes y de
distribucin.

Smbolos 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
asociacin, dependencia y generalizacin. Un elemento de modelo es
utilizado en varios diagramas diferentes, pero siempre tiene el mismo
significado y simbologa.

Reglas o Mecanismos generales

Proveen comentarios extras, informacin o semntica acerca del elemento de

modelo; adems proveen mecanismos de extensin para adaptar o extender
UML a un mtodo o proceso especfico, organizacin o usuario.

FASES DEL DESARROLLO DE UN SISTEMA

Las fases del desarrollo de sistemas que soporta UML son:Anlisis de

requerimientos,Anlisis,Diseo,ProgramacinyPruebas.

Anlisis de Requerimientos

UML tiene casos de uso (use-cases) para capturar los requerimientos del
cliente. A travs del modelado de casos de uso, los actores externos que
tienen inters 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 jerarquas. 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 anlisis de requerimientos puede
ser realizado tambin para procesos de negocios, no solamente para sistemas
de software.

Anlisis

La fase de anlisis abarca las abstracciones primarias (clases y objetos) y

mecanismos que estn 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
tambin se consideran en esta fase a travs de los modelos dinmicos en
UML. Es importante notar que slo se consideran clases que estn en el
dominio del problema (conceptos del mundo real) y todava 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.

Diseo

En la fase de diseo, el resultado del anlisis es expandido a una solucin

tcnica. Se agregan nuevas clases que proveen de la infraestructura tcnica:
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 anlisis son agregadas en esta fase. El diseo
resulta en especificaciones detalladas para la fase de programacin.

Programacin

En esta fase las clases del diseo son convertidas a cdigo en un lenguaje de
programacin orientado a objetos. Cuando se crean los modelos de anlisis y
diseo en UML, lo ms aconsejable es trasladar mentalmente esos modelos a
cdigo.

Pruebas

Normalmente, un sistema es tratado en pruebas de unidades, pruebas de

integracin, pruebas de sistema, pruebas de aceptacin, etc. Las pruebas de
unidades se realizan a clases individuales o a un grupo de clases y son
tpicamente ejecutadas por el programador. Las pruebas de integracin
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 aceptacin conducidas por el cliente verifican que el sistema
satisface los requerimientos y son similares a las pruebas de sistema.