GUIA DE CONSULTA , RAPIDA

Douglas Marcos da Silva

Guia de Consulta Rapida UML de Douglas Marcos da Silva

Todos os direitos reservados. E proibida a reprodugao desta obra, mesmo parcial, por qualquer processo, sem previa autorizagao, par escrito, do autor e da Editora.

ra desse guia Ul;ao 11orienta9ao aobjetos Objeto Oasse Polimorfismo Heran9a . letodos orientados a objetos u9ao 11UML Origem e evolu9ao da UML Diagramas na UML Diagrama de casos de uso Diagramas de intera9ao Diagrama de gnificos de estados Diagrama de atividades Diagrama de classes Diagrama de componentes Diagrama de objetos Diagrama de implanta9ao Como os diagramas se relacionam Prop6sitos da UML que a UML nao e Onde pode ser utilizada a UML Elementos da UML .: Bloeos de constru9ao da UML estaticos Classe Colabora9ao Caso de usa Componente dinamicos Intera9ao Maquina de estados P.acotes na UML

5 6 7 7 8 8 9 10 10 IO 10 11 12 13 13 14 14 15 15 16 16 16 17 17 18 18 18 18 19 19 19 19 20 20 20 21 22 22 23 23 24 24 25 26 27 27 28 28 31 32 34 36 37

Novatec Editora Ltda. Rua Cons. Moreira de Barros 1084 Conj. 01 02018-012 Sao Paulo - SP Brasil Tel.: (Oxxll) 6959-6529 Fax: (Oxxll) 6950-8869 E-mail: novatec@novateceditora.com.br Site: www.novateceditora.com.br

......................................................................................... Relacionamentos Associa9ao Agrega9ao e composi9ao Generaliza9ao Especializa9ao Realiza9ao oem utilizando a UML J.Jodelagem da arquitetura de sistemas A importancia da modelagem Construindo model os ~Iodelagem orientada a objetos I)ggrama de casos de usa Alor Varia90es na especifica9ao de casos de usa Erros comuns na especifica9ao de casos de usa Relacionamentos entre casos de usa Arquitetura de sistemas orientada a casos de uso ~Iodelando diagramas de casos de uso Como fazer

Diagrama de classes Atributos , Operacroes Pre-condicrao Pos-condicrao Operacroes versus metodos Analise de casos de uso Como fazer Diagrama de objetos Estrutura de objetos Diagramas de interac;ao Diagrama de seqUencia Diagrama de colaboracrao Introducrao aos objetos ReaIizando casos de uso Auxilio aos desenvolvedores Como fazer Diagrama de gflificos de estados ......................................... Estados Evento Transicrao Analisando os estados para urn objeto Como fazer Diagrama de atividades Thread condicional Concorrencia dinamica Raia de natacrao Diagrama de atividades versus diagramas de interacrao Como fazer Diagrama de componentes Componentes Interfaces Outros tipos de componentes Sistemas base ados em componentes Como fazer Diagrama de implantacrao A UML no ambiente ffsico Uso comum Como fazer Mecanismos de extensibilidade da UML Estereotipos Restricroes Alguns padroes para restricrao OCL (Object Constraint Language) Ferramentas que suportam a UML Rose Visio PowerDesigner Onde obter mais informacroes Versoes da UML Diferencras entre as versoes da UML Glossario Obtendo mais informacroes Consulte a UMLBrasil Consulte 0 autor , fndice

38 41 42 44 45 46 46 49 50 50 51 52 54 54 55 56 57 58 58 59 59 59 60 60 63 64 65 66 66 67 68 69 69 70 70 71 71 72 72 73 73 78 78 79 80 80 80 80 80 81 81 84 92 92 92 93

trutura desse guia

o topico lntrodur;iio a orientar;iio a objetos e apresentada uma visao geral da orientayao a objetos, seus principais conceitos e os metodos orientados a objetos mais usados nos ultimos anos. Em lntrodur;iio a UML e dada uma visao geral sobre todos os conceitos da UML. Sao apresentados os diagramas da UML, os relacionamentos, origem da linguagem, entre outros assuntos . Recomenda-se a leitura desse capitulo para a formayao de uma base conceitual sobre a UML. o topico Modelagem utilizando a UML, antes de entrarmos mais detalhadamente nos diagramas da Iinguagem, apresentam-se uma pequena introduyao a modelagem da arq uitetura de sistemas orientados a objetos e a importancia da modelagem de sistemas. Em seguida, e abordado minuciosamente cada diagrama da UML. Em Ferramentas que suportam a UML, sac apresentadas principais ferramentas que suportam a linguagem , contendo tambem 0 site de cada fabricante. Apendice sac ressaltadas as principais diferenyas tre as vers6es da UML, ocorridas ao longo de sua evoluyao.

II

Introduc;ao

a orientac;ao

a objetos

A orientac;iio a objetos surgiu como uma nova forma de modelar e construir sistemas de softwares, isto e, organizar e geriros conhecimentos manipulados e registrados dentro de uma empresa. No desenvolvimento de urn sistema orientado a objetos, dados e process os siio organizados e manipulados por objetos, e niio por programas.

Vantagens da orientaC;iio a objetos : Reutilizac;iio dos objetos Os dados e os processos siio manipulados por objetos, niio ficando engessados dentro de program as, isto e, os objetos construfdos podem ser utilizados pordiferentes sistemas. Modularidade

Pode ser qualquer coisa na natureza aracterfsticas e comportamentos.

que possua

o sistema e formado por objetos e niio por programas, facilitando 0 trabalho e a manutenc;iio desses objetos no futuro.
Utiliza-se dos mesmos conceitos da realidade construc;iio de sistemas de software. na

mna abstrac;iio de urn conjunto de objetos que possuem

mesmos tipos de caracterfsticas e comportamentos.

A orientac;iio a objetos baseia-se em conceitos da realidade - objetos, estados e estfmulos - para modelagem e construc;iio de sistemas de software. Dessa forma, 0 usa da orientac;iio a objetos se toma mais natural, pois os conceitos utilizados siio os mesmos que ja conhecemos, s6 que aplicados nesse casos ao desenvolvimento de sistemas.

sIi:~_
::: ...

''l

--

c.ro

de passeio

Carro esportivo

II

II

Polimorfismo (do grego "muitas formas") refere-se aos process os que varios objetos podem executar, dado apenas a solicita~ao de uma unica opera~ao. No ambiente polim6rfico, todos os objetos con tern uma mesma opera~ao, que e implementada por metodos particulares a cada objeto (a diferen~a entre opera~6es e metodos e apresentada na pag. 46).

Nos ultimos tempos houve uma grande evolu~ao na engenharia de software, que pas sou a contar com tecnicas, como a analise, 0 projeto estruturado e a Engenharia da Informa~ao. as metodos orientados a objetos surgiram na decada de 70, procurando melhorar essas tecnicas. A seguir sao apresentados resumidamente alguns metodos que surgiram para a orienta~ao a objetos. Metoda
Booch Descri~iio Consiste em tecnicas do desenho orientado a objetos. Esse metodo utiliza-se do desenho de objetos, que servem como base para a criacao dos mOdulosdo sistema. Esse metodo loi criado por Grady Booch (Rational Software). OMT 0 metodo OMT (Object Modeling Technique) consiste na modelagem semantica de dados, suportando os conceitos de: Modelagem de dados (atributos e relacionamentos). Objetos (composicao e agregacao). Heranca. Esse metodo loi criado por James Rumbaugh (GE Corporation). Os conceitos apresentados antes tambem sao utilizados pela UML, e sao detalhados a partir da pagina 20. OOSE 0 metodo OOSE (Object Oriented Soltware Engineering), consiste na analise dos requerimentos de um sistema utilizando casos de use, criando categorias para pessoas e equipamentos com que esses casos interagem. Esse metodo loi criado por Ivar Jacobson. as conceitos apresentados antes tambem sao utilizados pela UML e sao detalhados a partir da pagina 27. CoadIYourdon Peter Coad e Ed Yourdon dividiram a analise orientada a objetos em classes e objetos. Dentro desse contexto, os objetos sao relacionados pormeio dos conceitos de agregacao, generalizacaolespecializacao, associacoes, conexoes e . mensagens.

0 compartilhamento pelas classes especializadas (subclasses) dos atributos e opera~6es de classes mais gerais (superclasse).

Automovel esportivo

as conceitos da orienta~ao a objetos sao explorados em mais detalhes no decorrer deste guia.

II

II

Introdu~ao a UML
A Unified Modeling Language (UML) e 0 resultado da unifica~ao dos metodos Booch, OMT e OOSE, que da origem a uma linguagem padronizada para a modelagem de sistemas de software orientados a objetos, sendo adotada pela industria de software como linguagempadrao, e tambem por fornecedores de ferramentas CASE.

Os trabalhos para a cria~ao da UML iniciaram-se em 1994 com Grady Booch da Rational Software (metodo Booch) e James Rumbaugh (OMT), que combinaram seus dois metodos mais populares. Versiio
UML 0.8 UML 0.9

Ano
1995 1996

Principais'alos ocorridos
Lan9amento do primeiro esbo90da UML. Integra9aode Ivar Jacobson il equipe da Rational Software, e seu metodo OOSE il expansao do escopo da UML; forma9ao de um consorcio de empresas, com 0 objetivo de apoiar a delini9ao da UML. A UML loi submetida como candidata a Iinguagem-padraode modelagem il OMG (Object Management Group, uma entidade depadroniza9aoestabelecidapela industria de software). Expansao do consorcio formado por empresas para apoiar a defini9ao da UML, e aceita9ao da UML pela OMG. Revisoes e novas padroniza90es. Revisoes e novas padroniza90es.

Os diagramas de intera~ao representam colabora~6es entre objetos, para realizarem algum tipo de comportamento para um sistema. Os diagramas de intera~ao sao representados por : Diagrama de sequencia. Diagrama de colabora~ao.

UML 1.0

1997

UML 1.1

1997

UML 1.2 UML 1.3

1998 1998

Odiagrama de seqiiencia da enfase

a ordena~ao

temporal

em que as mensagens sao trocadas entre os objetos de um

Diagrama e a representa~ao grafica de urn conjunto de elementos do sistema. A UML disponibiliza nove diagramas que permitem representar diferentes partes do modelo de urn sistema.

sistema. Podemos entender por mensagens, os servi~os solicitados porum objeto a outro, e as respostas devolvidas a essas solicita~6es.

o diagrama de casas de usa representa urn conjunto de atores, casos de uso e os relacionamentos entre eles.

[tern Estoque] AtualizarQ

III

Introdu~ao it UML

Introdu~ao it UML

Diagrama de colabora~ao diagrama de colaborar;iio da enfase a ordena<;ao estrutural em que as mensagens sao trocadas entre os objetos de urn sistema.

Diagrama de atividades

o diagrama de atividades representa a modelagem do fluxo de controle de uma atividade para uma outra no sistema. Sao exibidos os estados das atividades e a<;6es, transi<;6es e objetos.

1: RegistrarO 2: VerificarO 3: [tern EstoqueJ:=AtualizarO

{ Efeluar pedido

--;r...

(~
"

Esloque

Diagrama de graficos de estados

o diagrama de graficos de estados representa os estados possfveis de urn objeto em particular. Sao exibidos os estados de urn objeto, eventos, transi<;6es e atividades. Pode ser usado principal mente para a modelagem de estados de classes e colabora<;6es.

Diagrama de classes

o diagrama de classes representa a estrutura (esqueleto) de urn sistema, sendo encontrado geralmente na maioria dos sistemas orientados a objetos. Sao exibidos classes e seus respectivos relacionamentos.
NotaFiscal codigo
naturezaOperacao Produto codigo nome valorUnitario 0 ..' 1..- InserirQ

condicaoPagamento
tipoPrestServico dataEmissao valor

I
i

RegistrarQ
RecuperarO

ReeuperarQ ExcluirQ AtualizarQ

CaneefarQ

I I
I

II

Introdu~aoit UML Diagrama de componentes

o diagrama de componentes representa urn conjunto de componentes e suas respectivas dependencias, podendo ter como base de sua constru<;ao os diagramas de classes.

de implantar;iio representa a configura<;ao e a arquitetura de urn sistema em que estarao ligados seus respectivos componentes, podendo ser representado tambem a arquitetura ffsica de hard wares, processadores, etc. Com 0 diagrama de componentes, representa os aspectos ffsicos de urn sistema.

o diagrama

o diagrama de objetos representa as instancias das classes de urn sistema, em determinado ponto no tempo.
c: Cliente codigo Nome

(Todos os diagramas apresentados ate aqui serao explorados com maior riqueza a partir da pag. 24).

Como as diagramas se relacionam na

UML
Os diagramas da UML representam diferentes partes do modelo de urn sistema. No quadro a seguir, edemonstrado como os diagram as se relacionam, formando toda a modelagem orientada a objetos.

= 145100 = "Joao da Silva"

cont: Contrato numero 00125 Natureza Operacao

= "Venda"

II

11

A UML nasceu com 0 prop6sito dedocumentar, visualizar, especificar e construir sistemas de software orientados a objetos. Prop6sito Descri~ao
Artelatos como requisi~6es de neg6cios, modele de arquitetura, c6digo-Ionte, modelo de analise, prot6tipo e outros documentos que servem de inlorma~ao sobre 0 sistema, podem ser documentados com a UML. No processo de desenvolvimentode sistemas de software, e quase impossivel a visualiza~ao de toda a estrutura de um software sem 0 use de modelos que a represente. Dessa lorma, a UML disponibiliza simbolos graficos para a representa~ao de artelatos de software. A UML e uma Iinguagem que atende a todos osrequisitos de especilica~ao dentro de um processo, desde a lase de analise ate a lase de testes e implementa~ao do sistema construido. Na UML e possivel realizar um mapeamento dos modelos gerados, para Iinguagens de programa~ao e ate mesmo para banco de dados relacionais ou orientados a objetos.

as elementos da UML sao as simbologias e nota~5es que utilizaremos para construir os modelos orientados a objetos. Nessecaso, os elementos principais sao os blocos de constru~ao.

as blocos de constru~ao da UML sao as materias-primas utilizadas pelos diagramas para representar partes de urn sistema de software. Entre os blocos de constru~ao existentes na UML, podemos observar: Itens. Relacionamentos.

A UML nao e uma linguagem de programa~ao visual, e sim uma linguagem para modelagem visual. Apesar de oferecer suporte a di versas linguagens de programa~ao, a UML e uma linguagem para a constru~ao de artefatos de software que servem para a tomada de decisao quanta it defini~ao de arquitetura, implementa~ao, etc. A UML nao e urn processo de desenvolvimento, mas pode e deve ser aplicado a urn. A UML, como uma linguagem de modelagem, pode e deve ser aplicada a urn processo de desenvolvimento de software, assim como outras linguagens utilizadas para a constru~ao de artefatos de software. Em Un! contexto de processos, a UML se prop5e a tratar, em diversos domfnios, diferentes problemas e em diferentes organiza~5es.

as itens sao os blocos de constru~ao da modelagem orientadaa objetos. Existem quatro tipos de itens na UML. Sao eles: Tipo Descri~ao
Representam a estrutura do modelo, elementos conceituais e fisicos (classes, colabora~6es, casos de use, etc.). Definem 0 comportamento do modele (intera~5es e estados dos objetos). Sao as partes organizacionais da UML. Sao as partes explicativas do modele na UML (comentarios e observa~6es de esclarecimentos no modelo).

Pacotes Notas

A UML pode ser aplicada a qualquer tipo de sistemas de software. Por ser uma Iinguagem muito abrangente, ela pode ser usada tambem para modelar process os de trabalhos, projetos de har dv'are, etc.

II

Os itens estaticos representam estavel de urn sistema.

esqueleto e a estrutura

Urn componente e a parte fisica de urn sistema. Existem diferentes tipos de componentes, como os componentes COM+ e Java Beans (mais detalhes na pag. 67).

Uma c1asse e urn conjunto de objetos que compartilham os mesmos atributos, opera~oes e relacionamentos. E representada graficamente como no exemplo a seguir:

NotaFiscal codigo naturezaOperacao condicaoPagamento tip 0 P rest S ervic 0 dataEmissao valor RegistrarO RecuperarO CancelarO

Os itens dinamicos representam as partes de urn sistema que possam ter alguma altera~ao. Existem dois tipos principais de itens dinamicos. Sao eles: Intera~ao. Maquina de estados.

Uma colaboraf(iio e 0 nome dado a intera~ao entre duas ou mais classes, com 0 objetivo de fomecer algum comportamento cooperativo. Ocorrem por meio da troca de mensagens entre dois ou mais objetos (mais detalhes na pag. 54).

Representa a realiza~ao dos processos de urn sistema, por meio da troca de mensagens entre 'os objetos. Pode envolver mensagens, seqtiencias de a~oes e conexoes entre os objetos (mais detalhes na pag. 51). Uma intera~ao e representada por uma f1echa cheia, como no exemplo a seguir:

Urn caso de uso e urn documento que descreve os cemirios pretendidos para urn sistema, com 0 objetivo de atender as necessidades do usuario (mais detalhes na pag. 27).

E representado

graficamente como no exemplo a seguir:

Representa urn comportamento que especifica as seqtiencias de estados pel os quais os objetos passam durante sua existencia, de acordo com os eventos atendidos. No exemplo aseguir, temos urn estado possivel para 0 objeto "Venda". Venda Pendente

II

AS pacotes organizam os modelos criados na UML. Todos os blocos de constru~ao criados na UML (casos de uso, classes, componentes, etc.); bem como os diagramas que tratam desses blocos, podem ser organizados em pacotes.
Deve-se fazer essa organiza~ao observando a semelhan~a de cada bloco e diagrama da UML, no que diz respeito a solu~ao do problema que cada urn esta empregando.

Uma associa~ao des creve relacionamentos entre objetos. Cada associa~ao tern duas pontas, onde em cad a ponta esta ligado urn objeto. Por exemplo, poderfamos ter urn relacionamento de associa~ao entre 0 objeto Cliente na primeira ponta, e 0 objeto AnaliseCredito na outra ponta.

NotaFiscal codigo naturezaOperacao condicaoPagamento tipoPrestServico dataEmissao valor RegistrarO RecuperarQ CancelarQ

Associal'ao

1
0.."

Produto codigo nome valorUnitario

1.." InserirO

~~~
Multiplicidade

RecuperarO ExcluirO AtualizarO

Ea
As notas representam comentarios, observa~6es e esclarecimentos que podem se utilizar para qualquer elemento da UML. No exemplo a seguir, a representa~ao de uma nota informando a ultima versao de uma classe.

indica~ao de quantos objetos podem participar de dado relacionamento. No exemplo anterior, pode-se dizer que 0 objeto NotaFiscal pode ter urn ou mais objetos Produtos, enquanto esse objeto pode zero ou mais objetos NotaFiscal. Na UML, temos basicamente multiplicidades: os seguintes tipos de

Ultima versao : 2.0

o (zero)
1 (um) 0..1 (zero ou um) 0.. * (zero ou mais) 1.. * (urn ou mais)

*
as relacionamentos reunem os itens criados na UML. Existem seis tipos de relacionamentos. Sao eles: Associacao. Agrega~ao e composi~ao. Generaliza~ao. Especializa~ao. Realiza~ao.

(muitos)

Introdu~aoit UML

Agregatrao e compositrao
A agrega<;ao e urn tipo de associac;ao na qual 0 todo e relacionado com suas partes (urn objeto todo contem os objetos-partes - relacionamento todo/parte). E representada como uma linha de associac;ao com urn diamante junto a classe agregadora.
PessoaFisica dataNascimento sexo RG CPF salario estadoCivii ContaBancaria Banco Agencia Conta tipoConta valUmite tipoEspecial

Especializatrao
A especializac;ao e a capacidade de se criar subtipos que representam refinamentos nos quais a estrutura e/ou comportamento do supertipo sac adicionados ou modificados. Os procedimentos para obter a especializac;ao sac: Perceber que algumas classes apresentam estrutura e/ ou comportamento especializado. Criar subtipos de acordo com sua especializac;ao.

Clionto
codigoCliente

nomeCliente Endoroco
Bairro

Cidado

CEP

A compoSlc;ao e urn tipo de relacionamento muito semelhante a agregac;ao. Em uma composic;ao, 0 objeto~ parte pode pertencer somente ao objeto-todo. AI em disso, geralmente 0 objeto-todo vive e mOITecom suas partes, isto e, acontece uma remoc;ao em cascata. E representada como uma linha de associac;ao com urn diamante preto, junto a classe agregadora.
PessoaFisica dataNascimento sexo RG CPF salario estadoCivil ClienteReferencia Nome Telefone tipoReferencia

Tolo(on01 Tolo(on02

PessoaFisica dataNascimenta sexo RG

PessoaJuridica CNPJ inscricaoEstadual

CPF
salario

ramoAtividado
faturamentoAnual numFuncionarios

esladoCivil

Generalizac;ao e a capacidade de se criar supertipos que encapsulam a estrutura e 0 comportamento comum a varios subtipos. Os procedimentos para se obter a generalizac;ao sac: Identificar similaridades de estruturalcomportamento entre varias classes. Criar 0 supertipo para encapsular a estrutura e comportamento comum a mais de uma classe.
0

A realizac;ao e urn relacionamento entre itens, em que urn item implementa comportamentos especificados por outros. Pode ser realizado entre interfaces e classes ou componentes que as realizam; e entre casos de uso e as colaborac;oes que os realizam. E representado por uma seta pontilhada, como no exemplo a seguir:

Os objetos originais passam a ser subtipos do novo supertipo criado.

Modelagem utilizando a UML

Modelagem utilizando a UML

Antes dos diagramas da UML serem apresentados urn a urn em detalhes, sent demonstrado como e dividida a modelagem de urn sistema orientado a objetos e o'uso da UML nesse contexto.

A arquitetura de urn sistema representa urn conjunto dos artefatos e elementos que formarao 0 sistema. A arquitetura deve abranger como este sera construido, seus elementos estruturais e comportamentais, suas colabora~5es, entre outras. Construir sistemas de software e uma tare fa que requer a visualiza~ao da arquitetura desses sistemas sob varias perspectivas e em diferentes niveis de detalhamento. Todos os en vol vidos na constru~ao de sistemas - gerentes, analistas, programadores, usuarios finais - necessitam visualizar a arquitetura de urn sistema sob perspectivas diferentes, pois a necessidade de entendimento de cada participante nesse processo influenciara seu tra:balho futuramente quando 0 sistema estiver pronto. Portanto, a arquitetura de urn sistema deve ser visualizada por meio de cinco vis5es:

Essa visao focaliza as quest6es de desempenho, escalabilidade, mecanismos de concorrencia e de sincroniza~ao, Diagramas utilizados; os mesmos diagramas da visao de projeto. Implementa~ao Essavisao focalizaos artefatoslisicos para aefetiva montagem do sistema. Sao abordados componentes e outros arquivos que servem para a montagem do sistema. Diagramas utilizados; diagrama de componentes, diagramas de intera~ao,diagrama de atividades ede graficos de estados. Implanta~ao Essa visao focaliza os nos que formam a topologia de hardware em que 0 sistema sera executado. Diagramas utilizados: diagrama de implanta~ao, diagramas de intera~ao,diagrama de atividades e de graficos de estados.

Processo

Antes de entrarmos mais detalhadamente nos diagramas da UML, e necessario entendermos a importancia de se fazer a modelagem dos sistemas de softwares que voce construira. Vamos imaginar uma possivel situa~ao. Voce trabalha para uma grande rede de lojas de departamentos, onde saG comercializados diversos produtos como eletroeletr6nicos, eletrodomesticos, informatica e outros. Essa rede automatizara toda a sua area de concessao de credito, e foi designado a voce a condu~ao de todo 0 processo de constru~ao de urn sistema que atenda as necessidades de neg6cios dessa empresa. Esse sistema sera encarregado de realizar toda a analise de credito dos cIientes dessas lojas, seguin do uma rigorosa polftica de credito estabelecida pela diretoria. Esse sistema deve fomecer informa~5es sobre 0 credito do cIiente, por meio de Orgaos de Prote~ao ao Credito, realizar analises pelo Credit Score, conferir as informa~5es pessoais prestadas pelo cliente, enfim, verificar 0 enquadramento do perfil desse cIiente junto as polfticas de concessao de credito da empresa.

Visao
Caso de uso

Descri9ao
Essa visao focaliza os comportamentos de um sistema, A visao deve ser transparente para todos os envolvidos na constru~ao do sistema -gerentes, analistas, programadores, usuarios finais. Diagramas ulilizados; diagrama de casos de use, diagramas de intera~ao,diagrama de alividades ede graficos de estados. Essa visao focaliza a estrutura (esqueleto) de um sistema. A visao sob essa" perspectiva demonstra as classes, colabora~6es e as interfaces de um sistema em constru~ao. Diagramas ulilizados : diagrama de classes, diagrama de objetos, diagrama de intera~ao, diagrama de atividades e de graficos de estados.

A menos que ja tenha feito diversos sistemas com as mesmas requisi~5es de neg6cios, voce certamente precisara fazer urn planejamento antes de come~ar a fazer a primeira linha de programa~ao. Nesse caso, voce devera estimar 0 tempo necessario para que esse sistema seja desenvolvido, bem como qual sera o custo do seu desenvolvimento. Sera preciso estimar tambem quais serao os recursos humanos envolvidos nesse processo, bem como 0 custo de cada recurso, suas responsabilidades, entre outras atividades.

II

Modelagem utilizando a UML Dessa forma, para que tudo saia con forme suas estimati vas (ou 0 mais proximo disso) voce com certeza necessitara de todos os modelos e esbo~os desse projeto que demonstrem a complexidade do processo e os riscos possfveis. Alem disso, voce desejara manter to do 0 processo documentado, pois em manuten~oes futuras desse sistema e, caso os desenvolvedores iniciais nao estejam mais presente, vocecertamente nao passaraapuros, esperando que cada linha de codigo seja decifrada para que se entenda como 0 processo funciona. Voce tambem desejara que, no proximo sistema que sera desenvolvido, se possa reutilizar os process os ja criados anteriormente, sem que seja necessario "reinventar aroda". Uma das variaveis que farao com que esse processo seja bem-sucedido e a utiliza~ao da modelagem. Nao quero atribuirtoda aresponsabilidade do sucesso de urn sistema, somente pelo fato do uso da modelagem. E evidente que a escolha de bons profissionais com 0 esfor~o em equipe (e principalmente, 0 apoio de todos os envolvidos nesse processo) se torna indispensavel para que se atinja 0 objetivo proposto. Modelagem orientada a objetos A visao do desenvolvimento de sistemas nos ultimos anos, vem adotando uma perspecti va orientada a objetos. Sob essa perspectiva, 0 principal bloco de constru~ao do sistema e 0 objeto. Nao ha duvidas de que os metodos orientados a objetos tern consolidado seu uso na constru~ao de sistemas de diferentes domfnios de problemas, sendo simples ou complexos.

Urn diagrama de casos de usa representa urn conjunto de cenarios identificados, que seja util aos usuarios de urn sistema. Urn caso de uso descreve cada cenario possfvel para urn sistema, composto por seqiiencias de passos em que ha intera~ao entre os usuarios e 0 sistema. Caracterfsticas de urn diagrama de casos de uso:

Capta 0 comportamento desejado para urn sistema, por meio da analise dos requisitos necessarios para a constru~ao do sistema. Imagine a constru~ao de uma nova casa, urn novo predio ou ate mesmo urn aviao, sem que seja construfdo primeiro os seus respectivos modelos. Seria urn erro cuja propor~ao nao poderfamos estimar. Milhoes de vidas seriam arriscadas (e certamente perdidas) se nao houvesse model os em que pudessemos visualizar 0 que futuramente vira a ser realidade, possibilitando a corre~ao de erros antes que fossem concebidos os produtos finais. Enfim, construfmos model os para compreendermos melhor 0 sistema que estamos desenvolvendo. Com a modelagem, podemos alcan~ar: A especifica~ao da estn,1tura e do comportamento sistema. do Permite enxergar melhor a abrangencia dos requisitos de urn sistema, pois utiliza-se de recursos grMicos para estruturar esses requisitos. Perrnite documentartodos os requisitos de urn sistema.

Sua estrutura e extremamente simples, pois os cenarios sao formados por textos, descritos em uma linguagem informal, possibilitando 0 entendimento nao somente da equipe tecnica, mas por todos que participam do processo de desenvolvimento de urn sistema. Permite organizar os requisitos, eliminando as redundancias de informa~oes por meio dos relacionamentos entre os casos de usa (mais detalhes na pag. 32). Permite identificar os riscos possfveis para a fase de constru~ao do sistema. Pode ser usado em todas as fases no desenvolvimento de urn sistema, orientando na defini~ao da arquitetura ate os testes funcionais do sistema.

A visualiza~ao do sistema como ele e ou como desejamos que ele seja. Documentar todas as decisoes tomadas.

II

Sao papeis desempenhados por qualquer usmmo de urn caso de uso, ou seja, 0 ator e quem solicita os servic;:os disponfveis em casos de uso. Urn ator pode ser : Uma pessoa que interage com
0

Na maioria das vezes, na fase de alllilise do processo de desenvolvimento de urn sistema, os participantes nao tern todas as informac;:oes prontas na "ponta da Ifngua", principalmente se estivermos falando de sistemas complexos, em que estejam envolvidas diversas areas da empresa para definirem os processos. Desse modo, os processos devem ser discutidos por meio de reunioes entre os participantes e as areas envolvidas, para consolidar os process os em levantamento.

sistema.
0

Urn hardware que interage com

sistema.

Urn outro sistema que tenha a necessidade de utilizar o caso de uso.

~------:2.,
Analista de Credito Objetivo: manter os clientes da empresa, onde tambem seriio submetidos a analise de credito. Os clientes devem jornecer injormafoes, como rejerencias pessoais e comerciais, dados projissionais e pessoais. Ator: Analista de credito.
Exernplo de descri~ao de urn caso de uso

Urn caso de uso pode ser especificado de di versas formas, pois nao ha urn padrao estabelecido para essa atividade. Foi dividida em duas formas neste guia a maneira de especificar casos de uso: Caso de uso de alto nfveI. Caso de uso detalhado.

Dica: Os casos de uso de alto nfvel podem ser

utilizados com freqiiencia. Use essa tecnica para fazer 0 levantamento preliminar das necessidades, sem se aprofundar no detalhamento. Essa tecnica deve serempregada para se ter uma visao geral de todos os requisitos do sistema. Dessa forma, serao obtidas as informac;:oes relevantes para poder mensurar, porexemplo, os custos envol vidos e os recursos necessarios na fase de analise de urn sistema.

A especificac;:ao de urn caso de uso de alto nfvel e uma forma de expressar 0 cOJIlportamento pretendido para urn sistema, sem se aprofundar em seu detalhamento. Sob uma perspectiva macro, em uma fase em que nao se tern todas as informac;:oes consolidadas, os casos de uso de alto nfvel se torn am uma boa opc;:ao para iniciar 0 processo de levantamento das necessidades de urn sistema.

Modelagem utilizando a UML Caso de uso detalhado Um caso de uso detalhado (como 0 pr6prio nome sugere) mostra mais detalhes do que um caso de uso de alto nfvel. Ap6s 0 levantamento inicial dos casos de uso de alto nfvel, teremos uma visao melhor para decidirmos qual sera 0 caso de uso, que deve ter prioridade em rela9ao a um outro, no que diz respeito ao seu detalhamento.

Modelagem utilizando a UML Se 0 cliente possuir contas bancarias, esses dados deveriio ser fomecidos. 0 cliente obrigatoriamente deve apresentar no minimo duas referencias pessoais ou comerciais, parafuturas consultas de credito. Para toda a manipulafiio dos clientes na base de dados, deve ser validado 0 CPF do cliente e se a cidade escolhida e verdadeira. Deve ser possivel incluir um novo cliente, sempre que existir uma nova proposta de jinanciamento. Deve ser possivel alterar os dados do cliente, com objetivo de atualizafiio cadastral.
0

o objetivo desse detalhamento e descrever a seqUencia de passos que deve ocorrer para 0 respectivo caso de usa, sem a omissao de qualquer informa9ao.

Analista de Credito

. .

--------~

-------"'---.-//
~~
mantemClientes do caso de uso

Deve ser possivel excluir 0 cliente cadastrado, caso haja desistencia da proposta de credito. Deve ser possivel consultar os dados do clientes, onde o Analista de Credito devera informar 0 CPF ou 0 c6digo do cliente, podendo consultar todos os dados deste.

~,

Erros comuns na especifica~aode casos de uso

Especifica~ao detalhada
mantemClientes

Objetivo: manter os clientes da empresa, onde tambem seriio submetidos a analise de credito. Os clientes devemfomecer informafoes, como referencias pessoais e comerciais, dados projissionais e pessoais. Ator: Analista de credito Descrifiio: esse caso de uso comefa no cadastramento de uma proposta de jinanciamento pelo Analista de Credito, que sera submetida a uma analise de credito. Passos: Como as primeiras informafoes a serem fomecidas siio as informafoes sobre 0 cliente, 0 Analista de Credito deve entrar com os dados pessoais deste, como nome do clie;ue, enderefo de residencia, bairro, cidade. CEP, estado, telefone de contato, nome da empresa, enderefo comercial, cargo que ocupa, saIario e data de nascimento. 0 Analista de Credito deve entrar com os documentos de apresentafiio obrigatoria, como 0 CPF eo RG.

C~mo ja foi dito, um caso de uso descreve cenarios pretendidos para urn sistema. Um erro bem comum no infcio desta atividade, e confundir um passo de certo cenario com 0 pr6prio cenario.

C)
Descrifiio: esse caso de uso se inicia quando 0 analista de credito necessita cadastrar as referencias pessoais do cliente, que seriio validadas ao longo do processo da analise de credito ...

o exemplo apresentado refere-se a uma atividade do caso de uso mantemClientes, e nao a um cenario, ou seja, a atividade de manter as referencias do cIiente faz parte do processo de manter os clientes (caso de uso mantemClientes).

Modelagem utilizando a UML Relacionamentos entre casos de uso No relacionamento de inclusiio (include), 0 cemmo comum a mais de urn caso de uso senicaptado em urn outro caso de uso, ou seja, esse servi<;o estara concentrado em urn caso de usa base, para que outros casos de uso utilizemse desse servi<;o. Dessa forma, evita-se descrever uma mesma seqUencia de passos a varios casas de uso, concentrando essa seqUencia em urn caso de uso publico. No proximo exemplo, ambos os casos de uso mantemCreditScore e 0 mantemAprovacaoUsuario, tinham em comum os passos relacionados ao controle das informa<;6es pelo Log, que consiste em documentar as a<;6esrealizadas pelos usuarios durante a intera<;ao cam 0 sistema. Utilizamos 0 estereotipo include para expressar esse tipo de relacionamento (para saber mais sabre estereotipas, ver pag. 73).

Voce pode organizar os casos de uso por meio de relacionamentos. A UML disponibiliza tres tipos para casos de uso. Sao eles:

A generaliza~iio e urn relacionamento de generaliza<;aa/ especializa<;ao em que toda a estrutura do caso de usa generalizado e herdada pelos casos de uso especializados.

o
analisaCredito Pessoa Fisica analisaCredito Pessoa Juridica

mantemCredilSs.

d 6
'","00 ~.'""~
mantem8ase Log

;( l''''''\

man~~~~~~acao

(supertipo) con tern cemirios comuns entre os casos de uso analisaCredito PessoaFisica e analisaCredito PessoaJuridica (subtipos). Os subtipos, por sua vez, contem cemirios especializado, particular a cada urn deles. mais

o caso de uso analisaCredito

Portanto, os cemirios comuns a mais de urn caso de usa e captado em urn caso de uso generalizado, que e herdado por outros casos de uso mais especializados. Dessa forma, alem de reduzir a duplicidade dos requisitos entre os casos de uso, as informa<;6es sao organizadas, 0 que tende a deixar 0 processo mais claro.

Modelagem

utilizando

a UML

Modelagem

utilizando

a UML

Extensao relacionamento de extenSGO (extend) e usado para descrever cemirios opcionais de urn caso de uso. Os casos de uso descrevem cemirios que sempre acontecerao no sistema,jaos casos de uso estendidos, descrevem cenarios que somente ocorrerao em uma situa~ao especffica. Utilizamos 0 estere6tipo extend esse tipo de relacionamento. para expressar

Descrevendo uma situac;ao no mundo real Vamos imaginar (agora como clientes) a realiza~ao da compra de urn veiculo. Ap6s varios anos, voce finalmente realizara 0 tao esperado sonho - a compra daquele maravilhoso autom6vel, cujo dinheiro voce guardou na antiga cademeta de poupan~a durante anos. Pois bern, voce se dirige a uma concessionaria de sua preferencia, e logo e avistado por urn vendedor. Voce entao come~a a descrever 0 modelo do autom6vel que deseja: Cor vermelha, quatro portas, bancos de couro, ar condicionado, dire~ao hidraulica, freios ABS, regulagem da altura dos bancos, air-bag, etc. Baseado em seus requisitos, 0 vendedor consulta 0 estoque dos acess6rios que voce solicitou. Se houver todos os acess6rios disponiveis em estoque (vamos imaginar que ha), 0 vendedor the informara 0 pre~o final do veiculo e, provavelmente, 0 dia da entrega. Tudo muito born, nao ? No dia da entrega do veiculo, voce se dirije a concessionaria, e aguarda a saida do ve1culo. Ap6s sairem da concessionaria, naquele calor de mais de 30, voce resolve ligar 0 ar-condicionado. Mas, ao apertar 0 botao, nada acontece. Voce entao chega a conclusao de que realmente 0 autom6vel comprado nao funciona como deveria. Agora vamos traduzir tudo isso para 0 mundo dos softwares. Mundo real
Requisitos do veiculo: cor vermelha, ar-eondicionado,air-bag, qualro portas.

Observa~ao: com esses relacionamentos, podemos melhorar a forma como as informa~6es sao organizadas por meio dos casos de usa, com 0 objetivo de entendermos melhor a necessidade dos usuarios de urn sistema. Arquitetura de sistemas orientada a casos de uso Do ponto de vista de urn processo de desenvol vimento de software, considero os casos de uso como 0 principal artefato de uma arquitetura de sistemas bem planejada. Utilize-se sempre desse recurso para planejar a arquitetura de urn sistema.

Produto entregue: cor vermelha, sem ar-eondicionado,air-bag, qualro portas.

Arquitetura niio orientada a caso de uso

Foi demonstrado com 0 exemplo apresentado, urn problema muito comum no processo de desenvolvimento de software. Quando a arquitetura de urn sistema e definida, algumas informa~6es sao perdidas ao longo do processo de desenvolvimento quando essa mesma arquitetura nao e construida pelas necessidades reais do sistema. Parece muito 6bvio que urn sistema deva ser construido de acordo com 0 solicitado. Mas, muitas vezes, 0 que nos parece urn simples detalhe pode ter, e com certeza tera para 0 usuario final, grande importancia.

II

Modelagem utilizando a UML Os casos de uso devem ser detalhados ate os ultimos pass os a serem realizados. Nao economize nas descri~6es de como e realizado urn caso de uso. Por exempIo, na fase de constru~ao, os casos de uso ajudarao na defini~ao da arquitetura de dados, bem como a arquitetura dos objetos, que serao os responsaveis por sua reaIiza~ao. Na fase de testes do sistema, os casos de uso serao utilizados para validar se 0 que foi construfdo esta de acordo com 0 que foi especificado.

Modelagem utilizando a UML

J---<)
solicita Pro posta de Financiamento

Os diagramas de casos de uso tern porobjetivo especificar, visualizar e documentar 0 comportamento que cada parte do sistema deve ter. Os diagramas de casos de uso apresentam em sua estrutura, principaImente os tres itens a seguir: Casos de uso. Atores. Relacionamentos. Com os diagramas de casos de uso e possfvel visualizar quais serao os servi~os oferecidos pelo sistema. ConseqUentemente, esses servi~os representam algum tipo de valor para cada ator que interage com esses casos de uso. Alem de especificar, visualizar e documentar as funcionalidades do sistema, os diagramas de casos de uso podem ser utilizados para: VisuaIizar as funcionalidades perspectiva extema a este. do sistema, sob uma

l sf 6
/analise CreditScore analisa Valor
Financiamento

Credito"

~ro Chente

Como fazer Identifique os possfveis atores que comporao 0 diagrama e fa~a uma listagem, atribuindo os papeis que cada urn deve desempenhar. Identifique os cenarios do sistema, considerando qual comportamento 0 sistema deve ter, e 0 represente por meio dos casos de uso. Paracada caso de uso, identifique e descreva a seqUencia de passos. Preencha 0 diagrama de casos de uso com esses atores, mostrando 0 relacionamento existente com esses casos. Organize os diagramas de casos de uso em pacotes, agrupando tais diagramas pelo tipo de cenario que cada urn esta empregando.

Servir como base de informa~6es para a gera~ao das classes (analisando 0 contexto de cada caso de uso), coIabora~6es (trocas de mensagens entre os objetos) e os pr6prios objetos.

o diagrama de classes representa 0 modelo da estrutura de urn sistema orientado a objetos. Esse tipo de diagrama eo centro dos principais conceitos da modelagem orientada a objetos.
Caracteristicas de urn diagrama de classes: Permite visualizar
0

As colaborafoes representam a forma como as classes interagirao para executar urn comportamento cooperati yo.

Clienle codigoClienle nomeClienle Endereco Bairro Cidade CEP Telefone1 Telefone2

modelo da estrutura de urn sistema.

E urn

dos diagramas mais utilizados na modelagem orientada a objetos.

Demonstra as classes, os relacionamentos (agregac;ao, composic;ao, generalizac;ao, etc.) e as colaborac;6es. As classesrepresentam os blocos de construc;ao utilizados nesse diagrama. Imaginando no mundo real e utilizandose do exemplo de urn vefculo, os blocos de construc;ao seriam as portas do vefculo, as dobradic;as, as mac;anetas, enfim, todos os objetos que interagirao de alguma forma para executarem urn comportamento desejado (no caso de vefculo, por exemplo, mover-se).

if

I
PessoaFlsica dalaNascimenlo sexo RG CPF salatio esladoCivii

I PessoaJuridica CNPJ inscricaoEsladual ramoAlivldade falu ram enloAn uaI numFuncionarios

Os relacionamentos, por sua vez', inform am em urn modelo de diagrama de classes como essas classes estarao de alguma forma ligadas (associadas) para atender as responsabilidades que lhes foram atribufdas. Sera tambem tare fa dos relacionamentos demonstrar os papeis de cada classe. Os relacionamentos demons tram, por exemplo, a imporrnnciade cada classe relacionadaa urn modelo quando for utilizado 0 relacionamento do tipo agregafQO, em que serao demonstradas a classe superior e suas agregadas. Por exemplo, as portas do vefculo estarao ligadas por meio das dobradic;as, com a responsabilidade de cumprir urn comportamento quando acionadas. Mas, qual a importancia das portas e das dobradic;as nesse prbcesso? As portas estao disponfveis para realizar a func;ao de dar aces so ao interior do vefculo. As dobradic;as auxiliarao as portas nesse processo, girando-se e fazendo com que a porta fac;a movimentos, permitindo assim a execuc;ao do comportamento "abrir". Assim, a porta, alem desse comportamento, deve realizar outros, como destravar-se e abrir os vidros. As dobradic;as somente estao ali para realizar 0 comportamento de girar-se. Logo, as dobradic;as sao agregadas da porta, pois sem as portas, as dobradic;as nao teriam sentido para estar ali.

ClienleReferencia Nome Telefone lipoReferencia

PIOpO!i1a

codigoProposla &odigoloja

Proouto
Valorfmantlamenlo VillorEntrada

."""

Data

polltiUCredilo' codlllOPolitlcaCredito idadlJMinima valorMinimoFinanciamenlo 1 wlof~'aldmoFlnanciarriento valorRendaJri(inima . cred:!iicorelrll:inimo

II

Modelagem utilizando a UML Mapeamento para Iinguagens de programa~ao Existem ferramentas que of ere cern suporte para 0 mapeamento das classes criadas por meio da UML, para as linguagens de programac;;aoorientadas a objetos. Apesar desse recurso, a UML e independente de qualquer linguagem de programac;;ao. Dessa forma, podemos representar os modelos na UML sem que obrigatoriamente tenhamos de atender a padr6es de uma linguagem de programac;;ao especffica. Classe Cliente
/ /Source file: c:/Cliente.java public class Cliente

Nessa forma voce podeni identificar, por exemplo, se foi atribufda a uma classe muitas responsabilidades que foi atribufda a uma outra. Isso pode ser urn problema futuramente para 0 sistema, visto que as classes precisam ser estruturadas dentro de uma harmonia, em que as responsabilidades de cada classe devem ser equilibradas.

Por meio dos diagramas de classes, voce podeni fazer a transic;;aodas classes que serao persistidas em banco de dados, para modelos 16gicos de banco de dados. No capftulo anterior, discutimos os diagramas de casos de uso. Essa in vestigac;;ao realizada para cap tar 0 comportamento de urn sistema e a base de toda a formac;;ao dos outros diagram as na UML.

private int codigoCliente; private String nomeCliente; private String Endereco; private String Bairro; private String Cidade; private String CEP; private String Telefone1; private String Telefone2; public Cliente{)

A descoberta dessas abstrac;;6es do sistema representa atribuir a realizac;;ao de cada caso de uso a elas. Portanto, usaremos no decorrer desse capftulo novos exemplos de casos de uso e os usados no capftulo anterior, paramostrar que com a amilise dos casos de uso e possfvel descobrir quais as classes responsaveis por sua implementac;;ao (dos casos de uso).

Voce deve utilizar os diagramas de classes para visualizar a arquitetura de urn sistema dentro das seguintes formas: Visualizar as classes de urn sistema, relacionamentos e colabora~oes seus

Atributo e uma propriedade de classe. Representa as caracterfsticas pr6prias de uma abstrac;;ao. Urn atributo representa algum tipo de propriedade da classe que esta sendo modelada.

Nessa forma e possfvel visualizar quais san as classes que formarao 0 sistema, bem como os relacionamentos existentes entre elas e suas colaborac;;6es. Nesse tipo de visualizac;;ao, 0 mais importante e a possibilidade de identificar qual e 0 tamanho da estrutura de classes que 0 sistema deve ter, e principal mente os tipos de relacionamento existentes entre as classes.

codigoCliente nblYieCliente idade

sexo, .

II

III

Modelagem utilizando a UML Voce ainda pode representar os atributos, com seu tipo e valor inicial padrao, como mostra a figura a seguir: A visibilidade e urn item importante para a especifica~ao de atributos e opera~5es de uma classe. A visibilidade especifica se urn atributo ou opera~ao pode ser utilizada par outras classes. A UML oferece tres tipos de visibilidade para essa especifica~ao. Sao elas:

Cliente codigoCliente : char nomeCliehte : char idade : int sexo:int

=1

rapa

Sfmbolo

Descri~ao

o elemento

pode ser utilizado pelo objeto no qual ele perlence e por qualquer objeto cliente.

o elemento pode ser utilizado somente pelo proprio objeto ao qual ele perlence, ou se existirem, pelas suas subclasses.
As opera~6es SaDprocess os ou servi~os realizados par uma classe, e disponibilizadas para usa de outras classes em urn sistema. Uma opera~ao e disparada a partir de urn evento gerada para 0 sistema. As opera~6es, com os atributos de uma classe, executam as responsabilidades atribufdas a uma classe.

o elemento pode ser utilizado somente pelo objeto ao qual ele perlence.

Cliente

consultarQ inserirO . atualizarQ 8xcluirO .

# codigoCliente # nomeCliente # Endereco # Bairro # Cidade # CEP + Telefone1 + Telefone2

consultar(codigoCliente inserirO atualizarO excluirO : int)

Voce ainda pode representar as opera~6es, definindo a visibilidade, parametros a serem enviados, etc.

c6nsultar(codigoCliente :..int) iriserirO ... . . .. atllalizarO

As responsabilidades SaDas obriga~6es que uma classe deve cumprir, por meio de seus atributos (caracterfsticas) e suas opera~6es (comportamentos).

exduirQ

II

II

Modelagem utilizando a UML

o exemplo demonstrado nesse guia, e a capta~ao dessas responsabilidades por meio da amilise de casos de uso.
Observa~ao: tive algumas experiencias na defini~ao de classes em que nao foi utilizada a analise de cas os de uso. Nao deram muito certo. Prefiro 0 uso da tecnica de analise de casos de uso, apesar da existencia de outras, como, por exemplo, 0 uso da tecnica dos cartoes CRC (Class - Responsability Collaboration). Uma classe pode ter qualquer numero de atributos e opera~oes. Na pratica, uma classe bem estruturada deve contersomente os atributos e opera~6es que dizem respeito aelamesma. Nao e possivel precisar urn numero certo de atributos e opera~6es que uma classe deve ter. Tente equilibrar a estrutura de suas classes de tal forma que seja possivel atingir seu proposito: atender as responsabilidades que lhe foram atribuidas. Uma pos-condir;fio e 0 resultado que uma opera~ao deve produzir apos 0 termino de sua execu~ao. Ao definir uma pos-condi~ao, voce implicitamente ja esta definindo qual eo resultado obtido apos 0 termino da execu~ao de uma opera~ao. A especifica~ao de pre-condi~ao e pos-condi~ao para as opera~6es do sistema san as informa~6es necessarias que os chamadores dessas opera~6es precisam saber sobre elas, ou seja, 0 chamador tern conhecimento do que a opera~ao necessita para ser executada (pre-condi~ao) e do resultado obtido apos sua execu~ao (pos-condi~ao). Da defini~ao de pre-condi~6es e de pos-condi~6es, podemos ter tambem as exce~6es. As exce96es ocorrem quando as pre-condi~6es foram atendidas, mas isso nao sera verdadeiro para as pos-condi~6es.

. AnaliseCredito.. ObterCreditScoreO

Nome da opera~ao: ObterCreditScore Responsabilidade: obtem a pontuayao atingida para urn c1iente, de acordo com os dados desse c1iente e da politica de credito definida Pre-condi~ao: deve ser informado qual e 0 cliente P6$-condi~ao: a pontuayao foi obtida, informando essa pontuayao ao chamador da operayao. Exce~ao: senao forem encontrados os dados necessarios para a obteyao da pontuayao, retornar urn erro

Uma pre-condir;fio e algo que necessita ocorrer antes da execu~ao de uma opera~ao. Isso significa que 0 sucesso da execu~ao de uma opera~ao esta condicionado ao atendimento a umaou mais pre-condi~6es. A defini~ao de uma pre-condi~ao deixa explicito que a responsabilidade de seu atendimento fica para 0 chamador da opera~ao. Isso ajuda muito quando estamos falando de opera~6es complexas, pois essa divisao de responsabilidades chamador I executor - reduz a complexidade no momenta em que estarnos escrevendo 0 quedeve fazer essas opera~oes.

II

Modelagem

utilizando

a UML

Operac;oes versus metod os

Apesarde muitas pessoas utilizarem opera~6es e metodo como sinonimos para algumas linguagens de programa~ao, na VML existe uma distin~ao entre os dois termos. Vma opera~ao e urn procedimento de chamada em urn objeto, enquanto urn metoda e 0 que implementa esse procedimento de chamada. Podemos ver essa distin~ao entre os dois termos, quando falamos em polimorfismo. Por exemplo, quando temos urn supertipo com dois subtipos, em que cada subtipo subrescreve a opera~ao "Salvar" do supertipo, temos uma opera~ao e dois metodos diferentes que a implementam (uma para cada subtipo).

0 Analista de Credito deve entrar com os documentos

de apresentar;ao obrigat6ria, como
0

CPF eo RG.

Se 0 cliente possuir contas bancarias, esses dados deverao ser fornecidos. 0 cliente obrigatoriamente deve apresentar no minimo duas referencias pessoais ou comerciais, parafuturas consultas de credito. Para toda manipular;ao dos clientes na base de dados, deve ser validado 0 CPF do cliente e se a cidade escolhida e verdadeira. Deve ser possivel incluir um novo cliente, sempre que existir uma nova proposta de financiamento. Deve ser possivel alterar os dados do cliente, com objetivo de atualizar;ao cadastral.
0

Vamos utilizar neste exemplo 0 mesmo caso de uso apresentado no t6pico Diagrama de casos de uso.

_________ 0
~.
Analista de

Deve ser possivel excluir 0 cliente cadastrado, caso haja desistencia da proposta de credito.

m"lemCII"""

Deve ser possivel consultar os dados do clientes, onde o Analista de Credito devera informar 0 CPF ou 0 c6digo do cliente, podendo consultar todos os dados deste.

Vamos analisar: Credito Objetos do caso de uso

Clientes Nome do cliente Endereyo de residencia Bairro Cidade Validar a cidade CEP Estado Telefone de contato Nome da empresa Endereyo comercial Cargo Salario Data de nascimento CPF RG Validaro CPF Conta bancaria referencias alterar os dados do cliente excluir 0 cliente Incluir urn novo c1iente consultar os dados dos clientes CPF

Caracteristica
Candidata a c1asse Atributo do c1iente Atributo do c1iente Atributo do cliente Candidata a classe Comportamento desejado Atributo do cliente Atributo do cliente Atributo do cliente Atributo do cliente Atributo do cliente Atributo do cliente Atributo do cliente Atributo do c1iente Atributo do cliente Atributo do cliente Comportamento desejado Candidata a classe Candidata a classe Comportamento desejado Comportamento desejado Comportamento desejado Comportamento desejado Atributo do cliente e candidato a chave de pesquisa Atributo do cliente e candidato a chave de pesquisa

Objetivo: manter os clientes da empresa, onde tambem serao submetidos a analise de credito. Os clientes devemfornecer informar;i'Jescomo referencias pessoais e comerciais, dados profissionais e dados pessoais. Ator : Analista de credito Descrir;ao: esse caso de uso comer;a no cadastramento de uma proposta de financiamento pelo Analista de Credito, que sera submetida a uma analise de credito. Passos: Como as primeiras informar;i'Jes a serem fornecidas SaD as informar;i'Jes sobre 0 cliente, 0 Analista de Credito deve entrar com os dados pessoais do cliente, como 0 nome completo, enderer;o de residencia, bairro, cidade, CEP, Estado, telefone de contato, nome da empresa, enderer;o comercial, cargo que ocupa, saldrio e data de nascimento.

II

Modelagem utilizando a UML Estabelecendo as classes do domlnio Vamos primeiramente listar as classes identificadas nesta analise de caso de uso.

Modelagem utilizando a UML Algumas classes como ClienteContaBancaria e ClienteReferencia, por exemplo, nao tern especificados no caso de uso quais saD os seus atributos. Dessa forma, os atributos citados nessas classes sao apenas sugest6es. Em urn caso de uso real, esses atributos deveriam estar especificados em caso de uso (nao se esque~a). Observa~ao: apresentado, uso. Vamos identificados de lnterat;ao. Como fazer Identifique as classes que farao parte da estrutura do sistema, par meio da analise de casos de uso. Identifique as caracterfsticas para cada classe. Fa~a com que as classes nao sejam sobrecarregadas com muitas responsabilidades. Distribua as responsabilidades harmonicamente, visando manter urn equillbrio em toda a estrutura do sistema. Junte todas as classes descobertas para 0 sistema e as coloque em diagramas de classes. Estabele~a os relacionamentos que devem existir entre as classes, explicitando a importancia e a fun~ao de cada classe no modelo. Detalhe a estrutura de cada classe e dos diagramas de classes, definindo 0 tipo de cada atributo e a multiplicidade nos relacionamentos entre as classes. criamos 0 diagrama de classes baseado na analise de casos de modelar os comportamentos nessa fase, no t6pico Diagramas

ClienteReferenCia

ClienteContaBancaria

Vamos agora identificar para cada classe descoberta, os seus atributos e os respectivos relacionamentos e multiplicidades.

Clientes' codigoCliente nomCliente .:.>

ClienleReferencia

cpr ....

> RC) dataNasCimenlci lipaSexo ...

.'./
1

1.-

Nome
Telefone IpoReferencia ,_."

norneE~presa ::: t~mpoServico ):

salario.:;:: ".<.::< ~ t!pEndCq~ranc~: 1

ca~go::::.....< :::':<

:ClienteContaBancaria cpdigoBanco . codigoAgen~ia codigoConta' 0.," valLimite .. npo~special

L' ClienteEndereco EridereCO' Complemento Bairi'o':':' CEp., E$i.d~'

1..

.., Cidilde codigoCidade ,.,

NomeC.idada::

tei~fone:"..:......
lipoEiiderecil

..

'

diagrama de objetos representa a modelagem de instancias das classes de urn sistema em determinado ponto e momenta de execu<;ao.

o diagrama de objetos pode ser considerado uma varia<;ao do diagrama de classes, pois se utiliza de quase todas as suas nota<;6es. 0 objetivo do diagrama de objetos e mostrar as instancias das classes de urn sistema em determinado momenta de execu<;ao desse sistema.
Nesse caso, os objetos saG diferenciados de suas classes por terem seus nomes sublinhados. Cada objeto tern 0 nome na seguinte forma: nome da instancia : nome da classe. Apesar de nao ser tao importante quanta urn diagrama de c1asse, 0 diagrama de objetos po de ajuda-Io na compreensao de diagramas complexos que nao estejarn muito c1aros.

Os diagramas de intera<;ao - formados pelos diagram as de seqUencia e diagramas de colabora<;ao - representam a dinarnica de urn sistema. Os diagramas de intera<;ao mostram como os objetos colaboram entre si para a realiza<;ao de urn cornportarnento. Os objetos colaboram entre si a partirdaintera<;ao existente entre os atores e 0 sistema. A partir dos eventos gerados pelos atores, havera de ter opera<;6es em resposta a esses eventos, ou seja, 0 evento e urn estfmulo gerado pelo ator no sistema, e as opera<;6es SaGas respostas a esse estfmulo. Porexemplo, quando 0 ator solicitar ao sistema a inser<;ao de urn novo c1iente, entre outras coisas, 0 sistema deve validar se 0 CPF informado pelo c1iente e verdadeiro. Por tras do evento "inserir novo c1iente", 0 sistema devera executar uma opera<;ao para satisfazer 0 even to gerado, podendo ser uma opera<;ao chamada ValidarCPF (). Utilize-se dos diagram as de intera<;ao para mostrar como os objetos colaboram entre si para a realiza<;ao dos cornportamentos identificados na analise de casos de uso. Caracterfsticas dos diagramas de intera<;ao: Representam a dinamica entre os objetos, para realizarem comportarnentos descobertos a partir dos casos de uso. Representam as colabora<;6es entre objetos para cada comportamento de urn sistema. Oferece simplicidade de visualiza<;ao, pois as colabora<;6es entre os objetos acontecem por meio da troca de mensagens, que podem ser vistas se forem observados os diagramas. Disponibiliza dois tipos de diagramas representarem as intera<;6es de urn sistema. para

~
codlgoProposta= 1023101 codlgoloja = 10 PfodUfO=lD479S89 VaJorFinanciamenlo = 1.500,00 ValOfEnttada = 500,00 Prazo>::5 ValOf'Parcela = 290,00

Oat; = 0510212001

I
codlgOAnallse=lDO

POICredlto:PoliticaCredito codlgoPolitlcaCfedito= 1

Data=05lO2J2001 Hora 02:25 PM

idadeMinima,.lS
lorMlnlmoFlmlOclamenlo = 200,00 alorMaximoFinanciamenlo = 2.000,00 ralorRendaMinlma = 500,00 creditScoreMinimo = 25

Responsavel
Resultado

= Aprovado
I

= Malia

Score:AnaliseCreditscore

Renda:AtlaliseRenda

credltScoleCllenle
creditScoreMinimo Data"05f02J2001 status = Aprovado

= 35 = 25

valOiRendalnformada valolRendaMinima,. Oala=05J021200t Slalus= A+lrovado

= 1.000,00 500,00

Os diagramas de objetos saG utilizados tipicamente na modelagem de estruturas de objetos, para mostrar os objetos de urn sistema funcionando em determinado ponto no tempo.

Os diagram as de seqiiencia dao enfase a ordena<;ao seqUencial em que os comportamentos acontecem, enquanto os diagramas de colaborat;ao dao enfase a ordena<;ao estrutural dos objetos que colaboram entre si.

Modelagem utilizando a UML Diagrama de sequencia colaboral;ao versus diagrama de

de seqUencia e 0 diagram a de colabora<;ao mostram os mesmos aspectos de urn modelo, apenas diferenciando como essas informa<;6es saG projetadas. Isso querdizerque os doisdiagramas saGsemanticamente equivalentes, podendo usar urn ou 0 outro para visualizar modelos sob uma perspectiva dinamica.

o diagrama

Uma condi~iio indica quando uma mensagem e enviada a urn objeto, desde que essa condi<;ao seja verdadeira.

/ObJetO$~

QlliJti

I ~

Urn marcador de intera~ao demonstra quantas vezes uma mensagem e enviada a urn objeto. Isso se torna util quando queremos demonstrar urn processamento em que hli mais de uma informa<;ao a ser processada. Pode ser demon strada com urn asterisco (*).

Uma mensagem de retorno indica 0 retorno de uma mensagem, e nao uma nova mensagem. Se necessario, voce pode representar urn retorno para cad a mensagem enviada aos objetos. Utilize esses retornos quando 0 resultado de uma mensagem nao ficar claro para quem estiver lendo 0 diagrama de seqUencia. Em diagramas de seqUencia em que hli muitos objetos colaborando, as mensagens de retorno pod em confundir 0 leitor por deixar 0 diagrama muito polufdo graficamente. Para urn cadastramento simples de c1ientes, poderfamos ter 0 seguinte diagrama de seqUencia: As linhas verticais nos diagramas de seqUencia saGchamadas de linha de vida, e representam a vida do objeto durante uma intera<;ao(por isso, ha uma Iinha para cada objeto).
: W;UCPFO

ofoco de controle tern urn importante papel nos diagramas de seqUencia, indicando 0 perfodo de dura<;ao pelo qual os objetos esmo cooperando para realizar urn comportamento.
Mensagem Uma me(sagem e representada por uma fIecha entre dois objetos. A mensagem e representada na posi<;aohorizontal entre as Iinhas de vida dos objetos, e sua ordem e demon strada de cima para baixo no diagrama.

S,tv"Q

If---~
"l1,mEIl'hIiOOI:

II

Modelagem utilizando a UML Diagrama de colaborac;ao Apesar dos diagramas de intera<;ao serem semanticamente equivalentes, ha diferen<;as na forma de como as informa<;6es saG organizadas em cada urn. No diagrama de colabora<;ao, os objetos seguem uma ordem estrutural, onde sao representados par fcones.

o nome

de urn objeto e representado como - nome do objeto: nome da classe.

2: ValidarCPFO

1:SalVar() Ent@da de urn

---:;;:.

n
"'Item referencia)

Voce representara nos diagramas de intera<;ao nao as classes, mas sim as instancias de classes (objetos). Como o objetivo dos diagramas de intera<;ao e demonstrar 0 momenta de intera<;ao dos objetos em resposta a algum evento, faz muito sentido a representa<;ao de instancias de classes.

!3:SCllvatO

Os diagramas de intera<;ao alem de serem apropriados para a modelagem dinamica de urn sistema, apresentam como principal foco a realiza<;ao dos casos de uso. Com esses diagramas e possfvel e recomendado que se fa<;aa realiza<;ao dos casos de uso, par meio da colabora<;ao entre os objetos do sistema que interagirao entre si para que esses comportamentos sejam satisfeitos. Exemplo da realiza<;ao dos comportamentos uso mantemClientes Comportamentos
Validara cidade Validar 0 CPF Incluirum novoc1iente

As mensagens nesse diagrama sao semelhantes as do diagrama de seqUencia. A autodelegar;ao e representada par urn arco e tern 0 mesmo prop6sito da autochamada nos diagram as de seqUencia.

do caso de

Urn objeto e uma manisfesta<;ao concreta de alguma abstra<;ao (classe). Urn objeto e a "invoca<;ao" de sua abstra<;ao para seu efetivo uso, ou seja, urn objeto e a instancia de uma classe. Instancia e objeto tern 0 mesmo significado, podendo ser usado qualquer urn dos termos. Uma abstra<;ao e algo que existe apenas ideal mente, ou seja, nao e algo materializado. Ja os objetos representam as abstra<;6es materializadas.

identificados: Caracterfstica
Comportamentodesejado Comportamentodesejado Comportamentodesejado

Objetosdo caso de uso

:aalnc:lulrumnowcHente:

Na UML e possfvel representar e diferenciar esses dois artefatos~

:~~Jepro

r---~
i

Recupen.'O

j(id,d.Eneonl.rad~1

: :

, i

Sa. 1()

!
:

"0

~ltmConIa3anean;l1

:
:

SMtO:

II

Modelagem utilizando a UML Auxflio aos desenvolvedores Todos os diagramas disponfveis pel a UML devem ser usados como fonte de infonna~6es para 0 desenvolvimento de urn sistema. Os diagramas de casos de usa, por exemplo, podem ser usados em todas as etapas da constru~ao do sistema, desde a defini~ao da arquitetura ate a etapa de testes. Os diagramas de classes podem servir de auxflio para visualizar 0 esqueleto de urn sistema, e como 0 sistema deve ser construfdo em rela~ao a sua arquitetura. Todos os diagramas disponfveis pel a UML sao pe~as fundamentais no desenvolvimento de urn sistema. Para a modelagem dos diagramas de intera~iio: Defina 0 caso de usa que voce deseja realizar por meio dos diagramas de intera~ao. Defina quais serao os comportarnentos do respectivo caso de usa que voce expressani pelos diagrarnas de interac;:ao. Caso todos os comportamentos do caso de usa que voce esta expressando fiquem rnuito confusos em urn unico diagrama, separe essa rnodelagem em mais de urn diagrarna, nomeando-os com umareferencia ao diagrarna principal. Nos diagramas de seqUencia, para cada evento gerado, mantenha apenas urn foco de controle, com a intenc;:ao de deixar claro para 0 leitor do diagrama quais sao as colabora~6es existentes entre os objetos em res posta ao respectivo evento representado. Crie notas para seus diagramas de interac;:ao a fim de deixa-los mais infonnativos e completos.

Os diagramas de intera~ao demons tram os eventos gerados pelos atores no sistema, e as opera~6es em resposta a esses eventos. Por isso, se observarmos os diagramas de intera~ao mais a fundo, podemos perceber mais informa~6es do que inicialmente parece. Podemos visualizar: Todos os passos para determinado sistema. cemirio de urn

Todos os objetos utilizados em resposta a cad a evento gerado no sistema. A l6gica utilizada para responder a cada evento, por meio das colabora~6es entre os objetos utilizados nesse processo. As opera~6es utilizadas em cada evento e a importancia que cada uma exerce no processo como urn todo. Recomenda-se 0 usa dos diagram as de intera~ao tambem na fase de constru~ao de urn sistema, pois nesses diagrarnas sao demonstrados todos os objetos trabalhando para atender as necessidades do sistema. Indo mais alem, toda a l6gica de como os objetos devem trabalhar para atender aos eventos gerados estao demonstrados nesses diagramas. Portanto, se voce e urn desenvolvedor de sistemas, fa~a usa desses diagramas para facilitar seu trabalho. Se voce nao e urn desenvolvedor de sistemas, indique ou fa~a com que seus desenvolvedores se utilizem desses diagramas.

Modelagem utilizando a UML

de graficos de estados representa os estados possfveis de urn objeto em particular. Isso quer dizer que serao demonstrados os eventos possfveis para somente urn objeto individual e as a~6es tomadas pOl'esse objeto em resposta a esses eventos.

o diagrama

Urn evento e uma ocorrencia de urn estfrnulo gerado para o objeto, capaz de fazer a mudan~a de seu estado atual.

Transic;ao
Uma transir;iio e urn relacionamento entre dois estados, em que 0 objeto em seu estado atual deve realizar atividades para passar para urn outro estado, desde que as atividades tenharn sido cumpridas.

o diagrama de graficos de estados representa as ocorrencias de eventos,bem como as atividades que devem ocorrer ao longo da vida de urn objeto. As atividades executadas pelo objeto resultam em a~6es que podem ou nao mudar 0 estado atual de urn objeto. Portanto, crie diagramas de gnificos de estados para as classes e os casos de usa de urn sistema.
Caracterfsticas dos diagramas de gnificos de estados: Demonstra os estados possfveis para urn objeto em particular. Demonstra pOl' meio das transi~6es, os eventos que geram a mudan~a de estado de urn objeto. Ajuda no entendimento de processos complexos, que casos de uso e classes passarn durante a execu~ao de urn sistema.

Os estados tambern model am a dinamica de urn sistema. Urn estado e urna situa~ao vivida pelo objeto pelo qual esse objeto deve responder algo aos eventos gerados. Portanto, urn estado e a condi~ao de urn objeto em algurn momenta em que 0 objeto esta sendo usado no sistema. Dica: crie diagramas de gnificos de estados para as classes e os casos de uso mais complexos, desde que os estados nao estejam tao claros. Os diagrarnas de intera~ao cumprem geralrnente 0 papel de retratar os estados dos objetos pormeio das mensagens trocadas entre eles em resposta a cada even to. E claro que ha diferen~as entre os diagramas de intera~ao e os diagram as de grafico de estados. 0 primeiro demonstra as colabora~6es entre objetos em resposta a eventos, 0 segundo demonstra os eventos e os estados para urn objeto em particular, apos a ocorrencia das atividades criadas a partir dos eventos gerados para 0 objeto.

Pela figura apresentada podemos observar duas nota~6es que representam 0 estado inicial e 0 estado final de urn objeto. 0 estado inicial representa 0 infcio do estado do objeto. E representado pOl'urn cfrculo preto preenchido. o estado final representa 0 termino dos estados de urn objeto. E representado pOl' urn cfrculo preto preen chi do com urn outro cfrculo em bran co a sua volta. Em seguida, podemos observar os dois estados possfveis para 0 objeto larnpada, 0 estado desligada e 0 estado acesa. Urn estado e representado pOl' urn retangulo com pontas arrendondadas. Entre os estados temos urn relacionamento, responsavel pOl' ilustrar a passagem de urn estado para outro, que chamarnos de transi~ao.

Retornando aos exemplos dados anteriormente, vamos analisar os estados do objeto AnaliseCredito (objeto criado agora para darmos 0 exemplo) no contexto da analise de credito das propostas de financiamento.

II

II

Modelagem utilizando a UML Como podemos ver na figura a seguir, uma amllise de credito inicia com urn estado que chamamos de Analis Pendente. Seguindo a seqUencia dos eventos, apos ess~ estado inicial 0 objeto passa para 0 estado Proposta Analisada (repare que os estados seguem uma seqUenci de eventos que fazem sentido se analisarmos todo contexto do processo). Apos 0 estado PropostaAnalisada. o objeto pode assumir 0 estado Analise Reprovada ou estado Analise Aprovada, de acordo com a condic;:ao explfcita nas mensagens enviadas a esses estados. Com 0 diagrama de atividades e posslvel tambem fazer a modelagem do fluxo de atividades de urn objeto especffico, por meio das transic;:oes de estados que urn objeto sofre durante sua existencia.

1-'01"'
, PedidodllAn:.liu ~-A!iYII:bd9 '\

/~~) d" Cridilo

(RiCUPirildadosdo 'cU&nta

'-

I
ICompativilj,

:=1/0... '
~Inntol

0/
/aprcuaranibe) \ dannd3,
(l'!I"Ida

,!
/llplll'fUJnii$ld.

.L

Como fazer Defina 0 tipo de contexto a ser abordado nos diagramas de gnificos de estados - classes ou cas os de uso. Defina quais serao os eventos importantes do objeto a serem representados. Estabelec;:a 0 estado inicial e
0

:u: ,
I.

estado final do objeto.

Estabelec;:a os estados para 0 objeto e, se posslvel, em ordem sequencial, os eventos e suas respectivas transic;:oes que ligarao urn estado a outro.

de ati vidades representa urn fluxo de controle de atividades, que ocorrem no processo de urn sistema, oferecendo suporte para comportamentos condicionais e paralelos.

o diagrama

Ao contnirio dos outros diagram as existentes na UML, 0 diagrama de atividades nao tern origem nos trabalhos de Booch, Rumbaugh e Jacobson. 0 diagrama de atividades teve sua origem e outras tecnicas, como : diagramas de eventos de Jim Odell, modelagem de estados SDL, modelagem de workflow e redes de Petri. Esses diagramas apresentam principalmente a descric;:ao de comportamentos por meio de processamento paralelo.

Modelagem utilizando a UML Atividade Uma atividade e urn estado de execuc,:aode alguma coisa. Pode ser, pOl'exemplo, a execuc,:aode urn metodo em urn::. c1asse, uma rotina de trabalho, etc.

Modelagem utilizando a UML No diagrama de atividades - Analise de credito - ap6s a recuperac,:aodos dados do c1iente, e acionada uma transic,:ao de entrada em que ha duas safdas concorrentes, ou seja, as safdas sac comportamentos paralelos. Chamamos esse comportamento de separa~ao. Ap6s serem efetuadas as atividades Calcular credit score e Recuperar renda do cliente, ocorre a atividade Comparar Politica de Credito. Esse tipo de comportamento chamamos de jun~ao (une as transic,:oes iniciadas pel a separac,:ao). Ajunc,:aoimpoe umaregra no quedizrespeito as atividades que esta recebe. Todas as atividades recebidas pOl' uma junc,:aodevem ser completadas (finalizadas) para que esta ocorra.

Uma separa~ao e usada para exibir comportamento: paralelos, que apresenta uma transic,:aode entrada podendo tervarias outras transic,:oesnasafda. Quando esses threads de entrada sac acionados, as transic,:oes de safda sao processadas em paralelo. No exemplo do processo d analise de credito, 0 calculo do credi t score e a recuperac,:ao e analise da renda do c1iente ocorrem em paralelo.

Umajun~ao e usada para exibir comportamentos pat'alelo . ou seja, 0 objetivo e unir em uma unica safda os threads iniciados pOl' uma separac,:ao.

Uma excec,:aoa regra dajunc,:ao e 0 thread que sai de uma separac,:ao, e que depende de uma condic,:ao para ser finalizado. Chamamos essa condic,:ao de thread condicional. Esse thread condicional diz no diagrama que, se a condic,:ao for falsa, esse thread pode ser considerado como finalizado. No exemplo a seguir, e demonstrado urn diagrama de atividades na preparac,:ao de urn bolo. Mesmo que eu nao goste de baunilha, os ingredientes serao misturados.

Urn desvio e uma transic,:aode uma unica entrada, em que ha varias transic,:oes de safda. Urn desvio e urn tipo de comportamento Condiciorial.

Uma intercala~ao e urn comportamento condicional em que hi muitas transic,:oesde entrada e uma unica transic,:ao de safda.

ISe

gostar de bau nilhaj

Marca

0 fim

das atividades no diagrama.

Caracterfsticas do diagrama de atividades: Demonstra as atividades que ocorrem para urn processo especffico do sistema. Pode ser utilizado para representar os passos de urn cenario descrito pOl'meio de caso de use, para facilitar seu entendimento.

II

Costuma-se dizer que diagramas de atividades saa variar;6es ou casos especiais de diagramas de gnificos de estados. Isso faz muito sentido, pois a maioria dos estadas sac estados de ati vidades, e as transir;6es sac acionadas se forem finalizadas as transir;6es de origem.

V ma raia de natac;tioorganiza as ati vidades representadas em diagramas. Essa organizar;ao consiste em criar grupos que sac respons3veis pelas atividades que ocorrem nos diagramas de atividades. Urn diagrama de atividades informa as atividades que ocorrem dentro de urn processo, mas nao diz quem sac os respons3veis por essas atividades. Voce deve utilizar as raias de natar;ao caso queira nomear os respons3veis por urn grupo ou par atividade, podendo inclusive informar, se for 0 caso, as classes que serao respons3veis por essas atividades. Vma raia de natar;ao e formada por zonas verticais delimitadas por linhas. A seguir, urn exemplo de raias de natar;ao demonstrando a responsabilidade de cada classe sobre as atividades em execur;ao:

Voce pode demonstrar atividades que se repetem por meio de concorrencia dinamica. Uma concorrencia din arnica indica que uma ati vidade deve ser executada em urn ciclo (loop), ate seu termino. Utilizando esse meio, voce nao precisa demonstrar a atividade dentro de urn cicIo de execur;ao. A concorrencia dinamica e expressa por urn marcador de multiplicidad~ (*), indicando a repetir;ao da mesma atividade mais de uma vez. A seguir, urn exemplo da execur;ao de uma atividade com uma concorrencia dinamica:

Preencher lista de propostas ..,

C oncorrencia dinfunica

Exemplo com algumas atividades do diagrama Analise de credito utilizando raias de natac;:ao

II

II

Modelagem utilizando a UML Diagrama de atividades intera;ao versus diagramas de

Quando voce usar as raias de nata<;:aoem diagramas de atividades, estani fazendo a atribui<;:ao de responsabilidades para as atividades em execu<;:ao.Esse tipo de nota<;:ao e semelhante as descri<;:6es de responsabilidades nos diagramas de intera<;:ao.A diferen<;:a e que em diagramas de intera<;:ao, sac demonstradas as intera<;:6es objetos, 0 que nao acontece com os diagramas de de atividades. Como fazer Identifique os cemirios que voce deseja representar por meio do diagrama de atividades. Inicie a modelagem apenas com as atividades basicas, acrescentando ao longo da modelagem separa<;:6ese jun<;:6es,desvios e intercala<;:6es, e outras nota<;:6esse necessario. Se necessario, tambem organize 0 diagrama de atividades com raias de nata<;:ao.Essa e uma 6tima op<;:ao para se visualizar as responsabilidades sobre as atividades em execu<;:ao.

o diagrama

de componentes representa os componentes que faraDparte dos sistemas em constru<;:ao,demonstrando as dependencias entre esses componentes. Todo 0 sistema orientado a objetos tera, dependendo do tamanho, dezenas ou centenas de componentes que em conjunto darao sentido a todos os processos de neg6cios desse sistema. Poderao existir componentes responsaveis pela irnplementa<;:ao de uma ou mais classes, mas podera, e com certeza existirao, outros tipos decomponentes, como tabelas, documentos, arquivos executaveis e tudo que compora fisicamente 0 sistema. Esses outros tipos de componentes de sistemas podem e devem ser representados nos diagramas de componentes. Caracteristicas do diagrama de componentes: Demonstra os componentes de urn sistema, com as dependencias entre eles. Podem serrepresentados componentes do tipo arquivo, documentos, tabelas, bibliotecas, entre outros artefatos de urn sistema.

Voce podera empregar os diagramas de componentes em dois tipos de modelagem: Fontes de sistemas. Vers6es de sistemas.

II

Modelagem utilizando a UML Fontes de sistemas Voce podeni utilizar m; diagramas de componentes para fazer a modelagem dos c6digos-fonte de urn sistema. Dessa forma, voce teni especificado e documentado a estrutura de componentes utilizados no constru<;ao do sistema. Uma interface e urn conjunto de opera<;6es que definem os servi<;osde uma classe e/ou componente. Uma interface pode definir, de forma total ou parcial, os servi<;os que serao utilizados ou fomecidos por urn componente. Graficamente, uma interface e representada por um cfrculo e, em sua forma expandida, por uma classe estereotipada como Interface.

Voce podera utilizar os diagramas de componentes para fazer a modelagem das vers6es liberadas dos sistemas que serao construfdos. Uma versao de urn sistema geralmente e composto por urn conjunto de componentes e outros arquivos que serao entregues aos seus usuarios.

Urn componente e uma implementa<;ao ffsica das abstra<;6es descobertas pelos diagramas de classes. Assim como as classes saD os blocos de constru<;ao mais importantes nos sistemas orientados a objetos, os componentes podem ser considerados implementa<;6es ffsicas desses blocos de constru<;ao. Urn modelo e algo que se pretende reproduzir. as componentes saD essas pr6prias reprodu<;6es, nao abstratas, mas ffsicas e executaveis, com 0 objetivo de se adaptar e realizar interfaces.

Interface Queue S~t> > DefaultCallB<ickO "<Get .DefaultCaliBackO GelEverilObjectO AddO

Interface Worker Set QueueMgrRefQ LetLogO . Get LogO .Lel~.>IDO

,Validacoas.java . .. ..

__ _ _.__ ._-~

Voce pode representar nos sistemas que construira nao s6 os componentes que deverao interagir com as interfaces definidas, mas tambem todos os tipos de artefatos que faraDparte do sistema. Esses artefatos podem ser arqui vos executaveis, tabelas, biblioteca, documentos, arquivos HTML, etc.

II

Modelagem utilizando a UML Tambem e possfvel definir estereotipos para classificaros componentes de sistemas.

Bibliolecas c1ientes.dll

Bibliotecas avalista.dll

a diagrama de implanta~ao representa a configura~ao e a arquitetura de urn sistema em que estarao ligados seus respectivos componentes, podendo ser representado tambem a arquitetura ffsica de hardwares, processadores, etc. a diagrama de implanta~ao abrange a visao estatica de implantac;:ao de urn sistema, envolvendo a modelagem da topologia de hardware em que 0 sistema sera executado.
Caracterfsticas do diagrama de implanta~ao : Pode representar a estrutura da plataforma em que sistema sera executado.
0

Sistemas baseados em componentes Ao contnirio de outros tipos de implementa~6es, os sistemas baseados em componentes podem trazerdiversos beneffcios. Urn deles e a modularidade. Em outros tipos de implementa~6es, urn sistema e construfdo em programas, engessando todo 0 processo do sistema. Quando urn sistema e construfdo em componentes isso nao acontece, pois esses componentes podem ser substitufdos, alterados e reutilizados indi vidualmente, sem comprometer outras partes do sistema ..

Po de representar qualquer dispositivo, como gerenciador de banco de dados, servidores, computadores, etc.

a foco dado nesse diagrama nao sera destinado aos desenvolvedores do sistema. Esse ctiagrama destina-se a profissionais, como, porexemplo, engenheiros de sistemas ou analistas de suporte, que devem estar preocupados com 0 hardware e 0 software que esta sendo construfdo, destacando principalmente a compatibilidade entre os dois.
Como ja foi dito anteriormente, a UML e uma linguagem para visualiza~ao, constru~ao, especifica~ao e documenta~ao de artefatos de sistemas de software, mas tambem pode abranger artefatos de hardware. Isso nao quer dizer que a UML e uma linguagem com urn objetivo amplo para a descri~ao de hardware. A UML vai ate 0 limite no que diz respeito a plataforma em que 0 sistema em desenvolvimento sera executadb.

a beneffcio nessa estruturae muito claro. Paraincluirmos mais funcionalidades aos sistemas, basta construirmos ou reutilizarmos componentes que forne~am os servi~os necessarios a nova implementa~ao. Dessa forma, construiremos sistemas com maior produtividade e qualidade, pois faremos apenas componentes que oferecerao servi~os ainda nao existentes no sistema.
Como fazer Identifique os componentes sistema. que farao parte de seu

Utilize estereotipos se necessano, para especificar melhoros componentes que voce utilizara no diagrama de componentes. Identifiqueas interfaces de sistemas que serao utilizadas e disponibilizadas pelos componentes, para ilustrar seu diagrama. Coloque no diagrama de componentes os documentos, tabelas, arquivos, que fazem parte de seu sistema.

Modelagem utilizando a UML Uso comum

o diagrama de implementa<;ao nao devera ser utilizado para todos os tipos de sistemas. Por exemplo, se voce esta desenvolvendo urn sistema simples que sera executado em apenas uma maquina, em que nao ha participa<;ao de outros tipos de hardware que interagem enquanto 0 sistema e executado, 0 uso do diagrama de implanta<;ao nao vai ser muito uti!.
Em vez disso, utilize 0 diagrama de implanta<;ao para fazer 0 mapeamento de hardwares cujo sistema interagini com mais de uma maquina de diferentes processadores, servidores, banco de dados, etc. Como fazer Identifique os dispositivos e processadores sistema que esta desenvolvendo. para
0

A UML e uma linguagem-padrao para a modelagem de sistemas orientados a objetos. Apesar de sua padroniza<;ao predefinida, a UML oferece nota<;6es de extensao que permitem a amplia<;ao de como podemos expressar nossos modelos. Basicamente, podemos encontrar duas formas de extensao da UML: Estere6tipos. Restri<;6es. Estere6tipos Os estere6tipos sac utilizados para a classifica<;ao de novos elementos na UML. 0 estere6tipo e utilizado para a cria<;ao de classifica<;6es de elementos que nao foram definidos como padrao, e deve ser utilizado para 0 tratamento de problemas especfficos de modelagem. Os estere6tipos sac formados por palavras entre fmgulos duplos "estereotipo ". Segue uma lista de estere6tipos predefinidos, que foram extraidos a partir do uso comum destes. Essa lista segue a seguinte classifica<;ao: Estere6tipos para relacionamentos Estere6tipos para classes. Estere6tipos para eventos e mensagens. Estere6tipos para componentes. Estere6tipos para relacionamentos Estere6tipos para restri<;6es. Estere6tipos para comentarios. Estere6tipos dependencias para relacionamentos de de generaliza<;ao. de dependencias.

Se for possivel, fa<;a uso de ferramentas para a descoberta da topologia de hardware onde 0 sistema sera executado. Se necessario crie mais de urn diagrama de implanta<;ao, cada urn focalizado em aspectos especfficos de sua estrutura de hardware. Para os diagramas de implanta<;ao, voce tambem pode utilizar notas para informar melhor 0 leitor sobre esses diagramas, bem como chamar a aten<;ao para aspectos importantes. Se voce fez a leitura desse guia des de 0 infcio, ja deve ter entendido 0 motivo pelo qual a UML foi estabelecida como padrao pela industria de software. A UML, dentro de urn ciclo de desenvolvimento, abrange todos os aspectos, que vaGdesde 0 levantamento inicial do sistema (onde nao se tern nada ainda), passando pela modelagem da arquitetura dos objetos que formarao esse sistema, ate 0 mapeamento da estrutura de hardware em que esse sistema sera executado.

Especifica que 0 conteudo publico do pacote de destine esta acessivel ao espa<;o do nome do pacote de origem.

Especifica que a origem instancia 0 template de destino, utilizando os parametros reais dados.

Especifica que a opera<;ao de origem invoca a opera<;ao de destino.

II

Modelagem

utilizando

a UML

Modelagem

utilizando

a UML

derived
Especifica queo elemento-origem e deri vado do elementodestino. Isso significa que 0 elemento-origem nao e uma instancia do elemento-destino, mas e uma instancia de urn outro elemento que e urn subtipo ou uma subclasse do elemento-destino.

Estere6tipos para classes

Especifica urn elemento que interage externamente com o sistema.

exception
Especifica urn evento que po de ser ativado ou capturado por uma opera<;ao de classe.

Especifica que urn caso de uso tern urn comportamento estendido a partir de urn caso de uso-base.

implementationC lass
Especifica a implementa<;ao de uma classe em uma linguagem de programa<;ao.

Especifica que 0 elemento-origem especial no elemento destino.

tern visibilidade

interface
Cole<;ao de opera<;6es que pode ser utilizado para definir os servi<;os que uma classe po de oferecer a outras.

import
Especifica que 0 conteudo publico do pacote-destino pode ser recebido e acessado por urn pacote-origem.

include
Especifica que comportamentos comuns a mais de urn caso de uso devem ser captura em outro caso de uso que sera utilizado pelos casos de uso que the deram origem.

Especifica urn classificadorcujas instancias de suas classes estaoenvolvidas em urn relacionamento de generaliza<;ao.

instanceof
Especifica que 0 objeto de origem classificador de destino.

Especifica urn classificador cujas instancias representam urn fluxo pesado.

e uma

instancia do

signal
Especifica urn estfmulo assfncrono comunicado instancias. entre

Especifica que as opera<;6es na classe de origem criam instancias da classe de destino.

stereotype
Especifica que 0 classificador e urn estere6tipo que pode ser aplicado a outros elementos.

Especifica que a origem que 0 destino.

e urn grau mais alto de abstra<;ao

Especifica urn classificador cujas instancias representam urn fluxo leve.
0

send
Especifica que a opera<;ao de origem envia destino. evento

Especifica que origem.

destino

e urn

antecessor hist6rico da

Especifica uma classe abstrata que e utilizada somente para determinar a estrutura e 0 comportamento de urn conjunto de objetos.

II

Modelagem utilizando a UML

Modelagem utilizando a UML

utility
Especifica classes cujos atributos e opera90es saD todo escopo de classes.

Estere6tipos para generalizac;ao implementation

relacionamentos

de

Estere6tipos para eventos e mensagens becomes

Especifica que 0 objeto-destino e 0 mesmo objeto que 0 de origem, mas em urn ponto adiante no tempo e com possiveis valores, estados ou papeis diferentes.

Especifica que 0 filho herd a a implementa9ao do pai, mas nao a toma publica, nem oferece suporte para suas interfaces, violando dessa forma a caracteristicade permitir substitui90es.

Especifica que 0 objeto de destino e uma c6pia exata do objeto-origem, mas e independente.

Especifica uma restri9ao que sempre precisa ser mantida para 0 elemento que esta associado.

precondition
Especifica que 0 objeto-destino e criado pelo evento ou pela mensagem enviada pelo objeto-origem. Especifica uma condi9ao que deve ser verdadeira antes da invoca9ao de uma opera9ao.

poscondition destroy
Especifica que 0 objeto-destino e destrufdo pelo evento ou pela mensagem enviada pelo objeto-origem. Especifica uma condi9ao que deve ser verdadeira ap6s termino da execu9ao de uma opera9ao.
0

Estere6tipos para comentarios Estere6tipos para componentes <<table

Especifica urn componente que representa uma tabela de banco de dados no sistema.

requirement
Especifica uma caracteristica ou comportamento desejado para urn sistema.

responsability
Especifica urn componente que representa urn documento do sistema. Responsabilidade ou obriga90es encarregado de cumprir. que urn elemento e

Especifica urn componente que representa urn componente que poden! ser executado no sistema.

file
Especifica urn componente que representa c6digos-fonte ou dados.

Especifica urn componente que representa uma bibliotec!l de objetos.

Modelagem utilizando a UML Restriyoes As restri~oes ampliam 0 vocabuhlrio dos elementos n UML, permitindo modificar ou acrescentar novas regras aos elementos do modelo. Por exemplo, por uma questiio de regra de neg6cio, todos os clientes do tipo pessoa ffsica devem ter obrigatoriamente 0 salario informado. Po demo expressar essa restri~ao como no exemplo a seguir. A regras devem ser express a entre chaves {}.

Modelagem utilizando a UML Restriyoes para instancias {destroyed} Especifica que a instancia deve ser destrufda antes da conclusao da intera~ao da qual ela faz parte.

Especifica que a instancia deve ser criada durante a execu~ao da intera~ao da qual ela faz parte.

PessoaFisica data Nascimento

sexo
RG CPF

Especifica que a instancia deve ser criada durante a execu~ao da intera~ao daqual elafaz parte, mas e destrufda antes da conclusao da execu~ao.

salario
estadoCivil

A UML, alem de disponibilizar nota~oes para restri~oes diversas, apresenta uma linguagem mais formal para a expressao de restri~oes e condi~oes, chamada DCL. Mais informa~oes sobre a DCL, consulte :

A UML tambem define como padrao algumas restri~oes. Aqui segue uma lista com esses padroes com 0 elemento a qual se aplica. Restriyoes para generalizayao {complete} Especifica que todos os subtipos de urn supertipo ja foram especificados, nao permitindo filhos adicionais.

Especifica que nem todos os subtipos de urn supertipo foram total mente especificados, permitindo filhos adicionais.

Especifica que subtipos de urn supertipo podem ter mais de urn filho como tipo.

Ferramentas que suportam a UML

Desde 0 lan~amento da UML no mercado, houve por parte de algumas empresas da area de informlitica a percep~ao da oportunidade de construirem ferramentas que suportassem essa nova tecnologia. A seguir 0 leitor encontrara algumas ferramentas disponiveis no mercado que suportam a linguagem UML. A seguir serao apresentadas as principais mudan~as ocorridas durante a evolu~ao da UML ate 0 momento.

Essa ferramenta foi des en vol vida pela Rational Software. Considero-a a mais completa disponivel ate 0 momenta no mercado. E uma ferramenta totalmente focada para a linguagem UML, mas tambem oferece suporte para os metodos Booch e OMT.

A UML des de seu nascimento vem passando por mudan~as em seu conteudo. Como con seqUencia dessas mudan~as foram criadas vers6es mais maduras e completas. Descrevo a seguir somente algumas mudan~as (que considero as mais importantes) que ocorreram durante as vers6es lan~adas da UML.

As mudan~as mais significativas nesta versao, diz respeito aos diagramas de classes e diagramas de seqUencia. Na versao 1.1, as classes podem ser especializadas como tipos ou como classes de implementar;iio.

Essa ferramenta foi desenvolvida pela Microsoft Corporation, fazendo parte do pacote Office. Consideroa uma ferramenta razoavel. Alem de suporte a UML, essa ferramenta oferece suporte para outros tipos de diagramas (nao UML) para as mais variadas aplica~6es. Consulte www.microsoft.comloffice/visio

Uma classe de implementa~ao e realmente uma classe programada no ambiente de software. Uma classe especializada como tipo que pode representar uma abstra~ao do sistema. Podem ser classes que representam apenas 0 modelo conceitual do sistema ou, ainda, as interfaces do sistema. Portanto, voce pode representar em seu modele de classes de implementa~ao urn ou mais tipos.

Essa ferramenta foi desenvolvida pela Sybase. Ainda nao tive a oportunidade de avaliar os recursos que suportam a UML, mas tenho informa~6es de que essa ferramenta suporta somente alguns diagramas da UML, como 0 de casos de uso, de classes e de seqUencia.

Para obter mais informa~6es sobre ferramentas suportam a linguagem UML, acesse 0 www.umlbrasil.com.bre clique em "Ferramentas".

que site

Na versao 1.0 da UML, os retomos em diagram as de seqUencia eram representados por uma flecha vazada, em vez de uma flecha cheia. Na versao 1.1, os retomos sac realizados por meio de uma flecha pontilhada, deixando mais perceptivel esse tipo de atividade. Sup6e-seque essa mudan~a foi realizada, pois a diferen~a entre uma flecha vazadae umacheia era muito suti! e de difici! diferencia~ao.

As mudan~as realizadas da versao 1.1 para a versao 1.2, foram modifica~6es sutis. Somente na versao 1.3 foram feitas mudan~as real mente significativas.

II

Na versao 1.1 da UML, haviadois tipos de relacionamentos entre casos de uso: relacionamento do tipo uses e extends. Ja na versao 1.3, foram disponibilizados tres tipos de relacionamentos: Include. Extends. Generalizac;ao.

Para comportamento condicional, voce pode agora usar a ~tividade de decisao (em forma de losango), para a mtercalac;ao ou ramificac;ao de comportamentos. A barra de sincronizac;ao e agora refedda como separac;ao ou junc;ao. Mas voce nao podera mais acrescentar condic;oes arbitrarias ~s junc;oes. Deve-se, entao, seguir regras de combinac;ao para assegurar-se de que separac;ao e junc;ao combinam.

No relacionamento do tipo include (substituindo 0 ate entao uses) as ati vidades em comum compartilhadas por alguns casos de uso saG inclufdas em urn outro caso de uso publico. Por exemplo, em urn sistema de analise de credito pode ser que tanto 0 processo de aprovac;ao de credito quanta 0 processo de reprovac;ao utilizem as atividades de validar a alc;ada do analista de credito.

o acionamento duplo nao e mais utilizado. Agora voce pode utilizar a concorrencia dinamica em uma atividade usando-se 0 asterisco (*). '

No relacionamento do tipo extends, as atividades de urn caso de uso nao obrigat6rias saG estendidas em urn outro caso de uso. Isso significa que urn comportamento de caso de uso po de ser desviado apenas em situac;oes predefinidas no caso de uso estendido. Por exemplo, em urn processo de analise de credito, 0 credito dos clientes pode ser aprovado automaticamente, sem que tenha de passar par todas as etapas de analise, caso sua renda seja cinco vezes 0 valor total do financiamento. Esse comportamento de aprovac;ao automatica pode mudartodo 0 comportamento do sistema caso sua condic;ao seja verdadeira.

No relacionamento de generalizar;ao 0 comportamento comum a mais de urn caso de uso em urn mesmo domfnio, ecapturadoem urn supertipo (generalizado). Sendo assim, esses casos de uso agora considerados subtipos (especializados) herdam desse supertipo criado 0 comportamento comum a eles mesmos.

abstra~ao
Caracterfstica essencial de uma entidade que a diferencia de todos os outros tipos.

caracterfstica estrutural Caracterfstica estrutural (estatica) de um elemento. cardinalidade Numero de elementos existentes em um conjunto. caso de uso Documento que descreve os cenarios pretendidos para um sistema, com 0 objetivo de atender as necessidades do usuario. classe Abstra<;ao de um conjunto de objetos que compartilham os mesmos atributos, opera<;6es e relacionamentos.

agrega~ao
Tipo de associa<;ao na qual um todo e relacionado com suas partes (relacionamento todo/parte). agregada Classe que representa agrega<;ao. "todo" no relacionamento de

arquitetura Arquitetura de sistemas e um conjunto de decis6es sobre artefatos e elementos que formaram 0 sistema. A arquitetura deve abranger como sera construfdo 0 sistema, seus elementos estruturais e comportamentais, suas colabora<;6es, etc. artefato Conjunto de informa<;6es utilizado ou realizado por um processo de desenvolvimento de sistemas de software. assinatura Nome, parfunetros e valores de retomo de uma opera<;ao.

colabora~ao
Nome dado a intera<;ao entre duas ou mais classes, com 0 objetivo de fornecer algum comportamento cooperativo. componente Parte ffsica de um sistema, que representa elementos l6gicos para a realiza<;ao de uma ou mais interfaces. com portamento Resultados produzidos por eventos e metodos.

composi~ao
Forma de agrega<;ao, em que 0 objeto-parte pode pertencer somente ao objeto-todo. Alem disso, geralmente 0 objetotodo vive e morre com suas partes, isto e, acontece uma remo<;ao em cascata container Objeto que existe para conter outros objetos e que proporciona opera<;6es para acessar ou interagir com seu conteudo.

associa~ao
Associa<;ao descreve relacionamentos entre objetos. Cada associa<;ao tem duas pontas, on de em cada ponta esta ligado um objeto. atividade Estado de execu<;ao de alguma coisa. Pode ser, por exemplo, a execu<;ao de um metodo em uma classe, uma rotina de trabalho, etc. ator Papel desempenhado por qualquer usuario de um caso de uso, ou seja, 0 ator e quem solicita os servi<;os disponfveis em casos de uso. atributo Atributo e uma propriedade de classe. Representa as caracterfsticas pr6prias de uma abstra<;ao. autochamada Mensagem que um objeto envia para si mesmo. caracterfstica comportamental Caracterfstica dinamica de um elemento, opera<;ao ou um metodo. como uma

delega~ao
Habilidade de um objeto enviar uma mensagem a um outro objeto como resposta a uma mensagem recebida. dependencia Relacionamento entre dois itens, em que a altera<;ao do item independente pode alterar a semantica do item dependente. destinatario Objeto que manipula a instancia de uma mensagem passada pelo objeto emissor. diagrama Representa<;ao grafica de um conjunto de elementos do sistema, que permite a visualiza<;ao do sistema sob diferentes perspectivas.

II

II

diagrama de atividades Representa urn fluxo de controle de atividades, que ocorrem no processo de urn sistema, oferecendo suporte para comportamentos condicionais e paralelos diagrama de casos de uso Representa urn conjunto de cemirios identificados, que seja util aos usuarios de urn sistema. diagrama de classes Representa 0 modelo da estrutura de urn sistema orientado a objetos, demonstrando as classes, os tipos e os relacionamentos. diagrama de colabora9ao Urn dos diagramas de interac;ao que da enfase a organizac;ao estrutural dos objetos que colaboram entre si. diagrama de componentes Representa os componentes que farao parte dos sistemas em construc;ao, demonstrando as dependencias entre esses componentes. diagrama de gnificos de estados Representaos estados possfveis deum objeto em particular. Sao demonstrados os estados de urn objeto, eventos, transic;6es e atividades. diagrama de implanta9ao Representa a configurac;ao e a arquitetura de urn sistema a que estarao Iigados seus respectivos componentes, podendo ser representada tambem a arquitetura ffsica de hard wares, processadores, etc. diagrama de objetos Representa a modelagem de instancias das classes de urn sistema em determinado ponto e momenta de execuc;ao. diagrama de sequencia Urn dos diagramas de interac;ao que da enfase a ordenac;ao sequencial em que os comportamentos acontecem. encapsulamento Mecanismo usado para ocultar os dados, a estrutura intema e os detalhes de implementac;ao de um objeto. Toda a interac;ao com um conjunto de objetos e feita de uma interface publica constitufda de operac;6es. estado Situac;ao vivida por um objeto, pela qual esse objeto deve responder algo aos eventos gerados.

estere6tipo Extensao do vocabulario da UML que permite a criac;ao de novos tipos de blocos de construc;ao, para atender necessidades especfficas de um modelo. estimulo Evento gerado no sistema que necessita de resultados. evento Ocorrencia de um estfmulo gerado para fazer a mudanc;a de seu estado atual.
0 objeto,

capaz de

exportar Tomar visfvel urn elemento fora do espac;o do nome que o contem. expressao SeqUencia de caracteres que tem como resultado um valor. expressao booleana Tem como resultado um valor booleano. filha Subclasse. foco de controle Indicador do perfodo de durac;ao pelo qual os objetos estao cooperando para realizar um comportamento. generaliza9ao E a capacidade de se criar superclasses que encapsulam a estrutura e 0 comportamento comum a varias subclasses. heran9a Mecanismo pelo qual elementos mais especfficos incorporam a estrutura e 0 comportamento de elementos mais gerais. heran9a multipla Uma variac;ao da generalizac;ao, em que uma subclasse pode herdar a estrutura e 0 comportamento de mais de uma superclasse. hierarquia de classes Representa descric;6es das relac;6es de heranc;a entre classes. implementa9ao Realizac;ao concreta do contrato declarado por uma interface ou a definic;ao de como algo e construfdo ou computado. incompleto Modelagem de um elemento em que faltam certas partes.

II

instancia Manisfesta~ao concreta de alguma abstra~ao, uma entidade a qual urn conjunto de operac,;5es pode ser aplicado e que tern urn estado para armazenar 0 efeito das operac,;5es. integridade Relacionamento consistente e apropriado entre dois ou mais elementos. intera930 Conjunto de objetos que interagem por meio da troca de mensagens, para a realiza~ao de urn comportamento. Iinha de vida do objeto Representa a existencia de urn objeto em uma intera~ao. m3e Superclasse. maquina de estados SeqUencia de estados pela qual urn objeto passa durante seu tempo de vida. mecanismos de extensabilidade Urn dos mecanismos que permite a extensao da UML de maneira organizada. mensagem Meio de comunica~ao entre objetos que contem informa~5es a espera de atividades que acontecerao. metodo Implementa~ao de uma opera~ao para uma c1asse. modele Simplifica~ao da realidade, criado com a finalidade de proporcionar uma melhor compreensao do sistema que sera gerado. multiplicidade Indica~ao de quantos objetos podem participar de urn dado relacionamento.

OCL (Object Constraint Language) Linguagem formal utilizada para expressar restri~5es de efeito livre. objeto Sinonimo de instancia de classe, sendo uma manifesta~ao concreta de uma abstra~ao com uma identidade que encapsula estados e comportamentos. objeto persistente Objeto que sobrevive ap6s processo ou urn thread. termino de execu~ao de urn

objeto transiente Objeto que sobrevive somente ate de urn processo ou urn thread.

0 termino

de execu~ao

opera93o Procedimento de chamada em urn objeto. opera93o polim6rfica Uma mesma operac,;ao que e implementada de maneira diferente por dois ou mais tipos. orientado a casos de uso Processo pelo qual os casos de uso sao utilizados como artefatos primarios para 0 estabelecimento do comportamento desejado do sistema, para verificar e validar a arquitetura de urn sistema. pacotes Organizam pai Superclasse. papel Comportamento de uma entidade determinado contexto no sistema. que participa de os modelos criados na UML.

n6
Elemento ffsico existente em tempo de execu~ao que representa urn recurso computacional. nota Representa comentarios, observa~5es e esclarecimentos que se podem utilizar para qualquer elemento da UML.

parametro Especificac,;ao de uma variavel que pode ser alterada, passada ou retornada. polimorfismo Conceito segundo 0 qual dois ou mais tipos de objetos podem responder a mesma mensagem de maneiras diferentes, usando opera~5es polim6rficas. p6s-condi93o Algo que necessita ser verdadeiro ap6s a chamada de uma operac,;ao.

.. II

pre-condi9ao Algo que necessita ser verdadeiro antes da chamada de uma opera9ao. privado Mecanismo de escopo usado para restringir 0 acesso a atributos e opera90es de uma classe, de maneira que outros objetos nao possa utiliza-Ios. produto Artefatos de desenvolvimento, documenta9ao gerada, etc. como c6digos, modelos,

superclasse Elemento que con tern a estrutura e 0 comportamento generalizado de outras classes (as subclasses). thread Fluxo leve de controle que pode ser executado concorrentemente com outros threads no mesmo processo. tipo Estere6tipo de uma classe, utilizado para especificar urn domfnio de objetos, com as opera90es que podem ser aplicadas aos objetos. transi9ao Relacionamento entre dois estados, em que 0 objeto no seu estado atual deve realizar atividades para passar para urn outro estado, desde que as atividades tenham sido cumpridas. UML (Unified Modeling Language) Linguagem de modelagem unificada para visualiza9ao, especifica9ao, constru9ao e documenta9ao de artefatos de sistemas de software. valor atribufdo Extensao das propriedades de urn elemento da UML, que permite a cria9ao de novas informa90es na especifica9ao desse elemento. versao Urn conjunto de artefatos de software, relativamente completos e consistentes que serao entregues. visao Proje9ao em urn modelo, vista a partir de deterrninada perspectiva ou ponto de vista, que omite as entidades que nao saG relevantes para essa visao. visao dinamica Aspectos de urn sistema que dao enfase a compartamentos. visao estatica Aspectos de urn sistema que dao enfase

propriedade Caracterfstica de urn elemento da UML. publico Mecanismo de escopo usado para tomar atributos e opera90es de classes acessfveis a outros objetos. raia de nata9ao Organiza as atividades representadas em diagramas de atividades. Essa organiza9ao consiste em criar grupos que saG responsaveis pelas atividades ocorridas. realiza9ao Relacionamento entre itens, no qual urn item implementa comportamentos especificados por outros. . receptor Objeto ao qual e enviada uma mensagem. refinamento Relacionamento que representa a especifica9ao completa de algo ja especificado em determinado nfvel de detalhe. relacionamentos Conexao semantica entre elementos. responsabilidade Contrato ou obriga9ao em urn tipo ou de uma classe. restri9ao Extensao da semantica de urn elemento da UML, permitindo criar ou modificar regras ja existentes. solicita9ao Especifica9ao de urn estfmulo enviado a urn objeto. subclasse Elemento que recebe por heran9a a estrutura comportamentos de uma superclasse. e os

a estrutura.

visibilidade Especifica9ao de como uma caracterfstica ou urn comportamento especificado para uma classe podem ser vistos par outros objetos de classe.

Obtendo mais informa~oes

A
abstra98.o 7 Agrega98.0 22 arquitetura 24, 34 Associa98.0 21 atividade 62 Ator 28 atributo 8, 41 Autochamada 53

o site www.umlbrasil.com.br foi criado pelo autor deste guia, e e 0 primeiro site brasileiro dedicado a linguagem UML. Nele voce encontrani tudo sobre a UML, orienta~ao a objetos, linguagens de programa~ao, entre outros assuntos relacionados com 0 tema.
A seguir, uma amostra do que
0

UMLBrasil oferece:

8
blocos de constru98.0 Booch 9 17, 38

Tutoriais
Tutoriais sobre UML, orienta~ao a objetos, linguagens de programa~ao, metodologias, etc.

C
caracterfsticas 7 caso de uso 18, 27 Caso de uso de alto nfvel 28 Caso de uso detalhado 28, 30 Classe 7, 18 CoadIYourdon 9 Colabora98.0 18 componentes 19, 67, 68 comportamentos 7, 24 composi98.0 22 concorrencia dinamica 64 condi98.0 53

Artigos
Artigos sobre objetos.
0

uso da UML, Java e orienta~ao a

Noticias
Notfcias sobre 0 mercado, lan~amentos de produtos. eventos, promo~6es e

Livros
Livros sobre UML, orienta~ao a objetos, banco de dados, metodologias e Iinguagens de programa~ao.

o
desvio 62 diagrama de colabora98.0 54 diagrama de atividades 13, 24, 25, 60 diagrama de casos de uso 10, 24, 27 diagrama de classes 13, 24, 38 diagrama de colabora98.o 12 diagrama de componentes 14, 25, 67 diagrama de graficos de estados 12, 58 diagrama de implanta98.o 15, 25, 71 diagrama de objetos 14, 24, 50 diagrama de sequencia 11, 52 diagramas de intera98.o 11, 24, 25, 51, 55, 66

Douglas Marcos da Sil va e bacharel em Administra~ao de Empresas. Atua como Consultor na modelagem de aplica~6es orientadas a objetos utilizando a linguagem UML, ministrando tambem treinamentos nesta linguagem. Para duvidas ou sugest6es, envie urn e-mail diretamente para 0 autor:

E
Especializa98.0 23 Estados 6, 58 Estere6tipos 73 Estfmulos 6 evento 59 Extens8.o 34

F
foco de contraIe 52

R
raia de natagao 65 Realizagao 23 relacionamentos 20, 38 Relacionamentosentre casos de uso 32 Restrigoes 73, 78 Reutizagao 6 Rose 80

G
Generalizagao 22, 32

H
Heranga 8

5
Inclusao 33 interagao 19, 51 intercalagao 62 Interfaces 69 Itensdinamicos 17, 19 !tensestciticos 17, 18 separagao 62

T
thread condicional 63 transigao 59

J
jungao 62

U
UML 10, 16, 17, 24, 40

L
Iinguagensde programagao 40 linha de vida 52

V
versoes da UML 81 visibilidade 43 Visio 80

M
Mciquinade estados 19 marcadorde interagao 53 mensagem 52 mensagemde retorno 53 metoda 46 metodoOMT 9 metodoOOSE 9 modelagemvisual 16 Modularidade 6 Multiplicidadede associagao 21

N
Notas 17, 20

o
objeto 7, 54 OMG 10 OMT 9 OOSE 9 operagao 8, 42, 46 orientagaoa objetos 6

p
Pacotes 17, 20 Polimorfismo 8 p6s-eondigao 45 PowerDesigner 80 pre-condigao 44

Rational@
the e-development company'" A Rational Software auxilia as empresas a desenvolver e implantar software para e-business, e-infrastructure e edevices atraves da combina~ao das melhores pniticas, ferramentas e servi~os de engenharia de software. A solu~ao de e-development da Rational ajuda as empresas a criar software mais nipido - Time-to- Market - e aIcan~ar a qualidade necessaria para satisfazerseus cIientes. Esta solu~ao unica e integrada simplifica 0 processo de aquisi~ao, implementa~ao e suporte de uma abrangente plataforma de desenvolvimento de software, 0 que reduz o custo total de propriedade.

Rational ClearCase@ Family Gerenciamento de configura~6es. Rational ClearQuesjTM and Rational ClearDDTSTM Gerenciamento de mudan~a e rastreamento de defeitos. Rational Purify, Rational Quantify, Rational PureCoverage@ Execu~ao de testes de confiabilidade. Rational Requisite Pro@ Gerenciamento de requisitos. Rational Robot Grava~ao de script funcional e de performance. Rational Rose@ family Possui recursos de modelagem em tempo real, casos de use, web, dados e aplicalivos. Rational SoDA@ Gera~ao automatizada de documenta~ao. Rational TeamTest Execu~ao de testes de funcionalidade. Rational TestManager Gerenciamento de artefatos de teste. Rational SiteLoad Testes de carga em websites. Rational QuaJityArchitect Gera~ao automatica de drives e stubs para teste unitario. Rational Unified Process Processo configuravel e adaptavel para qualquer projeto de software

A UML (Unified Modeling Language) e uma linguagem para especifica<;ao, documenta<;ao, visualiza<;ao e desenvolvimento de sistemas orientados a objetos. Sintetiza os principais metod os existentes, sendo considerada uma das linguagens mais expressivas para modelagem de sistemas orientados a objetos. Por meio de seus diagramas e possivel representar sistemas de softwares sob diversas perspectivas de visualiza<;ao. Facilita a comunica<;ao de todas as pessoas envolvidas no processo de desenvolvimento de um sistema - gerentes, coordenadores, analistas, desenvolvedores - por apresentar um vocabulario de facil entendimento. Este guia descreve os conceitos da UML e seus diagramas. Apresenta exemplos de utiliza<;ao destes diagramas, demonstrando, de maneira pratica, como pode ser feita a transi<;ao de um diagrama para outro. Pode ser de utilidade para profissionais que estejam conhecendo a modelagem de sistemas orientados a objetos, e para alunos dos cursos de Ciencias da Computa<;ao, Engenharia de Software, Processamento de Dados e Analise de Sistemas que estejam estudando 0 assunto.

Copyright Novatec Editora Ltda. Tel.: +55 11 6959-6529 Fax: +55 11 6950-8869 E-mail: novatec@novateceditora.com.br Site: www.novateceditora.com.br Sao Paulo Brasil