FACULDADE INTEGRAL DIFERENCIAL – FACID

CURSO DE SISTEMAS DE INFORMAÇÃO

RAFAEL SÁ CARVALHO SOUSA

MODELAGEM DE PROCESOS DE NEGÓCIO COM UML

TERESINA - PI
2008
 2

RAFAEL SÁ CARVALHO SOUSA

MODELAGEM DE PROSSESOS DE NEGÓCIO COM UML

Monografia Apresentada a
Faculdade Integral Diferencial – FACID
como requisito para a obtenção do título
de Bacharel em Sistemas de Informação.
Orientador: Prof. Msc. Guilherme Amaral
Avelino.

TERESINA - PI
2008
 3

RAFAEL SÁ CARVALHO SOUSA

MODELAGEM DE PROSSESOS DE NEGÓCIO COM UML

Monografia apresentada a
Faculdade Integral Diferencial – FACID
como requisito final para conclusão do
curso de Sistemas de Informação.

Monografia aprovada em __/__/__

BANCA EXAMINADORA

___________________________________________
Prof. Msc. Guilherme Amaral Avelino
Orientador

___________________________________________
Prof. Dr. Hudson Chagas dos Santos

___________________________________________
Prof. Msc. Leonardo Ramon
 4

AGRADECIMENTOS

Agradeço inicialmente a Deus por até aqui ter me ajudado, principalmente

nos momentos mais difíceis da minha vida.
Aos meus pais Custódio Fontes que é motivo de inspiração, a minha mãe
Leide Sá que me apoiou e possibilitou meios para eu chegar a onde estou e aos
meus irmãos que considero como pais.
Obrigado ao Prof Msc. Guilherme, orientador e professor, que aceitou ser
meu orientador bem no meio do desenvolvimento do meu projeto.
E agradeço a todas as pessoas que me ajudaram direto ou indiretamente
para o desenvolvimento deste projeto e principalmente do conhecimento que adquiri
em todo o andamento do curso. MUITO OBRIGADO a todos!
 5

Sousa, R S C. Modelagem de processo de negócio com UML. 2008. 68P.

Monografia de Conclusão de Curso (Bacharel em Sistemas de Informação).
Faculdade Integral Diferencial – FACID, Teresina, 2008.

RESUMO

A Linguagem de Modelagem Unificada (UML) surgiu com objetivo de

tornar padrão à modelagem de negócios, os sistemas apresentam visões distintas
que são abstraídas em diferentes diagramas, eles podem representar aspectos
estruturais e dinâmicos, levando em consideração a troca de mensagens, o tempo e
a mudanças de estado dos elementos. As fases da engenharia de software estão
relacionadas às etapas de criação e utilização dos diagramas ampliando a visão do
sistema a ser desenvolvido. Atualmente, é comum o uso de ferramentas de
modelagem que facilitam o desenvolvimento do software, uma dessas ferramentas é
o JUDE que torna mais fácil a criação e gerenciamento dos diagramas da UML. O
trabalho desenvolvido tem como finalidade descrever os aspectos mais genéricos da
UML levando em consideração as fases da engenharia de software. Com a UML as
pessoas envolvidas no desenvolvimento do sistema vão apresentar uma visão mais
abrangente do negócio a ser desenvolvido.

Palavras-chave: Visão, Engenharia de Software, JUDE

 6

Sousa, R S C. Business process modeling with UML. 2008. 68P. Completion of

work of course (Bachelor of Information Systems). Faculdade Integral Diferencial –
FACID, Teresina, 2008.

ABSTRACT

UML (Unified Modeling Language) has appeared with the aim to become
pattern the business modeling. The system present different aspects that are used in
different diagrams. They can represent structural and dynamic aspects taking into
account the exchange of messages, time and the elements state changes. The
phases of software engineering are related to the phases of creation and diagrams
usage improving the vision of the system to be developed. Nowadays it is common
the use of modeling tools that make the software development easier. One of such
tools is JUDE, which makes the creation and management of UML diagrams easier.
The paper aim of this paper is to describe most generic aspects taking into account
the software engineering phases. With the UML people involved in the development
of the system will present a broader view of the business to be developed.

Keywords: Vision. Software engineering. JUDE.

 7

SUMÁRIO

1. INTRODUÇÃO .................................................................................................. 1314

1.1. Motivação ...................................................................................................... 1415
1.2. Justificativa ................................................................................................... 1415
1.3. Objetivos ....................................................................................................... 1516
1.4. Organização .................................................................................................. 1516
2. IMPORTÂNCIA DA ENGENHARIA DE SOFTWARE ...................................... 1617
2.1. Primeira Crise do Software.......................................................................... 1617
2.2. Surgimento da Engenharia de Software..................................................... 1718
2.3. Métodos......................................................................................................... 1718
2.3.1. Engenharia de Requisitos ........................................................................ 1819
2.3.2. Projeto ........................................................................................................ 1819
2.3.3. Codificação ................................................................................................ 1819
2.3.4. Teste ........................................................................................................... 1920
2.3.5. Implantação ............................................................................................... 1920
2.4. Ferramentas .................................................................................................. 1920
2.5. Procedimentos ............................................................................................. 1920
3. VISÃO GERAL DA UML ................................................................................... 2021
3.1. Componentes da UML.................................................................................. 2021
3.2. Visões ............................................................................................................ 2122
3.3. Mecanismos Gerais ...................................................................................... 2223
3.4. Diagramas ..................................................................................................... 2324
3.5. Modelagem de Caso de Uso ........................................................................ 2324
3.5.1. Caso de Uso............................................................................................... 2425
3.6. Relacionamento............................................................................................ 2526
3.6.1. Relacionamento de Comunicação ........................................................... 2627
3.6.2. Relacionamento de Inclusão .................................................................... 2627
3.6.3. Relacionamento de Extensão ................................................................... 2728
3.6.4. Relacionamento de Generalização .......................................................... 2829
3.6.5. Diagrama de Caso de Uso ........................................................................ 2930
3.6.6. Construção do Modelo de Casos de Uso ................................................ 2930
3.6.7. Casos de Uso no Ciclo de Vida do Software .......................................... 3031
3.7. Modelo de Classes de Domínio ................................................................... 3031
3.7.1. Diagrama de classes ................................................................................. 3132
 8

3.7.2. Tipos de Associação ................................................................................. 3233

3.7.3. Construindo um Modelo de Classes de Domínio ................................... 3435
3.7.4. Diagrama de Objetos................................................................................. 3536
3.7.5. Modelo de classe no Ciclo de Vida do Software .................................... 3637
3.8. Modelagem de Interações............................................................................ 3637
3.8.1. Tipos de Diagramas de Interações .......................................................... 3738
3.8.2. Diagramas de Seqüência .......................................................................... 3738
3.8.3. Diagrama de Colaboração ........................................................................ 3940
3.8.4. Construindo Modelo de Interações.......................................................... 4041
3.8.5. Modelo de Interação no Ciclo de Vida do Software................................ 4041
3.9. Modelagem de Estado.................................................................................. 4041
3.9.1. Estados ...................................................................................................... 4041
3.9.2. Transições ................................................................................................. 4142
3.9.3. Evento ........................................................................................................ 4243
3.9.4. Condição de Guarda ................................................................................. 4243
3.9.5. Ações.......................................................................................................... 4243
3.9.6. Atividade .................................................................................................... 4344
3.9.7. Construção de Diagramas de Transições de Estado ............................. 4344
3.9.8. Diagrama de Estados no Ciclo de Vida do Software .............................. 4344
3.10. Modelagem de Atividades ......................................................................... 4445
3.10.1. Fluxo de Controle Concorrente .............................................................. 4445
3.10.2. Fluxo de Controle Paralelo ..................................................................... 4546
3.10.3. Construção de Diagramas de Atividade ................................................ 4647
3.10.4. Diagrama de Atividade no Ciclo de Vida do Software.......................... 4748
3.11. Diagrama de Componentes ....................................................................... 4748
3.11.1. Diagrama de Componentes no Ciclo de Vida do Software .................. 4950
4. MODELAGEM DE NEGÓCIOS ........................................................................ 5051
4.1. Ferramenta .................................................................................................... 5051
4.2. Levantamento de Requisitos....................................................................... 5152
4.2.1. Descrição do Sistema da Biblioteca ........................................................ 5152
4.2.2. Requisitos .................................................................................................. 5253
4.2.3. Atores do Sistema ..................................................................................... 5354
4.3. Diagrama de Casos de Uso ......................................................................... 5354
4.4. Especificações de Casos de Uso ................................................................ 5455
4.4.1. Caso de Uso: Pesquisa Publicação ......................................................... 5455
 9

4.4.2. Caso de Uso: Cadastrar Publicação ........................................................ 5556

4.5. Diagrama de classe ...................................................................................... 5657
4.6. Modelagem de Interações............................................................................ 5859
4.7. Diagrama de Estado ..................................................................................... 6061
4.8. Diagrama de Componentes ......................................................................... 6465
5. CONCLUSÃO ................................................................................................... 6566
6. REFERÊNCIAS ................................................................................................. 6768
 10

LISTA DE FIGURAS

Figura 1: Exemplo de estereótipo gráfico. ............................................................. 2223

Figura 2: Exemplo de nota explicativa. .................................................................. 2324
Figura 3: Exemplo de caso de uso. ....................................................................... 2526
Figura 4: Exemplo de atores. ................................................................................ 2526
Figura 5: Exemplo de relacionamento de comunicação. ....................................... 2627
Figura 6: Exemplo de relacionamento de inclusão. ............................................... 2728
Figura 7: Exemplo de relacionamento de extensão. ............................................. 2728
Figura 8: Exemplo de relacionamento de herança entre casos de uso. ................ 2829
Figura 9: Exemplo de relacionamento de herança entre atores. ........................... 2829
Figura 10: Notação de classe. ............................................................................... 3132
Figura 11: Exemplo de agregação. ....................................................................... 3334
Figura 12: Exemplo de composição. ..................................................................... 3334
Figura 13: Associação com três objetos de classes diferentes. ............................ 3435
Figura 14: Tipos de mensagens em um diagrama de seqüência. ......................... 3839
Figura 15: Exemplo do diagrama de seqüência. ................................................... 3940
Figura 16: Tipos de estado. ................................................................................... 4142
Figura 17: Exemplo de transações entre estados. ................................................ 4142
Figura 18: Exemplo de eventos entre estados. ..................................................... 4243
Figura 19: Exemplo de fluxo de controle. .............................................................. 4546
Figura 20: Exemplo de fluxo de controle paralelo. ................................................ 4647
Figura 21: Representação do conteúdo do pacote................................................ 4849
Figura 22: Exemplo de representação de interface. .............................................. 4950
Figura 23: Exemplo de subsistema. ...................................................................... 4950
Figura 24: Diagrama de caso de uso – Biblioteca. ................................................ 5455
Figura 25: Diagrama de classe – Biblioteca. ......................................................... 5758
Figura 26: Diagrama de colaboração – Cadastrar publicação. ............................. 5859
Figura 27: Diagrama de colaboração – Pesquisa publicação. .............................. 5960
Figura 28: Diagrama de colaboração – Registra empréstimo. .............................. 6061
Figura 29: Diagrama de atividade – Cadastra publicação. .................................... 6162
Figura 30: Diagrama de atividade – Pesquisa publicação. .................................... 6263
Figura 31: Diagrama de atividade – Registra empréstimo. ................................... 6364
Figura 32: Interface – Classe biblioteca. ............................................................... 6465
 11

LISTA DE TABELAS

Tabela 1: Os símbolos da multiplicidade ............................................................... 3234

Tabela 2: Classes candidatas ............................................................................... 5658
 12

LISTA DE ABREVIATURAS E SIGLAS

OOAD Object Oriented Analysis and Design

OOSE Object Oriented Software Engineering
OMT Object Modeling Technique
UML Unified Modeling Language
FACID Faculdade Integral Diferencial
RUP Processo Unificado Racional
FUD Fear, Uncertainty and Doub
DTE Diagrama de Transação de Estado
RF Requisitos Funcionais
RNF Requisitos Não Funcionais
JUDE Java and UML Developer Enviroment
MDD Desenvolvimento Orientado a Modelo
 13

1. INTRODUÇÃO

Em 1965 o engenheiro Gordon Moore, co-fundador da Intel, afirmou que

“a densidade de um transmissor dobra em um período entre 18 e 24 meses”, ou
seja, se um processador for construído hoje com capacidade de processamento X,
em dois anos, poderá construir um processador com capacidade 2X.
Com crescimento exponencial da capacidade de processamento das
máquinas, os sistemas computacionais tende a ficar mais complexos e grandes.
Com isso, surgiu a necessidade de reavaliar a forma de desenvolvê-los,
ocasionando uma revolução nas técnicas para construção dos sistemas,
especialmente no que se refere a modelagem de sistemas.
Na década de 50 e 60 os sistemas desenvolvidos apresentavam grau de
complexidade baixa, as técnicas de modelagem utilizadas eram os fluxogramas e
diagramas de módulos, os sistemas desenvolvidos eram feitos “direto ao assunto”,
ou seja, “ad-hoc”. Por volta de 1970 surgiram computadores com melhor
desempenho e mais acessíveis, conseqüentemente modelos mais robustos foram
sugeridos, como as linguagens de programação estruturada e o projeto estruturado.
Na década de 80, com elevação do poder computacional, os usuários
exigiram interfaces mais sofisticadas e diminuição do custo. Com isso, ocasionou
uma produção de softwares mais complexo dando impulso a análise estruturada.
Na década de 90 surgiu a análise orientada a objeto, sendo esta cada vez
mais utilizada pelos padrões de projeto, frameworks e componentes. Com a
maturidade de paradigma orientação a objeto, atingida, surgiram várias propostas
pra modelagem de sistemas (OOAD - Object-Oriented Analysis and Design, OOSE -
Object-Oriented Software Engineering, OMT - Object Modeling Technique:.) (BEZERRA,
2003, pag 13).
Dentre as diversas técnicas de modelagem orientada a objeto, foi
constatado que elas apresentavam diferentes noções gráficas para modelar uma
mesma perspectiva de um sistema e cada uma apresentava pontos fortes e fracos
em relação à representação utilizada. Para solucionar esse problema foram
realizados estudos pra encontrar uma linguagem que padronizasse a modelagem de
 14

sistemas. No ano de 1996, surgiu a Unified Modeling Language (UML) padronizando

as representações existentes nas diversas técnicas de modelagem de sistemas.

1.1. Motivação

Um dos grandes desafios na construção de sistemas de software é a

complexidade de seu desenvolvimento, que cresce proporcionalmente ao tamanho
do sistema. A grande maioria dos softwares desenvolvidos não utiliza técnicas de
modelagem, conseqüentemente o produto final acaba sendo de má qualidade e é
comum o prazo de entrega ultrapassar a data definida. Para amenizar esse
problema foram desenvolvidas varias técnicas de modelagem e como meio de
padronização foi definido a UML, que é capaz de compreender melhor as
funcionalidades do sistema, propor e auxiliar na implementação da solução.
A UML tem diversas ferramentas de modelagem que automatizam e/ou
facilitam o processo de construção de diagramas, sendo que este projeto visa à
descrição dos relacionamentos entre os diagramas da UML e demonstrar a
importância das ferramentas de modelagem no desenvolvimento de software.

1.2. Justificativa

No desenvolvimento de sistemas orientados a objeto as fases de

levantamento de requisitos e análise de sistemas exigem uma notação padronizada
e eficaz para uma ampla variedade de aplicações. A utilização da UML amplia a
visão de toda a equipe responsável pela criação do sistema, através do
relacionamento do banco de dados e do software, facilita a criação e identificação
dos componentes do software, melhora o entendimento do relacionamento entre as
classes, reaproveitamento das classes, criação de testes e geração de código.
O principal objetivo da UML é facilitar o desenvolvimento do projeto do
software ampliando a visão do sistema a ser desenvolvido. Esta descreve qualquer
tipo de sistema, em termos de diagramas orientado a objetos. Ele é mais utilizada na
criação de modelos de sistemas de software, mas pode ser utilizada em sistemas
 15

mecânicos sem nenhum software. Como, por exemplo, em Sistemas Técnicos e

Sistemas Real- time Integrados.

1.3. Objetivos

O objetivo principal deste trabalho é apresentar discussões e analisar a

modelagem de processos de negócios com UML. Os objetivos específicos consistem
em descrever todas as etapas do desenvolvimento do software e como elas se
relacionam umas com as outras. Além da utilização da ferramenta de modelagem
JUDE, pondo em prática os relacionamentos dos modelos de processos de um
negócio.

1.4. Organização

Além da introdução esta monografia conta com mais quatro capítulos,

como segue:
O Capítulo 2 apresenta uma descrição da 1a Crise do Software que
constou a necessidade da adoção de técnicas de desenvolvimento sólidas. Com
isso, foram realizadas várias conferências no final da década de 60 e início da
década de 70, surgindo, assim, a Engenharia de software. Neste mesmo capítulo,
foram descritos os componentes e as fases da engenharia de software.
O Capítulo 3 descreve a importância da UML para solucionar ou amenizar
muitos dos problemas que aparecem nas duas crises, além de apresentar os três
componentes que formam a UML, os principais diagramas, como eles se relacionam
entre si e como ele são utilizado nas fases da engenharia de software.
O Capítulo 4 discorre sobre o JUDE. Nele são apresentadas as principais
características e recursos desta ferramenta. Com base nela foi aplicado os conceitos
abordados nesse projeto através da modelagem de negócio com UML, tendo como
base a modelar, o sistema da biblioteca da FACID.
 16

2. IMPORTÂNCIA DA ENGENHARIA DE SOFTWARE

A Engenharia de Software passa constantemente por modificações,

principalmente quando surgem novas necessidades relacionadas ao
desenvolvimento de sistemas.

2.1. Primeira Crise do Software

Nos primórdios da era computacional, os programas eram pequenos,

normalmente escritos por uma única pessoa, eram utilizados por especialistas da
área. Os problemas enfrentados eram de natureza técnica, lidando com dados
numéricos, sendo a ênfase colocada na codificação eficiente de algoritmos bem
conhecidos (PRESSMAN, 2006, pag 2).
Ao decorrer dos anos foi aumentando o potencial do hardware e
infelizmente a habilidade de construir o software não conseguiu acompanhar as
exigências do mercado, acarretando uma série de problemas:
 A construção de software não é rápida o suficiente para atender a
demanda, os softwares exigidos pelo mercado de trabalho são muito
grandes, complexos e os usuários querem em um curto intervalo de tempo;
 Falhas das pessoas responsáveis pelo desenvolvimento de softwares
eficazes, devido a um gerenciamento sem background, profissionais da
área que não recebem ou tem recebido pouco treinamento formal em novas
técnicas para desenvolvimento de software. Com isso ficam evidentes as
dificuldades em:
 Identificar os requisitos;
 Produtividade da equipe;
 Falta de qualidade e viabilidade do software, sendo muitos erros
detectados após a entrega;
 O esforço de construir um software de qualidade fica muito complexo,
pois não é estabelecido nenhum conceito de qualidade sólido;
 17

 O suporte dos programas desenvolvidos é apoiado por uma

documentação pobre e com recursos inadequados, tornando a construção
do software mais lenta, apresenta dificuldades em prevê o progresso
durante o desenvolvimento e dificuldade em realizar a manutenção;
 Com uma documentação fraca e com a falta de treinamento e
entretenimento da equipe com o próprio usuário ocasiona uma
insatisfação no lado do cliente;

2.2. Surgimento da Engenharia de Software

Com a crise dos anos 60 ficou evidente a necessidade de adotar novas

técnicas de desenvolvimento sólidas e comprovadas pro desenvolvimento do
software. Foram feitas várias conferências nos finais dos anos 60 e início dos anos
70, em que surgiu o termo “Engenharia de Software”, fazendo uma analogia à forma
como a engenharia civil atua na elaboração e construção de casa e apartamentos.
A engenharia de software se ocupa de todas as etapas da produção do
software, desde os estágios iniciais de especificação do sistema até a manutenção
levando em consideração orçamento.
A engenharia de software é composta por três elementos fundamentais
(método, procedimentos e ferramentas) que devem apoiar no compromisso
organizacional com a qualidade do software e aumentar a produtividade do pessoal
responsável pela criação do software, tendo como conseqüência a satisfação do
usuário.

2.3. Métodos

Proporcionam os detalhes de “como fazer” para construir o software

envolvem um amplo conjunto de tarefas que inclui os seguintes tópicos a seguir. Os
métodos da engenharia de software incluem técnicas de modelagem e outras
técnicas descritivas que vão auxiliar na produção do software. Um exemplo, são os
 18

métodos para descoberta das classes de análise no RUP (Processo Unificado

Racional).

2.3.1. Engenharia de Requisitos

O desenvolvedor conversa com o cliente para definição das

funcionalidades e das restrições do software para obter a melhor solução para o
problema sem se preocupar com os detalhes da tecnologia e fornecer a todos os
desenvolvedores um entendimento escrito dele. E tendo como produto: cenários de
usuários, lista de funções e de características, modelos de análise, especificação
(diagrama de estado, de atividade, de classes, etc).

2.3.2. Projeto

Determina como o sistema funcionará para atender aos requisitos

especificados de acordo com os recursos tecnológicos existentes. Ocorre a
representação das estruturas dos componentes de dados e programas que são
necessários para construir um sistema baseado em computador.
Nesta fase são propostos modelos através de diagramas que vão
representar: a arquitetura, a interface e os componentes.

2.3.3. Codificação

O sistema é codificado traduzindo a descrição computacional obtida na

fase de projeto em código executável mediante o uso de uma ou mais linguagens de
programação. Vai resultar em instruções executáveis seguindo as operações obtidas
na fase de análise.
 19

2.3.4. Teste

O software é testado para descobrir erros que foram feitos

inadvertidamente no momento em que foi projetado e construído. Após o termino da
fase de teste pode ser feito documentação de cada teste feito na lógica interna,
interface, colaboração de componentes, requisito externo, documentação.

2.3.5. Implantação

O sistema é empacotado, distribuído e instalado no ambiente do usuário,

os manuais do sistema são escritos, os arquivos são carregados, os dados são
importados para o sistema e os usuários são treinados para utilizar o sistema
corretamente.

2.4. Ferramentas

As ferramentas de engenharia de software estabelecem apoio

automatizado ou semi-automatizado para os processos e para os métodos. Há
casos nos quais as ferramentas são integradas de modo que a informação criada
por uma ferramenta possa ser usada por outra.

2.5. Procedimentos

O processo é o elo entre os métodos e as ferramentas utilizados na

fabricação do software, em que se define a seqüência dos métodos que serão
aplicados, os produtos que são exigidos na entrega, as atividades de controle de
qualidade, coordenar as alterações e os milestones1 de avaliação de progresso.

1 Milestones: São técnicas utilizadas para demarcar pontos de verificação.

 20

3. VISÃO GERAL DA UML

No desenvolvimento de sistemas orientados a objeto as fases de

levantamento de requisitos, análise de sistemas e design exigem uma notação
padronizada e eficaz para uma ampla variedade de aplicações. Além dessas
características a UML possibilitou o desenvolvimento de novos conceitos não
normalmente utilizados na programação orientada a objetos.
A utilização da UML amplia a visão de toda a equipe responsável pela
criação do sistema, através do relacionamento entre o banco de dados e o software,
criação de componente do software, melhor entendimento do relacionamento entre
as classes, reaproveitamento das classes, criação de testes e geração de código.

3.1. Componentes da UML

A UML é formada por três componentes baseados nas cinco fases do

desenvolvimento do software (análise, projeto, codificação, teste e implantação):
visões, diagramas e mecanismo gerais.
As visões mostram diferentes aspectos do sistema que está sendo
modelado. A visão não é um gráfico, mas uma abstração consistindo em uma série
de diagramas.2 Uma ampla variedade de visões pode ser utilizada para mostrar
aspectos específicos do sistema com diferentes níveis de abstração, ela pode ser
utilizada nas ligações entre a linguagem de modelagem e auxiliar no
desenvolvimento de cada uma das fases da engenharia de software.
Os mecanismos gerais são formados por informações e/ou comentários
para tornar mais fácil e dinâmico o entendimento da equipe de desenvolvimento.
Pode-se estender a UML para ser utilizado por usuários específicos, organizações e
até mesmo no método/processo.

2 Disponível em: www.apostilando.com/download.php?cod=2038&categoria=Outras%2 0Apostilas,

acessado em 19 de março de 2008.
 21

Os diagramas são representações de gráficos que descrevem o conteúdo

de uma visão. Os conceitos utilizados na construção dos diagramas são
semelhantes a programação orientada a objetos como classes, objetos,
relacionamento, mensagens, herança, dependência e associação. Serão descritos
os principais diagramas da UML: diagrama de caso de uso, de classes, de objetos,
de estado, de seqüência, colaboração, de atividade e de componente, eles são
combinados para representar as visões do sistema.

3.2. Visões

O desenvolvimento de um sistema complexo e grande é uma tarefa muito

difícil, infelizmente um sistema não pode ser descrito em um único gráfico, pois ele
seria incapaz de capturar e representar todas as informações necessárias.
Desta forma, é utilizado um certo número de visões pra representar
aspectos particulares do sistema, descrever os diversos aspectos funcionais3, não
funcionais4 e as restrições5 do sistema. As visões que formam um sistema são:
 Visão lógica: descreve como o sistema será implementado com suas
funcionalidades, estabelece as estruturas estáticas (classes, objetos e
relacionamentos) e dinâmicas (troca de mensagens entre os objetos). Na
estrutura estática são feitos os diagramas de classe e objetos. Já na
modelagem dinâmica são feitos os diagramas de estado, seqüência,
colaboração e atividade.
 Visão componente: descreve a implementação e a dependência dos
módulos.
 Visão de concorrência: debate sobre o processamento do sistema,
essa visão esta focada no aspecto não funcional do sistema, define quais
tipos de eventos síncronos e assíncronos podem ocorrer no sistema,

3 Aspectos funcionais: é composto por uma estrutura estática e interações dinâmicas.

4 Aspectos não funcionais: descreve as características de qualidade que estão relacionadas às
funcionalidade.
5 Restrições: são obstáculos impostos no desenvolvimento do sistema. Como por exemplo:
plataforma tecnológica, interface com usuário, adequação de custo.
 22

permitindo um melhor desempenho deste. É representado no diagrama de

estado, seqüência, colaboração, atividade, componente e execução.
 Visão de organização: descrição das instalações físicas do sistema
(computadores e periféricos). Esta visão é representada pelo diagrama de
execução.

3.3. Mecanismos Gerais

Na construção dos diagramas é necessário utilizar estereótipos6 para

facilitar a comunicação dos envolvidos no desenvolvimento do sistema, a equipe de
desenvolvimento deve definir e utilizá-los de forma consistente para tornar sua
semântica compreensível a todos os envolvidos.
Há dois tipos de estereótipos: estereótipos gráficos e estereótipos de
rótulo.
 Um estereótipo gráfico é representado por um ícone que apresenta um
significado semelhante ao elemento associado. A Figura 1 apresenta
exemplos de estereótipos gráficos.

Figura 1: Exemplo de estereótipo gráfico.

 Um estereótipo de rótulo é representado por um nome que fica entre

símbolos para distinguir dos demais elementos do diagrama. Exemplo:
<<interface>>, << entidade>>:.

6 Estereótipo: É um metatipo, ou seja, define o significado de um elemento em um diagrama.

 23

Os comentários são feitos por notas explicativas, podendo ser

representadas em texto livre ou em linguagem de restrição de objetos da UML,
exemplo na Figura 2.

Figura 2: Exemplo de nota explicativa.

3.4. Diagramas

A UML é formada pelos diagramas de caso de uso, de classes, de

objetos, de estado, de seqüência, colaboração, de atividade e de componente.
Os diagramas podem apresentar estruturas estáticas, como é o caso do
diagrama de classes e diagrama de objeto. Os componentes dinâmicos são
representados pelos diagramas de estado, seqüência, colaboração e atividade. O
modelo funcional é aplicado nos diagramas de estado, seqüência, colaboração e
atividade. Os modelos dinâmicos são suportados pelos diagramas de componentes
e execução.

3.5. Modelagem de Caso de Uso

“O modelo de casos de uso é uma representação das funcionalidades

externamente observáveis do sistema e dos elementos externos ao sistema que
interagem com ele.” (BEZERRA, 2003, pag 45). O modelo de caso de uso é uma
técnica utilizada para descrever e definir os requisitos dos sistemas. Com ele, torna-
se mais fácil direcionar as tarefas que serão realizadas no clico de vida do software,
além de forçar a modelagem do sistema de acordo com as especificações do
usuário, evitando que o usuário se adapte ao sistema.
 24

A modelagem com caso de uso foi iniciada pelo engenheiro de software,

Ivar Jacobson, na década de 1970 em que a técnica foi incorporada no
desenvolvimento de um projeto denominado Objector (1992, apud BEZERRA, 2003,
pag 45). Mais tarde a técnica foi incorporada pela UML (Jacobson et al. 1992).
O modelo de caso de uso é formado por caso de uso, atores e
relacionamentos entre eles.

3.5.1. Caso de Uso

Um caso de uso consiste na representação de uma seqüência de ações

entre os atores e o sistema, sem levar em consideração o comportamento interno do
sistema.
A descrição do caso de uso é feito de forma narrativa, a UML não define a
forma, o grau de abstração e o grau de detalhamento.
Os formatos mais utilizados são: descrição continua, numérica e
particionada. Na descrição continua, é feito um texto narrativo, na numerada é feita
uma numeração de cada passo, e na particionada ocorre uma divisão entre cliente e
sistemas, a qual apresenta a seqüência de interações descritas para cada um. É de
fundamental importância que a descrição seja de fácil entendimento para a equipe e
principalmente para o cliente.
O grau de abstração está relacionado com a utilização ou não da
tecnologia, pode ser classificado como: caso de uso essencial que não faz menção a
tecnologia utilizada e em caso de uso real que necessita de tecnologia no seu
projeto, como por exemplo, a utilização de leitor de código de barra para
identificação do produto.
Graficamente os casos de uso são representados por uma elipse,
exemplo na Figura 3, cujo nome do caso de uso é Reservar Livro.
 25

Figura 3: Exemplo de caso de uso.

Na UML um ator é considerado qualquer entidade externa que interaje

com sistema, ou seja, o ator realiza trocas de informações com sistema. Os atores
podem ser pessoas (aluno, professor, funcionária e etc), organizações
(Administradora de cartões), outros sistemas (sistema de controle de matrícula) ou
equipamentos (leitora de código de barra, sensor, etc).
É de fundamental importância que o nome dado ao ator deva lembrar a
sua atuação no sistema, podendo atuar em vários casos de uso ou um caso de uso
pode evolver várias pessoas. Com isso, os atores são classificados em dois tipos:
atores primários que iniciam uma seqüência de interações com sistema e os atores
secundários que auxiliam na utilização do sistema. Como por exemplo, um aluno liga
para biblioteca da faculdade desejando renovar um livro, o funcionário consulta o
sistema da biblioteca e realiza as operações de renovação. Nesse exemplo o aluno
é o ator primário e o funcionário é o ator secundário.
Na UML os atores são representados por retângulos ou por ícones
humanos, exemplo: ator Funcionário e ator Aluno na Figura 4,

Figura 4: Exemplo de atores.

3.6. Relacionamento

Os relacionamentos são responsáveis pela comunicação entre atores,

casos de uso e entre eles mesmos. A UML possui diversos tipos de
 26

relacionamentos, dentre eles estão: comunicação, inclusão, extensão,

generalização, dependência e refinamento.

3.6.1. Relacionamento de Comunicação

O relacionamento de comunicação ocorre quando os atores são

associados aos respectivos casos de uso, há casos nos quais um ator pode se
relacionar com vários casos de uso, conseqüentemente um diagrama de casos de
uso é obrigatório ter pelo menos um relacionamento de comunicação.
No exemplo da Figura 5 o aluno realiza o relacionamento do caso de uso
reserva livro.

Figura 5: Exemplo de relacionamento de comunicação.

3.6.2. Relacionamento de Inclusão

O relacionamento de inclusão ocorre quando um comportamento comum

se repete em mais de um caso de uso, ele deve ser definido em um novo caso de
uso. Esse tipo de relacionamento só ocorre entre caso de uso.
Na Figurar 6, o sistema da biblioteca utiliza a busca para realizar a
reserva, a exclusão e listagem do livro especificado. A busca pode ser acoplada em
um único caso de uso, servindo tanto para excluir, reservar e listar livros
especificados.
 27

Figura 6: Exemplo de relacionamento de inclusão.

3.6.3. Relacionamento de Extensão

A extensão representa a descrição de um comportamento opcional do

caso de uso, ou seja, o estendido, representa diferentes situações nas quais uma
seqüência de interações pode ocorrer.
No sistema da biblioteca o aluno pode solicitar o empréstimo de livros,
caso o livro não esteja disponível o aluno pode optar por fazer reserva do livro, como
observado na Figura 7.

Figura 7: Exemplo de relacionamento de extensão.

 28

3.6.4. Relacionamento de Generalização

A generalização consiste no reuso entre casos de uso ou entre atores,

esse relacionamento nada mais é que herdar características genéricas de outros
elementos.
A herança entre casos de uso permite o reaproveitamento da seqüência
de comportamento do caso de uso, a parte que não for reaproveitada será
redefinida. No exemplo da Figura 8, o caso de uso cadastra de revista pode ser
herdado pelo caso de uso cadastrar.

Figura 8: Exemplo de relacionamento de herança entre casos de uso.

A herança entre atores consiste na absorção de características de outro

ator já definido.
Na Figura 9 tem um exemplo de um funcionário da faculdade que pode
estudar na própria faculdade e conseqüentemente o funcionário herda
características do aluno.

Figura 9: Exemplo de relacionamento de herança entre atores.

 29

3.6.5. Diagrama de Caso de Uso

O principal objetivo do caso de uso é fornecer uma documentação que

permita o entendimento da equipe de desenvolvimento e do usuário final, para
debater e analisar as funcionalidades do sistema. É de fundamental importância que
o caso de uso seja simples e fácil compreensão, pois muitas vezes eles são
complexos e fornece uma visão distorcida do sistema.

3.6.6. Construção do Modelo de Casos de Uso

Na fase de levantamento de requisitos são identificados os atores, a partir

deles são identificados os casos de uso e o relacionamento entre os processos.
Na documentação é preciso ter:
 Uma breve descrição dos atores que descrevem o caso de uso.
 O nome do caso de uso. É de fundamental importância que o nome
seja único.
 Um identificador para facilitar o gerenciamento na identificação do caso
de uso.
 O grau de importância, ele pode ser classificado de diversas maneiras,
levando em consideração a prioridade e o risco, como por exemplo:
 Risco alto e prioridade alta
 Risco alto e prioridade baixa
 Risco baixo e prioridade alta
 Risco baixo e prioridade baixa
 O sumário faz uma descrição superficial do caso de uso.
 Os nomes dos Atores primários e Secundários.
 O fluxo principal, o qual representa uma descrição de uma seqüência
de ações em um acontecimento normal.
 O fluxo alternativo, descreve uma alternativa escolhida pelo ator, cujo
difere do fluxo principal.
 O fluxo de exceção, que ocorre quando algo inesperado ocorre quando
acontece entre uma interação do ator e do caso de uso.
 30

 A pós-condição representa uma resposta em decorrência a uma

seqüência de ações, ou seja, é um estado alcançado depois a execução
de um caso de uso.

3.6.7. Casos de Uso no Ciclo de Vida do Software

A construção do caso de uso pode ocorrer em fases de engenharia de

requisito, projeto e “desenvolvimento”.
Na engenharia de requisitos são identificados os atores e os casos de
uso, sendo que outros casos de uso podem ser identificados.
Na fase de projeto são feitos os desenhos dos diagramas de casos de
uso e são ordenados com o grau de prioridade e risco.
Os casos de uso são agrupados de acordo com a interação, na fase de
desenvolvimento.

3.7. Modelo de Classes de Domínio

O modelo de caso de uso dá uma visão do ponto de vista externo, mais

internamente os objetos que compartilham mensagens uns com os outros para
obtenção de resultados visíveis pro usuário não são representados no diagrama.
A representação do comportamento interno de um sistema é feita por dois
tipos de colaborações entre os objetos:
 Aspecto dinâmico: corresponde à troca de mensagens entre objetos
que são representados nos diagramas de interações e estado.
 Aspecto estrutural estático: no ponto de vista estrutural se refere a
forma que os componentes do sistema estão organizados internamente,
tornando possível a visualização das classes de objetos e das relações
entre eles. É dito estático porque não apresenta informações sobre o
comportamento dos objetos ao decorrer do tempo. A representação é feita
através do diagrama de classes.
 31

3.7.1. Diagrama de classes

O diagrama de classes demonstra a estrutura estática das classes, ele é

utilizado desde a análise até a especificação. De todo os diagramas da UML, ele
apresenta maior detalhes em suas notações.
Os elementos que compõem classe em um diagrama de classes
consistem em:
 Nome da classe que inicia com a primeira letra das palavras em
maiúscula e no singular.
 Os atributos são informações que o objeto armazena.
 As operações são ações que o objeto pode realizar.
Eles são representados graficamente na ordem em que esta Figura 10,

Nome da Classe
lista de atributos
lista de operações

Figura 10: Notação de classe.

Para que as classes possam interagir uma com as outras é preciso que os
objetos se relacionem através da associação, cujo objeto A é usado por B. A
associação consiste em uma linha reta que liga as classes, possibilitando o
relacionamento entre objetos. No exemplo da Figura 9, um aluno realiza reserva do
livro.

Figura 9: Exemplo de associação.

 32

Os objetos são representados por um retângulo e para tornar mais legível

é atribuída uma seta indicando o direcionamento da leitura e um nome de
associação que fica na linha da associação.
Com a associação é possível especificar a quantidade de objetos
associados com a multiplicidade7. A Tabela 1 apresenta os possíveis símbolos de
multiplicidade.

Tabela 1: Os símbolos da multiplicidade

Nome Símbolos
Apenas Um 1
Zero ou Muitos 0..*
Um ou Muitos 1..*
Zero ou Um 0..1
Intervalo Especifico x..y

No intervalo específico os X e Y são substituídos pelos valores de limite

superior e inferior.

3.7.2. Tipos de Associação

A agregação é um dos tipos de associações. “Uma agregação é utilizada

para representar conexões entre objetos que guardam uma relação todo-parte entre
si.” (BEZERRA, 2003, pag 104), ou seja, o objeto A é parte do objeto B. Na Figura
11, a revista faz parte da biblioteca.

7 Multiplicidade: representa os limites inferior e superior do objeto.

 33

Figura 11: Exemplo de agregação.

Outro tipo de associação muito utilizado é a composição que apresenta

uma relação mais forte entre os objetos, ou seja, o objeto A é parte essencial do
objeto B, se B for eliminado automaticamente A também será eliminado. O exemplo
da Figura 12, o aluno é parte essencial da biblioteca.

Figura 12: Exemplo de composição.

“As classes associativas são classes que estão ligadas a associações, em

vez de estarem ligadas a outras classes”. (BEZERRA, 2003, pag 105). Normalmente
a classe associativa acontece quando mais de uma classe tem uma associação e
necessita das informações das demais associações, ela pode se conectar com
qualquer tipo de associação.
No caso das classes associativas não é permitido a nomeação da linha
que conecta a associação, é de fundamental importância que o nome da classe seja
de fácil compreensão.
Para realizar a associação com três objetos de diferentes classes utiliza
se uma associação ternária, exemplo na Figura 13.
 34

Figura 13: Associação com três objetos de classes diferentes.

3.7.3. Construindo um Modelo de Classes de Domínio

O primeiro passo na construção do modelo de classes é a identificação

das classes e objetos que vão compor o sistema.
A identificação das classes é feita em duas etapas:
 Primeira etapa: “classes candidatas, (ou seja, entidades que podem se
tornar classes) são identificadas.” (BEZERRA, 2003. pag 109).
 Segunda etapa: Após ter identificado as possíveis classes é feito um
refinamento para identificar quais são as possíveis classes. Há duas
formas de identificar as classes de um domínio: método dirigido a dados e
métodos dirigido à responsabilidades.
Os objetos de um sistema apresentam alguns tipos de responsabilidades,
eles são caracterizados em objetos de entidade, objetos de controle e objetos de
fronteira.
 Objeto de entidade: são responsáveis por armazenar informações
persistentes do sistema, geralmente são dados gravados no banco de
dados. Os atores que interagem com sistema interagem com outros
objetos para terem acesso aos objetos de entidade.
 Objetos de fronteira: são objetos que fazem a interação com ator,
desde os eventos gerados pelo ator até as respostas apresentadas pelo
ator. É de fundamental importância que objetos de fronteira considerem
somente objetos com informações externas e os resultados gerados pelo
sistema sejam repassados ao objeto de fronteira.
 Objetos de controle ou controlador: é responsável por interligar a
comunicação com ator (objetos de fronteira) e as informações
 35

armazenadas do sistema (entidade), por isso são considerados ativos. O

controlador controla a lógica de execução do caso de uso.
O modelador verifica se há classes redundantes ou incompetentes,
através de questionamentos dos seus colaboradores8 e das responsabilidades9
atribuída às classes identificadas.
Após validar as classes inicia o mapeamento do relacionamento entre as
classes, identificando as classes que necessitam de colaboração e qual será o tipo
de associação. Deve-se verificar os tributos associados entre as classes para
garantir a compatibilidade do valor armazenado pelo atributo.
Identificado e mapeado as classes, objetos, responsabilidade e
colaboradores, o documento é finalizado resultando no modelo de classes de
domínio. As classes devem ser posicionadas permitindo a leitura da direita para
esquerda e de cima pra baixo, essa medida é adotada para facilitar a leitura das
pessoas que na maioria das vezes são ocidentais, cujo seu hábito de leitura é o
mesmo utilizado na leitura do modelo de classes de domínio.

3.7.4. Diagrama de Objetos

O diagrama de objeto ou diagrama de instância é um diagrama de classes

que exibe objetos instanciados de suas respectivas classes, ele exibe um perfil do
sistema em um certo momento de sua execução, apresentando estruturas estáticas.
Há uma grande semelhança entre o diagrama de classe e o de objeto,
mais o diagrama de objeto apresenta objetos com nome sublinhado e todas as
instâncias do relacionamento são mostradas. Pelo fato de ser semelhante o
diagrama de objeto dificilmente é utilizado, sendo adotado apenas em
relacionamento complexos de um diagrama de classe.

8 Colaboração: é quando um objeto necessita de outro objeto pra cumprir sua tarefa.
9Responsabilidade: Corresponde a obrigação que um objeto tem com sistema no qual ele está sendo
utilizado.
 36

3.7.5. Modelo de classe no Ciclo de Vida do Software

Na fase de análise é possível identificar as classes essenciais e criar um

diagrama de classe a partir do modelo de caso de uso com as principais
funcionalidades do sistema.
Com ajuda do modelo de caso de uso o modelador verifica a consistência
e redundância entre os dois diagramas. Caso haja alguma irregularidade um dos
modelos é modificado podendo adicionar ou retirar detalhes do modelo.
As fases de análise e projeto não são muito distintas na construção dos
dois modelos, inicialmente é considerada a fase de análise, a fase de projeto inicia
na medida em que o desenvolvimento evolui, ou seja, após descrever os principais
componentes dos casos de uso e dos diagramas de classe.
Mesmo com essa documentação a visão do sistema ainda esta
incompleta, há especificações do aspecto dinâmico do sistema a serem definidos na
fase de projeto, utilizam os modelos de interações, modelo de estado e modelo de
atividades.

3.8. Modelagem de Interações

Diferente dos modelos de caso de uso e classes de domínio, o modelo de

interações representa as trocas de mensagens entre os objetos durante a execução
de casos de uso do sistema, ele fornece um entendimento do problema focando os
aspectos dinâmicos do sistema.
O principal responsável pela interação são as trocas de mensagens entre
os objetos do sistema, há alguns tipos de mensagens, como:
 Mensagem simples: ocorre quando o conteúdo da mensagem é
revelado para seu respectivo destinatário.
 Mensagem síncrona: o objeto remetente fica bloqueado aguardando a
resposta do receptor.
 Mensagem assíncrona: o objeto remetente fica esperando a resposta
do receptor.
 37

Para entender os aspectos dinâmicos do sistema utiliza se o diagrama de

interações que representa o comportamento interno do programa. Em um caso de
uso pode haver vários diagramas de interações, mais se o caso de uso for simples
um único diagrama de interações pode modelar o caso de uso como um todo.

3.8.1. Tipos de Diagramas de Interações

Há dois tipos de diagramas de interações: diagrama de seqüência e

diagramas de colaboração, a diferença entre eles esta no enfoque dado os objetos,
os diagramas são equivalentes, ou seja, pode se utilizar um dos diagramas para
modelar o outro. O diagrama de seqüência dá ênfase no decorrer do tempo já o
diagrama de colaboração dá ênfase ao contexto do sistema.

3.8.2. Diagramas de Seqüência

“No diagrama de seqüência a ênfase está na ordem temporal das

mensagens trocas entre os objetos.” (BEZERRA, 2003, pág 148), ou seja, o
diagrama foca nas mensagens enviadas no decorrer do tempo.
O diagrama de seqüência é composto por:
 Atores que compõem o caso de uso.
 Objetos do caso de uso a ser representado, a sua posição indica o
momento no qual ele inicia a sua participação, caso o objeto exista desde
o início ele deve ser posicionado no topo do diagrama.
 As classes só são representadas quando a mensagem for endereçada
para ela.
 Linha de vida representada por uma linha vertical.
 Mensagens são representadas por uma flecha na horizontal ligando a
linha de vida. A passagem do tempo é representada de acordo com a
seqüência da direção vertical, no sentido de cima para baixo, ou seja,
quanto mais para baixo uma mensagem aparece no diagrama mais tarde
 38

foi o tempo da mensagem enviada. Na Figura 14 tem os tipos de

mensagens utilizado no diagrama de seqüência.

Figura 14: Tipos de mensagens em um diagrama de seqüência.

 O foco de controle representa o tempo que um objeto executa uma

ação, ele inicia no momento em que a mensagem é recebida e a parte de
baixo do foco de controle indica o término da ação realizada em um o
objeto. No exemplo da Figura 16 tem um ator enviando a mensagem0
simples para o objeto1, o objeto1 envia a mensagem1 ao objeto2, ao
mesmo tempo objeto1 envia a mensagem3 a Classe, após receber a
mensagem o objeto2 envia a mensagem2 paralela a mensagem3 para a
Classe, depois o objeto1 envia a mensagem de retorno ao ator.
 39

Figura 15: Exemplo do diagrama de seqüência.

3.8.3. Diagrama de Colaboração

O diagrama de colaboração mostra a colaboração dinâmica entre os

objetos, ou seja, demonstra como os objetos se relacionam durante a troca de
mensagens de um caso de uso.
A principal diferença entre o diagrama de colaboração e o diagrama de
seqüência é que este dá ênfase ao tempo, já o diagrama de colaboração dá ênfase
no contexto do sistema.
A notação dos objetos e das classes é semelhante a do diagrama de
seqüência, os relacionamentos são os mesmos dos diagramas de classes
(associação, agregação, composição, etc)
Como o diagrama não mostra o tempo decorrido de uma ação, a ordem
das mensagens enviadas é representada através das expressões de seqüência.
 40

3.8.4. Construindo Modelo de Interações

Como base no caso de uso e no conjunto de cenários especificados, são

identificados os componentes (atores, objeto e mensagens) e criado o diagrama de
interação, pode correr a necessidade de adicionar novas classes.

3.8.5. Modelo de Interação no Ciclo de Vida do Software

A distinção entre as fases de análise e projeto não é tão nítida na

modelagem orientada a objeto, inicialmente o modelo de interação inicia na fase de
análise, à medida que as especificações evoluem a modelagem é feita na fase de
projeto.
Na fase de análise, o diagrama de interação pode começar a ser
construído após a definição da primeira versão do diagrama de classes, o objetivo
do diagrama de interação é fornecer informações adicionais para aprimorar outros
modelos e disponibilizar informações detalhadas aos programadores.

3.9. Modelagem de Estado

O diagrama de transação de estado (DTE) é utilizado para obter

representações dinâmicas do sistema, assim como o diagrama de interação, mais o
DTE realiza a descrição do comportamento dos objetos de uma determinada classe,
ou seja, quando acontece um evento interno ou externo ocasionando mudanças
para um outro estado e a execução de operações.

3.9.1. Estados

“Um estado é uma situação na vida de um objeto durante a qual ele

satisfaz alguma condição ou realiza alguma atividade.” (BEZERRA, 2003, pag 209).
 41

O estado de um objeto é determinado por dois valores um com seus atributos e o

outro com as ligações com objetos relacionados a ele.
Na UML o estado é representado por um retângulo com bordas
arredondadas. Há também o estado inicial do objeto que representa a inicialização
do objeto no diagrama e o estado final que consiste no termino do estado, são
representados com base na Figura 16.

Figura 16: Tipos de estado.

3.9.2. Transições

A transição consiste na troca de mensagens entre os estado associados.

A transição é considerada disparada quando uma linha saindo de um estado e
apontando para o outro estado associado a ela. Exemplo na Figura 17.

Figura 17: Exemplo de transações entre estados.

Associados a transição estão os eventos, a ação e as atividades que são

rotuladas com a seguinte expressão.

Evento (lista de parâmetros)[guarda]/ação

 42

3.9.3. Evento

“Uma transação possui um evento associado. Um evento é algo que

acontece em algum tempo e que pode modificar o estado de um objeto.” (BEZERRA,
2003, pag 211). Os eventos podem conter uma lista de parâmetros para os objetos
receptores. Na Figura 18 temos o estado 1 realizando uma evento associado ao
estado 2.

Figura 18: Exemplo de eventos entre estados.

3.9.4. Condição de Guarda

Uma condição de guarda pode ser composta por uma expressão lógica,
por parâmetros passados em eventos e atributos.
A condição de guarda em uma transação só é disparada caso ocorra um
evento de mudança e a condição for verdadeira. Para não confundir expressão de
guarda com evento, a condição de guarda é representada dentro de colchetes, já as
expressões condicionais de mudança de estado dos eventos são representadas com
cláusulas if, when:.

3.9.5. Ações

No momento em que o estado esta modificando o objeto, pode se realizar

ações no objeto. A ação pode ser determinar com operações, com atributos ou com
parâmetros dos eventos.
 43

3.9.6. Atividade

A atividade é executada pelo objeto, assim como a ação. Porém a

atividade pode ser interrompida, já a ação não pode ser interrompida, pois seu
tempo de execução é muito curto. Além da atividade estar associada a um estado e
a ação esta associada a uma determinada transição.

3.9.7. Construção de Diagramas de Transições de Estado

Inicialmente são identificados os estados de um objeto através dos seus

atributos e das possíveis ligações com outros objetos.
Já nas transações são identificados os eventos que podem originá-la e se
há e quais os fatores para realização do disparo da transição. Caso exista deve ser
especificada quais são as condições de guarda da transição. Com auxilio da
descrição de casos de uso torna se mais fácil identificar os eventos externo e com o
diagrama de interação é facilitada a identificação dos eventos internos, pois a
representação das mensagens trocadas entre os objetos são solicitações de um
objeto a outro objeto e essas solicitações são eventos.
O diagrama de estado não é utilizado em todas as classes identificadas,
mais ele é adotado em classes que apresentam comportamento dinâmico muito
elevado ou em objetos que participam em diversos casos de uso do sistema.
Após ter identificados as classes, os objetos, os estados e os eventos.
Realiza-se a identificação dos possíveis relacionamentos entre eles.

3.9.8. Diagrama de Estados no Ciclo de Vida do Software

O diagrama de estado ocorre na fase de projeto, com base no caso de

uso, no diagrama de interação e no diagrama de classe,
É comum serem adicionados novos atributos e/ou novas operações no
diagrama de estado como no modelo de classe, principalmente nas classes de
implementação.
 44

3.10. Modelagem de Atividades

Um diagrama de atividade é um diagrama de estado que captura ações e

seus resultados na mudança de estado do objeto. Com o diagrama torna se mais
fácil demonstrar as interações, as ações que são executadas, as mudanças de
estado que ocorrem, onde e quando elas são executadas.
O diagrama apresenta uma semelhança com fluxograma mais apresenta
uma semântica um pouco diferente, além de representar ações concorrentes (fluxo
de controle concorrente) e paralelas (fluxo de controle paralelo).

3.10.1. Fluxo de Controle Concorrente

Um diagrama de atividade demonstra a execução passo a passo de um

algoritmo. Os passo para solucionar o problema corresponde aos estados, eles
podem ser classificados em estado atividade que necessita de um certo período de
tempo para ser finalizado e estado ação que é realizado instantaneamente.
Para dar origem e término a execução é necessário um estado inicial e
um ou mais estados finais, mais o processo pode não ter fim, com isso, é
considerado um processo assíncrono.
Um ponto de ramificação apresenta uma única transição e possui várias
transições de saídas, em cada saída apresenta uma condição de guarda sem que
um delas de ser verdadeira.
O ponto de união consiste na junção de diversas transições.
No exemplo da Figura 19 o estado 1 tem duas opções: a primeira é
executar os estados 2 e 4 e a segunda opção é escutar os estado 3 e5 para chegar
ao estado 6.
 45

Figura 19: Exemplo de fluxo de controle.

3.10.2. Fluxo de Controle Paralelo

O fluxo de controle paralelo ocorre quando há mais de um fluxo de

controle sendo executado simultaneamente em um diagrama de atividade. Há dois
tipos:
 Barra de bifurcação: ocorre quando a barra recebe uma transição de
entrada cria mais de um fluxo de controle paralelo.
 Barra de junção: ocorre quando a barra recebe mais de uma transição
de entrada e junta os fluxos de controle em um único fluxo.
 46

Na Figura 20 o estado 1 pode executar simultaneamente os estado 2 e 3 e

gerando o estado 4.

Figura 20: Exemplo de fluxo de controle paralelo.

3.10.3. Construção de Diagramas de Atividade

Normalmente não se usa um diagrama de atividade, ele é construído para

melhorar o entendimento do problema, ou seja, ele descreve o comportamento dos
casos de uso do sistema em relação ao decorrer do tempo.
 47

Com ele pode-se descrever em um único diagrama os fluxos principais,

alternativos e de exceção, deve ser ressaltado que o diagrama de atividade vai
implementar a descrição do caso de uso, pois as informações descritas no caso de
uso são baseada nos atores, já o diagrama de atividade vai descrever as possíveis
atividades que ocorrem internamente no sistema.

3.10.4. Diagrama de Atividade no Ciclo de Vida do Software

O diagrama de atividade é semelhante ou diagrama de estado, pois

ambos ocorrem na fase de projeto e utiliza o caso de uso, o diagrama de interação.

3.11. Diagrama de Componentes

Um sistema orientado a objeto é formado por objeto que se relacionam

entre se, através da troca de mensagens. Esses objetos apresentam
comportamentos específicos de acordo com a definição de sua classe.
Como os objetos apresentam comportamentos diferentes, qual é forma
que esses objetos sejam decompostos em diversos subsistemas e como as classes
vão se relacionar uma com as outras? E quando o sistema for implantado como
dever ser distribuído fisicamente?
Essas perguntar estão relacionadas à arquitetura do projeto, ou seja,
“representa a estrutura dos componentes de dados e programas que são
necessários para construir um sistema baseado em computador” (PRESSMAN,
2006, pag 207).
Na estruturação dos componentes deve levar em consideração os
seguintes termos:
 Pacotes: Tem como finalidade agrupar várias classes e artefatos de um
modelo, como por exemplo, casos de uso. Os elementos de um pacote
podem ter acesso público, privado ou protegido. Os pacotes são
representados com uma pasta com uma aba sendo que dentro contém as
classes, exemplo de pacotes na Figura 21.
 48

Figura 21: Representação do conteúdo do pacote.

 Interfaces: É “a especificação de um conjunto de serviços que um ou

mais classificadores implementam” (BEZERRA, 2003, pag 238). O
conjunto de serviços é formado por especificações e métodos, as
especificações se referem ao serviço que se faz, o método se refere como
fazer o serviço e quais informações são necessárias para ser realizado
determinado serviço. Os classificadores são subsistemas ou um
componente que possui um conjunto de operações. Há dois tipos de
notações para interface a primeira é mesma utilizada para o diagrama de
classes, mais os métodos não especificam os atributos e a segunda é
representada por um segmento de reta com um circulo em uma das
extremidades e liga com classificador. Na Figura 22 a classe Funcionário
utiliza a interface Administrável para se comunicar com a classe Operação
e a classe Aluno utiliza a interface Manipulável para se comunicar com a
classe Operação.
 49

Figura 22: Exemplo de representação de interface.

 Subsistemas: São tipos especiais de pacotes, o que diferenciados por

utilizarem uma interface, pois um pacote só vai agrupar os objetos. Ele é
desenvolvido com auxilio do modelo de classes de domínio como critério
de identificação das classes mais importantes. O subsistema é
representado pelo estereótipo <<subsistema>>. A Figura 22 descreve a
representação de um subsistema:

Figura 23: Exemplo de subsistema.

3.11.1. Diagrama de Componentes no Ciclo de Vida do Software

O diagrama de componente é descrito na fase de projeto tendo como base

o diagrama de classe de domínio. (BEZERRA, 2003, pag 241).
 50

4. MODELAGEM DE NEGÓCIOS

Para aplicar os conceitos da modelagem de negócio com UML foi

realizado um estudo de caso para modelar as principais características do sistema
da biblioteca da FACID. A biblioteca da FACID foi escolhida devido ao
conhecimento prévio das regras de negócio e a facilidade de acesso ao sistema da
biblioteca da FACID, no aspecto do cliente.

4.1. Ferramenta

Para facilitar a criação dos diagramas foi adotado a ferramenta de

modelagem JUDE (Java and UML Developer Enviroment). Principais vantagens:
 Permite a modificação do código fonte, pois a mesma é open source;
 Permite desenhar diagramas limpos, facilitando a visualização
através da organização dos componentes e evitando sobreposição
dos relacionamentos;
 Facilidade no compartilhamento ou troca de modelos UML com outros
projetos;
 Reutilização dos dados, através da importação e exortação de
componentes do diagrama;
 Envia mensagens de erro quando são desenhados diagramas de
UML contra a especificação;
 Facilidade no gerenciamento de dados, com a flexibilidade de
modificar e organizar os componentes dos diagramas;
 Os dados podem ser representados em diversos formatos, como por
exemplo: gráficos, árvore estruturas, etc;
 Importação de código Java para criar modelo;
 Geração de código fonte Java a partir do modelo;
 51

Há duas versões: JUDE Comunidade que é a versão free e JUDE

Profissional. O JUDE Comunidade suporta todos os diagramas da UML 1.4
enquanto o JUDE Professional suporta os diagramas 1.4 e os 2.0 da UML 2.0.
Utilizando a ferramenta de modelagem JUDE é possível criar os
seguintes diagramas: diagrama de classe, diagrama de casos de uso, diagrama de
seqüência, diagrama de colaboração, diagrama de estados, diagrama de atividade,
diagrama de componente, diagrama de implantação, diagrama de objetos,
diagrama de pacotes e diagrama de robustez.

4.2. Levantamento de Requisitos

Após a definição da ferramenta de modelagem foi feita uma análise

identificando os requisitos funcionais e não funcionais do sistema a ser modelado.

4.2.1. Descrição do Sistema da Biblioteca

O primeiro passo realizado na análise foi o entendimento do problema e

a descrição dele. Como foi citado na seção 3.5.1 há três tipos de descrição:
continuar, numérica e particionada. A escolhida foi a descrição narrativa, pois ela
trata de forma clara os passos realizados pelos autores.
A atividade da biblioteca se concentra principalmente no empréstimo de
publicações pelos alunos e professores da faculdade O empréstimo é registrado
pelos funcionários da biblioteca, o sistema registra a data e hora do empréstimo e
emite um comprovante para o usuário. O funcionário também consulta diariamente
os empréstimos cujos prazos foram ultrapassados. O mesmo cadastra os dados
das publicações, tais como: nome, edição, autor, titulo, subtítulo, ano de publicação
e editora, sendo que também é necessário registrar os usuários com os seguintes
campos: nome, matrícula, tipo de usuário e telefone. O mesmo terá a permissão
para cadastrar novos usuários, bem como alterar dados dos mesmos ou excluir se
necessário. Cabe lembrar que cada autor pode ter um ou várias publicações e
cada publicação pode ter um ou vários autores.
 52

Os usuários necessitam pesquisar os livros existentes na biblioteca. O

mesmo tem um prazo de três dias para devolver um livro normal. Ultrapassando o
prazo estipulado à entrega do livro, ele pagará uma multa de R$ 1,30 por dia.
Qualquer livro cativo só poderá ser emprestado para devolução no mesmo dia,
caso não for entregue, o aluno pagará uma multa de R$ 1,30 por hora. Se o
usuário estiver com alguma multa não poderá fazer empréstimos, nem mesmo de
algum livro cativo. Caso o usuário consulte uma publicação e a mesma esteja
emprestada será mostrada a data e hora esperada de entrega e
conseqüentemente poderá ser feita uma reserva. Caso o livro não esteja reservado
o usuário poderá realizar renovação do livro. Cabe lembrar que as regras utilizadas
para os alunos são as mesmas para os professores, que consequentemente são
os usuários da biblioteca.
O sistema automaticamente deverá realizar um backup ao final de cada
dia. Para acessar o sistema tanto o aluno, professor e o funcionário deverão
acessar o mesmo através de um login e senha. Contudo o sistema deverá ser
implementado em uma linguagem que seja compatível com diversas plataformas
existentes.

4.2.2. Requisitos

Após o término e validação da descrição é realizado o refinamento das

informações através da identificação dos RF (requisitos funcionais) e RNF
(requisitos não funcionais).
 Requisitos funcionais
o RF1: O funcionário registra o empréstimo;
o RF2: O funcionário consulta diariamente os empréstimos cujos
prazos foram ultrapassados;
o RF3: O funcionário cadastra os dados das publicações;
o RF4: O sistema acadêmico informará os dados ao sistema
bibliotecário;
o RF5: Os alunos pesquisam as publicações existentes na
biblioteca;
 53

o RF6: O aluno reserva uma publicação emprestada;

o RF7: O aluno poderá renovar o livro caso não esteja reservado;
o RF8: O funcionário poderá cadastrar alterar e excluir os dados.

 Requisitos não funcionais

o RNF1: Fazer backup do Banco de Dados ao final de cada dia;
o RNF2: O acesso será restrito com login e senha;

4.2.3. Atores do Sistema

Com base na identificação dos requisitos são identificados os atores.

 Usuário pode realizar reserva pesquisa e renovação.
 Funcionário pode gerenciar usuários, cadastrar publicações, registrar
empréstimos e consultar empréstimos.

4.3. Diagrama de Casos de Uso

Com base na descrição, na identificação dos requisitos e dos atores, é

criado o diagrama de caso de uso, como esta identificando na Figura 24.
 54

Figura 24: Diagrama de caso de uso – Biblioteca.

4.4. Especificações de Casos de Uso

Um novo refinamento é feito com base em cada caso de uso, para

especificas os fluxos básico, alternativo e de exceção.

4.4.1. Caso de Uso: Pesquisa Publicação

Descrição: Realiza pesquisa de publicações disponíveis na biblioteca.

Atores: Usuário
Prioridade: Risco baixo e prioridade alta
 55

Fluxo básico:
1. O aluno escolhe a opção de pesquisa;
2. O aluno introduz expressão de pesquisa;
3. O aluno clica no botão “PESQUISAR”;
4. O sistema busca um certo livro pela expressão “PESQUISAR”;
5. As publicações com a expressão pesquisada são adicionadas a uma
lista;
6. O resultado da pesquisa é mostrado para o aluno;
7. O aluno finaliza a tela de pesquisa.
Fluxo alternativo:
4a. Caso o aluno clique em CANCELAR;
4a.1 O sistema para a pesquisa de livros;
4a.2 O sistema volta à página de pesquisa.
Fluxo de exceção:
6a. Caso o livro não seja encontrado a parece a expressão” Livro não
encontrado”

4.4.2. Caso de Uso: Cadastrar Publicação

Descrição: Realizar cadastro de um novo livro.

Atores: Funcionário
Prioridade: Risco baixo e prioridade alta
Fluxo básico:
1. O funcionário escola a opção de cadastro;
2. O funcionário preenche os campos de cadastro;
3. O funcionário clica no botão “INSERIR”;
4. O sistema verifica se os campos estão preenchidos;
5. O sistema insere os dados do livro na lista de livros;
6. O sistema gera automaticamente o código do livro;
7. O sistema envia uma mensagem de confirmação de inclusão do livro;
8. O funcionário fecha a tela de inclusão.
Fluxo de exceção:
4.a Aparece uma mensagem indicado os possíveis campos invalidados.
 56

4.5. Diagrama de classe

Antes de criar o diagrama de classe ou objeto é necessário identificar as

classes. Na tabela a baixo tem uma lista com as classes candidatas, a justificativa
de algumas não ser classes e as respectivas classes.

Tabela 2: Classes candidatas

CLASSE CANDIDATA MOTIVO CLASSE
Biblioteca
Publicações Publicação

Usuários Usuário
Empréstimo Empréstimo
Funcionário É Ator
Data Atributo de Empréstimo
Hora Atributo de Empréstimo
Comprovante Método de Empréstimo
Edição Atributo de Publicação
Multa Atributo de Empréstimo
Backup Ação do Sistema
Login Atributo do Usuário
Senha Atributo do Usuário
Autor Autor
Livro Livro
Periódico Periódico
Nome Atributo de usuário
Matrícula Atributo de usuário
Tipo de usuário Atributo de usuário
Telefone Atributo de usuário
Nome do autor Atributo de Autor
Editora Atributo de Autor
Título Atributo de Autor
Subtítulo Atributo de Autor
Ano de publicação Atributo de Autor
 57

Após a identificação das classes, torna-se mais fácil a criação do

diagramas de classe e objeto. Na Figura 25 têm-se um diagrama de classe que
exibe os relacionamentos entre as suas classes. Durante a elaboração do
diagrama de classe, é comum encontrar irregularidades nas fases que antecedem
a criação do diagrama de classe.

Figura 25: Diagrama de classe – Biblioteca.

 58

4.6. Modelagem de Interações

O modelo de interação e composto por dois diagramas: diagrama de

seqüência e colaboração, como foi falado anteriormente eles são equivalentes,
abaixo temos exemplos de diagramas de colaboração. O diagrama é criado com
base nas informações da descrição narrativa e no caso de uso., como mostra nas
Figuras 26,27 e 28.
 Caso de uso: Cadastrar publicações

Figura 26: Diagrama de colaboração – Cadastrar publicação.

 59

 Caso de uso: Pesquisa publicação

Figura 27: Diagrama de colaboração – Pesquisa publicação.

 60

 Caso de uso: Registrar empréstimo

Figura 28: Diagrama de colaboração – Registra empréstimo.

4.7. Diagrama de Atividade

O primeiro passo na construção do diagrama de atividade é a

identificados dos estados de um objeto com base nos atributos e das possíveis
ligações com outros objetos. Com base no caso de uso e no diagrama de
interação torna-se mais fácil a identificação dos eventos e os fatores que podem
gerar o disparo da transição, como por exemplo: clicar em um botão, enviar
mensagem de erro informando quais são os campos inválidos, etc. Após ter
identificados as classes, os objetos, os estados e os eventos. Realiza-se a
identificação dos possíveis relacionamentos entre eles, como consta nas Figuras
29, 30 e 31.
 61

 Caso de uso: Cadastrar publicações

Figura 29: Diagrama de atividade – Cadastra publicação.

 62

 Caso de uso: Pesquisa publicações

Figura 30: Diagrama de atividade – Pesquisa publicação.

 63

 Caso de uso: Registra empréstimo

Figura 31: Diagrama de atividade – Registra empréstimo.

 64

4.8. Diagrama de Componentes

Com base no diagrama de classe de domínio é possível identificar as

classes utilizadas no diagrama de componentes e com diagrama de objeto torna-se
mais fácil identificar as interfaces. No diagrama de componente, as classes que
apresentam comportamento em comum são agrupadas em pacotes, outra forma de
representar esse aspecto no sistema é através da definição da interface que vai
interligar classes como comportamento diferente, como, por exemplo, a classe
Aluno se interage com a interface Manipulável que se relaciona com a classe
Operação no qual tem as permissões de empréstimo, renovar e consulta. A classe
Funcionário interage com a interface Administrável, que se relaciona com a classe
Operação na qual tem acesso a todos os métodos, como mostra na Figura 32.

Figura 32: Interface – Classe biblioteca.

 65

5. CONCLUSÃO

Nos anos 70 a engenharia de software surgiu para atender as exigências

dos usuários, cada dia ele vem aumentando. A UML é um linguagem de modelagem
que obedece um conjunto de regras padronizadas com objetivo de representar
conceitualmente qualquer tipo de sistema. A modelagem amplia a visão das pessoas
envolvidas na elaboração, construção e utilização do software. Entendendo melhor o
sistema, torna-se mais fácil de gerenciar os riscos e as pessoas envolvidas no
desenvolvimento do projeto, solucionar problemas, evitar ambigüidades entre os
elementos do sistema, facilidade na elaboração da documentação, garantir a
qualidade do sistema e entrega no prazo estimado. As utilizações dos diagramas da
UML estão associadas às fases do desenvolvimento do software.
O diagrama de caso de uso descreve as funcionalidades externas do
sistema, sendo criado na análise e pode se estender na fase de projeto, podendo
sofre futuras modificações.
O modelo de classe de domínio fornece uma visão interna dos objetos
que compartilham mensagens entre sí. Essa interação de mensagens pode ser
representada no aspecto estrutural que se refere a forma na qual os componentes
estão organizados internamente e/ou dinamicamente, focando a troca de
mensagens entre os objetos no decorrer do tempo.
No aspecto estrutural, tem-se o diagrama de classe que demonstra a
estrutura estática das classes e o diagrama de objeto que consiste na instancia do
diagrama de classe. Como eles são semelhantes geralmente, só é utilizado o
diagrama de classes. Eles são criados na fase de análise e projeto, tendo como
base os requisitos identificados e o diagrama de caso de uso.
A representação dinâmica pode ser feita tanto pelo diagrama de
seqüência, que dá ênfase no decorrer do tempo, quanto pelo diagrama de
colaboração que enfatiza o contexto do sistema, sendo equivalentes. Eles são
construídos inicialmente na fase de análise e é estendido até a fase de projeto.
Normalmente, é descrito com base no diagrama de classes.
O diagrama de estado é uma representação dinâmica que enfatiza a
modificação do estado de um objeto ocasionado por um evento. Ele é descrito na
 66

fase de projeto tendo como base o diagrama de interação e de classe. O diagrama

de atividade é utilizado quando o diagrama de estado é muito complexo, ele é um
tipo de diagrama de estado, mas ele apresenta uma descrição mais detalhada de
fluxos alternativos e de exceções.
A utilização dos diagramas nas fases da engenharia de software não são
bem distintas, pois variam de acordo com as características do método utilizado. Os
diagramas são relacionados uns com os outros, mas nenhum diagrama é suficiente
para compreensão de um sistema, ou seja, cada diagrama tem uma visão do
sistema, quanto maior diversidade de diagramas mais fácil fica de abstrair o sistema.
Com base nas informações desse trabalho, pode-se realizar os seguintes
conclusões:
 Comparação entre a UML 1.4 e a UML 2.0 que é a versão mais atual,
devido à grande evolução do mercado de informática a nova versão
apresenta novos diagramas.
 Realizar descrições sobre processo de geração de código automático
tendo como base o Desenvolvimento Orientado a Modelo (MDD), os
principais artefatos no desenvolvimento do software são os diagramas,
com auxilio de uma ferramenta o código será gerado automaticamente a
partir dos diagramas gerados nas fases de análise e projeto.
 Comparação entre ferramentas de modelagem como o JUDE e
Enterprise Architect, levando em consideração quais diagramas são
gerados, desempenho, qual interface é mais amigável e quais vantagens
e desvantagens.
 Teste de reutilização de componentes de software, antes de reutilizar um
componente é necessário validá-lo, uma das formas de testar a
integração dos componentes é utilizando diagrama de atividade UML
que representa os comportamentos dos componentes.
 67

6. REFERÊNCIAS

BEZERRA, E . Princípios de Análise e Projeto de Sistemas com UML. 1 ed. São

Paulo: CAMPUS, 2002.

BOOCH, G; RUMBAUGH, J; JACOBSON, I. UML: Guia do Usuário. 2 ed. São Paulo:

CAMPUS, 2000.

PRESSMAN, Roger S. Engenharia de Software. 6 ed. São Paulo: McGraw Hill, 2006.

http://www.dcc.ufla.br/infocomp/artigos/v1.1/tutorialUML.pdf, acessado em 19 de
março de 2008

http://www.dsc.ufcg.edu.br/~patricia/pct/aula7/aula7.pdf, acessado em 19 de março

de 2008

http://noriegec.cpgec.ufrgs.br/tic2007/artigos/A1099.pdf, acessado em 19 de março

de 2008

http://www.anacristinamelo.eti.br/artigos/Artigo_Buscando_Novos_Caminhos.pdf,
acessado em 19 de março de 2008

http://www.uml.org/, acessado em 19 de março de 2008

http://www.visual-paradigm.com/product/vpuml/index.jsp, acessado em 19 de março

de 2008

http://www.google.com.br/search?as_q=UML+&hl=ptBR&num=10&btnG=Pesquisa+
Google&as_epq=artigos&as_oq=desenvolvimento+de+software%2C&as_eq=&lr=lan
g_pt&cr=&as_ft=i&as_filetype=pdf&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch
=&as_rights=&safe=images, acessado em 19 de março de 2008

http://www.micropic.com.br/noronha/Informatica/PD/AL/projeto%20orientado%20a%
20objeto%20uml.pdf, acessado em 19 de março de 2008

manoelnetom.googlepages.com/ApostiladeUMLCEFET.pdf, acessado em 19 de
março de 2008

http://www.dsc.ufcg.edu.br/~patricia/esii2003.2/aulas/UMLComponents.pdf,
acessado em 19 de março de 2008
 68

http://www2.ufp.pt/~jvasco/UML-Engsoft.pdf, acessado em 19 de março de 2008

http://www.deinf.ufma.br/~acmo/MOO_Intro.pdf, acessado em 19 de março de 2008

http://www.maxwell.lambda.ele.pucrio.br/cgibin/PRG_0599.EXE/7337_3.PDF?NrOco
Sis=20926&CdLinPrg=pt, acessado em 19 de março de 2008

http://www2.iesampa.edu.br/pids/Treinamentos/3%20MODELAGEMDESISTEMAS_
Trab_Correlato.pdf, acessado em 20 de março de 2008

www.apostilando.com/download.php?cod=2038&categoria=Outras%20Apostilas,
acessado em 19 de março de 2008

www.apostilando.com/download.php?cod=2595&categoria=Lógica%20de%20Progra
mação, acessado em 19 de março de 2008

http://www.google.com.br/search?q=UML,+fases+da+engenharia+de+software++filet
ype:pdf&hl=pt-BR&lr=lang_pt&as_qdr=all&start=10&sa=N, acessado em 19 de
março de 2008

http://www.uml.org/, acessado em 19 de março de 2008

http://www.visual-paradigm.com/product/vpuml/index.jsp, acessado em 19 de março
de 2008

http://www.cos.ufrj.br/~azevedo/UML_Diagrama_de_classes.pdf, acessado em 19 de
março de 2008

http://www.lozano.eti.br/palestras/mercado.pdf, acessado em 20 de março de 2008

http://www.itacoatiara.com/cn_inf-gc.htm, acessado em 13/11/2008

http://epf.eclipse.org/wikis/openuppt/openup_basic/guidances/concepts/milestones,_
HNxbwMBJEdqSgKaj2SZBmg.html, acessado em 13/11/2008
 69

http://teobaldobh.spaces.live.com/?_c11_BlogPart_BlogPart=blogview&_c=BlogPart
&partqs=cat%3DUML, acessado em 28/11/2008.

http://ctp.di.fct.unl.pt/~ja/mei-es/mdd.pdf, acessado em 28/11/2008.

http://www.sbrc2007.ufpa.br/anais/2007/WTF03%20-%2002.pdf, acessado em
28/11/2008.