A Unified Modeling Language (UML) uma linguagem de modelagem no
proprietria de terceira gerao. A UML no uma metodologia de desenvolvimento, o que significa que ela no diz para voc o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicao entre objetos. Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramas padronizados. Junto com uma notao grfica, a UML tambm especifica significados, isto , semntica. uma notao independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML. importante distinguir entre um modelo UML e um diagrama 1 (ou conjunto de diagramas) de UML. O ltimo uma representao grfica da informao do primeiro, mas o primeiro pode existir independentemente. O XMI (XML Metadata Interchange) na sua verso corrente disponibiliza troca de modelos mas no de diagramas. Os objetivos da UML so: especificao, documentao, estruturao para sub- visualizao e maior visualizao lgica do desenvolvimento completo de um sistema de informao. A UML um modo de padronizar as formas de modelagem. As propriedades estticas dos objetos so representadas pelos atributos e possuem as seguintes caractersticas: Tipo: determina o classificador das instncias dos valores, que pode ser uma classe, um tipo de dado primitivo ou uma interface; Multiplicidade: determina quantas instncias de valores um determinado produto pode ter; Valor inicial: determina o valor do atributo quando o objeto inicializado; Escopo: determina se cada valor esta relacionado a uma instncia da classe ou se esta relacionada diretamente classe. Mutabilidade: determina se o valor do atributo pode ser alterado aps a criao do objeto. Existem cinco fases no desenvolvimento de sistemas de software: anlise de requisitos, anlise, design (projeto), programao e testes. Estas cinco fases no devem ser executadas na ordem descrita acima, mas concomitantemente de forma que problemas detectados numa certa fase modifiquem e melhorem as fases desenvolvidas anteriormente de forma que o resultado global gere um produto de alta qualidade e performance. A seguir falaremos sobre cada fase do desenvolvimento de um sistema em UML:
Anlise de Requisitos
Esta fase captura as intenes e necessidades dos usurios do sistema a ser desenvolvido atravs do uso de funes chamadas "use-cases". Atravs do desenvolvimento de "use-case", as entidades externas ao sistema (em UML chamados de "atores externos") que interagem e possuem interesse no sistema so modelados entre as funes que eles requerem, funes estas chamadas de "use-cases". Os atores externos e os "use-cases" so modelados com relacionamentos que possuem comunicao associativa entre eles ou so desmembrados em hierarquia. Cada "use-case" modelado descrito atravs de um texto, e este especifica os requerimentos do ator externo que utilizar este "use-case". O diagrama de "use-cases" mostrar o que os atores externos, ou seja, os usurios do futuro sistema devero esperar do aplicativo, conhecendo toda sua funcionalidade sem importar como esta ser implementada. A anlise de requisitos tambm pode ser desenvolvida baseada em processos de negcios, e no apenas para sistemas de software.
Anlise
A fase de anlise est preocupada com as primeiras abstraes (classes e objetos) e mecanismos que estaro presentes no domnio do problema. As classes so modeladas e ligadas atravs de relacionamentos com outras classes, e so descritas no Diagrama de Classe. As colaboraes entre classes tambm so mostradas neste diagrama para desenvolver os "use-cases" modelados anteriormente, estas colaboraes so criadas atravs de modelos dinmicos em UML. Na anlise, s sero modeladas classes que pertenam ao domnio principal do problema do software, ou seja, classes tcnicas que gerenciem banco de dados, interface, comunicao, concorrncia e outros no estaro presentes neste diagrama.
Design (Projeto)
Na fase de design, o resultado da anlise expandido em solues tcnicas. Novas classes sero adicionadas para prover uma infra-estrutura tcnica: a interface do usurio e de perifricos, gerenciamento de banco de dados, comunicao com outros sistemas, dentre outros. As classes do domnio do problema modeladas na fase de anlise so mescladas nessa nova infra-estrutura tcnica tornando possvel alterar tanto o domnio do problema quanto infra-estrutura. O design resulta no detalhamento das especificaes para a fase de programao do sistema.
Programao
Na fase de programao, as classes provenientes do design so convertidas para o cdigo da linguagem orientada a objetos escolhida (a utilizao de linguagens procedurais extremamente no recomendada). Dependendo da capacidade da linguagem usada, essa converso pode ser uma tarefa fcil ou muito complicada. No momento da criao de modelos de anlise e design em UML, melhor evitar traduzi-los mentalmente em cdigo. Nas fases anteriores, os modelos criados so o significado do entendimento e da estrutura do sistema, ento, no momento da gerao do cdigo onde o analista conclua antecipadamente sobre modificaes em seu contedo, seus modelos no estaro mais demonstrando o real perfil do sistema. A programao uma fase separada e distinta onde os modelos criados so convertidos em cdigo.
Testes
Um sistema normalmente rodado em testes de unidade, integrao, e aceitao. Os testes de unidade so para classes individuais ou grupos de classes e so geralmente testados pelo programador. Os testes de integrao so aplicados j usando as classes e componentes integrados para se confirmar se as classes esto cooperando uma com as outras como especificado nos modelos. Os testes de aceitao observam o sistema como uma " caixa preta" e verificam se o sistema est funcionando como o especificado nos primeiros diagramas de "use-cases". O sistema ser testado pelo usurio final e verificar se os resultados mostrados esto realmente de acordo com as intenes do usurio final.
A Notao da Linguagem de Modelagem Unificada UML
Tendo em mente as cinco fases do desenvolvimento de softwares, as fases de anlise de requisitos, anlise e design utilizam-se em seu desenvolvimento cinco tipos de vises, nove tipos de diagramas e vrios modelos de elementos que sero utilizados na criao dos diagramas e mecanismos gerais que todos em conjunto especificam e exemplificam a definio do sistema, tanto a definio no que diz respeito funcionalidade esttica e dinmica do desenvolvimento de um sistema. Antes de abordarmos cada um destes componentes separadamente, definiremos as partes que compem a UML: Vises: as Vises mostram diferentes aspectos do sistema que est sendo modelado. A viso no um grfico, mas uma abstrao consistindo em uma srie de diagramas. Definindo um nmero de vises, cada uma mostrar aspectos particulares do sistema, dando enfoque a ngulos e nveis de abstraes diferentes e uma figura completa do sistema poder ser construda. As vises tambm podem servir de ligao entre a linguagem de modelagem e o mtodo/processo de desenvolvimento escolhido. Modelos de elementos: os conceitos usados nos diagramas so modelos de elementos que representam definies comuns da orientao a objetos como as classes, objetos, mensagem, relacionamentos entre classes incluindo associaes, dependncias e heranas. Mecanismos gerais: os mecanismos gerais provm comentrios suplementares, informaes, ou semntica sobre os elementos que compem os modelos; eles provm tambm mecanismos de extenso para adaptar ou estender a UML para um mtodo/processo, organizao ou usurio especfico. Diagramas: os diagramas so os grficos que descrevem o contedo em uma viso. UML possui nove tipo de diagramas que so usados em combinao para prover todas as vises do sistema.
Vises
Um sistema composto por diversos aspectos: funcional (que sua estrutura esttica e suas interaes dinmicas), no funcional (requisitos de tempo, confiabilidade, desenvolvimento, etc.) e aspectos organizacionais (organizao do trabalho, mapeamento dos mdulos de cdigo, etc.). Ento o sistema descrito em um certo nmero de vises, cada uma representando uma projeo da descrio completa e mostrando aspectos particulares do sistema. As vises que compem um sistema so: Viso "use-case": descreve a funcionalidade do sistema desempenhada pelos atores externos do sistema (usurios). A viso use-case central, j que seu contedo base do desenvolvimento das outras vises do sistema. Essa viso montada sobre os diagramas de use-case e eventualmente diagramas de atividade. Viso lgica: descreve como a funcionalidade do sistema ser implementada. feita principalmente pelos analistas e desenvolvedores. Em contraste com a viso use-case, a viso lgica observa e estuda o sistema internamente. Ela descreve e especifica a estrutura esttica do sistema (classes, objetos, e relacionamentos) e as colaboraes dinmicas quando os objetos enviarem mensagens uns para os outros para realizarem as funes do sistema. Propriedades como persistncia e concorrncia so definidas nesta fase, bem como as interfaces e as estruturas de classes. A estrutura esttica descrita pelos diagramas de classes e objetos. O modelamento dinmico descrito pelos diagramas de estado, sequncia, colaborao e atividade. Viso de componentes: uma descrio da implementao dos mdulos e suas dependncias. principalmente executado por desenvolvedores, e consiste nos componentes dos diagramas. Viso de concorrncia: trata a diviso do sistema em processos e processadores. Este aspecto, que uma propriedade no funcional do sistema, permite uma melhor utilizao do ambiente onde o sistema se encontrar, se o mesmo possui execues paralelas, e se existe dentro do sistema um gerenciamento de eventos assncronos. Uma vez dividido o sistema em linhas de execuo de processos concorrentes (threads), esta viso de concorrncia dever mostrar como se d a comunicao e a concorrncia destas threads. A viso de concorrncia suportada pelos diagramas dinmicos, que so os diagramas de estado, sequncia, colaborao e atividade, e pelos diagramas de implementao, que so os diagramas de componente e execuo.
Viso de organizao: finalmente, a viso de organizao mostra a organizao fsica do sistema, os computadores, os perifricos e como eles se conectam entre si. Esta viso ser executada pelos desenvolvedores, integradores e testadores, e ser representada pelo diagrama de execuo.
Modelos de Elementos
Alguns exemplos de modelos de elementos so as classes, objetos, estados, pacotes e componentes. Os relacionamentos tambm so modelos de elementos, e so usados para conectar outros modelos de elementos entre si.
Relacionamentos
Os relacionamentos ligam as classes/objetos entre si criando relaes lgicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos: Associao: uma conexo entre classes, e tambm significa que uma conexo entre objetos daquelas classes. Em UML, uma associao definida com um relacionamento que descreve uma srie de ligaes, onde a ligao definida como a semntica entre as duplas de objetos ligados. Generalizao: um relacionamento de um elemento mais geral e outro mais especfico. O elemento mais especfico pode conter apenas informaes adicionais. Uma instncia (um objeto uma instncia de uma classe) do elemento mais especfico pode ser usada onde o elemento mais geral seja permitido. Dependncia e Refinamentos: dependncia um relacionamento entre elementos, um independente e outro dependente. Uma modificao um elemento independente afetar diretamente elementos dependentes do anterior. Refinamento um relacionamento entre duas descries de uma mesma entidade, mas em nveis diferentes de abstrao. Realizao: relacionamento semntico entre classificadores em que um classificador especifica um contrato que outro classificador ir implementar. Ou melhor, a realizao um relacionamento entre os itens que implementa o comportamento especificado por outro. Um exemplo disso seria as classes abstratas e as interfaces que definem que o objeto filho dever realizar algum mtodo, propriedade no momento da herana.
Tipos de Diagramas
Diagramas estruturais: classe, objeto, pacote, componente, estrutura composta, implantao e perfil; Diagramas comportamentais: caso de uso, atividades e mquina de estados; Diagramas comportamentais de interao: sequncia, comunicao, interao geral e tempo.
Blocos de Construo
1. Itens e elementos o Estruturais: classes, interfaces, colaboraes, casos de uso, classes ativas, componentes e ns; o Comportamentais: iteraes e mquina de estados; o De agrupamento: blocos do modelo que podem ser decomposto; o De anotaes: anotaes no diagrama, representadas pela nota. 2. Relacionamentos: associao, dependncia, generalizao e realizao. 3. Diagramas: classe, objeto, pacotes, estrutura composta, componentes, implantao, caso de uso, estado, atividades, perfil, colaborao, sequncia, comunicao e tempo.
Mecanismos comuns da UML
Para tornar a construo do sistema mais simples e harmoniosa. a) Especificaes: repertrio semntico para determinar os detalhes do sistema (p.ex. atributos e operaes de classe); b) Adornos: variedades especficas de smbolos bsicos; c) Divises comuns: dicotomias comuns da UML, como entre interface/implementao, tipo/papel e classes/objetos (e similares para outros blocos, como para casos de uso/instncias de casos de uso); d) Mecanismos de extenso: permitem ampliar a UML de maneira controlada. Podem ser de 3 tipos: Esteretipos: permite a criao de novos tipos de blocos de construo derivados dos j existentes; Valores atribudos: estendem as propriedades dos blocos de informao, criando novas informaes; Restries: ampliam a semntica dos blocos de construo da UML, permitindo alterar as regras existentes ou criar novas regras. A UML pode ser estendida atravs de extenses de peso leve ou de peso pesado. As primeiras estendem as metaclasses da UML ou restringem ainda mais os elementos existentes. As segundas permitem alteraes mais profundas, como novas metaentidades ou alteraes profundas nas metaentidades existentes.
Diagrama de Classe
O diagrama de classes demonstra a estrutura esttica das classes de um sistema onde representam as coisas que so gerenciadas pela aplicao modelada. Classes podem se relacionar com outras atravs de diversas maneiras: associao (conectadas entre si), dependncia (uma classe depende ou usa outra classe), especializao (uma classe uma especializao de outra classe), ou em pacotes (classes agrupadas por caractersticas similares). Todos estes relacionamentos so mostrados no diagrama de classes juntamente com as suas estruturas internas, que so os atributos e operaes. O diagrama de classes considerado esttico, j que a estrutura descrita sempre vlida em qualquer ponto do ciclo de vida do sistema. Um sistema normalmente possui alguns diagramas de classes, j que no so todas as classes que esto inseridas em um nico diagrama e uma certa classe pode participar de vrios diagramas de classes.
Associao
As associaes representam as relaes entre as ocorrncias das classes. um tipo de relacionamento estrutural e esttico entre as classes. As associaes em um diagrama de classe definem os tipos de ligaes que os objetos participam. O termo associao binria se refere a uma associao entre duas classes.
Agregao
A associao de agregao sempre para indicar que um objeto colabora com outro objeto, mais a existncia desse objeto no obrigatria. Podemos dizer tambm que uma associao em que um objeto parte de outro, de tal forma que a parte pode existir sem o todo. Em mais baixo nvel, uma agregao consiste de um objeto contendo referncias para outros objetos, de tal forma que o primeiro seja o Todo, e que os objetos referenciados sejam as partes do todo. Tambm podemos dizer que uma relao do tipo todo/parte ou possui um esse ltimo mais utilizado na qual uma classe representa uma coisa grande que composta de coisas menores (classes agregadas).
Composio
A associao de composio um tipo de associao de agregao, mais a diferena entre elas que a composio faz parte do todo e depende do todo. Em outras palavras, os objetos so inseparveis, quando um objeto Pai destrudo o objeto filho tambm , pois ele faz parte do todo e componente todo.
Quando se tem uma classe que depende de outra classe para ser utilizada e quando se destri essa classe a outra tambm deve ser apagada ai temos um relacionamento de composio.
Relacionamentos
1. Entre classes: o Dependncia; o Generalizao; o Associao. 2. Entre classes e interfaces: o Dependncia; o Associao; o Realizao. 3. Entre interfaces: o Generalizao.
Generalizao
um relacionamento onde temos uma classe ancestral (supertipo) e outras classes herdadas (subtipos), o subtipo deve incluir todos os elementos (atributos e operaes) do supertipo.
Realizao
Relacionamento semntico entre classificadores em que um classificador especifica um contrato que outro classificador garante executar. uma relao entre uma interface e a classe que a implementa, i.e., que prov o servio definido pela interface. A realizao um relacionamento entre os itens que implementa o comportamento especificado por outro. Um exemplo disso seria as classes abstratas e as interfaces que definem que o objeto filho dever realizar algum mtodo, propriedade no momento da herana.
Interface
A interface define apenas a assinatura dos mtodos da classe sem apresentar sua implementao. Normalmente, nas linguagens de programao orientadas a objetos, as interfaces no apresentam atributos. A interface implementa a programao por contrato. A figura a seguir apresenta duas representaes de interface e o seu relacionamento com uma classe. No segundo exemplo note o uso do esteretipo para evidenciar a interface.
Uma interface fornecida descreve um servio implementado por uma classe. O conjunto de interfaces implementadas por uma classe so suas interfaces fornecidas e representam o conjunto de servios que a classe ao implementar uma interface suporta o conjunto de caractersticas possudas por esta e obedece s suas restries. Uma interface requerida, descrevem os servios que outras classes devem fornecer a uma determinada classe, que no precisa ter conhecimento de quais classes iro implementar estes servios.
Dependncia
Esse tipo de relacionamento indica que a mudana em um elemento pode causar mudanas em outros elementos. Nesse caso um elemento depende do outro, sendo que se um elemento mudar o outro poder ser afetado.
No exemplo acima, qualquer alterao na classe Formulrio poder afetar a classe GUI. A notao usada para representar a dependncia, um segmento de reta tracejado com uma seta aberta apontando para a classe dependida.
Esteretipos
Os esteretipos so uma extenso do vocabulrio da UML, que permite a criao de novos tipos de blocos de construo derivados dos j existentes, mas que so especficos ao seu problema. Os esteretipos so representados por aspas francesas ( <<nome do esteretipo>> ). Os esteretipos so normalmente predefinidos na prpria linguagem UML, por outro lado, a equipe de desenvolvimento pode definir os seus prprios esteretipos. Alguns exemplos: <<bounday>> ou classe de fronteira: usada para modelar a interao entre o ambiente do sistema e seus trabalhos internos; <<control>> ou classe de controle: usada para modelar um comportamento de controle especfico de um ou alguns casos de uso; <<entity>> ou classe de entidade: usada para modelar as informaes e o comportamento associado que devem ser armazenados.
Enumerao
um recurso usado em vrias linguagens de programao. So listas (literais) que podem ser armazenados como valores ou passados como parmetros. Para representar usa-se o esteretipo: <<enumerated>> ou <<enumeration>>.
Diagrama de Atividades
O diagrama de atividades um diagrama UML utilizado para modelar o aspecto comportamental de processos. um dos diagramas que mais sofreu mudanas em ser meta- modelo, desde o seu surgimento. Neste diagrama, uma atividade modelada como uma sequncia estruturada de aes, controladas potencialmente por ns de deciso e sincronismo. Em seu aspecto mais simples, um diagrama de atividades pode ser confundido com um fluxograma. Entretanto, ao contrrio de fluxogramas, os diagramas de atividades UML suportam diversos outros recursos, tais como as parties e os ns do tipo fork e merge, alm da definio de regies de interrupo, que permitem uma modelagem bem mais rica do que simplesmente um fluxograma.
Atividades
Booch (2005) define uma atividade como: comportamento expresso como um conjunto de aes conectadas por fluxos de controle de dados. Percebe-se, nesta definio que a atividade algo que est em andamento, ou conforme Fowler (2000) define, um estado de estar fazendo algo, assim as atividades so no atmicas e resultam ou so resultantes de outras aes que provocaro mudanas de estado em um sistema.
Estados de Ao
O estado de ao, segundo Melo (2000) um tipo simplificado de estado da mquina de estado, eles no devem ter transies internas. Guedes (2008) refora a tese de que os estados de ao, ao contrrio das atividades, so atmicos, ele descreve: Um estado de ao representa a realizao de uma ao dentro de um fluxo de controle, atmico, ou seja, no podem ser decompostos em sub-estados. Um estado de ao no possui aes internas e sua execuo considerada to rpida que no pode ser interrompida. Uma atividade costuma possuir diversos Estados de Ao. Assim, os estados de ao, representam os estados que so alterados a partir das transies (de um estado para o outro), gerados por condies de guarda e aes (vistos mais adiante nesse artigo). Tanto os estados de ao e/ou atividades so representados por um retngulo de pontas arredondadas com a descrio da ao em seu interior.
N de Atividade
O n de atividade outro conceito discutido quando estudamos o diagrama de atividades. Ns de atividades so vrias aes agrupadas dentro de uma nica atividade, por outro lado, podemos conceber uma ao, como um n de atividade que no pode ser descomposto.
Conector de Incio
Trata-se da representao de uma atividade abstrata que tem por objetivo apenas determinar o incio de um processo. representado por um crculo preenchido e a partir deste iniciado um primeiro estado.
Conector de Fim
De forma anloga ao conector de incio, o conector de fim (ou de finalizao), trata- se da representao de uma atividade abstrata que tem por objetivo apenas determinar o fim de um processo. representado por dois crculos concntricos, um preenchido e outro no.
Fluxos de Controle ou Transies
Com o propsito de associar uma atividade ou estado de ao a outro, informando que a atividade anterior foi completada a partir da execuo de suas aes, so usados os fluxos (ou transies de estado). Esses so representados por setas.
Condio de Guarda e Ao
A condio de guarda trata-se de uma expresso lgica (pode ser verdadeira ou no), capaz de alterar o estado do objeto ou de uma atividade. A situao de guarda normalmente est associada aps um branch (ou deciso do diagrama de atividades) e um dos fatores para o disparo de uma transio. Uma transio somente ser disparada se existir um evento associado a ela e a situao de guarda permitir. No diagrama de atividades a guarda representada entre colchetes ([ guarda ]). A ao, no diagrama de Atividades, trata-se de uma operao ou algo instantneo que no pode ser interrompido. Um objeto ao mudar de um estado a outro pode realizar diversas aes. No diagrama de atividades representada por uma barra (/ ao).
Branch (Desvio)
O Branch (deciso ou desvio) mostra um desvio no fluxo da atividade com vrias opes de sadas guardadas (condies de guarda). Nessa situao, apenas uma opo de sada pode ser tomada. Observa-se que diagrama de atividades modela lgica de um processo de Workflow e processos especficos envolvendo lgica, ele traz em suas anotaes detalhes dos fluxogramas, mas acrescenta conceitos de concorrncia e deciso.
Merge (Intercalao)
O Merge usado para finalizar o processo de deciso, ou seja, marca o final de um comportamento condicional iniciado por um branch.
Fork (Bifurcao) e Join (Juno)
Trata-se de uma opo para representar o processamento em paralelo, assim tem-se uma opo de entrada e vrias opes de sada. Quando a opo de entrada acionada (ou disparada) as opes de sada so iniciadas (acionadas) em paralelo. A juno ou unio, marca a finalizao de um fork. Transies sequenciais com ramificaes simples so os caminhos mais comuns a serem encontrados em diagramas de atividades. Entretanto principalmente quando estiver fazendo a modelagem de fluxo de trabalho de processos de negcio voc encontrar fluxos concorrentes. Na UML, a barra de sincronizao empregada para especificar a bifurcao e a unio desses fluxos paralelos de controle.
Swinlanes (Raias)
As raias de natao so usadas para identificar, no diagrama de atividades, entidades (e eventualmente as classes) responsveis por cada atividade (ou grupo de atividades).
Diagrama de Caso de Uso
O diagrama de caso de uso um diagrama da UML cujo objetivo representar um requisito do sistema que ser automatizado. Considere como requisito uma necessidade do sistema. O diagrama de casos de uso corresponde a uma viso externa do sistema e representa graficamente os atores, os casos de uso, e os relacionamentos entre estes elementos. Ele tem como objetivo ilustrar em um nvel alto de abstrao quais elementos externos interagem com que funcionalidades do sistema, ou seja, a finalidade de um diagrama de caso de uso apresentar um tipo de diagrama de contexto que apresenta os elementos externos de um sistema e as maneiras segundo as quais eles as utilizam. A notao utilizada para ilustrar atores em um diagrama de caso de uso a figura de um boneco, com o nome do ator definido abaixo dessa figura. Vale ressaltar que um ator nem sempre um ser humano. qualquer elemento externo que interage com o sistema (pessoas, organizaes, outros sistemas, equipamentos). Para representar casos de uso, utilizamos uma elipse, com o nome do caso de uso dentro da elipse, ou abaixo dela. Um relacionamento de comunicao representado por um segmento de reta ligando ator e caso de uso, sendo que um ator pode estar relacionado vrios casos de uso em um mesmo diagrama.
Objetivo
Especificar o contexto de um sistema; Capturar os requisitos funcionais de um sistema; Validar a arquitetura de um sistema; Dirigir a implementao e gerar casos de teste.
Na UML h 3 tipos de relacionamentos entre Casos de Uso, so eles:
Incluso: possibilita a subdiviso de casos de uso, bem como evita a descrio de uma mesma sequncia de interaes. Permite agrupar funcionalidades comuns em um ponto nico de utilizao; Generalizao: pode existir entre dois casos de uso ou entre dois atores. Permite que tanto um caso de uso como um ator herdem caractersticas de outro mais genrico. O caso de uso ou ator herdeiro pode especializar o comportamento do caso de uso ou ator base. Utiliza o mesmo smbolo da herana de classes. UML tambm permite utilizar o conceito de entidade abstrata ao Caso de Uso descrito em itlico; Extenso: no confundir com generalizao. Utilizado para expressar diferentes sequncias de interaes entre casos de uso. Caminhos alternativos ou excees. Cada uma das diferentes sequncias representa um comportamento opcional, que s ocorre sob certas condies ou cuja realizao depende da escolha do ator.
Em relao incluso e extenso
A seta saindo de um caso de uso apontando para o caso de uso base indica uma relao de extenso (opcionalidade na execuo do caso extendido). J a seta saindo do caso de uso base e apontando para um caso de uso indica uma relao de incluso (obrigatoriedade na execuo do caso de uso includo). Normalmente incluem-se os esteretipos <<include>>, <<extends>> nestas setas.
Tipos de Casos de Uso
Caso de uso caixa preta: detalhes internos sobre como o sistema responde s aes de um ator esto ausentes ou descritas muito resumidamente; Caso de uso caixa branca: detalhes internos sobre como o sistema responde s aes de um ator esto presentes e descritas detalhadamente.
Formatos dos Casos de Uso
Breve/Resumido: resumo conciso de um pargrafo que, usualmente, trata do cenrio principal; Casual/Informal: vrios pargrafos informais so definidos para abordar vrios cenrios; Completo: o mais elaborado. Todos os passos e variaes so descritas detalhadamente. Tambm incluem outras sees, como pr-condies e ps- condies.
Tipos de Itens
Estruturais: tambm chamados de classificadores. So os substantivos utilizados em modelos UML. So as partes mais estticas do modelo; Comportamentais: so as partes dinmicas dos modelos de UML. So os verbos representando comportamentos no tempo e no espao; Agrupamento: so as partes organizacionais do modelo UML; Anotacionais: so as partes explicativas dos modelos. So comentrios.
Diagrama de Sequncia
O diagrama de sequncia uma das ferramentas UML usadas para representar interaes entre objetos de um cenrio, realizadas atravs de operaes ou mtodos (procedimentos ou funes). Este diagrama construdo a partir do Diagrama de Casos de Uso. Primeiro, se define qual o papel do sistema (Use Cases), depois, definido como o software realizar seu papel (Sequncia de operaes). O diagrama de sequncia d nfase a ordenao temporal em que as mensagens so trocadas entre os objetos de um sistema. Entende-se por mensagens os servios solicitados de um objeto a outro, e as respostas desenvolvidas para as solicitaes.
Tipos de Mensagens
Sncrona: o emissor fica bloqueado at o receptor receber e tratar a mensagem; Assncrona: emissor continuar a emitir mensagens, no h dependncias.
Tipos de Interao
Mensagem de Retorno
Este tipo de mensagem identifica a resposta a uma mensagem para o objeto que a chamou. Uma mensagem de retorno pode retornar informaes especficas do mtodo chamado ou apenas um valor indicado se o mtodo for executado com sucesso ou no.
Auto-chamada ou Auto-delegao
So mensagens que partem da linha de vida do objeto e atinge a linha de vida do prprio objeto.
Controle Estruturado
Uma sequncia de mensagens boa para mostrar uma nica sequncia linear, mas frequentemente precisamos mostrar condicionais e loops. s vezes, preciso mostrar a execuo concorrente de vrias sequncias. O tipo de alto nvel pode ser apresentado com operadores de controle estruturado nos diagramas de sequncia. Tag OPT: o corpo do operador de controle executado se uma condio de proteo for verdadeira na entrada do operador. A condio de proteo uma expresso booleana que pode aparecer entre colchetes na parte superior de qualquer linha de vida no corpo, e pode fazer referncia a atributos desse objeto; Tag ALT: o corpo do operador de controle dividido em vrias sub-regies, por linhas horizontais tracejadas. Cada sub-regio representa um ramo de uma condicional. Cada sub-regio tem uma condio de proteo. Se a condio de proteo de uma regio for verdadeira, a sub-regio ser executada. Entretanto, no mximo uma sub-regio pode ser executada; se mais de uma condio de proteo for verdadeira, a escolha da sub-regio no ser determinstica, podendo varias de execuo para execuo. Se nenhuma condio de proteo for verdadeira, o controle continua passando pelo operador de controle. Uma sub-regio pode ter uma condio de proteo especial [else]; essa sub-regio ser executada, se nenhuma das outras condies de proteo for verdadeira; Tag PAR: o corpo do operador de controle dividido em vrias sub-regies por linhas horizontais tracejadas. Cada sub-regio representa uma computao paralela (concorrente); Tag LOOP: uma condio de proteo aparece na parte superior de uma linha de vida no corpo. O corpo do loop executado repetidamente enquanto a condio de proteo verdadeira, antes de cada iterao. Quando a condio de proteo falsa na parte superior do corpo, o controle sai do operador de controle; Tag BREAK: este operador de interao indica uma quebra na execuo do processo. usado principalmente para modelar o tratamento de execees.
Fragmentos de Interao
Os fragmentos de interao so noes abstratas de unidades de interao geral. Um fragmento de interao uma parte de uma interao, no entanto, cada fragmento de interao considerado uma interao independente. Uma das principais vantagens do uso de fragmentos de interao caracteriza-se pela possibilidade de se poder referenci-los por meio do operador Ref, que abreviatura de Referred (referido) e significa que se deve procurar por um diagrama cujo nome o mesmo do nome apresentado aps o operador Ref, ou seja, o fragmento faz referncia a outro diagrama no detalhado no diagrama em questo e que deve ser inserido neste, a isto se chama ocorrncia de interao e esta inovao permite que se montem diagramas mais complexos que fazem referncia a outros diagramas como se fossem sub-rotinas, detalhadas em separado.
Portes (Gates)
Um porto uma interface entre fragmentos, um ponto de conexo para relacionar uma mensagem fora de um fragmento de interao com uma mensagem dentro do fragmento de interao. Portes so representados simplesmente pelo encontro da seta da mensagem no retngulo do fragmento de interao, ou, em algumas ferramentas CASE, por pequenos quadrados posicionados na linha vertical do retngulo do fragmento, na altura em que a mensagem dever atingir a linha de vida do objeto a que ele se refere. O propsito de um porto simplesmente estabelecer que esta enviando e quem est recebendo uma mensagem, quando esta mensagem no est contida em um nico fragmento de interao.
Diagrama de Objetos
O diagrama de objetos uma variao do diagrama de classes. A diferena que neste diagrama voc pode colocar os nomes reais aos seus objetos. O diagrama de objetos no to importante quanto o de classes, mas ele vai ajudar a exemplificar um diagrama de classes muito complexo. Por exemplo, uma pessoa fsica que se chama Marcelo, voc pode definir um objeto Marcelo e representa ele aqui. Tecnicamente podemos dizer que o diagrama de objetos representa uma instncia da classe. Os diagramas de objetos tm seu nome sublinhado e todos os seus relacionamentos so mostrados. Seu nome vm separado da classe que ele representa por : (dois pontos). A representao de um objeto um retngulo composto por dois compartimentos, veja figura abaixo. No primeiro compartimento exibido o nome do objeto, e no segundo compartimento os atributos e seus valores so exibidos.
O primeiro compartimento denotado pelo nome do objeto + o tipo do objeto. Exemplo: o objeto d1 do tipo Department, ou seja, o objeto d1 pertence a classe Department. importante ressaltar que a identificao do objeto deve ser sempre sublinhada. No diagrama de objetos temos tambm os objetos annimos. Nesse caso, o nome objeto no exibido. Como podemos ver na figura acima, ContactInformation um exemplo de objeto annimo. O segundo compartimento opcional. Sua notao o nome do atributo seguido do valor do atributo. Os diagramas de objetos tambm representam o vinculo entre os objetos. Os vnculos so representados por um segmento de reta ligando dois objetos. Esse diagrama, ao contrrio do diagrama de classes, raramente utilizado.
Diagrama de Pacotes
Agrupa as classes em unidades de nvel mais alto. Esses elementos podem ser classes, diagramas ou at mesmo outros pacotes. O diagrama de pacotes, ou diagrama de mdulos, definido pela UML descreve os pacotes ou pedaos do sistema divididos em agrupamentos lgicos mostrando as dependncias entre estes, ou seja, pacotes podem depender de outros pacotes.
1. Um pacote pode ter o nome dentro ou na tab.
2. Os pacotes se relacionam atravs de suas dependncias.
Na realidade, no existe propriamente diagramas de pacotes em UML. Pacotes e relaes entre pacotes aparecem em outros diagramas. Pacotes de caso de uso; Pacotes de classes; Pacotes de componentes; Pacotes de ns. Uma vez que representa um agrupamento, um pacote , em geral, dono de diversos elementos. Classes; Interfaces; Componentes; Ns; Colaboraes; Casos de uso.
Dependncia de Pacotes
Dependncia simples: uma alterao do pacote de destino afeta o pacote de origem (dependente); Dependncia <<acess>>: o pacote de origem (dependente) acede elementos exportados pelo pacote destino; Dependncia <<import>>: o contedo pblico do pacote de destino adicionado ao pacote de origem.
Diagrama de Estados
Podemos ver o diagrama de estados como um complemento para o diagrama de classes. Neste diagrama podemos mostrar qual o estado em que o nosso objeto esta naquele momento. O diagrama de estado deve ser construdo para os objetos que tem seus estados definidos e onde o comportamento do objeto muda por causa de um determinado estado. O diagrama de estados visa o estudo do comportamento do objeto. Ele descreve as etapas pelas quais um objeto passa durante sua existncia. Objetos cujas mudanas de estado sejam complexas e difceis de entender podem ficar mais claros com o uso deste tipo de diagrama. Como os diagramas na UML so complementares, o diagrama de classe deve ter uma propriedade para a informao do estado do objeto criado e o diagrama de caso de uso deve prever a alterao do estado deste objeto nas vrias etapas do seu ciclo de vida. O diagrama de estados pode ser usado para descrever atores, subsistemas, operaes e objetos, mas comumente utilizado para objetos.
Componentes
Ponto inicial onde o objeto nasce; Ponto final onde o objeto deixa de existir; Transio relacionamento entre dois estados. Indica que um objeto no primeiro estado realizar certas aes (processos) e entrar no segundo estado quando um evento ocorrer ou uma condio (guarda) for satisfeita. o Evento: ocorrncia de um estmulo que aciona uma mudana de estado; o Guarda: uma condio lgica, a transio ocorre quando a guarda for verdadeira; o Ao: processo associado transio, a mudana de estado ocorre quando a ao executada. Estado possui um nome a vrias partes internas, que so opcionais. A atividade um processo associado ao estado.
Estados
So as situaes de um objeto nas quais ele satisfaz alguma condio, aguarda um evento ou realiza alguma atividade. Um diagrama de estados pode ser baseado em uma classe, mas podem existir classes sem estados a serem modeladas. Portanto um sistema pode ter vrios diagramas de estados e uma classe pode ter mais de um diagrama de estado associado. Outra forma de desenhar um estado separ-lo em dois compartimentos: um para um nome e outro para transies internas ao estado.
Esta diviso opcional e adotada em situaes onde muitos mtodos sejam chamados nas diferentes etapas da transio de estados. Possui os seguintes elementos: Compartimento de Nome: local onde conter o nome do estado; Compartimento de Transies Internas: lista as aes ou atividades executadas enquanto o objeto estiver no estado em foco; As palavras reservadas que aparecem antes das aes na rea de transies internas identificam o evento que disparado: Entry identifica uma ao que executada na entrada do estado; Exit identifica uma ao que executada na sada do estado; Do identifica uma atividade executada continuamente enquanto o objeto estiver no estado; Include uma chamada a uma submquina; On evento a ao ser executada ao ocorrer este evento, sem que o objeto saia deste estado. Tambm chamado de transio externa.
Subestados
Um estado simples aquele que no possui subestrutura. Um estado que possui subestados (estados aninhados) denominado estado composto. Os subestados podem ser aninhados em qualquer nvel. Uma mquina de estados aninhados deve ter no mximo um estado inicial e um estado final. Os subestados so usados para simplificar mquinas complexas de estados simples mostrando que alguns estados so possveis apenas dentro de um determinado contexto (o estado confinado).
Diagrama de Implantao
Um diagrama que mostra a configurao dos ns de processamento em tempo de execuo e os componentes, processos e objetos que neles vivem. Um dos diagramas que acredito ser um dos mais importantes tambm um dos menos vistos nos projetos de sistemas de informao. O diagrama de implantao representa como realizada a distribuio do sistema atravs de ns de hardware, componentes e dependncias de software e as suas devidas relaes de comunicao. O diagrama de implantao pode ser representado de duas formas: como descritor, onde mostra a configurao bsica do hardware, ou como uma instncia, onde mostra as reais caractersticas de configurao de hardware. Os diagramas de implantao so empregados para modelagem da viso esttica de implantao de um sistema. Com essa viso podemos analisar qual a real necessidade do projeto para a aquisio, por exemplo, de mquinas e pacotes de software adicionais. Ou seja, a importncia do diagrama de implantao no est somente na possibilidade de visualizar e especificar fisicamente os sistemas, mas sim como um auxlio no gerenciamento de projetos e sistemas de informao. O diagrama de implantao mostra a estrutura de ns nos quais os componentes e artefatos so implantados. Um n um elemento do mundo real e que representa um recurso computacional. Pode ser um dispositivo ou sistema operacional ou algum aplicativo necessrio para a execuo do sistema. no n onde sero implementados os artefatos. A comunicao entre ns mais utilizada a associao. Mas qualquer outro tipo de relacionamento definido na UML pode ser utilizado. A comunicao definida ainda por um esteretipo que descreve o tipo de comunicao que estabelecida.
Artefatos
Um artefato a especificao de um conjunto concreto de informaes que utilizado ou produzido por um processo de desenvolvimento de software, ou para a instalao ou operao de um sistema computacional. Exemplos de artefatos incluem arquivos de modelos, arquivos de cdigo-fonte, scripts, arquivos executveis, tabelas em bancos de dados, documento de texto, mensagem de e-mail ou qualquer outro resultado de um processo de desenvolvimento. Um artefato representa, portanto, um elemento concreto do mundo fsico. Uma instncia particular do artefato (ou cpia do artefato) instalada em uma instncia de um n. Artefatos podem manter associaes com outros artefatos que podem estar aninhados dentro de si prprio. Diversos esteretipos esto previstos na norma, especificando o tipo de artefato. Por exemplo, source ou executable. Estes esteretipos podem ser ainda especializados mais ainda em um profile. Por exemplo, o esteretipo jar poderia ser definido como uma subclasse de executable de forma a designar arquivos Java executveis.
Figura 1: Exemplo de um artefato.
Figura 2: Constituio de um artefato. Na linguagem UML, um artefato apresentado utilizando-se o retngulo de uma classe ordinria, com o uso da palavra-chave artifact. Alternativamente, este retngulo pode acrescentar ainda um pequeno cone no canto superior direito do retngulo.
Ns
Um n um recurso computacional onde artefatos podem ser instalados para posterior execuo. Ns podem ser interconectados por meio de conexes que definem estruturas de redes. Estas conexes representam caminhos de comunicao possveis entre os ns. Topologias especficas de redes podem ser definidas por meio dessas conexes. Ns hierrquicos (ou seja, ns dentro de ns) podem ser definidos utilizando-se associaes do tipo composio, ou definindo-se uma estrutura interna para aplicaes de modelagem avanada. Arcos tracejados com o uso do keyword deploy podem ser utilizados para representar a capacidade de um n de suportar um determinado tipo de artefato. Alternativamente, isso pode ser representado utilizando-se artefatos aninhados dentro do n. Em ambos os casos, isso significa que o artefato correspondente encontra-se instalado no n.
Figura 3: Exemplo da notao de um n.
Figura 4: Exemplo de artefatos instalados em um n.
Ns podem ainda receber esteretipos, para representar diferentes tipos de plataformas de execuo. Exemplos de esteretipos desse tipo incluem os esteretipos device para representar plataformas de hardware e executionEnvironment para representar plataformas de software com ambientes executveis.
Caractersticas do Diagrama
Pode representar a estrutura da plataforma em que ser utilizado; Pode representar bancos de dados, componentes de terceiros; Pode representar os servidores, a rede; Pode representar a configurao dos equipamentos.
Diagrama de Componentes
A linguagem UML especifica um conjunto de construtos que podem ser utilizados para definir sistemas de software de tamanho e complexidade arbitrrios. Em particular, define-se o conceito de componente, como uma unidade modular com um conjunto de interfaces bem definidas, que pode ser substitudo dentro de seu ambiente. O conceito de componente oriundo da rea de desenvolvimento baseado em componentes, onde um componente modelado durante o ciclo de desenvolvimento e refinado sucessivamente durante a instalao e execuo do sistema. Um aspecto importante do desenvolvimento baseado em componentes o reuso de componentes previamente construdos. Um componente pode ser considerado como uma unidade autnoma dentro de um sistema ou subsistema. Ele deve possuir uma ou mais interfaces, que podem ser potencialmente disponibilizadas por meio de portas, e seu interior normalmente inacessvel. O acesso a um componente deve ocorrer nica e exclusivamente por meio de suas interfaces. Apesar disso, um componente pode ser dependente de outros componentes, e a linguagem UML prov mecanismos para representar essa dependncia, indicando as interfaces que um componente demanda de outros componentes. Esse mecanismo de representao de dependncias torna o componente uma unidade encapsulada, de forma que o componente pode ser tratado de maneira independente. Como resultado disso, componentes e subsistemas podem ser reutilizados de maneira bastante flexvel, sendo substitudos por meio da conexo de diversos componentes por meio de suas interfaces e dependncias. A linguagem UML suporte a especificao tanto de componentes lgicos (e.g. componentes de negcios, componentes de processo) como de componentes fsicos (e.g. componentes EJB, componentes CORBA, componentes COM+ ou .NET, componentes WSDL, etc), junto com os artefatos que os implementam e os ns em que esses componentes so instalados e executados. Um componente possui um carter hierrquico, que pode ser explorado no processo de construo de um sistema. Desta forma, um componente pode ser visto, do ponto de vista externo, como um elemento executvel do sistema, que se conecta com outros componentes para integrar a composio deste sistema. Por outro lado, de uma perspectiva interna, um componente pode ser visto como tambm um conjunto integrado de componentes menores que se integram, constituindo o componente em seu nvel superior. Dessa forma, um componente representa uma parte modular de um sistema que encapsula seu contedo e cuja manifestao pode ser substitudo no ambiente em que se insere. Um componente define seu comportamento por meio da definio de suas interfaces disponibilizadas e das interfaces de que depende. Dessa forma, um componente pode ser substitudo por outro componente que possua um mesmo conjunto de interfaces disponibilizadas. A construo de um sistema envolve a montagem de componentes, uns aos outros, por meio de suas interfaces. Um arranjo de componentes montado desta maneira, constitui-se de um artefato. Artefatos podem ser instalados em diferentes ambientes de execuo e colocados em execuo nestes. Um componente uma unidade auto-contida que encapsula o estado e o comportamento de um grande nmero de objetos. Um componente especifica um contrato formal dos servios que prov a seus clientes e dos servios que necessita de outros componentes em termos de suas interfaces disponibilizadas e requeridas. Um componente uma unidade substituvel que pode ser remanejada tanto durante o design como na implementao, por outro componente que lhe seja funcionalmente equivalente, baseado na compatibilidade entre suas interfaces. De modo similar, um sistema pode ser estendido adicionando-se novos componentes que tragam novas funcionalidades. As interfaces disponibilizadas e requeridas podem ser organizadas opcionalmente por meio de portas. Portas definem um conjunto de interfaces disponibilizadas e requeridas que so encapsuladas de maneira conjunta. Certo nmero de esteretipos padro so previstos para serem utilizados com componentes. Por exemplo, o esteretipo subsystem pode ser utilizado na modelagem de componentes de larga escala. Os esteretipos specification e realization podem ser utilizados para representar componentes com especificaes e realizaes distintas, onde uma nica especificao pode ter mltiplas realizaes. A notao UML para um componente segue a notao de uma classe estereotipada com o esteretipo component. Opcionalmente, no canto superior direito, pode-se incluir um cone especfico, constitudo por um retngulo maior e dois pequenos retngulos menores sobressaindo-se em seu lado esquerdo. Essa representao pode ser visualizada na figura a seguir.
Figura 5: Exemplo da Notao de um Componente, com sua Interface disponibilizada.
Na figura a seguir, apresenta-se um componente com suas interfaces disponibilizadas e requeridas. Neste exemplo, o componente Order disponibiliza as interfaces ItemAllocation e Tracking, e requer as interfaces Person, Invoice e OrderableItem.
Figura 6: Exemplo da Notao de um Componente com Interfaces Disponibilizadas e Requeridas.
A figura a seguir apresenta outras notaes para componentes, com diferentes compartimentos modelando diferentes aspectos do componente. Em ambos os casos, as interfaces dispobilizadas e requeridas esto representadas internamente em compartimentos, ao invs de externamente, por meio da conexo com interfaces.
Figura 7: Outros Exemplos de Notao para Componentes.
A figura a seguir apresenta uma outra notao alternativa, onde as interfaces disponibilizadas e requeridas so modeladas detalhadamente.
Figura 8: Notao para Componentes com Interfaces Detalhadas. A figura a seguir apresenta a estrutura interna de um componente, realizado pela composio de diversos outros componentes. Observe como as interfaces requeridas de alguns componentes so interligadas s interfaces disponibilizadas por outros componentes, para a montagem do componente de nvel superior.
Figura 9: Perspectiva Interna de um Componente. Observe tambm na figura acima, a definio de portas, representadas como pequenos quadrados onde as interfaces requeridas e disponibilizadas so conectadas aos componentes.
Diagrama de Comunicao
Este diagrama era conhecido como Diagrama de Colaborao at a verso 1.5 da UML, tendo o seu nome modificado para Diagrama de Comunicao a partir da verso 2.0 e est amplamente associado ao Diagrama de Sequncia, na verdade um complementa o outro. As informaes mostradas no Diagrama de Comunicao, so com frequncia, praticamente as mesmas apresentadas no Diagrama de Sequncia, porm com um enfoque diferente, visto que este diagrama no se preocupa com a linha de tempo do processo, concentrando-se em como os objetos so vinculados e quais mensagens trocam entre si durante o processo.
O Diagrama de Comunicao tambm suporta atores e condies, sendo estas representadas entre colchetes. As mensagens trocadas podem ser enumeradas para indicar a sua ordem. Setas (): troca de mensagem (chamada) de mtodos, que podem ser enumeradas; Reta (___): vnculo entre dois objetos; Colchetes ([ ]): condio.
Diagrama de Estrutura Composta
Este diagrama utilizado para modelar colaboraes. Uma colaborao descreve uma viso de um conjunto de entidades cooperativas interpretadas por instncias que cooperam entre si para executar uma operao especfica. Este diagrama tambm pode ser utilizado para definir a estrutura interna de um classificador. Um classificador um elemento de modelo que descreve caractersticas estruturais e comportamentais. Seus tipos incluem: associao, classe e interface, sendo as classes seu tipo mais comumente usado.
Diagrama de Perfil
um diagrama auxiliar da UML que permite definir esteretipos de customizados, valores pr-definidos e restries. O mecanismo de perfil foi definido na UML para fornecer um mecanismo de extenso leve para o padro UML. Os perfis permitem adaptar o metamodelo UML para diferentes plataformas (como J2EE ou. NET), ou domnios (como o tempo real ou empresa de modelagem de processos).