TCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGAS DE LA INFORMACIN Y COMUNICACIN

UNIVERSIDAD TECNOLOGICA DE LA HUASTECA HIDALGUENSE

DOCENTE:

ASIGNATURA:

Ing. Bernardo Del Rosal Yaez

ACTIVIDAD:

Integradora II

ALUMNO: RICARDO HERNANDEZ ALVARADO EFREN HERNANDEZ JUAREZ JOSE RAUL PERALTA PUERTAS CUATRIMESTRE: QUINTO CUATRIMESTRE GRUPO: D

DIAGRAMA DE GANTT, WBS BITACORA

ESPECIALIDAD: SISTEMAS INFORMTICOS

MATRICULA: 2010033 2010030 2010047 HUEJUTLA HIDALGO A 08 DE FEBRERO DEL 2012

Indice

Introduccin del tema Principios de Usabilidad

1.- Diseo de iterfaz de Usuario

1.1.- Principios de Usabilidad
- Facilidad de aprendizaje Bsicamente debemos conseguir tres cosas: que sea mnimo el tiempo que se requiere desde el no conocimiento de una aplicacin a su uso productivo, que se reduzca el tiempo necesario para ayudar en las sesiones de aprendizaje y proporcionar ayuda a usuarios intermedios. - Consistencia Diremos que un sistema es consistente si todos los mecanismos que se utilizan son siempre usados de la misma manera, siempre que se utilicen y sea cual sea el momento en que se haga. - Flexibilidad La flexibilidad se refiere a la multiplicidad de maneras en que el usuario y el sistema intercambian informacin. - Robustez La robustez de una interaccin cubre las caractersticas para poder cumplir sus objetivos y su asesoramiento. - Recuperabilidad Grado de facilidad que una aplicacin permite al usuario para corregir una accin una vez est reconocido un error. - Tiempo de respuesta Se define generalmente como el tiempo que necesita el sistema para expresar los cambios de estado del usuario. Es importante que los tiempos de respuesta sean soportables para el usuario. - Adecuacin de las tareas Grado en que los servicios del sistema soportan todas las tareas que el usuario quiere hacer y la manera en que stas las comprenden. - Disminucin de la carga cognitiva Esto quiere decir que los usuarios tienen que confiar ms en los reconocimientos que en los recuerdos y que los usuarios no tienen que recordar abreviaciones y cdigos muy complicados. [T1-1]

Facilidad de Aprendizaje: facilidad con la que nuevos usuarios desarrollan una interaccin efectiva con el sistema o producto. Est relacionada con la predictibilidad, sintonizacin, familiaridad, la generalizacin de los conocimientos previos y la consistencia.

Facilidad de Uso: facilidad con la que el usuario hace uso de la herramienta, con menos pasos o ms naturales a su formacin especfica. Tiene que ver con la eficacia y eficiencia de la herramienta.

Flexibilidad: relativa a la variedad de posibilidades con las que el usuario y el sistema pueden intercambiar informacin. Tambin abarca la posibilidad de dilogo, la multiplicidad de vas para realizar la tarea, similitud con tareas anteriores y la optimizacin entre el usuario y el sistema.

Robustez: es el nivel de apoyo al usuario que facilita el cumplimiento de sus objetivos. Est relacionada con la capacidad de observacin del usuario, de recuperacin de informacin y de ajuste de la tarea al usuario. [T1-2]

1.2.- Tipos de estndares (Facto e Iure)

QU ES UN ESTNDAR? Un estndar, tal como lo define la ISO "son acuerdos documentados que contienen especificaciones tcnicas u otros criterios precisos para ser usados consistentemente como reglas, guas o definiciones de caractersticas para asegurar que los materiales, productos, procesos y servicios cumplan con su propsito". Por lo tanto un estndar de telecomunicaciones "es un conjunto de normas y recomendaciones tcnicas que regulan la transmisin en los sistemas de comunicaciones". Queda bien claro que los estndares debern estar documentados, es decir escritos en papel, con objeto que sean difundidos y captados de igual manera por las entidades o personas que los vayan a utilizar.

TIPOS DE ESTNDARES Existen tres tipos de estndares: de facto, de jure y los propietarios. Los estndares de facto son aquellos que tienen una alta penetracin y aceptacin en el mercado, pero an no son oficiales. Un estndar de jure u oficial, en cambio, es definido por grupos u organizaciones oficiales tales como la ITU, ISO, ANSI, entre otras. La principal diferencia en cmo se generan los estndares de jure y facto, es que los estndares de jure son promulgados por grupos de gente de diferentes reas del conocimiento que contribuyen con ideas, recursos y otros elementos para ayudar en el desarrollo y definicin de un estndar especfico. En cambio los estndares de facto son promulgados por comits "guiados" de una entidad o compaa que quiere sacar al mercado un producto o servicio; s tiene xito es muy probable que una Organizacin Oficial lo adopte y se convierta en un estndar de jure. Por otra parte, tambin existen los "estndares" propietarios que son propiedad absoluta de una corporacin u entidad y su uso todava no logra una alta penetracin en el mercado. Cabe aclarar que existen muchas compaas que trabajan con este esquema slo para ganar clientes y de alguna manera "atarlos" a los productos que fabrica. Si un estndar propietario tiene xito, al lograr ms penetracin en el mercado, puede convertirse en un estndar de facto e inclusive convertirse en un estndar de jure al ser adoptado por un organismo oficial. Un ejemplo clsico del xito de un estndar propietario es el conector RS-232, concebido en los aos 60's por la EIA (Electronics Industries Association) en Estados Unidos. La amplia utilizacin de la interfase EIA-232 dio como resultado su adopcin por la ITU, quin describi las caractersticas elctricas y funcionales de la interfase en las recomendaciones V.28 y V.24 respectivamente. Por otra parte las caractersticas mecnicas se describen en la recomendacin 2110 de la ISO, conocido comnmente como ISO 2110. [T1-3]

1.3.- Guas de Estilo

Qu son los Libros de Estilo? Por qu no se utilizan? Algunas pautas para crear Libros de Estilo para departamentos de tecnologa y desarrollo de aplicaciones. Las reas de Tecnologa y Sistemas de Informacin de las grandes empresas son conscientes de los beneficios de la normalizacin de interfaz en cuanto a su aspecto. En grandes departamentos de tecnologa formados por equipos variados y numerosos cada uno con sus propios usos y metodologa normalizar supone un cambio de metodologa de trabajo que debe abordarse desde una perspectiva global e integradora. La demanda de aplicaciones de negocio de interfaz web y su apertura tanto a usuarios internos como externos (entranet, internet) y la situacin de inconsistencia entre entornos ha despertado una especial sensibilidad por el diseo grfico y la normalizacin. El primer paso hacia la normalizacin suelen ser los Libros de Estilo y los mal llamados Manuales de Usabilidad.

Qu es una Gua de estilo

Es un documento que recoge normativas y patrones bsicos relacionados con el aspecto de un interfaz para su aplicacin en el desarrollo de nuevas pantallas dentro de un entorno concreto. (sitio web de contenidos, nuevas secciones, entorno de aplicaciones de negocio). Hemos dicho aspecto. Desde qu otras perspectivas debera abordar una Gua de Estilo? Las tres facetas de un interfaz:

Conceptualmente, el interfaz de usuario descansa en 3 puntos: Significado (qu): es la base del interfaz. Recoge el contenido o informacin de la pantalla. Textos, campos de formularios, botones, mens Comportamiento: trata el funcionamiento del interfaz. Cmo se comporta cuando un usuario enva un formulario (validaciones), hace clic en un enlace Aspecto: apariencia final de un sistema: colores, tipografa, disposicin de los elementos en pantalla (layout).

Las Guas de Estilo, generalmente se centran en el Aspecto. Puntos como diseo y maquetacin (colores, tipografas y pxeles), y apenas incluye criterios o casustica para aplicar en el proceso de diseo de interfaz (Significado).

Las Guas de Estilo no son Manuales de Usabilidad

A menudo se confunde el trmino Gua de Estilo con Gua de Usabilidad y un cambio de diseo lleva a definirse como una nueva usabilidad. (Necesitamos adaptar las aplicaciones antiguas a la nueva usabilidad (sic)). Hay personas que identifican aspecto y usabilidad: esto lleva a que dos aplicaciones pueden ser radicalmente opuestas en usabilidad cumpliendo ambas las pautas de una Gua de Estilo. Poniendo por ejemplo un coche: Desde una perspectiva de significado un coche se adapta a un uso por sus caractersticas (carretera, familiar, pequeo, todoterreno, descapotable) y no por su color (aspecto). Identificar usabilidad y diseo equivale a decir: Quiero un coche rojo. Para que lo quieres? Carretera, montaa, nios Qu ms da? Que sea rojo. Para que una Gua de Estilo pueda convertirse en un manual de usabilidad debera tocar puntos relacionados con significado ofreciendo criterios para, dentro de un estilo definido, seleccionar las caractersticas que se adapten al destino final de una aplicacin (objetivos+usuarios+contexto).

Destinatarios de las Guas de Estilo

Las Guas de Estilo son creadas inicialmente como documentos voluminosos muy vistosos que ilustran sobre la apariencia del interfaz de un sistema. Su problema ms grave es su falta de usabilidad: Estn pensadas desde una perspectiva de diseo y mrketing y no tienen en cuenta las necesidades de sus verdaderos destinatarios: Diseadores y Programadores de interfaz.

Una buena Gua de Estilo, debe integrarse de manera eficiente en el proceso de trabajo de un programador ofreciendo criterios y ayudando en la toma de decisiones en aspectos de diseo de interfaz. No deben ser una carga: han de ir acompaadas por acciones de promocin y formacin y materiales de apoyo que ahorren trabajo al programador.

Caractersticas de una Gua de Estilo til

Una Gua de Estilo debera abordar la perspectiva del significado del interfaz. Usable: invitar al uso. Debe integrarse de forma cmoda en el proceso de trabajo de un desarrollador dndole respuestas a situaciones propias dentro de la construccin del interfaz de una aplicacin. Visual: huir del texto. Por experiencia, una Gua de Estilo no se usa, y esta probabilidad se reduce drsticamente cuando se basa en texto lo que lleva a una desactualizacin y abandono. Educativa: rica en ejemplos aplicables Y RAZONADOS que permitan desarrollar criterios mnimos de usabilidad y esttica al personal tcnico. Actualizada: debe contener ejemplos tiles, actuales y materiales para su aplicacin directa disponibles a travs de repositorios.

Problemas de las Guas de Estilo: nadie lee

La experiencia demuestra que los equipos de desarrollo no se apoyan en las Guas de Estilo para realizar su trabajo. Razones: Resultan demasiado abstractas y simplistas: se crean desde reas (mrketing, negocio) que carecen de visin de la complejidad del trabajo del desarrollador obviando su problemtica cotidiana. Falta de adecuacin a los mtodos de desarrollo: El desarrollador no tiene tiempo para leer ni asimilar una documentacin que adems de ser voluminosa, le resulta ajena. Demasiado detalle: la documentacin entra en cuestiones de detalle (pixels de separacin entre elementos, tipografas, colores y valores hexadecimales) impropias del trabajo de un desarrollador. Falta de mantenimiento consistente: no existe una poltica de mantenimiento del Manual con una visin integradora de todo el proceso de desarrollo. Falta de apoyo: la Gua se publica sin acciones de promocin, formacin y apoyo. La documentacin caduca por no uso con lo que se vuelve a una situacin similar a la de partida. No tienen utilidad real: no se promueve la reutilizacin de soluciones (conocimiento, componentes) entre los diferentes equipos de desarrollo.

Crear una Gua de Estilos

Desarrollar una Gua de Estilo es un primer paso hacia un cambio cultural en las metodologas de desarrollo que deriva en la adopcin de tcnicas de Diseo Centrado en el Usuario. Es necesario un equipo nico de especialistas en interfaz de usuario con visin horizontal integradora del conjunto de sistemas y procesos de desarrollo que garanticen un entorno de aplicaciones consistente. Los cometidos de este equipo son: Documentar: crear documentacin de carcter visual, compuesta de literatura esencial, ejemplos razonados. Formar: dar charlas introductorias, cursos breves peridicos con el objetivo de desarrollar un criterio de usabilidad. Dar soporte: desde el arranque hasta el cierre del proyecto resolviendo dudas, detectando nuevas necesidades que se puedan plantear e incorporndolas a la Gua. Deteccin de patrones: identificacin de patrones que puedan derivar en componentes de interfaz reutilizables para su uso por los diferentes equipos de desarrollo. Para abstraer al programador de tareas de diseo, estos objetos deben llevar embebidos aspectos visuales y estticos. Deben ser puestos a disposicin de los equipos de programacin a travs de un repositorio nico actualizado. Investigacin e innovacin: tener identificados patrones reutilizables y componentes libera recursos de realizar tareas repetitivas y de escaso valor aadido para la deteccin de lneas de mejora del interfaz, metodologa y procesos de desarrollo. (Adecuacin a estndares tcnicos, accesibilidad, mejoras, tecnologas alternativas). Programar y realizar tests y pruebas con usuarios: conocer la apreciacin de los usuarios de las soluciones incorporadas permitir realizar correcciones e introducir mejoras. [T14]

10

2.- Documentacin en la etapa de documentacin.

2.1.- Diagramas UML en la codificacin.

Acerca de UML
Este captulo proporciona una introduccin rpida a las caractersticas bsicas de UML. Tenga en cuenta que no se trata de un manual de referencia de UML sino de una breve introduccin. Si desea ms informacin sobre UML, o sobre el anlisis y diseo del software en general, le recomendamos que lea cualquier de los libros publicados sobre el tema. Tambin hay una buena cantidad de tutoriales en Internet, que puede utilizar como punto de partida. El lenguaje unificado de diagrama o notacin (UML) sirve para especificar, visualizar y documentar esquemas de sistemas de software orientado a objetos. UML no es un mtodo de desarrollo, lo que significa que no sirve para determinar qu hacer en primer lugar o cmo disear el sistema, sino que simplemente le ayuda a visualizar el diseo y a hacerlo ms accesible para otros. UML est controlado por el grupo de administracin de objetos (OMG) y es el estndar de descripcin de esquemas de software. UML est diseado para su uso con software orientado a objetos, y tiene un uso limitado en otro tipo de cuestiones de programacin. UML se compone de muchos elementos de esquematizacin que representan las diferentes partes de un sistema de software. Los elementos UML se utilizan para crear diagramas, que representa alguna parte o punto de vista del sistema. Umbrello UML Modeller soporta los siguientes tipos de diagramas: Diagrama de casos de uso que muestra a los actores (otros usuarios del sistema), los casos de uso (las situaciones que se producen cuando utilizan el sistema) y sus relaciones. Diagrama de clases que muestra las clases y la relaciones entre ellas. Diagrama de secuencia muestra los objetos y sus mltiples relaciones entre ellos. Diagrama de colaboracin que muestra objetos y sus relaciones, destacando los objetos que participan en el intercambio de mensajes. Diagrama de estado muestra estados, cambios de estado y eventos en un objeto o en parte del sistema. Diagrama de actividad que muestra actividades, as como los cambios de una a otra actividad junto con los eventos que ocurren en ciertas partes del sistema.

11

Diagrama de componentes que muestra los componentes de mayor nivel de la programacin (cosas como Kparts o Java Beans). Diagrama de implementacin que muestra las instancias de los componentes y sus relaciones. Diagrama de relaciones de entidad que muestra los datos y las relaciones y restricciones entre ellos.

Diagrama de casos de uso

Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso. Es importante resaltar que los diagramas de casos de uso no estn pensados para representar el diseo y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicacin con los futuros usuarios del sistema, y con el cliente, y resultan especialmente tiles para determinar las caractersticas necesarias que tendr el sistema. En otras palabras, los diagramas de casos de uso describen qu es lo que debe hacer el sistema, pero no cmo.

12

Caso de uso
Un caso de uso describe, desde el punto de vista de los actores, un grupo de actividades de un sistema que produce un resultado concreto y tangible. Los casos de uso son descriptores de las interacciones tpicas entre los usuarios de un sistema y ese mismo sistema. Representan el interfaz externo del sistema y especifican qu requisitos de funcionamiento debe tener este (recuerde, nicamente el qu, nunca el cmo). Cuando se trabaja con casos de uso, es importante tener presentes algunas secillas reglas: Cada caso de uso est relacionado como mnimo con un actor

Cada caso de uso es un iniciador (es decir, un actor)

Cada caso de uso lleva a un resultado relevante (un resultado con valor intrnseco)

Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de relaciones ms comunes entre casos de uso son: <<include>> que especifica una situacin en la que un caso de uso tiene lugar dentro de otro caso de uso <<extends>> que especifica que en ciertas situaciones, o en algn punto (llamado punto de extensin) un caso de uso ser extendido por otro. Generalizacin que especifica que un caso de uso hereda las caractersticas del super caso de uso, y puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases.

Actor
Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema participando (y normalmente iniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios del sistema), otros ordenadores o eventos externos. Los actores no representan a personas fsicas o a sistemas, sino su rol. Esto significa que cuando una persona interacta con el sistema de diferentes maneras (asumiendo diferentes papeles), estar representado por varios actores. Por ejemplo, una persona que proporciona servicios de atencin telefnica a clientes y realiza pedidos para los clientes estara representada por un actor equipo de soporte y por otro actor representante de ventas.

13

Descripcin de casos de uso

Las descripciones de casos de uso son reseas textuales del caso de uso. Normalmente tienen el formato de una nota o un documento relacionado de alguna manera con el caso de uso, y explica los procesos o actividades que tienen lugar en el caso de uso.

Diagrama de clases
Los diagramas de clases muestran las diferentes clases que componen un sistema y cmo se relacionan unas con otras. Se dice que los diagramas de clases son diagramas estticos porque muestran las clases, junto con sus mtodos y atributos, as como las relaciones estticas entre ellas: qu clases conocen a qu otras clases o qu clases son parte de otras clases, pero no muestran los mtodos mediante los que se invocan entre ellas.

14

Clase
Una clase define los atributos y los mtodos de una serie de objetos. Todos los objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada objetos tiene el suyo propio). En ocasiones se utiliza el trmino tipo en lugar de clase, pero recuerde que no son lo mismo, y que el trmino tipo tiene un significado ms general. En las clases estn representadas por rectngulos, con el nombre de la clase, y tambin pueden mostrar atributos y operaciones de la clase en otros dos compartimentos dentro del rectngulo.

Atributos
En UML, los atributos se muestran al menos con su nombre, y tambin pueden mostrar su tipo, valor inicial y otras propiedades. Los atributos tambin pueden ser mostrados visualmente: + Indica atributos pblicos # Indica atributos protegidos - Indica atributos privados

Operaciones
Las operaciones (mtodos) tambin se muestan al menos con su nombre, y pueden mostrar sus parmetros y valores de retorno. Las operaciones, al igual que los atributos, se pueden mostrar visualmente: + Indica operaciones pblicas # Indica operaciones protegidas - Indica operaciones privadas

Plantillas
Las clases pueden tener plantillas, un valor usado para una clase no especificada o un tipo. El tipo de plantilla se especifica cuando se inicia una clase (es decir cuando se crea un objeto). Las plantillas existen en C++ y se introducirn en Java 1.5 con el nombre de Genricos.

15

Asociaciones de clases
Las clases se puede relaciones (estar asocionadas) con otras de diferentes maneras: Generalizacin La herencia es uno de los conceptos fundamentales de la programacin orientada a objetos, en la que una clase recoge todos los atributos y operaciones de la clase de la que es heredera, y puede alterar/modificar algunos de ellos, as como aadir ms atributos y operaciones propias. En UML, una asociacin de generalizacin entre dos clases, coloca a estas en una jerarqua que representa el concepto de herencia de una clase derivada de la clase base. En UML, las generalizaciones se representan por medio de una lnea que conecta las dos clases, con una flecha en el lado de la clase base.

Asociaciones
Una asociacin representa una relacin entre clases, y aporta la semntica comn y la estructura de muchos tipos de conexiones entre objetos. Las asociaciones son los mecanismos que permite a los objetos comunicarse entre s. Describe la conexin entre diferentes clases (la conexin entre los objetos reales se denomina conexin de objetos o enlace). Las asociaciones pueden tener un papel que especifica el propsito de la asociacin y pueden ser unidireccionales o bidireccionales (indicando si los dos objetos participantes en la relacin pueden intercambiar mensajes entre s, o es nicamente uno de ellos el que recibe informacin del otro). Cada extremo de la asociacin tambin tiene un valor de multiplicidad, que indica cuntos objetos de ese lado de la asociacin estn relacionados con un objeto del extremo contrario. En UML, las asociaciones se representan por medio de lneas que conectan las clases participantes en la relacin, y tambin pueden mostrar el papel y la multiplicidad de cada uno de los participantes. La multiplicidad se muestra como un rango [mn...mx] de valores no negativos, con un asterisco (*) representando el infinito en el lado mximo.

16

Acumulacin
Las acumulaciones son tipos especiales de asociaciones en las que las dos clases participantes no tienen un estado igual, pero constituyen una relacin completa. Una acumulacin describe cmo se compone la clase que asume el rol completo de otras clases que se encargan de las partes. En las acumulaciones, la clase que acta como completa, tiene una multiplicidad de uno. En UML, las acumulaciones estn representadas por una asociacin que muestra un rombo en uno de los lados de la clase completa.

Composicin
Las composiciones son asociaciones que representan acumulaciones muy fuertes. Esto significa que las composiciones tambin forman relaciones completas, pero dichas relaciones son tan fuertes que las partes no pueden existir por s mismas. nicamente existen como parte del conjunto, y si este es destruido las partes tambin lo son. En UML, las composiciones estn representadas por un rombo slido al lado del conjunto.

Diagramas de secuencia
Los diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en que se invocan) en un momento dado. Los diagramas de secuencia ponen especial nfasis en el orden y el momento en que se envan los mensajes a los objetos. En los diagramas de secuencia, los objetos estn representados por lneas intermitentes verticales, con el nombre del objeto en la parte ms alta. El eje de tiempo tambin es vertical, incrementndose hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operacin y los parmetros.

17

Los mensajes pueden ser o bien sncronos, el tipo normal de llamada del mensaje donde se pasa el control a objeto llamado hasta que el mtodo finalice, o asncronos donde se devuelve el control directamente al objeto que realiza la llamada. Los mensajes sncronos tienen una caja vertical en un lateral del objeto invocarte que muestra el flujo del control del programa.

Diagramas de colaboracin
Los diagramas de colaboracin muestran las interacciones que ocurren entre los objetos que participan en una situacin determinada. Esta es ms o menos la misma informacin que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los diagramas de colaboracin fijan el inters en las relaciones entre los objetos y su topologa.

18

En los diagramas de colaboracin los mensajes enviados de un objeto a otro se representan mediante flechas, mostrando el nombre del mensaje, los parmetros y la secuencia del mensaje. Los diagramas de colaboracin estn indicados para mostrar una situacin o flujo programa especficos y son unos de los mejores tipos de diagramas para demostrar o explicar rpidamente un proceso dentro de la lgica del programa.

Diagrama de estado
Los diagramas de estado muestran los diferentes estados de un objeto durante su vida, y los estmulos que provocan los cambios de estado en un objeto.

19

Los diagramas de estado ven a los objetos como mquinas de estado o autmatas finitos que pueden estar en un conjunto de estados finitos y que pueden cambiar su estado a travs de un estmulo perteneciente a un conjunto finito. Por ejemplo, un objeto de tipo NetServer puede tener durante su vida uno de los siguientes estados:

Listo Escuchando Trabajando Detenido

y los eventos que pueden producir que el objeto cambie de estado son Se crea el objeto El objeto recibe un mensaje de escucha Un cliente solicita una conexin a travs de la red Un cliente finaliza una solicitud La solicitud se ejecuta y ser termina El objeto recibe un mensaje de detencin

20

Diagrama de actividad
Los diagramas de actividad describen la secuencia de las actividades en un sistema. Los diagramas de actividad son una forma especial de los diagramas de estado, que nicamente (o mayormente) contienen actividades.

Los diagramas de actividad son similares a los diagramas de flujo procesales, con la diferencia de que todas las actividades estn claramente unidas a objetos. Los diagramas de actividad siempre estn asociados a una clase, a una operacin o a un caso de uso. Los diagramas de actividad soportan actividades tanto secuenciales como paralelas. La ejecucin paralela se representa por medio de iconos de fork/espera, y en el caso de las actividades paralelas, no importa en qu orden sean invocadas (pueden ser ejecutadas simultneamente o una detrs de otra).

21

Actividad
Una actividad es un nico paso de un proceso. Una activa es un estado del sistema que actividad interna y, al menos, una transicin saliente. Las actividades tambin pueden tener ms de una transicin saliente, si tienen diferentes condiciones. Las actividades pueden formar jerarquas, lo que significa que una actividad puede estar formada de varias actividades de detalle, en cuyo caso las transiciones entrantes y salientes deberan coincidir con las del diagrama de detalle. Elementos de ayuda Existen unos pocos elementos en UML que no tiene un valor semntico real en la maqueta, pero que ayudan a clarificar partes del programa. Estos elementos son Lnea de texto Notas de texto y enlaces Cajas

Las lneas de texto son tiles para aadir informacin textual a un diagrama. Es texto es libre y no tiene ningn significado para la maqueta. Las notas son tiles para aadir informacin ms detallada de un objeto o una situacin especfica. Tienen la gran ventaja de que se pueden anclar a los elementos UML para mostrar que una nota pertenece a un objeto o situacin especficos. Las cajas son rectngulos repartidos libremente que pueden usarse para juntar objetos haciendo los diagramas ms legibles. No tienen significado lgico en la maqueta.

Diagramas de componentes
Los diagramas de componentes muestran los componentes del software (ya sea las tecnologas que lo forman como Kparts, componentes CORBA, Java Beans o simplemente secciones del sistema claramente distintas) y los artilugios de que est compuesto como los archivos de cdigo fuente, las libreras o las tablas de una base de datos. Los componentes pueden tener interfaces (es decir clases abstractas con operaciones) que permiten asociaciones entre componentes.

Diagramas de implementacin
Los diagramas de implementacin muestran las instancias existentes al ejecutarse as como sus relaciones. Tambin se representan los nodos que identifican recursos fsicos, tpicamente un ordenador as como interfaces y objetos (instancias de las clases).

22

Diagramas de relacin de entidad

Los diagramas de relaciones de entidad (diagramas ER) muestran el diseo conceptual de las aplicaciones de bases de datos. Representan varias entidades (conceptos) en el sistema de informacin y las relaciones y restricciones existentes entre ellas. Una extensin de los diagramas de relaciones de entidad llamado diagramas de relaciones de entidad extendida o diagramas de relaciones de entidad mejoradas (EER), se utiliza para incorporar las tcnicas de diseo orientadas a objetos en los diagramas ER.

Entidad
Una Entidad es cualquier concepto del mundo real con una existencia independiente. Puede ser un objeto con una existencia fsica (ejemplo, mquina, robot) o puede ser un objeto con una existencia conceptual (p. ej.: Curso de universidad). Cada entidad tiene un conjunto de atributos que describen las propiedades de la entidad. Nota: No existen notaciones estndar para representar los diagramas ER. Los diferentes textos sobre este asunto utilizan diferentes notaciones. Los conceptos y notaciones para los diagramas

23

EER utilizados en Umbrello provienen del siguiente libro: Elmasri R. y Navathe S. (2004). Fundamentals of Database Systems 4 ed. Addison Wesley (Fundamentos de los sistemas de bases de datos) En un diagrama ER, las entidades se representan como rectngulos, con el nombre de la clase, y tambin pueden mostrar atributos y operaciones de la clase en otros dos compartimentos dentro del rectngulo.

Atributos de la entidad
En los diagramas ER, los atributos de la entidad se muestra con su nombre en un compartimento diferente de la entidad a la que pertenecen.

Restricciones
Las restricciones en los diagramas ER especifican las restricciones de los datos en el esquema de informacin. Existen cuatro tipos de restricciones soportadas por Umbrello: Clave primaria: El conjunto de atributos declarados como clave primaria es nica para la entidad. Solo puede haber una clave primaria en una entidad y ninguno de los atributos que la componen puede ser NULL. Clave nica: El conjunto de atributos declarados como nica son nicos para la entidad. Pueden haber muchas restricciones nicas en una entidad. Los atributos que lo componen pueden tener el valor NULL. Las claves nicas y primarias identifican de forma nica una fila de una tabla (entidad) Clave externa: Una clave externa es una restriccin referencia entre dos tablas. La clave externa identifica una columna o un conjunto de columnas en un tabla (referenciada) que referencia una columna o conjunto de columnas en otra tabla (referenciada). Las columnas en la tabla referenciada deben formar una clave primaria o una clave nica. Restriccin de comprobacin: Una restriccin de comprobacin (tambin conocida como restriccin de comprobacin de tabla) es una condicin que define los datos vlidos cuando se aaden o actualizan datos en una tabla de la base de datos relacional. Se aplicar una restriccin a cada fila de la tabla. La restriccin debe ser un predicado. Puede referirse a una o varias columnas de la tabla.

24

25

Bibliografa

26

[T1-1] Fran Tarifa, 23 Febrero, 2007. Principios generales de la usabilidad. [En lnea]. Disponible en http://www.mqaccesibilidad.com/2007/02/principio-generales-de-la-usabilidad.html[2012,3 de marzo] [T1-2] 04 de marzo 2012.Usabilidad. [En lnea]. Disponible en http://es.wikipedia.org/wiki/Usabilidad[2012,3 de marzo] [T1-3] Por Evelio Martnez, Julio 1999.Estndares de Telecomunicaciones. [En lnea]. Publicado en la Revista RED. Disponible en http://www.eveliux.com/mx/estandares-detelecomunicaciones.php[2012,3 de marzo] [T1-4] Luis Villa, 14 de marzo de 2012. Guas de estilo: diseo, normalizacin y usabilidad. [En lnea]. Disponible en http://www.slideshare.net/juanjo1152/fichas-bibliogrficas-apa1820836[2012,3 de marzo]

27