Metodologas de desarrollo de software

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 metodologasEn 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 AGILESEste 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.

ScrumEl 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

RolesScrum MasterAdministra todas las actividades, gente dentro del SprintProduct OwnerMejor conocido como el cliente, el cual es el que necesita su producto en los proximos 30 dias o ciclo de SprintTeamLa gente que desarrolla la aplicacin.

ScrumArtefactosLos artefactos es mejor entenderlos en este modelo como los documentos necesarios o que se realizan durante el desarrollo del producto.

Backlog de ProductoEn este documento se vacian todos los requerimientos del sistema prioritizados. Este documento es creado durante la reunion de la planeacion del SprintBacklog de SprintEn este documento de vacian los requerimientos a trabajar durante el Sprint en cursoBurn Down ChartEste 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

ScrumReunionesReunion 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)Se realiza despues de cada Sprint para revizar lo que se realizo bien, que necesita mas trabajo y cosas por el estilo.

VENTAJAS DEL SCRUMFlexibilidad a cambiosReduccin del tiempoMayor calidad del softwareMayor productividadMaximiza el retorno de la inversinPredicciones de tiemposReduccin 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 SoftwareDesarrollo iterativoAdministracin de requisitosUso de arquitectura basada en componentesControl de cambiosModelado visual del softwareVerificacin 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 RUPActividades: 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 XPEs 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.

RolesProgramadorEscribe las pruebas unitarias y produce el cdigo del sistema.ClienteEscribe 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.TesterAyuda 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.TrackerEs 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.ConsultorEs 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)Es el dueo de la tienda y el vnculo entre clientes y programadores. Su labor esencial es la coordinacin.

METODOLOGIAS ESTRUCTURADASse 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 DATOSUn 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 DATOSLos 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 DATOSLos 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 DATOSATRIBUTOLosatributosse 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 DATOSENTIDADLasentidadesson 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 DATOSRELACIONLa 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 SoftwareLas 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 SoftwareSe 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 SoftwareTecnologa 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 SoftwareAutomatizar:El desarrollo del softwareLa documentacinLa generacin del cdigoEl chequeo de erroresLagestindel proyecto

Permitir:La reutilizacin del softwareLa portabilidad del softwareLa estandarizacin de la documentacin

Herramientas CASE para el proceso de desarrollo de SoftwareComponentes de una herramienta caseDe 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 SoftwareCarga 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 SoftwareClasificacin 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 SoftwareCASE 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 SoftwareUna 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 SoftwareUna 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 implantacinHerramientas CASE para el proceso de desarrollo de SoftwareEjemplos 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 SoftwareMicrosoftProjectMicrosoft 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 SoftwareRacional 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 SoftwareMicrosoft VisioMicrosoft 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.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

EL LENGUAJE UNIFICADO DE MODELADO (UML)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.

DiagramasLos 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 modeloLos 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 generalesProveen 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 RequerimientosUML 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.