CRC

Es un tcnica de modela miento que facilita la visualizacin del sistema y para comenzar a desarrollar los diagramas del uml, es muy til porque en l se puede mostrar de forma fcil la informacin ms relevante. Su estructura es muy bsica, Es una tarjeta con tres secciones y espacio para su respectiva descripcin: 1. Clases: son todas las acciones, propiedades o cosas que requiera es sistema cumplir, pueden ser los requerimientos que se utilizan para los casos de uso, pero no necesariamente tienen que ser estos. 2. Responsabilidades: Se refieren a las responsabilidades que esta clases tiene dentro del sistema o subsistema. 3. Colaboraciones: Son las clases necesarias para cumplir las responsabilidades que tiene la clases. Al analizar las tarjetas se puede determinar en base a sus relaciones (colaboraciones) subsistemas y dependencias que facilitara el trabajo a la hora de desarrollar los diagramas de clases y casos de uso. Ejemplo de tarjeta CRC: Clase: Recepcionista responsabilidad Registrar Huspedes Facturar consumo Colaboraciones Registro cliente, registro habitacin Obtener lista de consumos, obtener registro de habitacin, registrar pago, abrir caja, informar a camareras la habitacin sucia ..... ... .

...... ... .

DIAGRAMA DE OBJETOS
Los diagramas de objetos son utilizados durante el proceso de Anlisis y Diseo de los sistemas informticos en la metodologa UML. Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias especficas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notacin es similar a los diagramas de clase. Una diferencia con los diagramas de clase es que el compartimiento de arriba va en la forma, Nombre de objeto: Nombre de clase. Por ejemplo, Miguel: Persona. Alfredo ArcosObtenido de "http://es.wikipedia.org/wiki/Diagrama_de_objetos"

Los diagramas de objetos. En UML, los diagramas de clase se utilizan para visualizar los aspectos estticos del sistema y los diagramas de interaccin se utilizan para ver los aspectos dinmicos del sistemas, y constan de instancias de los elementos del diagrama de clases y mensajes enviados entre ellos. En un punto intermedio podemos situar los diagramas de objetos, que contiene un conjunto de instancias de los elementos encontrados en el diagrama de clases, representando slo la parte esttica de un interaccin, consistiendo en los objetos que colaborar pero sin ninguno de los mensajes intercambiados entre ellos. Los diagramas de objetos se emplean para modelar la vista de dise no esttica o la vista de procesos esttica de un sistema al igual que se hace con los diagramas de clases, pero desde la perspectiva de instancias reales o prototpicas. Esta vista sustenta principalmente los requisitos funcionales de un sistema. Los diagramas de objetos permiten modelar estructuras de datos estticas, En general los diagramas de objetos se utilizan para modelar estructuras de objetos, lo que implica tomar una instantnea de los objetos de un sistema en un cierto momento. Un diagrama de objetos representa una escena esttica dentro de la historia representad a por un diagrama de interaccin. Los diagramas de objetos se utilizan para visualizar, especificar, construir y documentar la existencia de ciertas instancias en el sistema, junto a las relaciones entre ellas. Figura 3.12: Modelado de estructuras de objetos

http://www.youtube.com/watch?v=218TvjXZfi8&feature=related

DIAGRAMAS DE ESTADOS
Definicin: Los diagramas de estados son grafos dirigidos cuyos nodos representan posibles estados de un autmata y cuyos arcos representan la posibilidad de pasar de un estado a otro. La posibilidad de usar esa transicin suele venir indicada con una condicin sobre la entrada o sobre las variables del autmata. Un diagrama de estado debe tener un estado inicial y al menos un estado de salida. Jugabilidad: En resumidas cuentas un diagrama de estados es una representacin grfica para un autmata. Un autmata es un programa que pasa a un estado u otro en funcin de las variables de

entrada y del estado anterior. No tiene que hacer nada, solo cambiar de estado cuando debe. Pero en diseo de videojuegos, podemos aprovechar este comportamiento para que cada estado simule una determinada situacin, con lo que podemos emular comportamientos o movimientos o reacciones inteligentes. Por ejemplo, en el tema de movimiento, si tenemos un juego en el que queremos que un enemigo patrulle una determinada zona, podemos usar un diagrama de estados para hacerlo. Creamos tantos nodos como vertices tenga el polgono que define la ruta a seguir por el patrullero, luego creamos al autmata que cambia de un estado al siguiente si y solo si el patrullero lleg al punto indicado en ese nodo y sino permanece en el nodo y manda al patrullero la orden de avanzar en la direccin del punto.

Pero, adems de para esto, podemos usar los diagramas de estados para simular comportamientos o reacciones de los enemigos. En el mismo patrullero anterior podramos definir otro diagrama de estados que indicara el estado de alerta. En condiciones normales el enemigo est en modo descanso, patrulla pero lleva hacindolo meses y est horriblemente aburrido. Si oye algo o ve algo puede pasar a modo alerta, con lo que estar mucho ms pendiente y tal vez se mueva ms rpido o se quede quieto oteando. Si ve al jugador pasara a modo ataque, y emprendera fuego a la vez que alerta a la base.

Tcnicamente ste diagrama de estado no es correcto al no tener estado de salida, pero en nuestro caso el enemigo patrullara indefinidamente hasta que cambiramos de fase o de zona o resultara muerto en combate. Podramos aadir el nodo Muerto al que se podra llegar desde todos los estados al recibir un evento de colisin con una bala, pero para no emborronar ms el grafo no lo he puesto, tampoco est en los algoritmos de abajo ya que simplemente tendramos que eliminar el objeto (estructura o lo que sea) patrullero en ese caso.

DIAGRAMAS DE INTERACCIN

En los diagramas de interaccin se muestra la forma en que los objetos interactan por medio de mensajes. Hay dos tipos de diagrama de interaccin, ambos basados en la misma informacin, pero cada uno enfatizando un aspecto particular: -

Diagramas de Secuencia o Ilustran las interacciones entre objetos en forma de valla, en el cual los objetos se van agregando a la derecha del diagrama. o FUERTE: muestra la secuencia u ordenacin en el tiempo de los mensajes. Es una notacin mas simple Diagramas de Colaboracin (Diagramas de Comunicacin). o Ilustran las interacciones entre objetos en forma de grafo o red, en el cual los objetos se pueden colocar en cualquier lugar del diagrama. o Dificultan que se vea fcilmente la secuencia de mensajes. o Es mejor para ilustrar bifurcaciones complejas, iteraciones y comportamiento cuncurrente

DIAGRAMA DE SECUENCIA
MUESTRA UNA INTERACCIN ORDENADA SEGN LA SECUENCIA TEMPORAL DE EVENTOS. PERMITE DEFINIR EL ORDEN TEMPORAL DE LAS INTERACCIONES ENTRE DISTINTOS OBJETOS DE UN SISTEMA NORMALMENTE SE HACE PARA ESCENARIOS ESPECFICOS DE UN CASO DE USO, PARA LOS EVENTOS QUE GENRAN CIERTOS ACTORES LOS DIAGRAMAS DE SECUENCIA NO ESTN PENSADOS PARA MOSTRAR LGICAS DE PROCEDIMIENTOS COMPLEJOS.

ELEMENTOS: El EJE VERTICAL REPRESENTA EL TIEMPO, y en el EJE HORIZONTAL SE COLOCAN LOS OBJETOS Y ACTORES participantes en la interaccin, sin un orden prefijado. Muestra los objetos como LNEAS DE VIDA a lo largo de la pgina y con sus interacciones en el tiempo representadas como MENSAJES dibujados como FLECHAS desde la lnea de vida origen hasta la lnea de vida destino. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren. FOCO DE CONTROL: Es una caja de activacin que muestra el periodo en el cual se activa un objeto/actor con la ejecucin de un evento o el envo de un mensaje.

NOTACIN: PARA CUALQUIER TIPO DE ELEMENTO UML, UNA INSTANCIA UTILIZA EL MISMO SMBOLO GRFICO QUE EL TIPO, PERO CON LA CADENA DE TEXTO QUE LO DESIGNA SUBRAYADA.

Venta
CLASE -

: Venta
INSTANCIA

V1: Venta
INSTANCIA NOMBRADA

SINTAXIS DE LOS MENSAJES: o UML CUENTA CON UNA SINTAXIS BSICA PARA LAS EXPRESIONES DE LOS MENSAJES mensaje (parmetro: tipoParametro) : tipoRetorno o SE ESCRIBE SOBRE UNA LNEA CON PUNTA DE FLECHA ENTRE LOS OBJETOS TIPOS DE MENSAJES: Nombre
Mensaje sncrono.

Sintaxis unMensaje (unParmetro)

Semntica
El emisor espera hasta que el receptor regresa de ejecutar el mensaje.

Mensaje asncrono.

El

emisor

enva

el

mensaje

contina

unMensaje (unParmetro)

ejecutando; no espera una respuesta del receptor. Retorno mensaje. de El receptor de un mensaje anterior devuelve el foco del control al emisor de ese mensaje.

Creacin de objeto

El emisor crea una instancia del clasificador especificado por el receptor.

<<create>> unMensaje()

(Crea el objeto A)

:A
Destruccin de El emisor destruye el receptor. Si la lnea de vida tiene una lnea vertical discontinua, se termina con un X.

:A
<<destruct>>

objeto

(Destruye el objeto A)

EJEMPLO:

LOS MENSAJES PUEDEN SER: CONDICIONALES [color=rojo] calcular() CONDICIONAL MUTUALMENTE EXCLUSIVOS [X<10] calcular() [X>15] calcular() ITERACIN PARA UN MENSAJE * [i:=1N]: num:= siguienteEnt()

DIAGRAMA DE COLABORACIN
o o o ILUSTRAN LAS INTERACCIONES ENTRE OBJETOS EN FORMA DE GRAFO O RED, EN EL CUAL LOS OBJETOS SE PUEDEN COLOCAR EN CUALQUIER LUGAR DEL DIAGRAMA. DIFICULTAN QUE SE VEA FCILMENTE LA SECUENCIA DE MENSAJES. ES MEJOR PARA ILUSTRAR BIFURCACIONES COMPLEJAS, ITERACIONES Y COMPORTAMIENTO CUNCURRENTE

NOTACIN: o MENSAJES: SE INDICAN CON LA FLECHA AL LADO DEL NOMBRE DEL MENSAJE (INDICA LA DIRECCIN DEL MENSAJE) o LOS MENSAJES SE NOMBRAN IGUAL Q EN LOS D. DE SECUENCIA o LA SECUENCIA SE INDICA NUMERANDO LOS MENSAJES El mensaje 1 no se numera: ms1, 1. Msj2, 2. Msj3 ENLACE: CAMINO DE CONEXIN ENTRE DOS OBJETOS: INDICA QUE ES POSIBLE UNA FORMA DE NAVEGACIN Y VISIBILIDAD ENTRE LOS OBJETOS MENSAJES A SELF O THIS. o SE PUEDE ENVIAR UN MENSAJE DESDE UN OBJETO A L MISMO.

o o

o o o PARA CREAR INSTANCIAS: ADEMS DE CREATE SE PUEDE AGREGAR LA PROPIEDAD {new} A LA CAJA DE LA INSTANCIA PARRA RESALTAR LA CREACIN

DIAGRAMA DE COMPONENTES
Usados Para Demostrar los Mdulos Fsicosde software:Los ejecutables y librerias dinmicas, Las pginas WEB y los scriptsLos mdulos o funciones, etc. Sin Embargo Ms se Usan En Capturar la Organizacin de los Componentes de Software en estricto rigor (EXE, DLL, EJB, etc)
EJB Bodeguero BodegueroLocal

EJB Vendedor VendedorRemote

executable TouchScreen DAO Venta

Oracle BDPub

Elementos
C o m p o n e n te

Un Componente representa un mdulo fsico del software, una pieza encerrada y completa de cdigo o ejecutable Una Interfaz representa la parte de un componente visible desde afuera del componente accesible por otros componentes
I n te r fa z

Relaciones en Diagramas de Componentes

EJB Vendedor

DAO Venta

Dependencia Un componente hace uso del otro Cambio en un la necesidad dad de cambiar el otro

componente

automticamente

cau causa

Los diagramas de componentes describen el empaquetamiento fsico de elementos lgicos del sistema, tales como clases e interfaces, es decir, representa una unidad de cdigo (fuente, binario y ejecutable) Representan todos los tipos de elementos software que entran en la fabricacin de aplicaciones informticas. Pueden ser: - Simples archivos paquetes bibliotecas cargadas dinmicamente

PHYSICAL VIEW: DEPLOYMENT DIAGRAM

By Wenjun Wang

This paper focuses on the Unified Modeling Language (UML) deployment diagram, a static view of the run-time run time configuration of processing nodes and the components that run on those nodes. It shows both hardware and software partitioning. Page-Jones Jones (2001), Ambler (1999) and Eyrolles (1997) agree that the deployment diagram focuses on a systems infrastructure nodes, depicting system components, objects and the physical arrangement of run-time run time computational computat resources. But each author chooses to emphasize different things when implementing a deployment diagram Page-Jones Jones notes that the deployment diagram is roughly equivalent to the architecture --interconnect interconnect or architecture -- flow diagram. He focuses on associations between nodes that represent communication paths and the associations that have stereotypes to distinguish different kinds of paths. He says that a cube represents each hardware resource, showing the physical presence of the equipment with within the system. A few deployment diagrams can describe any system. Lines connect the nodes in the deployment diagram to each other and solid lines indicate communication connections between nodes. Stereotypes, indicated with <<text>> notation, are a UML mec mechanism for extending the modeling language by defining common types appropriate to the problem domain. Figure 1 shows the mapping between the nodes LCD Display and UI Processor to their physical architectural representation.

Figure 1. Illustrating the use of stereotypes in a deployment diagram Eyrolles views the deployment diagram in much the same way as Page Page-Jones, but Eyrolles dedicates more ore discussion to node -- the node classes and node instances. He says the graphical difference between classes and objects is that objects names receive underlining and class names do not. Physically nesting the object symbol inside the node symbol shows the presence of an object on a node and the object symbol may contain the tag location. Both Page-Jones Jones and Eyrolles concentrate on explaining of nodes. Eyrolles gives more details on nodes association, but both authors ignore the nodes relationship on dependency, pendency, generalization and when a software engineer needs to create the deployment model. Ambler provides the broadest and most accurate material on deployment diagrams, including Page-Jones Page Jones and Eyrolles ideas. He also covers dependency, modeling tips and nd how to determine whether a system needs to apply the UML deployment model in the software process stage. Many software engineers are happy using the core UML diagrams; such as class, use-case, use case, state and collaboration. But Ambler gives special attention to the deployment diagram, even though it usually gets little attention. Besides Page-Jones Page Jones and Eyrolles ideas, three suggestions on how and

when to apply UML deployment diagrams throughout the software process that Ambler proposes. First, Ambler discusses node dependencies, the connections between two components (sometimes through interfaces). Dotted lines with arrowheads show dependencies between nodes. Second, software engineers need to determine whether a project needs to create the deployment model? This is a common question for software engineers who are in charge of the UML modeling process. Its very clear that the software engineers must implement UML core diagrams, but what about the deployment diagram and the component diagram? When? Why? Ambler presents a simple way to answer these questions. Ask and answer the following question: If a software engineer know nothing about the system and someone asks him to either install or maintain it, would he wants a description of how the systems parts fit together? If the answer is yes, Ambler says develop a deployment diagram. Amblers practice shows that deployment modeling is well worth it -- deployment models force software engineers to think about important deployment issues long before they must deliver the system. Third, software engineers should perform the deployment modeling early in the projects life cycle and update it throughout the project as needed. Ambler says, deployment is a difficult process that software engineers should start early in the life cycle, the process begins with requirements definition during the Inception phase, continues with deployment modeling and deployment planning during the Elaboration and Construction phases, and lead to deployment of the system workflow starting late in the project life cycle. He says that deployment modeling is a key component of the deployment workflow and incorporating the UML deployment diagram into system development efforts will increase the chances of delivering the system successfully. As a result, deployment modeling and the deployment workflow are an important part of system development models. Based on Amblers discussion, Figure 2 depicts a UML deployment diagram for a university administration system. This figure depicts how software engineers deploy major software components into the production environment, enables the project team to identify its deployment strategy.

Figure 2. A Project-Specific UML Deployment Diagram

In conclusion, three authors suggested that the deployment diagram shows run-time architecture of processors and devices, and visualizes the configuration of physical processing elements and the software components that execute on the processing elements. The first two authors emphasize on how to implement the deployment diagram, and the third author emphasizes how and when software engineers need to apply the deployment diagram in the software process stage. This researcher believes that Amblers deployment diagram explanations give a fuller and clearer picture of a system than the methods of other authors. The deployment diagram is an important model for increasing the chance of successfully deliverin system. REFERENCES 1. Ambler, S. (1999, April). UML Deployment Modeling and Beyond. Available: http://www.sdmagazine.com/documents/s=759/sdm9904o/9904o.htm 2. Eyrolles, A. (1997) Deployment Diagram. Available: http://msdn.microsoft.com/library/default.asp?url=/library/enus/dniuml/html/deploymentdiagrams.asp 3. PageJones, M. (2001). Fundamentals of Object-Oriented Design in UML. Reading, MA: Addison-Wesley, Inc. 4. Pressman, R. S. (2001). Software Engineering, A Practitioner's Approach. (5th ed.). New York, NY: McGraw-Hill, Inc 5. Rumbaugh, J., Jacobson, I & Booch, G. (1999). The Unified Modeling Language Reference Manual. Reading, MA: Addison-Wesley, Inc.