Elementos UMLOs diagramas de caso de uso descreben as relacións e dependencias entre un grupo de Casos de Uso e os Actores a participar no proceso.
É importante decatarse de que os diagramas de casos de uso non son apropriados para representar o deseño, e non poden descreber o interior dun sistema. Estes diagramas serven para facilitar a comunicación cos futuros usuarios do sistema, e cos clientes, e son especialmente úteis para determinar as funcionalidades que o sistema debe ter. Os diagramas de casos de uso indican o que o sistema debera ter, pero non especifica como o acada, —nen pode—.
Umbrello UML Modeller mostrando un diagrama de caso de uso
Un caso de uso descrebe —desde o ponto de vista dos actores— un grupo de actividades nun sistema que produce un resultado concreto, tanxíbel.
Os casos de uso son descricións das interaccións típicas entre os usarios dun sistema e o sistema en si. Representan a interface externa do sistema e especifican unha forma de requerimentos do que debe facer o sistema (lembre, só o que, non como).
Cando se traballa cos casos de uso, é importante lembrar algunhas regras simples:
Cada caso de uso estará relacionado con polo menos un actor
Cada caso de uso ten un iniciador (isto é un actor)
Cada caso de uso conduce a un resultado relevante (un resultado con « valor de negocio »)
Os casos de uso tamén teñen relacións con outros casos de uso. Os tres tipos de relación máis típicas entre os casos son:
<<inclusión>> que indica que un caso de uso acontece dentro doutro caso de uso
<<extensión>> que indica que en certas situacións, ou nalgún ponto (chamado ponto de extensión) un caso de uso será ampliado por outro.
Xeneralización indica que un caso de uso herda as características do « Super »caso de uso, e pode sobrescreber algunhas deles ou engadir outras novas, de xeito similar á herdanza entre clases.
Un actor é unha entidade externa (fora do sistema) que interactúa co sistema ao participar (e a miúdo iniciar) un caso de uso. Os actores poden ser xente real (por exemplo os usuarios do sistema), outros sistemas informáticos ou eventos externos.
Os actores non representan a xente ou sistemas físicos, senón o seu papel. Isto significa que cando unha persoa interactúa co sistema de diferentes xeitos (asumindo diferentes papeis) estará representada por varios actores. Por exemplo unha persoa que dá servizo técnico aos clientes por teléfone e recive pedidos dos clientes, no sistema estaría representado por un actor « Servizo Técnico » e un actor « Comercial »
Os diagramas de clase mostran as diferentes clases que conforman o sistema e como se relacionan entre si. Sóese dicir que os diagramas de clase son « estáticos » porque mostran as clases, xunto cos seus métodos e atributos así como as relacións estáticas entre elas: que clases « coñecen » da existencia de outras ou que clases « son parte » de outras clases, pero non mostran as chamadas a métodos entre elas.
Umbrello UML Modeller mostrando un diagrama de clases
Unha clase define os atributos e métodos dun conxunto de obxectos. Todos os obxectos desa clase (instancias da clase) teñen o mesmo comportamento, e teñen o mesmo conxunto de atributos (cada obxecto ten o seu proprio conxunto). Ás veces chámaselles « Tipo » no canto de Clase, pero é importante mencionar que non son o mesmo, e que Tipo é un termo máis xeral.
En UML as clases son representadas por rectángulos, co nome da clase, que poden mostrar tamén os atributos e operacións da clase en outros dous « compartimentos » dentro do rectángulo.
Representación visual dunha clase en UML
En UML os atributos son mostrados con polo menos o seu nome, e tamén pode mostrar o tipo, valor inicial e outras propiedades. Os atributos tamén poden ser mostrados coa súa visibilidade:
+Significa que o atributo é público#Significa que o atributo é protexido-Significa que o atributo é privado
As operacións (métodos) tamén son mostradas con polo menos o seu noe, e tamén pode mostrar os seus parámetros e tipo de retorno. Os igual que cos atributos, tamén pode ver a súa visibilidade:
+Significa que a operación é pública#Significa que a operación é protexida-Significa que a operación é privada
As clases poden relacionarse (estar asociadas con) unhas coas outras de distintos xeitos:
A herdanza é un dos conceitos fundamentais da programación orientada a obxectos, na que unha clase « gaña » todos os atributos e operacións da clase da que herda, e pode sobrescreber/modificar algúns deles, así como engadir máis atributos e operacións proprias.
En UML, unha asociación de Xeneralización entre dúas clases ponnas nunha hierarquía que representa o conceito de herdanza dunha clase derivada respeito dunha clase base. En UML, as xeneralizacións son representadas por unha liña que conecta as dúas clases, cunha frecha ao lado da clase base.
Representación visual dunha xeneralización en UML
Unha asociación representa unha relación entre clases, e dá a semántica común e a estrutura de moitos tipos de « conexóns » entre obxectos.
As asociacións son o mecanismo que lles permite aos obxectos comunicarse entre si. Describen a conexón entre diferentes clases (a conexón entre os obxectos reais é denominada conexón entre obxectos, ou ligazón).
As asociacións poden ter un papel que especifica o propósito da asociación e pode ser uni ou bidireccional (indica se os dous obxectos participantes na relación poden enviar mensaxes uns aos outros, ou se só un deles sabe do outro). Cada extremo da asociación pode ter tamén unha multiplicidade, que dictamina cantos obxectos neste lado da asociación poden relacionarse cun obxecto do outro lado).
En UML as asociacións represéntanse como liñas que conectan as clases participantes na relación, e tamén poden mostrar o papel e a multiplicidade de cada un dos participantes. A multiplicidade é mostrada como un rango [mín..máx] de valores non negativos, onde un asterísco (*) no máximo representa o infinito.
Representación visual dunha asociación en UML
As agregacións son un tipo especial de asociación na que as dúas clases participantes non teñen o mesmo estatus, senón que teñen unha relación « todo-parte ». Unha agregación descrebe como a clase que adopta o papel de todo, está composta por(ten) outras clases, que adoptan o papel de partes. Nas agregacións, a clase que actúa como o todo sempre ten unha multiplicidade de un.
En UML as agregacións represéntanse mediante unha asociación cun rombo no lado do todo.
Representación visual dunha relación de agregación en UML
As composicións son asociación que representan agregacións moi fortes. Isto significa que as composicións tamén representan relacións todo-parte, pero cunha relación tan forte que as partes non poden existir por si mesmas. Só existen dentro do todo, e se o todo é destruído as partes tamén.
En UML as Composicións represéntanse cun rombo sólido no lado do todo.
Os diagramas de clase ademais de clases poden conter outro elementos.
As interfaces son clases abstractas que representan instancias que non poden ser criadas directamente. Poden conter operacións pero non atributos. As clases poden herdar de interfaces (mediante unha asociación de realización) e as instancias pode estar feitas destes diagramas.
Os tipos de datos son primitivas que tipicamente veñen incorporadas na linguaxe. Exemplos habituais son os inteiros e os booleanos. Non poden ter relacións con clases, pero as clases poden ter relacións con eles.
As enumeracións son listas simples de valores. Un exemplo típico é unha enumeración dos días da semana. As opcións dunha enumeración son denominadas Literais da enumeración. Ao igual cos tipos de datos non poden ter relacións coas clases pero as clases poden ter relacións con elas.
Os diagramas de secuencia mostran o intercambio de mensaxes (isto é chamadas a métodos) entre varios obxectos nunha situación concreta delimitada no tempo. Os obxectos son instancias das clases. Os diagramas de secuencia fan énfase na orden e tempos nos que se envían as mensaxes aos obxectos.
Nos diagramas de secuencia os obxectos son representados mediante liñas verticais de pontos co nome do obxecto no cume. O eixo do tempo tamén é vertical, aumentando cara baixo, de tal xeito que as mensaxes son enviasa dun obxecto para outro na forma de frechas co nome e os parámetros da operación.
Umbrello UML Modeller mostrando un diagrama de secuencia
As mensaxes poden ser síncronas, o tipo normal de mensaxe no que o control é pasado á obxecto chamado até que o seu método remate a execución, ou asíncronas, onde o control é devolto directamente ao obxecto que fai a chamada. As mensaxes síncronas teñen unha caixa vertical ao lado do obxecto chamado para mostrar o fluxo de control do programa.
Os diagramas de colaboración mostran as interaccións que acontecen entre os obxectos que participan nunha situación dada. Isto é similar á información que se mostra nun diagrama de secuencia pero neste faise fincapé en como acontecen as interaccións no tempo mentres que nos diagramas de colaboración poñen de relevo as relacións entre os obxectos e a súa topoloxía.
Nos diagramas de colaboración as mensaxes enviadas entre obxectos son representadas por frechas, co nome da mensaxe, os parámetros e a secuencia da mensaxe. Os diagramas de colaboración son adecuados para mostrar un fluxo específico do programa ou unha situación e son un dos mellores tipos de diagrama para demostrar rapidamente ou explicar un proceso na lóxica do programa.
Umbrello UML Modeller mostrando un diagrama de colaboración
Os diagramas de estado mostran os diferentes estados dun obxecto durante a súa existencia e os estímulos que fan que o obxecto mude o seu estado.
Os diagramas de estado consideran os obxectos como máquinas de estados ou autómatas finitos que poden estar nun dun conxunto finito de estados e que poden mudar o seu estado mediante un conxunto finito de estímulos. Por exemplo un obxecto do tipo NetServer pode estar nun dos seguintes estados durante a súa vida:
En aguarda
A escoitar
A traballar
Parado
e os eventos que poden facer que o obxecto mude de estado son
O obxecto é criado
O obxecto recebe a mensaxe "escoitar"
Un cliente pide unha conexón sobre a rede
Un cliente finaliza unha conexón
A petizón é executada e finaliza
O obxecto recebe a mensaxe "parar"
etc
Umbrello UML Modeller mostrando un diagrama de estado
Os estados son os tixolos cos que se fan os diagramas de estado. Un estado pertence a exactamente unha clase e representa un resumo dos valores que poden tomar os atributos dunha clase. Un estado en UML representa o estado interno dun obxecto nunha clase particular
Lembre que non todas as alteración nun atributo dun obxecto debe ser representado por un estado senón só aquelas modificación que poden afectar de xeito significativo a como traballe o obxecto
Hai dous tipos especiais de estado: Inicio e Fin. Son especiais porque nengún evento pode facer que un obxecto volte ao seu estado de Inicio, do mesmo xeito que nengún evento pode facer que un obxecto volte do estado de Fin unha vez que é acadado.
Os diagramas de actividade descreben a secuencia do traballo nun sistema coa axuda de Actividades. Os diagramas de actividade son unha forma especial de diagrama de estados, que só (ou maiormente) contén Actividades.
Umbrello UML Modeller mostrando un diagrama de actividade
Os diagramas de actividade son similares aos Diagramas de Fluxo dos procedimentos, coa diferenza de que todas as Actividades están claramente ligadas a Obxectos.
Os diagramas de actividade sempre están asociados ou a unha Clase, a unha Operación ou a un Caso de uso.
Os diagramas de actividade admiten actividades tanto secuenciais como paralelas. A execución en paralelo é representada mediante ícones Ramificar/Xuntar, e para as actividades con execución en paralelo, non é importante a orden na que son realizadas (poden ser executadas á vez ou unha tras da outra)
Unha actividade é unha etapa simples dun proceso. Unha actividade é un estado do sistema activo e, polo menos, unha transición saínte. As actividades tamén poden ter máis dunha transición saínte se teñen diferentes condicións.
As actividades poden formar hierarquías, isto significa que unha actividade pode estar composta por varias actividades « de detalle », neste caso as transicións entrantes e saíntes deben coincidir coas transicións de entrada e saída do diagrama de detalle.
Hai uns poucos elementos UML que non teñen valor semántico real para o modelo, pero axudan a aclarar partes do diagrama. Estes elementos son
Liñas de texto
Notas de texto e enganches
Caixas
As liñas de texto son úteis para engadir un texto informativo breve ao diagrama. Non están ligadas a nengún elemento e non teñen significado para o modelo en si.
As notas son úteis para engadir información máis detallada acerca dun obxecto ou situación específica. Teñen a grande vantaxe de que poden estar ligadas a elementos UML para mostrar que a nota « pertence »a un obxecto ou situación específica.
As caixas son rectángulos non ligado a nada que poden ser usadas para agrupar elementos e facer os diagramas máis lexíbeis. Non teñen significado lóxico no modelo.
Os diagramas de componentes mostrans os componentes do sóftware (sexantecnoloxías de componentes como KParts, componentes CORBA ou Java Beans ou só seccións do sistema claramente diferenciábeis) e os artefactos cos que están feitos, como ficheiros de código fonte, bibliotecas de programación ou táboas de bases de datos relacionais.
As componentes poden ter interfaces (isto é clases abstractas con operacións) que permiten asociacións entre componentes.
Os diagramas de implementación mostran as instancias en tempo de execución e as súas asociación. Inclúen Nós, que son recursos físicos, tipicamente un ordenador. Tamén mostran as interfaces e os obxectos (intancias de clases).
Os diagramas de relacións entre entidades (Diagramas ER) mostran o deseño conceptual das bases de datos. Con eles tense unha visión das diferentes entidades (conceitos) do sistema de información e das relacións e restricións existentes entre elas. Emprégase unha extensión dos diagramas de relacións entre entidades, chamada "Diagramas ampliados de relacións entre entidades" (EER), para incorporar técnicas de deseño orientado a obxectos nos diagramas ER.
Umbrello mostrando un diagrama de relacións entre entidades
Unha entidade é calquer conceito do mundo real que teña existencia independente. Pode ser un obxecto físico (por exemplo un ordenador, ou un bolígrafo) ou só ter existencia conceptual (p.ex: un curso da universidade). Cada entidade ten un conxunto de atributos que descreben as propriedades da entidade.
Nota: Non hai unha notación estándar para os diagramas ER. Os diferentes textos que tratan desta materia empregan notacións distintas. Os conceitos e notacións dos diagramas EER empregados en Umbrello son tomados do seguinte libro: Elmasri R. e Navathe S. (2004). Fundamentals of Database Systems 4th edn. Addison Wesley
Nun diagrama ER, as entidades son representadas por rectángulos, co nome da entidade na parte superior, e tamén pode mostras os atributos da entidade en outro « compartimento » dentro do rectángulo.
Representación visual dunha entidade nun diagrama ER
Nos diagramas ER, os atributos das entidades represéntanse polo seu nome nun compartimento diferente da entidade á que pertencen.
As restricións nus diagramas ER especifican as restricións nos datos do esquema de información.
Umbrello admite catro tipos de restricións:
Chave primaria O conxunto de atributos declarados como chave primaria son únicos da entidade. Só pode haber unha chave primaria nunha entidade e nengún dos atributos que a constitúan pode ser NULO.
Chave única: O conxunto de atributos declarados como únicos son específicos da entidade. Poda haber varias restricións de unicidade nunha entidade. Os atributos que a constitúen poden ser NULO. As chaves únicas e as chaver primarias idenfican univocamente unha fila dunha táboa (entidade)
Chave externa: Unha chave externa é unha restrición referencial entre dúas táboas. A chave externa identifica unha coluna ou conxunto de colunas nunha táboa (referinte) que se refete a unha coluna ou conxunto de colunas de outra táboa (referida). As colunas na táboa referida deben formar unha chave primaria ou única.
Restrición por comprobación: Unha restrición por comprobación (tamén coñecida por restrición de comprobación da táboa) é unha condición que define os datos válidos cando se engade ou actualiza unha entrada nunha táboa dunha base de datos relacional. Estas restricións aplícanse a cada fila da táboa. A restrición debe ser un predicado. Pode referirse a unha só ou a varias colunas da táboa.
Exemplo: prezo >=0
A especialización é unha maneira de formar novas entidades empregando entidades xa definidas. As entidades novas, coñecidas como entidades derivadas, toman (herdan) atributos das preexistentes, ás que se coñece por entidades base. O propósito é reutilizar datos xa existentes con pouca ou nengunha modificación.
En Umbrello, pódese especificar que a especialización sexa Disxunta ou Sobreposicionante
A especialización disxunta indica que as subclases da especialización deben ser disxuntas. Isto significa que unha entidade pode ser membro de como moito unha das entidades derivadas da especialización
Representación visual da especialización disxunta nun diagrama EER
Cando as entidades derivadas non teñen a restrición de ser disxuntas, dise que o seu conxunto de entidades está en especialización con sobreposición. Isto significa que a mesma entidade do mundo real pode ser membro de máis dunha entidade derivada da especialización.
Representación visual da especialización sobreposicionante nun diagrama EER
Dise que unha entidade derivada é unha Categoría cando representa unha coleccion de obxectos que é un subconxunto da unión dos distintos tipos de dato. A categoría modelízase cando surxe a necesidade dunha única relación superclase/subclase con máis dunha superclase, onde a superclase representa diferentes tipos de entidades. (Como a herdanza múltipla na programación orientada a obxectos).
Representación visual dunha Categoría nun diagrama EER