Anlise Orientada a Objetos

Goiansia 2011

Sumrio
Introduo ................................................................................................................................................... 5 Anlise e Especificao de Requisitos .......................................................................................................... 5 Processo de desenvolvimento de software .................................................................................................... 6 Vises de um Sistema .................................................................................................................................. 8

Levantamento de Requisitos ....................................................................................................10 Estudo de Viabilidade............................................................................................................... 12 Processo de Extrao de Requisitos .......................................................................................... 13 Tcnicas para extrao de requisitos ........................................................................................ 14 Especificao e documentao .................................................................................................17
Validao .................................................................................................................................................. 22 UML Linguagem de Modelagem Unificada ............................................................................................ 23 Um processo para utilizar a UML ............................................................................................................... 25 O Futuro da UML ....................................................................................................................................... 26

Abstrao.................................................................................................................................26 Classes .....................................................................................................................................27 Objetos ....................................................................................................................................27 Instanciao ............................................................................................................................. 28 Encapsulamento ...................................................................................................................... 28 Mtodos ..................................................................................................................................29 Herana ...................................................................................................................................30 Herana Mltipla ..................................................................................................................... 30 Polimorfismo ........................................................................................................................... 30
Diagramas da UML ................................................................................................................................... 31

Diagrama de Casos de Uso .......................................................................................................32 Atores .......................................................................................................................................... 33 Casos de Uso................................................................................................................................ 34 Associao (Interao) ................................................................................................................. 34 Relacionamento entre Atores ......................................................................................................34 Relacionamento entre Atores e casos de uso ............................................................................... 35 Relacionamento entre casos de uso e outros casos de uso ........................................................... 35 Documentao de Casos de Uso............................................................................................... 38 2

Diagrama de Classes .................................................................................................................................. 39

Responsabilidade ..................................................................................................................... 40 Componentes........................................................................................................................... 40 Atributos......................................................................................................................................40 Operaes (Mtodos) .................................................................................................................. 40 Visibilidade ..................................................................................................................................42 Relacionamentos ..................................................................................................................... 42 Classe Associativa .................................................................................................................... 47
Diagrama de Objetos ................................................................................................................................. 48 Diagrama de Mquina de Estados .............................................................................................................. 48

Estado ......................................................................................................................................49 Transies ................................................................................................................................ 49 Estados Inicial e Final ............................................................................................................... 50 Atividades internas .................................................................................................................. 50 Transies internas .................................................................................................................. 51 Auto-Transies ....................................................................................................................... 51 Pseudo-Estado de Escolha ........................................................................................................ 51 Barra de Sincronizao ............................................................................................................. 52 Pseudo-Estado de Juno ......................................................................................................... 53 Estado Composto ..................................................................................................................... 53 Estado de Histria .................................................................................................................... 54 Estado de Submquina ............................................................................................................. 54 Estados de Entrada e Sada (Entry e Exit States) .......................................................................55 Pseudo-Estado de Trmino ......................................................................................................55 Estado de Sincronismo ............................................................................................................. 55
Diagrama de Sequncia ............................................................................................................................. 56

Atores ......................................................................................................................................57 Objetos ....................................................................................................................................57 Linha de Vida ........................................................................................................................... 58 Foco de Controle ou Ativao...................................................................................................58 Mensagens ou Estmulos .......................................................................................................... 59 Mensagens de retorno ............................................................................................................. 61 Auto-chamadas ou Auto-delegaes ........................................................................................ 62 Fragmentos de Interao e Ocorrncias de Interao ............................................................... 62 3

Portes (Gates) ............................................................................................................................ 64 Fragmentos Combinados e Operadores de Interao ...................................................................64

Diagrama de Comunicao ........................................................................................................................ 68 Diagrama de Atividade .............................................................................................................................. 69

N de Ao .............................................................................................................................. 70 Controle de Fluxo ..................................................................................................................... 70 N Inicial ..................................................................................................................................71 N Final....................................................................................................................................71 N de Deciso .......................................................................................................................... 71 Conectores............................................................................................................................... 71 Subatividade ............................................................................................................................ 72 N de Bifurcao/Unio ........................................................................................................... 73 Fluxo de Objetos ...................................................................................................................... 74 N de Objeto ........................................................................................................................... 74 Alfinetes (Pins) ......................................................................................................................... 74 Excees ..................................................................................................................................75 Ao de Objeto de Envio .......................................................................................................... 75 Ao de Evento de Aceitao ...................................................................................................75 Ao de Evento de Tempo de Aceitao ................................................................................... 76 N de Repositrio de Dados (Data Store Node) ........................................................................ 76 Partio de Atividade ............................................................................................................... 77 Regio de Atividade Interrompvel ........................................................................................... 77 Regio de Expanso ................................................................................................................. 78
Diagrama de Componente ......................................................................................................................... 78 Diagrama de Execuo ............................................................................................................................... 80 Diagrama de Estrutura Composta .............................................................................................................. 80

Introduo
O desenvolvimento de software uma atividade de crescente importncia na sociedade contempornea. A utilizao de computadores nas mais diversas reas do conhecimento humano tem gerado uma crescente demanda por solues

computadorizadas. importante observar que, associada ao acrscimo da demanda, a evoluo do hardware tem sido mais acentuada, disponibilizando aos usurios mquinas cada vez mais velozes e com maior capacidade de processamento. Neste contexto, identificou-se, j na dcada de 70, uma situao crtica no desenvolvimento de software, a chamada Crise do Software, caracterizada pelos seguintes fatos: demanda muito superior capacidade de desenvolvimento; qualidade insuficiente dos produtos; e estimativas de custo e tempo raramente cumpridas nos projetos. Visando melhorar a qualidade dos produtos de software e aumentar a produtividade no processo de desenvolvimento, surgiu a rea de pesquisa denominada Engenharia de Software. A Engenharia de Software busca organizar esforos no desenvolvimento de ferramentas, metodologias e ambientes de suporte ao desenvolvimento de software. Dentre as principais atividades de um processo de desenvolvimento de software, destaca-se a atividade de anlise e especificao de requisitos, na qual os requisitos de um sistema so levantados e modelados, para s ento ser projetada e implementada uma soluo. Esta atividade o objeto de estudo desta disciplina.

Anlise e Especificao de Requisitos

Um completo entendimento dos requisitos do software essencial para o sucesso de um esforo de desenvolvimento de software. A atividade de anlise e especificao de requisitos um processo de descoberta, refinamento, modelagem e especificao. O escopo do software definido no planejamento do projeto refinado em detalhe, as funes e o desempenho do software so especificados, as interfaces com outros sistemas so indicadas e restries que o software deve atender so estabelecidas. Modelos dos dados
5

requeridos, do controle e do comportamento operacional so construdos. Finalmente, critrios para a avaliao da qualidade em atividades subseqentes so estabelecidos. Os principais profissionais envolvidos nesta atividade so o analista e o cliente/usurio. Na atividade de especificao, os requisitos so capturados sob uma perspectiva dos usurios, isto , os modelos gerados procuram definir as funcionalidades (requisitos funcionais) e restries (requisitos no funcionais) que devem ser consideradas para atender s necessidades dos usurios. J na atividade de anlise so modeladas as estruturas internas de um sistema capazes de satisfazer os requisitos identificados. A etapa de especificao de requisitos independente de paradigma, uma vez que trata os requisitos do sistema sob uma perspectiva externa. Nesta parte, so discutidas tcnicas para levantamento de requisitos e a tcnica de modelagem de casos de uso, para modelagem dos requisitos funcionais de um sistema. Entretanto, a atividade de anlise, que modela as estruturas internas de um sistema, completamente dependente do paradigma adotado no desenvolvimento, como a Anlise Orientada a Objetos, que apresenta os principais conceitos da orientao a objetos e a linguagem de modelagem unificada (UML) e explora a modelagem de anlise segundo o paradigma de objetos; e a Anlise Essencial de sistemas que apresenta os principais conceitos da anlise essencial e discute a modelagem de anlise segundo o mtodo da anlise essencial, que adota o paradigma estruturado.

Processo de desenvolvimento de software

Um Processo de desenvolvimento de software um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software. estudado dentro da rea de Engenharia de Software, sendo considerado um dos principais mecanismos para se obter software de qualidade e cumprir corretamente os contratos de desenvolvimento, sendo uma das respostas tcnicas adequadas para resolver a t do software. Passos/Atividades do Processo:

Anlise de requisitos de software: A extrao dos requisitos de um desejado produto de software a primeira tarefa na sua criao. Embora o cliente, provavelmente, acredite saber o que o software deva fazer, esta tarefa requer
6

habilidade e experincia em engenharia de software para reconhecer a incompletude, ambigidade ou contradio nos requisitos.

Especificao: A especificao a tarefa de descrever precisamente o software que ser escrito, preferencialmente de uma forma matematicamente rigorosa. Na prtica, somente especificaes mais bem sucedidas foram escritas para aplicaes bem compreendidas e afinadas que j estavam bem desenvolvidas, embora sistemas de software de misso crtica sejam freqentemente bem especificados antes do desenvolvimento da aplicao. Especificaes so mais importantes para interfaces externas que devem permanecer estveis.

Arquitetura de Software: A arquitetura de um sistema de software remete a uma representao abstrata daquele sistema. Arquitetura concernente garantia de que o sistema de software ir ao encontro de requisitos do produto, como tambm assegurar que futuros requisitos possam ser atendidos. A etapa da arquitetura tambm direciona as interfaces entre os sistemas de software e outros produtos de software, como tambm com o hardware bsico ou com o sistema operacional.

Implementao (ou codificao): A transformao de um projeto para um cdigo dever ser a parte mais evidente do trabalho da engenharia de software, mas no necessariamente a sua maior poro.

Teste: Teste de partes do software, especialmente onde tenha sido codificado por dois ou mais engenheiros trabalhando juntos, um papel da engenharia de software.

Documentao: Uma importante tarefa a documentao do projeto interno do software para propsitos de futuras manutenes e aprimoramentos. As documentaes mais importantes so das interfaces externas.

Suporte e Treinamento de Software: Uma grande porcentagem dos projetos de software falha pelo fato de o desenvolvedor no perceber que no importa quanto tempo a equipe de planejamento e desenvolvimento ir gastar na criao do software se ningum da organizao ir us-lo. As pessoas ocasionalmente resistem mudana e evitam aventurar-se em reas pouco familiares. Ento, como parte da fase de desenvolvimento, muito importante o treinamento para os usurios de software mais entusiasmados, alternando o treinamento entre usurios neutros e usurios favorveis ao software. Usurios iro ter muitas questes e problemas de software os quais conduziro para a prxima fase.

Manuteno: A manuteno e melhoria de software lidam com a descoberta de novos problemas e requerimentos. Ela pode tomar mais tempo que o gasto no desenvolvimento inicial do mesmo. No somente pode ser necessrio adicionar cdigos que combinem com o projeto original, mas determinar como o software trabalhar em algum ponto depois da manuteno estar completa, pode requerer um significativo esforo por parte de um engenheiro de software. Cerca de de todos os engenheiros de software trabalham com a manuteno. Uma pequena parte destes trabalha na correo de erros. A maioria das manutenes para ampliar os sistemas para novas funcionalidades, as quais, de diversas formas, podem ser consideradas um novo trabalho. Analogamente, cerca de de todos os engenheiros civis, arquitetos e construtores trabalham com manuteno de uma forma similar.

Vises de um Sistema
O desenvolvimento de um sistema complexo no uma tarefa fcil. O ideal seria que o sistema inteiro pudesse ser descrito em um nico grfico e que este representasse por completo as reais intenes do sistema sem ambiguidades, sendo facilmente interpretvel. Infelizmente, isso impossvel. Um nico grfico incapaz de capturar todas as informaes necessrias para descrever um sistema. Um sistema composto por diversos aspectos: funcional (que sua estrutura esttica e suas interaes dinmicas), no funcional (requisitos de tempo, confiabilidade, desenvolvimento, etc.) e aspectos organizacionais (organizao do trabalho, mapeamento dos mdulos de cdigo, etc.). Ento o sistema descrito em um certo nmero de vises, cada uma representando uma projeo da descrio completa e mostrando aspectos particulares do sistema. Cada viso descrita por um nmero de diagramas que contm informaes que do nfase aos aspectos particulares do sistema. Existe em alguns casos uma sobreposio entre os diagramas o que significa que cada um pode fazer parte de mais do que uma viso. Os diagramas que compem as vises contm os modelos de elementos do sistema. As vises que compem um sistema so:

Viso de Componentes

Viso Lgica

Viso de Use-case

Viso de Organizao

Viso de Concorrncia

Viso "Use-case" (caso de uso): Descreve a funcionalidade do sistema desempenhada pelos atores externos do sistema (utilizadores). A viso use-case central, j que seu contedo base do desenvolvimento das outras vises do sistema. Essa viso montada sobre os diagramas de use-case (caso de uso) e eventualmente diagramas de atividade.

Viso Lgica: Descreve como a funcionalidade do sistema ser implementada. feita principalmente pelos analistas, programadores e utilizadores. Em contraste com a viso use-case, a viso lgica observa e estuda o sistema internamente. Ela descreve e especifica a estrutura esttica do sistema (classes, objectos, e relacionamentos) e as colaboraes dinmicas quando os objetos enviarem mensagens uns para os outros para realizarem as funes do sistema. Propriedades como persistncia e concorrncia so definidas nesta fase, bem como as interfaces e as estruturas de classes. A estrutura esttica descrita pelos diagramas de classes e objetos. O modelo dinmico descrito pelos diagramas de estado, sequncia, Comunicao e atividade.

Viso de Concorrncia: Trata a diviso do sistema em processos e processadores. Este aspecto, que uma propriedade no funcional do sistema, permite uma melhor utilizao do ambiente onde o sistema se encontrar, se o mesmo possui execues paralelas, e se existe dentro do sistema uma gesto de eventos assncronos. Uma vez dividido o sistema em linhas de execuo de processos concorrentes (threads), esta viso de concorrncia dever mostrar como se d a comunicao e a concorrncia destas threads. A viso de concorrncia suportada pelos diagramas dinmicos, que so os diagramas de estado, sequncia, Comunicao e atividade, e pelos diagramas de implementao, que so os diagramas de componentes e de instalao.

Viso de Componentes: suportada pelos diagramas de componentes que descrevem a implementao dos mdulos e suas dependncias. principalmente executada por programadores.

Viso de Organizao: Esta viso representada pelos diagramas de instalao ou

de execuo. A viso de organizao mostra a organizao fsica do sistema, os
9

computadores, os perifricos e como eles se conectam entre si. executada pelos engenheiros de sistemas (programadores, integradores e testers).

Levantamento de Requisitos
Entender os requisitos de um problema est entre as tarefas mais difceis enfrentadas por um engenheiro de software. A engenharia de requisitos ajuda os engenheiros de software a compreender melhor o problema que eles vo trabalhar para resolver. Inclui um conjunto de tarefas que levam a um entendimento de qual ser o impacto do software sobre o negcio, do que o cliente quer e de como os usurios finais vo interagir com o software. A engenharia de requisitos comea com a concepo tarefa que define o escopo e a natureza do problema a ser resolvido. Ela avana para o levantamento tarefa que ajuda o cliente a definir o que necessrio; e depois para a elaborao em que os requisitos bsicos so refinados e modificados. medida que o cliente define o problema, ocorre a negociao quais so as prioridades, o que essencial, o que necessrio? Mas ser que fcil?

10

Segundo dicionrio da Lngua Portuguesa: Requisito: Condio a ser preenchida necessariamente pelo produto ou servio. uma condio ou capacidade que deve ser alcanada ou possuda por um sistema ou componente deste para satisfazer um contrato, padro, especificao ou outros documentos formalmente impostos. No importa quo bem projetado ou codificado est um programa, se ele for mal analisado e especificado desapontar o usurio e trar aborrecimentos ao desenvolvedor. A atividade de levantamento de requisitos a etapa de compreenso do problema aplicado ao desenvolvimento de software. O principal objetivo que os desenvolvedores e usurios do sistema a ser construdo tenham a mesma viso do problema a ser resolvido. de suma importncia que antes da escrita de uma nica linha de cdigo, seja concluda a etapa do levantamento de requisitos, vale a mxima que quase impossvel concluir esta etapa devido natureza flexvel que os sistemas de softwares exigem. Normalmente os requisitos de um sistema so identificados a partir do domnio do negcio. O produto do levantamento de requisito o documento de requisitos, que declara os diversos tipos de requisitos do sistema. O vocabulriqo utilizado que deve ser utilizado neste documento deve ser acessvel ao usurio (cliente) do sistema e preferencialmente que no possua nenhuma referncia tecnologia. Imagine que um determinado software tenha sido desenvolvido aplicando as melhores prticas e tcnicas de programao, mas que quando entram em produo os usurios no conseguem oper-los, ou no conseguem extrair/trabalhar as informaes que ele normalmente est acostumado a obter. Ento logo eles iro comear a reclamar do sistema e em muitos dos casos iro se antepor a utiliz-lo. para evitar situaes como essa que a fase de levantamento de requisitos existe. Uma das formas de se medir a qualidade de um sistema de software atravs de sua utilidade. E um sistema ser til para seus usurios se atender aos requisitos definidos. Portanto, os requisitos devem ser expressos de uma maneira tal que eles possam ser verificados e comunicados a leitores tcnicos e no-tcnicos. Clientes (leitores notcnicos) devem entender esses documentos para que possam priorizar o desenvolvimento dos requisitos, conforme as necessidades da organizao. No importa qual seja o processo de desenvolvimento utilizado: o envolvimento do usurio final no desenvolvimento de um sistema de software de fundamental importncia.

11

A engenharia de requisitos consiste no estudo de viabilidade do sistema, na extrao, na anlise, na especificao, na documentao e validao de requisitos. O produto final do processo de extrao de requisitos um documento de Especificao de Requisitos de Software (ERS), que descreve o que o sistema proposto dever fazer, sem, entretanto descrever como o software far isso.

Estudo de Viabilidade
Para todos os sistemas novos, o processo de engenharia de requisitos deve comear com um estudo de viabilidade. A entrada para o estudo de viabilidade uma descrio geral do sistema e de como ele ser utilizado dentro de uma organizao. Os resultados do estudo de viabilidade deve ser um relatrio que recomenda se vale a pena ou no realizar o processo de engenharia de requisitos e o processo de desenvolvimento de sistema. Um estudo de viabilidade , na maioria das vezes, um estudo breve, direcionado, que se destina a responder algumas perguntas: O sistema contribui para os objetivos gerais da organizao? O sistema pode ser implementado com a utilizao de tecnologia atual dentro das restries de custo e de prazo? O sistema pode ser integrado com outros sistemas j em operao? Preparar um estudo de viabilidade envolve avaliar e coletar informaes e preparar relatrios. Depois de obtida as informaes, as seguintes perguntas devem ser feitas: Como a organizao se comportaria, se esse sistema no fosse implementado? Quais so os problemas com os processos atuais e como o sistema ajudaria a diminu-los? Quais sero as contribuies diretas advindas do novo sistema? Essas informaes podem ser transferidas para outros sistemas existentes na organizao e/ou podem ser recebidas de programas j implementados? O sistema requer tecnologia que no tenha sido utilizada anteriormente na organizao? Quais as compatibilidades que sero necessrias para com o sistema? Entre as fontes de informao esto os gerentes dos departamentos no qual o sistema ser implantado, os engenheiros de software acostumados com o tipo do sistema proposto, peritos em tecnologia, usurios finais do sistema, etc (stakeholders - qualquer pessoa que tenha uma influncia direta ou indireta sobre os requisitos do sistema).
12

O relatrio de estudo de viabilidade pode propor mudanas no enfoque, no oramento e no cronograma e sugerir outros requisitos de alto nvel do sistema.

Processo de Extrao de Requisitos

A tarefa de extrao de requisitos no fcil. As necessidades do usurio mudam medida que o ambiente no qual o sistema funciona muda com o tempo. Alm disso, frequentemente a ERS e o prprio processo de anlise e especificao de requisitos do novas ideias aos clientes sobre as suas necessidades e sobre as funes do sistema. Portanto, mudanas nos requisitos acontecem na maioria dos sistemas complexos. Embora muitas mudanas sejam devidas s mudanas das necessidades dos usurios, muitas advm da interpretao ou especificao incorreta dos requisitos do sistema. Requisitos incompletos, incorretos ou mal entendidos so as causas mais frequentes da baixa qualidade, excesso de custo e entrega fora do prazo. Essa tarefa no encarada com a devida importncia durante a maioria dos cursos. Normalmente o professor cria a especificao e os alunos sentam-se frente ao computador e comeam a escrever o programa. Na vida real, isso no acontece. O software a ser desenvolvido pode ter escopos e complexidade diversificados e na maioria dos casos no possvel sentar frente da mquina antes de obter mais informaes sobre o que o software deve fazer, que sero obtidas atravs da extrao de requisitos. A habilidade de empregar um processo sistemtico na extrao de requisitos um dos conhecimentos imprescindveis para um engenheiro de software. Pesquisas tm mostrado que quase todo o software vendido no satisfaz as necessidades do usurio. A engenharia de requisitos, um dos termos utilizados para esse processo, engloba os seguintes processos: Extrao dos Requisitos: o processo atravs do qual os usurios ou compradores de um sistema de software descobrem, revelam e entendem os requisitos. Anlise dos Requisitos: o processo de raciocnio sobre os requisitos que foram extrados; envolve atividades de exame dos requisitos para descobrir conflitos ou inconsistncias, unio de requisitos relacionados e identificao de requisitos que porventura estejam faltando. Especificao dos Requisitos: o processo de armazenar os requisitos em uma ou mais formas, incluindo lngua natural ou formal, representaes simblicas ou grficas.
13

Validao dos Requisitos: o processo de confirmao, junto ao usurio, que os requisitos especificados so vlidos e esto corretos e completos. Esses processos no podem ser totalmente separados e executados seqencialmente.

Todos eles so intercalados e executados repetidamente. Em muitos casos, quando se especifica os requisitos localiza-se conflitos ou ausncias, quando se valida, percebe-se a necessidade de outros requisitos ou detalhes. Nesses casos, precisa-se retornar ao processo de extrao de requisitos. A maneira mais comum de extrair requisitos obter a informao diretamente das pessoas que utilizam o sistema e esse procedimento pode ser dividido em cinco etapas: Identificar as fontes de requisitos relevantes (usurios ou mais propriamente stakeholders); Fazer perguntas apropriadas visando obter um entendimento das necessidades dos usurios; Analisar as informaes obtidas, procurando por implicaes, inconsistncias ou questes no resolvidas; Confirmar com os usurios o seu entendimento do problema; Sintetizar os requisitos de forma apropriada.

Tcnicas para extrao de requisitos

Em todo desenvolvimento de software, um aspecto fundamental a captura dos requisitos dos usurios. A extrao de requisitos um processo impreciso e difcil. Existem vrias dificuldades implcitas nesse processo.

Para apoiar este trabalho, diversas tcnicas podem ser utilizadas. Amostragem: Em um levantamento de requisitos, geralmente um engenheiro de software se depara com duas importantes questes: Entre os muitos relatrios, formulrios e documentos gerados pelos membros de uma organizao, quais devero ser objeto de investigao?
14

Pode haver um grande nmero de pessoas afetadas pelo sistema de informao proposto. Quais delas devem ser entrevistadas, observadas ou questionadas? Servindo de base para todas as tcnicas de levantamento de requisitos, entre elas

investigao, entrevistas e observao, esto as decises cruciais dizendo respeito a o que examinar e quem questionar ou observar. Estas decises podem ser apoiadas por uma abordagem estruturada chamada amostragem. Amostragem o processo de seleo sistemtica de elementos representativos de uma populao. Quando os elementos selecionados em uma amostragem so analisados, pode-se assumir que esta anlise revelar informaes teis acerca da populao como um todo. Por que usar amostragem? diminuir custos; acelerar o processo de levantamento de informaes; eficincia: a informao tende a ser mais apurada, j que menos elementos podem ser analisados, mas estes podem ser analisados com mais detalhes; reduzir tendncias.

Investigao: Muitas vezes, algumas informaes so difceis de serem obtidas atravs de entrevistas ou observao. Tais informaes revelam, tipicamente, um histrico da organizao e sua direo. Nestes casos, devemos utilizar investigao, isto , anlise de documentos. Atravs de investigao, podemos obter mais facilmente informaes, tais como tipos de documentos e problemas associados, informao financeira e contextos da organizao. Essas informaes so difceis de serem obtidas atravs de outras tcnicas de levantamento de requisitos, tais como entrevistas ou observao. Entrevistas: Uma entrevista de levantamento de informaes uma conversa direcionada com um propsito especfico, que utiliza um formato pergunta-resposta. Os objetivos de uma entrevista incluem: obter as opinies do entrevistado, o que ajuda na descoberta dos problemas-chave a serem tratados; conhecer os sentimentos do entrevistado sobre o estado corrente do sistema; obter metas organizacionais e pessoais; e levantar procedimentos informais
15

Em uma entrevista, o engenheiro de software est, provavelmente, estabelecendo um relacionamento com uma pessoa estranha a ele. Assim, importante que ele: construa, rapidamente, uma base de confiana e entendimento; mantenha o controle da entrevista; venda a idia do sistema, provendo ao entrevistado as informaes necessrias.

Questionrios: O uso de questionrios constitui uma tcnica de levantamento de informaes que permite ao analista obter de vrias pessoas afetadas pelo sistema (corrente ou proposto). Informaes tais como: Posturas: o que as pessoas na organizao dizem querer; Crenas: o que as pessoas pensam ser realmente verdade; Comportamento: o que as pessoas fazem; Caractersticas: propriedades de pessoas ou coisas. Um questionrio pode ter objetivos distintos, em funo de sua aplicao, tais como: Procurar quantificar o que foi levantado em entrevistas. Determinar como um sentimento (expresso em uma entrevista) realmente difundido ou limitado. Examinar uma grande amostra de usurios do sistema para sentir problemas ou levantar questes importantes, antes de se programar entrevistas. H muitas similaridades entre estas duas tcnicas. De fato, pode ser til utilizar as duas abordagens em conjunto: procurando refinar respostas no claras de um questionrio em uma entrevista; projetando um questionrio com base no que foi levantado em uma entrevista.

Observao: Observar o comportamento e o ambiente do indivduo que toma decises pode ser uma forma bastante eficaz de levantar informaes que, tipicamente, passam despercebidas usando outras tcnicas. Tomadas de deciso ocorrem em diversos nveis da organizao: operacional, gerencial e estratgico e, portanto, importante observ-las em todos os nveis que tenham interao com o sistema. Atravs da observao possvel capturar: o que realmente feito e no apenas o que documentado ou explicado. o relacionamento entre o tomador de deciso e outros membros da organizao. A observao usada para:
16

obter informaes sobre o tomador de deciso e seu ambiente, que no so capturadas por outras tcnicas.

confirmar ou negar informaes de entrevistas e/ou questionrios. Alguns pontos importantes devem ser realados: o analista deve saber o que

observar, quem observar, quando, onde, porque e como. Prototipao: A prototipao uma tcnica valiosa para se obter rapidamente informaes especficas sobre requisitos de informao do usurio. Trata-se de uma verso inicial do sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que atravs da comunicao verbal no so to facilmente identificveis. Neste tipo de abordagem apenas so desenvolvidas algumas funcionalidades sendo normalmente desenvolvidas primeiro aquelas que so mais fceis de compreender por parte do utilizador e que lhe podem trazer maior valor acrescentado (principalmente na prototipao evolutiva, isto , aquela que mais tarde evoluda para a fase de desenvolvimento). O uso de prottipos deve ser considerado apenas mediante uma anlise custo-benefcio, j que os custos de desenvolvimento de um prottipo podem facilmente crescer, sendo particularmente teis em situaes em que a interface com os utilizadores , para eles, um aspecto crtico. Tipicamente, a prototipao permite capturar os seguintes tipos de informao: Reaes iniciais do usurio: Como o usurio se sente em relao ao sistema em desenvolvimento? Reaes ao prottipo podem ser obtidas atravs da observao, entrevistas, questionrio ou relatrio de avaliao. Sugestes do usurio para refinar ou alterar o prottipo: guiam o analista na direo de melhor atender as necessidades dos usurios. Inovaes: novas capacidades, no imaginadas antes da interao com o prottipo. Informaes para reviso de planos: estabelecer prioridades e redirecionar planos. Usurios so fundamentais na prototipao. Para capturar as reaes dos usurios em relao ao prottipo, outras tcnicas de levantamento de informao devem ser usadas em conjunto. Durante a experimentao do usurio com o prottipo, utiliza-se a observao. Para capturar opinies e sugestes, podem ser empregados, alm da observao, entrevistas e questionrios.

Especificao e documentao
nesta fase que se d a produo propriamente dita do documento de especificao de requisitos.
17

Em todos os tipos de especificao h dois tipos de requisitos a considerar: Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente. aquilo que o utilizador espera que o sistema oferea, atendendo aos propsitos para qual o sistema ser desenvolvido. Exemplos: o O software deve possibilitar o clculo dos gastos dirios, semanais, mensais e anuais com pessoal. o O software deve emitir relatrios de compras. o Os usurios devem poder obter o nmero de aprovaes, reprovaes e trancamentos em todas as disciplinas. Os requisitos funcionais descrevem as funcionalidades e servios que o sistema deve oferecer. Dependem do tipo do software, potenciais usurios e do tipo de sistema onde o software ser utilizado. Requisitos no-funcionais: referem-se a aspectos no-funcionais do sistema, como restries nas quais o sistema deve operar ou propriedades emergentes do sistema. Costumam ser divididos em Requisitos no-funcionais de: Utilidade, Confiana, Desempenho, Suporte e Escalabilidade. Exemplos: o O tempo de resposta do sistema deve ser inferior a 30 segundos. o O tempo de desenvolvimento no deve ultrapassar seis meses. o O software deve ser operacionalizado no sistema especfico. Os requisitos no-funcionais definem as propriedades do sistema e suas restries, isto , confiabilidade, tempo de resposta. Restries podem ser capacidade de dispositivos de I/O, representaes grficas, etc. Pode-se tambm considerar os requisitos do domnio, que tal como o nome indica derivam do domnio e no de necessidades especficas dos utilizadores, podendo depois ser classificados como funcionais ou no funcionais. A documentao produzida poder ter diferentes destinatrios e como tal diferentes objetivos. Podem-se distinguir trs tipos de especificao: Especificao de requisitos do usurio. Especificao de requisitos do sistema. Especificao do design da aplicao.
18

A vantagem de conceber mais do que uma especificao para um dado sistema a de em cada especificao se comunicar apenas um determinado tipo de informao adequado ao leitor a que se destina (usando "linguagens" que o utilizador conhea). Por exemplo, enquanto que nos requisitos do utilizador apenas feita uma abordagem de alto nvel das funcionalidades do sistema e suas restries, usando linguagem natural e eventualmente diagramas (esquemas), nos requisitos do sistema cada requisito descrito com mais detalhe introduzindo j alguns conceitos relativos arquitetura do sistema, fazendo-se uso de linguagens estruturadas (notaes grficas como diagramas de casos de uso). Requisitos do Usurio: Os requisitos do utilizador destinam-se, portanto, aos vrios nveis hierrquicos da organizao na qual o sistema ser implementado (desde gestores a utilizadores), pelo que so descritos usando apenas linguagem natural, formulrios e diagramas muito simples. Obviamente, neste nvel de especificao surgem algumas dificuldades: o Ambigidade: torna-se difcil descrever os requisitos de uma forma inequvoca sem tornar a sua descrio muito longa ou de difcil compreenso. o Confuso: ainda que possa no ser to relevante do ponto de vista do cliente, a distino entre requisitos funcionais/no-funcionais e objetivos do sistema torna-se difcil. o Agrupamento de requisitos: ao descrever as funcionalidades de um sistema, pode tornar-se difcil separar claramente os requisitos, o que leva a que vrios requisitos sejam expressos como sendo apenas um. Algumas consideraes teis a ter em conta ao escrever uma especificao de requisitos do utilizador: o Usar o mesmo formato em todos os requisitos (evitam-se omisses e facilita-se a verificao dos requisitos). o Distinguir claramente entre comportamentos esperados e desejveis do sistema atravs do uso de expresses como "O sistema permitir criar (...)" ou "Dever ser possvel criar (...)" respectivamente. importante deixar claro o que o sistema tem de fazer e sugestes de como o deve fazer e, acima de tudo, usar este tipo de expresses de forma consistente ao longo de todo o documento.

19

Usar formatao de texto para salientar determinados aspectos do documento (usando negrito, por exemplo).

Evitar usar termos demasiado tcnicos ou fora do mbito do sistema, identificando-os e definindo-os de uma forma clara quando for absolutamente necessrio us-los.

Requisitos do sistema: Os requisitos do sistema tm um carter mais tcnico, consistindo numa descrio detalhada dos requisitos do utilizador correspondentes recorrendo ao uso, para alm da linguagem natural, de linguagens estruturadas e notaes grficas. Estes requisitos destinam-se ainda aos utilizadores do sistema (e particularmente aos engenheiros que trabalhem nessa organizao) e destinam-se tambm s equipes de especificao de arquitetura do sistema e de desenvolvimento. Tal como nos requisitos do utilizador, o uso de linguagem natural levanta problemas, embora alguns deles sejam ligeiramente diferentes: o As mesmas palavras podem, de acordo com a interpretao de cada pessoa, designar conceitos diferentes. o O mesmo requisito pode ser descrito de formas diferentes, o que leva a que cada pessoa tenha de saber quando que descries diferentes se referem ou no a requisitos diferentes. Design de aplicao: Por fim, a especificao do design da aplicao consiste num documento usado pela equipe de desenvolvimento do sistema no qual esto definidos pormenores, a um nvel mais tcnico, acerca da implementao do sistema e sua arquitetura. A partir deste documento, um elemento que entre para a equipe de desenvolvimento a meio do projeto dever ser capaz de "se situar" quando precisar comear a codificar, compreendendo a forma como a implementao, a um nvel global, est a ser feita, mas sem conhecer necessariamente os detalhes de implementao dos componentes menores. No convm cair na tentao de deixar toda a implementao detalhada, uma vez que convm que os desenvolvedores tenham alguma margem de manobra tanto para inovar como para resolver problemas encontrados em subsistemas de forma que uma especificao inicial da arquitetura no consegue prever.

Sadas de um bom processo ajuda os usurios a explorarem e entenderem completamente seus requisitos, especialmente a separao entre o que eles querem e o que
20

realmente precisam. Suas interaes com o engenheiro de software os ajudam a entender as restries que podem ser impostas ao sistema pela tecnologia, pelas prticas da prpria organizao ou por regulamentaes governamentais. Eles passam a entender as alternativas, tanto tecnolgicas quanto procedimentais, as escolhas que podem ser necessrias quando dois requisitos no podem ser totalmente satisfeitos, entendendo, na maioria das vezes, as implicaes das decises por eles tomadas durante o desenvolvimento de requisitos, criando poucas surpresas no momento de entrega do sistema. Os usurios passam a compartilhar com o engenheiro de software uma viso dos problemas que esto tentando resolver, dos tipos de solues possveis e se sentem um pouco donos dos produtos gerados pela extrao, sentem-se satisfeitos, informados e acreditam que o risco minimizado. Similarmente, os engenheiros e desenvolvedores de software que participaram do processo de extrao de requisitos tm confiana de que esto resolvendo o problema certo e se convencem de que esto resolvendo o problema vivel sob todos os aspectos, no somente tcnicos, mas tambm humanos. Sabem que os usurios iro cooperar se for necessrio novos esclarecimentos e que essas interaes sero mnimas. Sadas de um Processo Ruim o pior resultado de um processo de extrao de requisitos mal feito que os desenvolvedores podero estar resolvendo o problema errado. Mesmo que os desenvolvedores estejam resolvendo essencialmente o problema certo, um processo de extrao ruim pode trazer outras conseqncias negativas. Compradores e usurios podem ficar insatisfeitos (acontecem freqentemente quando os desenvolvedores no ouvem os usurios ou tendem a forar suas prprias vises e interpretaes), resultando numa participao menos efetiva por parte dos compradores e usurios, resultando em respostas menos completas, podendo continuar afetando o projeto durante o desenvolvimento e entrega. Os desenvolvedores podem descobrir que h informaes importantes faltando, o que resulta em encontros adicionais, podem tomar decises erradas devido falta de entendimento das reais necessidades. Os requisitos podem mudar freqentemente, resultando em demoras ou esforos desperdiados nas fases de projeto e implementao, resultando num custo maior, atraso no planejamento e algumas vezes, projetos cancelados. Tudo isso pode resultar numa perda de dinheiro, tanto para a empresa a que pertencem os desenvolvedores, como para os compradores, m reputao e perda de credibilidade dos desenvolvedores, alm de uma queda na confiana dos prprios desenvolvedores em si mesmos

21

Validao
Nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, o sistema que o cliente necessita. semelhana do que sucede na anlise dos requisitos, pretende-se encontrar problemas/conflitos na especificao, porm ao contrrio das fases anteriores esta fase lida com uma especificao completa dos requisitos. A validao especialmente importante em sistemas de grandes dimenses porque muitas vezes so encontrados erros (durante o desenvolvimento ou j depois de o sistema estar sendo usado) no documento de requisitos, e esses erros tm repercusses proporcionais dimenso do projeto. Estes tipos de erros traduzem-se em elevados custos e necessidade de refazer muito do trabalho que se julgava j concludo. Durante a fase de validao dos requisitos, devem ser verificados (atravs de checklists) os seguintes atributos dos requisitos:

Validade: a especificao resulta da anlise dos requisitos identificados junto das diversas partes interessadas envolvidas. Como tal, requisitos identificados individualmente (isto , junto de cada parte interessada) podem diferir da especificao final que se atinge aps o cruzamento de informao e necessrio que cada cliente compreenda e aceite a especificao final obtida.

Consistncia: no devem existir conflitos entre os requisitos identificados. Compreensibilidade/Ambigidade: os requisitos devem poder ser compreendidos de forma inequvoca pelas partes interessadas.

Completude: todas as funcionalidades pretendidas devem fazer parte da especificao do sistema.

Realismo: dadas s restries do projeto (tecnolgicas, financeiras e temporais) o sistema especificado tem de ser implementvel.

Verificabilidade: de forma a evitar futuras discordncias quanto concretizao dos requisitos especificados, estes devem ser descritos de modo a que seja possvel verificar se foram ou no concretizados, isto , se o sistema final corresponde especificao inicial.

Rastreabilidade: a origem dos requisitos, em relao ao cliente, deve estar claramente identificada. Entre outros motivos, isto importante para facilitar a gesto futura dos requisitos.
22

Conformidade com normas: para alm dos aspectos funcionais dos requisitos, a sua especificao deve obedecer s normas usadas ao longo de todo o documento. A fase de validao no deve ser encarada de nimo leve: trata-se de uma fase

muito importante na engenharia de requisitos e da qual dependem elevados custos a mdio e longo prazo. Por depender bastante dos retornos transmitidos pelos clientes (que no so peritos em validao de requisitos) bastante falvel e regra geral h erros que no so encontrados num primeiro momento, o que leva inevitavelmente a discordncias numa fase posterior, j com o documento validado e o projeto em desenvolvimento ou concludo. Quando isto sucede, torna-se necessrio negociar e chegar a um acordo quanto forma de corrigir o erro detectado.

UML Linguagem de Modelagem Unificada

A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) uma linguagem visual utilizada para modelar sistemas computacionais por meio do paradigma de orientao a objetos. Essa linguagem tornou-se, nos ltimos anos, a linguagem padro de modelagem de Software adotada internacionalmente pela indstria de Engenharia de Software. Deve ficar bem claro, no entanto, que a UML no uma linguagem de programao e sim uma linguagem de modelagem, cujo objetivo auxiliar os engenheiros de Software a definir as caractersticas do Software, tais como seus requisitos, seu comportamento, sua estrutura lgica, a dinmica de seus processos e at mesmo suas necessidades fsicas em relao ao equipamento sobre o qual o sistema dever ser implantado. Todas essas caractersticas so definidas por meio da UML antes do Software comear a ser realmente desenvolvido. Atravs da UML podemos modelar um sistema utilizando vrios diagramas, nos quais podemos destacar dois grandes grupos: Modelagem Estrutural o Diagrama de Classes o Diagrama de Objetos o Diagrama de Componentes o Diagrama de Estrutura Composta o Diagrama de Pacotes
23

o Diagrama de Implantao Modelagem Comportamental (Temporal) o Diagrama de Casos de Uso o Diagrama de Atividades o Diagrama de Transio de Estados o Diagrama de Mquina de Estados o Diagramas de Interao Geral o Diagramas de Interao entre Objetos Diagrama de Sequncia Diagrama de Comunicao Diagrama de Tempo Diagrama de Comunicao A UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que so conhecidos como "os trs amigos". Eles possuem um extenso conhecimento na rea de modelagem orientado a objetos j que as trs mais conceituadas metodologias de modelagem Orientada a Objetos foram eles que desenvolveram e, a UML a juno do que havia de melhor nestas trs metodologias adicionado novos conceitos e vises da linguagem. A UML o resultado da unificao da linguagem de modelagem de objetos de 3 mtodos lderes do mercado: Booch, Object Modeling Technique (OMT) e ObjectedOriented Software Engineering (OOSE). Em 1997, a UML v1.1 foi adotada pela OMG (Object Management Group) e desde ento tornou-se o padro da indstria de Software para a modelagem de objetos e componentes.

24

Um processo para utilizar a UML

A UML contm notaes e regras que tornam possvel expressar modelos orientados a objetos. Mas ela no prescreve como o trabalho tem que ser feito, ou seja, no possui um processo de como o trabalho tem que ser desenvolvido. J que a UML foi desenvolvida para ser usada em diversos mtodos de desenvolvimento. Para usar a UML com sucesso necessrio adotar algum tipo de mtodo de desenvolvimento, especialmente em sistema de grande porte onde a organizao de tarefas essencial. A utilizao de um processo de desenvolvimento torna mais eficiente calcular o progresso do projeto, controlar e melhorar o trabalho. Um processo de desenvolvimento descreve "o que fazer", "como fazer", "quando fazer", e "porque deve ser feito". Este tambm descreve um nmero de atividades que devem ser executadas em uma certa ordem. Quando so definidas e relacionadas as atividades de um processo, um objetivo especfico alcanado. Em seu uso normal, a palavra "processo" significa uma relao de atividades que devem ser executadas em uma certa ordem sem importar o objetivo, regras ou material a ser usado. No processo de desenvolvimento da engenharia de software, necessrio saber o objetivo final do processo, definir regras a serem seguidas e adotar um mtodo fixo de desenvolvimento. Um mtodo (processo) tradicional de desenvolvimento orientado a objetos dividido em anlise de requisitos, anlise, design (projeto), implementao, e testes. A anlise de requisitos captura as necessidades bsicas funcionais e no-funcionais do sistema que deve ser desenvolvido. A anlise modela o problema principal (classes, objetos) e cria um modelo ideal do sistema sem levar em conta requisitos tcnicos do sistema. O design expande e adapta os modelos da anlise para um ambiente tcnico, onde as solues tcnicas so trabalhadas em detalhes. A implementao consiste em codificar em linguagem de programao e banco de dados os modelos criados. E as atividades de testes devem testar o sistema em diferentes nveis, verificando se o mesmo corresponde as expectativas do usurio. Existe um processo desenvolvido pela Rational Inc., mesma empresa que desenvolveu a UML, que monta duas vises do desenvolvimento de um sistema: viso gerencial e tcnica. A viso tcnica utiliza as tradicionais atividades de anlise, design e implementao, enquanto a viso gerencial utiliza as seguintes fases no desenvolvimento de cada gerao do sistema.
25

Incio: Define o escopo e objetivo do projeto; Elaborao: Desenvolve o produto em detalhes atravs de uma srie

de interaes. Isto envolve mais anlise, design e programao;

Transio: Gera o sistema para o usurio final, incluindo as

atividades de marketing, suporte, documentao e treinamento. Cada fase no ciclo executada em sries de interaes que podem sobrepor outras fases. Cada interao consiste tipicamente em atividades tradicionais como anlise e design, mas em diferentes propores dependendo da fase em que esteja a gerao do sistema em desenvolvimento. Ferramentas modernas devem dar suporte no apenas para linguagens de modelagem e programao, mas devem suportar um mtodo de desenvolvimento de sistemas tambm. Isso inclui conhecimento das fases em um processo, ajuda online, e aconselhamentos do que fazer em cada fase do desenvolvimento, suporte a desenvolvimento interativo e fcil integrao com outras ferramentas.

O Futuro da UML
Embora a UML defina uma linguagem precisa, ela no uma barreira para futuros aperfeioamentos nos conceitos de modelagem. O desenvolvimento da UML foi baseado em tcnicas antigas e marcantes da orientao a objetos, mas muitas outras influenciaro a linguagem em suas prximas verses. Muitas tcnicas avanadas de modelagem podem ser definidas usando UML como base, podendo ser estendida sem se fazer necessrio redefinir a sua estrutura interna. A UML ser a base para muitas ferramentas de desenvolvimento, incluindo modelagem visual, simulaes e ambientes de desenvolvimento. Em breve ferramentas de integrao e padres de implementao baseados em UML estaro disponveis para qualquer um. A UML integrou muitas idias adversas, e esta integrao vai acelerar o uso do desenvolvimento de softwares orientados a objetos.

Abstrao
O uso do computador baseado em abstraes, que nada mais do que uma representao simplificada da realidade, segundo um ponto de vista especfico. Na orientao a objetos o principal mecanismo de abstrao a Classe. Abstrao nada mais
26

do que, a grosso modo, interpretao, ou seja, conseguir enxergar informaes que esto subentendidas.

Exemplo de Abstrao

Classes
Conceitualmente, uma classe descreve um conjunto de objetos que compartilham caractersticas comuns. Uma classe implementa um Tipo Abstrato de Dados, e encapsula esses dados e suas operaes. Classe a definio de um conjunto de objetos que compartilham estruturas e comportamentos comuns, sendo a sua abstrao muito importante, dizendo respeito s informaes extradas em um levantamento de requisitos, por exemplo. Assim as classes podem ser entendidas como descries genricas ou coletivas de entidades do mundo real. Mantm-se aqui a inteno de aproximar entidades externas de representaes internas. Desta forma, a definio das classes de um sistema dever procurar inspirao nas entidades do mundo real.

Exemplo de Classe

Objetos
Um objeto um elemento que podemos manipular, acompanhar seu comportamento, criar, destruir etc. Um objeto existe no mundo real. Pode ser uma parte de qualquer tipo de sistema, por exemplo, uma mquina, uma organizao, ou negcio. Existem objetos que no encontramos no mundo real, mas que podem ser vistos de derivaes de estudos da estrutura e comportamento de outros objetos do mundo real. Um objeto um elemento da classe
27

o Objeto deve pertencer a somente uma classe o O objeto o elemento que efetivamente armazena as informaes de um programa. Objetos trocam mensagens entre si o O funcionamento de um programa OO caracterizado pela troca de mensagens de objetos criados

Exemplos de Objetos

Instanciao
Instanciao trata-se apenas da criao um objeto a partir de uma classe j definida, isto , instanciamos um objeto a partir de uma classe. Deve-se ressaltar que Instncias (Objetos) de uma mesma classe possuem caractersticas idnticas, variando os valores que essas caractersticas podem assumir. Ex: Todos os objetos de uma classe carro possuem uma caracterstica comum que cor, mas um pode ter o valor para essa caracterstica igual a Azul e outro Preto.

Exemplo de Instanciao

Encapsulamento
Encapsular significa Proteger dados, ou informaes de um objeto, atravs de mtodos, que garantem acesso seguro informao armazenada nesses objetos.
28

Ocultamento da Informao o O acesso aos dados internos de objetos s pode ocorrer a partir de mensagens.

Independncia de aplicao o Um mtodo deve acessar informaes internas do objeto. Na necessidade de outra informao, somente atravs de mensagens.

Exemplo de Encapsulamento

Encapsulamento - Muralha em volta do objeto

Mtodos
Mtodos ou comportamentos representam atividades que objetos de uma classe podem executar. um conjunto de instrues que executado quando chamado, por exemplo, um objeto da classe carro pode executar a atividade de transportar pessoas (mtodo). Grande parte da codificao propriamente dita dos sistemas de informao orientados a objetos esta contida nos mtodos definidos em suas classes.

Exemplo de Mtodo

29

Herana
Herana o reaproveitamento de atributos e mtodos, otimizando o tempo de desenvolvimento. uma das caractersticas mais poderosas e importantes da orientao a objetos, porque permite a diminuio de linhas de cdigo. Quando temos herana, a classe que fornece a herana chamada de SuperClasse, e a que recebe a herana chamada de SubClasse. Quando uma SubClasse herda os atributos e operaes de outra, ela herda todos. O que faz a diferena a visibilidade, que veremos mais adiante.

Exemplo de Herana

Herana Mltipla
Ocorre quando uma SubClasse herda caractersticas e mtodos de duas ou mais SuperClasses.

Exemplo de Herana Mltipla

Polimorfismo
O conceito de polimorfismo est associado herana. O polimorfismo trabalha com a redeclararo de mtodos herdados por uma classe. Esses mtodos, embora semelhantes, diferem de alguma forma da implementao utilizada na SuperClasse, sendo necessrio, portanto, reimplement-los na SubClasse. O conceito polimorfismo muito semelhante ao conceito de variveis locais e globais, utilizado pela linguagem de programao C. Ao declararmos uma varivel global
30

em um programa escrito na linguagem C, essa varivel poder ser vista e utilizada por qualquer outra funo do programa, no entanto se em alguma funo declararmos uma varivel local com o mesmo nome da varivel global, naquela funo especfica, quando nos referirmos varivel em questo ser varivel local e no global. O mesmo ocorre com os mtodos polimrficos, ou seja, supondo existirem diversas SubClasses que herdem um mtodo de uma SuperClasse, se uma delas redeclarar este mtodo, ele s se comportar de maneira diferente nos objetos da classe que o modificou, permanecendo igual forma como foi implementado na SuperClasse para os objetos de todas as outras classes.

Exemplo de Polimorfismo

Diagramas da UML
Poderamos nos perguntar: Porque a UML composta de tantos diagramas? O objetivo disto fornecer mltiplas vises do sistema a ser modelado, analisando-o e modelando-o sob diversos aspectos, procurando-se assim alcanar a completitude da modelagem, permitindo que cada diagrama complete os outros. Cada diagrama da UML analisa o sistema, ou parte dele, sob uma determinada tica, como se o sistema fosse modelado em camadas, sendo que alguns diagramas enfocam o sistema de forma mais geral, apresentando uma viso mais externa do sistema, como o objetivo do diagrama de casos de uso, enquanto outros oferecem uma viso de uma camada mais profunda do Software, apresentando um enfoque mais tcnico ou ainda visualizando apenas uma caracterstica especfica do sistema ou um determinado processo. A utilizao de diversos diagramas permite que falhas sejam descobertas, diminuindo a possibilidade da ocorrncia de erros futuros.

31

Diagramas UML

Diagrama de Casos de Uso

O diagrama de casos de uso procura, por meio de uma linguagem simples, possibilitar a compreenso do comportamento externo do sistema por qualquer pessoa, tentando apresentar o sistema atravs de uma perspectiva do usurio. , dentre todos os diagramas da UML o mais abstrato e, portanto o mais flexvel e informal. O diagrama de casos de uso costuma ser utilizado principalmente no incio da modelagem do sistema, principalmente nas etapas de levantamento e anlise de requisitos, embora venha a ser consultado e possivelmente modificado durante todo o processo de engenharia e sirva de base para a modelagem de outros diagramas. Este diagrama tem por objetivo apresentar uma viso externa geral das funes e servios que o sistema dever oferecer aos usurios, sem se preocupar em como essas funes sero implementadas. O diagrama de casos de uso de grande auxlio na etapa de anlise de requisitos, ajudando a especificar, visualizar e documentar as caractersticas, funes e servios do sistema desejados pelo usurio. O diagrama de casos de uso tenta identificar os tipos de usurios que iro interagir com o sistema, quais os papis que esses usurios iro assumir e quais funes sero requisitadas por cada usurio especfico. Por utilizar uma linguagem informal e apresentar uma viso geral do comportamento do sistema a ser desenvolvido, o diagrama de casos de uso pode e deve ser apresentado durante as reunies iniciais com os clientes como uma forma de ilustrar o comportamento do sistema de informao, facilitar o entendimento dos usurios e auxiliar na identificao de possveis falhas de especificao. bastante til e recomendvel que
32

um diagrama de casos de uso seja apresentado aos clientes juntamente com um prottipo, que permitir que um complete o outro.
Atores

Atores so representaes de entidades externas, mas que interagem com o sistema durante sua execuo. Basicamente, a interao de atores com o sistema d-se atravs de comunicaes (troca de mensagens). As entidades externas representadas pelos atores podem ser: Pessoas: usurio, secretria, aluno, professor, administrador, etc. Dispositivos: impressora, mquina ou outro equipamentos externo. Hardwares: placa de modem, placa de controle, etc. Software: sistema de banco de dados, aplicativos, etc. E importante observar que atores representam, na verdade, papis desempenhados por pessoas, dispositivos ou outros Softwares quando estiverem interagindo com o sistema. Por exemplo, um ator cujo identificador seja Aluno no representa um aluno especfico, mas sim um aluno qualquer, ou seja, uma pessoa qualquer que esteja interagindo com o sistema na qualidade de aluno. Desta forma, um ator pode representar um entre vrios indivduos, equipamentos ou Softwares. De forma anloga, uma entidade externa pode ser representada na forma de vrios atores. Isto ocorre quando a entidade tem mais de um papel (tipo de participao ou interao) no sistema. Por exemplo, o indivduo Joo da Silva poderia ser representado em um sistema na forma do ator Usurio, pois ele interage com o sistema nesta qualidade, e tambm na forma do ator Administrador, pois ele tambm interage com o sistema para este outro fim que a administrao do Software.

Exemplos de Atores

33

Casos de Uso

A descrio dos servios a serem oferecidos pelo sistema feita na UML discriminando-se os Casos de Usos do sistema. Cada Caso de Uso descreve uma aplicao ou uso completo do Software. O conceito de caso de uso no deve ser confundido com o de mdulo j que um caso de uso no um componente do sistema, mas sim um de seus empregos possveis. Tambm no se deve confundir o conceito de caso de uso com o de funo que possui um escopo muito mais limitado, traduzindo frequentemente apenas um recurso ou utilidade do sistema. Um caso de uso muito mais abrangente, envolvendo todo um conjunto de transaes que juntas constituem um servio completo oferecido pelo sistema. A especificao das funcionalidades de um sistema na forma de casos de uso permite uma viso mais abrangente das aplicaes do sistema, favorecendo um levantamento mais completo e preciso de suas atribuies.

Exemplos Caso de Uso

Associao (Interao)

As associaes representam as interaes ou relacionamentos entre os atores que fazem parte do diagrama, entre os atores e os casos de uso, ou os relacionamentos entre os casos de uso e outros casos de uso. Os relacionamentos entre os casos de uso recebem nomes especiais como Incluso, Extenso e Generalizao. Uma Associao entre um ator e um caso de uso demonstra que o ator utiliza-se, de alguma maneira, da funo do sistema representada pelo caso de uso em questo, seja requisitando a execuo daquela funo, seja recebendo o resultado produzido por ela a pedido de outro ator.
Relacionamento entre Atores

Como os atores so entidades externas, os relacionamentos entre eles sero relaes externas ao sistema. Embora estas relaes possam ser desprezadas, pois no fazem parte do sistema e nem so de conhecimento do sistema, possvel inclu-las no modelo de casos de uso. De certa forma, estas relaes descrevem parte do modelo de negcios da empresa.

34

Exemplos de Relacionamentos entre atores

Relacionamento entre Atores e casos de uso

O relacionamento entre um ator e um caso de uso expressa sempre uma comunicao entre eles, pois o ator sendo uma entidade externa no poderia possuir qualquer relacionamento estrutural com o sistema computacional. A notao UML para este tipo de relacionamento um segmento de reta ligando ator e caso de uso. Em diagramas mais complexos pode-se utilizar cadeias de segmentos de retas para se evitar cruzamentos. Como atores podem ter vrios propsitos, no que diz respeito a suas interaes com o sistema, podem existir mais de um relacionamento de um ator com diferentes casos de usos. De forma anloga, um mesmo caso de uso pode envolver a participao de mais de um ator. O caso de uso Emitir Histrico Escolar envolve a participao de dois atores: Secretaria e Impressora. O ator Secretaria participa em dois casos de uso: Emitir Histrico e Registrar Novo Aluno.

Exemplo Relacionamento Ator / Caso de Uso

Relacionamento entre casos de uso e outros casos de uso

Ao contrrio do relacionamento entre ator e caso de uso, as relaes entre casos de uso nunca sero do tipo comunicao. Isto ocorre porque casos de uso so aplicaes completas do sistema e, por consequncia, no existe sentido em fazer-se comunicar dois
35

usos do sistema. Todas as relaes entre casos de uso sero sempre estruturais. Existem trs tipos de relaes entre casos de uso (incluso, extenso e generalizao) conforme descritos a seguir. Incluso (<<Include>>) A associao de incluso costuma ser utilizada quando existe um servio, situao ou rotina comum a mais de um caso de uso. Quando isso ocorre documentao dessa rotina colocada em um caso de uso especfico para que outros casos de uso utilizem-se desse servio, evitando descrever uma mesma seqncia de passos em vrios casos de uso. Os relacionamentos de incluso indicam obrigatoriedade de execuo.

Exemplo de Relacionamento de Incluso Extenso (<<Extends>>) Associaes de extenso so utilizadas para descrever cenrios opcionais de um caso de uso. Eles descrevem cenrios que somente ocorrero em uma situao especfica, se uma determinada condio for satisfeita. Representam eventos que no ocorrem sempre, ou seja, so incomuns, no obrigatrios.

Exemplo de Relacionamento de Extenso

36

Restries em Associaes de Extenso Restries so compostas por um texto entre chaves e so utilizadas para definir validaes, consistncias, condies etc., que devem ser aplicadas a um determinado componente ou situao. s vezes, no fica claro qual a condio para que um caso de uso estendido seja executado, assim, pode-se acrescentar uma restrio associao de extenso por meio de uma nota explicativa, determinando a condio para que o caso de uso seja executado.

Exemplo de Extenso com Restrio Generalizao Este relacionamento uma forma de Associao entre casos de uso na qual existem dois ou mais casos de uso com caractersticas semelhantes, apresentando pequenas diferenas entre si. Quando tal situao ocorre, costuma-se definir um Caso de Uso Geral, que descreve as caractersticas compartilhadas por todos os casos de uso em questo, e ento relacion-lo com estes, cuja documentao conter somente as caractersticas especificas de cada um. Assim no ser necessrio colocar a mesma documentao para todos os casos de uso envolvidos, porque toda a estrutura de um Caso de Uso generalizada herdada pelos Casos de Uso Especializados, incluindo quaisquer possveis Associaes.

Exemplo de Relacionamento de Generalizao

37

Documentao de Casos de Uso

A documentao de um caso de uso costuma descrever, por meio de uma linguagem bastante simples, a funo em linhas gerais do caso de uso, destacando quais atores interagem com ele, quais etapas devem ser executadas pelo ator e pelo sistema para que o caso de uso execute sua funo, quais parmetros devem ser fornecidos e quais restries e validaes o caso de uso deve possuir. No existe um formato especfico de documentao para casos de uso definido pela UML, o que est de acordo com a caracterstica do prprio diagrama, ou seja, o formato de documentao de um caso de uso bastante flexvel, permitindo que se documente o caso de uso da forma que se considerar melhor. Os casos de uso podem tambm ser documentados por meio de outros diagramas, como o Diagrama de Sequncia ou o Diagrama de Atividade.

Descrio dos Casos de uso

Descrio do Caso de Uso so narrativas de texto do Caso de Uso. Elas usualmente tomam a forma de uma nota ou um documento que de alguma maneira ligada ao Caso de Uso, e explana o processo ou atividades que tomaro lugar no Caso de Uso.

Descrio dos atores

Descrio dos atores narrativa de texto descrevendo suas funes e suas interaes em relao ao sistema.

Detalhamento dos casos de uso

Tabela descritiva contendo todas as informaes e interaes do caso de uso que descrevem ainda os fluxos de atividade entre o sistema e o usurio. Nome do Caso de Uso Caso de Uso Geral Coloque um nome adequado para o Caso de Uso Se for um caso de uso generalizado, colocar o nome do caso de uso mais geral Descrio Pr Condies Ps Condies Atores Descreva detalhadamente o propsito do caso de uso Se existir uma ou mais pr condies, descreva-as aqui Se existir uma ou mais ps condies, descreva-as aqui. Liste os atores que se relacionam com este caso de uso Fluxo Principal Aes Recebidas Aes Realizadas

1. O ator X inicia a fluxo 2. O processo recebe a entrada, avalia e principal (ou fluxo timo). envia ao controle.
38

3. O controle trata a informao. 4. Aps tratar a informao os dados so apresentados ao ator. Fluxo Alternativo N Aes Recebidas O ator X inicia a fluxo alternativo N (ou fluxo de erro, ou fluxo opcional, etc). Aes Realizadas O processo recebe a entrada, avalia e envia ao controle. O controle trata a informao. Aps tratar a informao os dados so apresentados ao ator.

Diagrama de Classes
O diagrama de classes , com certeza, o mais importante e mais utilizado diagrama da UML. Seu principal enfoque est em permitir a visualizao das classes que comporo o sistema com seus respectivos atributos e mtodos, bem como em demonstrar como as classes do diagrama se relacionam, complementam e transmitem informaes entre si. Esse diagrama apresenta uma viso esttica de como as classes esto organizadas, preocupandose em como definir a estrutura lgica das mesmas. O diagrama de classe serve ainda como base para a construo da maioria dos outros diagramas da linguagem UML. Basicamente o diagrama de classes composto por suas classes e pelas associaes existentes entre elas, ou seja, os relacionamentos entre as classes. Nesse diagrama a abstrao de cada classe com seus atributos e mtodos individualmente corresponde modelagem de vocabulrio, onde so definidas as classes do sistema. no diagrama de classes que comeamos a sair da parte exclusivamente de negcios e passamos a tornar realidade automatizao do negcio desejado

Exemplo de uma Classe

39

Responsabilidade
Uma classe sempre deve versar sobre um mesmo assunto. Uma classe encapsula um dado conhecimento sobre algo. No faz sentido inserirmos, em uma classe que trata de apartamentos, dados sobre a imobiliria ou atrasos de pagamento da hipoteca so assuntos diferentes, portanto, classes diferentes! Uma classe tem responsabilidade por tudo o que lhe diz respeito. Sua responsabilidade resumida em seus atributos e mtodos. No de responsabilidade de um proprietrio incluir um apartamento, responsabilidade da prpria classe fazer essa incluso.

Componentes
Atributos

Classes costumam definir atributos, tambm conhecidos como propriedades. Os atributos representam as caractersticas de uma classe, ou seja, as peculiaridades que costumam variar de objeto para objeto, como a altura de um OBJETO da classe pessoa ou a cor de um OBJETO da classe carro e que permitem diferenciar um objeto de outro da mesma classe devido a essas variaes. Os atributos normalmente possuem duas informaes: O Nome que o identifica e o tipo de dado que ele armazena (Ex.: Integer, Float, Caracter, etc.). Essa ltima informao no obrigatria, mas bastante til e recomendvel.

Exemplo de Atributos
Operaes (Mtodos)

Os mtodos implementam operaes a serem executadas pelas classes. Assim temos em sua estrutura: Nome do Mtodo: definido por uma cadeia de caracteres que identificam exclusivamente o mtodo dentro da classe. Sugere-se o emprego unicamente de
40

letras comeando-se por uma letra maiscula e concatenando-se palavras mantendo a primeira letra em maisculo. Exemplo: CalcularValor, ArmazenarDados Parmetros: so variveis definidas junto aos mtodos e que so utilizadas pelos mtodos para recebimento de valores no momento da ativao. Os parmetros podem tambm ser utilizados para retorno de valores aps a execuo do mtodo. Cada parmetro especificado usando a notao: Nome do Parmetro:Tipo=Valor Padro O Nome do Parmetro uma cadeia de caracteres que identifica o parmetro dentro do mtodo. Tipo um especificador de tipo de dado padro da linguagem de programao. Valor Padro a especificao de uma constante cujo valor ser atribudo ao parmetro se em uma chamada ao mtodo no for especificado um valor para o parmetro. Exemplo: CalcularValor( val1:int, val2:float=10.0) ArmazenarDados( nome:char[30], salario:float=0.0) Valor de Retorno: indica se o mtodo retorna algum valor ao trmino de sua execuo e qual o tipo de dado do valor retornado. Pode-se utilizar aqui os tipos padres da linguagem de programao que se pretende utilizar ou novos tipos definidos no projeto (inclusive classes). Exemplo: CalcularValor():int // retorna um valor inteiro ArmazenarDados(nome:char[30]): bool // retorna verdadeiro ou falso

Exemplo de Mtodos
41

Visibilidade

A visibilidade utilizada para indicar o nvel de acessibilidade de um determinado atributo ou mtodo. Existem basicamente trs modos de visibilidade: Visibilidade pblica: representada por um smbolo de ( + ) apresentado antes da descrio do atributo ou mtodo e significa que o atributo ou mtodo pode ser utilizado por qualquer classe; Visibilidade protegida: representada pelo smbolo de sustenido ( # ) e determina que somente a classe possuidora do atributo ou mtodo ou suas sub-classes podem ter acesso ao mesmo. Atributo ou mtodo privado representado por um sinal de menos ( - ) e significa que somente a classe possuidora do atributo ou mtodo pode utiliz-lo.

Exemplo de Visibilidade

Relacionamentos
As classes costumam possuir relacionamentos entre si, com o intuito de compartilhar informaes e colaborarem umas com as outras para permitir a execuo dos diversos processos executados pelo sistema.

Associaes
Uma associao descreve um vnculo que ocorre normalmente entre duas classes, chamado nesse caso de associao binria, mas perfeitamente vlido que uma classe esteja vinculada a si mesmo, caso conhecido como associao unria, ou que uma mesma associao seja compartilhada por vrias classes, o que conhecida como associao ternria ou n-ria, embora esta ltima seja o tipo de associao mais raro e complexo. Em uma associao, determina-se que as instncias de uma classe esto de alguma forma, ligadas s instncias das outras classes envolvidas na associao, podendo haver
42

troca de informaes entre elas e compartilhamento de mtodos, ou mesmo que uma determinada instncia de uma das classes origine uma ou mais instncias nas outras classes envolvidas nas associaes. Uma associao pode ainda identificar algum nvel de dependncia entre as classes que a compem. As associaes representam o equivalente mais prximo dos relacionamentos utilizados no modelo entidade-relacionamento, ou seja, seu objetivo definir a maneira como as classes esto unidas e interagem entre si, compartilhando informaes. As associaes so representadas por retas ligando as classes envolvidas, possuindo ou no setas em suas extremidades para indicar a navegabilidade da associao. Pode-se tambm definir uma descrio para a associao (Papel) para determinar o vnculo estabelecido entre as classes. Unria (Reflexiva) (Recursiva): ocorre quando existe um relacionamento de uma classe para consigo mesma.

Exemplo de associao unria Binria: um tipo de associao muito comum, ocorre quando so identificados relacionamentos entre duas classes.

Exemplo de associao Binria

43

Multiplicidade

Significado No mnimo Zero e no mximo Um. Indica que os objetos das classes associadas no preciso obrigatoriamente estar relacionados, mas se houver relacionamento indica que apenas uma instncia da classe se relaciona com as instncias da outra classe. Um e somente Um. Indica que apenas um objeto da classe se relaciona com os objetos da outra classe. No mnimo Zero e no mximo Muitos. Indica que pode ou no haver instncias da classe participando do relacionamento. Muitos. Indica que muitos objetos da classe esto envolvidos no relacionamento. No mnimo Um no mximo Muitos. Indica que h pelo menos um objeto envolvido no relacionamento podendo haver muitos envolvidos. No mnimo Trs e no mximo Cinco. Indica que existem pelo menos trs instncias envolvidas no relacionamento e que podem ser quatro ou cinco as instncias envolvidas, no mais que isso.

0..1

1..1

0..*

1..*

3..5

Ternria (N-ria): so associaes que conectam trs ou mais classes. So representadas por um losngo para onde convergem todas as ligaes da associao.

Exemplo de associao N-ria Multiplicidade: procura determinar qual das classes envolvidas em uma associao fornece informaes para as outras, alm de permitir especificar o nvel de dependncia de uma classe para com as outras classes envolvidas na associao. A multiplicidade extremamente semelhante ao conceito de cardinalidade utilizado no modelo entidade-relacionamento. Agregao: um tipo especial de associao onde tenta-se demonstrar que as informaes de um objeto (chamado objeto-todo) precisam ser complementadas
44

pelas informaes contidas em um ou mais objetos de outra classe (chamado objeto-parte). Este tipo de associao tenta demonstrar uma relao todo/parte entre os objetos associados. Objeto-parte no pode ser destrudo por um objeto diferente do objeto-todo. O smbolo de agregao difere do de associao por conter um losngulo na extremidade da classe que contm o objeto-todo. A agregao fornece tambm um canal de comunicao entre o objeto-todo e o objeto-parte. Note que esta comunicao unidirecional do objeto-todo para o objeto-parte. O objeto-parte no conhece, a princpio, o objeto-todo. Desta forma, ele no pode comunicar-se com o objeto-todo.

Exemplo de agregao

Exemplo da notao de agregao Composio (Agregao Forte): representa um vnculo mais forte entre os objetos todo e os objetos parte, demonstra que os objetos parte tem de pertencer exclusivamente a um objeto todo com que se relaciona. Os objetos parte no podem viver quando o objeto todo destrudo.

Exemplo de composio Especializao/Generalizao (Herana): este um tipo especial de

45

relacionamento muito similar associao de mesmo nome utilizado no Diagrama

de Casos de Uso. Seu objetivo identificar classes-me, chamadas gerais e classesfilhas, chamadas especializadas. Este tipo de relacionamento permite tambm demonstrar a ocorrncia de mtodos polimrficos nas classes especializadas do sistema. Como no Diagrama de Casos de Uso a especializao/generalizao ocorre quando existem duas ou mais classes com classes com caractersticas muito semelhantes, assim para evitar ter que declarar atributos e/ou mtodos idnticos e como uma forma de reaproveitar cdigo, cria-se uma classe geral onde so declarados os atributos e mtodos comuns a todas as classes envolvidas no processo e ento declaram-se classes especializadas ligadas classes geral, que herdam todas as suas caractersticas podendo possuir atributos e mtodos prprios. Alm disso, mtodos podem ser redeclarados em uma classe especializada, possuindo o mesmo nome, mas comportando-se de forma diferente, no sendo, portanto necessrio modificar o cdigo fonte do sistema com relao s chamadas de mtodos das classes especializadas, porque o nome do mtodo no mudou apenas foi redeclarado em uma classe especializada e s se comportar de maneira diferente quando for chamado por objetos desta classe. Uma estrutura de generalizao/especializao implica herana: um filho herda dados do pai como cor dos olhos e cor da pele. Uma estrutura todo-parte no possui herana: um brao parte do pai, como suas pernas, mas no h herana nesses casos.

Exemplo de generalizao/especializao
46

Dependncia: identifica certo grau de dependncia de uma classe em relao outra, isto , sempre que ocorrer uma mudana na classe na qual uma outra classe depende, esta tambm dever sofrer uma mudana. O relacionamento de dependncia representado por uma seta tracejada entre duas classes contendo uma seta apontando a classe independente e na outra extremidade est a classe dependente.

Exemplo de Relao de Dependncia

Classe Associativa
Classes associativas so classes produzidas quando da ocorrncia de associaes que possuem multiplicidade muitos pra muitos. Elas so necessrias nesses casos porque no existe um repositrio que possa armazenar informaes produzidas pelas associaes j que todas as classes envolvidas apresentam multiplicidade muitos e isto obriga que seu atributo chave seja transmitido s outras classes envolvidas e como todas possuem a mesma multiplicidade, nenhuma delas pode receber os atributos das outras, assim preciso criar uma classe associativa para armazenar os atributos transmitidos pela associao, o que no impede que a classe associativa possua atributos prprios, alm dos recebidos.

Exemplo de Classe Associativa

47

Diagrama de Objetos
O diagrama de objetos uma variao do diagrama de classes e utiliza quase a mesma notao. A diferena que o diagrama de objetos mostra os objetos que foram instanciados das classes. O diagrama de objetos como se fosse o perfil do sistema em um certo momento de sua execuo. A mesma notao do diagrama de classes utilizada com duas excees: os objetos so escritos com seus nomes sublinhados e todas as instncias num relacionamento so mostradas. Os diagramas de objetos no so to importantes como os diagramas de classes, mas eles so muito teis para exemplificar diagramas complexos de classes ajudando muito em sua compreenso. Diagramas de objetos tambm so usados como parte dos diagramas de Comunicao, onde a colaborao dinmica entre os objetos do sistema so mostrados.

Diagrama de Mquina de Estados

O diagrama de mquina de estados tipicamente um complemento para a descrio das classes. Este diagrama mostra todos os estados possveis que objetos de classe podem se encontrar e mostra tambm quais so os eventos dos sistemas que provocam tais mudanas. Os diagramas de estado no so escritos para todas as classes de um sistema, mas apenas para aquelas que possuem um nmero definido de estados conhecidos e onde o comportamento das classes afetado e modificado pelos diferentes estados. Este diagrama demonstra o comportamento de um elemento por meio de um conjunto de transies de estado. O elemento modelado muitas vezes uma instncia de
48

uma classe, no entanto, pode-se usar esse diagrama para modelar o comportamento de um caso de uso ou mesmo o comportamento de um sistema completo Diagramas de mquinas de estados capturam o ciclo de vida dos objetos, subsistemas e sistemas. Eles mostram os estados que um objeto pode possuir e como os eventos (mensagens recebidas, timer, erros, e condies sendo satisfeitas) afetam estes estados ao passar do tempo.

Estado
Um estado representa a situao em que um objeto se encontra em um determinado momento durante o perodo em que este participa de um processo. Um estado mostrado como um retngulo com cantos arredondados. Um objeto pode passar por diversos estados dentro de um mesmo processo. Um estado pode demonstrar a espera pela ocorrncia um evento, a reao a um estmulo, a execuo de alguma atividade ou a satisfao de alguma condio. Abaixo termos um exemplo em que representado um estado de um objeto da classe Submisso. Nesse estado, a submisso est sendo registrada. Muitas vezes o estado de um objeto descrito no gerndio, uma vez que, em geral, ele est executando uma atividade.

Transies
Uma transio representa um evento que causa uma mudana no estado de um objeto, gerando um novo estado. Uma transio representada por uma reta ligando dois estados, contendo uma seta em uma de suas extremidades, apontando para o novo estado gerado. Transies podem possuir condies de guarda e descries, se isto for considerado necessrio.

Uma transio de estado normalmente possui um evento ligado a ela. Se um evento anexado a uma transio, esta ser executada quando o evento ocorrer. Se uma transio no possuir um evento ligado a ela, a mesma ocorrer quando a ao interna do
49

cdigo do estado for executada (se existir aes internas como entrar, sair, fazer ou outras aes definidas pelo desenvolvedor). Ento quando todas as aes forem executadas pelo estado, a transio ser disparada e sero iniciadas as atividades do prximo estado no diagrama de estados.

Estados Inicial e Final

Um estado inicial utilizado para representar o incio da modelagem dos estados de um objeto. Da mesma forma, um estado final utilizado para representar o fim dos estados modelados. A partir de um estado inicial sempre existe uma transio que gera o primeiro estado do diagrama, ao passo que o ltimo estado gerar uma transio para o estado final. O estado inicial representado por um crculo preenchido, e o estado final por um crculo preenchido envolvido por outro crculo no-preenchido.

A figura acima apresenta um exemplo de estados iniciais e finais.

Atividades internas
Quando em um estado, um objeto pode executar uma ou mais atividades, que so conhecidas como atividades internas. Essas atividades podem ser detalhadas por meio das seguintes clusulas: Entry - identifica uma atividade que executada quando o objeto assume (entra em) um estado. Exit - identifica uma atividade que executada quando o objeto sai de um estado Do - identifica uma atividade realizada durante o tempo em que o objeto se encontra em um estado. Atividades internas do tipo Do tambm so chamadas de atividades de estado. As atividades internas so representadas em uma segunda diviso do estado, conforme demonstra a figura abaixo, em que o objeto executa o mtodo RegSub, enquanto se encontra no estado Registrando submisso.

50

Transies internas
Transies internas so transies que no produzem modificaes no estado de um objeto. Abaixo temos um exemplo de transio interna, em que, durante o registro de um cliente, disparado um mtodo para validar o CPF do cliente. Como este um evento interno referente ao registro do cliente, ele descrito como uma transio interna.

Auto-Transies
Auto-transies saem do estado atual do objeto, podendo executar alguma ao quando dessa sada e retornam ao mesmo estado. Abaixo temos um exemplo de autotransio, em que um pedido est sendo atendido e nem todos os itens do pedido se encontram disponveis, sendo, portanto, necessrio adquiri-los. Assim, sempre que um novo item for adquirido, ocorre uma auto-transio; no entanto, se algum item ainda estiver indisponvel, o objeto volta para o estado Atendendo pedido. Somente quando todos os itens do pedido estiverem disponveis ser possvel passar ao estado seguinte.

Pseudo-Estado de Escolha
Conhecido nas verses anteriores como estado de ponto de escolha dinmico, representa um ponto na transio de estados de um objeto em que deve ser tomada uma deciso, a partir da qual um determinado estado ser ou no gerado, normalmente em detrimento de diversos outros possveis estados. Assim, um pseudo-estado de escolha representa uma deciso, apoiada por condies de guarda, em que se decidir qual o prximo estado do objeto a ser gerado. Um pseudo-estado de escolha pode ser representado por um losango ou por um crculo vazio.
51

O exemplo aqui utilizado corresponde aos estados do caso de uso Manter Comentrios. So realizados dois testes aps a listagem dos possveis comentrios existentes: o primeiro verifica se o Avaliador deseja inserir um novo comentrio ou consultar um comentrio j existente. Se o usurio resolver consultar um comentrio ele pode, aps isso, alterar o comentrio, exclu-lo ou simplesmente finalizar a consulta.

Barra de Sincronizao
utilizada quando da ocorrncia de estados paralelos, causados por transies concorrentes. Sua funo determinar o momento em que o processo passou a ser executado em paralelo e em quantos subprocessos se dividiu (bifurcao) ou determinar o momento em que dois ou mais subprocessos se uniram em um nico processo (unio). A imagem abaixo apresenta um exemplo de barra de sincronizao, em que so modelados dois estados paralelos por que passa um objeto da classe carro no momento em que um ator necessita dirigi-lo.

52

Pseudo-Estado de Juno
utilizado para projetar caminhos transacionais complexos, podendo unir mltiplos fluxos em um nico ou dividir um fluxo em diversos; pode ainda utilizar condies de guarda como auxlio.

Nesse exemplo, existem duas possibilidades: o submissor pode j estar registrado e ir fornecer seu login e senha ou o submissor ainda no est registrado e ter de se autoregistrar. Aps se auto-registrar, o submissor fornecer seu login e senha de qualquer modo, e o fluxo volta a ser unificado pelo pseudo-estado de juno que extremamente semelhante a um estado inicial.

Estado Composto
um estado que contm internamente dois ou mais estados, chamados de subestados. So utilizados para "dissecar" um Estado individual, ou seja, um estado composto um estado que foi "explorado'; de maneira a apresentar detalhadamente todas as etapas por que passa o objeto quando no estado em questo. A imagem abaixo apresenta um exemplo de estado composto, no qual detalhamos os estados internos do estado "Registrando cliente" j apresentado anteriormente.

53

Estado de Histria
Um estado de histria representa o registro do ltimo subestado em que um objeto se encontrava, quando, por algum motivo, o processo foi interrompido. Assim, por meio do estado de histria, pode-se retornar exatamente ao ltimo subestado em que o objeto se encontrava quando da interrupo do processo. A imagem abaixo apresenta um exemplo de estado de histria aplicado a um estado composto em que calculado o novo valor de todos os produtos de uma categoria. Caso haja a necessidade de suspender o reclculo, o estado de histria servir para guardar o ltimo estado em que se encontrava o processo antes da suspenso. O fato de o estado de histria apontar para um subestado especfico no significa que seja este o estado que ele est guardando.

Existe tambm o estado de histria profunda, representado pelo mesmo smbolo seguido de um asterisco, utilizado quando da ocorrncia de estados compostos dentro de estados compostos. Assim, o estado de histria profunda guarda e recupera o ltimo subestado em qualquer dos estados compostos em que ele possa estar.

Estado de Submquina
Um estado de submquina equivalente a um estado composto, no entanto no apresenta seus subestados. Ele determina que existem estados internos, mas que estes esto detalhados em um outro diagrama, normalmente com o nome do prprio estado de submquina. Isso vantajoso por permitir fazer referncia a outros diagramas j modelados.

A figura apresenta um estado de sub mquina referente ao processo de Verificar Submisses, no qual, aps visualizar a situao de suas submisses, o autor pode, se
54

quiser, visualizar os comentrios de uma submisso especfica. Como esse processo referese a outro caso de uso, ns o modelamos em separado e o referenciamos por meio de um estado de submquina.

Estados de Entrada e Sada (Entry e Exit States)

Normalmente utilizados juntamente com estados de submquina, demonstram pontos de entrada e sada que sero somente usados em casos excepcionais. A imagem abaixo apresenta um exemplo de estados de entrada e sada, no qual o estado de entrada representado por um crculo vazio na borda do estado de submquina e o estado de sada representado por um crculo com um X. Esses estados normalmente representam excees, por este motivo o exemplo apresenta transies normais que no necessitam desses estados e excees que os utilizam.

Pseudo-Estado de Trmino
Fora o trmino da execuo de uma mquina de estados, em razo, por exemplo, da ocorrncia de uma exceo. representado por um "X'; conforme demonstrado abaixo.

Estado de Sincronismo
Em alguns processos pode eventualmente haver a necessidade de que estes estejam de alguma forma sincronizados, por vezes sendo necessrio que um processo paralelo espere por outro. Assim, preciso existir um estado de sincronismo, cuja funo permitir que os relgios de dois ou mais processos paralelos estejam sincronizados em um determinado momento do processo, conforme a figura abaixo, que ilustra uma situao em que, sempre que um semforo troca de sinal, fora a troca de sinal do outro semforo.

55

Diagrama de Sequncia
Um diagrama de sequncia mostra a colaborao dinmica entre os vrios objetos de um sistema. O mais importante aspecto deste diagrama que a partir dele percebe-se a sequncia de mensagens enviadas entre os objetos. Ele mostra a interao entre os objetos, alguma coisa que acontecer em um ponto especfico da execuo do sistema. Este diagrama procura determinar a sequncia de eventos que ocorrem em um determinado processo, identificando quais mtodos devem ser disparados entre os atores e objetos envolvidos e em que ordem. O diagrama de seqncia baseia-se no diagrama de casos de uso, havendo normalmente um diagrama de seqncia para cada caso de uso, uma vez que um caso de uso, em geral, refere-se a um processo disparado por um ator. Assim, um diagrama de seqncia tambm permite documentar um caso de uso. Obviamente, o diagrama de seqncia depende tambm do diagrama de classes, j que as classes dos objetos declarados no diagrama esto descritas nele, bem como os mtodos disparados entre os objetos. No entanto, o diagrama de seqncia uma excelente forma de validar o diagrama de classes, pois ao model-lo muitas vezes percebem-se falhas e a necessidade de se declarar novos mtodos que no haviam sido imaginados antes. O diagrama de sequncia consiste em um nmero de objetos mostrado em linhas verticais. O decorrer do tempo visualizado observando-se o diagrama no sentido vertical de cima para baixo. As mensagens enviadas por cada objeto so simbolizadas por setas entre os objetos que se relacionam. Diagramas de sequncia possuem dois eixos: o eixo vertical, que mostra o tempo e o eixo horizontal, que mostra os objetos envolvidos na sequncia de uma atividade. Eles tambm mostram as interaes para um cenrio especfico de uma atividade do sistema.

56

No eixo horizontal esto os objetos envolvidos na sequncia. Cada um representado por um retngulo de objeto (similar ao diagrama de objetos) e uma linha vertical pontilhada chamada de linha de vida do objeto, indicando a execuo do objeto durante a sequncia, como exemplo citamos: mensagens recebidas ou enviadas e ativao de objetos. A comunicao entre os objetos representada como linha com setas horizontais simbolizando as mensagens entre as linhas de vida dos objetos. A seta especifica se a mensagem sncrona, assncrona ou simples. As mensagens podem possuir tambm nmeros sequnciais, eles so utilizados para tornar mais explcito as sequncia no diagrama. Em alguns sistemas, objetos rodam concorrentemente, cada um com sua linha de execuo (thread). Se o sistema usa linhas concorrentes de controle, isto mostrado como ativao, mensagens assncronas, ou objetos assncronos. Os diagramas de sequncia podem mostrar objetos que so criados ou destrudos como parte do cenrio documentado pelo diagrama. Um objeto pode criar outros objetos atravs de mensagens. A mensagem que cria ou destri um objeto geralmente sncrona, representada por uma seta slida. Vejamos abaixo os elementos que compe o Diagrama de sequncia:

Atores
Os atores so os mesmos do diagrama de casos de uso e possuem a mesma representao diferenciando-se por possurem uma linha de vida

Exemplo Ator

Objetos
Objetos representam as instncias das classes envolvidas no processo ilustrado pelo diagrama de seqncia. Os objetos do diagrama de seqncia possuem a mesma notao utilizada no diagrama de objetos, diferenciando-se por possurem uma linha de vida, representada por uma linha vertical tracejada abaixo do objeto.
Sub1: Submisso

Exemplo Objeto

57

Um objeto pode existir desde o incio do processo ou ser criado durante a execuo do mesmo. No primeiro caso, o objeto aparecer na parte superior do diagrama; j no segundo, o objeto surgir na mesma altura em que a mensagem que o criar for chamada. A Figura abaixo apresenta um exemplo contendo objetos ativos desde o incio do processo e objetos criados no decorrer do mesmo.

Objetos em um diagrama de sequncia

Na Figura acima foi utilizado o componente notas para destacar a existncia de dois objetos no diagrama. Ao estudarmos a figura, verificamos que o objeto da classe Tema esteve ativo desde o incio do processo, no entanto, o objeto sub1 da classe Submisso foi instanciado no decorrer do processo. O objeto da classe Tema no possui uma descrio, porque nesse caso o processo pode se referir a muitos objetos dessa classe.

Linha de Vida
Representa o tempo em que um objeto existe durante um processo. As linhas de vida so representadas por linhas finas verticais tracejadas partindo do objeto. A linha de vida interrompida com um "X" quando o objeto destrudo.

Foco de Controle ou Ativao

Indica os perodos em que um objeto est participando ativamente do processo. Os focos de controle so representados dentro da linha de vida de um objeto, porm as linhas de vida so representadas por tracejados finos, ao passo que o foco de controle representado por uma linha mais grossa. A Figura abaixo apresenta um exemplo de linha de vida e foco de controle

58

Ao observarmos a Figura, podemos perceber, por meio da linha de vida, que o objeto da classe Tema esteve presente durante todo o processo, no entanto, ele s teve participao ativa quando do disparo dos mtodos de seleo e consulta de tema, quando a linha de vida se tornou mais grossa, indicando que o foco de controle do processo estava sobre o objeto da classe Tema.

Mensagens ou Estmulos
As mensagens so utilizadas para demonstrar a ocorrncia de eventos, que normalmente foram a chamada de um mtodo em algum dos objetos envolvidos no processo. Pode ocorrer, no entanto, de uma mensagem representar a comunicao entre dois atores, neste caso, no disparando mtodos. Um diagrama de seqncia em geral iniciado por um evento externo, causado por algum ator, o que acarreta o disparo de um mtodo em um dos objetos. As mensagens podem ser disparadas entre: Um ator e outro ator. Um ator e um objeto, em que um ator produz um evento que dispara um mtodo em um objeto. Um objeto e um objeto, o que constitui a ocorrncia mais comum de mensagens, em que um objeto transmite uma mensagem para outro objeto em geral solicitando a execuo de um mtodo. Um objeto pode inclusive enviar uma mensagem para si mesmo, disparando um mtodo em si prprio, o que conhecido como auto-chamada. Um objeto e um ator; em geral, isso ocorre somente quando um objeto envia uma mensagem de retorno em resposta chamada de um mtodo solicitado, contendo seus resultados.
59

As mensagens so representadas por uma seta entre dois componentes, indicando qual componente enviou a mensagem e qual a recebeu. As mensagens so apresentadas na posio horizontal entre as linhas de vida dos componentes e sua ordem seqencial demonstrada de cima para baixo. Os textos contidos nas mensagens primeiramente identificam qual evento ocorreu e forou o envio da mensagem e qual mtodo foi chamado. As duas informaes so separadas por um smbolo de dois pontos (:). Podem ocorrer eventos que no disparam mtodos; neste caso, a mensagem descreve apenas o evento que ocorreu, sem o smbolo de dois pontos e nenhum texto aps os mesmos. Tambm pode acontecer de somente o mtodo chamado ser descrito, sem detalhar qual evento o causou. A Figura abaixo apresenta um exemplo de mensagem.

Quando a mensagem dirigida a um objeto que j existe, a seta da mensagem atinge a linha de vida do objeto, engrossando-a, indicando que o foco de controle est sobre o objeto em questo. Quando a mensagem cria um novo objeto, no entanto, a seta atinge o retngulo do objeto, indicando que a mensagem representa um mtodo construtor e que o objeto passa a existir somente a partir daquele momento. A Figura abaixo apresenta um exemplo de mensagem que causa a criao de um novo objeto.

A Figura acima representa a criao de um novo objeto da classe Submisso, causada pela confirmao de submisso por um submissor de um trabalho a ser analisado em um congresso. Uma mensagem pode tambm representar um mtodo destrutor, ou seja, um mtodo que elimina um objeto no mais necessrio. Nesse caso, a mensagem atinge a linha
60

de vida de um objeto e a interrompe com um xis (X). A Figura abaixo apresenta um exemplo de chamada de mtodo destrutor.

Nesse exemplo, existe um objeto car1 pertencente a uma classe Carrinho, que representa um carrinho de compras, como os encontrados nas livrarias digitais da Internet e que pode possuir muitos itens, representados pelos objetos da classe Item_Carrinho. Se em algum momento o cliente resolver cancelar a compra de algum dos itens do carrinho, o objeto da classe Carrinho dever disparar um mtodo destrutor no objeto da classe Item_Carrinho, aqui representado pelo mtodo Excluir.

Mensagens de retorno
Este tipo de mensagem identifica a resposta a uma mensagem para o objeto que a chamou. Uma mensagem de retorno pode retornar informaes especficas do mtodo chamado ou apenas um valor indicando se o mtodo foi executado com sucesso ou no. As mensagens de retorno so representadas por uma seta tracejada contendo uma seta fina que aponta para o objeto ou ator que recebe o resultado do mtodo chamado. A Figura abaixo apresenta um exemplo de mensagem de retorno.

Nesse exemplo, o mtodo RegSub disparado sobre o objeto sub1 retoma um valor considerado verdadeiro, significando que o mtodo foi concludo com sucesso. Obviamente um mtodo dificilmente retornaria uma string com o texto "Verdadeiro'; mas um valor numrico cuja interpretao significaria verdadeiro ou falso. Alguns autores s modelam as mensagens de retorno consideradas realmente importantes para evitar deixar o diagrama muito poludo.
61

Auto-chamadas ou Auto-delegaes
So mensagens que partem da linha de vida objeto e atingem a linha de vida do prprio objeto. A Figura abaixo demonstra um exemplo de auto-chamada.

Neste exemplo, o objeto autor1 dispara em si mesmo um mtodo para validao de CPF.

Fragmentos de Interao e Ocorrncias de Interao

Os fragmentos de interao so noes abstratas de unidades de interao geral. Um fragmento de interao uma parte de uma interao, no entanto, cada fragmento de interao considerado como uma interao independente. Um fragmento representado como um retngulo que envolve toda a interao, alm de conter uma aba no canto superior esquerdo, contendo um operador que determina a qual tipo de diagrama de interao ele se refere. O operador sd, por exemplo, indica que o fragmento um diagrama de seqncia. O texto seguinte ao operador contm a descrio da interao que est sendo modelada, normalmente contendo apenas o nome da interao. A figura abaixo apresenta um exemplo de fragmento de interao.

Essa figura representa o incio do processo de encerramento de uma conta bancria especial, em que o cliente solicita ao funcionrio do banco (aqui representado pelo ator Banco) que sua conta seja encerrada, informando sua conta e senha. Caso estas
62

sejam vlidas, o funcionrio disparar o mtodo Saldo para obter o saldo da conta. Esse exemplo est incompleto, posto que seu objetivo , neste caso, apenas ilustrativo. Uma das principais vantagens do uso de fragmentos de interao caracteriza-se pela possibilidade de se poder referenci-los por meio do operador Ref, que a abreviatura de Referred (referido) e significa que deve-se procurar por um diagrama cujo nome o mesmo do nome apresentado aps o operador Ref, ou seja, o fragmento faz referncia a outro diagrama, no detalhado no diagrama em questo e que deve ser inserido neste. A isso se chama ocorrncia de interao, e esta inovao permite que se montem diagramas mais complexos que fazem referncia a outros diagramas como se fossem sub-rotinas, detalhadas em separado. A Figura abaixo apresenta um exemplo do uso de ocorrncias de interao em um fragmento de interao.

Nesse exemplo, enfocamos o processo de confirmao de pedidos pertencente a um sistema de vendas pela Internet, em que o cliente pode consultar o carrinho de compras a qualquer momento, no entanto, caso ele resolva confirmar o pedido, o sistema obrigatoriamente dever chamar a rotina de Visualizao de Carrinho. Assim, como o processo de Visualizao de Carrinho pode ser chamado de vrias partes do sistema, mais prtico model-lo em separado e referenci-lo sempre que for necessrio, como demonstrado nesse caso. possvel encontrar ocorrncias de interao simplesmente sobrepostas s linhas de vida dos objetos que fazem parte do processo, sem nem ao menos cham-las por meio de uma mensagem, como se as instrues contidas nas ocorrncias de interao fossem adicionadas automaticamente ao diagrama, como pode ser visto na Figura abaixo.

63

Como pode-se observar, a figura acima apresenta o mesmo exemplo da figura anterior; nesse caso, porm, a ocorrncia de interao est simplesmente sobre a linha de vida dos objetos envolvidos. As ocorrncias de interao podem se constituir em uma simples chamada a outro fragmento de interao ou podem passar parmetros para o mesmo, receber o retorno da chamada deste ou ambos.
Portes (Gates)

Um porto uma interface entre fragmentos, um ponto de conexo para relacionar uma mensagem fora de uma ocorrncia de interao com uma mensagem dentro da ocorrncia de interao. Portes so representados simplesmente pelo encontro da seta da mensagem no retngulo da ocorrncia de interao ou, em algumas ferramentas CASE, por pequenos quadrados posicionados na linha vertical do retngulo do fragmento, na altura em que a mensagem dever atingir a linha de vida do objeto a que ela se refere. Quando se tratar de uma ocorrncia de interao referenciada, na qual no possvel determinar em que local o objeto est, o porto colocado no centro da linha vertical. O propsito de um porto simplesmente estabelecer quem est enviando e quem est recebendo uma mensagem, quando esta mensagem no est contida em um nico fragmento de interao. A figura abaixo apresenta um exemplo de uso de um porto.

Fragmentos Combinados e Operadores de Interao

Nas verses anteriores verso 2.0 da UML, os diagramas de seqncia tinham dificuldade em trabalhar questes como testes se-seno, laos ou processamentos paralelos. Essas questes foram abordadas na verso 2.0 por meio do uso de fragmentos combinados que permitem uma modelagem semi-independente da parte do diagrama em que se deve enfocar problemas como os enunciados. Os fragmentos combinados so representados por um retngulo que determina a rea de abrangncia do fragmento no diagrama, alm de conterem ainda uma subdiviso em sua extremidade superior esquerda, para identificar a descrio do fragmento combinado e seu operador de interao, que define o tipo de fragmento que est sendo
64

modelado. Alguns dos operadores de interao mais comuns so listados e exemplificados a seguir: Alt - Abreviatura de Alternatives (Alternativas). Este operador de interao define que o fragmento combinado representa uma escolha entre dois ou mais comportamentos. Esse tipo de fragmento combinado costuma utilizar condies de guarda, tambm conhecidas como restries de interao, para definir o teste a ser considerado na escolha de um dos comportamentos. Veja o exemplo abaixo:

Aqui damos continuidade ao processo de encerramento de conta especial, em que, aps verificar o saldo da conta, dever ser feita uma escolha entre duas operaes: se o saldo da conta for positivo, ento ele executar um saque e entregar ao cliente o valor depositado; se o saldo estiver negativo, o cliente dever depositar o valor necessrio para cobrir o saldo negativo da conta antes de encerr-la. Observe que fragmentos combinados que utilizam o operador de interao Alt possuem ao menos uma diviso, representada por uma linha tracejada, separando as aes executadas em cada opo. Cada uma dessas divises chamada separador de operando de interao, e o contedo representado em cada diviso conhecido como operando de interao, ou seja, uma rea de atuao de um fragmento combinado. Este possui ao menos um operando de interao, sendo que em alguns casos ele deve possuir ao menos dois, como neste exemplo, e em outros, no poder ter mais do que um, quando no existem fluxos alternativos ou paralelos. Neste ltimo caso, o operando de interao representa todo o contedo do fragmento combinado.
65

 Opt - Abreviatura de Option (Opo). Este operador de interao determina que o fragmento combinado representa uma escolha de comportamento em que este ser ou no executado, no havendo uma escolha entre mais de um comportamento possvel. A figura a seguir apresenta um exemplo de fragmento combinado utilizando o operador de interao Opt.

A imagem acima nos mostra a situao em que o cliente, aps visualizar o carrinho de compras, dever se logar, caso ainda no o tenha feito. Uma vez que o cliente pode se logar antes de confirmar o pedido, necessrio testar se o cliente j se encontra logado. Por este motivo utilizamos um fragmento combinado com operador Opt, significando que os passos nele contidos sero ou no executados dependendo de sua condio, determinada pela restrio de interao ''Ainda no logado" Sendo assim se notar que o processo Logar um processo referenciado, ou seja, uma ocorrncia de interao, da mesma forma que Visualizar carrinho. Posto que o cliente tem a possibilidade de executar o processo Logar em mais de um local do sistema, melhor model-lo em separado e referenci-lo sempre que for necessrio inclu-lo em um outro processo. Par - Abreviatura de Parallel (Paralelo). Este operador de interao determina que o fragmento combinado representa uma execuo paralela de dois ou mais comportamentos.

66

Identificamos aqui uma situao em que o ator Motorista deve realizar duas operaes simultneas sobre o objeto car1 da classe Carro, para poder dirigi-lo: soltar a embreagem e pressionar o acelerador. Note que uma linha tracejada divide os operandos de interao representando cada operao paralela. Loop - Abreviatura de Looping (Lao). Este operador de interao determina que o fragmento combinado representa um lao que poder ser repetido diversas vezes.

Nesse exemplo identificamos um processo utilizado para aumentar os produtos de uma categoria. Ao observarmos a figura, percebemos que primeiramente o funcionrio seleciona uma categoria, informa o percentual de aumento e manda aumentar o valor de todos os produtos pertencentes categoria selecionada. Percebemos ainda que o mesmo mtodo aplicado a cada produto pertencente categoria, conforme demonstra a restrio de interao [Para cada produto]. Existem ainda alguns operadores de interao menos utilizados, apresentados a seguir: Break (Quebra). Este operador de interao indica uma "quebra" na execuo normal do processo. usado principalmente para modelar o tratamento de excees. CriticaI Region (Regio Crtica). Este operador de interao identifica uma operao atmica que no pode ser interrompida por outro processo at ser totalmente concluda. Neg - Abreviatura de Negative (Negativo) - este operador de interao representa eventos considerados invlidos, que no devem ocorrer. Todos os eventos no-contidos em um fragmento combinado do tipo neg (quando existir um) so considerados positivos. Assertion (Afirmao) - este operador de interao o oposto do anterior, representando eventos considerados como vlidos. Todos os eventos no contidos em
67

um fragmento combinado do tipo Assertion so automaticamente considerados negativos. Ignore (Ignorar) - o operador de interao Ignore determina que as mensagens contidas no fragmento devem ser ignordas. Essas mensagens podem ser consideradas insignificantes e so intuitivamente ignoradas se elas aparecerem em uma execuo correspondente. Alternativamente pode-se entender Ignore como significando que as mensagens que so ignoradas podem aparecer em qualquer lugar nos eventos. Consider (Considerar) - este operador de interao o oposto do anterior e determina que as mensagens devem obrigatoriamente ser consideradas e que todas as outras mensagens no contidas no fragmento devem ser automaticamente desconsideradas. Tanto o operador de interao Ignore como Consider so freqentemente utilizados juntamente com os operadores Neg e Assertion, de maneira que um fragmento pode conter o outro. Seq - Abreviatura de Weak Sequencing (Seqncia Fraca) - este operador de interao identifica uma situao em que as ocorrncias de evento devem atender estas propriedades: As ordenaes das ocorrncias de evento dentro de cada um dos operandos so mantidas no resultado. Ocorrncias de evento em linhas de vida diferentes de operandos diferentes podem vir em qualquer ordem. Ocorrncias de evento na mesma linha de vida de operandos diferentes so ordenadas de tal forma que uma ocorrncia de evento do primeiro operando venha antes do segundo operando. Strict - Abreviatura de Strict Sequencing (Seqncia Estrita) - o operador de interao strict apresenta um refinamento do operador Weak Sequencing e garante que todas as mensagens no fragmento combinado so ordenadas do incio ao fim.

Diagrama de Comunicao
O Diagrama de Comunicao era conhecido como Diagrama de Colaborao at a verso 1.5 da UML, tendo seu nome modificado para Diagrama de Comunicao a partir da verso 2.0.

68

Um diagrama de comunicao mostra de maneira semelhante ao diagrama de sequncia, a Comunicao dinmica entre os objetos. Normalmente pode-se escolher entre utilizar o diagrama de Comunicao ou o diagrama de sequncia. No diagrama de Comunicao, alm de mostrar a troca de mensagens entre os objetos, percebe-se tambm os objetos com os seus relacionamentos. A interao de mensagens mostrada em ambos os diagramas. Se a nfase do diagrama for o decorrer do tempo, melhor escolher o diagrama de sequncia, mas se a nfase for o contexto do sistema, melhor dar prioridade ao diagrama de Comunicao. O diagrama de Comunicao desenhado como um diagrama de objeto, onde os diversos objetos so mostrados juntamente com seus relacionamentos. As setas de mensagens so desenhadas entre os objetos para mostrar o fluxo de mensagens entre eles. As mensagens so nomeadas, que entre outras coisas mostram a ordem em que as mensagens so enviadas. Tambm podem mostrar condies, interaes, valores de resposta, e etc. O diagrama de Comunicao tambm pode conter objetos ativos, que executam paralelamente com outros.

Diagrama de Atividade
Diagramas de atividade capturam aes e seus resultados. Eles focam o trabalho executado na implementao de uma operao (mtodo), e suas atividades numa instncia de um objeto. O diagrama de atividade uma variao do diagrama de mquina de estado e possui um propsito um pouco diferente do diagrama de estado, que o de capturar aes (trabalho e atividades que sero executados) e seus resultados em termos das mudanas de estados dos objetos. O diagrama de atividade o diagrama com maior nfase ao nvel de algoritmo da UML e provavelmente um dos mais detalhistas. Este diagrama apresenta muitas semelhanas com os antigos fluxogramas utilizados para desenvolver a lgica de
69

programao e determinar o fluxo de controle de um algoritmo, sendo possvel inclusive encontrar diagramas de atividade utilizando pseudocdigo ou at mesmo uma linguagem de programao real, como Java, C ou Pascal. Esse diagrama utilizado, como o prprio nome diz, para modelar atividades, que podem ser um mtodo ou um algoritmo, ou mesmo um processo completo. Atividades podem descrever computao procedural; neste contexto elas so os mtodos correspondentes s operaes sobre classes. Atividades tambm podem ser aplicadas modelagem organizacional para engenharia de processos de negcios e workflow. Finalmente atividades podem tambm ser usadas para modelagem de sistemas de informao para especificar processos ao nvel de sistema. Uma atividade composta por um conjunto de aes, ou seja, os passos necessrios para que a atividade seja concluda. Um diagrama de atividade pode modelar mais de uma atividade. Uma atividade sempre conter aes, as quais, no entanto, no necessariamente estaro representadas dentro da atividade, como quando for necessrio fazer referncia a uma atividade j modelada ou para poupar espao no diagrama. Alm disso, o diagrama de atividade pode ser usado para representar dois tipos de fluxo: de controle e de objetos.

N de Ao
Ns de ao so os elementos mais bsicos de uma atividade. Um n de ao representa um passo, uma etapa que deve ser executada em uma atividade. Um n de ao atmico, no podendo ser decomposto. A figura apresenta um exemplo de n de ao.

Controle de Fluxo
O controle de fluxo um conector que liga dois ns, enviando sinais de controle. representado por uma reta contendo uma seta apontando para o novo n e partindo do antigo, podendo conter uma descrio, uma condio de guarda ou uma restrio, chamada neste diagrama de peso (weight), que determina, por exemplo, o nmero mnimo de sinais que devem ser transmitidos pelo fluxo. Um sinal (token) pode conter valores de controle, objetos ou dados, sendo que estes dois ltimos somente podem ser transmitidos por meio de um fluxo de objeto.

70

N Inicial
Este componente pertence ao grupo de ns de controle, utilizados para o controle de fluxo. usado para representar o incio da atividade e representado por um crculo preenchido.

N Final
Este componente um n de controle usado para representar o fim de uma atividade; representado por um crculo preenchido dentro de um crculo vazio.

N de Deciso
Um n de deciso tambm um n de controle, utilizado para representar uma escolha entre dois ou mais fluxos, dos quais um ser escolhido em detrimento dos outros. Em geral, um n de deciso acompanho por condies de guarda, que determinam a condio para que um fluxo possa ser escolhido. Um n de deciso pode ser utilizado tambm para unir um fluxo dividido por um n de deciso anterior, quando ento passa a chamar-se n de unio.

Conectores
Conectores so basicamente atalhos para o fluxo, utilizados quando existe uma distncia relativamente grande entre os ns que o fluxo precisa ligar. A figura abaixo apresenta um exemplo de conectores, no qual modelamos o processo de Relatrio de

71

Avaliaes. Pode-se notar que existe um conector denominado A que liga os ns de ao Posicionar prxima submisso e Selecionar avaliaes da submisso:

Subatividade
Uma subatividade representa a execuo de uma seqncia no-atmica de etapas que possuem alguma durao. Pode ser comparada a uma sub-rotina que j foi ou ser explorada em outro diagrama de atividade e, portanto, no h necessidade de explor-la no diagrama atual. Uma subatividade pode ainda representar uma rotina contida em uma biblioteca cujas etapas de execuo so desconhecidas. Este componente possui a mesma representao de uma atividade, exceto por possuir em seu canto inferior direito um smbolo que representa um diagrama de atividade. Uma subatividade difere-se de uma atividade por no ser independente, s podendo ser executada a partir de uma atividade especfica. A imagem abaixo apresenta um exemplo de subatividade, em que um arquivo criptografado recebido e repassado para uma rotina de decodificao. Como as etapas para decodificar o arquivo so desconhecidas ou j foram modeladas em outro diagrama, no h necessidade de defini-las novamente.
72

N de Bifurcao/Unio
Um n de bifurcao/unio um n de controle que pode tanto dividir um fluxo em dois ou mais fluxos concorrentes, como mesclar dois ou mais fluxos concorrentes em um nico fluxo de controle. Este n representado por uma barra que pode estar tanto na horizontal como na vertical. A Figura 10.9 apresenta um exemplo de n de bifurcao/unio.

Final de Fluxo Representa o encerramento de uma rotina representada pelo fluxo, mas no de toda a atividade. O smbolo de final de fluxo representado por um crculo com um X, conforme demonstrado abaixo, na qual assumimos uma situao em que muitos componentes podem ser construdos, e instalados. Quando o ltimo componente for construdo esta parte do fluxo estar concluda como demonstra o smbolo de final de fluxo; no entanto, outras etapas devero ser concludas durante a atividade.

73

Fluxo de Objetos
Um fluxo de objetos um conector que pode possuir objetas ou dados passando atravs dele. Representa o fluxo de valores (objetos ou dados) que so enviados a partir de um n de objeto ou para um n de objeto.

N de Objeto
Um n de objeto representa uma instncia de uma classe, que pode estar disponvel em um determinado ponto da atividade. Ns de objeto podem ser utilizados de diversas formas, em sua forma mais tradicional, so representados como um retngulo. O fluxo de objetos pode ser utilizado para modificar o estado de um objeto, definindo um valor para um de seus atributos ou mesmo instanciando o objeto. Um objeto pode apresentar multiplicidade, que, neste caso, determina o nmero mnimo e mximo de valores que o objeto aceita. Se existir um valor mnimo determinado, a ao s inicia quando ele for atingido. Um objeto pode apresentar tambm um "Upperbound" entre colchetes que determina o valor mximo de valores que o objeto pode conter. Em tempo de execuo, quando este valor ultrapassado o fluxo interrompido.

Exemplo de Objeto e fluxo de Objeto

Alfinetes (Pins)
O fluxo de objetos muitas vezes exige a utilizao de alfinetes (pins). Alfinetes so ns de objeto que representam uma entrada para uma ao ou uma sada de uma ao. Eles fornecem valores para as aes e recebem os valores resultantes delas. O prprio objeto apresentado anteriormente um alfinete. Os alfinetes podem ser representados como pequenos retngulos e, em geral, so colocados ao lado das aes s quais esto ligados. Quando o tipo de entrada e sada o mesmo, pode-se utilizar um nico retngulo no centro do fluxo de dois ns de ao, conforme apresentado anteriormente.

N de Parmetro de Atividade Um n de parmetro de atividade um n de objeto utilizado para representar a entrada ou sada de um fluxo de objetos em uma atividade. A Figura 10.13 apresenta um exemplo de n de parmetro de atividade. O n de objeto "Materiais de Produo" um n
74

de parmetro de entrada na atividade, ao passo que os ns de objeto "Computadores Aceitos" e "Computadores Rejeitados" so ns de parmetro de sada na atividade.

Excees
possvel, no diagrama de atividade, detalhar a ocorrncia de excees, bastante comuns na maioria das linguagens de programao atuais. Para descrever a manipulao de uma exceo, o diagrama de atividade fornece uma seta em forma de raio que aponta para a rotina de tratamento da interrupo ou exceo, chamada de fluxo de interrupo.

Observe que a seta de exceo atinge um quadrado no manipulador de exceo. Esse quadrado tambm um n de objeto, chamado n de entrada de exceo.

Ao de Objeto de Envio
uma ao que representa o envio de um objeto para seu objeto de destino. Uma ao de objeto de envio representada por um retngulo com uma protuberncia triangular em seu lado direito.

Ao de Evento de Aceitao
uma ao que representa a espera de ocorrncia de um evento de acordo com determinadas condies. Uma ao de evento de aceitao representada por um retngulo com uma reentrncia triangular em seu lado direito. A figura abaixo apresenta um exemplo de aes de objeto de envio e de evento de aceitao.

75

Nesse exemplo, utilizamos um fluxo de controle referente ao envio de um texto para impresso. Aps preparar o texto, enviado um sinal impressora para verificar se esta est pronta para receber o material a ser impresso. Em seguida, a impressora envia um sinal em resposta informando que ela pode imprimir o documento. Observe que a impressora representada como um objeto e que os sinais so enviados e recebidos por meio de um fluxo de objeto.

Ao de Evento de Tempo de Aceitao

uma variao da ao de evento de aceitao que leva em considerao o tempo para que o evento possa ser disparado. Pode ser comparada com uma trigger.

N de Repositrio de Dados (Data Store Node)

Um n de repositrio de dados um n de objeto representado com o esteretipo de datastore. Um n de repositrio de dados usado para armazenar dados ou objetos permanentemente. um tipo especial de n de buffer central, cuja funo gerenciar fluxos de mltiplas fontes e destinos. Os dados que entram em um n de repositrio de dados so armazenados permanentemente, atualizando os dados que j existiam. Os dados que vm de um n de repositrio de dados so uma cpia dos dados originais.

76

Partio de Atividade
As parties de atividade permitem representar o fluxo de um processo que passa por diversos setores ou departamentos de uma empresa, ou mesmo um processo que manipulado por diversos atores. As parties de atividade so formadas por retngulos representando divises que identificam as zonas de influncia de um determinado setor sobre um determinado processo.

Regio de Atividade Interrompvel

Uma regio de atividade interrompvel engloba um certo nmero de elementos da atividade que podem sofrer uma interrupo, assim todo o processo envolvido pela regio poder ser interrompido, no importando em que elemento da atividade a interrupo ocorreu. A regio delimitada por um retngulo tracejado com as bordas arredondadas. necessrio utilizar uma ao de objeto de envio para indicar a interrupo.

77

Regio de Expanso
Uma regio de expanso uma regio de atividade estruturada que executada mltiplas vezes de acordo com os elementos de uma coleo de entrada. Uma regio de expanso engloba uma parte da atividade e representa uma regio aninhada na qual cada entrada uma coleo de valores. A regio de expanso executada uma vez para cada elemento na coleo de entrada. A cada execuo da regio um valor de sada inserido na coleo de sada na mesma posio que os elementos de entrada. Os elementos de entrada e sada so ns de objeto, cada um representado por trs pequenos quadrados juntos, colocados nas extremidades da regio de expanso, aqui chamados de ns de expanso. Uma regio de expanso pode ser iterativa, em que as interaes ocorrem na ordem dos elementos; paralela, na qual todas as interaes so independentes; ou de fluxo (stream), na qual h uma nica execuo da regio em que os valores na coleo de entrada so extrados e colocados na execuo da regio de expanso como um fluxo. A Figura abaixo apresenta um exemplo de regio de expanso, no qual foi modelado um clculo recursivo de fatorial.

Diagrama de Componente
O diagrama de componente e o de execuo so diagramas que mostram o sistema por um lado funcional, expondo as relaes entre seus componentes e a organizao de seus mdulos durante sua execuo.
78

O diagrama de componente descreve os componentes de software e suas dependncias entre si, representando a estrutura do cdigo gerado. Os componentes so a implementao na arquitetura fsica dos conceitos e da funcionalidade definidos na arquitetura lgica (classes, objetos e seus relacionamentos). Eles so tipicamente os arquivos implementados no ambiente de desenvolvimento. Um componente mostrado em UML como um retngulo com uma elipse e dois retngulos menores do seu lado esquerdo. O nome do componente escrito abaixo ou dentro de seu smbolo. Componentes so tipos, mas apenas componentes executveis podem ter instncias. Um diagrama de componente mostra apenas componentes como tipos. Para mostrar instncias de componentes, deve ser usado um diagrama de execuo, onde as instncias executveis so alocadas em nodes. A dependncia entre componentes pode ser mostrada como uma linha tracejada com uma seta, simbolizando que um componente precisa do outro para possuir uma definio completa. Com o diagrama de componentes facilmente visvel detectar que arquivos .dll so necessrios para executar a aplicao.

Componentes podem definir interfaces que so visveis para outros componentes. As interfaces podem ser tanto definidas ao nvel de codificao (como em Java) quanto em interfaces binrias usadas em run-time (como em OLE). Uma interface mostrada como uma linha partindo do componente e com um crculo na outra extremidade. O nome colocado junto do crculo no final da linha. Dependncias entre componentes podem ento apontar para a interface do componente que est sendo usada.

79

Diagrama de Execuo
O diagrama de execuo mostra a arquitetura fsica do hardware e do software no sistema. Pode mostrar os atuais computadores e perifricos, juntamente com as conexes que eles estabelecem entre si e pode mostrar tambm os tipos de conexes entre esses computadores e perifricos. Especifica-se tambm os componentes executveis e objetos que so alocados para mostrar quais unidades de software so executados e em que destes computadores so executados. O diagrama de execuo demonstra a arquitetura run-time de processadores, componentes fsicos (devices), e de software que rodam no ambiente onde o sistema desenvolvido ser utilizado. a ltima descrio fsica da topologia do sistema, descrevendo a estrutura de hardware e software que executam em cada unidade. O diagrama de execuo composto por componentes, que possuem a mesma simbologia dos componentes do diagrama de componentes, nodes, que significam objetos fsicos que fazem parte do sistema, podendo ser uma mquina cliente numa LAN, uma mquina servidora, uma impressora, um roteador, etc., e conexes entre estes nodes e componentes que juntos compem toda a arquitetura fsica do sistema.

Diagrama de Estrutura Composta

O Diagrama de estrutura composta utilizado para modelar colaboraes. Uma colaborao descreve uma viso de um conjunto de entidades cooperativas interpretadas por instncias que cooperam entre si para executar uma funo especfica. Este diagrama fornece meios de definir a estrutura de um elemento e de focalizla no detalhe, na construo e em relacionamentos internos. um dos novos diagramas propostos na segunda verso de UML, voltado a detalhar elementos de modelagem estrutural, como classes, pacotes e componentes, descrevendo sua estrutura interna.

80

Ento podemos dizer que o diagrama de estrutura composta reflete a colaborao interna das classes para descrever a funcionalidade. So bem similares aos diagramas de classes, exceto pelo fato de que eles modelam um uso especfico da estrutura. O diagrama de estrutura composta introduz a noo de porto, um ponto de conexo do elemento modelado, a quem podem ser associadas interfaces. Tambm utiliza a noo de colaborao, que consiste em um conjunto de elementos interligados atravs de seus portos para a execuo de uma funcionalidade especfica recurso til para a modelagem de padres de projeto.

81