apostila uml
TRANSCRIPT
1
Análise Orientada a
Objetos
Goianésia – 2011
2
Sumário Introdução ................................................................................................................................................... 5
Análise e Especificação de Requisitos .......................................................................................................... 5
Processo de desenvolvimento de software .................................................................................................... 6
Visões de um Sistema .................................................................................................................................. 8
Levantamento de Requisitos .................................................................................................... 10
Estudo de Viabilidade ............................................................................................................... 12
Processo de Extração de Requisitos .......................................................................................... 13
Técnicas para extração de requisitos ........................................................................................ 14
Especificação e documentação ................................................................................................. 17
Validação .................................................................................................................................................. 22
UML – Linguagem de Modelagem Unificada ............................................................................................ 23
Um processo para utilizar a UML ............................................................................................................... 25
O Futuro da UML ....................................................................................................................................... 26
Abstração ................................................................................................................................. 26
Classes ..................................................................................................................................... 27
Objetos .................................................................................................................................... 27
Instanciação ............................................................................................................................. 28
Encapsulamento ...................................................................................................................... 28
Métodos .................................................................................................................................. 29
Herança ................................................................................................................................... 30
Herança Múltipla ..................................................................................................................... 30
Polimorfismo ........................................................................................................................... 30
Diagramas da UML ................................................................................................................................... 31
Diagrama de Casos de Uso ....................................................................................................... 32
Atores .......................................................................................................................................... 33
Casos de Uso ................................................................................................................................ 34
Associação (Interação) ................................................................................................................. 34
Relacionamento entre Atores ...................................................................................................... 34
Relacionamento entre Atores e casos de uso ............................................................................... 35
Relacionamento entre casos de uso e outros casos de uso ........................................................... 35
Documentação de Casos de Uso ............................................................................................... 38
3
Diagrama de Classes .................................................................................................................................. 39
Responsabilidade ..................................................................................................................... 40
Componentes........................................................................................................................... 40
Atributos...................................................................................................................................... 40
Operações (Métodos) .................................................................................................................. 40
Visibilidade .................................................................................................................................. 42
Relacionamentos ..................................................................................................................... 42
Classe Associativa .................................................................................................................... 47
Diagrama de Objetos ................................................................................................................................. 48
Diagrama de Máquina de Estados .............................................................................................................. 48
Estado ...................................................................................................................................... 49
Transições ................................................................................................................................ 49
Estados Inicial e Final ............................................................................................................... 50
Atividades internas .................................................................................................................. 50
Transições internas .................................................................................................................. 51
Auto-Transições ....................................................................................................................... 51
Pseudo-Estado de Escolha ........................................................................................................ 51
Barra de Sincronização ............................................................................................................. 52
Pseudo-Estado de Junção ......................................................................................................... 53
Estado Composto ..................................................................................................................... 53
Estado de História .................................................................................................................... 54
Estado de Submáquina ............................................................................................................. 54
Estados de Entrada e Saída (Entry e Exit States) ....................................................................... 55
Pseudo-Estado de Término ...................................................................................................... 55
Estado de Sincronismo ............................................................................................................. 55
Diagrama de Sequência ............................................................................................................................. 56
Atores ...................................................................................................................................... 57
Objetos .................................................................................................................................... 57
Linha de Vida ........................................................................................................................... 58
Foco de Controle ou Ativação ................................................................................................... 58
Mensagens ou Estímulos .......................................................................................................... 59
Mensagens de retorno ............................................................................................................. 61
Auto-chamadas ou Auto-delegações ........................................................................................ 62
Fragmentos de Interação e Ocorrências de Interação ............................................................... 62
4
Portões (Gates) ............................................................................................................................ 64
Fragmentos Combinados e Operadores de Interação ................................................................... 64
Diagrama de Comunicação ........................................................................................................................ 68
Diagrama de Atividade .............................................................................................................................. 69
Nó de Ação .............................................................................................................................. 70
Controle de Fluxo ..................................................................................................................... 70
Nó Inicial .................................................................................................................................. 71
Nó Final.................................................................................................................................... 71
Nó de Decisão .......................................................................................................................... 71
Conectores ............................................................................................................................... 71
Subatividade ............................................................................................................................ 72
Nó de Bifurcação/União ........................................................................................................... 73
Fluxo de Objetos ...................................................................................................................... 74
Nó de Objeto ........................................................................................................................... 74
Alfinetes (Pins) ......................................................................................................................... 74
Exceções .................................................................................................................................. 75
Ação de Objeto de Envio .......................................................................................................... 75
Ação de Evento de Aceitação ................................................................................................... 75
Ação de Evento de Tempo de Aceitação ................................................................................... 76
Nó de Repositório de Dados (Data Store Node) ........................................................................ 76
Partição de Atividade ............................................................................................................... 77
Região de Atividade Interrompível ........................................................................................... 77
Região de Expansão ................................................................................................................. 78
Diagrama de Componente ......................................................................................................................... 78
Diagrama de Execução ............................................................................................................................... 80
Diagrama de Estrutura Composta .............................................................................................................. 80
5
Introdução
O desenvolvimento de software é uma atividade de crescente importância na
sociedade contemporânea. A utilização de computadores nas mais diversas áreas do
conhecimento humano tem gerado uma crescente demanda por soluções
computadorizadas.
É importante observar que, associada ao acréscimo da demanda, a evolução do
hardware tem sido mais acentuada, disponibilizando aos usuários máquinas cada vez mais
velozes e com maior capacidade de processamento.
Neste contexto, identificou-se, já na década de 70, uma situação crítica 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 esforços 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 análise e especificação de requisitos, na qual os requisitos de um
sistema são levantados e modelados, para só então ser projetada e implementada uma
solução.
Esta atividade é o objeto de estudo desta disciplina.
Análise e Especificação de Requisitos
Um completo entendimento dos requisitos do software é essencial para o sucesso de
um esforço de desenvolvimento de software. A atividade de análise e especificação de
requisitos é um processo de descoberta, refinamento, modelagem e especificação. O
escopo do software definido no planejamento do projeto é refinado em detalhe, as funções
e o desempenho do software são especificados, as interfaces com outros sistemas são
indicadas e restrições que o software deve atender são estabelecidas. Modelos dos dados
6
requeridos, do controle e do comportamento operacional são construídos. Finalmente,
critérios para a avaliação da qualidade em atividades subseqüentes são estabelecidos.
Os principais profissionais envolvidos nesta atividade são o analista e o
cliente/usuário.
Na atividade de especificação, os requisitos são capturados sob uma perspectiva dos
usuários, isto é, os modelos gerados procuram definir as funcionalidades (requisitos
funcionais) e restrições (requisitos não funcionais) que devem ser consideradas para
atender às necessidades dos usuários. Já na atividade de análise são modeladas as
estruturas internas de um sistema capazes de satisfazer os requisitos identificados.
A etapa de especificação de requisitos é independente de paradigma, uma vez que
trata os requisitos do sistema sob uma perspectiva externa. Nesta parte, são discutidas
técnicas para levantamento de requisitos e a técnica de modelagem de casos de uso, para
modelagem dos requisitos funcionais de um sistema. Entretanto, a atividade de análise, que
modela as estruturas internas de um sistema, é completamente dependente do paradigma
adotado no desenvolvimento, como a Análise Orientada a Objetos, que apresenta os
principais conceitos da orientação a objetos e a linguagem de modelagem unificada (UML)
e explora a modelagem de análise segundo o paradigma de objetos; e a Análise Essencial
de sistemas que apresenta os principais conceitos da análise essencial e discute a
modelagem de análise segundo o método da análise 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 técnicas adequadas para resolver a t do
software.
Passos/Atividades do Processo:
Análise de requisitos de software: A extração dos requisitos de um desejado
produto de software é a primeira tarefa na sua criação. Embora o cliente,
provavelmente, acredite saber o que o software deva fazer, esta tarefa requer
7
habilidade e experiência em engenharia de software para reconhecer a
incompletude, ambigüidade ou contradição nos requisitos.
Especificação: A especificação é a tarefa de descrever precisamente o software que
será escrito, preferencialmente de uma forma matematicamente rigorosa. Na
prática, somente especificações mais bem sucedidas foram escritas para aplicações
bem compreendidas e afinadas que já estavam bem desenvolvidas, embora sistemas
de software de missão crítica sejam freqüentemente bem especificados antes do
desenvolvimento da aplicação. Especificações são mais importantes para interfaces
externas que devem permanecer estáveis.
Arquitetura de Software: A arquitetura de um sistema de software remete a uma
representação abstrata daquele sistema. Arquitetura é concernente à garantia de que
o sistema de software irá ao encontro de requisitos do produto, como também
assegurar que futuros requisitos possam ser atendidos. A etapa da arquitetura
também direciona as interfaces entre os sistemas de software e outros produtos de
software, como também com o hardware básico ou com o sistema operacional.
Implementação (ou codificação): A transformação de um projeto para um código
dever ser a parte mais evidente do trabalho da engenharia de software, mas não
necessariamente a sua maior porção.
Teste: Teste de partes do software, especialmente onde tenha sido codificado por
dois ou mais engenheiros trabalhando juntos, é um papel da engenharia de
software.
Documentação: Uma importante tarefa é a documentação do projeto interno do
software para propósitos de futuras manutenções e aprimoramentos. As
documentações mais importantes são das interfaces externas.
Suporte e Treinamento de Software: Uma grande porcentagem dos projetos de
software falha pelo fato de o desenvolvedor não perceber que não importa quanto
tempo a equipe de planejamento e desenvolvimento irá gastar na criação do
software se ninguém da organização irá usá-lo. As pessoas ocasionalmente resistem
à mudança e evitam aventurar-se em áreas pouco familiares. Então, como parte da
fase de desenvolvimento, é muito importante o treinamento para os usuários de
software mais entusiasmados, alternando o treinamento entre usuários neutros e
usuários favoráveis ao software. Usuários irão ter muitas questões e problemas de
software os quais conduzirão para a próxima fase.
8
Manutenção: A manutenção 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. Não somente pode ser necessário adicionar
códigos que combinem com o projeto original, mas determinar como o software
trabalhará em algum ponto depois da manutenção estar completa, pode requerer um
significativo esforço por parte de um engenheiro de software. Cerca de ⅔ de todos
os engenheiros de software trabalham com a manutenção. Uma pequena parte
destes trabalha na correção de erros. A maioria das manutenções é 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 manutenção de uma forma similar.
Visões de um Sistema
O desenvolvimento de um sistema complexo não é uma tarefa fácil. O ideal seria
que o sistema inteiro pudesse ser descrito em um único gráfico e que este representasse por
completo as reais intenções do sistema sem ambiguidades, sendo facilmente interpretável.
Infelizmente, isso é impossível. Um único gráfico é incapaz de capturar todas as
informações necessárias para descrever um sistema.
Um sistema é composto por diversos aspectos: funcional (que é sua estrutura
estática e suas interações dinâmicas), não funcional (requisitos de tempo, confiabilidade,
desenvolvimento, etc.) e aspectos organizacionais (organização do trabalho, mapeamento
dos módulos de código, etc.). Então o sistema é descrito em um certo número de visões,
cada uma representando uma projeção da descrição completa e mostrando aspectos
particulares do sistema.
Cada visão é descrita por um número de diagramas que contém informações que
dão ênfase aos aspectos particulares do sistema. Existe em alguns casos uma sobreposição
entre os diagramas o que significa que cada um pode fazer parte de mais do que uma visão.
Os diagramas que compõem as visões contêm os modelos de elementos do sistema. As
visões que compõem um sistema são:
Visão de Componentes Visão Lógica
Visão de Use-case
9
Visão "Use-case" (caso de uso): Descreve a funcionalidade do sistema
desempenhada pelos atores externos do sistema (utilizadores). A visão use-case é
central, já que seu conteúdo é base do desenvolvimento das outras visões do
sistema. Essa visão é montada sobre os diagramas de use-case (caso de uso) e
eventualmente diagramas de atividade.
Visão Lógica: Descreve como a funcionalidade do sistema será implementada. É
feita principalmente pelos analistas, programadores e utilizadores. Em contraste
com a visão use-case, a visão lógica observa e estuda o sistema internamente. Ela
descreve e especifica a estrutura estática do sistema (classes, objectos, e
relacionamentos) e as colaborações dinâmicas quando os objetos enviarem
mensagens uns para os outros para realizarem as funções do sistema. Propriedades
como persistência e concorrência são definidas nesta fase, bem como as interfaces e
as estruturas de classes. A estrutura estática é descrita pelos diagramas de classes e
objetos. O modelo dinâmico é descrito pelos diagramas de estado, sequência,
Comunicação e atividade.
Visão de Concorrência: Trata a divisão do sistema em processos e processadores.
Este aspecto, que é uma propriedade não funcional do sistema, permite uma melhor
utilização do ambiente onde o sistema se encontrará, se o mesmo possui execuções
paralelas, e se existe dentro do sistema uma gestão de eventos assíncronos. Uma
vez dividido o sistema em linhas de execução de processos concorrentes (threads),
esta visão de concorrência deverá mostrar como se dá a comunicação e a
concorrência destas threads. A visão de concorrência é suportada pelos diagramas
dinâmicos, que são os diagramas de estado, sequência, Comunicação e atividade, e
pelos diagramas de implementação, que são os diagramas de componentes e de
instalação.
Visão de Componentes: É suportada pelos diagramas de componentes que
descrevem a implementação dos módulos e suas dependências. É principalmente
executada por programadores.
Visão de Organização: Esta visão é representada pelos diagramas de instalação ou
de execução. A visão de organização mostra a organização física do sistema, os
Visão de Organização Visão de Concorrência
10
computadores, os periféricos 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 difíceis
enfrentadas por um engenheiro de software. A engenharia de requisitos ajuda os
engenheiros de software a compreender melhor o problema que eles vão trabalhar para
resolver. Inclui um conjunto de tarefas que levam a um entendimento de qual será o
impacto do software sobre o negócio, do que o cliente quer e de como os usuários finais
vão interagir com o software. A engenharia de requisitos começa com a concepção – tarefa
que define o escopo e a natureza do problema a ser resolvido. Ela avança para o
levantamento – tarefa que ajuda o cliente a definir o que é necessário; e depois para a
elaboração – em que os requisitos básicos são refinados e modificados. À medida que o
cliente define o problema, ocorre a negociação – quais são as prioridades, o que é
essencial, o que é necessário?
Mas será que é fácil?
11
Segundo dicionário da Língua Portuguesa:
“Requisito: Condição a ser preenchida necessariamente pelo produto ou serviço.”
É uma condição ou capacidade que deve ser alcançada ou possuída por um sistema
ou componente deste para satisfazer um contrato, padrão, especificação ou outros
documentos formalmente impostos.
Não importa quão bem projetado ou codificado está um programa, se ele for mal
analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor.
A atividade de levantamento de requisitos é a etapa de compreensão do problema
aplicado ao desenvolvimento de software. O principal objetivo é que os desenvolvedores e
usuários do sistema a ser construído tenham a mesma visão do problema a ser resolvido.
É de suma importância que antes da escrita de uma única linha de código, seja
“concluída” a etapa do levantamento de requisitos, vale a máxima que é quase impossível
concluir esta etapa devido à natureza flexível que os sistemas de softwares exigem.
Normalmente os requisitos de um sistema são identificados a partir do domínio do
negócio. O produto do levantamento de requisito é o documento de requisitos, que declara
os diversos tipos de requisitos do sistema. O vocabuláriqo utilizado que deve ser utilizado
neste documento deve ser acessível ao usuário (cliente) do sistema e preferencialmente que
não possua nenhuma referência à tecnologia.
Imagine que um determinado software tenha sido desenvolvido aplicando as
melhores práticas e técnicas de programação, mas que quando entram em produção os
usuários não conseguem operá-los, ou não conseguem extrair/trabalhar as informações que
ele normalmente está acostumado a obter. Então logo eles irão começar a reclamar do
sistema e em muitos dos casos irão se antepor a utilizá-lo. É para evitar situações como
essa que a fase de levantamento de requisitos existe.
Uma das formas de se medir a qualidade de um sistema de software é através de sua
utilidade. E um sistema será útil para seus usuários se atender aos requisitos definidos.
Portanto, os requisitos devem ser expressos de uma maneira tal que eles possam ser
verificados e comunicados a leitores técnicos e não-técnicos. Clientes (leitores não-
técnicos) devem entender esses documentos para que possam priorizar o desenvolvimento
dos requisitos, conforme as necessidades da organização.
Não importa qual seja o processo de desenvolvimento utilizado: o envolvimento do
usuário final no desenvolvimento de um sistema de software é de fundamental
importância.
12
A engenharia de requisitos consiste no estudo de viabilidade do sistema, na
extração, na análise, na especificação, na documentação e validação de requisitos. O
produto final do processo de extração de requisitos é um documento de Especificação 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 começar
com um estudo de viabilidade. A entrada para o estudo de viabilidade é uma descrição
geral do sistema e de como ele será utilizado dentro de uma organização. Os resultados do
estudo de viabilidade deve ser um relatório que recomenda se vale a pena ou não 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 organização?
O sistema pode ser implementado com a utilização de tecnologia atual dentro das
restrições de custo e de prazo?
O sistema pode ser integrado com outros sistemas já em operação?
Preparar um estudo de viabilidade envolve avaliar e coletar informações e preparar
relatórios. Depois de obtida as informações, as seguintes perguntas devem ser feitas:
Como a organização se comportaria, se esse sistema não fosse implementado?
Quais são os problemas com os processos atuais e como o sistema ajudaria a
diminuí-los?
Quais serão as contribuições diretas advindas do novo sistema?
Essas informações podem ser transferidas para outros sistemas existentes na
organização e/ou podem ser recebidas de programas já implementados?
O sistema requer tecnologia que não tenha sido utilizada anteriormente na
organização?
Quais as compatibilidades que serão necessárias para com o sistema?
Entre as fontes de informação estão os gerentes dos departamentos no qual o
sistema será implantado, os engenheiros de software acostumados com o tipo do sistema
proposto, peritos em tecnologia, usuários finais do sistema, etc… (stakeholders - qualquer
pessoa que tenha uma influência direta ou indireta sobre os requisitos do sistema).
13
O relatório de estudo de viabilidade pode propor mudanças no enfoque, no
orçamento e no cronograma e sugerir outros requisitos de alto nível do sistema.
Processo de Extração de Requisitos
A tarefa de extração de requisitos não é fácil. As necessidades do usuário mudam à
medida que o ambiente no qual o sistema funciona muda com o tempo. Além disso,
frequentemente a ERS e o próprio processo de análise e especificação de requisitos dão
novas ideias aos clientes sobre as suas necessidades e sobre as funções do sistema.
Portanto, mudanças nos requisitos acontecem na maioria dos sistemas complexos. Embora
muitas mudanças sejam devidas às mudanças das necessidades dos usuários, muitas advêm
da interpretação ou especificação incorreta dos requisitos do sistema. Requisitos
incompletos, incorretos ou mal entendidos são as causas mais frequentes da baixa
qualidade, excesso de custo e entrega fora do prazo.
Essa tarefa não é encarada com a devida importância durante a maioria dos cursos.
Normalmente o professor cria a especificação e os alunos sentam-se frente ao computador
e começam a escrever o programa. Na vida real, isso não acontece. O software a ser
desenvolvido pode ter escopos e complexidade diversificados e na maioria dos casos não é
possível sentar à frente da máquina antes de obter mais informações sobre o que o software
deve fazer, que serão obtidas através da extração de requisitos.
A habilidade de empregar um processo sistemático na extração de requisitos é um
dos conhecimentos imprescindíveis para um engenheiro de software. Pesquisas têm
mostrado que quase todo o software vendido não satisfaz as necessidades do usuário. A
engenharia de requisitos, um dos termos utilizados para esse processo, engloba os
seguintes processos:
Extração dos Requisitos: é o processo através do qual os usuários ou compradores
de um sistema de software descobrem, revelam e entendem os requisitos.
Análise dos Requisitos: é o processo de raciocínio sobre os requisitos que foram
extraídos; envolve atividades de exame dos requisitos para descobrir conflitos ou
inconsistências, união de requisitos relacionados e identificação de requisitos que
porventura estejam faltando.
Especificação dos Requisitos: é o processo de armazenar os requisitos em uma ou
mais formas, incluindo língua natural ou formal, representações simbólicas ou
gráficas.
14
Validação dos Requisitos: é o processo de confirmação, junto ao usuário, que os
requisitos especificados são válidos e estão corretos e completos.
Esses processos não podem ser totalmente separados e executados seqüencialmente.
Todos eles são intercalados e executados repetidamente. Em muitos casos, quando se
especifica os requisitos localiza-se conflitos ou ausências, quando se valida, percebe-se a
necessidade de outros requisitos ou detalhes. Nesses casos, precisa-se retornar ao processo
de extração de requisitos.
A maneira mais comum de extrair requisitos é obter a informação diretamente das
pessoas que utilizam o sistema e esse procedimento pode ser dividido em cinco etapas:
Identificar as fontes de requisitos relevantes (usuários ou mais propriamente
stakeholders);
Fazer perguntas apropriadas visando obter um entendimento das necessidades dos
usuários;
Analisar as informações obtidas, procurando por implicações, inconsistências ou
questões não resolvidas;
Confirmar com os usuários o seu entendimento do problema;
Sintetizar os requisitos de forma apropriada.
Técnicas para extração de requisitos
Em todo desenvolvimento de software, um aspecto fundamental é a captura dos
requisitos dos usuários. A extração de requisitos é um processo impreciso e difícil. Existem
várias dificuldades implícitas nesse processo.
Para apoiar este trabalho, diversas técnicas podem ser utilizadas.
Amostragem: Em um levantamento de requisitos, geralmente um engenheiro de software
se depara com duas importantes questões:
Entre os muitos relatórios, formulários e documentos gerados pelos membros de
uma organização, quais deverão ser objeto de investigação?
15
Pode haver um grande número de pessoas afetadas pelo sistema de informação
proposto. Quais delas devem ser entrevistadas, observadas ou questionadas?
Servindo de base para todas as técnicas de levantamento de requisitos, entre elas
investigação, entrevistas e observação, estão as decisões cruciais dizendo respeito a o que
examinar e quem questionar ou observar. Estas decisões podem ser apoiadas por uma
abordagem estruturada chamada amostragem.
Amostragem é o processo de seleção sistemática de elementos representativos de
uma população. Quando os elementos selecionados em uma amostragem são analisados,
pode-se assumir que esta análise revelará informações úteis acerca da população como um
todo.
Por que usar amostragem?
diminuir custos;
acelerar o processo de levantamento de informações;
eficiência: a informação tende a ser mais apurada, já que menos elementos podem
ser analisados, mas estes podem ser analisados com mais detalhes;
reduzir tendências.
Investigação: Muitas vezes, algumas informações são difíceis de serem obtidas através de
entrevistas ou observação. Tais informações revelam, tipicamente, um histórico da
organização e sua direção. Nestes casos, devemos utilizar investigação, isto é, análise de
documentos.
Através de investigação, podemos obter mais facilmente informações, tais como
tipos de documentos e problemas associados, informação financeira e contextos da
organização. Essas informações são difíceis de serem obtidas através de outras técnicas de
levantamento de requisitos, tais como entrevistas ou observação.
Entrevistas: Uma entrevista de levantamento de informações é uma conversa
direcionada com um propósito específico, que utiliza um formato “pergunta-resposta”. Os
objetivos de uma entrevista incluem:
obter as opiniões 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
16
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 confiança e entendimento;
mantenha o controle da entrevista;
venda a “idéia do sistema”, provendo ao entrevistado as informações necessárias.
Questionários: O uso de questionários constitui uma técnica de levantamento de
informações que permite ao analista obter de várias pessoas afetadas pelo sistema (corrente
ou proposto). Informações tais como:
Posturas: o que as pessoas na organização dizem querer;
Crenças: o que as pessoas pensam ser realmente verdade;
Comportamento: o que as pessoas fazem;
Características: propriedades de pessoas ou coisas.
Um questionário pode ter objetivos distintos, em função de sua aplicação, 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 usuários do sistema para sentir problemas ou
levantar questões importantes, antes de se programar entrevistas.
Há muitas similaridades entre estas duas técnicas. De fato, pode ser útil utilizar as
duas abordagens em conjunto:
procurando refinar respostas não claras de um questionário em uma entrevista;
projetando um questionário com base no que foi levantado em uma entrevista.
Observação: Observar o comportamento e o ambiente do indivíduo que toma decisões
pode ser uma forma bastante eficaz de levantar informações que, tipicamente, passam
despercebidas usando outras técnicas.
Tomadas de decisão ocorrem em diversos níveis da organização: operacional,
gerencial e estratégico e, portanto, é importante observá-las em todos os níveis que tenham
interação com o sistema. Através da observação é possível capturar:
o que realmente é feito e não apenas o que é documentado ou explicado.
o relacionamento entre o “tomador de decisão” e outros membros da organização.
A observação é usada para:
17
obter informações sobre o “tomador de decisão” e seu ambiente, que não são
capturadas por outras técnicas.
confirmar ou negar informações de entrevistas e/ou questionários.
Alguns pontos importantes devem ser realçados: o analista deve saber o que
observar, quem observar, quando, onde, porque e como.
Prototipação: A prototipação é uma técnica valiosa para se obter rapidamente informações
específicas sobre requisitos de informação do usuário. Trata-se de uma versão inicial do
sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar
desde cedo falhas que através da comunicação verbal não são tão facilmente identificáveis.
Neste tipo de abordagem apenas são desenvolvidas algumas funcionalidades sendo
normalmente desenvolvidas primeiro aquelas que são mais fáceis de compreender por
parte do utilizador e que lhe podem trazer maior valor acrescentado (principalmente na
prototipação evolutiva, isto é, aquela que mais tarde é evoluída para a fase de
desenvolvimento). O uso de protótipos deve ser considerado apenas mediante uma análise
custo-benefício, já que os custos de desenvolvimento de um protótipo podem facilmente
crescer, sendo particularmente úteis em situações em que a interface com os utilizadores é,
para eles, um aspecto crítico. Tipicamente, a prototipação permite capturar os seguintes
tipos de informação:
Reações iniciais do usuário: Como o usuário se sente em relação ao sistema em
desenvolvimento? Reações ao protótipo podem ser obtidas através da observação,
entrevistas, questionário ou relatório de avaliação.
Sugestões do usuário para refinar ou alterar o protótipo: guiam o analista na
direção de melhor atender as necessidades dos usuários.
Inovações: novas capacidades, não imaginadas antes da interação com o protótipo.
Informações para revisão de planos: estabelecer prioridades e redirecionar planos.
Usuários são fundamentais na prototipação. Para capturar as reações dos usuários
em relação ao protótipo, outras técnicas de levantamento de informação devem ser usadas
em conjunto. Durante a experimentação do usuário com o protótipo, utiliza-se a
observação. Para capturar opiniões e sugestões, podem ser empregados, além da
observação, entrevistas e questionários.
Especificação e documentação É nesta fase que se dá a produção propriamente dita do documento de especificação
de requisitos.
18
Em todos os tipos de especificação 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 ofereça, atendendo aos propósitos para qual o sistema será
desenvolvido.
Exemplos:
o “O software deve possibilitar o cálculo dos gastos diários, semanais,
mensais e anuais com pessoal”.
o “O software deve emitir relatórios de compras”.
o “Os usuários devem poder obter o número de aprovações, reprovações e
trancamentos em todas as disciplinas”.
Os requisitos funcionais descrevem as funcionalidades e serviços que o
sistema deve oferecer. Dependem do tipo do software, potenciais usuários e do tipo
de sistema onde o software será utilizado.
Requisitos não-funcionais: referem-se a aspectos não-funcionais do sistema, como
restrições nas quais o sistema deve operar ou propriedades emergentes do sistema.
Costumam ser divididos em Requisitos não-funcionais de: Utilidade, Confiança,
Desempenho, Suporte e Escalabilidade.
Exemplos:
o “O tempo de resposta do sistema deve ser inferior a 30 segundos”.
o “O tempo de desenvolvimento não deve ultrapassar seis meses”.
o “O software deve ser operacionalizado no sistema específico”.
Os requisitos não-funcionais definem as propriedades do sistema e suas
restrições, isto é, confiabilidade, tempo de resposta. Restrições podem ser
capacidade de dispositivos de I/O, representações gráficas, etc.
Pode-se também considerar os requisitos do domínio, que tal como o nome indica
derivam do domínio e não de necessidades específicas dos utilizadores, podendo depois ser
classificados como funcionais ou não funcionais.
A documentação produzida poderá ter diferentes destinatários e como tal diferentes
objetivos. Podem-se distinguir três tipos de especificação:
Especificação de requisitos do usuário.
Especificação de requisitos do sistema.
Especificação do design da aplicação.
19
A vantagem de conceber mais do que uma especificação para um dado sistema é a
de em cada especificação se comunicar apenas um determinado tipo de informação
adequado ao leitor a que se destina (usando "linguagens" que o utilizador conheça). Por
exemplo, enquanto que nos requisitos do utilizador apenas é feita uma abordagem de alto
nível das funcionalidades do sistema e suas restrições, 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 (notações gráficas como diagramas de casos de
uso).
Requisitos do Usuário: Os requisitos do utilizador destinam-se, portanto, aos
vários níveis hierárquicos da organização na qual o sistema será implementado
(desde gestores a utilizadores), pelo que são descritos usando apenas linguagem
natural, formulários e diagramas muito simples. Obviamente, neste nível de
especificação surgem algumas dificuldades:
o Ambigüidade: torna-se difícil descrever os requisitos de uma forma
inequívoca sem tornar a sua descrição muito longa ou de difícil
compreensão.
o Confusão: ainda que possa não ser tão relevante do ponto de vista do
cliente, a distinção entre requisitos funcionais/não-funcionais e objetivos do
sistema torna-se difícil.
o Agrupamento de requisitos: ao descrever as funcionalidades de um sistema,
pode tornar-se difícil separar claramente os requisitos, o que leva a que
vários requisitos sejam expressos como sendo apenas um.
Algumas considerações úteis a ter em conta ao escrever uma especificação
de requisitos do utilizador:
o Usar o mesmo formato em todos os requisitos (evitam-se omissões e
facilita-se a verificação dos requisitos).
o Distinguir claramente entre comportamentos esperados e desejáveis do
sistema através do uso de expressões como "O sistema permitirá criar (...)"
ou "Deverá ser possível criar (...)" respectivamente. É importante deixar
claro o que o sistema tem de fazer e sugestões de como o deve fazer e,
acima de tudo, usar este tipo de expressões de forma consistente ao longo de
todo o documento.
20
o Usar formatação de texto para salientar determinados aspectos do
documento (usando negrito, por exemplo).
o Evitar usar termos demasiado técnicos ou fora do âmbito do sistema,
identificando-os e definindo-os de uma forma clara quando for
absolutamente necessário usá-los.
Requisitos do sistema: Os requisitos do sistema têm um caráter mais técnico,
consistindo numa descrição detalhada dos requisitos do utilizador correspondentes
recorrendo ao uso, para além da linguagem natural, de linguagens estruturadas e
notações gráficas. Estes requisitos destinam-se ainda aos utilizadores do sistema (e
particularmente aos engenheiros que trabalhem nessa organização) e destinam-se
também às equipes de especificação 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 interpretação 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 descrições diferentes se referem ou
não a requisitos diferentes.
Design de aplicação: Por fim, a especificação do design da aplicação consiste
num documento usado pela equipe de desenvolvimento do sistema no qual
estão definidos pormenores, a um nível mais técnico, acerca da implementação
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 começar a codificar, compreendendo a forma como a
implementação, a um nível global, está a ser feita, mas sem conhecer
necessariamente os detalhes de implementação dos componentes menores. Não
convém cair na tentação de deixar toda a implementação detalhada, uma vez
que convém que os desenvolvedores tenham alguma margem de manobra tanto
para inovar como para resolver problemas encontrados em subsistemas de
forma que uma especificação inicial da arquitetura não consegue prever.
Saídas de um bom processo – ajuda os usuários a explorarem e entenderem
completamente seus requisitos, especialmente a separação entre o que eles querem e o que
21
realmente precisam. Suas interações com o engenheiro de software os ajudam a entender as
restrições que podem ser impostas ao sistema pela tecnologia, pelas práticas da própria
organização ou por regulamentações governamentais. Eles passam a entender as
alternativas, tanto tecnológicas quanto procedimentais, as escolhas que podem ser
necessárias quando dois requisitos não podem ser totalmente satisfeitos, entendendo, na
maioria das vezes, as implicações das decisões por eles tomadas durante o
desenvolvimento de requisitos, criando poucas surpresas no momento de entrega do
sistema. Os usuários passam a compartilhar com o engenheiro de software uma visão dos
problemas que estão tentando resolver, dos tipos de soluções possíveis e se sentem um
pouco donos dos produtos gerados pela extração, sentem-se satisfeitos, informados e
acreditam que o risco é minimizado. Similarmente, os engenheiros e desenvolvedores de
software que participaram do processo de extração de requisitos têm confiança de que
estão resolvendo o problema certo e se convencem de que estão resolvendo o problema
viável sob todos os aspectos, não somente técnicos, mas também humanos. Sabem que os
usuários irão cooperar se for necessário novos esclarecimentos e que essas interações serão
mínimas.
Saídas de um Processo Ruim – o pior resultado de um processo de extração de requisitos
mal feito é que os desenvolvedores poderão estar resolvendo o problema errado. Mesmo
que os desenvolvedores estejam resolvendo essencialmente o problema certo, um processo
de extração ruim pode trazer outras conseqüências negativas. Compradores e usuários
podem ficar insatisfeitos (acontecem freqüentemente quando os desenvolvedores não
ouvem os usuários ou tendem a forçar suas próprias visões e interpretações), resultando
numa participação menos efetiva por parte dos compradores e usuários, resultando em
respostas menos completas, podendo continuar afetando o projeto durante o
desenvolvimento e entrega. Os desenvolvedores podem descobrir que há informações
importantes faltando, o que resulta em encontros adicionais, podem tomar decisões erradas
devido à falta de entendimento das reais necessidades. Os requisitos podem mudar
freqüentemente, resultando em demoras ou esforços desperdiçados nas fases de projeto e
implementação, 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á reputação e perda de
credibilidade dos desenvolvedores, além de uma queda na confiança dos próprios
desenvolvedores em si mesmos
22
Validação
Nesta fase pretende-se demonstrar que o documento de requisitos produzido
corresponde, de fato, o sistema que o cliente necessita.
À semelhança do que sucede na análise dos requisitos, pretende-se encontrar
problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lida
com uma especificação completa dos requisitos.
A validação é especialmente importante em sistemas de grandes dimensões porque
muitas vezes são encontrados erros (durante o desenvolvimento ou já depois de o sistema
estar sendo usado) no documento de requisitos, e esses erros têm repercussões
proporcionais à dimensão do projeto. Estes tipos de erros traduzem-se em elevados custos
e necessidade de refazer muito do trabalho que se julgava já concluído.
Durante a fase de validação dos requisitos, devem ser verificados (através de
checklists) os seguintes atributos dos requisitos:
Validade: a especificação resulta da análise dos requisitos identificados junto das
diversas partes interessadas envolvidas. Como tal, requisitos identificados
individualmente (isto é, junto de cada parte interessada) podem diferir da
especificação final que se atinge após o cruzamento de informação e é necessário
que cada cliente compreenda e aceite a especificação final obtida.
Consistência: não devem existir conflitos entre os requisitos identificados.
Compreensibilidade/Ambigüidade: os requisitos devem poder ser compreendidos
de forma inequívoca pelas partes interessadas.
Completude: todas as funcionalidades pretendidas devem fazer parte da
especificação do sistema.
Realismo: dadas às restrições do projeto (tecnológicas, financeiras e temporais) o
sistema especificado tem de ser implementável.
Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização
dos requisitos especificados, estes devem ser descritos de modo a que seja possível
verificar se foram ou não concretizados, isto é, se o sistema final corresponde à
especificação inicial.
Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar
claramente identificada. Entre outros motivos, isto é importante para facilitar a
gestão futura dos requisitos.
23
Conformidade com normas: para além dos aspectos funcionais dos requisitos, a
sua especificação deve obedecer às normas usadas ao longo de todo o documento.
A fase de validação não deve ser encarada de ânimo leve: trata-se de uma fase
muito importante na engenharia de requisitos e da qual dependem elevados custos a médio
e longo prazo.
Por depender bastante dos retornos transmitidos pelos clientes (que não são peritos
em validação de requisitos) é bastante falível e regra geral há erros que não são
encontrados num primeiro momento, o que leva inevitavelmente a discordâncias numa fase
posterior, já com o documento validado e o projeto em desenvolvimento ou concluído.
Quando isto sucede, torna-se necessário 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 orientação a objetos. Essa linguagem tornou-se, nos últimos anos, a
linguagem padrão de modelagem de Software adotada internacionalmente pela indústria de
Engenharia de Software.
Deve ficar bem claro, no entanto, que a UML não é uma linguagem de
programação e sim uma linguagem de modelagem, cujo objetivo é auxiliar os engenheiros
de Software a definir as características do Software, tais como seus requisitos, seu
comportamento, sua estrutura lógica, a dinâmica de seus processos e até mesmo suas
necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser
implantado. Todas essas características são definidas por meio da UML antes do Software
começar a ser realmente desenvolvido.
Através da UML podemos modelar um sistema utilizando vários 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
24
o Diagrama de Implantação
Modelagem Comportamental (Temporal)
o Diagrama de Casos de Uso
o Diagrama de Atividades
o Diagrama de Transição de Estados
o Diagrama de Máquina de Estados
o Diagramas de Interação Geral
o Diagramas de Interação entre Objetos
Diagrama de Sequência
Diagrama de Comunicação
Diagrama de Tempo
Diagrama de Comunicação
A UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que são
conhecidos como "os três amigos". Eles possuem um extenso conhecimento na área de
modelagem orientado a objetos já que as três mais conceituadas metodologias de
modelagem Orientada a Objetos foram eles que desenvolveram e, a UML é a junção do
que havia de melhor nestas três metodologias adicionado novos conceitos e visões da
linguagem.
A UML é o resultado da unificação da linguagem de modelagem de objetos de 3
métodos líderes do mercado: Booch, Object Modeling Technique (OMT) e Objected-
Oriented Software Engineering (OOSE). Em 1997, a UML v1.1 foi adotada pela OMG
(Object Management Group) e desde então tornou-se o padrão da indústria de Software
para a modelagem de objetos e componentes.
25
Um processo para utilizar a UML
A UML contém notações e regras que tornam possível expressar modelos
orientados a objetos. Mas ela não prescreve como o trabalho tem que ser feito, ou seja, não
possui um processo de como o trabalho tem que ser desenvolvido. Já que a UML foi
desenvolvida para ser usada em diversos métodos de desenvolvimento.
Para usar a UML com sucesso é necessário adotar algum tipo de método de
desenvolvimento, especialmente em sistema de grande porte onde a organização de tarefas
é essencial. A utilização 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 também descreve um número de atividades que
devem ser executadas em uma certa ordem. Quando são definidas e relacionadas as
atividades de um processo, um objetivo específico é alcançado.
Em seu uso normal, a palavra "processo" significa uma relação 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, é necessário saber
o objetivo final do processo, definir regras a serem seguidas e adotar um método fixo de
desenvolvimento.
Um método (processo) tradicional de desenvolvimento orientado a objetos é
dividido em análise de requisitos, análise, design (projeto), implementação, e testes. A
análise de requisitos captura as necessidades básicas funcionais e não-funcionais do
sistema que deve ser desenvolvido. A análise modela o problema principal (classes,
objetos) e cria um modelo ideal do sistema sem levar em conta requisitos técnicos do
sistema. O design expande e adapta os modelos da análise para um ambiente técnico, onde
as soluções técnicas são trabalhadas em detalhes. A implementação consiste em codificar
em linguagem de programação e banco de dados os modelos criados. E as atividades de
testes devem testar o sistema em diferentes níveis, verificando se o mesmo corresponde as
expectativas do usuário.
Existe um processo desenvolvido pela Rational Inc., mesma empresa que
desenvolveu a UML, que monta duas visões do desenvolvimento de um sistema: visão
gerencial e técnica. A visão técnica utiliza as tradicionais atividades de análise, design e
implementação, enquanto a visão gerencial utiliza as seguintes fases no desenvolvimento
de cada geração do sistema.
26
Início: Define o escopo e objetivo do projeto;
Elaboração: Desenvolve o produto em detalhes através de uma série
de interações. Isto envolve mais análise, design e programação;
Transição: Gera o sistema para o usuário final, incluindo as
atividades de marketing, suporte, documentação e treinamento.
Cada fase no ciclo é executada em séries de interações que podem sobrepor outras
fases. Cada interação consiste tipicamente em atividades tradicionais como análise e
design, mas em diferentes proporções dependendo da fase em que esteja a geração do
sistema em desenvolvimento.
Ferramentas modernas devem dar suporte não apenas para linguagens de
modelagem e programação, mas devem suportar um método de desenvolvimento de
sistemas também. 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 fácil integração com outras ferramentas.
O Futuro da UML
Embora a UML defina uma linguagem precisa, ela não é uma barreira para futuros
aperfeiçoamentos nos conceitos de modelagem. O desenvolvimento da UML foi baseado
em técnicas antigas e marcantes da orientação a objetos, mas muitas outras influenciarão a
linguagem em suas próximas versões. Muitas técnicas avançadas de modelagem podem ser
definidas usando UML como base, podendo ser estendida sem se fazer necessário redefinir
a sua estrutura interna.
A UML será a base para muitas ferramentas de desenvolvimento, incluindo
modelagem visual, simulações e ambientes de desenvolvimento. Em breve ferramentas de
integração e padrões de implementação baseados em UML estarão disponíveis para
qualquer um.
A UML integrou muitas idéias adversas, e esta integração vai acelerar o uso do
desenvolvimento de softwares orientados a objetos.
Abstração O uso do computador é baseado em abstrações, que nada mais é do que uma
representação simplificada da realidade, segundo um ponto de vista específico. Na
orientação a objetos o principal mecanismo de abstração é a Classe. Abstração nada mais é
27
do que, a grosso modo, interpretação, ou seja, conseguir enxergar informações que estão
subentendidas.
Exemplo de Abstração
Classes Conceitualmente, uma classe descreve um conjunto de objetos que compartilham
características comuns. Uma classe implementa um Tipo Abstrato de Dados, e “encapsula”
esses dados e suas operações.
Classe é a definição de um conjunto de objetos que compartilham estruturas e
comportamentos comuns, sendo a sua abstração muito importante, dizendo respeito às
informações extraídas em um levantamento de requisitos, por exemplo.
Assim as classes podem ser entendidas como descrições genéricas ou coletivas de
entidades do mundo real. Mantém-se aqui a intenção de aproximar entidades externas de
representações internas. Desta forma, a definição das classes de um sistema deverá
procurar inspiração 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 máquina, uma organização, ou negócio.
Existem objetos que não encontramos no mundo real, mas que podem ser vistos de
derivações de estudos da estrutura e comportamento de outros objetos do mundo real.
Um objeto é um elemento da classe
28
o Objeto deve pertencer a somente uma classe
o O objeto é o elemento que efetivamente armazena as informações 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
Instanciação Instanciação trata-se apenas da criação um objeto a partir de uma classe já definida,
isto é, “instanciamos” um objeto a partir de uma classe. Deve-se ressaltar que Instâncias
(Objetos) de uma mesma classe possuem características idênticas, variando os valores que
essas características podem assumir. Ex: Todos os objetos de uma classe carro possuem
uma característica comum que é cor, mas um pode ter o valor para essa característica igual
a “Azul” e outro “Preto”.
Exemplo de Instanciação
Encapsulamento Encapsular significa “Proteger” dados, ou informações de um objeto, através de
métodos, que garantem acesso seguro à informação armazenada nesses objetos.
29
Ocultamento da Informação
o O acesso aos dados internos de objetos só pode ocorrer a partir de
mensagens.
Independência de aplicação
o Um método deve acessar informações internas do objeto. Na necessidade de
outra informação, somente através de mensagens.
Exemplo de Encapsulamento
Encapsulamento - “Muralha” em volta do objeto
Métodos Métodos ou comportamentos representam atividades que objetos de uma classe
podem executar. É um conjunto de instruções que é executado quando é chamado, por
exemplo, um objeto da classe carro pode executar a atividade de transportar pessoas
(método). Grande parte da codificação propriamente dita dos sistemas de informação
orientados a objetos esta contida nos métodos definidos em suas classes.
Exemplo de Método
30
Herança Herança é o reaproveitamento de atributos e métodos, otimizando o tempo de
desenvolvimento. É uma das características mais poderosas e importantes da orientação a
objetos, porque permite a diminuição de linhas de código.
Quando temos herança, a classe que fornece a herança é chamada de SuperClasse, e
a que recebe a herança é chamada de SubClasse. Quando uma SubClasse herda os atributos
e operações de outra, ela herda todos. O que faz a diferença é a visibilidade, que veremos
mais adiante.
Exemplo de Herança
Herança Múltipla Ocorre quando uma SubClasse herda características e métodos de duas ou mais
SuperClasses.
Exemplo de Herança Múltipla
Polimorfismo O conceito de polimorfismo está associado à herança. O polimorfismo trabalha com
a redeclararão de métodos herdados por uma classe. Esses métodos, embora semelhantes,
diferem de alguma forma da implementação utilizada na SuperClasse, sendo necessário,
portanto, reimplementá-los na SubClasse.
O conceito polimorfismo é muito semelhante ao conceito de variáveis locais e
globais, utilizado pela linguagem de programação C. Ao declararmos uma variável global
31
em um programa escrito na linguagem C, essa variável poderá ser vista e utilizada por
qualquer outra função do programa, no entanto se em alguma função declararmos uma
variável local com o mesmo nome da variável global, naquela função específica, quando
nos referirmos à variável em questão será à variável local e não à global.
O mesmo ocorre com os métodos polimórficos, ou seja, supondo existirem diversas
SubClasses que herdem um método de uma SuperClasse, se uma delas redeclarar este
método, 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 Poderíamos nos perguntar: Porque a UML é composta de tantos diagramas? O
objetivo disto é fornecer múltiplas visões do sistema a ser modelado, analisando-o e
modelando-o sob diversos aspectos, procurando-se assim alcançar 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 visão mais externa do sistema,
como é o objetivo do diagrama de casos de uso, enquanto outros oferecem uma visão de
uma camada mais profunda do Software, apresentando um enfoque mais técnico ou ainda
visualizando apenas uma característica específica do sistema ou um determinado processo.
A utilização de diversos diagramas permite que falhas sejam descobertas, diminuindo a
possibilidade da ocorrência de erros futuros.
32
Diagramas UML
Diagrama de Casos de Uso O diagrama de casos de uso procura, por meio de uma linguagem simples,
possibilitar a compreensão do comportamento externo do sistema por qualquer pessoa,
tentando apresentar o sistema através de uma perspectiva do usuário. É, dentre todos os
diagramas da UML o mais abstrato e, portanto o mais flexível e informal. O diagrama de
casos de uso costuma ser utilizado principalmente no início da modelagem do sistema,
principalmente nas etapas de levantamento e análise 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 visão externa geral das funções e
serviços que o sistema deverá oferecer aos usuários, sem se preocupar em como essas
funções serão implementadas. O diagrama de casos de uso é de grande auxílio na etapa de
análise de requisitos, ajudando a especificar, visualizar e documentar as características,
funções e serviços do sistema desejados pelo usuário. O diagrama de casos de uso tenta
identificar os tipos de usuários que irão interagir com o sistema, quais os papéis que esses
usuários irão assumir e quais funções serão requisitadas por cada usuário específico.
Por utilizar uma linguagem informal e apresentar uma visão geral do
comportamento do sistema a ser desenvolvido, o diagrama de casos de uso pode e deve ser
apresentado durante as reuniões iniciais com os clientes como uma forma de ilustrar o
comportamento do sistema de informação, facilitar o entendimento dos usuários e auxiliar
na identificação de possíveis falhas de especificação. É bastante útil e recomendável que
33
um diagrama de casos de uso seja apresentado aos clientes juntamente com um protótipo,
que permitirá que um complete o outro.
Atores Atores são representações de entidades externas, mas que interagem com o sistema
durante sua execução. Basicamente, a interação de atores com o sistema dá-se através de
comunicações (troca de mensagens). As entidades externas representadas pelos atores
podem ser:
Pessoas: usuário, secretária, aluno, professor, administrador, etc.
Dispositivos: impressora, máquina 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, papéis desempenhados
por pessoas, dispositivos ou outros Softwares quando estiverem interagindo com o sistema.
Por exemplo, um ator cujo identificador seja Aluno não representa um aluno
específico, 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 vários indivíduos, equipamentos ou Softwares. De forma análoga, uma entidade
externa pode ser representada na forma de vários atores. Isto ocorre quando a entidade tem
mais de um papel (tipo de participação ou interação) no sistema. Por exemplo, o indivíduo
João da Silva poderia ser representado em um sistema na forma do ator Usuário, pois ele
interage com o sistema nesta qualidade, e também na forma do ator Administrador, pois ele
também interage com o sistema para este outro fim que é a administração do Software.
Exemplos de Atores
34
Casos de Uso A descrição dos serviços a serem oferecidos pelo sistema é feita na UML
discriminando-se os Casos de Usos do sistema. Cada Caso de Uso descreve uma aplicação
ou uso completo do Software. O conceito de caso de uso não deve ser confundido com o de
módulo já que um caso de uso não é um componente do sistema, mas sim um de seus
empregos possíveis. Também não se deve confundir o conceito de caso de uso com o de
função 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 transações que juntas constituem um serviço completo oferecido pelo
sistema.
A especificação das funcionalidades de um sistema na forma de casos de uso
permite uma visão mais abrangente das aplicações do sistema, favorecendo um
levantamento mais completo e preciso de suas atribuições.
Exemplos Caso de Uso
Associação (Interação) As associações representam as interações 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 Inclusão, Extensão e Generalização.
Uma Associação entre um ator e um caso de uso demonstra que o ator utiliza-se, de
alguma maneira, da função do sistema representada pelo caso de uso em questão, seja
requisitando a execução daquela função, seja recebendo o resultado produzido por ela a
pedido de outro ator.
Relacionamento entre Atores Como os atores são entidades externas, os relacionamentos entre eles serão relações
externas ao sistema. Embora estas relações possam ser desprezadas, pois não fazem parte
do sistema e nem são de conhecimento do sistema, é possível incluí-las no modelo de casos
de uso. De certa forma, estas relações descrevem parte do modelo de negócios da empresa.
35
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
comunicação entre eles, pois o ator sendo uma entidade externa não poderia possuir
qualquer relacionamento estrutural com o sistema computacional. A notação 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 vários propósitos, no que diz respeito a suas interações com
o sistema, podem existir mais de um relacionamento de um ator com diferentes casos de
usos. De forma análoga, um mesmo caso de uso pode envolver a participação de mais de
um ator. O caso de uso Emitir Histórico Escolar envolve a participação de dois atores:
Secretaria e Impressora. O ator Secretaria participa em dois casos de uso: Emitir Histórico
e Registrar Novo Aluno.
Exemplo Relacionamento Ator / Caso de Uso
Relacionamento entre casos de uso e outros casos de uso Ao contrário do relacionamento entre ator e caso de uso, as relações entre casos de
uso nunca serão do tipo comunicação. Isto ocorre porque casos de uso são aplicações
completas do sistema e, por consequência, não existe sentido em fazer-se comunicar dois
36
”usos do sistema”. Todas as relações entre casos de uso serão sempre estruturais. Existem
três tipos de relações entre casos de uso (inclusão, extensão e generalização) conforme
descritos a seguir.
Inclusão (<<Include>>)
A associação de inclusão costuma ser utilizada quando existe um serviço, situação
ou rotina comum a mais de um caso de uso. Quando isso ocorre à documentação dessa
rotina é colocada em um caso de uso específico para que outros casos de uso utilizem-se
desse serviço, evitando descrever uma mesma seqüência de passos em vários casos de uso.
Os relacionamentos de inclusão indicam obrigatoriedade de execução.
Exemplo de Relacionamento de Inclusão
Extensão (<<Extends>>)
Associações de extensão são utilizadas para descrever cenários opcionais de um
caso de uso. Eles descrevem cenários que somente ocorrerão em uma situação específica,
se uma determinada condição for satisfeita. Representam eventos que não ocorrem sempre,
ou seja, são incomuns, não obrigatórios.
Exemplo de Relacionamento de Extensão
37
Restrições em Associações de Extensão
Restrições são compostas por um texto entre chaves e são utilizadas para definir
validações, consistências, condições etc., que devem ser aplicadas a um determinado
componente ou situação. Às vezes, não fica claro qual é a condição para que um caso de
uso estendido seja executado, assim, pode-se acrescentar uma restrição à associação de
extensão por meio de uma nota explicativa, determinando a condição para que o caso de
uso seja executado.
Exemplo de Extensão com Restrição
Generalização
Este relacionamento é uma forma de Associação entre casos de uso na qual existem
dois ou mais casos de uso com características semelhantes, apresentando pequenas
diferenças entre si. Quando tal situação ocorre, costuma-se definir um Caso de Uso Geral,
que descreve as características compartilhadas por todos os casos de uso em questão, e
então relacioná-lo com estes, cuja documentação conterá somente as características
especificas de cada um. Assim não será necessário colocar a mesma documentação 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 possíveis Associações.
Exemplo de Relacionamento de Generalização
38
Documentação de Casos de Uso A documentação de um caso de uso costuma descrever, por meio de uma
linguagem bastante simples, a função 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 função, quais parâmetros devem ser fornecidos e quais
restrições e validações o caso de uso deve possuir.
Não existe um formato específico de documentação para casos de uso definido pela
UML, o que está de acordo com a característica do próprio diagrama, ou seja, o formato de
documentação de um caso de uso é bastante flexível, permitindo que se documente o caso
de uso da forma que se considerar melhor.
Os casos de uso podem também ser documentados por meio de outros diagramas,
como o Diagrama de Sequência ou o Diagrama de Atividade.
Descrição dos Casos de uso Descrição do Caso de Uso são 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 tomarão lugar no Caso de Uso.
Descrição dos atores Descrição dos atores é narrativa de texto descrevendo suas funções e suas
interações em relação ao sistema.
Detalhamento dos casos de uso Tabela descritiva contendo todas as informações e interações do caso de uso que
descrevem ainda os fluxos de atividade entre o sistema e o usuário.
Nome do Caso de Uso Coloque um nome adequado para o Caso de Uso
Caso de Uso Geral Se for um caso de uso generalizado, colocar o nome do
caso de uso mais geral
Descrição Descreva detalhadamente o propósito do caso de uso
Pré Condições Se existir uma ou mais pré condições, descreva-as aqui
Pós Condições Se existir uma ou mais pós condições, descreva-as aqui.
Atores Liste os atores que se relacionam com este caso de uso
Fluxo Principal
Ações Recebidas Ações Realizadas
1. O ator X inicia a fluxo
principal (ou fluxo ótimo).
2. O processo recebe a entrada, avalia e
envia ao controle.
39
3. O controle trata a informação.
4. Após tratar a informação os dados são
apresentados ao ator.
Fluxo Alternativo N
Ações Recebidas Ações Realizadas
O ator X inicia a fluxo
alternativo N (ou fluxo de
erro, ou fluxo opcional, etc).
O processo recebe a entrada, avalia e
envia ao controle.
O controle trata a informação.
Após tratar a informação os dados são
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 visualização das classes que comporão
o sistema com seus respectivos atributos e métodos, bem como em demonstrar como as
classes do diagrama se relacionam, complementam e transmitem informações entre si. Esse
diagrama apresenta uma visão estática de como as classes estão organizadas, preocupando-
se em como definir a estrutura lógica das mesmas. O diagrama de classe serve ainda como
base para a construção da maioria dos outros diagramas da linguagem UML.
Basicamente o diagrama de classes é composto por suas classes e pelas associações
existentes entre elas, ou seja, os relacionamentos entre as classes. Nesse diagrama a
abstração de cada classe com seus atributos e métodos individualmente corresponde à
modelagem de vocabulário, onde são definidas as classes do sistema.
É no diagrama de classes que começamos a sair da parte exclusivamente de
negócios e passamos a tornar realidade à automatização do negócio desejado
Exemplo de uma Classe
40
Responsabilidade Uma classe sempre deve versar sobre um mesmo assunto. Uma classe encapsula
um dado conhecimento sobre algo. Não faz sentido inserirmos, em uma classe que trata de
apartamentos, dados sobre a imobiliária ou atrasos de pagamento da hipoteca – são
assuntos diferentes, portanto, classes diferentes!
Uma classe tem responsabilidade por tudo o que lhe diz respeito. Sua
responsabilidade é resumida em seus atributos e métodos. Não é de responsabilidade de um
proprietário incluir um apartamento, é responsabilidade da própria classe fazer essa
inclusão.
Componentes
Atributos Classes costumam definir atributos, também conhecidos como propriedades. Os
atributos representam as características 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 variações.
Os atributos normalmente possuem duas informações: O Nome que o identifica e o
tipo de dado que ele armazena (Ex.: Integer, Float, Caracter, etc.). Essa última informação
não é obrigatória, mas é bastante útil e recomendável.
Exemplo de Atributos
Operações (Métodos) Os métodos implementam operações a serem executadas pelas classes. Assim
temos em sua estrutura:
Nome do Método: é definido por uma cadeia de caracteres que identificam
exclusivamente o método dentro da classe. Sugere-se o emprego unicamente de
41
letras começando-se por uma letra maiúscula e concatenando-se palavras mantendo
a primeira letra em maiúsculo.
Exemplo: CalcularValor, ArmazenarDados
Parâmetros: são variáveis definidas junto aos métodos e que são utilizadas pelos
métodos para recebimento de valores no momento da ativação. Os parâmetros
podem também ser utilizados para retorno de valores após a execução do método.
Cada parâmetro é especificado usando a notação:
Nome do Parâmetro:Tipo=Valor Padrão
O Nome do Parâmetro é uma cadeia de caracteres que identifica o parâmetro
dentro do método. Tipo é um especificador de tipo de dado padrão da linguagem de
programação. Valor Padrão é a especificação de uma constante cujo valor será
atribuído ao parâmetro se em uma chamada ao método não for especificado um
valor para o parâmetro.
Exemplo: CalcularValor( val1:int, val2:float=10.0)
ArmazenarDados( nome:char[30], salario:float=0.0)
Valor de Retorno: indica se o método retorna algum valor ao término de sua
execução e qual o tipo de dado do valor retornado. Pode-se utilizar aqui os tipos
padrões da linguagem de programação 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 Métodos
42
Visibilidade A visibilidade é utilizada para indicar o nível de acessibilidade de um determinado
atributo ou método. Existem basicamente três modos de visibilidade:
Visibilidade pública: é representada por um símbolo de ( + ) apresentado antes da
descrição do atributo ou método e significa que o atributo ou método pode ser
utilizado por qualquer classe;
Visibilidade protegida: é representada pelo símbolo de sustenido ( # ) e determina
que somente a classe possuidora do atributo ou método ou suas sub-classes podem
ter acesso ao mesmo.
Atributo ou método privado é representado por um sinal de menos ( - ) e significa
que somente a classe possuidora do atributo ou método pode utilizá-lo.
Exemplo de Visibilidade
Relacionamentos As classes costumam possuir relacionamentos entre si, com o intuito de
compartilhar informações e colaborarem umas com as outras para permitir a execução dos
diversos processos executados pelo sistema.
Associações Uma associação descreve um vínculo que ocorre normalmente entre duas classes,
chamado nesse caso de associação binária, mas é perfeitamente válido que uma classe
esteja vinculada a si mesmo, caso conhecido como associação unária, ou que uma mesma
associação seja compartilhada por várias classes, o que é conhecida como associação
ternária ou n-ária, embora esta última seja o tipo de associação mais raro e complexo.
Em uma associação, determina-se que as instâncias de uma classe estão de alguma
forma, ligadas às instâncias das outras classes envolvidas na associação, podendo haver
43
troca de informações entre elas e compartilhamento de métodos, ou mesmo que uma
determinada instância de uma das classes origine uma ou mais instâncias nas outras classes
envolvidas nas associações. Uma associação pode ainda identificar algum nível de
dependência entre as classes que a compõem.
As associações representam o equivalente mais próximo dos relacionamentos
utilizados no modelo entidade-relacionamento, ou seja, seu objetivo é definir a maneira
como as classes estão unidas e interagem entre si, compartilhando informações.
As associações são representadas por retas ligando as classes envolvidas, possuindo
ou não setas em suas extremidades para indicar a navegabilidade da associação. Pode-se
também definir uma descrição para a associação (Papel) para determinar o vínculo
estabelecido entre as classes.
Unária (Reflexiva) (Recursiva): ocorre quando existe um relacionamento de uma
classe para consigo mesma.
Exemplo de associação unária
Binária: é um tipo de associação muito comum, ocorre quando são identificados
relacionamentos entre duas classes.
Exemplo de associação Binária
44
Ternária (N-ária): são associações que conectam três ou mais classes. São
representadas por um losângo para onde convergem todas as ligações da
associação.
Exemplo de associação N-ária
Multiplicidade: procura determinar qual das classes envolvidas em uma
associação fornece informações para as outras, além de permitir especificar o nível
de dependência de uma classe para com as outras classes envolvidas na associação.
A multiplicidade é extremamente semelhante ao conceito de cardinalidade utilizado
no modelo entidade-relacionamento.
Agregação: é um tipo especial de associação onde tenta-se demonstrar que as
informações de um objeto (chamado objeto-todo) precisam ser complementadas
Multiplicidade Significado
0..1
No mínimo Zero e no máximo Um. Indica que os objetos das classes associadas não precisão obrigatoriamente estar relacionados, mas se houver relacionamento indica que apenas uma instância da classe se relaciona com as instâncias da outra classe.
1..1 Um e somente Um. Indica que apenas um objeto da classe se relaciona com os objetos da outra classe.
0..* No mínimo Zero e no máximo Muitos. Indica que pode ou não haver instâncias da classe participando do relacionamento.
* Muitos. Indica que muitos objetos da classe estão envolvidos no relacionamento.
1..* No mínimo Um no máximo Muitos. Indica que há pelo menos um objeto envolvido no relacionamento podendo haver muitos envolvidos.
3..5 No mínimo Três e no máximo Cinco. Indica que existem pelo menos três instâncias envolvidas no relacionamento e que podem ser quatro ou cinco as instâncias envolvidas, não mais que isso.
45
pelas informações contidas em um ou mais objetos de outra classe (chamado
objeto-parte). Este tipo de associação tenta demonstrar uma relação todo/parte entre
os objetos associados. Objeto-parte não pode ser destruído por um objeto diferente
do objeto-todo. O símbolo de agregação difere do de associação por conter um
losângulo na extremidade da classe que contém o objeto-todo.
A agregação fornece também um canal de comunicação entre o objeto-todo
e o objeto-parte. Note que esta comunicação é unidirecional do objeto-todo para o
objeto-parte. O objeto-parte não conhece, a princípio, o objeto-todo. Desta forma,
ele não pode comunicar-se com o objeto-todo.
Exemplo de agregação
Exemplo da notação de agregação
Composição (Agregação Forte): representa um vínculo 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 não podem
viver quando o objeto todo é destruído.
Exemplo de composição
Especialização/Generalização (Herança): este é um tipo especial de
relacionamento muito similar à associação de mesmo nome utilizado no Diagrama
46
de Casos de Uso. Seu objetivo é identificar classes-mãe, chamadas gerais e classes-
filhas, chamadas especializadas. Este tipo de relacionamento permite também
demonstrar a ocorrência de métodos polimórficos nas classes especializadas do
sistema.
Como no Diagrama de Casos de Uso a especialização/generalização ocorre
quando existem duas ou mais classes com classes com características muito
semelhantes, assim para evitar ter que declarar atributos e/ou métodos idênticos e
como uma forma de reaproveitar código, cria-se uma classe geral onde são
declarados os atributos e métodos comuns a todas as classes envolvidas no processo
e então declaram-se classes especializadas ligadas à classes geral, que herdam todas
as suas características podendo possuir atributos e métodos próprios.
Além disso, métodos podem ser redeclarados em uma classe especializada,
possuindo o mesmo nome, mas comportando-se de forma diferente, não sendo,
portanto necessário modificar o código fonte do sistema com relação às chamadas
de métodos das classes especializadas, porque o nome do método não 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 generalização/especialização implica herança: um filho
herda dados do pai como cor dos olhos e cor da pele.
Uma estrutura todo-parte não possui herança: um braço é parte do pai,
como suas pernas, mas não há herança nesses casos.
Exemplo de generalização/especialização
47
Dependência: identifica certo grau de dependência de uma classe em relação à
outra, isto é, sempre que ocorrer uma mudança na classe na qual uma outra classe
depende, esta também deverá sofrer uma mudança. O relacionamento de
dependência é 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 Relação de Dependência
Classe Associativa Classes associativas são classes produzidas quando da ocorrência de associações
que possuem multiplicidade muitos pra muitos. Elas são necessárias nesses casos porque
não existe um repositório que possa armazenar informações produzidas pelas associações
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 associação, o
que não impede que a classe associativa possua atributos próprios, além dos recebidos.
Exemplo de Classe Associativa
48
Diagrama de Objetos
O diagrama de objetos é uma variação do diagrama de classes e utiliza quase a
mesma notação. A diferença é 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 execução. A mesma notação do diagrama de classes é utilizada com
duas exceções: os objetos são escritos com seus nomes sublinhados e todas as instâncias
num relacionamento são mostradas. Os diagramas de objetos não são tão importantes como
os diagramas de classes, mas eles são muito úteis para exemplificar diagramas complexos
de classes ajudando muito em sua compreensão. Diagramas de objetos também são usados
como parte dos diagramas de Comunicação, onde a colaboração dinâmica entre os objetos
do sistema são mostrados.
Diagrama de Máquina de Estados
O diagrama de máquina de estados é tipicamente um complemento para a
descrição das classes. Este diagrama mostra todos os estados possíveis que objetos de
classe podem se encontrar e mostra também quais são os eventos dos sistemas que
provocam tais mudanças. Os diagramas de estado não são escritos para todas as classes de
um sistema, mas apenas para aquelas que possuem um número 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 transições de estado. O elemento modelado muitas vezes é uma instância de
49
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 máquinas 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 condições sendo satisfeitas) afetam estes
estados ao passar do tempo.
Estado Um estado representa a situação em que um objeto se encontra em um
determinado momento durante o período em que este participa de um processo. Um estado
é mostrado como um retângulo com cantos arredondados. Um objeto pode passar por
diversos estados dentro de um mesmo processo. Um estado pode demonstrar a espera pela
ocorrência um evento, a reação a um estímulo, a execução de alguma atividade ou a
satisfação de alguma condição. Abaixo termos um exemplo em que é representado um
estado de um objeto da classe Submissão. Nesse estado, a submissão está sendo registrada.
Muitas vezes o estado de um objeto é descrito no gerúndio, uma vez que, em geral, ele está
executando uma atividade.
Transições Uma transição representa um evento que causa uma mudança no estado de um
objeto, gerando um novo estado. Uma transição é representada por uma reta ligando dois
estados, contendo uma seta em uma de suas extremidades, apontando para o novo estado
gerado. Transições podem possuir condições de guarda e descrições, se isto for
considerado necessário.
Uma transição de estado normalmente possui um evento ligado a ela. Se um
evento é anexado a uma transição, esta será executada quando o evento ocorrer. Se uma
transição não possuir um evento ligado a ela, a mesma ocorrerá quando a ação interna do
50
código do estado for executada (se existir ações internas como entrar, sair, fazer ou outras
ações definidas pelo desenvolvedor). Então quando todas as ações forem executadas pelo
estado, a transição será disparada e serão iniciadas as atividades do próximo estado no
diagrama de estados.
Estados Inicial e Final Um estado inicial é utilizado para representar o início 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 transição que gera o
primeiro estado do diagrama, ao passo que o último estado gerará uma transição para o
estado final. O estado inicial é representado por um círculo preenchido, e o estado final por
um círculo preenchido envolvido por outro círculo não-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 são
conhecidas como atividades internas. Essas atividades podem ser detalhadas por meio das
seguintes cláusulas:
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 também são chamadas de atividades de
estado.
As atividades internas são representadas em uma segunda divisão do estado,
conforme demonstra a figura abaixo, em que o objeto executa o método RegSub, enquanto
se encontra no estado Registrando submissão.
51
Transições internas Transições internas são transições que não produzem modificações no estado de
um objeto. Abaixo temos um exemplo de transição interna, em que, durante o registro de
um cliente, é disparado um método para validar o CPF do cliente. Como este é um evento
interno referente ao registro do cliente, ele é descrito como uma transição interna.
Auto-Transições Auto-transições saem do estado atual do objeto, podendo executar alguma ação
quando dessa saída e retornam ao mesmo estado. Abaixo temos um exemplo de auto-
transição, em que um pedido está sendo atendido e nem todos os itens do pedido se
encontram disponíveis, sendo, portanto, necessário adquiri-los. Assim, sempre que um
novo item for adquirido, ocorre uma auto-transição; no entanto, se algum item ainda
estiver indisponível, o objeto volta para o estado Atendendo pedido. Somente quando todos
os itens do pedido estiverem disponíveis será possível passar ao estado seguinte.
Pseudo-Estado de Escolha Conhecido nas versões anteriores como estado de ponto de escolha dinâmico,
representa um ponto na transição de estados de um objeto em que deve ser tomada uma
decisão, a partir da qual um determinado estado será ou não gerado, normalmente em
detrimento de diversos outros possíveis estados. Assim, um pseudo-estado de escolha
representa uma decisão, apoiada por condições de guarda, em que se decidirá qual o
próximo estado do objeto a ser gerado. Um pseudo-estado de escolha pode ser re-
presentado por um losango ou por um círculo vazio.
52
O exemplo aqui utilizado corresponde aos estados do caso de uso Manter
Comentários. São realizados dois testes após a listagem dos possíveis comentários
existentes: o primeiro verifica se o Avaliador deseja inserir um novo comentário ou
consultar um comentário já existente. Se o usuário resolver consultar um comentário ele
pode, após isso, alterar o comentário, excluí-lo ou simplesmente finalizar a consulta.
Barra de Sincronização É utilizada quando da ocorrência de estados paralelos, causados por transições
concorrentes. Sua função é determinar o momento em que o processo passou a ser
executado em paralelo e em quantos subprocessos se dividiu (bifurcação) ou determinar o
momento em que dois ou mais subprocessos se uniram em um único processo (união). A
imagem abaixo apresenta um exemplo de barra de sincronização, em que são modelados
dois estados paralelos por que passa um objeto da classe carro no momento em que um ator
necessita dirigi-lo.
53
Pseudo-Estado de Junção É utilizado para projetar caminhos transacionais complexos, podendo unir
múltiplos fluxos em um único ou dividir um fluxo em diversos; pode ainda utilizar
condições de guarda como auxílio.
Nesse exemplo, existem duas possibilidades: o submissor pode já estar registrado
e irá fornecer seu login e senha ou o submissor ainda não está registrado e terá de se auto-
registrar. Após se auto-registrar, o submissor fornecerá seu login e senha de qualquer
modo, e o fluxo volta a ser unificado pelo pseudo-estado de junção que é extremamente
semelhante a um estado inicial.
Estado Composto É um estado que contém internamente dois ou mais estados, chamados de
subestados. São 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 questão. A imagem abaixo apresenta
um exemplo de estado composto, no qual detalhamos os estados internos do estado
"Registrando cliente" já apresentado anteriormente.
54
Estado de História Um estado de história 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 história, pode-se retornar exatamente ao último subestado em que o objeto se
encontrava quando da interrupção do processo. A imagem abaixo apresenta um exemplo
de estado de história 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 recálculo, o
estado de história servirá para guardar o último
estado em que se encontrava o processo antes da suspensão. O fato de o estado de
história apontar para um subestado específico não significa que seja este o estado que ele
está guardando.
Existe também o estado de história profunda, representado pelo mesmo símbolo
seguido de um asterisco, utilizado quando da ocorrência de estados compostos dentro de
estados compostos. Assim, o estado de história profunda guarda e recupera o último
subestado em qualquer dos estados compostos em que ele possa estar.
Estado de Submáquina Um estado de submáquina é equivalente a um estado composto, no entanto não
apresenta seus subestados. Ele determina que existem estados internos, mas que estes estão
detalhados em um outro diagrama, normalmente com o nome do próprio estado de
submáquina. Isso é vantajoso por permitir fazer referência a outros diagramas já
modelados.
A figura apresenta um estado de sub máquina referente ao processo de Verificar
Submissões, no qual, após visualizar a situação de suas submissões, o autor pode, se
55
quiser, visualizar os comentários de uma submissão específica. Como esse processo refere-
se a outro caso de uso, nós o modelamos em separado e o referenciamos por meio de um
estado de submáquina.
Estados de Entrada e Saída (Entry e Exit States) Normalmente utilizados juntamente com estados de submáquina, demonstram
pontos de entrada e saída que serão somente usados em casos excepcionais. A imagem
abaixo apresenta um exemplo de estados de entrada e saída, no qual o estado de entrada é
representado por um círculo vazio na borda do estado de submáquina e o estado de saída é
representado por um círculo com um X. Esses estados normalmente representam exceções,
por este motivo o exemplo apresenta transições normais que não necessitam desses estados
e exceções que os utilizam.
Pseudo-Estado de Término Força o término da execução de uma máquina de estados, em razão, por exemplo,
da ocorrência de uma exceção. É 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 necessário que um processo
paralelo espere por outro. Assim, é preciso existir um estado de sincronismo, cuja função é
permitir que os relógios de dois ou mais processos paralelos estejam sincronizados em um
determinado momento do processo, conforme a figura abaixo, que ilustra uma situação em
que, sempre que um semáforo troca de sinal, força a troca de sinal do outro semáforo.
56
Diagrama de Sequência
Um diagrama de sequência mostra a colaboração dinâmica entre os vários objetos
de um sistema. O mais importante aspecto deste diagrama é que a partir dele percebe-se a
sequência de mensagens enviadas entre os objetos. Ele mostra a interação entre os objetos,
alguma coisa que acontecerá em um ponto específico da execução do sistema.
Este diagrama procura determinar a sequência de eventos que ocorrem em um
determinado processo, identificando quais métodos devem ser disparados entre os atores e
objetos envolvidos e em que ordem. O diagrama de seqüência baseia-se no diagrama de
casos de uso, havendo normalmente um diagrama de seqüência 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 seqüência também permite documentar um caso de uso.
Obviamente, o diagrama de seqüência depende também do diagrama de classes, já
que as classes dos objetos declarados no diagrama estão descritas nele, bem como os
métodos disparados entre os objetos. No entanto, o diagrama de seqüência é 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 métodos que não haviam sido imaginados antes.
O diagrama de sequência consiste em um número 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 são simbolizadas por setas
entre os objetos que se relacionam.
Diagramas de sequência possuem dois eixos: o eixo vertical, que mostra o tempo
e o eixo horizontal, que mostra os objetos envolvidos na sequência de uma atividade. Eles
também mostram as interações para um cenário específico de uma atividade do sistema.
57
No eixo horizontal estão os objetos envolvidos na sequência. Cada um é
representado por um retângulo de objeto (similar ao diagrama de objetos) e uma linha
vertical pontilhada chamada de linha de vida do objeto, indicando a execução do objeto
durante a sequência, como exemplo citamos: mensagens recebidas ou enviadas e ativação
de objetos. A comunicação 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 é síncrona, assíncrona ou simples. As mensagens podem possuir
também números sequênciais, eles são utilizados para tornar mais explícito as sequência no
diagrama.
Em alguns sistemas, objetos rodam concorrentemente, cada um com sua linha de
execução (thread). Se o sistema usa linhas concorrentes de controle, isto é mostrado como
ativação, mensagens assíncronas, ou objetos assíncronos.
Os diagramas de sequência podem mostrar objetos que são criados ou destruídos
como parte do cenário documentado pelo diagrama. Um objeto pode criar outros objetos
através de mensagens. A mensagem que cria ou destrói um objeto é geralmente síncrona,
representada por uma seta sólida.
Vejamos abaixo os elementos que compõe o Diagrama de sequência:
Atores Os atores são os mesmos do diagrama de casos de uso e possuem a mesma
representação diferenciando-se por possuírem uma linha de vida
Exemplo Ator
Objetos Objetos representam as instâncias das classes envolvidas no processo ilustrado
pelo diagrama de seqüência. Os objetos do diagrama de seqüência possuem a mesma
notação utilizada no diagrama de objetos, diferenciando-se por possuírem uma linha de
vida, representada por uma linha vertical tracejada abaixo do objeto.
Exemplo Objeto
Sub1: Submissão
58
Um objeto pode existir desde o início do processo ou ser criado durante a
execução 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 início do
processo e objetos criados no decorrer do mesmo.
Objetos em um diagrama de sequência
Na Figura acima foi utilizado o componente notas para destacar a existência de
dois objetos no diagrama. Ao estudarmos a figura, verificamos que o objeto da classe
Tema esteve ativo desde o início do processo, no entanto, o objeto sub1 da classe
Submissão foi instanciado no decorrer do processo. O objeto da classe Tema não possui
uma descrição, 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 são representadas por linhas finas verticais tracejadas partindo do objeto. A linha de
vida é interrompida com um "X" quando o objeto é destruído.
Foco de Controle ou Ativação Indica os períodos em que um objeto está participando ativamente do processo. Os
focos de controle são representados dentro da linha de vida de um objeto, porém as linhas
de vida são 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
59
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
participação ativa quando do disparo dos métodos de seleção 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 Estímulos As mensagens são utilizadas para demonstrar a ocorrência de eventos, que
normalmente forçam a chamada de um método em algum dos objetos envolvidos no
processo. Pode ocorrer, no entanto, de uma mensagem representar a comunicação entre
dois atores, neste caso, não disparando métodos. Um diagrama de seqüência em geral é
iniciado por um evento externo, causado por algum ator, o que acarreta o disparo de um
método 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 método em
um objeto.
Um objeto e um objeto, o que constitui a ocorrência mais comum de mensagens, em
que um objeto transmite uma mensagem para outro objeto em geral solicitando a
execução de um método. Um objeto pode inclusive enviar uma mensagem para si
mesmo, disparando um método em si próprio, 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 método solicitado, contendo seus
resultados.
60
As mensagens são representadas por uma seta entre dois componentes, indicando
qual componente enviou a mensagem e qual a recebeu. As mensagens são apresentadas na
posição horizontal entre as linhas de vida dos componentes e sua ordem seqüencial é
demonstrada de cima para baixo.
Os textos contidos nas mensagens primeiramente identificam qual evento ocorreu
e forçou o envio da mensagem e qual método foi chamado. As duas informações são
separadas por um símbolo de dois pontos (:). Podem ocorrer eventos que não disparam
métodos; neste caso, a mensagem descreve apenas o evento que ocorreu, sem o símbolo de
dois pontos e nenhum texto após os mesmos. Também pode acontecer de somente o
método 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 questão. Quando a mensagem cria um novo objeto, no entanto, a seta
atinge o retângulo do objeto, indicando que a mensagem representa um método construtor
e que o objeto passa a existir somente a partir daquele momento. A Figura abaixo apresenta
um exemplo de mensagem que causa a criação de um novo objeto.
A Figura acima representa a criação de um novo objeto da classe Submissão,
causada pela confirmação de submissão por um submissor de um trabalho a ser analisado
em um congresso.
Uma mensagem pode também representar um método destrutor, ou seja, um
método que elimina um objeto não mais necessário. Nesse caso, a mensagem atinge a linha
61
de vida de um objeto e a interrompe com um xis (X). A Figura abaixo apresenta um
exemplo de chamada de método 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 método destrutor no objeto da classe
Item_Carrinho, aqui representado pelo método 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 informações específicas do método
chamado ou apenas um valor indicando se o método foi executado com sucesso ou não. As
mensagens de retorno são representadas por uma seta tracejada contendo uma seta fina que
aponta para o objeto ou ator que recebe o resultado do método chamado. A Figura abaixo
apresenta um exemplo de mensagem de retorno.
Nesse exemplo, o método RegSub disparado sobre o objeto sub1 retoma um valor
considerado verdadeiro, significando que o método foi concluído com sucesso.
Obviamente um método dificilmente retornaria uma string com o texto "Verdadeiro'; mas
um valor numérico cuja interpretação significaria verdadeiro ou falso. Alguns autores só
modelam as mensagens de retorno consideradas realmente importantes para evitar deixar o
diagrama muito poluído.
62
Auto-chamadas ou Auto-delegações São mensagens que partem da linha de vida objeto e atingem a linha de vida do
próprio objeto. A Figura abaixo demonstra um exemplo de auto-chamada.
Neste exemplo, o objeto autor1 dispara em si mesmo um método para validação
de CPF.
Fragmentos de Interação e Ocorrências de Interação Os fragmentos de interação são noções abstratas de unidades de interação geral.
Um fragmento de interação é uma parte de uma interação, no entanto, cada fragmento de
interação é considerado como uma interação independente. Um fragmento é representado
como um retângulo que envolve toda a interação, além de conter uma aba no canto
superior esquerdo, contendo um operador que determina a qual tipo de diagrama de
interação ele se refere. O operador sd, por exemplo, indica que o fragmento é um diagrama
de seqüência. O texto seguinte ao operador contém a descrição da interação que está sendo
modelada, normalmente contendo apenas o nome da interação. A figura abaixo apresenta
um exemplo de fragmento de interação.
Essa figura representa o início do processo de encerramento de uma conta
bancária especial, em que o cliente solicita ao funcionário do banco (aqui representado
pelo ator Banco) que sua conta seja encerrada, informando sua conta e senha. Caso estas
63
sejam válidas, o funcionário disparará o método 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 interação 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 após o operador Ref, ou seja, o fragmento faz referência a
outro diagrama, não detalhado no diagrama em questão e que deve ser inserido neste. A
isso se chama ocorrência de interação, e esta inovação permite que se montem diagramas
mais complexos que fazem referência a outros diagramas como se fossem sub-rotinas,
detalhadas em separado. A Figura abaixo apresenta um exemplo do uso de ocorrências de
interação em um fragmento de interação.
Nesse exemplo, enfocamos o processo de confirmação 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 Visualização de Carrinho. Assim, como o
processo de Visualização de Carrinho pode ser chamado de várias partes do sistema, é
mais prático modelá-lo em separado e referenciá-lo sempre que for necessário, como é
demonstrado nesse caso.
É possível encontrar ocorrências de interação 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 instruções contidas nas ocorrências de interação fossem
adicionadas automaticamente ao diagrama, como pode ser visto na Figura abaixo.
64
Como pode-se observar, a figura acima apresenta o mesmo exemplo da figura
anterior; nesse caso, porém, a ocorrência de interação está simplesmente sobre a linha de
vida dos objetos envolvidos. As ocorrências de interação podem se constituir em uma
simples chamada a outro fragmento de interação ou podem passar parâmetros para o
mesmo, receber o retorno da chamada deste ou ambos.
Portões (Gates) Um portão é uma interface entre fragmentos, um ponto de conexão para relacionar
uma mensagem fora de uma ocorrência de interação com uma mensagem dentro da
ocorrência de interação. Portões são representados simplesmente pelo encontro da seta da
mensagem no retângulo da ocorrência de interação ou, em algumas ferramentas CASE, por
pequenos quadrados posicionados na linha vertical do retângulo 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 ocorrência de interação referenciada, na qual não é possível determinar em
que local o objeto está, o portão é colocado no centro da linha vertical. O propósito de um
portão é simplesmente estabelecer quem está enviando e quem está recebendo uma
mensagem, quando esta mensagem não está contida em um único fragmento de interação.
A figura abaixo apresenta um exemplo de uso de um portão.
Fragmentos Combinados e Operadores de Interação Nas versões anteriores à versão 2.0 da UML, os diagramas de seqüência tinham
dificuldade em trabalhar questões como testes se-senão, laços ou processamentos paralelos.
Essas questões foram abordadas na versão 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 são representados por um retângulo que determina a
área de abrangência do fragmento no diagrama, além de conterem ainda uma subdivisão
em sua extremidade superior esquerda, para identificar a descrição do fragmento
combinado e seu operador de interação, que define o tipo de fragmento que está sendo
65
modelado. Alguns dos operadores de interação mais comuns são listados e exemplificados
a seguir:
Alt - Abreviatura de Alternatives (Alternativas). Este operador de interação define
que o fragmento combinado representa uma escolha entre dois ou mais
comportamentos. Esse tipo de fragmento combinado costuma utilizar condições de
guarda, também conhecidas como restrições de interação, 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,
após verificar o saldo da conta, deverá ser feita uma escolha entre duas operações: se o
saldo da conta for positivo, então ele executará um saque e entregará ao cliente o valor
depositado; se o saldo estiver negativo, o cliente deverá depositar o valor necessário para
cobrir o saldo negativo da conta antes de encerrá-la.
Observe que fragmentos combinados que utilizam o operador de interação Alt
possuem ao menos uma divisão, representada por uma linha tracejada, separando as ações
executadas em cada opção. Cada uma dessas divisões é chamada separador de operando de
interação, e o conteúdo representado em cada divisão é conhecido como operando de
interação, ou seja, uma área de atuação de um fragmento combinado. Este possui ao menos
um operando de interação, sendo que em alguns casos ele deve possuir ao menos dois,
como neste exemplo, e em outros, não poderá ter mais do que um, quando não existem
fluxos alternativos ou paralelos. Neste último caso, o operando de interação representa
todo o conteúdo do fragmento combinado.
66
Opt - Abreviatura de Option (Opção). Este operador de interação determina que o
fragmento combinado representa uma escolha de comportamento em que este será ou
não executado, não havendo uma escolha entre mais de um comportamento possível. A
figura a seguir apresenta um exemplo de fragmento combinado utilizando o operador
de interação Opt.
A imagem acima nos mostra a situação em que o cliente, após visualizar o
carrinho de compras, deverá se logar, caso ainda não o tenha feito. Uma vez que o cliente
pode se logar antes de confirmar o pedido, é necessário testar se o cliente já se encontra
logado. Por este motivo utilizamos um fragmento combinado com operador Opt,
significando que os passos nele contidos serão ou não executados dependendo de sua
condição, determinada pela restrição de interação ''Ainda não logado"
Sendo assim se notará que o processo Logar é um processo referenciado, ou seja,
uma ocorrência de interação, 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 necessário incluí-lo em um
outro processo.
Par - Abreviatura de Parallel (Paralelo). Este operador de interação
determina que o fragmento combinado representa uma execução paralela de dois ou
mais comportamentos.
67
Identificamos aqui uma situação em que o ator Motorista deve realizar duas
operações simultâneas 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
interação representando cada operação paralela.
Loop - Abreviatura de Looping (Laço). Este operador de interação determina que o
fragmento combinado representa um laço 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 funcionário
seleciona uma categoria, informa o percentual de aumento e manda aumentar o valor de to-
dos os produtos pertencentes à categoria selecionada. Percebemos ainda que o mesmo
método é aplicado a cada produto pertencente à categoria, conforme demonstra a restrição
de interação “[Para cada produto]”.
Existem ainda alguns operadores de interação menos utilizados, apresentados a
seguir:
Break (Quebra). Este operador de interação indica uma "quebra" na execução normal
do processo. É usado principalmente para modelar o tratamento de exceções.
CriticaI Region (Região Crítica). Este operador de interação identifica uma operação
atômica que não pode ser interrompida por outro processo até ser totalmente concluída.
Neg - Abreviatura de Negative (Negativo) - este operador de interação representa
eventos considerados inválidos, que não devem ocorrer. Todos os eventos não-contidos
em um fragmento combinado do tipo neg (quando existir um) são considerados
positivos.
Assertion (Afirmação) - este operador de interação é o oposto do anterior,
representando eventos considerados como válidos. Todos os eventos não contidos em
68
um fragmento combinado do tipo Assertion são automaticamente considerados
negativos.
Ignore (Ignorar) - o operador de interação Ignore determina que as mensagens
contidas no fragmento devem ser ignoràdas. Essas mensagens podem ser consideradas
insignificantes e são intuitivamente ignoradas se elas aparecerem em uma execução
correspondente. Alternativamente pode-se entender Ignore como significando que as
mensagens que são ignoradas podem aparecer em qualquer lugar nos eventos.
Consider (Considerar) - este operador de interação é o oposto do anterior e determina
que as mensagens devem obrigatoriamente ser consideradas e que todas as outras
mensagens não contidas no fragmento devem ser automaticamente desconsideradas.
Tanto o operador de interação Ignore como Consider são freqüentemente utilizados
juntamente com os operadores Neg e Assertion, de maneira que um fragmento pode
conter o outro.
Seq - Abreviatura de Weak Sequencing (Seqüência Fraca) - este operador de
interação identifica uma situação em que as ocorrências de evento devem atender estas
propriedades:
As ordenações das ocorrências de evento dentro de cada um dos operandos são
mantidas no resultado.
Ocorrências de evento em linhas de vida diferentes de operandos diferentes
podem vir em qualquer ordem.
Ocorrências de evento na mesma linha de vida de operandos diferentes são
ordenadas de tal forma que uma ocorrência de evento do primeiro operando
venha antes do segundo operando.
Strict - Abreviatura de Strict Sequencing (Seqüência Estrita) - o operador de
interação strict apresenta um refinamento do operador Weak Sequencing e garante que
todas as mensagens no fragmento combinado são ordenadas do início ao fim.
Diagrama de Comunicação
O Diagrama de Comunicação era conhecido como Diagrama de Colaboração até a
versão 1.5 da UML, tendo seu nome modificado para Diagrama de Comunicação a partir
da versão 2.0.
69
Um diagrama de comunicação mostra de maneira semelhante ao diagrama de
sequência, a Comunicação dinâmica entre os objetos. Normalmente pode-se escolher entre
utilizar o diagrama de Comunicação ou o diagrama de sequência.
No diagrama de Comunicação, além de mostrar a troca de mensagens entre os
objetos, percebe-se também os objetos com os seus relacionamentos. A interação de
mensagens é mostrada em ambos os diagramas. Se a ênfase do diagrama for o decorrer do
tempo, é melhor escolher o diagrama de sequência, mas se a ênfase for o contexto do
sistema, é melhor dar prioridade ao diagrama de Comunicação.
O diagrama de Comunicação é desenhado como um diagrama de objeto, onde os
diversos objetos são mostrados juntamente com seus relacionamentos. As setas de
mensagens são desenhadas entre os objetos para mostrar o fluxo de mensagens entre eles.
As mensagens são nomeadas, que entre outras coisas mostram a ordem em que as
mensagens são enviadas. Também podem mostrar condições, interações, valores de
resposta, e etc. O diagrama de Comunicação também pode conter objetos ativos, que
executam paralelamente com outros.
Diagrama de Atividade
Diagramas de atividade capturam ações e seus resultados. Eles focam o trabalho
executado na implementação de uma operação (método), e suas atividades numa instância
de um objeto. O diagrama de atividade é uma variação do diagrama de máquina de estado
e possui um propósito um pouco diferente do diagrama de estado, que é o de capturar
ações (trabalho e atividades que serão executados) e seus resultados em termos das
mudanças de estados dos objetos.
O diagrama de atividade é o diagrama com maior ênfase ao nível de algoritmo da
UML e provavelmente um dos mais detalhistas. Este diagrama apresenta muitas
semelhanças com os antigos fluxogramas utilizados para desenvolver a lógica de
70
programação e determinar o fluxo de controle de um algoritmo, sendo possível inclusive
encontrar diagramas de atividade utilizando pseudocódigo ou até mesmo uma linguagem
de programação real, como Java, C ou Pascal.
Esse diagrama é utilizado, como o próprio nome diz, para modelar atividades, que
podem ser um método ou um algoritmo, ou mesmo um processo completo. Atividades
podem descrever computação procedural; neste contexto elas são os métodos
correspondentes às operações sobre classes. Atividades também podem ser aplicadas à
modelagem organizacional para engenharia de processos de negócios e workflow.
Finalmente atividades podem também ser usadas para modelagem de sistemas de
informação para especificar processos ao nível de sistema. Uma atividade é composta por
um conjunto de ações, ou seja, os passos necessários para que a atividade seja concluída.
Um diagrama de atividade pode modelar mais de uma atividade. Uma atividade
sempre conterá ações, as quais, no entanto, não necessariamente estarão representadas
dentro da atividade, como quando for necessário fazer referência a uma atividade já
modelada ou para poupar espaço no diagrama. Além disso, o diagrama de atividade pode
ser usado para representar dois tipos de fluxo: de controle e de objetos.
Nó de Ação Nós de ação são os elementos mais básicos de uma atividade. Um nó de ação
representa um passo, uma etapa que deve ser executada em uma atividade. Um nó de ação
é atômico, não podendo ser decomposto. A figura apresenta um exemplo de nó de ação.
Controle de Fluxo
O controle de fluxo é um conector que liga dois nós, enviando sinais de controle.
É representado por uma reta contendo uma seta apontando para o novo nó e partindo do
antigo, podendo conter uma descrição, uma condição de guarda ou uma restrição, chamada
neste diagrama de peso (weight), que determina, por exemplo, o número mínimo 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.
71
Nó Inicial Este componente pertence ao grupo de nós de controle, utilizados para o controle
de fluxo. É usado para representar o início da atividade e é representado por um círculo
preenchido.
Nó Final Este componente é um nó de controle usado para representar o fim de uma
atividade; é representado por um círculo preenchido dentro de um círculo vazio.
Nó de Decisão Um nó de decisão é também 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 decisão é acompanho por condições de guarda, que determinam a
condição para que um fluxo possa ser escolhido. Um nó de decisão pode ser utilizado
também para unir um fluxo dividido por um nó de decisão anterior, quando então passa a
chamar-se nó de união.
Conectores Conectores são basicamente atalhos para o fluxo, utilizados quando existe uma
distância relativamente grande entre os nós que o fluxo precisa ligar. A figura abaixo
apresenta um exemplo de conectores, no qual modelamos o processo de Relatório de
72
Avaliações. Pode-se notar que existe um conector denominado “A” que liga os nós de ação
“Posicionar próxima submissão” e “Selecionar avaliações da submissão”:
Subatividade Uma subatividade representa a execução de uma seqüência não-atômica de etapas
que possuem alguma duração. Pode ser comparada a uma sub-rotina que já foi ou será
explorada em outro diagrama de atividade e, portanto, não há necessidade de explorá-la no
diagrama atual. Uma subatividade pode ainda representar uma rotina contida em uma
biblioteca cujas etapas de execução são desconhecidas. Este componente possui a mesma
representação de uma atividade, exceto por possuir em seu canto inferior direito um
símbolo que representa um diagrama de atividade. Uma subatividade difere-se de uma
atividade por não ser independente, só podendo ser executada a partir de uma atividade
específica.
A imagem abaixo apresenta um exemplo de subatividade, em que um arquivo
criptografado é recebido e repassado para uma rotina de decodificação. Como as etapas
para decodificar o arquivo são desconhecidas ou já foram modeladas em outro diagrama,
não há necessidade de defini-las novamente.
73
Nó de Bifurcação/União Um nó de bifurcação/união é 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
bifurcação/união.
Final de Fluxo
Representa o encerramento de uma rotina representada pelo fluxo, mas não de
toda a atividade. O símbolo de final de fluxo é representado por um círculo com um X,
conforme é demonstrado abaixo, na qual assumimos uma situação em que muitos
componentes podem ser construídos, e instalados. Quando o último componente for
construído esta parte do fluxo estará concluída como demonstra o símbolo de final de
fluxo; no entanto, outras etapas deverão ser concluídas durante a atividade.
74
Fluxo de Objetos Um fluxo de objetos é um conector que pode possuir objetas ou dados passando
através dele. Representa o fluxo de valores (objetos ou dados) que são enviados a partir de
um nó de objeto ou para um nó de objeto.
Nó de Objeto Um nó de objeto representa uma instância de uma classe, que pode estar
disponível em um determinado ponto da atividade. Nós de objeto podem ser utilizados de
diversas formas, em sua forma mais tradicional, são representados como um retângulo. 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 número mínimo e máximo de
valores que o objeto aceita. Se existir um valor mínimo determinado, a ação só inicia
quando ele for atingido. Um objeto pode apresentar também um "Upperbound" entre
colchetes que determina o valor máximo de valores que o objeto pode conter. Em tempo de
execução, quando este valor é ultrapassado o fluxo é interrompido.
Exemplo de Objeto e fluxo de Objeto
Alfinetes (Pins) O fluxo de objetos muitas vezes exige a utilização de alfinetes (pins). Alfinetes
são nós de objeto que representam uma entrada para uma ação ou uma saída de uma ação.
Eles fornecem valores para as ações e recebem os valores resultantes delas. O próprio
objeto apresentado anteriormente é um alfinete. Os alfinetes podem ser representados
como pequenos retângulos e, em geral, são colocados ao lado das ações às quais estão
ligados. Quando o tipo de entrada e saída é o mesmo, pode-se utilizar um único retângulo
no centro do fluxo de dois nós de ação, conforme apresentado anteriormente.
Nó de Parâmetro de Atividade
Um nó de parâmetro de atividade é um nó de objeto utilizado para representar a
entrada ou saída de um fluxo de objetos em uma atividade. A Figura 10.13 apresenta um
exemplo de nó de parâmetro de atividade. O nó de objeto "Materiais de Produção" é um nó
75
de parâmetro de entrada na atividade, ao passo que os nós de objeto "Computadores
Aceitos" e "Computadores Rejeitados" são nós de parâmetro de saída na atividade.
Exceções É possível, no diagrama de atividade, detalhar a ocorrência de exceções, bastante
comuns na maioria das linguagens de programação atuais. Para descrever a manipulação
de uma exceção, o diagrama de atividade fornece uma seta em forma de raio que aponta
para a rotina de tratamento da interrupção ou exceção, chamada de fluxo de interrupção.
Observe que a seta de exceção atinge um quadrado no manipulador de exceção.
Esse quadrado é também um nó de objeto, chamado nó de entrada de exceção.
Ação de Objeto de Envio É uma ação que representa o envio de um objeto para seu objeto de destino. Uma
ação de objeto de envio é representada por um retângulo com uma protuberância triangular
em seu lado direito.
Ação de Evento de Aceitação É uma ação que representa a espera de ocorrência de um evento de acordo com
determinadas condições. Uma ação de evento de aceitação é representada por um retângulo
com uma reentrância triangular em seu lado direito. A figura abaixo apresenta um exemplo
de ações de objeto de envio e de evento de aceitação.
76
Nesse exemplo, utilizamos um fluxo de controle referente ao envio de um texto
para impressão. Após 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 são enviados e recebidos por
meio de um fluxo de objeto.
Ação de Evento de Tempo de Aceitação É uma variação da ação de evento de aceitação que leva em consideração o tempo
para que o evento possa ser disparado. Pode ser comparada com uma trigger.
Nó de Repositório de Dados (Data Store Node) Um nó de repositório de dados é um nó de objeto representado com o estereótipo
de «datastore». Um nó de repositório de dados é usado para armazenar dados ou objetos
permanentemente. É um tipo especial de nó de buffer central, cuja função é gerenciar
fluxos de múltiplas fontes e destinos. Os dados que entram em um nó de repositório de
dados são armazenados permanentemente, atualizando os dados que já existiam. Os dados
que vêm de um nó de repositório de dados são uma cópia dos dados originais.
77
Partição de Atividade As partições 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 partições de atividade são formadas por retângulos
representando divisões que identificam as zonas de influência de um determinado setor
sobre um determinado processo.
Região de Atividade Interrompível Uma região de atividade interrompível engloba um certo número de elementos da
atividade que podem sofrer uma interrupção, assim todo o processo envolvido pela região
poderá ser interrompido, não importando em que elemento da atividade a interrupção
ocorreu. A região é delimitada por um retângulo tracejado com as bordas arredondadas. É
necessário utilizar uma ação de objeto de envio para indicar a interrupção.
78
Região de Expansão Uma região de expansão é uma região de atividade estruturada que é executada
múltiplas vezes de acordo com os elementos de uma coleção de entrada. Uma região de
expansão engloba uma parte da atividade e representa uma região aninhada na qual cada
entrada é uma coleção de valores. A região de expansão é executada uma vez para cada
elemento na coleção de entrada. A cada execução da região um valor de saída é inserido na
coleção de saída na mesma posição que os elementos de entrada. Os elementos de entrada
e saída são nós de objeto, cada um representado por três pequenos quadrados juntos,
colocados nas extremidades da região de expansão, aqui chamados de nós de expansão.
Uma região de expansão pode ser iterativa, em que as interações ocorrem na
ordem dos elementos; paralela, na qual todas as interações são independentes; ou de fluxo
(stream), na qual há uma única execução da região em que os valores na coleção de entrada
são extraídos e colocados na execução da região de expansão como um fluxo. A Figura
abaixo apresenta um exemplo de região de expansão, no qual foi modelado um cálculo
recursivo de fatorial.
Diagrama de Componente
O diagrama de componente e o de execução são diagramas que mostram o sistema
por um lado funcional, expondo as relações entre seus componentes e a organização de
seus módulos durante sua execução.
79
O diagrama de componente descreve os componentes de software e suas
dependências entre si, representando a estrutura do código gerado. Os componentes são a
implementação na arquitetura física dos conceitos e da funcionalidade definidos na
arquitetura lógica (classes, objetos e seus relacionamentos). Eles são tipicamente os
arquivos implementados no ambiente de desenvolvimento.
Um componente é mostrado em UML como um retângulo com uma elipse e dois
retângulos menores do seu lado esquerdo. O nome do componente é escrito abaixo ou
dentro de seu símbolo.
Componentes são tipos, mas apenas componentes executáveis podem ter
instâncias. Um diagrama de componente mostra apenas componentes como tipos. Para
mostrar instâncias de componentes, deve ser usado um diagrama de execução, onde as
instâncias executáveis são alocadas em nodes.
A dependência entre componentes pode ser mostrada como uma linha tracejada
com uma seta, simbolizando que um componente precisa do outro para possuir uma
definição completa. Com o diagrama de componentes é facilmente visível detectar que
arquivos .dll são necessários para executar a aplicação.
Componentes podem definir interfaces que são visíveis para outros componentes.
As interfaces podem ser tanto definidas ao nível de codificação (como em Java) quanto em
interfaces binárias usadas em run-time (como em OLE). Uma interface é mostrada como
uma linha partindo do componente e com um círculo na outra extremidade. O nome é
colocado junto do círculo no final da linha. Dependências entre componentes podem então
apontar para a interface do componente que está sendo usada.
80
Diagrama de Execução
O diagrama de execução mostra a arquitetura física do hardware e do software no
sistema. Pode mostrar os atuais computadores e periféricos, juntamente com as conexões
que eles estabelecem entre si e pode mostrar também os tipos de conexões entre esses
computadores e periféricos. Especifica-se também os componentes executáveis e objetos
que são alocados para mostrar quais unidades de software são executados e em que destes
computadores são executados.
O diagrama de execução demonstra a arquitetura run-time de processadores,
componentes físicos (devices), e de software que rodam no ambiente onde o sistema
desenvolvido será utilizado. É a última descrição física da topologia do sistema,
descrevendo a estrutura de hardware e software que executam em cada unidade.
O diagrama de execução é composto por componentes, que possuem a mesma
simbologia dos componentes do diagrama de componentes, nodes, que significam objetos
físicos que fazem parte do sistema, podendo ser uma máquina cliente numa LAN, uma
máquina servidora, uma impressora, um roteador, etc., e conexões entre estes nodes e
componentes que juntos compõem toda a arquitetura física do sistema.
Diagrama de Estrutura Composta
O Diagrama de estrutura composta é utilizado para modelar colaborações. Uma
colaboração descreve uma visão de um conjunto de entidades cooperativas interpretadas
por instâncias que cooperam entre si para executar uma função específica.
Este diagrama fornece meios de definir a estrutura de um elemento e de focalizá-
la no detalhe, na construção e em relacionamentos internos. É um dos novos diagramas
propostos na segunda versão de UML, voltado a detalhar elementos de modelagem
estrutural, como classes, pacotes e componentes, descrevendo sua estrutura interna.
81
Então podemos dizer que o diagrama de estrutura composta reflete a colaboração
interna das classes para descrever a funcionalidade. São bem similares aos diagramas de
classes, exceto pelo fato de que eles modelam um uso específico da estrutura.
O diagrama de estrutura composta introduz a noção de “porto”, um ponto de
conexão do elemento modelado, a quem podem ser associadas interfaces. Também utiliza a
noção de “colaboração”, que consiste em um conjunto de elementos interligados através de
seus portos para a execução de uma funcionalidade específica – recurso útil para a
modelagem de padrões de projeto.