Tcnicas del modelado de UML

La participacin en este tipo de tcnica desarrolla habilidades tales como

el anlisis, sntesis y evaluacin de la informacin.
Posibilita tambin el desarrollo del pensamiento crtico, el

trabajo

en

equipo y la toma de decisiones.

Modelado de Casos de Uso: El modelado de Casos de Uso es la

tcnica ms efectiva y a la vez la ms simple para modelar los
requisitos del sistema desde la perspectiva del usuario. Los Casos de
Uso se utilizan para modelar cmo un sistema o negocio funciona
actualmente, o cmo los usuarios desean que funcione. No es
realmente una aproximacin a la orientacin a objetos; es realmente
una forma de modelar procesos. Es, sin embargo, una manera muy
buena de dirigirse hacia el anlisis de sistemas orientado a objetos.
Los casos de uso son generalmente el punto de partida del anlisis
orientado a objetos con UML. Un estudio a fondo de UML El modelo
de casos de uso consiste en actores y casos de uso. Los actores
representan usuarios y otros sistemas que interaccionan con el
sistema. Se dibujan como "muecos" de palo. Actualmente
representan el tipo de usuario, no una instancia de usuario. Los
casos de uso representan el comportamiento del sistema, los
escenarios que el sistema atraviesa en respuesta a un estmulo

desde un actor. Se dibujan como elipses.

Diagramas de Secuencia: El Diagrama de Secuencia es uno de los
diagramas ms efectivos para modelar interaccin entre objetos en
un sistema. Un diagrama de secuencia se modela para cada caso de
uso. Mientras que el diagrama de caso de uso permite el modelado
de una vista del escenario, el diagrama de secuencia contiene

detalles de implementacin del escenario, incluyendo los objetos y

clases que se usan para implementar el escenario, y mensajes

pasados entre los objetos.

Diagramas de Colaboracin:

El Diagrama de Colaboracin

presenta una alternativa al diagrama de secuencia para modelar

interacciones entre objetos en el sistema. Mientras que el diagrama
de secuencia se centra en la secuencia cronolgica del escenario
que estamos modelando, el diagrama de colaboracin se centra en
estudiar todos los efectos de un objeto dado durante un escenario.
Los objetos se conectan por medio de enlaces, cada enlace
representa una instancia de una asociacin entre las clases
implicadas.

Modelos de UML
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.
Un mtodo es 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
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 un lenguaje de modelado. Un lenguaje de

modelado consiste de vistas, diagramas, elementos de modelo los
smbolos utilizados en los modelos y un conjunto de mecanismos
generales o reglas que indican cmo utilizar los elementos. Las reglas son
sintcticas, semnticas y pragmticas
De igual forma se constituye el modelo de la siguiente manera:
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 llamados nodos.
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.

Tcnicas de Construccin del Modelo

Las fases del desarrollo de sistemas que soporta UML son:

Anlisis de requerimientos
Anlisis
Diseo
Programacin
Pruebas.

Anlisis de Requerimientos
UML tiene casos de uso 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 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 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 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.

Modelo Esttico y Modelo Dinmico

Modelo Esttico
Este modelo tiene la tarea de modelar la estructura esttica de nuestro
sistema, mostrndonos las clases, objeto y relaciones que existen dentro del
sistema.
Ahora este modelo tiene dos herramientas para mostrar de una manera
ms grafica el comportamiento esttico del sistema, estas son El diagrama
de Clases y El diagrama de Objetos.
El diagrama de clases como sus nombre indica, solo hace uso de clases
para representar el sistema, mientras el diagrama de objetos usa los objetos
instanciados del diagrama de clases, por lo cual para hacer un diagrama de
objetos, antes se debe realizar el diagrama de clases. El diagrama de clases
usa los siguientes smbolos para modelar el sistema.
Clases: Para definir niveles de acceso se usa la siguiente nomenclatura:
+ (Publico)
# (Protegido)
- (Privado)
Seguido al nombre del atributo o mtodo, se puede definir el tipo que
representa o que devuelve (solo mtodos), para hacer esto deberemos de
seguir la siguiente nomenclatura:
Nombre_Atributo/Metodo: Tipo_Dato

De igual modo para los parmetros de entrada usaremos la misma

nomenclatura.
Relacin de Herencia: La flecha siempre debe de ir apuntando a la
clase padre, la relacin de herencia no tiene multiplicidad ni tampoco se debe
de etiquetar, ya que viene implcito.
Se denota de la siguiente manera:

Relacin de Composicin: Esta relacin al igual que la binaria simple

debe de tener multiplicidad, pero no as etiqueta ya que al igual que la
herencia esto ya viene implcito, como apunte se debe de recordar que el
rombo debe de ir apuntando a la clase que est compuesta de la otra clase

De igual forma se deben tener presente los siguientes conceptos.

Alta Cohesin: Los atributos y operaciones de una clase deben
referenciar a la misma clase y no a atributos o funcionalidades de otras
clases que estn dentro del contexto del problema, en otras palabras, las
clases deben de tener solo atributos y mtodos que le conciernan solo a s
mismas.
Bajo Acoplamiento: Define la caracterstica de un diagrama de clase
donde cada clase debe de tener la mnima cantidad de asociaciones posible

con otras clases, esto nos dice que no hagamos asociaciones intiles entre
clases.
Clave Candidata: Un atributo que debe de tener un valor nico, la clave
candidata se parece al OID, pero a diferencia de esta, en la clave candidata
se puede modificar su valor o eliminar el valor.

Modelo Dinmico.
El modelo dinmico tiene la tarea de mostrar el comportamiento del
sistema durante el transcurso del tiempo o mejor dicho en funcin al tiempo.
El modelo dinmico al igual que el esttico tiene dos herramientas para
representar esto, y estas son

El Diagrama de Estado

El diagrama de Sucesos.

MODELOS DE PROCESOS

Un modelo de componentes es una definicin de estndares para la

implementacin, documentacin y el despliegue de componentes.
Los modelos de componentes son:

el modelo Enterprise Java Beans (EJB): La tecnologa de Enterprise

JavaBeans (EJB) es la arquitectura de componentes de servidor para
Java Platform, Enterprise Edition (Java EE). La tecnologa EJB
permite los desarrollos rpidos y simplificados de aplicaciones
distribuidas, transaccionales, seguras y porttiles basadosen la
tecnologa Java.

el modelo COM+ (modelo .NET): se basa en y se extiende

aplicaciones escritas usando COM, MTS, y otras tecnologas basadas
en COM. COM + se encarga de muchas de las tareas de gestin de
recursos que anteriormente haba que programar usted mismo, tales
como la asignacin de rosca y la seguridad. COM + tambin hace que
sus aplicaciones ms escalable, proporcionando conjunto de hilos, la
agrupacin de objetos, y la activacin de objetos just-in-time. COM +
tambin ayuda a proteger la integridad de sus datos al proporcionar
soporte de transacciones, incluso si una transaccin se extiende por
varias bases de datos en una red.

el modelo de componentes Corba: es un estndar definido por Object

Management Group (OMG) que permite que diversos componentes de
software escritos en mltiples lenguajes de programacin y que corren
en diferentes computadoras, puedan trabajar juntos; es decir, facilita el
desarrollo de aplicaciones distribuidas en entornos heterogneos.

El modelo de componentes especfica como deben ser definidas las

interfaces y los elementos que deben ser incluidos en una definicin de
interface.

Procesos Gerenciales

La aplicacin de procesos, tcnicas y prcticas gerenciales es un factor

crtico de xito en el desarrollo de software.
La calidad del producto, la entrega a tiempo del producto, el cabal
cumplimiento de su presupuesto y el uso eficiente de los recursos humanos y
tecnolgicos asignados a un proyecto de software son slo posibles
mediante la aplicacin de procesos gerenciales.
El modelo de procesos del Mtodo WATCH emplea un conjunto de
procesos gerenciales, muchos de los cuales son propuestos por el estndar
IEEE 1074 [IEEE95] para la elaboracin de modelos de procesos de
software. Sus principales actividades y los productos asociados al desarrollo
de aplicaciones empresariales bajo el mtodo WATCH son las siguientes:

Gestin de proyecto

Gestin de la calidad del Software

Gestin de Configuracin del Software

Verificacin y Validacin

Gestin de riesgos

Adiestramientos

Documentacion.

Los procesos gerenciales son responsabilidad del lder del proyecto.

Estas actividades se realizan a lo largo del proceso de desarrollo de
la aplicacin empresarial.

Muchas de la actividades gerenciales indicadas en la Tabla 1 estn

estrechamente vinculadas a las actividades tcnicas del desarrollo del
proyecto y se describen con mayor detalle en las fases 1-8.

Bibliografa:
http://www.adictosaltrabajo.com/tutoriales/umlintro/
http://www.monografias.com/trabajos28/proyecto-uml/proyecto-uml.shtml

https://matriarm.wordpress.com/desarrollo-basado-en-componentes/
http://aprenderaprogramar.com/index.php?
option=com_content&view=article&id=688:ique-es-y-para-que-sirve-umlversiones-de-uml-lenguaje-unificado-de-modelado-tipos-de-diagramasuml&catid=46:lenguajes-y-entornos&Itemid=163
http://alvearjofre.galeon.com/
http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-softwarei/materiales-de-clase-1/is1-t02-trans.pdf
http://www.ctr.unican.es/asignaturas/mc_oo/doc/m_dinamico.pdf