Estandar de Uml Para Ppi

5/9/2018 Estandar de Uml Para Ppi - slidepdf.com

http://slidepdf.com/reader/full/estandar-de-uml-para-ppi 1/12

UML PARA PPI

Versión 1.0

Documento de Estándar para PPI

Versión 1.0



UML para PPI Versión : 1.0


Página 2 de 12

Historial de Revisiones

Fecha Versión Descripción Autor

22/07/2010 1.0 Estándares de UML Adriana Reyes Gamboa

Revisión





Página 3 de 12

Tabla de Contenidos

Historial de Revisiones ................................ ................................ .............................. 2 Tabla de Contenidos ................................ ................................ ................................ .. 3 Estándares de UML ................................ ................................ ................................ ... 4

1. Introducción ................................ ................................ ................................ .......... 4

1.1. Definiciones, acrónimos y abreviaturas ................................ ...................... 4 1.1.1 Definiciones ................................ ................................ ............................ 4

2. Estándares ................................ ................................ ................................ ............. 5 2.1. Diagramas de Casos de Uso ................................ ................................ ...... 5 2.2. Descripción de los Casos de Uso de ................................ ........................... 6 2.3. Diagrama de Clases ................................ ................................ ................... 7 2.4. Diagrama de Secuencia................................ ................................ .............. 8 2.5. Diagrama de Estados ................................ ................................ ............... 10 2.6. Diagrama de Componentes ................................ ................................ ...... 11 2.7. Arquitectura de Software ................................ ................................ ......... 11





Página 4 de 12

Estándares de UML

1. Introducción

EL objetivo de este documento es describir los estándares de UML del sistema, para ser aplicado en el Proyecto Pedagógico Integrador (PPI). A la vez de establecer el esquema ylos pasos a seguir en la elaboración de los siguientes diagramas: Diagramas de Casos deUso, Diagrama de clases, Diagrama de secuencias, Diagrama de estados, Diagrama decomponentes y Arquitectura de Software.

1.1. Definiciones, acrónimos y abreviaturas

1.1.1 Definiciones

Nombre del Diagrama Descripción

Diagrama de Caso de Uso

Describe la estructura dinámica del sistema, Sus

actores, casos de uso (funcionalidades del sistema) y

relaciones.

Diagrama de ClasesDescribe la estructura estática del sistema. Muestra

las clases, sus contenidos y sus relaciones.

Diagrama de SecuenciaModela la secuencia lógica, a través del tiempo, delos mensajes entre las instancias.

Diagrama de ComponentesMuestra los componentes del sistema. Se ven loscomponentes, sus interrelaciones, interacciones y sus

interfaces públicas.

Diagrama de EstadosDescribe los estados que pueden tener un objeto ointeracción, así como las transiciones entre dichosestados.





Página 5 de 12

2. Estándares

2.1. Diagramas de Casos de Uso

Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento deun sistema mediante su interacción con los usuarios y/o otros sistemas. O lo que es igual, un

diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una

relación es una conexión entre los elementos del modelo, por ejemplo la relación y la

generalización son relaciones.

En este tipo de diagrama intervienen algunos conceptos nuevos: un actor es una entidad

externa al sistema que se modela y que puede interactuar con él; un ejemplo de actor podría

ser un usuario o cualquier otro sistema.

Relaciones de Casos de Uso

Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML, el

cual describe notación gráfica para esas relaciones.

Inclusión

Es una forma de interacción, un caso de uso dado puede "incluir" otro. El primer caso de uso a

menudo depende del resultado del caso de uso incluido. Esto es útil para extraer

comportamientos verdaderamente comunes desde múltiples casos de usoa una descripción

individual. Desde el caso de uso que lo incluye hasta el caso de uso incluido, con la etiqueta

"«include»". Este uso se asemeja a una expansión de una macro donde el comportamiento del

caso incluido es colocado dentro del comportamiento del caso de uso base. No hay parámetros

o valores de retorno.

Extensión

Es otra forma de interacción, un caso de uso dado, (la extensión) puede extender a otro. Esta

relación indica que el comportamiento del caso de uso extensión puede ser insertado en el

caso de uso extendido bajo ciertas condiciones. La notación es una flecha rayada desde el

caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser útil

para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento

del sistema y su extensión. El extensión se utiliza en casos de uso, un caso de uso a otro caso

siempre debe tener extensión o inclusión

Generalización

En la tercera forma de relación entre casos de uso, existe una relación

generalización/especialización. Un caso de uso dado puede estar en una forma especializada

de un caso de uso existente. La notación es una línea solida terminada en un triángulo dibujado

desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto

orientado a objetos de sub-clases, en la práctica puede ser útil factorizar comportamientoscomunes, restricciones al caso de uso general, descríbelos una vez, y enfréntate a los detalles

excepcionales en los casos de uso especializados.





Página 6 de 12

2.2. Especificación de los Casos de Uso

<Plantilla de especificación de los casos de uso>

Nombre del Caso de Uso

Código del Caso de Uso

Código Requisito asociado

Actor(es)

Descripción

Precondiciones

Flujo Principal

Acción actor Acción sistema

1) 2)

3) 4)

5) 6)

7) 8)

Flujo Alternativo 11) 2)

Flujo Alternativo 2 1) 2)

Postcondiciones

Flujos Alternativos1) 2)

Frecuencia

Importancia

Comentarios

Tabla 1: Formato de Especificación de Casos de Uso





Página 7 de 12

2.3. Diagrama de Clases

Una clase agrupa un conjunto de objetos que contienen atributos o propiedades y sus

acciones.

Figura 2: Clase Abstracta.

Pautas para el nombramiento de una clase:

y El nombre de la clase debe de iniciar con letra Mayúscula.

y Si el nombre de la clase contiene más de una palabra se juntarán sin dejar

espacio en blanco, el inicio de cada palabra se escribirá con letra Mayúscula.

Pautas para el nombramiento de atributos y operaciones o métodos:

y El nombre de los atributos y las operaciones deben iniciar con letra minúscula.

y Si el nombre consta de más de una palabra colocarlas juntas sin dejar espacio, al

inicio de la segunda y posteriores palabras colocarlas al inicio con letra

mayúscula.

Pautas para las asociaciones o relaciones:

y Se emplearan flechas que indican la relación de dos clases, la dirección de la

flecha indica el sentido de la relación con sus respectivos nombres.

y Las relaciones presentan multiplicidad.





Página 8 de 12

Formato para la presentación del diccionario de datos:

Clase:[Nombre de la clase]

Atributo ipo Visibilidad Descripción

atributo 1 string public ...atributo 2 integer protected ...

...

Método isibilidad

Parámetros deentrada

Valores que retornaDescripción

Tipo Descripción Tipo Descripción

Método 1 public integer void ...

Método 2 private void string ...

...

Figura 3: Formato del Diccionario de Datos.

2.4. Diagrama de Secuencia

Los diagramas de secuencia representan la interacción de los objetos en e transcurso deun tiempo mediante eventos. Los objetos se representan por columnas y los mensajespor flechas.

Pautas para los mensajes:

y Los mensajes están formados por un nombre y sus respectivos parámetros.

y Se empleará notas para describir la información más detallada.

Representación Tipo deMensaje

Utilizado para

Simple Para transferir el control de un

objeto a otro.

Sincrónico Para indicar que el objeto que

emitió el mensaje esperará una

respuesta para poder continuar

con su trabajo

Asincrónico Para indicar que el objeto que

emitió el mensaje no esperará

una respuesta para poder

continuar con su trabajo

De Retorno oRespuesta

Para indicar el mensaje deretorno o respuesta.

Tabla 1: Tipos de mensajes utilizados en los diagramas de secuencia.





Página 9 de 12

Pautas para los objetos:

y Se empleará cuadros de activación para describir el tiempo que durará un objetopara terminar una determinada tarea.

y Cuando se desea destruir un objeto se representará con una aspa ³X́ al final dela línea de vida.

Pautas adicionales:

y Los diagramas de secuencia se realizarán de izquierda a derecha y de ar riba

hacia abajo para facilitar la lectura del diagrama.

y La línea vertical del diagrama representa el tiempo de vida del objeto y la

dimensión horizontal muestra la disposición de los objetos.

Figura 4: E jemplo Diagrama de Secuencia.





Página 10 de 12

2.5. Diagrama de Estados

Los diagramas de estado describen el valor que tiene un objeto y sus transiciones en

estados.

Para los diagramas se tendrán en consideración los siguientes patrones:

y El nombre de los estados se escribirá en singular.

y Si el nombre de los estados contiene más de una palabra, estas estaránseparadas por el carácter ³_´.

y El nombre de los estados deben iniciar con letra mayúscula.

y El estado Inicial se nombrará con la palabra Inicio

Figura 5: El grafo contendrá el nombre del estado actual del ob jeto.

y El estado inicial se denotará de la siguiente manera:

Figura 6: Estado Inicial

y El estado final se denotará de la siguiente manera:

Figura 7: Estado Final

y La transición entre estados se representará mediante una flecha y deberáncontener los siguientes elementos:

2.1 Estado Inicial: Estado afectado por la transición2.2 Evento: Evento que hace que se ejecute la transición2.3 Condición: Expresión booleana que es evaluada para que la transición se

ejecute. Sólo sí es verdadera, se ejecuta la transición.2.4 Acción: Operación que se realiza cuando se ejecuta la transición. Por ser

atómica, no puede ser interrumpida por otros eventos hasta completarse2.5 Estado Final: Estado en el cual queda el objeto luego de ejecutarse la

transición

Figura 8: E jemplo Diagrama de Estados.





Página 11 de 12

2.6. Diagrama de Componentes

Se utilizará la notación UML v1.x para el diagrama de componentes.

Las reglas a seguir están detalladas en los estándares de Arquitectura de Software.

2.7. Arquitectura de SoftwarePara mostrar la Arquitectura del Software se utilizarán Diagramas de Componentes y

Diagramas de Despliegue.

Se utilizará un Diagrama de Componentes para mostrar los componentes ejecutables

(*.exe, *.dll, etc.) y de base de datos.

Símbolos del Diagrama de Componentes Símbolo Significado

Componente: Ejecutable en undispositivo de hardware.

Interface: Colección de operaciones

ofrecida por el componente.

Dependencia: Relación de dependenciaentre componentes.

Se utilizará un Diagrama de Despliegue para mostrar los nodos (dispositivos de hardware)

en los que se ejecutarán los componentes.

Símbolos del Diagrama de Despliegue

Símbolo SignificadoDispositivo de hardware (Servidor, PC,etc.)

Comunicación: Relación entre nodos queimplica comunicación directa.

Se deberán indicar los componentes que se ejecutan en cada nodo, utilizando una tabla

como la siguiente:

Tabla de Despliegue de ComponentesDispositivo de hardware Componentes

Nombre del Dispositivo de hardware Nombre Componente 1Nombre Componente 2





Página 12 de 12

REFERENCIAS

Braude Eric. Ingeniería de Software. Una perspectiva orientada a objetos.

Alfaomega Grupo Editor S.A. 2003.

Booch G; Rumbaugh J; Jacobson I. El Lenguaje Unificado de Modelado. UML 2.0

Addison Wesley. 2006.Ian Sommerville, Ingeniería del Software, Séptima edición, Pearson Addison

Wesley, 2005

Larman Craig. UML y Patrones. Segunda edición. Prentice Hall. 2003.

Pressman Roger S. Ingeniería del Software. Un enfoque práctico. Mc Graw Hill. 6a.

Edición. 2005.

Estandar de Uml Para Ppi

Documents

Transcript of Estandar de Uml Para Ppi