Modelagem Processos Unip PDF

Modelagem de Processos
Autor: Prof. Dr. Ivanir Costa

Colaboradores: Prof. Roberto Macias
Profa. Elisângela Mônaco de Moraes
Prof. Emanuel Augusto Severino de Matos
Professor conteudista: Dr. Ivanir Costa
Doutor em Engenharia de Produção pela Escola Politécnica da Universidade de São Paulo (USP, 2003) e mestre
em Engenharia de Produção pela Universidade Paulista (UNIP), pós-graduado em Sistemas de Informação pela UNIP,
graduado em Física pela USP. Professor titular do programa de mestrado e doutorado da UNIP em Engenharia de
Produção, onde realiza orientação para alunos doutorandos, mestrandos e da iniciação científica na graduação.
Professor da EAD na UNIP, nas disciplinas de Qualidade de Software e Sistemas de Informação. Orientador de alunos de
mestrado do IPT (Instituto de Pesquisas Tecnológicas) da USP, professor do curso Gestão da Tecnologia da Informação,
MBA da FIA/FEA. Possui dezenas de publicações na área de Engenharia de Produção e Tecnologia da Informação
no Brasil e no exterior. É consultor há mais de 30 anos em Tecnologia da Informação, com ênfase em Engenharia
de Software e Qualidade de Software, atuando principalmente nos seguintes temas: desenvolvimento de software,
metodologia de desenvolvimento, métricas de software, métodos ágeis, produção de software, qualidade de software
e governança de TI.
Dados Internacionais de Catalogação na Publicação (CIP)
C837m Costa, Ivanir
Modelagem de processos / Ivanir Costa. – São Paulo: Editora

Sol, 2012.
144 p., il.
Notas: este volume está publicado nos Cadernos de Estudos e

Pesquisas da UNIP, Série Didática, ano XVII, n. 2-066/12, ISSN 1517-9230.
1. Tecnologia da informação. 2. Modelagem de processos. 3.

Modelagem comportamental. I. Título.
CDU 65.011.56
© Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida por qualquer forma e/ou
quaisquer meios (eletrônico, incluindo fotocópia e gravação) ou arquivada em qualquer sistema ou banco de dados sem
permissão escrita da Universidade Paulista.
Prof. Dr. João Carlos Di Genio
Reitor
Prof. Fábio Romeu de Carvalho

Vice-Reitor de Planejamento, Administração e Finanças
Profa. Melânia Dalla Torre

Vice-Reitora de Unidades Universitárias
Prof. Dr. Yugo Okida

Vice-Reitor de Pós-Graduação e Pesquisa
Profa. Dra. Marília Ancona-Lopez

Vice-Reitora de Graduação
Unip Interativa – EaD
Profa. Elisabete Brihy

Prof. Marcelo Souza
Prof. Dr. Luiz Felipe Scabar
Prof. Ivan Daliberto Frugoli
Material Didático – EaD
Comissão editorial:
Dra. Angélica L. Carlini (UNIP)
Dra. Divane Alves da Silva (UNIP)
Dr. Ivan Dias da Motta (CESUMAR)
Dra. Kátia Mosorov Alonso (UFMT)
Dra. Valéria de Carvalho (UNIP)
Apoio:
Profa. Cláudia Regina Baptista – EaD
Profa. Betisa Malaman – Comissão de Qualificação e Avaliação de Cursos
Projeto gráfico:
Prof. Alexandre Ponzetto
Revisão:
Virgínia Bilatto
Amanda Casale
Sumário
APRESENTAÇÃO.......................................................................................................................................................7
INTRODUÇÃO............................................................................................................................................................7
Unidade I
1 A Linguagem Unificada de Modelos...............................................................................................11
1.1 Introdução.................................................................................................................................................11
1.2 Motivação para o uso de modelos................................................................................................. 12
1.3 Princípios da modelagem de software......................................................................................... 14
1.4 Modelagem e orientação a objetos............................................................................................... 15
1.5 Por que usar a orientação a objetos?............................................................................................ 16
1.6 Conceitos básicos da orientação a objetos................................................................................. 22
2 a linguagem unificada de modelos (uml)................................................................................. 28
2.1Introdução................................................................................................................................................. 28
2.2 A UML e o Processo Unificado......................................................................................................... 32
2.2.1 Engenharia de software e processos de software...................................................................... 33
2.2.2 Os processos denominados de ágeis................................................................................................ 37
2.2.3 O Processo Unificado – UP.................................................................................................................. 37
Unidade II
3 Modelo Conceitual da UML.................................................................................................................. 43
3.1 Introdução................................................................................................................................................ 43
3.2 Visão geral da UML............................................................................................................................... 43
3.3 Arquitetura da UML.............................................................................................................................. 44
3.4 Modelagem estrutural......................................................................................................................... 45
3.4.1 Classes de objetos.................................................................................................................................... 45
3.4.2 Relacionamentos entre classes de objetos/instâncias.............................................................. 46
3.4.3 Mecanismos comuns.............................................................................................................................. 46
3.4.4 Diagramas da UML.................................................................................................................................. 47
4 Diagrama de classes de objetos da UML.................................................................................... 51
4.1 Introdução................................................................................................................................................ 51
4.2 Associação................................................................................................................................................ 53
4.3 Papéis em associação........................................................................................................................... 55
4.4 Classe de associação............................................................................................................................ 56
4.5 Agregação e composição................................................................................................................... 58
4.6 Generalização/especialização........................................................................................................... 59
4.7 Herança..................................................................................................................................................... 60
4.8 Conceitos avançados envolvendo classes................................................................................... 63
4.8.1 Herança múltipla..................................................................................................................................... 63
4.8.2 Classes abstratas...................................................................................................................................... 65
4.8.3 Polimorfismo (ocultamento de informações).............................................................................. 66
4.8.4 Interfaces tipos e papéis....................................................................................................................... 67
4.8.5 Pacotes lógicos......................................................................................................................................... 67
4.8.6 Objetivos do diagrama de classes..................................................................................................... 68
4.9 Estudo de caso aplicando modelo de classes............................................................................ 68
4.9.1 Descrição do sistema.............................................................................................................................. 68
4.9.2 Requisitos do sistema............................................................................................................................ 69
4.9.3 Modelo de classe do sistema.............................................................................................................. 70
Unidade III
5 MODELAGEM COMPORTAMENTAL (MODELO DINÂMICO).............................................................. 76
5.1 Introdução................................................................................................................................................ 76
5.2 Modelo de casos de uso..................................................................................................................... 77
5.2.1 Diagramas de caso de uso.................................................................................................................... 77
6 Outros modelos comportamentais da UML............................................................................. 91
6.1 Introdução................................................................................................................................................ 91
6.2 Diagrama de atividades...................................................................................................................... 92
6.3 Diagrama de sequência....................................................................................................................... 93
6.3.1 Linha de vida............................................................................................................................................. 95
6.3.2 Ativação....................................................................................................................................................... 95
6.3.3 Autodelegação.......................................................................................................................................... 95
6.3.4 Mensagem.................................................................................................................................................. 95
6.4 Diagramas de estado (máquina de estado)................................................................................ 96
6.4.1 Estado........................................................................................................................................................... 96
6.4.2 Notações...................................................................................................................................................... 96
6.4.3 Evento........................................................................................................................................................... 97
6.4.4 Transição...................................................................................................................................................... 98
Unidade IV
7 MODELAGEM DA ARQUITETURA DE NEGÓCIO..................................................................................103
7.1 Introdução..............................................................................................................................................103
7.2 Modelagem de negócio....................................................................................................................104
7.2.1 Conceitos de negócio...........................................................................................................................105
7.2.2 Extensão de negócio da UML............................................................................................................ 110
7.2.3 Visões de modelos de negócio.........................................................................................................114
7.3 OCL e sua utilização na modelagem de processo de negócio.......................................... 114
7.4 Integração com o desenvolvimento de software................................................................... 116
7.4.1 Processo de desenvolvimento de software.................................................................................116
7.4.2 Arquitetura de negócio e arquitetura de software..................................................................117
8 A modelagem de processos de negócio................................................................................... 119
8.1 Visão Erikson e Penker....................................................................................................................... 119
8.2 A modelagem de processos de negócio com a BPM............................................................122
8.2.1 Objetos de fluxo.................................................................................................................................... 125
8.2.2 Objetos de conexão.............................................................................................................................. 127
8.2.3 Raias (Swimlanes)................................................................................................................................. 129
8.2.4 Artefatos....................................................................................................................................................131
8.3 Conclusão do BPMN..........................................................................................................................133
APRESENTAÇÃO
O objetivo da disciplina Modelagem de Processos é apresentar e conceituar a importância de modelos

no desenvolvimento de sistemas de informação.
Nela, os alunos terão condições de entender, analisar, desenhar e descrever os principais e mais
importantes modelos de desenvolvimento de software, utilizando a linguagem de modelagem UML
(Unified Modeling Language), tanto os modelos estáticos como os modelos dinâmicos.
A disciplina também apresenta os conceitos e simbologias envolvidos com a modelagem das áreas
de negócio, bem como os mapeamentos de negócios por meio da UML e da moderna linguagem de
modelagem de negócios BPMN (Business Process Modeling Notation).
INTRODUÇÃO
Entre os autores e especialistas envolvidos com os processos de desenvolvimento de software, existe

a crença de que, de algum modo, a modelagem pode ser aplicada para facilitar a nossa vida.
Desde a década de 1970, os autores especializados em software vêm propondo processos ou

metodologias de desenvolvimento de sistemas que, apesar de utilizarem abordagens diferentes, sempre
possuem em seu bojo o uso de modelos visuais e descritivos. Isso é fundamentado no fato de que
os modelos visuais permitem o entendimento do mesmo assunto por pessoas com conhecimentos e
perfis diferentes. A importância desse entendimento torna-se primordial, já que no processo de software
temos a participação de pessoas de diversas áreas de uma organização, indo do usuário final de uma
área de negócio até o especialista em software e hardware da área de TI.
Todavia, ao longo desse tempo, a modelagem de software vem sendo criticada devido à percepção
de que a modelagem é uma atividade que precede o desenvolvimento real e que tem como foco a
documentação. Isto é, para muitos especialistas, não se deve privilegiar o desenho ao próprio
desenvolvimento. Essas críticas vieram principalmente dos defensores dos métodos ágeis, que privilegiam
o código em vez da documentação.
Outros autores, entretanto, insistem que a modelagem deve ser reconhecida como uma tarefa de
desenvolvimento central importante. Quando os modelos são considerados parte das atividades do
processo de desenvolvimento e geram artefatos de primeira classe, os desenvolvedores geram menos
código convencional, uma vez que abstrações de aplicativo mais poderosas podem ser empregadas.
Dessa forma, quando os modelos abrangem as atividades de desenvolvimento, a comunicação entre

as pessoas envolvidas pode ser otimizada e a capacidade de rastreamento ativada no ciclo de vida em
qualquer direção. A otimização também vem do fato de que os modelos podem ser fontes de reuso
tanto dos objetos criados como das descrições que os envolvem.
Acredita-se que tornar a modelagem uma corrente predominante dentro da área de desenvolvimento
de sistemas de uma organização pode levar a uma economia de recursos e, com isso, aumentar a
7
abrangência de automação no atendimento das necessidades de uma empresa. A automação do processo
de desenvolvimento com o uso de geradores de sistemas a partir de modelos construídos tende a ser
uma realidade a médio e longo prazos no processo de software.
Pode-se citar, dentro dessa realidade, a Microsoft, que emitiu um documento denominado de
“Estratégia de modelagem” em 2005, que aborda o desenvolvimento dirigido por modelo dentro de
uma iniciativa chamada Fábricas de Software.
Existem diversas empresas, órgãos e grupos que adotam e propõem o uso de modelos no
desenvolvimento de software. Entre eles, pode-se citar o Object Management Group (OMG), que adotou
a linguagem para a modelagem de produtos de software denominada de UML em novembro de 1997.
Essa adoção ocorreu em um evento histórico e marcante, pois assinalou a aceitação de uma linguagem
padronizada de modelagem de sistemas baseada nas melhores práticas atuais para a análise, o projeto
e a construção de software orientado a objetos.
A UML, tema central desta disciplina, é a primeira notação que atingiu o consenso entre a maioria
dos profissionais, vendedores e acadêmicos como o padrão real para expressar um domínio comercial
da solução de software. Entre os autores da UML, temos o americano Grady Booch, que diz que a
modelagem deve atingir quatro objetivos para se tornar efetiva em um ambiente de desenvolvimento
de software:
1. Ajudar a equipe de projeto a visualizar um sistema como ele é ou pretende ser.
2. Ajudar a especificar a estrutura ou o comportamento do sistema.
3. Proporcionar um modelo que sirva de guia na construção do sistema.
4. Documentar as decisões tomadas pela equipe de desenvolvimento de projeto.
A UML precisa desses objetivos para ser efetiva (REED Jr., 2000).
Ela é apresentada tanto nos seus modelos estáticos como nos modelos dinâmicos que mostram as
estruturas e os comportamentos dos objetos envolvidos em uma determinada aplicação ou software
nos modelos da tecnologia orientada a objetos.
Na atualidade, outra área de interesse e importante na construção de sistemas fundamentais é a

de processos de negócio, que se propõe a mostrar as atividades previamente estabelecidas nas áreas de
negócio e determinar a forma como o trabalho é realizado numa organização.
Essas atividades de negócio constituem um conjunto de ações relacionadas entre si de forma lógica
e coerente, a fim de promover uma saída favorável à organização, em níveis interno e externo. Uma
boa modelagem dos processos de negócio leva à implementação de um sistema de informação bem-
estruturado.
8
A disciplina aborda os conceitos de modelos, a importância da modelagem de sistemas de informação,
a tecnologia orientada a objetos e as modelagens UML e BPM no processo de desenvolvimento de
software.
9
Unidade I
1 A Linguagem Unificada de Modelos
1.1 Introdução
Existe uma crença, entre os envolvidos no desenvolvimento de software, de que, de algum modo, a
modelagem pode ser aplicada para facilitar as suas vidas.
Todavia, ao longo do tempo, a modelagem de software vem sendo criticada devido à

percepção de que é uma atividade que precede o desenvolvimento real e que tem como foco a
documentação.
Outros autores insistem que a modelagem deve ser reconhecida como uma tarefa de desenvolvimento
central importante e não uma atividade focada principalmente em documentação.
Quando os modelos são considerados artefatos de desenvolvimento de primeira classe, os

desenvolvedores geram menos código convencional, uma vez que abstrações de aplicativo mais
poderosas podem ser empregadas.
Assim, o desenvolvimento dirigido por modelo é inerentemente mais produtivo e ágil. Além
disso, outros participantes no desenvolvimento como analistas de negócios, arquitetos e gerentes
de projetos, irão reconhecer a modelagem como o que adiciona valor às tarefas pelas quais são
responsáveis.
Quando os modelos abrangem as atividades de desenvolvimento e em tempo de execução dessa

maneira, a comunicação entre as pessoas pode ser otimizada, e a capacidade de rastreamento ativada
no ciclo de vida em qualquer direção.
Acredita-se que, ao tornar a modelagem uma corrente predominante, pode-se alterar a economia
do desenvolvimento de softwares e garantir que os sistemas de software atendam às necessidades de
uma empresa.
De acordo com a Microsoft, em seu documento denominado de Estratégia de modelagem, de 2005,

essa abordagem do desenvolvimento dirigido por modelo é parte de uma iniciativa chamada Fábricas
de software.
11
Unidade I
Saiba mais
Vale a pena ler o artigo de maio de 2005, disponível no site

<http://msdn.microsoft.com/pt-br/library/ms379623(v=vs.80).aspx>,
que discute a estratégia de desenvolvimento da Microsoft, dirigido
por modelos com uma série de perguntas e respostas relativas a esses
tópicos e interesses. Esse artigo basicamente pergunta e responde:
por que modelagem? Como as DSLs são usadas no desenvolvimento
dirigido por modelo? E quanto à UML? E quanto à MDA? O que são
fábricas de software?
1.2 Motivação para o uso de modelos
Ainda de acordo com a Microsoft, um modelo deve ser um artefato de primeira classe em um
projeto, não apenas uma documentação aguardando para se tornar desatualizada.
O autor Senge (1990):
1. Define que modelos são mentais, são pressuspostos profundamente arraigados, generalizações,
ou mesmo imagens que influenciam a forma de ver o mundo e de nele agir. Muitas vezes,
não estamos conscientes de nossos modelos mentais ou de seus efeitos sobre nosso
comportamento.
2. Afirma que o trabalho com modelos mentais inclui também a capacidade de realizar
conversas ricas em aprendizados, que equilibrem indagação e argumentação, em que as
pessoas exponham de forma eficaz seus próprios pensamentos e estejam abertas à influência
dos outros.
3. Os modelos possuem uma sintaxe precisa, geralmente são melhores editados e visualizados com
uma ferramenta gráfica e contêm semânticas que determinam como conceitos específicos de
domínio mapeiam para outros artefatos de implementação, como: código, estruturas de projeto
e arquivos de configuração.
4. Dessa maneira, um modelo se parece muito com um arquivo de código-fonte, e os mecanismos

que o sincronizam com outros artefatos de implementação são muito semelhantes a compiladores.
5. Um modelo representa um conjunto de abstrações que dá suporte a um desenvolvedor em um

aspecto de desenvolvimento bem definido.
6. Como os modelos podem abstrair e agregar informações de uma série de artefatos, podem dar
suporte de modo mais rápido a verificações de consistência e outras formas de análise.
12
Observação
Um modelo de conectividade de aplicativos, por exemplo, poderá

suportar validação de protocolo de contrato, análise de segurança ou
análise de desempenho.
Um modelo é uma representação ou interpretação simplificada da realidade, ou uma interpretação

de um fragmento de um sistema segundo uma estrutura de conceitos.
Um modelo apresenta “apenas” uma visão ou cenário de um fragmento do todo. Normalmente, para
estudar um determinado fenômeno complexo, criam-se vários modelos.
Observação
Por exemplo, pode-se citar obras da Engenharia civil, tais como, uma
grande obra hidráulica, uma ampliação de uma praia artificial ou mesmo
uma usina hidrelétrica, não são projetadas sem estudos detalhados em
vários tipos de modelos matemáticos de diversas categorias e tipos, como
modelos de hidrologia, hidráulica e mecânica dos solos.
Modelagem também pode ser vista como a arte de criar moldes tanto em fundição (nesse caso, os
de areia), como em calçados e em confecção de peças para o vestuário. No caso dessa última, o molde é
obtido por uma das três técnicas básicas: moulage, modelagem geométrica ou simples cópia.
Segundo os autores Huckvale e Ould (1993, apud BRANCO, 2007), um modelo aplicado a processos
oferece:
• Um meio para discussão: o modelo de processos ajuda a situar as questões relevantes ao permitir
a abstração do mundo real, salientando os objetos e relacionamentos que são de interesse e
ignorando detalhes que possam contribuir para aumentar a complexidade.
• Um meio para comunicação: permite que outras pessoas, que não as envolvidas no desenvolvimento
do modelo, possam utilizá-lo como base para a sua implementação ou para a concepção de novos
modelos.
• Uma base para análise: a análise de um modelo pode revelar os pontos fortes e fracos do processo,
com especial relevância para os fracos, como ações que acrescentam pouco valor ou são potenciais
focos de problemas.
• A análise por simulação e animação do modelo permite, ainda, estudar os efeitos que possíveis
alterações podem causar em um dado processo.
13
Unidade I
• Uma base para concepção de novos processos.
• Uma base para melhoria contínua: as sugestões para a mudança podem ser expressas em termos
de alterações ao modelo e da sua análise, sendo possível ainda sugerir métricas para avaliar o seu
desempenho.
• Uma base para controle: quando suficientemente formal para ser automatizado, o modelo pode
ser utilizado para controlar a execução do sistema modelado, como em um sistema de gestão de
Workflow.
• Além de garantir o correto funcionamento, permite efetuar medições quanto ao desempenho do

processo.
1.3 Princípios da modelagem de software
A modelagem de sistemas de informação (software) é a atividade de construir modelos que expliquem

as características ou o comportamento de um software ou aplicativo, ou de um sistema de software.
Na construção do software, os modelos podem ser usados na identificação das características e

funcionalidades que o esse deverá prover e no planejamento de sua construção.
Frequentemente, a modelagem de software usa algum tipo de notação gráfica e é apoiada pelo uso
de ferramentas de apoio denominadas de ferramentas Case.
Ferramentas Case (Computer-Aided Software Engineering) é uma classificação que abrange todas
as ferramentas baseadas em computadores que auxiliam atividades de Engenharia de software, desde
análise de requisitos e modelagem até programação e testes.
Podem ser consideradas como ferramentas automatizadas que têm como objetivo auxiliar o
desenvolvedor de sistemas em uma ou várias etapas do ciclo de desenvolvimento de software.
A modelagem de software normalmente implica a construção de modelos gráficos que simbolizam

os artefatos dos componentes de software utilizados e os seus inter-relacionamentos.
Uma forma comum de modelagem de programas procedurais (não orientados a objeto) é por meio
de fluxogramas, enquanto que a modelagem de programas orientados a objeto normalmente usa a
linguagem gráfica de modelos UML.
Observação
Vale a pena, para quem ainda não conhece ou utilizou uma

ferramenta Case, fazer download de uma ferramenta free, tais como a
ferramenta JUDE ou a ferramenta Umbrello UML, e com elas verificar
14
uma série de propriedades e facilidades que ajudam na documentação,

facilitam a comunicação e ainda aumentam de forma considerável
a produtividade dos desenvolvedores de software. Algumas são tão
sofisticadas que chegam a gerar código diretamente dos modelos
construídos.
1.4 Modelagem e orientação a objetos
De acordo com vários autores, há muito tempo busca-se um padrão de construção de software
orientado a objetos e sua representação, à semelhança da planta utilizada por outras áreas da Engenharia,
tal como a planta de uma casa ou arquitetura de um prédio da Engenharia Civil.
O enfoque tradicional de modelagem para a construção de sistemas de informação baseia-se na

compreensão desse sistema como um conjunto de programas que, por sua vez, executam processos
sobre dados.
O enfoque de modelagem por objetos vê o mundo como uma coletânea de objetos que interagem
entre si e apresentam características próprias, que são representadas pelos seus atributos (dados) e
operações (processos) (FURLAN, 1998).
A figura 1 mostra o enfoque baseado em sistema versus o enfoque baseado em objetos.
Programa Classe
Processos
Atributos
Dados
Operações
Foco em sistema Foco em objeto
Figura 1 – Sistema vs. objeto
Um programa, no sentido tradicional agora, é um conjunto de objetos que se relacionam para

executar as funcionalidades ou processos do sistema aplicativo. Então, o programa é representado por
classes; os processos, por operações ou métodos; e os dados, por atributos dos objetos.
Essa mudança de enfoque se justifica devido ao fato de que os objetos existem na natureza muito
antes de o homem criar os computadores e os seus programas de software.
15
Unidade I
Carros, equipamentos, pessoas, bancos etc. apresentam características próprias que podem ser
representadas pelos seus atributos e pelos seus comportamentos no mundo real.
Furlan (1998) informa que essa abordagem oferece como principais benefícios:
• manter a modelagem do sistema e, em decorrência, sua automação o mais próximo possível de

uma visão conceitual do mundo real;
• servir de base à decomposição e modelagem do sistema nos dados, que é o elemento mais estável
de todos aqueles que compõem um sistema de informação;
• oferecer maior tranparência na passagem de modelagem para a construção por meio da introdução
de detalhes, não requerendo uma reorganização do modelo.
Lembrete
Embora o termo “orientação a objetos” tenha sido usado de várias

formas distintas, deveria sempre sugerir uma associação entre coisas do
mundo real e trechos de programas de computador ou objetos.
De uma maneira mais informal, objeto pode ser visto ou entendido como uma entidade independente,
assíncrona e concorrente.
Diz-se que um objeto “sabe coisas”, isto é, armazena dados; objeto “realiza trabalho”, isto é, encapsula
serviços; objeto “colabora” com outros objetos por meio de troca de mensagens, para executar as funções
finais do sistema, sendo modelado.
James Rumbaugh (1994) define orientação a objetos como:
[...] uma nova maneira de pensar os problemas utilizando modelos

organizados a partir de conceitos do mundo real.
O componente fundamental é o objeto que combina estrutura e

comportamento em uma única entidade (RUMBAUGH, 1994).
1.5 Por que usar a orientação a objetos?
Dentre as várias razões pode-se citar:
• Inconsistência na visão dos modelos:
— Diferentemente das outras tecnologias de desenvolvimento, o mesmo conjunto de modelos na

OO é utilizado em todo o ciclo de desenvolvimento.
16
— Os objetos são:
– Descobertos na fase de análise de sistemas para representar os requisitos do usuário.
– Alterado na fase de projeto para incorporar as características do ambiente operacional do

sistema.
– E finalmente utilizado na fase de construção para subsidiar a implementação nas linguagens

OO e nos gerenciadores de banco de dados.
— Objetos definidos na análise têm representação direta no código, evidenciando a relação entre
a definição do problema e a sua implementação.
• Melhor abstração do domínio do problema:
— A OO mantém uma forte coesão entre a estrutura e o comportamento dos objetos, e essa é a
maneira como a realidade se manifesta.
• Facilidade para reusabilidade:
— A grande procura da Engenharia de software nos últimos anos foi uma forma, ou um método
que possibilitasse o reuso de código, prometida por todos, mas nunca alcançado.
— A OO, com a implementação do conceito de generalização e especialização, a partir da herança,

possibilitam isto.
• Melhor suporte à integridade:
— Interação entre os componentes OO é restrita a poucas interfaces que são bem definidas.
— A única forma de comunicação entre os objetos se dá por meio de troca de mensagens.
• Suporte decorrencial à concorrência:
— A sincronização de suas partes pode ser mostrada por meio de diagramas e da passagem de
mensagens entre os objetos do sistema.
• Uso de herança:
— Identifica e aproveita os pontos comuns dos dados e serviços (operações, rotinas, métodos).
Herança é sinônimo de reusabilidade.
A orientação a objetos oferece modularidade de seus elementos, podendo-se tomar um subconjunto

existente e integrá-lo de uma maneira diferente em outra parte do sistema.
17
Unidade I
Afirma-se que, dessa forma, uma aplicação (sistema) no universo de objetos consiste de um conjunto
de blocos de construção autocontidos e predefinidos que podem ser localizados, reparados ou substituídos.
Lembrete
Uma das coisas mais importantes da modelagem orientada a objetos está

na reusabilidade. As técnicas de orientação a objetos permitem reutilizar
muito mais do que o código. Com os modelos orientados a objetos, pode-se
reutilizar requisitos, análise, projeto, planejamento de testes, interfaces de
usuários e arquiteturas.
Praticamente todos os componentes do ciclo de vida da Engenharia de software podem ser

encapsulados como objetos reusáveis (YOURDON, 1998).
A essência da análise e do desenho orientados a objetos de uma aplicação de software é a descrição

de comportamentos. Modelos dinâmicos são utilizados para implementar os comportamentos que
atendem às necessidades e metas do usuário.
As disciplinas de análise e de desenho com objetos apresentam técnicas utilizadas para separar e
encapsular os comportamentos das aplicações de software.
Os diferentes modelos elaborados durante a análise e o desenho são utilizados de acordo com a sua
natureza:
• Modelo dinâmico: descreve os comportamentos exibidos pelo computador, quando esse realiza os
serviços solicitados pelo usuário.
• Modelo estático: descreve a estrutura lógica do computador, de modo que ele se comporte de
maneira adequada, e gerencia as dependências entre as diversas partes lógicas do computador.
A modelagem orientada a objetos inicia-se com a análise orientada a objetos (AOO), que estabelece o
comportamento fundamental de um sistema, comportamento que pode ser mantido independentemente
de como o sistema será construído.
Na análise OO, são construídos modelos formais de um sistema de software proposto (semelhante
aos modelos em escala de um prédio feitos por um arquiteto ou engenheiro civil), que capturam os
requisitos essenciais do sistema.
Esse modelo deve ser documentado em uma notação ou linguagem simbólica, de preferência
conhecida e testada no mercado de software.
Um modelo de AOO retrata objetos que representam um domínio de aplicação específico, juntamente
com diversos relacionamentos estruturais e de comunicação.
18
De acordo com Yourdon (1998), o modelo de AOO serve para dois propósitos: primeiro, para formalizar
a visão do mundo real dentro do qual o sistema de software será construído; segundo, estabelece
a maneira pela qual um dado conjunto de objetos colabora para executar o trabalho do sistema de
software que está sendo especificado.
Na abordagem AOO, de Edgard Yourdon, existem cinco camadas ou visões, conforme a figura 2, que
permitem visualizá-lo de perspectivas distintas.
Nome da camada Símbolos

Bordas da classe
Classes e objetos
Borda da instância (objeto)
Atributos
Atributos
Conexão entre
objetos
Mensagens
Serviços
Serviços
Estruturas
Assuntos Assuntos
Figura 2 – Estrutura de um modelo de AOO
A camada de classes e objetos apresenta os blocos básicos de construção do sistema proposto. Os

objetos são abstrações de conceitos do domínio de aplicação do mundo real.
O coração de qualquer AOO é o processo denominado de modelagem de informações. Na modelagem

AOO, os autores consideram como parte difícil do problema estabelecer o que são as coisas do mundo
real.
No caso de métodos orientados a objetos, tem sido dada mais ênfase na modelagem de informações
como um procedimento formal dentro do processo de Engenharia de software (YOURDON, 1998).
A figura 3 apresenta um exemplo de aplicação da modelagem AOO com o uso da notação de Edward
Yourdon. Serão representadas as entidades envolvidas em um domínio de prestação de serviços por
assinatura, como uma assinatura de tv fechada, uma assinatura telefônica etc.
O exemplo apresenta somente alguns atributos e alguns serviços de um domínio de aplicação

qualquer.
19
Unidade I
Assinante Assinatura
Id_assinante Id_assinatura
Det_assinante 1 1 Estado_assinatura
Id_endereco Detalhes_assinatura
Entrar_assinante
Informar_endereco
Entrar_assinatura
Figura 3 – Exemplo de uma aplicação da AOO
Após a modelagem completa do sistema com todas as entidades, seus atributos, seus serviços e suas
estruturas comportamentais definidas (relacionamentos), deve ser construído o Projeto Orientado a
Objetos (POO), como uma extensão do modelo AOO.
Na proposta de Edward Yourdon, o modelo POO contém as mesmas cinco camadas e usa a
mesma notação do modelo AOO, mas é estendido para conter: componente de interação humana
(interface homem x máquina), componente de gerenciamento de tarefas e componente de
gerenciamento de dados.
O componente de interação humana modela a tecnologia de interface que será usada para uma
implementação específica do sistema.
O componente de gerenciamento de tarefas especifica os itens operacionais que serão

estabelecidos para implementar o sistema. Finalmente, o componente de gerenciamento de dados
define aqueles objetos necessários para interfacear com a tecnologia de banco de dados que está
sendo usada.
Além da abordagem de Edward Yourdon, outros métodos e modelagens orientadas a objetos

apareceram desde a década de 1970 até 1995. A seguir, algumas das iniciativas desse período:
• Sally Shlaer e Steve Mellor escreveram livros sobre análise e desenho orientado a objetos no final
da década de 1980 e início da década de 1990.
• Jim Odell e James Martin basearam seus enfoques na longa experiência adquirida por ambos
no uso e divulgação da Engenharia da informação. Em 1994 e 1996, lançaram os livros mais
conceituais da época.
• Peter Coad e Ed Yourdon escreveram livros que propuseram um enfoque de desenho recursivo em
1997, propondo a AOO e o POO.
• Jim Rumbaugh liderou uma equipe de pesquisadores nos laboratórios da General Electric, que o
levou ao livro sobre métodos chamados OMT (Object Modeling Technique) em 1991.
20
• Grady Booch desenvolveu um método na Rational Software para análise de sistemas intensivos
em Engenharia e que foram apresentados em seus livros publicados em 1994 e 1995.
• Ivar Jacobson produziu seus livros a partir de sua experiência em sistemas na Ericson e desenvolveu
o método OOSE (Object-Oriented Software Engineering), que se tornou a base do processo UP e
do processo RUP.
Toda a proposta está na procura da independência de tecnologia e, portanto, a busca da reusabilidade.

Se um dia for necessário trocar a tecnologia envolvida com as interfaces GUI por outra tecnologia mais
atual, seria necessário substituir apenas o componente de interação humana.
A história da OO inicia-se no final da década de 1960, com a linguagem Simula, que foi projetada
por Kristen Nygaard e Ole-Johan Dahl no centro de computação norueguês, em Oslo.
No início da década de 1970, os cientistas da computação Edsger Dijkstra e David Lorge Parnas
trabalharam no conceito de programação modular, que é um importante elemento da programação
orientada a objetos nos dias de hoje.
Também na década de 1970, surge a linguagem Smalltalk:
• Uma linguagem de programação orientada a objeto fracamente tipada. Em Smalltalk, tudo é

objeto: os números, as classes, os métodos, os blocos de código etc.
• Não há tipos primitivos, ao contrário de outras linguagens orientadas a objeto. Strings, números e
caracteres são implementados como classes em Smalltalk, por isso essa linguagem é considerada
puramente orientada a objetos.
• Tecnicamente, todo elemento de Smalltalk é um objeto de primeira ordem.
• Os programadores definem classes de objetos em suas aplicações para imitar (ou simular) o mundo
real. Essas classes de objeto são organizadas hierarquicamente, de modo que seja possível fazer
novos objetos com características de outros objetos, com poucas mudanças.
• A linguagem Smalltalk foi desenvolvida por Adele Goldberg e Alan C. Kay.
No final da década de 1970, surge a linguagem ADA:
• Ada é uma linguagem de programação estruturada, de tipagem estática, é uma linguagem

imperativa, orientada a objetos, e é uma linguagem de alto nível, originada da linguagem Pascal
e de outras linguagens.
• Foi originalmente produzida por uma equipe liderada por Jean Ichbiah, da Companhia Honeywell
Bull, contratada pelo Departamento de Defesa dos Estados Unidos durante a década de 1970, com
o intuito de substituir as centenas de linguagem de programação usadas pelo DoD.
21
Unidade I
• Ada é uma aplicação com compiladores validados para uso confiável em missões críticas, tais
como softwares de aviação. Normatizada internacionalmente pela ISO, sua versão mais atual é de
2005.
Em meados de 1980, o cientista da computação dinamarquês Bjarne Stroustrup criou a linguagem

C++ e, dessa forma, é conhecido como o pai da linguagem de programação C++.
Stroustrup também escreveu o que muitos consideram a obra padrão de introdução à linguagem, A
linguagem de programação C++, que se encontra na terceira edição. A obra possui revista para refletir a
evolução da linguagem e o trabalho do comité de padrões de C++, e inspirou as novas linguagens, tais
como a linguagem Java e o C#.
Saiba mais
Vale a pena ler o livro de Bertrand Meyer cujo título é Object-oriented

Software Construction, que se tornou um clássico na área da tecnologia
OO. O livro, apesar de ser de 1988, já apresenta um conjunto de conceitos
sobre a reusabilidade, técnicas de projeto, programação orientada a objetos
e a aplicação das técnicas OO em outros ambientes de desenvolvimento.
1.6 Conceitos básicos da orientação a objetos
Os objetos podem ser vistos como blocos de construção que, combinados por meio de técnicas
apropriadas, produzem um sistema.
Blocos de construção
Blocos de rotinas/métodos
Técnicas adequadas
Análise/ de análise e projeto
Projeto/
Construção
Sistemas
Figura 4 – Objetos vistos como blocos de construção
22
A tecnologia OO apresenta diversos conceitos fundamentais para seu entendimento e aplicação

(FURLAN, 1998):
• Objeto: um objeto é uma ocorrência específica (instância) de uma classe e é similar a uma entidade
de dados do modelo E x R ou a uma tabela relacional, somente até o ponto em que representa
uma coleção de dados relacionados com um tema em comum.
Uma pessoa é um objeto, um veículo é um objeto, um documento é um objeto.
Outros conceitos sobre objeto:
— Objeto é uma bolha de inteligência que sabe agir numa determinada situação (Steve Jobs).
— Objeto é alguma coisa que faz sentido no contexto de uma aplicação, dependente do nível de
abstração do desenvolvedor do sistema.
— Objetos são a base da tecnologia orientada a objetos.
— Objetos podem representar coisas do mundo real: carro, gato, máquinas etc.
— Entidades conceituais: conta bancária, compras, pedido etc.
— Coisas visuais: polígonos, pontos, retas, letras, formulários etc.
— Objeto é um conceito, uma abstração, algo com limites nítidos e significado com relação ao
problema em causa (James Rumbaugh).
• Abstração: abstração consiste na seleção que se faz de alguns aspectos do problema em questão,
ignorando-se outros aspectos.
— Qualquer objeto real pode ser abstraído para filtrar seu estado e comportamento.
— O estado de um objeto é determinado pelo seu conjunto de atributos (dados), e seu

comportamento é definido pelos seus serviços (métodos).
– Exemplos de objetos de informática: label, botão, caixa de texto, de diálogo etc.
– Exemplos de objetos de negócio: funcionário, departamento, produto etc.
• Mensagem: objetos se comunicam a partir da troca de mensagens, isto é, um sinal enviado de

um objeto a outro, requisitando um serviço por meio da execução de uma operação do objeto
chamado.
— A interface lógica entre objetos é feita a partir da passagem de mensagens.

23
Unidade I
— As mensagens ocorrem apenas entre objetos que possuem uma associação.
— Todo o processamento da OO é ativado por uma implementação de mensagens que reforça o

conceito de baixo acoplamento em sistemas orientados a objetos.
— A recepção de uma mensagem causa a invocação de uma operação no recebedor (objeto alvo).
Esse executa o método da classe que corresponde àquela operação.
— Uma mensagem pode tomar várias formas: procedure, passagem de sinal entre “threads” ativas,
acionamento específico de um evento etc.
— Um determinado objeto, recebendo uma mensagem, executará uma ação específica como
resposta, alterando seu estado interno, enviando mensagens a outros objetos, criando novos
objetos etc.
Objeto o1 Objeto
cliente para o2
Objeto o3
Objeto
servidor
Mensagem para o2
de o1
para o2
Objeto o2
Objeto
cliente
para o3
01 02
aeronave Flap 1
Flap Objeto
Objeto Ângulo
Flap
aeronave aterrisar ajustar ângulo
Flap
ajustado
Nome da
mensagem
Figura 5 – Troca de mensagens entre objetos
— A mensagem indica uma solicitação de O1 para O2, “coloque o flap num ângulo x!”
— Essa é uma mensagem imperativa.
— O objeto 02 responde que está tudo ok. Na OO, os parâmetros de chamada e resposta também
são chamados objetos (tudo é objeto).
24
• Polimorfismo: é o poder que uma operação de um objeto tem de assumir vários comportamentos
dependendo da chamada recebida, tratando e devolvendo respostas específicas ao chamador.
— Exemplo: uma classe possui um atributo saldo que pode variar de acordo com o objeto
chamador. Pode ser saldo do correntista, saldo da poupança, saldo do fundo de ações, saldo de
renda fixa etc.
— Então, a operação “buscar_saldo” vai buscar o saldo dependendo do tipo ou parâmetro da

chamada, tendo várias lógicas diferentes para um mesmo comportamento denominado
“buscar_saldo”.
• Classe: classe é uma coleção de objetos que podem ser descritos com os mesmos atributos e as
mesmas operações.
— Representa uma idéia ou um conceito simples e categoriza objetos que possuem propriedades
similares, configurando-se em um modelo para a criação de novas instâncias.
— É uma abstração das características comuns a um conjunto de objetos similares.
— A classe pode ser pensada como sendo um tipo abstrato de dados.
— Conjunto de objetos com propriedades semelhantes, mesmo comportamento (operações,

métodos), mesmos relacionamentos com outros objetos e mesma semântica em um domínio
de aplicação.
— É como se fosse um molde para criação de objetos.
— A linguagem Java é um conjunto de classes. Por exemplo: Panel, Label etc. Se o objeto “O”
pertence à classe “C”, dizemos que:
– “O” é uma instância de “C”; ou
– “O” é um membro da classe “C”; ou
– “O” pertence a “C”.
— Quando queremos ser precisos e nos referirmos a uma coisa exata, usaremos “instância de
objeto”.
— Para nos referirmos a um grupo de coisas semelhantes, usaremos “classe de objetos”.
— Os objetos de uma classe compartilham um objetivo semântico comum, além dos requisitos de
atributos e comportamentos.
25
Unidade I
Classe Classe
Cavalo Celeiro
Figura 6 – Exemplo de classe de objetos
— Embora um celeiro e um cavalo tenham ambos um preço e uma idade, podem pertencer a
classes diferentes.
— Caso sejam vistos, no problema, apenas como bens contábeis, poderiam pertencer à mesma classe.
• Herança: é a capacidade de um novo objeto tomar atributos e operações de um objeto existente,

permitindo criar classes complexas sem repetir código. A nova classe simplesmente herda seu
nível base de características de um antepassado na hierarquia de classe.
— O propósito principal do uso de herança é construir estruturas que possam ser estendidas
em muitas formas diferentes. Esse enfoque pragmático pode-se completar considerando os
propósitos de reusabilidade a vários níveis e os propósitos de ordem conceitual.
— A reusabilidade é uma das metas mais prezadas que os produtos de software pretendem
atingir. O termo reusar tem o significado de poder usar um elemento numa situação diferente
da original para o qual foi criado, reduzindo e simplificando esforços (MATICH e CARVALHO,
1992).
— A herança tem implicitamente um propósito de reusabilidade, já que proporciona uma forma

de reaproveitar características capturadas por componentes, seja na forma de objetos, tipos ou
classes.
• Atributo ou propriedade: característica particular de uma ocorrência da classe, por exemplo: o

aluno possui nome, sexo, data de nascimento, número de registro, telefone etc.
— Característica que um objeto possui. Exemplo: nome, cor, altura, data de nascimento etc.
— Conjunto de propriedades de um objeto que definem o seu estado.
– Propriedades estáticas: mantêm o mesmo valor durante toda a sua existência (exemplo:
data de nascimento de uma pessoa).
– Propriedades dinâmicas: podem ter valores que variam com o passar do tempo (exemplo:
salário de um funcionário).
• Encapsulamento: combinação de atributos e operações em uma classe. Exemplo: classe “aluno”,

com atributo “nome” e operação “altera_nome_aluno”.
26
— É a capacidade que possuem os objetos de incorporar tanto as estruturas de dados que os

determinam, como as operações aplicáveis a essas estruturas em único bloco de organização e
só permitir o acesso a elas por meio de métodos determinados.
— Vantagens do encapsulamento:
– Esconder (ocultar) a complexidade do código.
– Não é necessário conhecer como a operação é feita para poder utilizá-la, o código é oculto
do usuário.
– Proteger os dados, permitindo o acesso a eles apenas a partir de métodos, evita que seus
dados sejam corrompidos por aplicações externas.
• Generalização: atributos e operações comuns, compartilhados por classes em uma hierarquia

“pai-e-filho”, ou superclasse e subclasses, ou classe “pai” e classes “filho”.
• Instância de classe: uma ocorrência específica de uma classe. É o mesmo que objeto. “José
Carlos Filho” é uma instância da classe aluno, já que o “José Carlos Filho” é aluno cadastrado no
sistema acadêmico da escola.
— Classes fabricam instâncias sob requisição. Esse processo é chamado instanciação.
Um objeto
Aeronave
Uma
classe Outro objeto
Instanciação
E outro objeto
Figura 7 – Instanciação
— O projetista/programador cria a classe. Em tempo de execução, a classe pode ser solicitada para
criar novos objetos.
— Uma classe possui dados/atributos ou variáveis (programação), serviços/operações ou métodos

(programação).
– Exemplo: quantidade de carros é um atributo de classe da classe carro. Cada atributo de

classe possui um único valor para o conjunto de objetos da classe.
27
Unidade I
— Uma instância (um membro) de uma classe também possui: dados/atributos ou variáveis de
instância e operações/métodos de instância.
– Exemplo: cor, peso e ano de fabricação são atributos de instância da classe “carro”.
— Cada atributo de instância possui um valor para cada instância de objeto. O nome de um
atributo é único dentro de uma classe.
— O agrupamento de objetos em classes permite a abstração de um problema.
— As definições comuns e as operações de cada instância são descritas somente uma vez na
classe, e os objetos da classe podem beneficiar-se da reutilização das definições armazenadas.
• Operações: lógica contida em uma classe para designar-lhe um comportamento. Exemplo:

calcular a idade de um aluno dada a sua data de nascimento.
— Operação é uma função ou transformação que pode ser aplicada a objetos ou por esses a uma
classe em uma determinada situação.
– Exemplo: alterar sua cor, mostrar uma janela, debitar um valor, aceitar o crédito de um cliente.
— Todos os objetos da classe compartilham as mesmas operações.
— Método é a implementação de uma operação para uma classe.
— O ato de invocar um método também é chamado de “passar uma mensagem para o objeto”.
— Toda classe possui um método denominado “construtor”: atribui valores às propriedades de um

objeto quando esse é criado. É o método de inicialização de um objeto instanciado.
— Em Java o método construtor possui sempre o mesmo nome da classe.
• Subclasse: característica particular de uma classe. Exemplo: classe “animal”, subclasses “gato”,
“cachorro” etc.
2 a linguagem unificada de modelos (uml)
2.1Introdução
Antes da UML, havia uma diversidade imensa e improdutiva de abordagens de modelagem, e sua convergência
na UML 1.0 foi um passo à frente significante na utilização de modelos no desenvolvimento de software.
Cada desenvolvedor usava a abordagem do autor de sua preferência, que nem sempre convergiam
suas opiniões em torno do tema. Outro problema era a proliferação de ferramentas gráficas específicas
28
para uma determinada notação para uma metodologia OO também específica e, na maioria das vezes,
proprietárias.
Ivar Jacobson, Grady Booch e Jim Rumbaugh, em 1995, tomaram a iniciativa de unificar os métodos
OOSE (Object Oriented Software Engineering), o método Booch’93 e o OMT (Object Modeling Technique)
e deram o nome de UML. UML significa Unified Modeling Language e é uma ferramenta para modelagem
de sistemas de todas as complexidades (MEDEIROS, 2004).
Lembrete
UML significa Unified Modeling Language (Linguagem Unificada de

Modelos) e é uma ferramenta para modelagem de sistemas de todas as
complexidades, (MEDEIROS, 2004).
Em 1999, na versão 1.3, a UML passou a ser mantida pela OMG (Object Management Group), que é
um grupo americano responsável pela padronização do uso da orientação a objetos nos Estados Unidos.
A UML firma-se então no mercado e passa a ser um padrão internacional para a especificação e
modelagem de sistemas aplicativos em todas as áreas de abrangência da área de informática ou TI
(Tecnologia da Informação).
A finalidade da UML é proporcionar um padrão para a especificação e arquitetura de projetos de

sistemas, desde os aspectos conceituais até as soluções concretas, tais como, as classes de objetos,
esquemas de banco de dados e componentes de software reusáveis (BOOCH; RUMBAUGH e JACOBSON,
1999).
A UML foi criada para ser independe de processo de software. Os desenvolvedores podem pegar
alguma coisa da UML que seja apropriado para seu próprio tipo de projeto e para seu próprio processo,
usando a UML para registrar os resultados de suas decisões de análise e design.
Lembrete
A garantia de ser um padrão internacional levou a UML a ser adotada

pela OMG que especifica e mantém o metamodelo UML.
A especificação da UML, na OMG, é definida usando-se uma abordagem de metamodelo, (isto é,

um metamodelo é usado para especificar o modelo que compreende a UML), que adota técnicas de
especificação formal.
Por outro lado, enquanto essa abordagem usa o rigor de um método formal de especificação,
também oferece a vantagem de ser mais intuitivo e pragmático para a maioria dos implementadores e
praticantes.
29
Unidade I
O metamodelo da UML foi projetada com os princípios de design flexível, tendo em mente o seguinte:
• Modularidade: o princípio da forte coesão e baixo acoplamento é aplicado para a construção em

pacotes, que permitem organizar recursos em metaclasses.
• Camadas: o conceito de camadas é aplicado para o metamodelo UML.
• Particionamento: o particionamento é usado para organizar as áreas conceituais dentro de uma

mesma camada.
• Extensibilidade: a UML pode ser estendida de duas maneiras:
— Um novo dialeto da UML pode ser definido por meio de perfis para personalizar o idioma
para plataformas específicas (por exemplo, (J2EE/EJB, .NET / COM +) e domínios (por exemplo,
finanças, telecomunicações, aeroespacial).
— Uma nova linguagem relacionada à UML pode ser especificada por reutilizar parte do pacote e
bibliotecas de “InfraEstrutura” dessa.
• Reutilização: a biblioteca do metamodelo é flexível para permitir que seja reutilizada para definir
o metamodelo UML, bem como outros metamodelos arquitetônicos relacionados, tais como, o
Meta Object Facility (MOF) e o Common Warehouse Metamodel (CWM).
A infraestrutura da UML é definida pela biblioteca de “InfraEstrutura” UML, pertencente e definida

pela OMG. A OMG é uma associação internacional, aberta, sem fins lucrativos e um consórcio da indústria
de computador desde 1989.
Qualquer organização pode participar da OMG e dos processos de definição das normas. A política da
OMG garante que todas as organizações, grandes e pequenas, tenham uma voz eficaz no seu processo.
A associação inclui centenas de organizações, sendo metade de softwares finais e a outra metade
representando praticamente todas as organizações da indústria de computadores.
Quando metamodelamos, primeiramente distinguimos entre metamodelos e modelos. Um modelo

deve ser instanciado a partir de um metamodelo que, por sua vez, pode ser usado como um metamodelo
de outro modelo de forma recursiva.
Um modelo normalmente contém os elementos do modelo. Esses são criados instanciando-se

os elementos do modelo a partir de um metamodelo. O papel típico de um metamodelo é definir a
semântica de como os elementos do modelo em um modelo podem ser instanciados.
Como exemplo, considere-se a figura 4, em que as metaclasses “Classe” e “Associação” são ambas
definidas como parte do metamodelo UML.
30
Essas são instanciadas em um modelo de usuário ou desenvolvedor, de modo que as classes “Pessoa” e “Carro” são
as duas instâncias da metaclasse “Classe”, e a associação entre as classes é um exemplo da metaclasse “Associação”.
A Figura 8 mostra todos os relacionamentos entre o metamodelo e o modelo do sistema que está
sendo desenvolvido.
Metalmodelo
UML Classe Associação
“InstânciaDe”
Modelo do Pessoa Carro

sistema
Figura 8 – Exemplo de metamodelagem (note que todos os relacionamentos são mostrados no diagrama)
A semântica da UML define o que acontece quando o usuário define os elementos que são
instanciados em seu modelo.
Saiba mais
Na atualidade, a UML encontra-se na versão 2.3 e é composta de 13

diagramas. A especificação formal da UML 2.3 pode ser encontrada no
endereço <www.omg.org/spec/UML/2.3/>.
Quadro 1 – Diagramas da UML
Número UML 1.X UML 2.3

1 Atividade Atividade
2 Caso de uso Caso de uso
3 Classe de objetos Classe de objetos
4 Objetos Objetos
5 Sequência Sequência
6 Colaboração Comunicação
Diagramas
7 Estado Estado
8 Componentes Componentes
9 Implantação Implantação
10 ------------- Pacotes
11 ------------- Interação
12 ----------- Tempo
13 ---------- Estrutura composta
31
Unidade I
A proposta da UML não é dizer como se deve fazer um software, mas sim proporcionar formas
ou maneiras que podem ser utilizadas para representar um software de acordo com a fase do
desenvolvimento.
Ela propõe modelos para a fase de especificação, outros modelos para a fase de design e modelos
para o momento de se definir as lógicas dos programas ou transações.
Todas essas formas ou modelos obedecem às regras e fundamentos da orientação a objetos na

construção de softwares.
Conforme Medeiros (2004), apesar da definição dos três amigos, pode-se dizer que a UML é uma
forma de comunicar uma idéia, e busca um padrão para a ciência da computação com relação à
comunicação de pessoas da área, e não uma linguagem de computador.
A UML não é um processo de desenvolvimento, tais como, o modelo cascade, ou o modelo RUP
(Rational Unified Process), ou o processo ágil SCRUM. É uma linguagem de comunicação que pode
ser utilizada em qualquer processo de software dentro de seu ciclo de vida. Hoje, é uma linguagem de
modelagem bem definida, expressiva, poderosa e geralmente aplicável a diversos tipos de sistemas, dos
mais simples até os mais complexos.
Além disso, a UML é não proprietária e aberta a todos. Com a aprovação da UML em novembro de
1997 pela OMG, a guerra de métodos OO havia chegado ao seu final.
De acordo com a UML, ela pode ser usada para:
• Mostrar as fronteiras de um sistema e suas funções principais. Aqui se introduziu os conceitos de

atores e casos de uso.
• Ilustrar a realização de casos de uso com diagramas de interações.
• Representar uma estrutura estática de um sistema utilizando diagramas de classes.
• Modelar o comportamento de objetos com diagramas de transição de estado.
• Revelar a arquitetura de implementação física com diagramas de componentes e de implantação

(deployment).
• Estender sua funcionalidade a partir de estereótipos.
2.2 A UML e o Processo Unificado
Para se falar de um processo de software, é necessário alguns conceitos envolvidos com a Engenharia
de software.
32
2.2.1 Engenharia de software e processos de software
Mas o que é a Engenharia de software?
A Engenharia de software pode ser conceituda como:
• Uma disciplina de Engenharia voltada para todos os aspectos da produção de software de qualidade.
• A Engenharia de software estuda processos, modelos e metodologias de desenvolvimento, a

gerência de projeto de software, investigação de novos métodos, ferramentas e teorias correlatas,
tais como, a qualidade e a produtividade.
• Envolve a escolha seletiva de métodos e ferramentas adequados para o atendimento de um

determinado contexto (restrições) de sistema de computação.
• Abrange todo o ciclo de vida do software, desde a especificação inicial do sistema até sua operação
e manutenção.
A Engenharia de software está baseada em pilares que lhe dão sustentação. A figura 9 mostra um
esquema dessa visão da ES.
Engenharia de software(s)
Processos/ Técnicas Ferramentas Qualidade/ Gerência

guias/práticas/ métodos produtividade governança
metodologias métricas
Figura 9 – Pilares da Engenharia de software
O estudo dos métodos/técnicas/métricas definem a sequência, a simbologia e os padrões em que as

atividades devem ser aplicadas no desenvolvimento e manutenção de software.
Com relação às ferramentas, a ES estuda e propõe a automatização dos métodos e técnicas. Essas
ferramentas de software são chamadas de ferramentas Case (Computer Aided Software Engineering).
A qualidade pode ser definida como um conjunto de modelos que apoiam o processo de
desenvolvimento na construção de softwares de qualidade. Com as ferramentas, procura-se também a
melhoria da produtividade das equipes de desenvolvimento.
A gestão/gerência/governança inclui o planejamento de projetos, controle dos projetos, alocação

de recursos, cronogramas e indicadores que apoiem na busca da garantia da qualidade dos produtos
confeccionados e no alinhamento da área de TI com as estratégias empresariais.
33
Unidade I
Dentro dessa abrangência da ES, um dos aspectos mais importantes é o estudo dos processos
envolvidos com o software.
Saiba mais
A Engenharia de Software é uma disciplina que é adotada

nos cursos de Ciência da Computação, Sistemas de Informação e
Engenharia da Computação e cobre todo ciclo de vida de um sistema
ou software .
Os principais livros adotados pelos cursos são: Engenharia de software,

de Roger. S. Pressman, editado no Brasil McGraw Hill; o livro Engenharia
de software, de Ian Sommerville, editado pela Addison-Wesley; o livro
Engenharia de software – teoria e prática, de James F. Peters e Witpçd
Pedrycz, editado pela Editora Campos; e o Livro Engenharia de software
fundamentos, métdos e padrões, de Wilson de Pádua Paula Filho, editado
pela LTC.
Mas, o que é um processo de software?
• Um processo de software é um conjunto estruturado de atividades (ou fases) necessárias para

produzir um produto de software.
• Um processo de software completo abrange as grandes fases de especificação, design ou projeto,

a implementação e a manutenção ou evolução do software.
• Os processos de software são organizados segundo diferentes modelos de desenvolvimento.
Quais são os modelos ou processos de software mais conhecidos?
• Ao longo do tempo, desde a década de 1960, a Engenharia de software desenvolveu diferentes

representações abstratas das fases de um processo de software e suas interdependências.
• Os modelos mais representativos e utilizados na Engenharia de software são:
— Modelo cascata (ou clássico):
– O paradigma do ciclo de vida clássico ou cascade demanda uma abordagem sistemática e

sequencial para o desenvolvimento de software.
– Começa em termos de sistema e progride por meio da análise, design, codificação, teste e
manutenção.
34
– A figura 10 mostra um esquema visual do modelo cascade ou cascata.
Engenharia de
Sistemas
Análise
Design
Codificação
Teste
Manutenção
Figrura 10 – Ciclo de vida clássico
– Todavia, os projetos reais raramente seguem um fluxo sequencial que o modelo propõe.
Ocorrem interações, voltas a níveis anteriores, provocando problemas na aplicação do
paradigma clássico.
– Frequentemente, os usuários têm dificuldade de estabelecer explicitamente todos os

requisitos do software, acompanhados das incertezas naturais que existem no início de
muitos projetos.
– Os usuários tem que ser muito pacientes. Uma versão do software somente estará disponível
quando todo o sistema for definido e desenvolvido. Qualquer alteração pode ocasionar um
desastre no desenvolvimento do sistema.
– Esses problemas são reais, porém o paradigma do ciclo clássico de software tem um definitivo
e importante lugar na Engenharia de software, pois ele proporciona um modelo real para o
uso dos métodos para analisar, projetar, codificar, testar e manter softwares.
— Espiral:
– O modelo espiral para a ES foi desenvolvido para abranger as melhores características do

ciclo clássico, adicionando um novo elemento chamado análise de risco.
– O modelo apresenta quatro grandes atividades:
– Planejamento: determinação dos objetivos, alternativas e requerimentos.
– Análise de risco: análise das alternativas e identificação e resolução dos riscos.

35
Unidade I
– Engenharia: desenvolvimento do próximo nível do produto.
– Avaliação do cliente: aceite dos resultados da Engenharia.
– O modelo espiral desenvolve o software passo a passo. Cada novo ciclo pressupõe um maior
detalhamento do software, sua construção por meio ou não de prototipagem e um uso real
para aceite dos usuários.
– A cada final de ciclo e início de outro, os riscos são avaliados e o projeto pode ser ou não
cancelado. O número de ciclos não pode ser alto, pois poderia colocar em risco o modelo.
– O ciclo final é utilizado para incorporar a parte de segurança, perfomance e garantias de

qualidade ao software.
– O modelo espiral segue os conceitos da iteratividade ao longo do desenvolvimento de um

aplicativo ou projeto de software.
Observação
Todos os modernos processos de software, inclusive os métodos ágeis,

consideram a iteratividade e a liberação parcial de um projeto em suas
propostas metodolóicas, conceitos oriundos do modelo espiral.
— 4GL – técnicas de quarta geração:
– O termo “técnicas de quarta geração” (4GL) abrange um conjunto de ferramentas de

software que possuem alguma coisa em comum.
– Permitem ao desenvolvedor especificar algumas características do software em alto nível de

abstração e então geram automaticamente códigos fontes baseados nas definições.
– Os principais ambientes que suportam o paradigma 4GL são: linguagens não procedurais para
pesquisas em banco de dados, geradores de relatórios, manipuladores de dados, definidores de
telas interativas, geradores de código, geradores de gráficos, arquitetura MDA etc.
– Idêntico aos outros paradigmas, o 4GL começa com a especificação dos requisitos junto aos
usuários, que deverão ser transportados para um prototipador. Os códigos gerados deverão
ser testados e aprovados para que o sistema possa ser considerado pronto.
– As técnicas de quarta geração têm se tornado uma parte importante da ES, principalmente
na área de sistemas de informação gerenciais. O que se ve é uma diminuição cada vez maior
no uso de métodos tradicionais no desenvolvimento de sistemas, e o crescimento no uso
das técnicas de quarta geração.
36
2.2.2 Os processos denominados de ágeis
Os processos ágeis ou a modelagem ágil é um processo baseado nas práticas que descrevem como
um modelador ágil deve agir.
A motivação é devido às estratégias atuais ou clássicas de modelagem que, muitas vezes, não se
mostram funcionais ou são consideradas muito pesadas e burocráticas.
Em um extremo, a modelagem não existe; do outro, se produz modelagem em excesso.
De acordo com Scott W. Ambler, a modelagem ágil se propõe a encontrar um meio termo, o qual
permita uma modelagem suficiente para explorar e documentar um sistema de modo eficaz, mas não a
ponto de tornar isso um fardo e fatalmente torná-lo um fracasso.
As técnicas da modelagem ágil podem e devem ser aplicadas por equipes de projetos que desejam
empregar uma estratégia ágil de desenvolvimento de software.
Os principais frameworks ou modelos ou métodos ágeis da atualidade são: XP (Xtremme Programming),

SCRUM, Crystal, AUP (Ágile Unified Process), ICONIX etc.
Saiba mais
Roger S. Pressman, em seu livro Engenharia de software (6ª ed.,

2006), nas páginas 59 a 76, faz uma abordagem sintética sobre os
métodos ágeis que ele denomina de desenvolvimento ágil, que se
inicia com a discussão do que é agilidade, passa pelos conceitos de um
processo ágil e apresenta os principais modelos ou métodos ágeis em
uso no âmbito internacional, tais como: a Extreme Programming (XP), o
Scrum, o Crystal, o FDD (Desenvolvimento Guiado por Características) e
a Modelagem Ágil.
2.2.3 O Processo Unificado – UP
O processo unificado UP (Unified Process) é um processo de software composto por quatro fases: a
fase de concepção, de elaboração, de construção e de transição.
O processo unificado, que depois foi extendido para o processo RUP (Rational Unified Process), é
todo baseado na UML cujos diagramas e modelos cobrem praticamente todo o ciclo de desenvolvimento
desses modelos.
A figura 11 mostra um diagrama criado por Scott W. Ambler que mostra, na vertical, as fases da UP
e, na horizontal, as disciplinas aplicadas nas fases.
37
Unidade I
Phases
Inception Elaboration Construction Transition
Model
Implementation
Test
Deployment
Configuration management
Project management
Environment
I1 E1 C1 C2 Cn T1 T2
Figura 11 – A UP vista sob a ótica dos modelos ágeis proposta por Scott W. Ambler
A fase inception seria a fase de concepção, a fase Elaboration seria a fase de elaboração, a fase
Construction é a fase de construção e a fase Transition é a fase de transição.
Na fase de concepção, se definem os requisitos do software e se avalia a tecnologia necessária

para uma solução aderente às necessidades do cliente. Nesse ponto, também é importante que sejam
considerados os riscos principais envolvidos com o software a ser desenvolvido.
Diversos diagramas e modelos da UML (disciplina Model) podem ser utilizados nessa fase, sendo o
mais importante modelo de casos de uso em um nível mais abstrato, já que não se pode demorar muito
para se fazer uma proposta comercial e técnica ao cliente envolvido.
Na fase de elaboração, na qual para a UP se detalham os requisitos, a UML apóia com diversos
diagramas e modelos (disciplina Model), tais como: o modelo de casos de uso com os cenários
detalhados, diagrama de atividades (para especificações visuais de lógicas mais complexas), diagramas
de estado, diagrama de classes em nível de domínio e outros que se fizerem necessários para deixar as
especificações suficientes para a implementação.
A fase de construção é quando se pensa em protótipos, em banco de dados e lógicas de programação.
A UML, nessa fase, contribui com os diagramas de sequência, comunicação, tempo, pacotes,
implantação e componentes.
Se o processo é iterativo e incremental, no qual o software não é liberado todo de uma

única vez, mas desenvolvido e liberado em pedaços, a fase de construção consiste de muitas
iterações, em que constrói-se software, testa-se e faz-se a integração que satisfaça um conjunto
de requisitos do projeto.
Já na fase de transição, estamos falando dos testes e homologação, dos quais a UML não possui
diagramas ou modelos de suporte diretamente.
38
Resumo
Este capítulo apresentou um histórico e conceitos da modelagem de

software e o histórico da linguagem de modelos UML.
Modelar sistemas é a capacidade de simplificar a complexidade inerente

aos sistemas de informação.
A construção de modelos permite se enxergar o todo antes de se iniciar

a construção ou programação propriamente dita.
Modelar significa desenhar e pensar antes de fazer. Permite a passagem

de conhecimento para outras pessoas que saibam ler os desenhos e as
plantas do sistema.
Significa, no final, que os sistemas fiquem menos dependentes de

pessoas e passem a ser uma propriedade coletiva.
Bom para os profissionais e bom para as empresas de software.
É importante salientar que a UML é uma linguagem de modelagem, não

uma metodologia de desenvolvimento de software.
A UML define uma notação e um metamodelo. A notação é o material

gráfico visto em modelos, é a sintaxe da linguagem de modelagem.
Ainda sobre a tecnologia orientada a objetos:
• As técnicas baseadas em objetos simplificam o projeto de sistemas

complexos.
• A tecnologia de objetos visualiza os sistemas como uma coleção de

objetos, cada um deles em um determinado estado, dentre muitos
estados existentes.
• A revolução na indústria de software indica um movimento em

direção a uma era em que os softwares serão montados a partir de
componentes reutilizáveis.
• Os componentes serão criados a partir de componentes existentes, e

serão criadas grandes bibliotecas desses componentes.
39
Unidade I
• Novamente, discute-se com bastante veemência o conceito das

caixas-pretas, cujo interior não enxergamos, apesar de sabermos o
que elas fazem ou produzem.
• As técnicas baseadas em objetos sozinhas não podem prover a

magnitude da mudança necessária. Elas têm de ser combinadas com
outras tecnologias.
• As tecnologias ditas otimizadoras são:
— ferramentas Case;
— programação visual;
— geradores de código;
— repositório central de dados e módulos/componentes;
— metodologias baseadas em objetos;
— banco de dados orientado a objetos;
— linguagens não procedurais;
— métodos formais baseados na matemática;
— tecnologia cliente-servidor, aplicativos orientados a serviços

(SOA);
— bibliotecas de classes que maximizem a reusabilidade;
— abstração de modelos mais próximas do mundo real.
Exercícios
Questão 1. Os autores que trabalham os conceitos envolvidos com os objetivos da

Engenharia de software afirmam que ela é a aplicação de teoria, modelos, formalismos, técnicas
e ferramentas da ciência da computação e áreas afins para o desenvolvimento sistemático
de software . Ainda de acordo com os autores, o desenvolvimento de software que utiliza
modelos para representar a realidade se torna mais produtivo e ágil; aqueles construídos em
padrões e simbologias predefinidos permitem que os participantes de um projeto, tanto os
analistas como os arquitetos e programadores de software , tenham um mesmo entendimento
do problema que está sendo resolvido. Os métodos, as técnicas e as ferramentas também
40
apoiam o gerenciamento do processo de desenvolvimento, devido principalmente a criação de

uma documentação formal, que é destinada à comunicação entre os membros da equipe e aos
usuários do sistema.
Considerando os conceitos sobre o uso de modelos no desenvolvimento de software, analise as

afirmações a seguir e assinale a alternativa incorreta:
A) O uso de modelos mentais influencia a forma de encararmos o mundo, e o trabalho com modelos
permite a realização de conversas ricas em aprendizados.
B) Como os modelos possuem uma sintaxe precisa, geralmente são melhor utilizados com o apoio
de uma ferramenta gráfica, que, por conter semânticas que determinam como os conceitos
específicos de domínio são aplicados, diminuem consideravelmente os erros cometidos no
processo de desenvolvimento.
C) Como os modelos aplicados na Engenharia de software podem abstrair e agregar informações

de uma série de artefatos, eles podem ser utilizados para as verificações de consistência e para a
garantia da qualidade.
D) Um modelo pode ser considerado um meio de comunicação entre as pessoas envolvidas

em um projeto. Também ajuda outros indivíduos, que podem utilizá-lo como base para a sua
implementação ou para a concepção de novos modelos.
E) Os modelos, no processo de desenvolvimento de software, somente possuem características de

comunicação e não conseguem apoiar a equipe na melhoria contínua de seus processos.
Resposta: Alternativa E.
A modelagem de sistemas de informação ou sistemas de software é uma atividade que, a partir da

construção de modelos, consegue explicar as características ou o comportamento de um aplicativo ou
de um sistema de software. No processo de desenvolvimento e construção de um software, os modelos
podem ser usados na identificação das características e funcionalidades que o software deverá prover e
no planejamento de sua construção.
Análise das alternativas
A) Correta. Quando se defronta com um problema, o homem desenvolve mentalmente uma série de
abstrações, as quais permitem o encaminhamento de soluções. Essas abstrações da realidade são
denominadas modelos.
B) Correta. Os modelos são acompanhados de padrões no seu uso e possuem uma semântica bem
definida. As ferramentas denominadas CASE incluem esses padrões, conseguindo, assim, orientar
e diminuir os possíveis erros que possam ser cometidos pelas pessoas.
41
Unidade I
C) Correta. A qualidade de software pressupõe que os artefatos produzidos no ciclo de desenvolvimento

devem ser verificados passo a passo, para que se tenha uma consistência nos produtos realizados.
Como os modelos representam graficamente os produtos de software, possibilitam revisões mais
cosistentes pelos participantes de seu processo de construção.
D) Correta. Como um modelo representa uma abstração de uma realidade, outros podem ser construídos
para uma solução de novos aspectos envolvidos com aquela realidade. Um modelo também pode ser
detalhado com o uso de novos modelos mais específicos dentro da realidade observada.
E) Incorreta. Os modelos no processo de desenvolvimento são utilizados por todos os envolvidos no

sistema e são considerados como uma forma de entendimento e apoio às atividades do processo
de desenvolvimento, que, a partir da avaliação dos problemas encontrados, pode proporcionar a
melhoria do processo.
Questão 2. A Orientação a Objetos é considerada um paradigma para o desenvolvimento de software.

Baseia-se na utilização de componentes individuais (chamados de objetos), que colaboram para construir
sistemas mais complexos. Toda a comunicação ou colaboração entre os objetos é feita por meio do
envio de mensagens (um objeto aciona outro objeto para a execução de uma operação e aguarda uma
resposta). Um paradigma é um conjunto de regras que estabelece fronteiras e descreve como resolver
problemas dentro dessa fronteira. Um paradigma ajuda o homem a organizar a e coordenar a maneira
como ele observa o mundo.
Considerando-se os conceitos sobre a Orientação a Objetos, analise as afirmações a seguir e assinale

a alternativa incorreta:
A) Dentro da tecnologia OO, um objeto é alguma coisa que faz sentido no contexto de uma aplicação
e representa uma entidade relevante para o entendimento e para a solução de uma necessidade
de uma atividade ou ao usuário do sistema.
B) Como na OO os objetos se comunicam por meio de mensagens, uma mensagem enviada por um
objeto causa a ativação de uma operação (método) no objeto alvo para responder ao chamado do
objeto ativador ou chamador.
C) Na OO, o conceito de polimorfismo surge quando uma operação de um determinado objeto atua
de acordo com as definições específicas de sua funcionalidade.
D) Para ser utilizada, uma classe de objeto precisa de um método denominado Construtor, que
inicializa o objeto quando ele é instanciado e disponibiliza os recursos para que sejam utilizados
pelos métodos ou operações do objeto.
E) A UML (Unified Modeling Language) foi desenvolvida na década de 1990 para unificar as diversas correntes
existentes no desenvolvimento de software que utilizavam a tecnologia da Orientação a Objetos.
Resolução desta questão na Plataforma.

42
MODELAGEM DE PROCESSOS
UNIDADE I
Questão 2
Resposta correta: alternativa C.
Justificativa: os autores originais da UML afirmam que a linguagem de modelos

não pretende dizer para os desenvolvedores como se deve fazer um software, e sim
proporcionar formas ou maneiras que podem ser utilizadas para representar essa
ferramenta de acordo com a fase do desenvolvimento dentro de um processo
específico. A UML propõe diversos modelos diferentes que cobrem todo o ciclo de
desenvolvimento, desde a especificação até a construção do produto de software. Os
modelos propostos na UML obedecem às regras e fundamentos da Orientação a
Objetos e não podem ser interpretados como um processo de desenvolvimento, como
os modelos cascade e RUP (Rational Unified Process) e o processo ágil SCRUM.
A) Correta. Uma aplicação desenvolvida com a Orientação a Objetos é um

conjunto de objetos (representados por classes de objetos) que interagem para
resolver as funcionalidades do sistema ou aplicação.
B) Correta. Os objetos são denominados de cliente e fornecedor. Cliente é o

objeto que aciona outro objeto; fornecedor é o objeto que atende a um chamado de
outro objeto. O atendimento ocorre por meio das operações do objeto fornecedor, que
recebe os parâmetros, executa suas ações e devolve o resultado ao objeto cliente
(chamador).
C) Incorreta. Polimorfismo é quando uma operação ou método de um objeto atua

de formas diferentes dependendo da chamada recebida. Isto é, o comportamento do
objeto varia de acordo com o tipo de chamada realizada para a operação do objeto.
Polimorfismo quer dizer diversas formas assumidas pelo objeto em um determinado
contexto.
D) Correta. Sem um método construtor, o objeto não poderia ser inicializado e não
se teria a atribuição de valores às propriedades do objeto.
E) Correta. Conforme Medeiros (2004), os autores Ivar Jacobson, Grady Booch e

Jim Rumbaugh se uniram em 1995 para unificar seus métodos para o
desenvolvimento OO e criaram a UML, que se tornou ao longo do tempo a linguagem
padrão para a OO.
Unidade II
3 Modelo Conceitual da UML
3.1 Introdução
O Object Management Group (OMG) adotou a UML em novembro de 1997. Essa adoção ocorreu
em um evento histórico e marcante, pois assinalou a aceitação de uma linguagem padronizada de
modelagem de sistemas baseada nas melhores práticas atuais para a análise, projeto e construção de
software orientado a objetos.
Saiba mais
A Object Management Group, ou OMG, é uma organização internacional

que aprova padrões abertos para aplicações orientadas a objetos. O Object
Management Group foi fundado em 1989. Constantemente, a OMG publica
o documento dos padrões e normativos sobre a UML no seu portal cuja URL
é: <http://www.omg.org/spec/UML/2.3/Infrastructure>.
A UML é a primeira notação que atingiu o concenso entre a maioria dos profissionais,
vendedores e acadêmicos como o padrão real para expressar um domínio comercial da solução
de software.
Grady Booch (2000) diz que a modelagem deve atingir quatro objetivos para se tornar efetiva em
um ambiente de desenvolvimento de software:
• ajudar a equipe de projeto a visualizar um sistema como ele é ou como ele pretende ser;
• ajudar a especificar a estrutura ou comportamento do sistema;
• proporcionar um modelo que sirva de guia na construção do sistema;
• documentar as decisões tomadas pela equipe de desenvolvimento de projeto (REED JR., 2000).
3.2 Visão geral da UML
A UML não é um modelo de processo/metodologia de software. É uma notação, um mecanismo para

“mostrar o problema” de forma a expor a essência do domínio de um aplicativo.
43
Unidade II
A combinação da UML com um bom modelo de processo, tais como, o RUP (Rational Unified Process)
ou o processo ágil SCRUM, resulta em uma poderosa combinação para a criação de aplicativos bem-
sucedidos (REED JR., 2000).
A linguagem de modelos UML tem dois objetivos: um deles é proporcionar consistência, informando
o cliente ou patrocinador do projeto de que o domínio do problema está bem entendido pela equipe
de desenvolvedores. O outro objetivo é proporcionar um modelo de consistência para a equipe de
implementação (arquitetos e programadores), que assim poderão fazer uma implementação adequada
do software.
Lembrete
Todavia, deve ficar claro que somente os diagramas da UML não

conseguem garantir o processo de desenvolvimento. Um bom modelo de
processo e um plano adequado do projeto são fundamentais para que o
projeto não falhe.
Todos os artefatos propostos pela UML são rastreáveis e, se construídos ao longo de um processo
de desenvolvimento padronizado na empresa, os modelos podem se completar uns aos outros. Esse
elemento da rastreabilidade é fundamental para o projeto.
Esses artefatos construídos ao longo do desenvolvimento com a UML servirão como um ponto
de controle da qualidade do modelo anterior, já que se completam. Como os modelos UML são inter-
relacionados na sua criação, é mais fácil identificar quando um componente está faltando ou está incorreto.
Todavia, a UML não resolve diretamente alguns aspectos de um projeto e, se necessário, deve-se
utilizar outros diagramas auxiliares, como a interface gráfica de usuário (GUI), a distribuição do processo
(processamento distribuído) e a distribuição dos dados (BDs distribuídos).
3.3 Arquitetura da UML
Uma arquitetura de sistema de software pode ser descrita por cinco visões interconectadas. Cada
visão é uma projeção na organização e estrutura do sistema, focando em um aspecto particular desse.
As cinco visões da arquitetura UML são: visão de análise, visão de design, visão de implementação,
visão do processo e visão da implantação. Para a UML, o modelo ou visão que interconecta essas visões
se dá pelo modelo de caso de uso.
A visão de caso de uso de um sistema compreende os que descrevem o comportamento do sistema

como visto pelos usuários finais, analistas e testadores.
Essa visão não especifica a organização do sistema de software. Na UML, os aspectos estáticos do
sistema são capturados no diagrama de caso de uso.
44
Os 13 diagramas da UML estão divididos em três categorias: estático, dinâmico e arquitetural:
• Os diagramas estáticos mostram a esturutra do sistema e as responsabilidades. Esses diagramas

mostram a estrutura física dos elementos e não envolvem a passagem do tempo. Isto é,
eles não mostram a dinâmica das coisas, simplesmente sua organização. Os três principais
diagramas estáticos da UML são: o modelo de caso de uso, o modelo de classes e o modelo
de objetos.
• Um diagrama dinâmico mostra a interação ativa que o sistema suporta e detalha a interação
entre os elementos estruturais dos diagramas estáticos.
• Essas interações dinâmicas são descobertas nos casos de uso como caminhos executados
em resposta a alguns estímulos externos ao sistema. Os diagramas dinâmicos mostram o
comportamento pretendido do sistema. Os principais diagramas dinâmicos são: atividades,
comunicação, sequência e estado.
• Um diagrama arquitetural mostra a realização do sistema em componentes funcionais e

executáveis. Eles também diferenciam a localização física da execução e os nós de armazenamento
e uma estrutura dentro da qual eles podem interagir.
• Os principais diagramas estruturais são: componentes e implantação.
3.4 Modelagem estrutural
Na UML, o principal diagrama que mostra a estrutura de um sistema é o diagrama de classes.
Todavia, outros diagramas também permitem visualizar a estrutura do sistema, tais como, o diagrama
de pacotes, o diagrama de componentes, o diagrama de objetos e o diagrama deployment (implantação).
3.4.1 Classes de objetos
Uma classe de objetos é uma coleção de objetos que podem ser descritos com os mesmos atributos
e as mesmas operações.
Representa uma idéia ou um conceito simples e categoriza objetos que possuem propriedades
similares, configurando-se em um modelo para a criação de novas instâncias (outros objetos).
Uma classe de objetos na UML possui três segmentos: nome, atributos e operações.
A representação ou notação de uma classe é um retângulo com os três segmentos. Cada classe deve
ter um nome que a distingue de outras classes. Um nome é um texto.
Uma classe possui diversos atributos. Um atributo é uma propriedade do objeto que descreve a faixa
de valores que as instâncias do objeto podem ter.
45
Unidade II
O terceiro segmento da classe são as operações. Uma operação é a implementação de um serviço

ou funcionalidade que pode ser requisitado de qualquer objeto da classe para afetar o comportamento
do objeto.
3.4.2 Relacionamentos entre classes de objetos/instâncias
As classes de objetos, no modelo de classes, se relacionam ou se associam de acordo com as

necessidades do sistema. Esses relacionamentos são denominados “associação entre classes”.
Um relacionamento define as regras da associação que, por seu lado, são impostas pelas regras de
negócio da aplicação, sendo modelada.
A criação de um objeto, baseado em uma classe, recebe um nome especial: instância. Quando
é necessário manipular um determinado objeto, a classe é carregada na memória, e os objetos são
instanciados, isto é, são criados na memória e podem ser manipulados.
A instanciação de objetos depende da linguagem OO utilizada, mas, em geral, possuem uma função
especial que cuida das instâncias dos objetos, denominada construtora.
Quando o objeto já não é mais necessário, outra função especial chamada de destrutora da classe
elimina as instâncias criadas. Por exemplo: para uma classe funcionário, o objeto tipo funcionario “João
Carlos da Silva” seria uma instância na memória.
3.4.3 Mecanismos comuns
A UML é feita simplesmente pela presença de mecanismos comuns que garantem a consistência a
partir da linguagem, tais como: especificação, adornos e mecanismo de extensibilidade.
A especificação refere-se aos padrões das descrições dos componentes dos modelos: como
nomear os componentes, como descrever a lógica de um cenário de um caso de uso , e assim
por diante.
Adornos são itens gráficos e textuais que são adicionados a uma notação de um elemento básico e
são usados para visualizar detalhes da especificação do elemento. Por exemplo, no símbolo de nó de um
diagrama de implantação, pode ser interessante colocar os componentes executáveis dentro de uma
caixa extra do desenho.
O mecanismo de extensibilidade da UML permite extender a linguagem de uma maneira controlada.

Esse mecanismo inclui estereótipos, valores marcados e restrições.
Um estereótipo extende o vocabulário da UML, permitindo que se criem novos tipos

de blocos de construção que são derivados de outros existentes, mas especifícos para um
determinado problema.
46
3.4.4 Diagramas da UML
Com um modelo, é possível um melhor entendimento dos sistemas que estão em desenvolvimento.
Com a UML, pode-se construir modelos a partir de um conjunto de blocos básicos, tais como, classes,
interfaces, colaborações, componentes, nós, dependências, generalizações e associações.
Lembrete
Quando o homem modela qualquer coisa, ele está criando uma

simplificação da realidade.
A UML propõe 13 diagramas, conforme mostra a quadro 2:
Quadro 2 – Diagramas da UML
Número UML 1.X UML 2.3

1 Atividade Atividade
2 Caso de uso Caso de uso
3 Classe de objetos Classe de objetos
4 Objetos Objetos
5 Sequência Sequência
6 Colaboração Comunicação
Diagramas
7 Estado Estado
8 Componentes Componentes
9 Implantação Implantação (deployment)
10 ------------- Pacotes
11 ------------- Interação
12 ----------- Tempo
13 ---------- Estrutura composta
Lembrete
Com relação ao ciclo de desenvolvimento de software:
• Cada diagrama da UML, ou modelo, pode ser usado em um

determinado momento do ciclo de desenvolvimento de software.
• Um diagrama da UML deve ser usado para resolver ou mostrar

aspectos específicos do problema sendo modelado.
• Um diagrama da UML pode ser usado para especificar artefatos

diferentes em atividades diferentes do processo de software. Por
47
Unidade II
exemplo, o diagrama de atividade pode ser usado para detalhar uma

funcionalidade, como mostrar um determinado fluxo do problema
que está sendo estudado etc.
3.4.4.1 Diagrama de atividade
Os diagramas de atividades são usados para modelar o comportamento de um sistema, e a forma em

que esses comportamentos estão relacionados em um fluxo geral desse.
O fluxo mostra os caminhos de um processo lógico a seguir, com base em várias condições,
processamento simultâneo, acesso a dados, interrupções e outras distinções do caminho lógico.
São usados para construir um sistema, um processo, ou um procedimento.
3.4.4.2 Diagrama de caso de uso
Um diagrama de caso de uso captura as funcionalidades do sistema e as relações entre os atores e o

sistema. Ele descreve os requisitos funcionais do sistema, a maneira pela qual as coisas de fora (atores)
interagem no limite do sistema e a resposta desse aos usuários.
Lembrete
O diagrama de caso de uso, ou modelo de caso de uso, é um dos mais

importantes modelos da UML e será detalhado na Unidade 3.
3.4.4.3 Diagrama de objetos
Um diagrama de objetos está intimamente relacionado a um diagrama de classes de objetos,

com a distinção de que retrata instâncias de objetos das classes e seus relacionamentos em um
ponto no tempo.
Isso pode parecer semelhante a um diagrama de estrutura composta, que também modela
comportamentos em tempo de execução. A diferença é que os diagramas de objetos exemplificam os
diagramas de classes estáticas, enquanto que os diagramas de estrutura composta refletem arquiteturas
em tempo de execução.
Eles são úteis na compreensão de um diagrama de classes complexas, criando diferentes casos em
que os relacionamentos e as classes são aplicados.
Um diagrama de objeto também pode ser uma espécie de diagrama de comunicação, que
também modela as conexões entre os objetos, mas adiciona sequências de eventos ao longo de
cada caminho.
48
3.4.4.4 Diagrama de sequência
O diagrama de sequência é um dos quatro tipos de diagrama de interação. Um diagrama de sequência

é uma representação estruturada de comportamento com uma série de etapas sequenciais ao longo do
tempo.
Ele é usado para descrever o fluxo de trabalho, passagem de mensagens. Cada elemento da sequência
é organizado em uma sequência horizontal, com mensagens que passam para trás e para frente entre
os elementos.
Um elemento de ator pode ser usado para representar o usuário que inicia o fluxo de eventos.
Elementos estereotipados, como limite, controle e entidade, podem ser usados para ilustrar as telas, os
controladores e os itens de banco de dados, respectivamente. Cada elemento tem uma linha pontilhada
tronco chamada de linha-de-vida, na qual o elemento existe e, potencialmente, participa das interações.
3.4.4.5 Diagrama de comunicação
Um dos quatro tipos de diagrama de interação. Um diagrama de comunicação mostra as interações

entre os elementos em tempo de execução da mesma maneira que um diagrama de sequência.
No entanto, os diagramas de comunicação são usados para visualizar as relações entre objetos, enquanto
os diagramas de sequência são mais eficazes na visualização de processamento ao longo do tempo.
Os diagramas de comunicação empregam associações rotuladas e ordenadas para ilustrar o

processamento. A numeração é importante para indicar a ordem e a nodificação de processamento.
Um esquema de numeração pode ser: 1, 1.1, 1.1.1, 1.1.2, 1.2 e assim por diante.
3.4.4.6 Diagrama de estado (máquina de estado)
Os diagramas de estado da máquina eram anteriormente conhecidos como diagramas de estado.

Esse diagrama ilustra como um elemento (geralmente uma classe) pode mover-se entre os estados,
classificando o seu comportamento de acordo com gatilhos de transição ou guardas de restrição.
Outros aspectos do diagrama de máquina de estado ajudam a descrever e explicar os movimentos e

comportamentos dos sistemas.
3.4.4.7 Diagrama de componentes
Um diagrama de componentes mostra os pedaços de software, controladores embutidos que formam

um sistema, sua organização e as dependências.
Um diagrama de componente tem um nível maior de abstração do que um diagrama de classes. Geralmente,
um componente é implementado por uma ou mais classes (ou objetos) em tempo de execução.
49
Unidade II
Eles são blocos de construção, construídos de modo que, eventualmente, um componente pode
abranger uma grande parte de um sistema.
3.4.4.8 Diagrama de implantação
Um diagrama de implantação (deployment) mostra como e onde o sistema será implantado, ou seja,
sua arquitetura de execução.
Dispositivos de hardware, processadores e ambientes de software de execução (artefatos do sistema)

são refletidos como nós, e a construção interna pode ser representada incorporando nós no desenho.
Como os artefatos são alocados para os nós do modelo de implantação do sistema, a alocação é guiada
pela utilização das especificações de implantação.
3.4.4.9 Diagrama de pacotes
O diagrama de pacotes (pakage) mostra a organização dos elementos de um modelo em pacotes

(agrupamentos) e as dependências entre esses pacotes, incluindo pacotes importados e extensões de
pacotes.
3.4.4.10 Diagrama de interação (visão geral)
Um diagrama geral de interação visualiza a cooperação entre os diagramas de interação para ilustrar
um fluxo de controle que serve a um propósito abrangente.
Como os diagramas gerais de interação são uma variante de diagramas de atividades, a maioria da
notação do diagrama é a mesma, como é o processo de construção do diagrama.
Pontos de decisão, forks, junções, pontos iniciais e finais são os mesmos. Em vez de elementos
de atividade, no entanto, elementos retangulares são usados. Existem dois tipos desses elementos:
elementos de interação e e elementos de ocorrência.
3.4.4.11 Diagrama de tempo
Um diagrama de tempo define o comportamento de objetos diferentes dento de uma escala de

tempo. Ele fornece uma representação visual da mudança dos objetos, mudando de estado e interagindo
todo o tempo.
Ele pode ser usado para definir os componentes e softwares embutidos. Também pode ser utilizado
para especificar processos de negócio orientados pelo tempo.
3.4.4.12 Diagrama estrutura composta
Um diagrama de estrutura composta reflete a colaboração interna de classes, interfaces ou

componentes (e suas propriedades) para descrever a funcionalidade do sistema.
50
Eles são similares aos diagramas de classe, exceto pelo fato de que eles modelam um uso específico
da estrutura. Um diagrama de estrutura composta é usado para expressar o tempo de execução das
arquiteturas, padrões e relacionamentos dos elementos participantes, que não podem ser refletidos por
meio de diagramas estáticos.
4 Diagrama de classes de objetos da UML
Entre esses diagramas, o diagrama de classes é considerado um dos principais e será detalhado a
seguir.
4.1 Introdução
O diagrama de classes mostra a estrutura estática do sistema por meio de suas classes e objetos e
também como eles se relacionam.
É considerado por alguns autores como o mais importante diagrama no desenvolvimento orientado
a objetos e, portanto, também da UML.
Observação
A meta na construção de um modelo de objetos é incorporar os

conceitos do mundo real que sejam importantes para a aplicação.
A figura 12 mostra um exemplo de modelo de classes de objetos na notação da UML.
Mundo real
Realidade de interesse
(Observado)
Modelo de objeto
Nome da classe de objetos
Atributos
Operações ( )
Figura 12 – Visão do mundo real x a OO
51
Unidade II
A figura 13 mostra um exemplo de diagrama de objetos com um metamodelo de classe, uma classe
e duas instâncias da classe “José da Silva” e “Maria Rodrigues”.
José da Silva Maria de Tal

Nome da classe de objetos Pessoa 32 26
Nome dos atributos Nome
idade
Operações ( ) Mudar_endereço ( ) Objetos com valores da

classe pessoa.
O nome da classe (metamodelo)

representa o agrupamento de
objetos do mesmo tipo.
Figura 13 – Exemplo de uma classe e suas instâncias na notação UML
Alguns meios de implementação (linguagens de programação e sistemas gerenciadores de banco de

dados) exigem que um objeto tenha um identificador explícito para cada objeto. Esses identificadores
explícitos não são obrigatórios em um modelo de objetos.
A figura 14 mostra um uso incorreto de identificadores internos.
Pessoa Pessoa
Correto
Cod_Pessoa Nome
Nome idade
Figura 14 – Uso incorreto de identificador interno
Os identificadores internos (gerados pelas linguagens) não podem ser confundidos com atributos
do mundo real e não devem fazer parte do modelo conceitual. O “número_telefone” e “número_placa_
carro” não são identificadores internos porque têm significado no mundo real.
Uma classe sempre deve representar um mesmo assunto, isto é, ela encapsula conhecimentos sobre
algo. Não teria sentido colocarmos dados sobre a empresa em que trabalha na classe pessoa.
Pessoa e empresa são assuntos diferentes ou objetos diferentes e, portanto, devem estar em classes
distintas. Uma classe tem responsabilidade por tudo o que lhe diz respeito. Não é de responsabilidade da
pessoa/funcionário incluir ou manter os dados da empresa.
Uma classe poder ter visibilidade pública, protegida, privada:
• Uma classe pública indica que qualquer outra classe poderá acessar seus atributos e solicitar a
execução de suas operações.
52
• Uma classe é denominada de privada quando restringe totalmente o acesso a seus atributos e as
suas operações.
• Uma classe com visibilidade protegida somente permite a ela e aos seus herdeiros o acesso a seus
atributos e suas operações.
As operações ou comportamentos de uma classe de objetos recebem e devolvem valores que

são passados numa lista de argumentos, dentro de um padrão específico que cada linguagem
adota.
O diagrama do modelo conceitual deve ser independente da tecnologia, e quando da implementação

é que se considera os padrões específicos.
A figura 15 mostra um exemplo de chamada de uma operação com a lista de argumentos.

Exemplo: mudar_endereço (novo_endereço, ok)
Operação Parâmetro Parâmetro

de entrada de saída
Figura 15 – Exemplo de uma operação e a lista de argumentos
Em um modelo de classes, existem diversas classes do domínio da aplicação que precisam se

relacionar dentro das regras de negócio.
Elas, quando estão relacionadas, podem trocar mensagens para que uma determinada tarefa que
envolve diversos objetos possa ser realizada com sucesso.
Os relacionamentos das classes no modelo de classes podem ser de três tipos: associação, agregação
e composição e generalização/especialização.
4.2 Associação
Associação é uma relação semântica entre classes. Uma associação acontece quando uma
determinada instância de uma classe se associa a uma ou mais instâncias de outra ou da
mesma classe.
Ligações e associações são os meios para estabelecermos relacionamentos entre objetos e classes. As
ligações são conexões entre instâncias de objetos.
A figura 16 mostra o metamodelo de associação de classes e um exemplo prático.
53
Unidade II
Papel 1
Classe A Classe B
Papel 2
associação
Pessoa Empresa
trabalha_para
João da Silva Telesp
ligação
Figura 16 – Exemplo de uma associação entre duas classes. O modelo apresentado

é o modelo de objetos no qual o objeto pessoa trabalha para uma empresa
As associações ainda podem ser binárias, unárias, ternárias e assim por diante. Uma
associação é dita binária quando duas classes estão envolvidas na associação, conforme mosta
a figura 17.
Pais tem_capital Cidade
Nome 0.1 1 Nome
Figura 17 – Associação binária
Uma associação é dita unária quando o relacionamento de uma classe é consigo própria.
A figura 18 mostra um exemplo de associação unária. Uma peça pode compor outras peças maiores,
mas também pode ser composta de outras peças menores.
Peça 1..*
Componente
Composta 0..*
Figura 18 – Um exemplo de associação unária
Uma associação é dita ternária quando três classes fazem parte da associação. Na figura 19, tem-se
que um projeto tem várias pessoas trabalhando nele e pode ser implementado em várias linguagens
diferentes.
A nomeação das associações são opcionais para associações ternárias ou de ordem superior
(n-árias).
54
A figura 19 mostra um exemplo de associação ternária.
1..* 1..*
Projeto Linguagem
1..*
Pessoa
Símbolo de associação ternária ou de ordem superior
Figura 19 – Exemplo de uma associação ternária
4.3 Papéis em associação
A UML possui uma notação específica para representar as regras de uma associação entre os objetos
das classes.
A notação denomina-se cardinalidade ou multiplicidade e deve ser descrita no diagrama, como

mostra a tabela 1.
Tabela 1 – Cardinalidades ou multiplicidades das associações entre classes
Cardinalidade Descrição
0..1 Opcional e único
0..* Opcional e múltiplo
1 Obrigatório e único
1..* Obrigatório e múltiplo
* O mesmo que 0..*
2..4 De 2 a 4
1..2,5,7..14 1 e 2, 5 e 7 a 14
Quando se quer ressaltar que um dado elemento da associação deve estar classificado, deve-se
utilizar a palavra-chave {ordenado}, como mostra a figura 20.
Papel 2
Classe A Classe B
Papel 1 {ordenado}
Figura 20 – Uso da palavra chave {ordenado}
Quando se quer declarar a visibilidade da associação, deve-se colocar os símbolos em frente ao nome
do papel (“+” público, ”#” protegido, “-“ privado). Isso declara a visibilidade da associação em direção
àquele papel.
55
Unidade II
Por exemplo: na figura 9, se for colocado em frente do papel 1 o símbolo “+”, está declarado que esse
papel na associação é de uso público.
Quando existir a necessidade de mostrar o sentido da navegação em uma determinada

associação, deve-se colocar uma seta na extremidade da associação para indicar a direção
suportada pelo modelo.
A figura 21 mostra um exemplo do uso da navegação em uma associação entre duas classes de
objetos.
Pais tem capital Cidade
Nome 0..1 1 Nome
Figura 21 – Navegação (restrição de acionamento de classes)
A seta indica o sentido em que a navegação é suportada no modelo, dessa forma não é possível
operações da classe cidade acessarem as operações da classe país.
4.4 Classe de associação
Em alguns modelos, devido às regras de negócio, torna-se necessária a colocação de atributos em

uma determinada associação. Um atributo é uma propriedade dos objetos de uma classe.
Como uma associação também é um objeto, é perfeitamente possível colocar nela atributos. Então,
um atributo de ligação é uma propriedade de uma associação.
A figura 22 apresenta a classe “depto de uma empresa” e a classe funcionário, nas quais ficam os
funcionários da empresa.
Depto Chefia Funcionário

1
0..1 Cod_func
Nome nome
Figura 22 – O uso de atributos de associação
A questão que se coloca no modelo é: onde colocar a data de posse da chefia, em departamento
ou em funcionário? Todavia, a data de posse é uma propriedade da associação “chefia” e deve
pertencer a ela.
A data de posse não é propriedade nem do departamento e nem do funcionário.
Uma das soluções seria colocar a data em uma das classes associadas. A escolha fica a critério do
analista, já que esse atributo não é natural nem para departamento e nem para funcionário.
56
O problema decorrente da colocação dos atributos de ligação em uma das classes ligadas é a
flexibilidade futura do modelo. Caso haja qualquer dúvida com relação ao futuro, como regra, cria-se
uma “classe de associação”.
Como mostra a figura 23, criou-se uma classe nova denominada “classe de associação” para permitir
a colocação do atributo específico da associação.
A classe de objetos “chefia”, possui atributos próprios e provavelmente operações para tratar esses
atributos e as associações.
0..1
Depto Funcionário
1
Cod_func
Nome nome
Chefia
Data_posse
Figura 23 – O uso da classe de associação
A figura 24 mostra outro exemplo de classe de associação para um modelo mais sofisticado. Temos
um modelo que mostra uma empresa, seus funcionários e o grau de desempenho desses.
Funcionário Empresa
1..*
Nome 0..* Trabalha_para Nome
RG Endereço
Endereço
Trabalha para
Gerencia
Salário
Grau de Cargo
desempenho
Admite_funcionário ( )
Figura 24 – Classes de associação
Note que o grau de desempenho pertence à associação, já que o atributo somente tem sentido
enquanto o funcionário ocupa o cargo de gerência.
A classe “trabalha para” indica que o salário e o cargo do funcionário são atributos que dependem
da empresa em que trabalha, já que o modelo permite que um funcionario trabalhe em mais de uma
empresa.
57
Unidade II
4.5 Agregação e composição
Agregação é um tipo especial de associação em que um objeto contém o(s) outro(s). É também
chamado de relacionamento “todo/parte”. Agregação é um modo de associação na qual um objeto
agregado é feito de componentes. Os componentes fazem parte do agregado.
A figura 25 mostra um exemplo de agregação. Uma publicação possui artigos obrigatoriamente no

modelo. Isso significa que uma publicação é composta necessariamente de artigos.
O diamante vazio indica que a ligação é fraca, já que uma publicação pode existir sem nenhum
artigo, mas um artigo não existe sem uma publicação associada.
Publicação
1..*
0..*
Artigo
Figura 25 – Exemplo de uma agregação entre classes associadas
As agregações incluem explosões das partes e expansões de um objeto em suas partes constituintes.
A figura 26 mostra outro exemplo de agregação entre classes de objetos.
Empresa Trabalha_para Funcionário

0..1 0..*
1
0..*
Divisão
1
0..*
Departamento
Figura 26 – Exemplo de agregação
Uma empresa é uma agregação de suas divisões, que são, por sua vez, agregações de seus
departamentos. Uma empresa não é uma agregação de seus funcionários, uma vez que empresa e
pessoa são objetos distintos e independentes.
58
Uma composição é uma agregação forte em que as partes estão fisicamente contidas dentro do
todo. Os componentes não podem ser compartilhados por outros compostos. Uma exclusão do todo
desencadeia uma exclusão em cascata das partes, portanto, o ciclo de vida das classes em composição
coincidem.
A figura 27 mostra um exemplo de composição.
Livro
1
0..*
Capítulo
Figura 27 – Exemplo de composição (associação forte)
A exclusão de um livro acarreta a exclusão de todos os seus capítulos, e a exclusão dos capítulos do
livro implica a elimincação do livro.
4.6 Generalização/especialização
A generalização é uma forma de se estruturar a visibilidade de um elemento global com uma visão
mais detalhada desse. Isso é feito adicionando características específicas ao elemento na visão detalhada
e aproveitando as características gerais.
generalização
especialização
Figura 28 – Generalização x especialização
A generalização/especialização pode ser usada para diversos outros modelos da UML, como em
diagramas de pacotes e diagramas de casos de uso.
59
Unidade II
As classes superiores são chamadas superclasses, e as inferiores subclasses. Tanto a superclasse como
as subclasses referem-se às características de um único objeto.
Com a generalização, um objeto é simultaneamente instância da superclasse e instância da

subclasse.
Associação de
generalização
Empresa Trabalha_para Funcionário
0..1 0..*
Masculino Feminino
Divisão
Departamento
Figura 29 – Exemplo de generalização
Uma árvore de generalização é composta por classes que descrevem um objeto. No exemplo da figura
19, a classe funcionário foi especializada em masculino e feminimo, devido a características específicas
de cada um, mas o modelo garante que as características comuns estão representadas somente uma
vez na superclasse funcionário.
Diz-se que masculino é um “tipo_de” funcionário ou masculino “é um” funcionário. Um funcionário

ou é masculino ou é feminino.
4.7 Herança
Na UML, herança é um mecanismo por meio do qual uma instância de uma classe assume os atributos
e os comportamentos dos objetos de outra classe (antepassados ou antecedentes).
Os objetos subordinados herdam atributos e serviços da classe superior. A propriedade herança

permite que novas classes sejam construídas pela herança de classes existentes. A figura 30 mostra um
exemplo de herança.
60
Aeronave
Classe ou superclasse
Jato Planador
Subclasse
Figura 30 – Exemplo de aplicação do mecanismo de herança
No exemplo da figura 30, as classes jato e planador são subclasses de aeronave. As classes subordinadas
podem ter atributos e ou métodos próprios. O conceito de herança reforça a extensibilidade característica
que sempre se procurou na programação.
Uma classe descendente/subclasse não pode omitir ou suprimir um atributo da superclasse, senão
não seria uma instância antecessora. As subclasses também são chamadas de classes derivadas ou
classes-filho na hierarquia de classes.
As classes que ficam mais altas na hierarquia são denominadas de superclasses.
Funcionário
Funcionário Funcionário
feminino masculino
nome solteira
registrar licença
maternindade
Figura 31 – Exemplo de herança
Pode acontecer de uma subclasse possuir alguma operação diferente de seu antecessor. Isso
é chamado de extensão. Uma subclasse pode restringir atributos do antecessor. Isso é chamado de
“restrição”, pois restringe os valores que aquela instância pode assumir.
Lembrete
O mecanismo de herança se tornou sinônimo de reutilização de código

no projeto orientado a objetos.
61
Unidade II
A figura 32 mostra um exemplo completo do uso de herança.
Equipamento
nome
fabricante
preço
peso Tanque
Volume
Bomba Tipo de equipamento pressão
pressão de sucção
pressão de descarga
taxa de fluxo Tipo de tanque
Tipo de bomba
Tanque esférico Tanque pressurizado Tanque de teto flutuante

Bomba centrífuga diâmetro diâmetro diâmetro
eixo de rotação altura altura
Bomba de diafragma Bomba de imersão

material do diafragma diâmetro de pistão
número de cilindros
Figura 32 – Exemplo completo do uso de herança
A quadro 3 mostra o conteúdo dos objetos da classe “bomba centrífuga” e da classe “tanque de teto
flutuante” com suas características específicas apesar de serem ambas equipamento.
Diversos atributos e operações são válidos para os dois objetos e possuem atributos e operações
específicos.
Quadro 3 – Conteúdo das classes
Bomba de diafragma Tanque de teto flutuante

Nome = P101 Nome = T111
Fabricante = Simplex Fabricante = Simplex
Peso = 100 kg Peso = 10.000 kg
Preço = R$ 5.000,00 Preço = R$ 50.000,00
Pressão sucção = 1,1 atm Volume = 400.000 l
Pressão de descarga = 3,3 atm Pressão = 1,1 atm
Taxa de fluxo = 300 l/hora Diâmetro = 8 m
Mat. diafragma = teflon Altura = 9 m
62
Herança é um mecanismo da OO que permite criar novas classes a partir de classes já

existentes, aproveitando-se das características existentes na classe a ser extendida.
Este mecanismo é muito interessante, pois promove um grande reuso e reaproveitamento

de código existente. Com a herança é possível criar classes derivadas (subclasses) a partir de
classes bases (superclasses). As subclasses são mais especializadas do que as suas superclasses,
mais genéricas. As subclasses herdam todas as características de suas superclasses, como
suas variáveis e métodos.
Imagine que dentro de uma organização empresarial, o sistema de RH tenha que

trabalhar com os diferentes níveis hierárquicos da empresa, desde o funcionário de baixo
escalão até o seu presidente.
Todos são funcionários da empresa, porém cada um com um cargo diferente. Mesmo
a secretária, o pessoal da limpeza, o diretor e o presidente possuem um número de
identificação, além de salário e outras características em comum. Essas características em
comum podem ser reunidas em um tipo de classe em comum, e cada nível da hierarquia ser
tratado como um novo tipo, mas aproveitando-se dos tipos já criados, a partir da herança.
Os subtipos, além de herdarem todas as características de seus supertipos, também

podem adicionar mais características, seja na forma de variáveis e/ou métodos adicionais,
bem como reescrever métodos já existentes na superclasse (polimorfismo).
A herança permite vários níveis na hierarquia de classes, podendo criar tantos subtipos
quanto necessário, até se chegar no nível de especialização desejado. Podemos tratar
subtipos como se fossem seus supertipos, por exemplo, o sistema de RH pode tratar uma
instância de presidente como se fosse um objeto do tipo funcionário, em determinada
funcionalidade.
Porém, não é possível tratar um supertipo como se fosse um subtipo, a não ser que o
objeto em questão seja realmente do subtipo desejado e a linguagem suporte este tipo de
tratamento, seja por meio de conversão de tipos ou outro mecanismo.
Fonte: <http://www.softechnetwork.com.br/java/CursoOO.pdf>. Acesso em: 15 jun. 2012.
4.8 Conceitos avançados envolvendo classes
4.8.1 Herança múltipla
Herança múltipla é uma extensão da análise orientada a objetos que permite uma classe ter mais de
uma superclasse e herdar todas as características (atributos e operações) de todos os seus pais.
É considerada a mais complicada forma de generalização, e nem todas as linguagens de programação

dão suporte diretamente. A figura 33 mostra um exemplo de herança múltipla.
63
Unidade II
Janela Texto Árvore
Tela
Figura 33 – Herança múltipla
Com a herança múltipla a classe tela herda todas as caracerísticas de suas três classes-pai ou superclasses.
A classe janela possui as propriedades das janelas e as operações para mostrá-las e movimentá-las pela tela.
A classe texto oferece as propriedades textuais das janelas, com operações/métodos para manipular
linhas de texto etc.
A herança múltipla aumenta o potencial de uma linguagem orientada a objetos, mas a um custo na
complexidade da programação, bem como um overhead de compilação e de tempo de execução.
Uma classe com mais de uma superclasse é chamada de classe-de-junção.
Veículo
Terrestre Aquático
Carro Anfíbio Barco
Figura 34 – Classe-de-junção anfíbia
Uma característica proveniente da mesma classe ancestral encontrada em mais de um caminho é

herdada apenas uma vez.
No exemplo da figura 34, a característica “cor” da classe veículo é herdada tanto por veículo terrestre
como por veículo aquático, mas a subclasse veículo anfíbio, que possui herança múltipla, herda a
característica “cor” de apenas uma das suas superclasses.
64
As subclasses provenientes de generalizações podem ou não ser disjuntas. No exemplo da figura 34,
as classes terrestre e aquático não são disjuntas nesse nível, porque elas se sobrepõem, isto é, algum
veículo pode andar na terra e na água.
4.8.2 Classes abstratas
Uma classe abstrata é uma classe que não possui instâncias diretamente, mas cujos descendentes
possuem instâncias diretas. Esse tipo de classe é útil durante um projeto OO, para facilitar a programação
e a manutenção dos sistemas.
Às vezes, é útil criar superclasses abstratas para encapsular classes que participam em uma mesma
associação. Algumas classes abstratas aparecem naturalmente no domínio da aplicação, outras são
artificialmente criadas como um mecanismo para permitir reuso de código.
As classes abstratas são usadas frequentemente para definir métodos para serem abordados por subclasses.
Uma classe abstrata não é uma classe concreta já que não pode ser instanciada diretamente. Para
ser instanciável a classe abstrata deve possuir descendentes concretos.
Já uma classe concreta pode ser uma classe de folhas (último nível da hierarquia). Uma classe abstrata
não pode ser classe de folha já que precisa de descendentes para ser instanciável.
A figura 35 mostra uma hierarquia de classes concretas e dessa forma todas podem ser instanciáveis
diretamente.
Trabalhador
{incompleto}
Pedreiro Cobrador Açougueiro
Figura 35 – hierarquia de classes concretas
A classe trabalhador também pode ser classe concreta, pois algumas ocupações podem estar contidas
nelas. Dessa forma, a hierarquia é {incompleto}.
Todavia, uma classe concreta pode ser refinada em várias subclasses concretas e se tornar abstrata.
Quando isso acontece, a hierarquia passa a ser {completo}.
O exemplo da figura 36 mostra uma superclasse empregado que se tornou abstrata no momento em
que foram criadas diversas subclasses concretas, que herdaram a operação Calcular_Salario( ) e que
serão programadas com lógicas específicas.
65
Unidade II
Trabalhador
{completo}
Horista Mensalista Autônomo

Calcular_Salário () Calcular_Salário( ) Calcular_Salário()
Figura 36 – Exemplo de classe abstrata
Nesse exemplo, a classe empregado não possui instâncias diretas, e a operação Calcular_Salario( )
será implementada por métodos diferentes em cada subclasse. A classe de origem de qualquer estrutura
é a classe definidora de mais alto nível.
Ela define o “protocolo” ou “assinatura” da estrutura (tipo de um atributo, número e tipo de

argumentos e tipo de resultado de uma operação). As classes descendentes podem refinar o protocolo,
restringindo os tipos ou refazendo a inicialização ou a codificação do método, mas não podem ampliar
ou modificar o protocolo.
Por exemplo: se um atributo foi definido na classe de origem, as classes descendentes podem
restringir os valores que aceitam no atributo, mas não podem modificar seu tipo.
O discriminador {completo} indica que qualquer instância da superclasse empregado será uma
instância de um dos seus filhos, e a superclasse se torna abstrata.
Já o discriminador {incompleto} indica que o conjunto pode esperar novas subclasses, e a

superclasse é concreta. Dessa forma, a superclasse pode ser instanciada diretamente.
4.8.3 Polimorfismo (ocultamento de informações)
O polimorfismo implica que uma mesma operação pode comportar-se de maneira diferente em
classes distintas, apesar de possuir o mesmo nome. É a propriedade de se utilizar um mesmo nome para
fazer coisas diferentes.
Observação
Por exemplo: mandar alguém correr. Se a pessoa estiver parada, irá

sair correndo. Se a pessoa estiver no volante de um carro, irá aumentar a
pressão do pé no acelerador.
O polimorfismo é estimulado pelo paradigma da hereditariedade, exclusivo da OO. Dentro do

polimorfismo, pode-se ter a sobreposição, a redefinição (overriding) de método: o método deve ter a
mesma assinatura (nome, argumentos e valor de retorno) e código diferente.
66
Já na sobrecarga (overloading), usa-se o mesmo nome e mais alguma característica para se fazer a
mesma coisa. Dependendo dos argumentos da chamada, será chamado o método adequado.
4.8.4 Interfaces tipos e papéis
A herança múltipla não é permitida em algumas de programação OO diretamente. Para facilitar a

necessidade do uso desse tipo de herança, aparece o uso da interface.
Uma interface, por exemplo, na linguagem Java não é uma classe, é um arquivo que define valores
constantes, e as operações que outra classe deve implementar. Ela não tem operações/métodos, apenas
seus protótipos.
Dessa forma, quando uma classe expõe apenas constantes e operações sem implementação, também
é chamada de interface.
4.8.5 Pacotes lógicos
A UML define um diagrama de pacotes como sendo um modelo que descreve como os elementos são
organizados dentro de pacotes e suas dependências. Um pacote pode estar contido em outros pacotes.
Em um diagrama de pacotes, esses são ligados por setas pontilhadas, que têm seu estereótipo
alterado de acordo com a necessidade.
Um pacote pode ter qualquer diagrama da UML, porém são mais comuns em diagrama de casos
de uso, para ajudar a abstração do domínio do problema, e em classes, para ajudar na organização das
classes construídas em sistemas médios e grandes.
Uma classe também pode ser declarada com “em pacote” e, dessa forma, terá a sua visibilidade
restrita ao pacote em que reside. Classes fora desse pacote não poderão sequer saber de sua existência
e, por isso, não poderá acessar classes do pacote.
Uma classe dentro de um pacote sem visibilidade definida assume a visibilidade padrão do pacote.
Existe uma notação especial na UML para designar um pacote. Essa notação não deixa dúvidas ao
implementador que está usando o diagrama sobre a intenção do uso do pacote.
pktLogin
Figura 37 – Exemplo de um pacote
67
Unidade II
Nesse exemplo, todas as classes referentes ao login estão contidas nesse pacote. O acesso a essas
classes internas vai depender da visibilidade do pacote.
4.8.6 Objetivos do diagrama de classes
1. Mostrar a estrutura estática do sistema.
2. Montar essa estrutura com as classes de objetos e também como seus relacionamentos.
3. Mapear os objetos a partir das classe de objetos com seus nomes, atributos e operações.
4. Aplicar as propriedades e características da tecnologia OO por meio dos mecanismos de associação,

herança, polimorfismo e abstração.
4.9 Estudo de caso aplicando modelo de classes
Para demonstração do uso de um dos mais importantes modelos da UML, será utilizada a descrição
de um sistema de vendas simples, com algumas funcionalidades fundamentais.
Como ferramenta de apoio à preparação do estudo de caso, foi utilizada a ferramenta Case Enterprise
Architect (EA).
Saiba mais
O estudo de caso foi adaptado do exemplo apresentado no livro

Modelagem de Objetos, do autor José Davi Furlan, publicado pela editora
Makron Books (FURLAN, 1998).
4.9.1 Descrição do sistema
O sistema de vendas tem o objetivo de fornecer informações unificadas, abrangentes e atualizadas

aos vendedores, incluindo a situação dos pedidos tirados, a posição de crédito dos clientes, a programação
de apresentação de produtos e a eficiência de vendas.
A força de vendas está estruturada em filiais, zonas e setores. Uma filial atua em uma área geográfica.
Os vendedores das filiais atuam em zonas de vendas e um deles é o responsável pela tal. A estrutura de
visitas aos clientes pelos vendedores é definida por essas zonas de vendas e distribuída aos vendedores.
As visitas ainda são organizadas semanalmente e representam períodos semanais, quinzenais e mensais.
A partir da data e do período de visita, o sistema encarrega-se de gerar automaticamente o roteiro

diário que deve ser seguido pelo vendedor para cumprir sua programação de vendas.
68
4.9.2 Requisitos do sistema
A partir da descrição do sistema existem diversas alternativas de solução. De qualquer maneira, os

requisitos independem de outra solução específica, mais simples ou mais complexa, já que eles mapeiam
as necessidades dos clientes em forma de sentenças.
A figura 38 apresenta o diagrama de requisitos do sistema a ser modelado.
Observação
Os requisitos são organizados em dois grupos ou pacotes. O pacote de

requisitos funcionais e o pacote de requisitos não funcionais:
• O pacote que contém os requisitos funcionais apresentam

as características que representam o comportamento das
funcionalidades ou regras de negócio que o sistema deve apoiar.
• O pacote de requisitos não funcionais contém os requisitos condicionantes

e níveis de desempenho que o sistema deve atender. Por exemplo: tempo
de resposta do sistema, transações de segurança etc.
No nosso estudo, somente serão abordados os requisitos funcionais.
req Modelo de requisitos
Requisitos funcionais
RF01 – O sistema deve manter atualizada a posição do cliente
RF02 – O sistema deve elaborar o roteiro de visita do dia
RF03 – Sistema emite informações adicionais sobre os clientes
RF04 – Gera informações sobre filial
RF05 – Analisa situação financeira do cliente
RF06 – Análise do histórico de vendas
RF07 – Registra pedido de venda
Figura 38 – Requisitos do sistema modelado na ferramenta EA
69
Unidade II
4.9.3 Modelo de classe do sistema
Após uma análise dos requisitos e reuniões com a área de vendas, o analista de sistemas aprova o
modelo de requisitos e detalha as funcionalidades usando o modelo de casos de uso.
A partir dos cenários e das funcionalidades, são descobertas as entidades envolvidas com o problema
e que serão usuárias do sistema, e as entidades de dados que serão modeladas e colocadas no banco de
dados desse.
As principais classes obtidas com essa análise são:
1. filial de venda;
2. zona de venda;
3. setor de venda;
4. cliente;
5. produto;
6. produto em cliente;
7. preço do produto;
8. pedido;
9. item de pedido;
10. nota fiscal;
11. fatura.
A figura 39 apresenta o diagrama de classes proposto para o sistema, contendo os principais atributos.
Esse modelo/diagrama é denominado de modelo de domínio, já que não contém as classes de objetos
da solução tecnológica do sistema, tais como: classes de interface, classes de comunicação, classes de
padrões e classes de banco de dados.
Essas classes completarão o modelo de domínio na fase de design do projeto.
70
class Diagrama de Classes
Cliente
- codigo: int
- nomeCompleto: char
- nomeReduzido: char Pedido
Filial de venda - endereco: char
- IRPJ: char - numero: int
- numero: int - data: date
- nome: char - telefone: char 1 0..*
- horarioDeVisita: int - situacao: int
- CondicaoDePagamento: int - tipoDePedido: int
- dataDaUltimaVisita: date
1 1
*
Zona de venda 1 0..*
0..*
0..*
- numero: int Item de pedido
- nomeDoVendedor: char Nota fiscal
- numero: int
- quantidade: date - numero: int
- precoNegociado: int - dataDeEmissao: date
0..* 0..* - situacao: boolean
- situacao: int
- condicaoDeEntrega: int
* 0..* 0..*
0..*
Setor de venda
- nome: char 0..*
- dataDaUltimaVisita: date Produto em cliente 1 0..*
- periodoDeVisita: date - data: date Produto Fatura
- quantidade: int - codigo: int
- tipo: int - numero: int
- descricao: int - dataDeEmissao: date
- faixaDePreco: int - dataDeVencimento: date
- valorUnitario: int - valor: int
- dataEfetivaPagamento: date
Figura 39 – Diagrama de classes preliminar
Nesse diagrama, temos as principais classes juntamente com seus relacionamentos.
O modelo, nesse momento, ainda não sofreu quaisquer questionamentos conceituais profundos, ou
mesmo foi promovida uma normalização visando à sua estabilidade e integridade.
As operações dessas classes são obtidas a partir do estudo das funcionalidades descritas nos modelos
de caso de uso e diagramas de sequência das transações necessárias, para que o sistema atenda aos
requisitos, que não serão mostrados nesse exemplo, já que se pretende apresentar somente um exemplo
de aplicação do modelo de classes.
A figura 40 apresenta o mesmo diagrama de classes, mas com as principais operações necessárias
para resolver o sistema.
71
Unidade II
class Diagrama de Classes

Cliente
- codigo: int
- nomeCompleto: char
- nomeReduzido: char
- endereco: char
- IRPJ: char Pedido
- telefone: char
- horarioDeVisita: int - numero: int
- CondicaoDePagamento: int 0..* - data: date
Filial de venda - dataDaUltimaVisita: date 1 - situacao: int
- numero: int - tipoDePedido: int
+ obte_Clientes_Ativos() : void
- nome: char + obter_Limite_Credito() : void + obter_Pedido() : void
+ obter_Nome_Filial(): void + obter_Condicao_Entrega : void + incluir_Pedido() : void
+ obter_Condicao_Pagamento() : void
+ obter_dia_Entrega() : void 1 1
* 1
Zona de venda 0..*
0..*
0..*
- numero: int Item de pedido
- nomeDoVendedor: char Nota fiscal
- numero: int
- quantidade: date - numero: int
- precoNegociado: int - dataDeEmissao: date
0..* 0..* - situacao: boolean
- situacao: int
- condicaoDeEntrega: int + obter_NF_Cliente() : void
* 0..*
+ obter_Descricao_Produto() : void 0..*
Setor de venda + obter_Preco_Produto() : void
- nome: char 0..*
- dataDaUltimaVisita: date 0..*
- periodoDeVisita: date 0..* Fatura
1
+ atualizar_Data_Ultima_Visita() : void Produto - numero: int
- dataDeEmissao: date
- codigo: int - dataDeVencimento: date
Produto em cliente - descricao: int - valor: int
- faixaDePreco: int - dataEfetivaPagamento: date
- data: date - valorUnitario: int
- quantidade: int + obter_Faturas_Vencidas() : void
- tipo: int + obter_Descricao_Produto() : void + obter_Faturas_A_Vencer
+ obter_Preco_Produto() : void
+ registrar_Estoque_Cliente() : void
+ registrr_Produto_Recolhodo() : void
Figura 40 – Diagrama/modelo de classes com algumas operações
O modelo de classes, quando completo, incluindo atributos e operações, pode ser implementado em
um banco de dados e em uma linguagem de programação orientada a objetos.
Outras classes serão necessárias, tanto para o banco de dados, como para a implementação em uma
linguagem específica nas próximas fases do desenvolvimento.
Para a fase de design, deverão ser desenvolvidos os modelos de interface homem versus máquina,
que indicará as interações dos usuários com o sistema. Para isso deverão ser montados os modelos de
casos de uso com os atores e as funcionalidades.
72
Por meio do modelo de caso de uso e do protótipo, os diagramas de sequência indicarão as mensagens
que serão trocadas entre os objetos. A partir dessas mensagens, o modelo de classe será aumentado, e
todas as operações ou métodos deverão ser incluídos nas classes específicas.
Resumo
Esta unidade apresentou uma visão da estrutura da UML. Foi discutido

que, de acordo com os autores a UML, não é um modelo de processo/
metodologia de software.
Ela é considerada uma linguagem padrão de modelagem de sistemas e,

por isso, tem uma notação e um mecanismo para “mostrar o problema”, de
forma a expor a essência do domínio de um aplicativo.
Também se detalhou os conceitos envolvidos com todos os diagramas

apresentados na linguagem UML, principalmente o diagrama de classes de
objetos. O detalhamento desse modelo se justifica devido à sua importância
na tecnologia orientada a objetos.
A partir desse modelo de classes detalhado, são derivadas as soluções

de banco de dados e as classes que serão implementadas em linguagens
específicas. O diagrama de classes é a entrada para os processos de
arquitetura e implentação, tanto do banco de dados como do aplicativo.
Uma das mensagens mais importantes é com relação ao reuso de

software. Quando se trabalha com os conceitos envolvidos com o reuso de
software, o modelo de classes é fundamental e apresenta os mecanismos
de herança e polimorfismo que permite um avanço considerável em direção
à reusabilidade.
Exercícios
Questão 1. De acordo com a IBM-Rational, a Unified Modeling Language (UML) é uma linguagem
de modelagem não proprietária adotada pela OMG, e não uma metodologia de desenvolvimento. Ela
não diz como desenvolver ou manter um sistema ou software, mas auxilia a visualizar seu desenho
e a comunicação entre os objetos envolvidos com o sistema. Também permite que desenvolvedores
vejam os produtos de seus trabalhos em diagramas ou gráficos padronizados, oferecendo uma notação
gráfica, especificando os significados, isto é, ela é uma liguagem com uma semântica predefinida. É
uma notação independente de metodologias ou processos, embora muitas delas, como o RUP (Rational
Unified Process), tenham sido especificamente desenvolvidos utilizando a UML. Outro fator importante
é a diferença entre um modelo UML e um diagrama (ou conjunto de diagramas) de UML; um diagrama
ou gráfico é uma representação gráfica da informação de um determinado sistema, e o modelo pode
73
Unidade II
existir independentemente. Considerando-se os conceitos sobre a UML, analise as afirmações a seguir e

assinale a alternativa incorreta:
A) A visão de caso de uso de um sistema descreve as fucionalidades ou o comportamento do sistema

assim como os analistas e programadores de sistemas.
B) De acordo com diversos autores, o diagrama de classes de objetos é o mais importante dos
diagramas da UML, pois uma classe de objetos é uma coleção de objetos que podem ser descritos
com os mesmos atributos e as mesmas operações. Também representam as entidades envolvidas
em um sistema de informação.
C) Para que um sistema seja executado, as classes de objetos precisam estar relacionadas ou
associadas no modelo de classes. Esse relacionamento ou associação deve estar de acordo com
as necessidades do sistema e deve cobrir as regras de negócio envolvidas com as funcionalidades
que o sistema executará.
D) Sistema é a representação abstrata do mundo real; quanto mais complexo, mais necessita de
descrições de seus vários aspectos. Ele deve mostrar: a estrutura estática dos objetos e a interação
dinâmica entre eles; as características do tipo de tempo de processamento, de confiabilidade, de
usabilidade etc.; e, por último, o mapeamento do modelo organizacional em termos da organização
do trabalho, mapeamento e os códigos.
E) Herança é o mecanismo de reutilização de atributos e operações definidos em superclasses por

classes mais específicas, podendo ser usada para expressar tanto generalização como associação.
Resposta: Alternativa A.
De acordo com a OMG, a UML apresenta 4 grandes objetivos: especificação de um sistema,

documentação de todos os artefatos produzidos no processo, estruturação para subvisualização
e maior visão lógica do desenvolvimento completo de um sistema de informação. A UML é uma
linguagem padronizada de se modelar sistemas de informação desenvolvidos na tecnologia da
Orientação a Objetos.
A) Incorreta. A visão de caso de uso de um sistema realmente descreve as funcionalidades ou o

comportamento de um sistema, mas tem como princípio fundamental entender os requisitos do
sistema e interpretá-los graficamente. Outro fator fundamental é que os Casos de Uso são como
uma linguagem de comunicação entre os usuários e os desenvolvedores de um determinado
sistema.
B) Correta. Uma classe de objetos representa uma ideia ou um conceito simples e categoriza objetos
que possuem propriedades similares, configurando-se em um modelo para a criação de novas
instâncias. Exemplo: uma classe que represente um Cliente pode ser instanciada para representar
74
um cliente pessoa física ou um cliente pessoa jurídica, os quais possuem características semelhantes
e específicas.
C) Correta. Esses relacionamentos ou associações definem as regras que são impostas pelas regras de
negócio da aplicação sendo modelada.
D) Correta. Cada visão apresentada em um diagrama da UML é descrita por um ou mais diagramas,
que contêm informações referentes a um aspecto específico do sistema sendo modelado.
E) Correta. Quando se usa o paradigma da herança na OO, uma classe de menor nível (subclasse)
é considerada uma classe especializada ou uma classe de extensão da classe de maior nível
(superclasse).
Questão 2. Dentro da UML, o diagrama de classe de objetos tem por objetivo descrever um grupo
de objetos com propriedades similares, relacionamentos comuns com outros objetos e uma semântica
comum. As propriedades são: os atributos e as operações. Estas são encapsuladas no objeto. Exemplo:
em um sistema ERP, o cliente e o fornecedor são classes de objetos. Cada cliente tem um nome e
um endereço; estes seriam os atributos comuns da classe cliente. Fornecedores também podem ter os
mesmos atributos, nomes e endereços definidos. Entretanto, elas podem não estar definidas em uma
mesma estrutura de objetos devido à distinção semântica. Como se pode observar, o agrupamento em
classes não leva em conta apenas o compartilhamento de propriedades, senão essas classes deveriam
ser sempre agrupadas na mesma estrutura. Considerando-se os conceitos apresentados sobre a UML
nesta unidade, examine as afirmações a seguir e assinale a alternativa incorreta:
A) Com a hierarquia de classes de objetos que são apresentadas no diagrama de classes e com o
mecanismo de herança, o modelo de classes de objetos potencializa o reuso no desenvolvimento
de software OO.
B) Para se ter herança múltipla em um modelo de classes, necessita-se que uma subclasse herde
atributos e operações de mais de uma superclasse.
C) Quando um modelo de classes apresenta herança múltipla e vai ser implementado em uma
linguagem de programação OO e em banco de dados, pode-se ter problemas na transição, devido
a que esses ambientes podem não suportar a herança múltipla.
D) O uso de herança múltipla deve ser evitado a todo custo nos projetos de sistema OO, haja visto ele
nunca aparecer na modelagem do mundo real.
E) Uma classe abstrata possui a mesma estrutura de uma classe concreta, a única diferença é que
tem um modificador abstract em sua definição de atributo ou de operação. Ela não pode ser
instanciada, ou seja, não é possível obter objetos. Classes abstratas podem ser herdadas por outras
classes abstratas ou concretas, e isso possibilita o polimorfismo.
Resolução desta questão na plataforma.

75
UNIDADE II
Questão 2
Resposta correta: alternativa D.
Justificativa: todo objeto sabe a que classe ele pertence, ou seja, a classe de um
objeto é um atributo implícito do objeto. Este conceito é suportado na maior parte das
linguagens de programação orientada a objetos, como C ++, ADA etc.
A) Correta. Como várias subclasses podem herdar as propriedades de uma

superclasse, os mesmos atributos e operações são reutilizados nas subclasses,
levando ao reúso de software.
B) Correta. A herança múltipla permite que uma subclasse herde propriedades de

várias superclasses. Exemplo: carro e barco são objetos que possuem características
semelhantes, mas diferentes comportamentos. Todavia, um anfíbio pode se
comportar como um carro quando em terra e como um barco quando está na água.
Então, esse animal pode herdar tanto propriedades e comportamentos de carro como
do barco.
C) Correta. Exemplo: na linguagem de programação Java, não temos a

implementação da herança múltipla, e isso dificulta a transição do modelo de classes
para o código na linguagem Java.
D) Incorreta. O uso de herança múltipla, apesar de não ser comum nos modelos
de sistemas OO, aparece na modelagem do mundo real, porém raramente é
implementada em linguagens de programação.
E) Correta. As classes abstratas são permissões das linguagens orientadas a

objeto que permitem definir classes com a mesma estrutura de classes concretas.
Podem ser herdadas por subclasses que programam as operações com a mesma
assinatura herdada, mas com códigos específicos, por meio do mecanismo do
polimorfismo.
Unidade III
Unidade III
5 MODELAGEM COMPORTAMENTAL (MODELO DINÂMICO)
5.1 Introdução
Na abordagem de análise da UML, a visão de modelo comportamental representa o sistema do ponto

de vista dos comportamentos e interações do sistema com o usuário. Os diagramas que modelam o
comportamento de um sistema da UML são:
• diagrama de caso de uso (use case): é um diagrama de uso geral para as fases de levantamento e
análise de requisitos do sistema;
• o diagrama de estados ou máquina de estados: que procura acompanhar as mudanças sofridas

por um objeto dentro de um processo no tempo;
• o diagrama de atividades: que descreve os passos a serem percorridos para a conclusão de uma atividade.
• os diagramas de interação: que são dividios em:
— diagrama de sequência: diagrama que descreve a ordem temporal em que as mensagens são
trocadas entre os objetos;
— diagrama geral interação: é uma variação dos diagramas de atividades que fornece visão geral
dentro do sistema ou processo do negócio;
— diagrama de comunicação: associado ao diagrama de sequência, complementando-o e

concentrando-se em como os objetos estão vinculados.
— diagrama de tempo: diagrama que descreve a mudança de estado ou condição de uma instância
de uma classe, ou seu papel durante o tempo.
Esta unidade abordará os principais diagramas comportamentais da UML.
Lembrete
A UML propõe 13 diagramas que cobrem as estruturas estáticas e os

comportamentos de um aplicativo ou sistema de software. Nesta unidade,
somente serão abordados os diagramas denominados comportamentais.
76
5.2 Modelo de casos de uso
O caso de uso nos modelos da UML é um elemento que descreve como um usuário do sistema
proposto interage com o sistema para realizar uma determinada tarefa discreta.
Ele descreve e significa uma interação simples, a todo o tempo, que tenha significado para o usuário
(uma pessoa, uma máquina ou outro sistema).
Um caso de uso, de acordo com a UML:
• tipicamente, tem requisitos e restrições que descrevem as facilidades e regras sobre as quais ele
opera;
• pode ter um diagrama associado (diagrama de sequência ou de atividades) que ilustre seus
comportamentos ao longo do tempo: quem faz o quê, para quem e quando.
• tipicamente, tem cenários associados com ele e que descrevem o fluxo de trabalho durante todo
o tempo que realiza suas tarefas, até produzir os resultados finais.
• a especificação da OMG UML afirma: “um caso de uso é um tipo de classificador de comportamento
que representa uma declaração de um comportamento oferecido”.1
Cada caso de uso especifica alguns comportamentos, possivelmente incluindo variantes, as quais
pode executar em colaboração com um ou mais atores.
Lembrete
Os elementos de casos de uso são utilizados para construir modelos de

caso de uso. Eles descrevem a funcionalidade do sistema a ser construído,
os requisitos, as restrições e como o usuário interage com o sistema.
Muitas vezes, os diagramas de sequência são associados com casos de uso para capturar o fluxo de
trabalho e o comportamento do sistema.
5.2.1 Diagramas de caso de uso
O diagrama ou modelo de casos de uso mostra o que existe fora do sistema (atores) e o que pode ou
deve ser executado pelo sistema (casos de uso).
Os casos de uso são importantes, pois provêm uma ferramenta para capturar os requisitos do sistema,
ou seja, o que o sistema necessita disponibilizar para possibilitar a execução das atividades do negócio.
1
UML Superestrutura Especificação, versão 2.1.1, p. 592.
77
Unidade III
O conjunto de casos de uso do sistema representa a funcionalidade desse, isto é, a totalidade de

maneiras de se utilizar o sistema.
Um diagrama de caso de uso é um gráfico de:
• atores;
• conjunto de casos de uso do sistema, encapsulados pela fronteira desse;
• a associação entre os atores e os casos de uso utilizados por eles; e
• os eventuais relacionamentos entre os próprios casos de uso.
A figura 41 mostra um exemplo de um diagrama típico de casos de uso.
uc Use Case Model
Faz login
Usuário <<extend>>
Registra
Usuário
Figura 41 – Diagrama ou modelo de casos de uso
5.2.1.1 Atores
Os atores representam toda a necessidade de troca de informação com o sistema. Eles constituem,
portanto, o ambiente do sistema (seres humanos, máquinas, agrupamentos lógicos, outros sistemas).
A diferença entre atores e usuários é que um ator representa certa regra que um usuário pode utilizar
na interação com o sistema, e o usuário é a pessoa que está usando aquela regra, naquele momento.
Dentro da tecnologia OO, o ator é uma classe, enquanto o usuário é uma instância daquela classe.
A instância existe apenas enquanto o usuário está fazendo algo no sistema, portanto, o mesmo usuário
pode ser instância de vários atores no sistema.
78
A figura 42 mostra a notação de Ator na UML.
Cliente
Figura 42 – Notação de ator
O ícone padrão do estereótipo do ator é a figura do stick man. O nome do ator deve ser sempre um
substantivo no singular, por exemplo: cliente, professor, operador etc.
Observação
A especificação da OMG UML2 afirma:
Um ator modela um tipo de papel desempenhado por uma entidade

que interage com o sistema (por exemplo, intercâmbio de dados e sinais),
mas que é externo ao sistema.
Atores podem representar papéis desempenhados por usuários humanos, de hardware externo ou
de outros sistemas.
Note que um ator não representa, necessariamente, uma entidade física específica, mas apenas uma
faceta particular (isto é, “papel”) de alguma entidade que é relevante para a especificação de seus casos
de uso associados.
Saiba mais
Vale a pena fazer download do manual da OMG Unified Modeling

Language (OMG UML), o Infrastruture versão 2.3, que se encontra gratuitamente
disponível em: <http://www.omg.org/spec/UML/2.3/Infrastructure>, e possui
todas as definições e características dos modelos da UML.
Assim, uma única instância física pode desempenhar o papel de vários atores diferentes e,
inversamente, um determinado ator pode ser jogador de várias instâncias diferentes.
5.2.2.2 Casos de uso
Uma instância de um ator desencadeia a execução de um caso de uso no sistema. Na UML, um caso
de uso é representado por uma elipse com seu nome em texto dentro.
2
79
Unidade III
A figura 43 mostra um exemplo da notação de caso de uso na UML.
Receber
Pagamento
Figura 43 – Notação de caso de uso
Um caso de uso é, portanto, um conjunto de transações, executadas em uma determinada sequência,

em diálogo com o sistema.
Além disso, um caso de uso pode ser visto como uma classe de objetos, devido ao fato de possuir
propriedades e comportamentos. Quando se inicia um caso de uso, se está instanciando a classe: caso de uso.
Cada instância dessa classe é chamada de cenário. Cada cenário retrata a sequência de interações
entre atores (estímulos e respostas) e classes do sistema (consultas e atualizações), com todas as
alternativas de decisão (e respectivas ações) definidas.
Um cenário (instância de caso de uso) pode ser desencadeado:
• por meio de um evento externo (estimulado por um usuário – instância de um ator); ou
• por um evento temporal (o sistema toma a iniciativa a partir de um algoritmo interno – tempo
transcorrido, mudança de estado etc.)
Para se representar os cenários de um caso de uso, podem ser utilizados outros diagramas da UML, tais
como, os diagramas de interação: diagrama de atividades, diagrama de sequência ou de comunicação.
O nome do caso de uso deve ser sempre composto de um verbo e um objeto direto. O verbo pode
estar no infinitivo ou na terceira pessoa do singular. O importante é manter um padrão que todos sigam
na empresa, por exemplo: emitir recibo ou emite recibo.
Observação
O diagrama de casos de uso exerce um papel importante na análise

de sistemas no momento de se entender e especificar as necessidades do
cliente ou usuário, já que:
• é o principal diagrama para ser usado no diálogo com o usuário na

descoberta e validação de requisitos;
• o diagrama pode ser construído a partir do protótipo do sistema, pois

mostra os usuários (atores) interagindo com o sistema, de acordo
com as telas, páginas ou relatórios apresentados no protótipo;
80
• os casos de uso constituem elementos que estruturam todas as

etapas do processo de software.
5.2.1.3 Para identificar casos de uso
A partir do levantamento das necessidades do cliente ou de um usuário, a identificação dos casos de

uso devem seguir um roteiro, conforme o sugerido a seguir:
• O que cada ator necessita ou deve ser capaz de fazer com ou para o sistema. Um ator pode
armazenar, eliminar, alterar ou ler informações.
• Que tarefas devem ser executadas para suprir deficiências da atual implementação do
sistema.
• Quais tarefas executar que a implementação atual não supre (novas funcionalidades).
5.2.1.4 Casos de uso empregados por mais de um ator
Quando vários atores do mesmo tipo utilizam o mesmo caso de uso, é possível identificar um ator
abstrato e tornar os outros atores do mesmo tipo que o utilizam herdeiros dele. Ou ainda, eleger um ator
como usuário do caso de uso e tornar os demais atores seus herdeiros.
5.2.1.5 Casos de uso utilizados por outros casos de uso
Um relacionamento de extensão (extend) de um caso “B” (caso estendido) para um caso “A” (caso
básico) indica que instâncias específicas de “A” podem incluir “B”.
Portanto, um caso de uso de extensão é normalmente criado para mostrar comportamentos

especiais e de exceção, que complementam o caso básico, quando aquelas condições
excepcionais ocorrerem.
A figura 44 mostra um caso de uso com extensão.
uc Use Case Model
A B
<<extend>>
Figura 44 – O uso da extensão
No exemplo da figura 45, somente nas instâncias do caso de uso receber pagamento em que o prazo
estiver vencido é que o caso calcular juros de mora será utilizado como extensão.
81
Unidade III
uc Use Case Model
Receber Calcular juros

pagamento <<extend>> de mora
Figura 45 – Uso de extend (extensão)
Um relacionamento de inclusão (include) de um caso A para um caso B indica que uma instância
do caso A incluirá, também, as instâncias do caso B. Nesse caso, o caso de uso B sempre será acionado
quando o caso de uso A estiver ativo. A figura 46 mostra esse caso.
uc Use Case Model
A B
<<include>>
Figura 46 – Uso do include
A figura 47 mostra um exemplo de include. Nesse caso, sempre que o caso de uso receber pagamento
for ativado, o caso de uso emitir recibo também será acionado.
uc Use Case Model
Receber Emitir
pagamento <<include>> recibo
Figura 47 – Uso do include (inclusão)
Para todas as instâncias do caso de uso receber pagamento, será usado o caso de uso emitir recibo.
O caso de uso emitir recibo poderá ser usado também por outros casos de uso.
Tanto o relacionamento de extensão (extend) como de inclusão (include) são provenientes de

fatoração de casos de uso maiores, sendo que:
• extensão normalmente descreve variações de um comportamento normal, e
• inclusão revela comportamentos utilizados por mais que um caso de uso (reuso de caso de uso).
5.2.1.6 Especificação do modelo de caso de uso
A UML não específica um formato rigído para os cabeçalhos e a estrutura de um caso de uso. Eles
podem ser alterados de acordo com as necessidades de documentação dos sistemas.
82
O quadro 4 a seguir mostra um exemplo de especificação de um caso de uso de alto nível.
Quadro 4 – Descrição de um caso de uso de alto nível
Caso de uso Comprar Itens

Atores envolvidos Cliente e operador
Tipo Primário
Um cliente chega ao caixa com itens para
Descrição comprar. O operador registra os itens e coleta o
pagamento. Ao final, o cliente sai com os itens.
O quadro 5 mostra um exemplo de um caso de uso extendido (detalhado).
Quadro 5 – Caso de uso extendido
Caso de uso Comprar itens com dinheiro

Atores envolvidos Cliente e operador
Propósito Capturar uma venda e seu pagamento em dinheiro.
Um cliente chega ao caixa com itens para comprar.
Descrição O operador registra os itens e coleta um pagamento
com dinheiro. Ao final, o cliente sai com os itens.
Tipo Primário e essencial .
Referência Requisitos funcionais: R1, R2, R3 (requisitos).
O quadro 6 mostra a sequência de eventos do exemplo do quadro 5. Ações dos atores e do sistema
durante a ocorrência de compra.
Quadro 6 – Sequência de eventos em uma compra de cliente
Ação do ator Resposta do sistema

1. Este caso de uso começa quando um cliente chega ao
caixa com itens para comprar.
2. O operador registra o identificador de cada item. 3. Determina o preço do item e adiciona
informação sobre o item à transação de venda em
Se há mais de um do mesmo item, o operador também andamento. Mostra a descrição e o preço do item
pode informar a quantidade. corrente.
4. Após processar o último item, o operador indica ao 5. Calcula e mostra o valor total da venda.
sistema.
6. O operador informa o total ao cliente.
7. O cliente entrega um pagamento em dinheiro,
possivelmente maior do que o valor total.
9. Mostra o troco devido.
8. O operador registra o valor recebido em dinheiro.
Emite um recibo.
10. O operador deposita o dinheiro e retira o troco devido.
11. Registra a venda no log de vendas completadas.
O operador entrega o troco e o recibo ao cliente.
12. O cliente sai com os itens comprados.
83
Unidade III
Essa sequência de eventos ainda pode comportar os eventos de excessão ou sequência de erros.
Essas sequências devem ser colocadas como caminhos alternativos e podem merecer que novos casos
de uso possam ser definidos para comportá-las.
Saiba mais
O autor Martin Fowler escreveu com Kendall Scott um livro denominado

UML Distilled, que resume a UML e discute todos os modelos ou diagramas
envolvidos com a linguagem. O livro se encontra na sua 3ª edição. Ele foi
traduzido para o português pela editora Bookman em 2004, e se chama
UML Essencial – Um breve guia para a linguagem padrão de modelagem
de Objetos.
O livro “UML Essencial’ descreve a maioria dos tipos de diagramas

UML, sua utilização e a notação básica envolvida na criação. Esses
diagramas incluem classes, sequência, objeto, pacote, instalação,
casos de uso, máquina de estados, atividades, comunicação, estruturas
compostas, componentes, visão geral da interação e diagramas de
temporização.
Os exemplos são claros e as explicações chegam ao fundamento lógico

de projeto de software orientado a objetos.
5.2.1.7 Estudo de caso com o modelo de caso de uso
Para demonstração da aplicação do modelo de caso de uso da UML, será utilizada a descrição de um
sistema de vendas simples com algumas funcionalidades fundamentais (mesmo exemplo utilizado na
unidade 2, como exemplo do uso do diagrama de classes).
Como ferramenta de apoio à preparação do estudo de caso, foi utilizada a ferramenta Case Enterprise
Architect (EA).
Saiba mais
O estudo de caso foi adaptado do exemplo apresentado no livro

Modelagem de objetos, do autor José Davi Furlan, publicado pela Makron
Books (FURLAN, 1998). Foi um dos autores brasileiros pioneiros na divulgação
da UML no Brasil.
84
Ferramentas Case:
O termo Case (Computer-Aided Software Engineering) signfica Engenharia de software auxiliada

por computador.
Antigamente, os engenheiros de software desenvolviam software para outras áreas, tais como,
Engenharia, Arquitetura, Medicina etc., mas não se utilizavam de software para fazer seu trabalho,
confirmando o velho ditado “casa de ferreiro, espeto de pau”.
Com a necessidade de aumentar a produtividade e melhorar a qualidade, foram obrigados a

desenvolver também software para uso próprio.
Inicialmente, era utilizado o termo Workbench, que significa “bancada de trabalho” e que designava
as ferramentas, geralmente automatizadas, que auxiliavam no trabalho dos desenvolvedores de software.
Mais tarde, surgiu o termo Case. Uma ferramenta Case é qualquer software que auxilia as pessoas
que trabalham em um ambiente de desenvolvimento de software.
A presença de ferramentas Case é vital hoje em dia para o bom funcionamento desse ambiente, e elas
existem apoiando todo o ciclo de desenvolvimento (análise, projeto, implementação, teste e manutenção).
Há também ferramentas Case para apoiar a gerência dos projetos de desenvolvimento, a gerência de
configuração e a gerência de riscos.
Sem ferramentas, uma metodologia ou método não terá boa aceitação no mercado devido ao
aumento de trabalho que provoca no ambiente.
Isto ocorreu com diagramas, como o DFD e o E-R, que só foram amplamente utilizados quando
surgiram as primeiras ferramentas para auxiliar na tarefa de diagramação.
Hoje em dia, há também a difusão do termo I-Case, que é usado para caracterizar um grupo de
ferramentas Case integradas, isto é, que se relacionam entre si (entradas e saídas) e que permitem
controlar a consistência dos dados quando uma metodologia é seguida.
Vantagens das ferramentas Case:
• Maior qualidade dos produtos finais: as ferramentas Case diminuem a probabilidade de erros, uma
vez que podem ajudar no controle de consistência dos dados em um ambiente de desenvolvimento
de software; também proporcionam maior eficácia dos produtos, ao auxiliarem as fases de análise
e teste do produto pelo usuário.
• Produtividade: ao ajudar na realização de tarefas e até mesmo ao realizar algumas

automaticamente, as ferramentas contribuem para uma maior agilidade no desenvolvimento
de software, isto é, mais produtos em menos tempo.
85
Unidade III
• Eliminação de trabalho monótono: as ferramentas Case podem realizar algumas tarefas cansativas
para os desenvolvedores, tais como, procurar informações e desenhar símbolos de um diagrama,
as quais são mais suscetíveis ao erro.
• Mais tempo para a tomada de decisão: em consequência das ferramentas realizarem certas
atividades pelas pessoas, essas ficam liberadas para outras tarefas, geralmente mais nobres, que
exigem tomada de decisão e criatividade, ao invés de tarefas repetitivas.
• Flexibilidade para mudanças: as ferramentas permitem que sejam mudados dados e diagramas de
maneira mais rápida e fácil, o que ajuda o desenvolvedor no trabalho de atender às necessidades
do usuário.
• Menos programação: as ferramentas eliminam muito do trabalho de programação, deixando mais

tempo para que a equipe técnica se preocupe com a análise do sistema, que é onde se define
como solucionar o problema do usuário.
• Melhor documentação: por armazenarem dados e diagramas, as ferramentas também contribuem

para uma melhor documentação do sistema, agilizando relatórios, busca de informações e
alterações.
• Manutenção mais fácil e ágil: por consequência do item anterior, é possível ter mais informações
sobre o software na hora de realizar sua manutenção (correção, atualização ou expansão).
5.2.1.8 Descrição do sistema – exemplo de uso do modelo de caso de uso
O sistema de vendas tem o objetivo de fornecer informações unificadas, abrangentes e atualizadas

aos vendedores, incluindo a situação dos pedidos tirados, posição de crédito dos clientes, a programação
de apresentação de produtos e a eficiência de vendas.
A força de vendas está estruturada em filiais, zonas e setores. Uma filial atua em uma área geográfica.
Os vendedores das filiais atuam em zonas de vendas, e um deles é o responsável pela zona de vendas.
A estrutura de visitas aos clientes pelos vendedores é definida por zona de vendas e distribuída aos
vendedores. As visitas ainda são organizadas semanalmente e representam períodos semanais, quinzenais
e mensais.
A partir da data e do período de visita, o sistema encarrega-se de gerar automaticamente o roteiro

diário que deve ser seguido pelo vendedor para cumprir sua programação de vendas.
5.2.1.8.1 Requisitos do sistema
A partir da descrição do sistema, existem diversas alternativas de solução. De qualquer maneira, os

requisitos independem de outra solução específica, mais simples ou mais complexa, já que eles mapeiam
as necessidades dos clientes em forma de sentenças.
86
A figura 48 apresenta o diagrama de requisitos do sistema a ser modelado.
Os requisitos são organizados em dois grupos ou pacotes. O pacote de requisitos funcionais e o

pacote de requisitos não funcionais:
• O pacote que contém os requisitos funcionais apresenta as características que representam o

comportamento das funcionalidades ou regras de negócio que o sistema deve apoiar.
• O pacote de requisitos não funcionais contém os requisitos condicionantes e níveis de desempenho

que o sistema deve atender. Por exemplo: tempo de resposta do sistema, transações de segurança
etc.
No nosso estudo, somente serão abordados os requisitos funcionais. Ler foneticamente.
req Modelo de requisitos
Requisitos funcionais
RF01 – O sistema deve manter atualizada a posição do cliente
RF02 – O sistema deve elaborar o roteiro de visita do dia
RF03 – Sistema emite informações adicionais sobre os clientes
RF04 – Gera informações sobre filial
RF05 – Analisa situação financeira do cliente
RF06 – Análise do histórico de vendas
RF07 – Registra pedido de venda
Figura 48 – Requisitos do sistema modelado na ferramenta EA
5.2.1.7.2 Modelo de caso de uso do sistema
O primeiro passo para modelar o sistema é a partir dos requisitos apresentados na figura 48, que
definem os casos de uso que descrevem o que o sistema de suporte a vendas irá oferecer em termos de
funcionalidades.
Os atores envolvidos são pessoas, o vendedor e o comprador. O vendedor interage com o sistema no
sentido de obter e registrar o pedido do comprador. O comprador recebe uma série de informações do
sistema, mas não interage com o sistema diretamente para entrada de dados ou para consultas online.
87
Unidade III
A figura 49 apresenta uma possível visão de solução para o sistema. O diagrama ou modelo de caso
de uso não mostra as soluções de arquitetura do sistema, mostra apenas os atores interagindo com as
funcionalidades dele.
uc Modelo de Caso de Uso
Mostra
detalhes do
cliente
<<extend>>
Manter
cliente
Informa
Elabora o visita
roteiro de <<include>>
visita
Coloca Cliente
Vendedor pedido
<<include>>
Manter filial <<include>>
Analisa
Analisa situação
histórico de financeira
Gera vendas
informações
sobre filial
Figura 49 – Modelo de caso de uso do estudo de caso
5.2.1.8.3 Especificações do modelo de caso de uso
Inicialmente, deve-se descrever os atores envolvidos com o sistema e suas interações.
Ator vendedor:
• O vendedor, com base na zona e setor de vendas da filial, solicita a elaboração do roteiro de visita
a clientes do dia.
• O vendedor, a partir do roteiro de visitas, programa seu deslocamento a clientes.
• O sistema deverá estar preparado para informar o vendedor sobre a localização dos logradouros e
as principais alternativas viárias de acesso ao cliente.
• O sistema deve estar preparado para fornecer informações adicionais sobre os clientes para apoiar
o vendedor na venda.
• O vendedor acessa o sistema para obter dados gerais sobre a filial.

88
• O vendedor analisa e discute com o cliente a situação da fatura com o cliente, tanto as faturas
vencidas, como as faturas a vencer nos próximos períodos.
• O sistema permite que o vendedor analise a média de vendas por produto nos últimos meses, por
meio do histórico de vendas ao cliente.
• Após a formalização do pedido de venda, o vendedor faz as últimas anotações sobre a visita ao
cliente.
Ator cliente:
• O ator cliente ou comprador recebe, do sistema, dados sobre seu cadastro e um aviso da visita do
vendedor com data e hora prevista. Ele também recebe uma cópia do pedido depois de dada a
entrada pelo vendedor.
• Após as descrições dos atores e de suas interações com o sistema, o desenvolvedor deverá descrever
os casos de uso, usando padrão definido pela organização em que trabalha.
• Será mostrada, como exemplo, a descrição do caso de uso manter filial, que é de responsabilidade
do vendedor. A ferramenta Case utilizada é o EA.
• Descrição geral:
— A força de vendas está estruturada em filiais, zonas e setores. Uma filial atua em uma área
geográfica. Os vendedores das filiais atuam em zonas de vendas e um deles é o responsável
pela zona de vendas.
• Pré-condições: vendedor autorizado no sistema.
• Pós-condições: filial liberada para uso.
• Caminho básico:
— Nome: inclui filial.
— Descrição (passos):
1. Vendedor responsável entra com dados da Filial.
2. Sistema valida filial.
3. Vendedor responsável entra com dados da zona de venda.
4. Sistema valida zona de venda.

89
Unidade III
5. Sistema associa zona de venda à filial.
6. Vendedor responsável entra com dados do setor de vendas.
7. Sistema valida setor de vendas.
8. Vendedor responsável associa setor de vendas à zona de venda.
9. Vendedor responsável associa outros vendedores à zona de vendas.
• Caminho alternativo:
— Nome: altera filial.
1. Vendedor responsável entra com filial.
2. Sistema valida filial.
3. Vendedor altera dados da filial.
4. Sistema altera dados da filial.
5. Vendedor responsável entra com dados da zona de venda/ setor de vendas a serem alterados.
6. Sistema valida zona de venda/setor de vendas.
7. Sistema altera dados da zona ou setor de vendas.
8. Vendedor associa/disassocia zona de venda a filial.
9. Sistema altera dados no banco de dados.
— Nome: exclui filial.
1. Vendedor responsável entra com filial/zona de venda ou setor de vendas que quer
excluir.
2. Sistema valida filial/zona e setor de vendas.

90
3. Sistema verifica se existe cliente com pedido pendente.
4. Sistema exclui vendedores da lista da filial.
5. Sistema elimina filial/zona ou setor de vendas.
— Nome: erros.
1. Filial/zona ou setor de vendas inválido.
2. Filial/zona ou setor de vendas já existe.
3. Filial/zona ou setor de vendas não existe.
4. Não é possível eliminar filial/zona ou setor de vendas.
6 Outros modelos comportamentais da UML
6.1 Introdução
A UML apresenta diversos tipos de diagramas que modelam o comportamento de um sistema. Entre
os diversos diagramas ou modelos comportamentais, o diagrama de caso de uso é considerado o mais
importante deles e tem como finalidade modelar as necessidades ou requisitos de um cliente ou usuário
de um sistema.
Todavia, outras necessidades de representar a realidade surgem quando os analistas de sistemas estão
desenvolvendo ou especificando todas as abordagens necessárias para um entendimento completo do
sistema que está sendo construído.
Para dar apoio aos desenvolvedores com relação ao comportamento do sistema perante uma
determinada realidade ou situação, a UML propõe diversas alternativas de modelos que devem
ser utilizados de acordo com as características do sistema ou do tipo de aplicação necessária para
automatizar um determinado processo de negócio.
Os modelos comportamentais, além do modelo de caso de uso, são: diagrama de atividades, diagrama
de estados ou máquina de estados. Outro diagrama importante abordado nesta unidade é o diagrama
de sequência, sendo que os diagramas de comunicação e de tempo não serão detalhados por não serem
os mais utilizados na prática da UML.
91
Unidade III
6.2 Diagrama de atividades
Um diagrama de atividade é um fluxo que representa as passagens de uma atividade para outra
durante um fluxo de trabalho. Seu propósito é estudar os fluxos dirigidos por processamento interno,
descrevendo as atividades em uma operação.
Esse diagrama tem sido usado para desenhar as lógicas dos cenários dos casos de uso, ou a lógica de
processamento de uma operação de uma classe de objetos mais complexa.
A notação de um diagrama de atividades da UML usa os seguintes símbolos:
Quadro 7 – Símbolos do diagrama de atividade
Símbolos Breve descrição
Representa uma atividade realizada por um usuário ou

Atividade pelo sistema.
Representa a passagem de uma atividade para outra.

Esta passagem também é chamada de gatilho (trigger).
É também chamado de fluxo de controle.
Símbolo de decisão.
Podem-se apontar diversas entradas ou saídas para esse
símbolo de decisão.
Pode indicar que uma atividade chegou neste ponto e
foi subdividida em mais de uma atividade (fork).
Caso diversas atividades chegem neste ponto e saiam
para uma única atividade. O símbolo chama-se Join.
Símbolo de início ou entrada em um fluxo de
atividades.
Pode haver vários pontos de entrada para um processo.
Símbolo de saída de um processo.
Pode haver diversos pontos de saída para um processo.
Fluxo final.
O X dentro do símbolo indica o final de um fluxo que
não seja uma saída normal do processo.
act Use Case Model Swimlanes: este símbolo reproduz as raias de uma
piscina.
Indica o confinamento de um conjunto de atividades
em uma determinada área da empresa.
É usada para organizar logicamente uma atividade.
A figura 50 mostra um exemplo da aplicação do diagrama de atividade.
92
Avaliar item
em estoque
Registrar
pedido
Autorizar forma
de pagamento OK?
Cancelar Aceitar
pedido pedido
Figura 50 – Exemplo de diagrama de atividade
6.3 Diagrama de sequência
O diagrama de sequência mostra os objetos e as mensagens sendo trocadas entre eles, necessárias
para a execução de uma determinada tarefa, evidenciando a ordem em que as coisas acontecem, sem
mostrar as associações entre os objetos.
Um diagrama de sequência é uma representação estruturada de comportamento com uma série

de etapas sequenciais ao longo do tempo. Ele é usado para descrever o fluxo de trabalho, passagem de
mensagens e mostrar como elementos em geral cooperam no tempo para alcançar um resultado.
Esse diagrama pode ser usado para mostrar a evolução de uma dada situação em um determinado
momento do software, mostrar uma dada colaboração entre duas ou mais classes e pode, também, ser
usado para mostrar a tradução de um caso de uso, desde a interação com o usuário até a finalização
daquele dado processo (MEDEIROS, 2004).
Os objetos são mostrados na parte superior do gráfico e, para cada objeto, é desenhada uma linha
vertical, que representa sua linha de vida.
As mensagens são representadas por setas horizontais que ligam os objetos por meio de suas linhas
de vida, a ponta da seta aponta para o objeto alvo.
O eixo vertical normalmente aponta para baixo, indicando que as mensagens vão ocorrendo de cima
para baixo na sequência de eventos.
Cada elemento da sequência é organizado em uma sequência horizontal, com mensagens que
passam para trás e para frente entre os elementos.
93
Unidade III
Um elemento de ator pode ser usado para representar o usuário que inicia o fluxo de eventos.
Elementos estereotipados, como interface, controle e entidade, podem ser usados para ilustrar as
telas, os controladores e os itens de banco de dados, respectivamente.
Cada elemento tem uma linha pontilhada tronco chamada de linha da vida do objeto ou elemento,
na qual o elemento/objeto existe e, potencialmente, participa das interações.
A figura 51 mostra um diagrama de sequência de um evento em que uma pessoa está telefonando,
essa pessoa é chamada de chamador.
Os objetos telefone chamador e telefone chamado também interagem para que o telefonema
aconteça.
sd Use Case Model
Chamador Telefone Telefone chamado

chamador
chamador levanta receptor( ) Linha de

vida do
objeto
sinal de discar começa ( )
disca ( )
Ativação
disca ( )
disca ( )
telefone ocupado ( )
telefone toca ( )
som da campainha ( )
atenda telefone ( )
telefones interligados ( )
telefones interligados ( )
pessoa chamada desliga ( )
conexão desfeita ( )
conexão desfeita ( )
chamador desliga ( )
Figura 51 – Exemplo de diagrama de sequência
94
6.3.1 Linha de vida
As linhas pontilhadas na vertical representam a existência do objeto em um determinado tempo.
Se uma determinada mensagem representa a criação da instância do objeto, sua linha de vida inicia-
se naquele ponto.
Se ela representa a destruição do objeto, a linha termina nesse ponto e a sequência termina.
Se o objeto existe durante todo o processo, a linha de vida permeia todo o espaço vertical
do diagrama.
A linha de vida pode se bifurcar em duas ou mais linhas concorrentes para mostrar
condicionalidades.
6.3.2 Ativação
Uma ativação evidencia o período de tempo em que um objeto está executando uma ação,
diretamente ou a partir de um procedimento subordinado.
A ativação é representada por um retângulo de base pequena e cuja altura representa o tempo da
ação (o topo do retângulo coincide com o início da ação e a base com o seu fim).
A ação a ser executada pode ser colocada em uma etiqueta na proximidade da ativação ou na
margem esquerda do diagrama, ou estar implícita na mensagem que aciona a ativação.
6.3.3 Autodelegação
Evidencia a mensagem cujo objeto emissor (remetente) coincide com o objeto alvo (destinatário).
Trata-se de uma chamada recursiva. Se a chamada recursiva se der sobre uma ativação, desenha-se
outro retângulo aninhado com o primeiro, para mostrar a autodelegação.
6.3.4 Mensagem
Uma comunicação entre objetos, que leva informação com a expectativa de que resultará em uma
atividade.
O recebimento de uma mensagem é normalmente considerado um evento. Mensagem é a unidade

fundamental da comunicação entre objetos.
A recepção de uma mensagem causa a invocação de uma operação no recebedor (objeto alvo). Esse
executa o método da classe que corresponde àquela operação.
95
Unidade III
As mensagens são representadas por setas nomeadas, colocadas nas proximidades da ligação, que
ligam os objetos por meio de suas linhas de vida.
A ponta da seta aponta para o objeto alvo. Quando um objeto for acionar uma mensagem nele
mesmo, a seta inicia-se e termina no mesmo objeto.
A implementação de uma mensagem pode tomar várias formas: a chamada procedure, a passagem
de sinal entre threads ativas, o específico acionamento de um evento etc.
6.4 Diagramas de estado (máquina de estado)
O diagrama de estados representa, para uma determinada classe de objetos, seu padrão de eventos,
estados e transição de estados.
Um diagrama de estados é uma rede de estados e eventos.
Na realidade, somente constrói-se diagrama de estados para as classes que possuem comportamento
dinâmico importante.
6.4.1 Estado
Um estado é uma abstração dos valores de atributos e ligações de um objeto. Por exemplo: a linha
telefônica está no estado sinal de discar.
Caso o dígito seja discado, a linha muda de estado, indo para o estado discando. Se o usuário
recolocar o telefone no gancho, a linha telefônica passa do o estado sinal de discar para o estado
inativa.
Os conjuntos de valores podem ser agrupados em um estado de acordo com propriedades que
afetam o comportamento geral do objeto. Por exemplo: o fato do estado de um banco ser de solvência
ou de insolvência depende do seu ativo exceder o seu passivo.
Com o passar do tempo, os objetos estimulam uns aos outros, resultando em uma série de alterações
em seus estados.
6.4.2 Notações
Na UML, o estado é representado por um retângulo, como no diagrama de atividades. Um retângulo

com o nome do estado representa um estado simples.
Um retângulo maior designa um estado composto ou máquina de estados. Quando outros estados
(simples) estão participando de determinado composto, são desenhados em seu interior.
96
Pseudo_estado_inicial
Estado_composto
Estado_simples
Est_simples 1 Est_simples 2
Pseudo_estado_final
Figura 52 – Símbolos do diagrama de estado
6.4.3 Evento
Um estímulo individual de um objeto A que o objeto B reconhece e reage é um evento.

Objeto Objeto
Estímulo B
A
Figura 53 – Evento entre objetos
O objeto B reage ao estímulo dependente de seu estado. Ele pode modificar seu estado, pode enviar
resposta para o remetente ou acionar outro objeto, a partir de novos eventos e estímulos.
Os eventos possuem os seguintes tipos: mensagem, tempo transcorrido e condição de guarda.
Um evento é algo que acontece em um certo momento com os objetos de uma classe. Por exemplo:
um usuário aperta o botão cancelar, o cliente desconta um cheque.
Um evento pode logicamente preceder ou suceder outro evento. Dois eventos podem não estar
relacionados, nesse caso, são chamados de concorrentes.
Cada evento é uma ocorrência única, que pode ser agrupada em classes de eventos.
Cada classe de eventos recebe um nome para indicar estrutura e comportamentos comuns.
O exemplo a seguir demonstra uma classe de eventos:
• O voo 100 parte de São Paulo.
• O voo 200 parte de Fortaleza.
• O voo 30 parte de Porto Alegre.
97
Unidade III
Pode-se criar a classe partida de aviões e tratar esses voos como instâncias da classe. Os atributos
dessa classe seriam: linha_aérea, número_do_voo, cidade_origem, cidade_destino etc.
A Figura 54 mostra exemplos de classes de eventos:
Partida_aviões Botão_do_mouse_
levantado
Empresa_aerea
Número_do_voo Botão
Cidade_destino localização
Altera_destino()
Figura 54 – Exemplo de classes de eventos
6.4.4 Transição
A modificação de estado causada por um evento é chamada de transição. A reação de um

objeto a um evento pode constituir-se de uma ação que provoca uma modificação de estado no
objeto.
Um estado corresponde ao intervalo entre dois eventos recebidos por um objeto.
Os eventos correspondem a “pontos no tempo”, e os estados representam “intervalos no tempo”,

como mostra a Figura 55.
Estados de um objeto
t (objeto)
Evento 1 Evento 2
Figura 55 – eventos e estados
Na definição de estados, ignoram-se os atributos que não afetam o comportamento dos

objetos.
Englobam-se em um só estado todas as combinações de valores de atributos e ligações que

apresentam a mesma reação dos eventos.
O diagrama de estados ou diagrama de máquina de estados determina ou específica a sequência de

estados causada por uma sequência de eventos.
A Figura 56 mostra um exemplo de eventos para uma classe conta de cliente de um banco.
98
Inativa
Depósito_Cliente
Depositando Depósito_Rejeitado Mensagem

rejeitado
Depósito_Aceito
Ativa
Figura 56 – Exemplo de um diagrama de estado
Um diagrama de estados é uma fonte de descoberta de operações. Ajuda a descobrir também novos
estados, regras de integridade e definir com mais precisão os domínios dos atributos envolvidos.
A figura 56 mostra um exemplo de um sistema de biblioteca.
Cadastramento
Publicação Correção de erros

indisponível de digitação
Empréstimo de Liberação da publicação
todos exemplares
Publicação Devolução do empréstimo
disponível
Indisp.
Retirada por empréstimo temporária
Depósito_Aceito (alienada)
Figura 56 – Diagrama de estados
Saiba mais
Vale a pena ler o material disponível no endereço: <http://www.

fabriciosousa.com/APS_Diagrama_Estados.pdf>.
Este material está baseado no livro Princípios de análise e projeto de

sistemas com UML, de Eduardo Bezerra, 2ª ed., Editora Campus/Elsevier.
99
Unidade III
Resumo
Esta unidade apresentou conceitos da modelagem comportamental

dos sistemas de informação.
Diversos diagramas e modelos da UML são utilizados para se modelar

os comportamentos dos sistemas, mas esta unidade deu ênfase ao modelo
de caso de uso que, para alguns autores, é o principal modelo de UML,
juntamente com o modelo de classes de objetos.
Como os modelos estruturais são fundamentais para se definir a

estrutura de um sistema, sua composição e dependências, os modelos
comportamentais mostram as ações que durante o tempo acontecem com
o sistema e com os atores que com ele interagem.
A UML apóia o processo de desenvolvimento UP (Unified Process). Ele

é considerado um processo use case driven, o que significa um processo
dirigido por casos de uso.
O modelo de caso de uso mostra o sistema realizando uma sequência

de ações, para receber entradas dos usuários e gerar saídas para responder
as necessidades do negócio. Daí a sua importância no desenvolvimento
moderno e a ênfase dada a ele nesta unidade.
De todos os diagramas da UML, juntamente com o diagrama

de casos de uso e o diagrama de classes, o diagrama de sequência é
considerado um dos mais importantes, principalmente no momento da
programação.
Com ele, pode-se passar a ordem e a sequência de chamadas dos

objetos para resolver determinada lógica ou cenário de um caso de uso. Por
sua vez, o diagrama de estado descreve o comportamento de um objeto de
uma determinada classe de objetos.
Já com o diagrama de estados, são modelados os eventos que podem

ser representados como operações nos modelos de objetos. O modelo
dinâmico de uma classe é herdado por suas subclasses. As subclasses
herdam os estados e as transições de seus ancestrais. As subclasses podem
ter seus próprios diagramas de estado.
100
Exercícios
Questão 1. Os processos de desenvolvimento de software que se baseiam na UML como linguagem

de modelos denominam o modelo de caso de uso como o orientador do processo (use case driven). Nesse
modelo, temos três elementos considerados básicos: o Ator, o Caso de Uso e a Associação entre o ator e o
caso de uso. O ator é usado para definir o papel que um utilizador ou usuário representa relativamente ao
sistema de informação modelado. Ele representa um conjunto coerente de papéis que os usuários de casos
de uso desempenham quando interagem com esses casos de uso. Pode-se afirmar que um ator representa
um papel que um ser humano, um dispositivo de hardware ou até outro sistema desempenha com o
sistema. A UML define que um usuário do sistema representado pelo ator pode ser: uma pessoa; outro
sistema de informação; um equipamento hardware especializado; a passagem de tempo. Considerando-se
os conceitos apresentados sobre a UML, analise as afirmações a seguir e assinale a alternativa incorreta:
A) Na UML, o modelo de caso de uso é importante, já que auxilia na captura de requisitos do sistema
que será construído.
B) Os casos de uso de um diagrama de Caso de Uso representam as funcionalidades que serão

implementadas em um sistema de informação.
C) Os atores representam o ambiente externo do sistema (seres humanos, máquinas, agrupamentos

lógicos, outros sistemas).
D) Como a UML apresenta modelos e elementos na tecnologia OO, pode-se afirmar que um Ator é
uma classe de objetos.
E) O ícone que representa um ator no diagrama de casos de uso é um retângulo com diversos
segmentos.
Resposta: Alternativa E.
Na UML, o modelo de caso de uso descreve como os usuários do sistema (entidades externas ao
sistema), interagem com o sistema enviando ou recebendo informações.
A) Correta. Quando o analista de sistemas precisa representar as necessidades do cliente ou usuário,

utiliza o modelo de caso de uso da UML; este permite ao usuário mapear os requisitos em torno
dos usuários e das funcionalidades do sistema.
B) Correta. No modelo de caso de uso, o elemento que representa as funcionalidades do sistema e

que executará os requisitos do sistema é o próprio caso de uso.
101
Unidade III
C) Correta. Como os atores estão fora do sistema e interagem com o mesmo modelo de Caso de Uso,
representam o ambiente externo do sistema.
D) Correta. Todos os elementos de todos os modelos da UML representam objetos que podem ser
instanciados na execução do sistema. O ator que representa os usuários do sistema também será
instanciado na execução do sistema.
E) Incorreta. O ícone que representa um ator no diagrama de caso de uso é a figura do stick man ou
o homem palito.
Questão 2. Os casos de uso em um modelo de caso de uso podem ser expandidos por meio de outros
para mostrar comportamentos especiais e de extensão que complementam os cenários do caso de uso
básico modelo. Considerando-se os conceitos apresentados sobre o modelo de caso de uso, analise as
afirmações a seguir e assinale a alternativa incorreta:
A) Um modelo de casos de uso é um modelo das funções pretendidas do sistema e suas vizinhanças,
que serve como contrato entre o cliente e os desenvolvedores.
B) Há muitas maneiras de modelar um sistema, cada uma pode atender a uma finalidade diferente,
e o modelo de caso de uso, por ser facilmente compreendido, torna-se uma ferramenta poderosa
de comunicação entre as pessoas envolvidas com o sistema.
C) Os usuários e qualquer outro sistema que pode interagir com o sistema sendo modelado com o
diagrama de caso de uso são os atores.
D) O modelo de casos de uso não é uma ferramenta útil na negociação entre os desenvolvedores e
os clientes/usuários devido à sua complexidade técnica.
E) Os casos de uso são desenvolvidos com base nas necessidades dos atores. Isso garante que o
sistema será o que os usuários esperam.
102
UNIDADE III
Questão 2
Resposta correta: alternativa D.
Justificativa: quando uma funcionalidade (caso de uso) for complexa, propõe-se

uma decomposição em funções mais detalhadas, entretanto, um dos pontos mais
difíceis é aprender como determinar em que nível de detalhe os casos de uso devem
"começar e terminar". Os casos de uso ou os requisitos do software devem
estabelecer "o que" o sistema executa, mas não "como" ele executa.
A) Correta. Quando o modelo de caso de uso é criado, ele deve ser aprovado pelo
cliente ou usuário do futuro sistema. Dessa forma, ele pode ser usado para garantir
aos clientes ou aos usuários que a equipe entendeu o problema e que vai tomar uma
solução adequada.
B) Correta. O modelo de caso de uso foi desenvolvido para facilitar a comunicação

da equipe de desenvolvimento entre os seus componentes e com os clientes ou
usuários do sistema. Dessa forma, ele é considerado uma ferramenta de
comunicação no processo de desenvolvimento de sistemas.
C) Correta. O Ator representa os usuários que irão interagir com o sistema, seja
por meio da entrada de dados ou como receptor das saídas do sistema.
D) Incorreta. O modelo de casos de uso é um dos modelos mais simples da UML,

sendo que essa simplicidade e os poucos símbolos gráficos permitem que pessoas
sem grandes conhecimentos técnicos em sistemas consigam interpretá-lo.
E) Correta. O modelo de caso de uso tem por finalidade mapear as necessidades

ou os requisitos de um sistema e é a ferramenta de comunicação entre os envolvidos
com o sistema.
Unidade IV
7 MODELAGEM DA ARQUITETURA DE NEGÓCIO
7.1 Introdução
Processos de negócio são atividades previamente estabelecidas que têm como objetivo determinar
a forma como o trabalho é realizado numa organização.
Constituem um conjunto de ações, relacionadas entre si de forma lógica e coerente, a fim de

promover uma saída favorável à organização, tanto em termos internos como externos.
Uma estrutura de processos de negócio mal concebida pode por em risco a eficiência e a eficácia de
uma empresa por meio dos produtos e serviços que gera e disponibiliza.
Dada a similaridade das suas composições, função de negócio e processo de negócio são conceitos
que frequentemente suscitam dúvidas entre as pessoas interessadas em formar um melhor entendimento
a respeito dos elementos de uma arquitetura de negócios.
Ambos são “coisas que a empresa faz”, entretanto, os processos são transfuncionais (ou horizontais),
já que perpassam diversas barreiras funcionais dentro da organização (por exemplo: adquirir bem,
alienar bem, contratar funcionário), enquanto que as funções, que em conjunto descrevem a missão da
empresa, são verticais (por exemplo: contabilidade, vendas, logística).
Um outro aspecto relevante, e que pode representar uma mais valia na implementação dos processos de
negócio numa organização, tem a ver com a implementação de um sistema de informação bem estruturado.
A existência de uma boa rede de informação, entre todos os intervenientes nos processos de negócio
da organização, é condição sine qua non, uma vez que permite a comunicação em tempo real, tornando
possível uma adequada tomada de decisão, resultante do ajuste contínuo de procedimentos que irá
repercutir em toda a dinâmica organizacional e, consequentemente, na excelência dos seus resultados.
Desse modo, quando se fala em processos de negócio, a abrangência é enorme, pois o seu âmbito de
atuação é transversal e atua em todas as áreas da organização, com elevado impacto na qualidade dos
serviços e/ou produtos, na redução de custos e no desenvolvimento do próprio negócio.
Por outro lado, a existência de uma interface entre os processos de negócio e uma rede de sistemas
de informação constituem fatores-chave fundamentais, quer para a generalidade dos negócios dos
tempos de hoje, quer para a produção de indicadores e instrumentos de controle efetivo para uma
constante monitorização das atividades da organização.
103
Unidade IV
Assim, como a Figura 57 sugere, pode-se definir processos de negócio como um conjunto de atividades
desenvolvidas a partir de um objetivo predefinido que irá concretizar-se num resultado específico, em
termos de produto ou serviço que se pretenda realizar.
Pessoas Equipamento Informação
Objetivo Processos de negócio Resultado
Que tarefas específicas?
Qual a prioridade?
Quais os procedimentos?
Figura 57 – Processos de negócio
7.2 Modelagem de negócio
Para compreender uma organização, é necessário entender seus processos de negócio. Profissionais
da Tecnologia da Informação se empenham em construir soluções que têm por finalidade auxiliar a
empresa na conquista de maior espaço no mercado globalizado.
Nesse contexto, os processos são avaliados e, sempre que possível, informatizados, de forma a
promover vantagens competitivas a partir do alinhamento estratégico entre o sistema e o negócio da
empresa.
Para a OMG (Object Management Group, 2005), um processo de negócio corresponde a um conjunto
coeso de atividades que criam um resultado, o qual garante a criação de valor a um cliente externo
ou interno à empresa, ou, visto de outra forma, pode ser um conjunto de tarefas regido por regras de
negócio e que se desenvolve a partir de um determinado evento de negócio.
Segundo Laudon e Laudon (2001), um processo de negócio refere-se à maneira pela qual o trabalho
é organizado, coordenado e focado, para produzir um produto ou serviço de valor.
De um lado, processos de negócios são fluxos de trabalhos concretos de materiais,

informações e conhecimentos. De outro, referem-se também à maneira singular de as
organizações coordenarem trabalho, informação e conhecimento, e de como a gerência prefere
coordenar o trabalho.
Já a modelagem de negócio é uma técnica de modelagem de alto nível, que surgiu das dificuldades
identificadas pelos analistas de sistemas.
104
É uma abstração voltada à realidade dos administradores, assim, estudiosos e pesquisadores da

área de TI criaram uma técnica de modelagem de alto nível denominada de modelagem de negócio,
que hoje é parte integrante no processo de desenvolvimento de software e que serviu para facilitar
a comunicação com as pessoas que fazem parte do negócio mas não possuem conhecimentos de
Engenharia de software.
Observação
Os autores Michael Hammer e James Champy afirmam:
Um processo de negócio é uma coleção de atividades que usam um ou mais tipos

de entrada e criam uma saída que seja de valor para o cliente. Um processo de negócio
tem um objetivo e é afetado por eventos que ocorrem no mundo externo ou em outros
processos.
Lembrete
A técnica de modelagem de negócio é profundamente relacionada à

arquitetura de negócios.
Observação
Já o autor Thomas Davenport aponta que o processo de modelagem de

negócios:
[...] é um conjunto estruturado de atividades, desenhado para produzir

um resultado especificado para um cliente ou um mercado em particular. Isso
implica forte ênfase sobre como o trabalho é feito dentro da organização,
em contraste com o foco no produto. Um processo é então uma ordenação
específica de atividades de trabalho, por meio do tempo e do espaço, com
começo e fim e entradas e saídas claramente dentificadas: uma estrutura
para ação.
7.2.1 Conceitos de negócio
Funções de negócio são estruturas conceituais idealizadas que servem para descrever a missão de
uma organização. Uma vez que tenham sido definidas e decompostas adequadamente, elas se mantêm
estáveis ao longo do tempo, mesmo diante de reorganizações da empresa.
Como são perenes, as funções representam um ponto de referência (conceitos comuns) ao se

descrever diferentes negócios, que de outra forma exibiriam variações significativas.
105
Unidade IV
A Figura 58 exemplifica o relacionamento dentro de uma organização entre as funções de negócio e

os processos de negócio a partir das atividades organizacionais e atividades de processos.
act Business Process Model
Função de negócio
Atividade de negócio
Atividade componente
do processo
Processo de negócio
Subprocesso
componente de processo
Figura 58 – Função de negócio, processo de negócio e seus relacionamentos
Como exemplo da aplicação dessa definição, temos o fato de que a função contabilidade de uma
empresa define o contador, a função gerencial define o gerente e assim por diante.
Funções de negócio são também alocadas a unidades ou áreas organizacionais específicas (que
exercerão os diferentes papéis) e são envolvidas e acionadas no decorrer do “comportamento” do
negócio.
A Figura 58 mostra que uma função corresponde a uma série de atividades relacionadas, envolvendo
uma ou mais entidades de dados, realizadas com o objetivo de se cumprir um ou mais objetivos da
missão da empresa.
As atividades de negócio que compõem uma função de negócio são relacionadas entre si por
“afinidade”, porque trabalham um grupo comum de entidade de dados (clientes e produtos) ou porque
são sequenciais ou paralelas na realização do trabalho associado a um resultado final comum.
Observação
A arquitetura de negócio busca uma visão conceitual e única de uma

atividade ou funcionalidade, de forma que se possa identificar quando e
como ela se repete nos diversos processos de negócio, a fim de determinar
106
a generalização dos conceitos de tarefas comuns, identificando atividades

compartilhadas e administrando seu reuso por meio da distribuição dos
componentes que as suportam.
Da mesma forma, os sistemas de informação que suportam tais funções estarão focados em
aspectos específicos do funcionamento do negócio, independentemente da forma como a empresa está
organizada.
As atividades são direcionadas a dados e são “iniciadas” por transações ou solicitações de dados. Elas
são a porção ativa das funções e tendem a ser repetitivas e formalizadas.
Observação
É importante notar:
• Uma maneira de se diferenciar o conceito de funções e atividades

é que, geralmente, as funções são gerenciadas e atividades são
realizadas.
• Funções são gerenciais e atividades são operacionais.
Já um processo de negócio é definido como a sequência completa de um comportamento de

negócio, provocado por algum evento, que produz um resultado significativo para o negócio e que, de
preferência, tenha foco no cliente.
No percurso do processo, desde o evento inicial até a produção de um determinado resultado,

várias funções do negócio podem estar envolvidas. Assim, diz-se que os processos são elementos
transfuncionais, já que perpassam diversas funções dentro da organização.
Se uma função é composta de atividades que representam um papel ou razão de existir da

organização, os processos de negócio “executam” essas atividades de forma que, individualmente ou
combinadas, realizem o trabalho de uma determinada função.
Um estudo de aplicação de modelagem de processo de negócio para apoiar a

especificação de requisitos de um sistema
Antes de entrarmos em duas notações de modelagem de processos seria interessante

analisarmos os resultados obtidos com a aplicação da modelagem apresentada no artigo
Um estudo de aplicação de modelagem de processo de negócio para apoiar a especificação
de requisitos de um sistema, dos autores Adriana Andrade, Andriele Ribeiro, Eduardo Borges
e Wolber Neves, apresentado no VI Simpósio Internacional de Melhoria de Processos de
Software, em São Paulo, em 2004.
107
Unidade IV
No item resultados obtidos, os autores afirmam:
A aplicação da modelagem de processos de negócio trouxe resultados bastante positivos.

A execução dessa etapa antes da realização do levantamento dos requisitos do sistema foi
um fator de redução de riscos, tanto para o cliente quanto para o fornecedor.
O cliente pôde ter uma visão melhor do seu negócio, identificando as áreas que realmente
seriam beneficiadas pela construção do sistema, evitando assim o desperdício de recursos.
Foi interessante observar que, durante as oficinas, o cliente pôde perceber que
determinados processos não estavam sendo executados da melhor forma. Diante desta
percepção, alguns processos foram remodelados, evitando que o sistema fosse construído
sobre uma base operacional deficiente.
Para o fornecedor, a execução da modelagem de processos de negócio resultou em

maior facilidade na gestão dos requisitos do sistema. Muitas das constantes mudanças
que ocorrem durante o desenvolvimento de um sistema decorrem da inexistência de um
consenso entre os representantes do cliente sobre a melhor forma de se executar um
processo.
A modelagem de processos de negócio fez com que esse consenso fosse alcançado antes
do início do levantamento dos requisitos do sistema, tornando esta etapa mais eficiente.
A identificação dos casos de uso do sistema (UML) também foi bastante facilitada. Como
passaram a conhecer melhor a realidade do cliente, os engenheiros de requisitos puderam
ser mais proativos nessa atividade, contribuindo com sugestões e ponderações baseadas em
conhecimento mais sólido.
Esta proatividade mostrou-se especialmente útil nas primeiras oficinas, já que naquele
momento os representantes do cliente ainda não estavam totalmente seguros com a
metodologia de levantamento dos requisitos.
Outro benefício trazido pela modelagem de processos de negócio diz respeito à

rastreabilidade dos requisitos. Uma característica de qualidade importante para uma
especificação de requisitos é a facilidade em se determinar os resultados do desenvolvimento
que serão afetados por cada requisito (rastreabilidade para frente), bem como a origem de
cada um (rastreabilidade para trás).
Como os requisitos foram derivados diretamente do modelo de processos de negócio, a

rastreabilidade para trás foi garantida documentando-se, para cada requisito, o processo de
negócio que o gerou.
Um ponto importante no desenvolvimento de um sistema, especialmente quando seu

porte não é pequeno, é a sua divisão em produtos. A divisão é uma maneira formal de se
108
exercitar o desenvolvimento incremental, já que produtos coesos e de menor porte são

entregues em menor tempo do que um único módulo que contemple todas as funções.
Isto é importante tanto do ponto de vista técnico quanto do de negócio, já que muitas
vezes o cliente não dispõe de recursos para construir todo o sistema de uma só vez, e a
priorização de requisitos dentro de um módulo único não é uma tarefa simples.
Esse foi também um ponto em que a modelagem de processos de negócio foi benéfica.
Antes de sua realização, cliente e fornecedor imaginavam que o sistema seria composto por
três produtos. Após a modelagem, percebeu-se que o número de produtos era realmente
três, mas a composição dos mesmos foi bastante modificada. Dois dos produtos foram
agrupados em um único, e um produto de controle de fluxo de trabalho (workflow) foi
identificado.
Apenas um produto permaneceu conforme tinha sido concebido no início. A divisão

inicial dos produtos espelhava a divisão funcional da empresa, o que não se mostrou uma
boa idéia do ponto de vista de sistemas. A modelagem de processos de negócio fez com
que cliente e fornecedor percebessem que duas das áreas eram muito integradas, o que
justificaria um único produto para atendê-las.
Da mesma forma, o problema de controle de fluxo de trabalho era comum a todas as

áreas funcionais, o que justificaria um produto genérico para este fim, e não a inserção de
funcionalidades correlatas em um dos produtos específicos para determinada área.
Após a divisão dos produtos, um deles foi escolhido para ser especificado e construído.
Seria necessário, portanto, realizar uma estimativa do tamanho do produto em pontos
de função, para orçar-se a fase de elaboração. O melhor conhecimento da organização,
conseguido por meio da modelagem de processos de negócio, também foi fundamental
para que essa estimativa fosse bem próxima da contagem oficial de pontos de função,
realizada alguns meses depois (após o fim da elaboração).
Percebeu-se inclusive que a aproximação do número real foi maior do que em projetos
em que a modelagem de processos de negócio não foi usada.
Como último resultado importante, podemos citar o artefato resultante da modelagem de

processos de negócio. Esse documento é importante para o cliente, já que é a documentação
dos processos da organização. Mas também do ponto de vista do fornecedor o documento
foi de grande utilidade, pois serviu para dar uma visão geral às pessoas que entravam no
projeto depois de seu início. Foi uma forma simples e barata de integrar novas pessoas à
equipe.
Adaptado de: <www.simpros.com.br>. Acesso em: 13 jul. 2012.
109
Unidade IV
7.2.2 Extensão de negócio da UML
Segundo Paul e Serrano (2003), o estudo sobre processo de negócio não deve ser isolado, sendo
importante seu relacionamento com a área de TI, pois ela é considerada sua grande modificadora.
O processo de negócio geralmente confia no suporte fornecido pelos Sistemas de Informação (SI)
para a realização de suas atividades.
Similarmente, esses sistemas dependem da infraestrutura de comunicação, normalmente oferecido

por rede de computadores (RC).
A Figura 59 demonstra o relacionamento existente entre processos, sistemas de informação e redes

de computadores, no qual mudanças ocorridas em alguns dos domínios devem afetar os demais.
Processo1 Processo2 Processon
...
SI1 SI2 SIn
RC1 RCn
TI
Figura 59 – Relacionamento de processos, Sistemas de Informação (SI) e

Redes de Computadores (RC)
De acordo com Dalal et al (2004), muitas técnicas para modelagem dos processos empresariais, incluindo
DFDs (Diagramas de Fluxo de Dados), Idef0 (Definições Integradas para Modelagem por Funções, em nível
0) e diagramas de casos de uso de negócio, têm suas raízes nos processos de desenvolvimento de software.
De acordo com as orientações da UML 2.0 Superstructure Specification, disponibilizada a partir de

outubro de 2004 pela OMG, os casos de uso são meios de especificar os requisitos de um sistema de
informação.
Todavia, quando casos de uso documentam processos de negócio de uma organização, o Sistema
sob Discussão (SsD), do inglês System under Discussion (SuD), é a própria organização.
Os stakeholders ou atores de negócio são os acionistas da companhia, clientes, vendedores e as

agências governamentais regulamentadoras. Os atores primários incluem os clientes da companhia e
talvez seus fornecedores. Um caso de uso apenas documenta um processo, ele não faz reEngenharia, ou
seu projeto novamente (COCKBURN, 2005).
Um caso de uso especifica o comportamento de um sistema ou de parte de um sistema e é uma

descrição de um conjunto de sequências de ações, incluindo variantes realizadas pelo sistema para
produzir um resultado observável do valor de um ator.
110
Além disso, os casos de usos podem ser aplicados para captar o comportamento pretendido do sistema
que está sendo desenvolvido, sem ser necessário especificar como esse comportamento é implementado.
Também fornecem uma maneira para os desenvolvedores chegarem a uma compreensão comum com os
usuários finais do sistema e com os especialistas do domínio e servem para ajudar a validar a arquitetura e
para verificar o sistema à medida que ele evolui durante seu desenvolvimento (BOOCH et al, 2000).
Quando utilizados para representar processos de uma organização, os casos de uso são identificados
como casos de uso de negócio.
Em outras palavras, um caso de uso de negócio representa o que a organização faz (BOGGS e BOGGS,
2002). O escopo de um caso de uso pode abranger uma escala de assuntos:
• Uma empresa ou uma linha de negócio: este nível de modelo é utilizado para descrever como os
sistemas se integram.
• Um sistema individual: este é o nível mais utilizado na abordagem por casos de uso.
• Um simples subsistema simples ou componente: este nível descreve os mecanismos de

implementação de um elemento do modelo.
• Para descrever um processo de trabalho de um negócio.
• Para focar discussão sobre futuros requisitos de software.
• Para ser os requisitos funcionais de um sistema.
• Para documentar o projeto do sistema.
• Para ser escrito em um grupo pequeno e restrito, ou em um grupo grande ou distribuído.
O modelo de casos de uso de negócio é um modelo das funções pretendidas do negócio. É usado
como base para identificar papéis e produtos liberados na organização.
Os casos de uso de negócios são identificados e possivelmente resumidos no início da fase de

iniciação, para ajudar a definir o escopo do projeto (RUP, 2001).
Quadro 8 – Propriedades de um caso de uso de negócio
Nome da propriedade Descrição

Nome O nome do caso de uso de negócio.
Breve descrição Uma breve descrição do papel e da finalidade do caso de uso de negócios.
Metas Uma especificação das metas ou objetivos mensuráveis do caso de uso de negócios.
Uma especificação das métricas relevantes ao caso de uso de negócios e uma
Metas de desempenho definição das metas de utilização dessas métricas.
111
Unidade IV
Uma descrição textual do fluxo de trabalho representado pelo caso de uso de

negócios. O fluxo deve descrever o que o negócio faz para oferecer vantagens
Fluxo de trabalho a um ator de negócio, e não como esse negócio resolve os problemas. A
descrição deve ser compreensível para qualquer pessoa dentro do negócio.
Se o caso de uso de negócios pertence à categoria central, suporte ou
Categoria gerenciamento.
Uma especificação dos riscos de executar e/ou implementar o caso de uso de
Risco negócios.
Possibilidades Uma descrição do potencial de melhoria estimado do caso de uso de negócios.
Uma definição de quem é o proprietário do processo de negócios: a pessoa que
Proprietário do processo gerencia e planeja as mudanças.
As características do caso de uso de negócio não cobertas pelo fluxo de
Requisitos especiais trabalho conforme descrito.
Uma lista dos locais dentro do fluxo de eventos do caso de uso de negócios
Pontos de extensão em que um comportamento adicional pode ser inserido por meio do
relacionamento de extensão.
Os relacionamentos (como associações de comunicação, relacionamentos de
Relacionamentos inclusão e de extensão) dos quais o caso de uso participa.
Diagramas de atividades Esses diagramas mostram a estrutura do fluxo de trabalho.
Diagramas de casos de uso Esses diagramas mostram os relacionamentos que envolvem o caso de uso.
Ilustrações do fluxo de trabalho Resultados ou esboços manuscritos provenientes das sessões de encenação.
Adaptado de: RUP, 2001.
De acordo com o RUP (2001), os elementos de um modelo de caso de uso de negócio podem ser
demonstrados conforme o quadro 9.
Quadro 9 – Componentes do diagrama de caso de uso de negócio
Nome Notação Descrição
Um ator de negócio representa um papel

Ator de negócio desempenhado em relação ao negócio por
alguém ou algo no ambiente do negócio.
Um caso de uso de negócios define uma

instância de negócio, no qual cada instância
é uma sequência de ações realizada por um
Caso de uso de negócio negócio que produz um resultado de valor
observável para um determinado ator de
negócio.
O modelo de casos de uso de negócios é um

modelo das funções pretendidas do negócio.
Modelo de caso de uso de negócio É usado como base para identificar papéis e
produtos liberados na organização.
112
Um relacionamento de generalização de uma

classe de ator de negócio (descendente) com outra
Generalização de ator classe de ator de negócios (ascendente) indica que
o descendente herda o papel que o ascendente
pode assumir em um caso de uso de negócios.
Uma associação de comunicação entre um caso

Associação de comunicação
de uso e um ator indica que uma instância
do caso de uso e uma instância do ator irão
interagir.
Um relacionamento de extensão é aquele que
se estabelece entre um caso de uso de extensão
e um caso de uso base, especificando como o
“extensão” comportamento definido para o caso de uso de
Relacionamento de extensão extensão pode ser inserido no comportamento
definido para o caso de uso de base. Ele é
inserido implicitamente, ou seja, a extensão não
é exibida no caso de uso base.
Um relacionamento de inclusão é aquele que
se estabelece entre um caso de uso base e um
“inclusão”
caso de uso de inclusão, especificando como
Relacionamento de inclusão o comportamento definido para o caso de uso
de inclusão é inserido de forma explícita no
comportamento definido para o caso de uso
base.
Uma generalização de casos de uso é um
relacionamento de um caso de uso filho com
Generalização de casos de uso um caso de uso pai, especificando como um
filho pode adotar todo o comportamento e as
características descritas para o pai.
Um diagrama de casos de uso mostra os atores

Diagrama de casos de uso de negócios, os casos de uso de negócios, os
pacotes de casos de uso e seus relacionamentos.
De acordo com o RUP (2001), a projeção realizada pela Engenharia de negócio é fundamental para
a realização do sistema.
As atividades do negócio e os relacionamentos identificados entre elas, bem como a atuação dos
envolvidos, determinarão os objetivos a serem alcançados pelo software a ser desenvolvido.
A Figura 60 apresenta uma conexão entre essas duas áreas.

Proposta para informatização
Proposta
de software
Engenharia de Engenharia
processo de negócio de software
Modelo de negócio
Figura 60 – O relacionamento entre Engenharia de processo de negócio e Engenharia de software
113
Unidade IV
7.2.3 Visões de modelos de negócio
O modelo de negócios é a forma pela qual uma empresa cria valor para todos os seus principais
públicos de interesse.
Sua utilização ajuda a ver de forma estruturada e unificada os diversos elementos que compõem
todas as formas de negócios da organização.
O modelo de negócio de uma empresa é composto por 5 principais elementos:
• Modelo de proposta de valor: é a forma pela qual a empresa define qual é o seu diferencial
no mercado, a forma pela qual é única e se destaca de todas as demais empresas que participam
desse mesmo mercado.
• Modelo de interface com o consumidor: é o que escreve onde, quando e como uma empresa
interage com os seus consumidores. Essa interação pode se dar por meio de lojas, embalagens de
produtos, comerciais, SAC, website etc.
• Modelo de operação: é como que uma empresa faz para levar o seu produto até o seu consumidor.
Esse modelo deve prever todos as etapas necessária para viabilizar sua produção, passando por
logística, até chegar às mãos de quem compra o seu produto ou serviço.
• Modelo estratégico: é a descrição de como uma empresa irá atingir os seus objetivos estratégicos.
Nesse modelo é onde visualiza-se a missão de uma empresa, sua visão, seus valores e todas as
competências necessárias para que a empresa funcione de forma adequada.
• Modelo econômico: é onde se demonstra a viabilidade financeira de uma empresa. Esse

modelo mostra como uma empresa ganha recursos e paga suas despesas a fim de atingir a
sustentabilidade.
7.3 OCL e sua utilização na modelagem de processo de negócio
A OCL (Object Constraint Language) é uma notação que permite se dar mais precisão nas especificações
ou modelos que usam a UML.
Lembrete
A OCL é baseada na lógica e matemática discreta. Assim como a UML,

é uma linguagem de modelagem e não uma linguagem de programação. É
uma linguagem de modelos tipada. Inicialmente, a OCL era uma extensão
para a UML, agora é parte da UML padrão.
114
Por que a OCL?
• Um diagrama UML, tal como o diagrama de classes, é tipicamente não refinado o suficiente para
permitir-se ter todos os aspectos relevantes de uma especificação.
• Há a necessidade de se descrever restrições adicionais sobre os objetos de um modelo.
• A linguagem natural é inerentemente ambígua.
• Linguagens formais tradicionais são dificíeis para usuários de negócio ou modeladores de sistemas.
• A OCL é uma linguagem formal que permanece simples para ler e escrever.
Quando se deve usar a OCL?
• A linguagem OCL é usada para expressar condições constantes de restrições de especificações

para sistemas que estão sendo modelados.
• Para especificar invariantes nas classes e tipos no modelo de classes.
• Para especificar tipos invariantes para estereótipos.
• Para descrever pré e pós-condições nas operações e métodos.
• Para especificar restrições nas operações.
A OCL é suportada para os seguintes tipos de diagramas da UML 2.0, como mostrta a quadro 10.
Quadro 10 – Diagramas com suporte OCL
Tipo de diagrama Versão da UML Como o suporte é provido

Restrições para o comportamento associado
com os casos de uso como expressões OCL.
Use case (caso de uso) UML 2.0 Por exemplo, uma interação escolhida como
um comportamento.
Classes (classe, namespace e Restrições na criação de objetos são
UML 1.5 e 2.0
comunicação) suportadas.
Restrições de invariância de estado para
Interação (sequência e comunicação) UML 2.0 linhas de vida e restrições dos operandos de
fragmentos combinados como expressões OCL.
Condições de guarda de transições como
Máquina de estado UML 2.0 expressões OCL.
Como os modelos de negócio são suportados pelos diagramas de casos de uso a OCL, esses apoiarão
as restrições das pré e pós-condições para execução de um caso de uso de negócio.
115
Unidade IV
7.4 Integração com o desenvolvimento de software
Num processo iterativo de desenvolvimento de software, a equipe do projeto segue uma série de
fases, cada uma focando diferentes partes do negócio ou sistema. Existem duas abordagens para a
modelagem de negócio em um ambiente iterativo:
• Primeiro, terminar toda a modelagem de negócio e, na sequência, iniciar as atividades iterativas

(análise, design, codificação, teste e implantação).
• Alternativamente, pode-se incluir a modelagem de negócio nas iterações (BOGGS e BOGGS, 2002).
Para Boggs e Boggs (2002), tanto num processo iterativo, como num modelo de processo do tipo
“cascata”, a modelagem de negócio surge nas fases iniciais.
As razões pelas quais isso ocorre é que a modelagem de negócio determina o contexto para o
projeto. As figuras 60 e 61 mostram o aparecimento da modelagem de negócio nos processos de
desenvolvimento de software.
Modelagem de negócio
Análise
Implantação
Design
Teste Implementação
Figura 61 – Processo iterativo após o surgimento da modelagem de negócio
Modelagem Análise
de negócio
Implantação
Design
Teste Implementação
Figura 62 – Modelagem de negócio como fase integrante do processo iterativo
7.4.1 Processo de desenvolvimento de software
Existem inúmeros caminhos para reproduzir modelos de negócio dentro dos processos de
desenvolvimento de software, incluindo o uso de outras notações tais como Idef0 (modelagem
funcional), ou mesmo descrições textuais do processo.
116
No entanto, a UML é um padrão bem definido, suportado por muitas técnicas. É a linguagem de
modelagem dominante, usada em sistemas de informação orientados a objeto.
A UML é na atualidade o padrão que possui a melhor definição, suportada por muitas ferramentas e,
dessa forma, tornou-se a linguagem de modelagem dominante na aplicação da tecnologia da orientação
a objetos.
Além disso, pode ser utilizada para a modelagem de negócio e também para a modelagem de
outros sistemas, ou seja, para aqueles que não serão utilizados para o desenvolvimento de softwares
(OMG, 2005).
Para Widrig e Leffingwell (2003), os principais modelos para a modelagem de negócio são: business
use-case e business object model. Diagramas num modelo de negócio ajudarão a compreender o que a
organização fornece de valor, dentro de um relacionamento.
Enquanto a maioria dos diagramas da UML foca no sistema que será construído, o modelo de casos
de uso de negócio se concentra no negócio em torno desse sistema (BOGGS e BOGGS, 2002).
O modelo de caso de uso de negócio consiste na interação entre atores e casos de uso, para
demonstrar a sequência de eventos necessários na realização de um trabalho.
Juntos, atores e casos de uso descrevem o que está envolvido nas atividades do negócio e também
como ele ocorre (WIDRIG e LEFFINGWELL, 2003).
7.4.2 Arquitetura de negócio e arquitetura de software
Um dos principais esforços da investigação relacionada com a Engenharia de software tem sido
a definição e representação de modelos que descrevam os processos de software, garantindo que
esses correspondam fidedignamente às necessidades efetivas (em forma e conteúdo) dos processos
de negócio.
Deparamo-nos então com duas realidades complementares: a modelagem dos processos de negócio
e a modelagem do software, que também podem ser chamadas de arquitetura de negócio e arquitetura
de software, na qual esta última tem cada vez mais a necessidade de estar em sintonia com toda a
abrangência do negócio (RODRIGUES, 2004).
As modelagens de negócio e de sistema (software) são frequentemente desenvolvidas como parte

de dois diferentes projetos com dois diferentes times. Ambas devem possuir boa definição, pois são
ferramentas importantes para o gerenciamento da complexidade da amplitude e dificuldade do sistema
(PENKER e ERIKSSON, 2000).
Rodrigues (2004), ao avaliar o contexto da modelagem de negócio para a modelagem de sistema,

especifica que ainda existe um caminho a ser percorrido para que a ponte entre esses dois domínios seja
estabelecida de forma suave e sem sobressaltos.
117
Unidade IV
A Figura 63 mostra a integração proposta por Rodrigues (2004).
Modelagem do processo Modelagem de sistema
O que existe para fazer a ponte efetiva

entre modelagem de negócio e sistema?
Figura 63 – Integração entre modelagem de negócio e sistema
No RUP (2001), a integração entre negócio e sistema tem início nas primeiras atividades da iteração
do ciclo de desenvolvimento do sistema, definida como iniciação.
Nesse momento, a maior parte dos esforços, para as disciplinas Modelagem de Negócios e Requisitos,
é utilizada com o propósito de obter as informações necessárias para a condução do projeto e elaboração
do software.
A Figura 64 demonstra, no detalhe, o esforço necessário na fase inicial da iteração, a partir do

desenho de visão geral do RUP.
Fases
Disciplinas Iniciação Elaboração Construção Transição
Modelagem de negócios
Requisitos
Concentração
de esforços nas
fases iniciais.
Figura 64 – O esforço da modelagem de negócios e requisitos
A Figura 64 mostra que as disciplinas de Modelagem de Negócios e Requisitos do Sistema são

perfeitamente integradas e dependentes ao longo do processo de desenvolvimento iterativo RUP.
Um conceito atual que vem sendo tratado pelos autores e as empresas de tecnologia é o gerenciamento
de processos de negócio ou business process management.
118
Saiba mais
Vale a pena conferir o documento Business Process Management Enabled

by SOA, da IBM de 2009, em que o gerenciamento de processos de negócio
é mais frequentemente associado com o ciclo de vida de um de processos
de negócios. O ciclo de vida de processo de negócio abrange identificar
e melhorar os processos que proporcionam capacidade de negócios para
implantar e gerenciar os seus processos quando estiver operacional.
O que é frequentemente esquecido é a gestão do desempenho do processo depois que é operacional.

De certa forma, essa é provavelmente a fase mais importante do ciclo de vida de processos. Depois que
um processo de negócio é implantado, ele deve ser gerenciado, e, para gerenciar o processo de negócio,
deve-se ter visibilidade do desempenho de processos.
Quando um processo não atingir mais o seu desempenho de seus objetivos, é hora de voltar ao
ciclo de vida para avaliar a causa raiz do problema de desempenho e buscar oportunidades de melhoria
adicionais.
Subjacente, BPM é também governança. Governança é um componente essencial de BPM porque

fornece a estrutura que garante que a estratégia de negócios e metas sejam implementadas no nível
operacional.
A estrutura de governança também permite negócio e alinhamento de TI, fornecendo mecanismos

que aumentem a colaboração e cooperação entre os dois mundos, os processos de negócio e a tecnologia
da informação.
8 A modelagem de processos de negócio
8.1 Visão Erikson e Penker
Antes que a OMG se preocupasse com a modelagem de negócios com a linguagem UML, os autores
Erikson e Penker (2000) propuseram um metamodelo para a modelagem dos processos de negócio, o
qual apresenta:
• Uma visão de mais alto nível, visando identificar a situação do negócio que será abordada.
• Nessa visão, deve-se definir o contexto e o escopo, sendo que:
— o contexto é o que está relacionado, qual a situação, descrição do problema; e
— o escopo é até onde vai, contorno ou limite.
119
Unidade IV
• Essa visão pode incluir FCSs (Fatores Críticos de Sucesso).
• As metas e objetivos (do original Goal) podem ser decompostos em diferentes níveis, como,
estratégico/tático/operacional, sendo que:
— o objetivo é qualificável; e
— a meta é quantificável.
Nesse modelo, os processos de negócio:
• possuem uma meta;
• possuem entradas e saídas específicas;
• usam recursos;
• possuem um número de atividades, realizadas em alguma ordem, que podem ser vistas como
subprocessos;
• afetam mais de uma unidade da organização;
• criam valor para algum consumidor (interno ou externo).
A figura 65 apresenta os elementos ou símbolos propostos para o modelo de Erikson e Penker.
<<processo>>
Processo A
<<processo>> <<processo>> <<processo>>

Subprocesso A1 Subprocesso A1 Subprocesso A1
Atividade A2a Atividade A2b Atividade A2c
Atividades podem ser entendidas

como processos atômicos
Figura 65 – Notação de Erikson e Penker para modelagem de negócio
120
As atividades ou processos atômicos são:
• Diretas: diretamente envolvidas na criação do produto ou serviço, que é o valor criado pelo
processo.
• Indiretas: dá suporte às atividades diretas, como manutenção, administração etc.
• Garantia de qualidade: atividades que garantem a qualidade de outras atividades, como

inspeção, controle, revisão e validação.
A figura 66 ilustra os passos de um processo de negócio nesta notação.
<<processo>>
Furação
<<processo>>
Fazer furo
Ler Ligar Furar
Calibrar instrução furadeira
Processo contendo 3 subprocessos: dois atômicos e um composto
Figura 66 – Passos de um processo
A figura 67 mostra um exemplo de um processo de negócio com recepção e emissão.
<<processo>>
Ordem Administração Compra de
de de compra de ação no
<<processo>> compra ação mercado
Demanda
do cliente
por ação
<<processo>>
Ordem Venda de
de Administração
de venda de ação no
venda mercado
ação
Figura 67 – Processo de recepção e emissão
121
Unidade IV
Como novo exemplo, a figura 68 apresenta um modelo de processo de furação de chapas em uma
indústria qualquer.
<<goal>>
chapas furadas
por dia: Meta
Quantitativa
Valor = 100
<<achieve>>
<<information>> <<processo>>
instruções
de fucação furação <<physical>>
chapa
perfurada
<<physical>>
chapa de aço
Figura 68 – Exemplo de um processo de furação de chapa
A notação de Erikson e Penker ainda hoje é utilizada, e algumas ferramentas Case, tal como a
ferramenta EA, mantêm essa notação.
8.2 A modelagem de processos de negócio com a BPM
A notação BPMN surgiu como um padrão alternativo à UML, também sendo gráfica, porém seus
símbolos são um pouco diferentes, pois a BPMN (Business Process Modeling Notation) foi criada
especificamente para modelar processos de negócio. Essa notação não oferece qualquer suporte para
modelar dados, atores, estados de ciclo de vida, ou sistemas.
Quem desenvolveu o BPMN foi o Business Process Management Initiative (BPMI), iniciativa oriunda
da OMG que lançou a especificação 1.0 ao público em maio de 2004.
Tanto a UML como a BPMN são notações mantidas pela OMG.
Os objetivos do esforço do grupo que desenvolveu o BPMN são:
• Fornecer uma notação que seja fácil.
• Ser compreensível por todos os usuários de negócios.
• Envolver os analistas de negócio, os desenvolvedores, os técnicos responsáveis pela aplicação dos

sistemas que irão executar os processos e as pessoas de negócios.
122
A BPMN define um Business Process Diagram (BPD), que é baseado em um fluxograma adaptado
para a criação de modelos gráficos de tarefas dos processos de negócio.
Para a BPMN, um modelo de processo de negócios é uma rede de objetos gráficos, denominados de
atividades, e do fluxo de controle, que define a ordem de execução.
As grandes empresas de software, tais como a IBM, a Oracle, a SAP e outras, vêm investindo em
sistemas que automatizam a gestão de processos de negócio (execução, controle e monitoração).
Esses sistemas são os denominados BPMS (Business Process Management Suite), que dão suporte ao
mapeamento, execução, monitoração e controle dos processos de negócio de uma organização.
Tipicamente, inclui:
• o mapeamento dos processos de negócio ponta-a-ponta;
• desenho dos fluxos e formulários eletrônicos;
• definição de workflow;
• regras de negócio;
• integradores;
• monitoração em tempo real das atividades; e
• alertas.
É uma poderosa ferramenta de gestão, para garantir que os processos estão sendo efetivamente
executados como modelados, contribuindo para os objetivos da organização.
Os softwares utilizados na operacionalização e gerenciamento de processos de negócio são um dos

principais facilitadores da gestão do conhecimento referente ao processo, sendo considerada a maior
facilidade para obtenção, distribuição e análise dos dados.
Há algumas funcionalidades que podem ser disponibilizadas via software, inclusive nos softwares
BPMS, que, quando disponíveis, aumentam a capacidade dos gestores e demais envolvidos com o processo
em estabelecer uma troca de imagens e idéias, nos ambientes onde ocorre a geração do conhecimento.
Observação
A solução BPMS não propõe a substituição dos sistemas existentes na

organização os conhecidos como “sistemas legados”, e sim disponibiliza um
ambiente de integração de sistemas de informação, que permite definir:
123
Unidade IV
• fluxo de execução;
• regras;
• eventos;
• demais especificações necessárias à operação e gerenciamento do

processo de negócio.
Dessa forma, permite atender a outra característica do processo de negócio: a de ser

extremamente dinâmico, permitindo, por exemplo, uma substituição rápida e simples de um
software por outro, necessária quando uma empresa parceira da organização é substituída,
demandando a integração com um novo software disponível no ambiente computacional do
novo parceiro.
De acordo com vários autores, um BPMS completo teria os seguintes módulos ou funcionalidades:
• Funcionalidades mínimas para uma solução poder se classificar como BPMS:
— ferramenta de modelagem e desenho do processo;
— engenho de execução do processo;
— orquestração de web services;
— interface de workflow para usuários.
• Para ter um produto mais completo, seria necessário:
— suporte para regras de negócio complexas;
— Business Activity Monitoring (BAM);
— controle de versão dos documentos anexados a instâncias do processo.
• E para um produto completo, seria acrescentado de:
— Enterprise Service Bus (ESB);
— Repositório de metadados;
— Uma suite de business intelligence.
124
Um BPD é formado por um conjunto de quatro elementos gráficos, que são:
• objetos de fluxo;
• objetos de conexão;
• raias (swimlanes); e
• artefatos.
8.2.1 Objetos de fluxo
Um BPD apresenta três objetos de fluxo: evento, atividade e gateway. Os objetos de fluxo são os
principais elementos gráficos para definir o comportamento de um processo de negócio.
8.2.1.1 Evento
Um evento é algo que “acontece” no decurso de um processo de negócio. Esses eventos afetam o
fluxo do processo e normalmente têm uma causa (trigger) ou um impacto (resultado).
Somente os eventos têm a capacidade de iniciar ou terminar um processo, porém não executam
tarefas nesse. Os eventos ainda podem forçar a execução ou desviar para uma determinada atividade.
Há três tipos de eventos, com base em quando eles afetam o fluxo: evento de início, evento
intermediário e evento de fim, com notação apresentada na figura 69.
BPMN BPMN
Evento início
Evento intermediário
Evento fim
Figura 69 – Símbolos de eventos da BPMN
125
Unidade IV
O evento início define a inicialização em um processo. O evento intermediário define um evento

intermediário em um processo. Já o evento fim define o término de um evento em um processo.
Um processo pode ser iniciado por diferentes circunstâncias. Essas circunstâncias são chamadas de
gatilhos (triggers), tais como, uma mensagem chegando ou um temporizador.
8.2.1.2 Atividade
Uma atividade organiza e especifica participação de comportamentos subordinados, tais como, as

sub-atividades ou ações, para refletir o controle e o fluxo de dados de um processo.
As atividades são usadas nos diagramas de atividades para vários propósitos de modelagem: para a
modelagem do desenvolvimento de uma aplicação típica, para modelagem de um processo de negócio
ou para modelar um workflow.
Durante a criação, ou em edições mais tarde, uma atividade pode ser definida como um elemento
composto. Contudo, quando se cria uma atividade composta, é possível usar também o elemento
atividade estruturada, que foi criada para esse propósito.
A especificação da OMG UML1 estabelece:
• Uma atividade específica à coordenação da execução de comportamentos subordinados, usando

um controle e modelo de fluxo de dados.
• Os comportamentos subordinados coordenados por esses modelos podem ser iniciados porque
outros comportamentos no modelo irão concluir a execução, ou porque os objetos e os dados
ficam disponíveis, ou porque ocorrem eventos externos para o fluxo.
• O fluxo de execução é modelado como atividades, os nós são ligados por arestas. Um nó pode ser
a execução de um comportamento do subordinado, como um cálculo aritmético, uma chamada
para uma operação, ou a manipulação do conteúdo do objeto.
• Atividades podem formar hierarquias invocando outras atividades, em última análise, para resolver
as ações individuais. Em um modelo orientado a objetos, as atividades são geralmente chamadas
indiretamente de métodos vinculados às operações que estejam diretamente invocadas.
• As atividades podem descrever processos de computação. Nesse contexto, são os métodos

correspondentes às operações nas classes. As atividades podem ser aplicadas à modelagem
organizacional para a Engenharia de processos de negócio e workflow.
• Nesse sentido, eventos geralmente se originam de dentro do sistema, tais como o acabamento de
uma tarefa, mas também de fora do sistema, como uma chamada de cliente.
1
126
• As atividades também podem ser utilizadas para a modelagem de sistema de informação, para
especificar os processos ao nível do sistema. As atividades podem incluir ações de vários tipos
(funções primitivas, operações aritméticas etc.).
Uma atividade é representada por um retângulo de bordas arredondadas e é um termo genérico para o
trabalho que a empresa realiza. Uma atividade pode ser atômica (tarefa) ou não atômica (composta – subprocesso).
analysis Diagrama Estrutura de Versão
Atividade Sub_processo
Figura 70 – Atividade atômica e não atômica
8.2.1.3 Gateway
Utilizado para controlar a divergência e convergência da sequência de fluxos, determina as decisões tradicionais
de bifurcação, fusão e união de caminhos. Marcadores internos indicam o tipo de controle do comportamento.
analysis Diagrama Estrutura de Versão
Figura 71 – Elemento gateway
Gateways são os mecanismos padronizados na notação BPMN para desvios. Eles controlam como
o processo diverge ou converge, ou seja, representam pontos de controle para caminhos dentro do
processo. Eles separam e juntam o fluxo de um processo por meio do fluxo de sequência.
8.2.2 Objetos de conexão
Os objetos de fluxo são conectados ao diagrama pelos objetos de conexão, para criar o esqueleto
estrutural básico de um processo de negócio.
Um BPD tem três objetos de conexão: fluxo de sequência, fluxo de mensagem e associação.
127
Unidade IV
8.2.2.1 Fluxo de sequência
Um fluxo de sequência é usado para mostrar a ordem (sequência) que as atividades são realizadas
em um processo.
A figura 72 mostra um exemplo de fluxo de sequência.
BPMN BPMN
Fluxo de sequência
Atividade 1 Atividade 2
Figura 72 – Fluxo de sequência
8.2.2.2 Fluxo de mensagem
Um fluxo de mensagem é usado para mostrar mensagens entre dois participantes do processo
(entidades empresariais ou papéis de negócio) que enviam e recebem mensagens.
BPMN BPMN
Fluxo de mensagem
Atividade 1 Atividade 2
Figura 73 – Fluxo de mensagem
8.2.2.3 Associação
Uma associação é usada para associar dados, textos e outros artefatos com os objetos de fluxo.
Associações são utilizadas para mostrar as entradas e saídas de atividades.
analysis Diagrama Visão Estrutura de Versão
Documento
Activity2
IntermediateEvent3
Figura 74 – Associação
128
A figura 75 mostra um exemplo de um pedaço de um processo utilizando os elementos apresentados.
class BPMN
No
EndEvent
StartEvent
Repeat for Each Supplier
Limite do tempo excedeu
YES Send RFQ Receive Add

Quote Quote
Evento intermediário
Marca que mostra que o para um time out
subprocesso tem loop
Figura 75 – Exemplo de um processo
8.2.3 Raias (Swimlanes)
Swimlanes é um mecanismo para organizar atividades em categorias visuais separadas, que

organizam as diversas capacidades ou responsabilidades. Os objetos swimlanes do BPD são:
• Pool;
• Lane.
Swinlanes ou raias ajudam a dividir e organizar atividades em diferentes categorias visuais em um

diagrama, de forma a ilustrar diferentes capacidades funcionais ou responsabilidades.
Pools são utilizados quando o diagrama envolve duas entidades empresariais e são separados fisicamente
no diagrama. As atividades dentro de grupos separados são consideradas processos autocontidos.
Os fluxos de sequência não podem cruzar a fronteira de um pool. Deve-se usar o fluxo de mensagem
como mecanismo para mostrar a comunicação entre dois participantes em pools diferentes.
8.2.3.1 Pool
Pool representa um participante em um processo (pessoa, área, empresa, outro processo etc.). Atua
como um container gráfico para o particionamento de um conjunto de atividades de um ou mais
processos de um participante.
129
Unidade IV
class BPMN
<<Pool>>
Cliente
Figura 76 – Exemplo de um diagrama com pool
8.2.3.2 Lane
Lane é uma subpartição dentro de um pool que vai se estender a todo comprimento do pool,
tanto verticalmente quanto horizontalmente. Lanes são usadas para organizar e categorizar
atividades.
As lanes são elementos que são posicionados dentro de pools para indicar mais de um perfil que
colaboram para a execução de um processo. Lanes criam subpartições para os objetos dentro de um
pool. Essas participações são usadas para agrupar elementos do processo.
São frequentemente usadas para separar as atividades associadas com uma função ou papel de uma
determinada empresa. Os fluxos de sequência podem atravessar as fronteiras das lanes dentro de um
pool.
O fluxo de mensagem não pode ser usado entre fluxos de objetos nas lanes de um mesmo pool.
class BPMN
Cliente
<<Pool>>
HELPDESK
CAC
Figura 77 – Uma pool com duas lanes
A figura 78 mostra um exemplo de um BDP com duas pools, sendo que essas somente possuem uma
lane cada.
130
class BPMN
Envia Recebe Envia Recebe

pedido pedido
<<Pool>>
PACIENTE
sintomas receita
médico sintomas
Ocorre
doença Eu quero ver Eu me sinto
o médico doente
O médico Pegue sua receita

Consultório Médico
pede sintomas para comprar os

<<Pool>>
remédios
Envia Recebe Envia Recebe

pedido pedido sintomas receita
médico sintomas
Figura 78 – Exemplo de pools e lanes juntas
8.2.4 Artefatos
A notação BPMN permite aos modeladores o uso de extensões de notação. Um número qualquer
de artefatos pode ser adicionado ao diagrama, conforme as necessidades apropriadas ao contexto de
negócio sendo modelado.
A versão corrente do BPMN predefine três tipos de artefatos BPD:
• objeto de dados;
• grupo; e
• anotação.
Os modeladores podem criar seus próprios tipos de artefatos, que podem adicionar mais detalhes
sobre como o processo é executado.
A figura 79 mostra um diagrama com lanes dentro de uma pool e com adicionamento de artefatos.
131
Unidade IV
class BPMN
<<Group>>
Administração
Informações Prepara ordem
pagamento de pagamento
+
Web Service
E-mail Aprova
requisição requisição
aprovação
Gerenciamento
Estas atividades
Despacha para podem ser iniciadas
aprovação ao mesmo tempo
Figura 79 – Uso de artefatos no BPD
8.2.4.1 Objeto de dados
São mecanismos para mostrar que dados são requeridos ou produzidos pelas atividades. São
conectados às atividades a partir das associações.
BPMN BPMN
<<Group>>
Grupos
Objetos de dados
Anotações
Figura 80 – Artefatos do BPD
8.2.4.2 Grupo
Um grupo pode ser usado para documentação, mas não afeta o fluxo de mensagens.
8.2.4.3 Anotação
É um mecanismo para um modelador colocar textos de informações adicionais no diagrama.
132
8.3 Conclusão do BPMN
Um objetivo-chave da BPMN foi criar uma ponte entre a notação da modelagem de processos de
negócios e a modelagem de linguagens orientadas para TI, que irá implementar os processos dentro de
um sistema de gestão de processos de negócios.
Observação
Os objetos gráficos da BPMN, apoiados por um rico conjunto de atributos

de objeto, foram mapeados para o Business Process Execution Language
for Web Services (BPEL4WS v 1.1), o padrão de fato para a execução do
processo.
Resumo
Esta unidade mostrou os conceitos envolvidos com a modelagem de

negócios que precede a modelagem de sistemas de informação.
Mostrou também que a UML propõe uma notação e um padrão de

modelagem voltados para a especificação das regras de negócio de uma função
e processo de negócio de uma organização. A OMG também vem propondo o
uso da nova notação denominada BPMN, que está sendo preparada para novas
ferramentas de automação de aplicações a partir dos modelos de negócio.
O uso dessa combinação tem como grande objetivo colocar a área de

desenvolvimento de sistemas totalmente casada com ás áreas de negócio e
construindo aplicações que agreguem valor ao negócio.
Com relação às organizações, elas estão descobrindo que a modelagem

de processos de negócio pode ser uma excelente ferramenta para disseminar
o conhecimento organizacional.
Uma vez que as organizações passam a compreendê-lo como um recurso,

a modelagem de processos de negócio pode tornar-se uma excelente fonte
para a vantagem competitiva.
Processos de negócio estruturados na cooperação, integração e no

alinhamento entre todas as áreas organizacionais constituem o segredo de
sucesso de uma organização.
Atualmente, o modelo de caso de uso de negócio pode ser aplicado

nos modelos de desenvolvimento em cascata, na fase de levantamento
133
Unidade IV
de requisitos de negócio, e no modelo iterativo RUP, na fase de iniciação,

também para modelagem dos requisitos de negócio que precedem as
definições e especificações dos modelos dos sistemas de informação da
organização.
Exercícios
Questão 1. Os autores definem que processos de negócio são um conjunto de atividades previamente
estabelecidas cujo objetivo é determinar como o trabalho será realizado em uma organização por uma
área de negócio. Diz-se que uma estrutura de processos de negócio mal concebida pode por em risco
a eficiência e a eficácia da organização por meio dos produtos e serviços gerados e disponibilizados.
Considerando os conceitos sobre processos de negócio, analise as afirmações a seguir e assinale a
alternativa incorreta:
A) Uma função de negócio é a mesma coisa que um processo de negócio, já que ambos representam
o conjunto de atividades de uma organização.
B) Processos de negócio são atividades transfuncionais previamente estabelecidas para tratar um

determinado negócio da organização.
C) Um sistema de informação bem estruturado implementa processos de negócio de uma empresa

ou organização.
D) Uma Função de Negócio representa a estrutura funcional da Organização, já que um “Processo

de Negócio” é um conjunto de atividades ou ações que são transfuncionais, isto é, atravessam
diversas áreas ou funções de negócio.
E) Os processos de negócio devem funcionar de forma alinhada em relação a toda a estrutura

organizacional, pois somente dessa forma será possível atingir os objetivos transversais de
qualquer organização.
Resposta: Alternativa A.
Alguns autores definem processo de negócio ou processo organizacional como sendo um conjunto
de atividades. Nesse conjunto, uma organização deve ser estruturada com o objetivo de produzir valor
para os seus clientes.
A) Incorreta. Função de negócio é uma representação de uma estrutura dentro de uma

organização. Por exemplo: o departamento financeiro é uma função de negócio; já um sistema
financeiro (processo de negócio financeiro), atua em diversas áreas da empresa. Quando se
mapeia o processo de negócio financeiro, torna-se necessário entender diversas áreas ou
134
funções da empresa, que, de alguma forma, utilizam ou precisam tratar com as informações
financeiras da empresa.
B) Correta. Os processos de negócio estão diretamente ligados aos negócios da empresa e independem
da estrutura organizacional. Normalmente atravessam as fronteiras das funções de negócio.
C) Correta. Um sistema de informação automatiza atividades dos processos de negócio, e, se ficarem

estritamente ligados a uma função da empresa, não serão eficazes na busca de valor para a
instituição.
D) Correta. uma função de negócio representa uma estrutura funcional de uma empresa, por
exemplo: área de TI, área de Logística etc. E um processo de negócio seria a venda de carros de
luxo de uma montadora de veículos.
E) Correta. A venda de carros de luxo de uma montadora possuirá atividades espalhadas por toda a estrutura
de uma montadora: área de marketing, design de veículos, linha de produção, e assim por diante.
Questão 2. Na atualidade, com propósito de se ter sistemas de informações abrangentes e que

agreguem valor ao negócio de uma organização, evolue-se para duas visões complementares: a modelagem
de negócio e a modelagem de sistemas de informação. Normalmente, as modelagens de negócio e de
sistemas (software) são desenvolvidas como parte de dois diferentes projetos, com dois diferentes times. A
modelagem de negócios trata todas as atividades envolvidas com o negócio, e a modelagem de sistemas
verifica o aspecto de automação a partir do modelo de negócio. Ambas devem possuir boa definição,
pois são ferramentas importantes para o gerenciamento da complexidade da amplitude e dificuldade do
sistema. Considerando os conceitos sobre Arquitetura de negócio, Arquitetura de Software e exemplos
apresentados nesta unidade, analise as afirmações a seguir e assinale a alternativa incorreta:
A) Para a modelagem de negócio, utiliza-se a notação BPMN, a qual surgiu como um padrão alternativo à
UML, já que esta foi desenvolvida para abranger somente as atividades de desenvolvimento de software.
B) A modelagem de negócio com BPMN é gráfica, porém, para representar as atividades existentes
nos processos de negócio, seus símbolos são um pouco diferentes da UML.
C) Quem desenvolveu o BPMN foi o Instituto de Engenharia de Software, em 1991.
D) Pode-se afirmar que o processo de modelagem de negócios “é um conjunto estruturado de

atividades, desenhado para produzir um resultado específico para um cliente ou um mercado em
particular”.
E) A modelagem de negócio leva em consideração que um processo é “uma ordenação específica

de atividades de trabalho, por meio do tempo e do espaço, com começo, fim e entradas e saídas
claramente identificadas: é uma estrutura para ação”.

135
Figuras e ilustrações
Figura 2
Estrutura de um modelo de AOO. Adaptada de YOURDON, E.; ARGILA, C. Análise e projeto orientados a
objetos, São Paulo: Makron Books, 1998.
Figura 3
Exemplo de uma aplicação da AOO. Adaptada de YOURDON, E.; ARGILA, C. Análise e projeto orientados
a objetos, São Paulo: Makron Books, 1998.
Figura 57
Processos de negócio. Disponível em: <http://www.trainning.com.br/analistadenegocios_bpm_artigo.

asp>. Acesso em: 14 mai. 2012.
Figura 59
Relacionamento de processos, Sistemas de Informação (SI) e Redes de Computadores (RC). PAUL, R. J.;
SERRANO, A. Simulation for business processes and information systems design. Anais da Conferência
de Simulação de Inverno de 2003. Departamento de Sistemas de Informação e Computação,
Universidade de Brunel, U.K.: Uxbridge Middlesex, 2003.
Figura 60
O relacionamento entre Engenharia de processo de negócio e Engenharia de software. RUP. Rational

Unified Process. Rational Software Corporation, versão 2002.05.00, 2001.
Figuras 61 e 62
Processo iterativo após o surgimento da modelagem de negócio e Modelagem de negócio como fase
integrante do processo iterativo. BOGGS; BOGGS. Mastering UML with Rational Rose. SYBEX Sample
Chapter. 2002.
Figura 63
Integração entre modelagem de negócio e sistema. RODRIGUES, V. M. S. Mapeamento de processos de

negócio com base nas extensões de penker e eriksson para casos de uso. Portugal. 2004.
Figura 64
O esforço da modelagem de negócios e requisitos. RUP. Rational Unified Process. Rational Software
Corporation, versão 2002.05.00, 2001.
136
Referências
BRANCO, I. V. C. Modelagem de processos organizacionais integrada às aplicações práticas de

aprendizagem organizacional e compeências conversacionais. Dissertação de Mestrado da UCB,
Brasilia, Brasil, 2007.
BOGGS; BOGGS. Mastering UML with Rational Rose. SYBEX Sample Chapter. 2002.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML – guia do usuário. Rio de Janeiro: Editora Campus, 2000.
COCKBURN, A. Escrevendo casos de uso eficazes – um guia prático para desenvolvedores de software.
Tradução de Roberto Vedoato. 1ª ed. Porto Alegre: Bookman, 2005.
DALAL, N. et al. Toward an integrated framework for modeling enterprise processes. Communications
of the ACM, v. 47, nº 3, 2004.
ERIKSON, H.; PENKER, M. Business modeling with UML: business patterns at work. John Wiley & Sons, 2000.
HUCKVALE, T.; OULD, M. Process modeling: why, what and how., New York, EUA: Jonh Wiley, 1993.
FURLAN, J. D. Modelagem de objetos através da UML, São Paulo: Makron Books, 1998.
JACOBSON, I; BOOCH, G; RUMBAUGH, J. The unified software development process. Indianápolis, EUA:
Addison Wesley, 1999.
JACOBSON, I; BOOCH, G; RUMBAUGH, J. The unified modeling language – user guide. Massachusetts,
EUA: Addison Wesley, 1999.
LAUDON, K. C.; LAUDON, J. P. Gerenciamento de sistemas de informação. Rio de Janeiro: LTC, 2001.
MEDEIROS, E. Desenvolvendo software com UML. São Paulo: Makron Books, 2004.
OMG. Object management Group. Disponível em: <http://www.uml.org/>. Acesso em: 17 ago. 2005.
PAUL, R. J.; SERRANO, A. Simulation for business processes and information systems design. Anais
da Conferência de Simulação de Inverno de 2003. Departamento de Sistemas de Informação e
Computação, Universidade de Brunel, U.K.: Uxbridge Middlesex, 2003.
PFLEEGER, S. L. Engenharia de software – teoria e prática. São Paulo: Prentice hall, 2004.
RUMBAUGH, J. et al. Modelagem e projetos baseados em objetos. São Paulo: Editora Campus, 1994.
REED JR., P. R. Desenvolvendo aplicativos com Visual Basic e UML. São Paulo: Makron Books, 2000.
137
RODRIGUES, V. M. S. Mapeamento de processos de negócio com base nas extensões de Penker e
Eriksson para casos de uso. Portugal, 2004.
RUP. Rational Unified Process. Rational Software Corporation, versão 2002.05.00, 2001.
SENGE, P. M. A quinta disciplina: arte, teoria e prática da organização de aprendizagem. São Paulo:
Best Seller, 1990.
SZILAGYI, D. C. Modelagem de processos de negócio – um comparativo entre BPML e UML. Dissertação

de Mestrado da Pontifícia Universidade Católica – São Paulo, 2010.
YOURDON, E.; ARGILA, C. Análise e projeto orientados a objetos, São Paulo: Makron Books, 1998.
WIDRIG, D.; LEFFINGWELL, D. Managing software requirements: a use case approach. 2ª ed. Addison
Wesley, 2003.
138
139
140
141
142
143
144
Informações:
www.sepi.unip.br ou 0800 010 9000
UNIDADE IV
Questão 2
Resposta correta: C.
Justificativa
A) Correta. Para a modelagem de negócio, é utilizada a notação BPMN, a qual

surgiu como um padrão alternativo à UML. Os autores da UML eram da área de
software e desenvolveram esse padrão para ser utilizado somente no
desenvolvimento de sistemas.
B) Correta. Tanto a modelagem de negócio como a modelagem de sistemas

utilizam símbolos gráficos, porém a simbologia da modelagem de negócios está
voltada para o entendimento das atividades do processo, enquanto a modelagem de
sistemas está voltada para a solução das funcionalidades e arquiteturas de sistemas
de informação (software).
C) Incorreta. Quem desenvolveu o BPMN foi o Business Process Management

Initiative (BPMI), iniciativa oriunda da OMG que lançou a especificação 1.0 ao público
em maio de 2004.
D) Correta. A técnica de Modelagem de Negócios é profundamente relacionada à

Arquitetura de Negócios e é baseada em atividades das áreas de negócio.
E) Correta. Processo de Negócio é definido como a sequência completa de um

comportamento de negócio provocado por algum evento e que produz um resultado
significativo para o negócio e que, de preferência, tenha foco no cliente.

Modelagem Processos Unip PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Modelagem Processos Unip PDF

Caricato da

Copyright:

Formati disponibili

Modelagem de Processos

Autor: Prof. Dr. Ivanir Costa

Dados Internacionais de Catalogação na Publicação (CIP)

C837m Costa, Ivanir

Modelagem de processos / Ivanir Costa. – São Paulo: Editora

Notas: este volume está publicado nos Cadernos de Estudos e

1. Tecnologia da informação. 2. Modelagem de processos. 3.

Prof. Fábio Romeu de Carvalho

Profa. Melânia Dalla Torre

Prof. Dr. Yugo Okida

Profa. Dra. Marília Ancona-Lopez

Unip Interativa – EaD

Profa. Elisabete Brihy

Material Didático – EaD

O objetivo da disciplina Modelagem de Processos é apresentar e conceituar a importância de modelos

Entre os autores e especialistas envolvidos com os processos de desenvolvimento de software, existe

Desde a década de 1970, os autores especializados em software vêm propondo processos ou

Dessa forma, quando os modelos abrangem as atividades de desenvolvimento, a comunicação entre

1. Ajudar a equipe de projeto a visualizar um sistema como ele é ou pretende ser.

2. Ajudar a especificar a estrutura ou o comportamento do sistema.

3. Proporcionar um modelo que sirva de guia na construção do sistema.

4. Documentar as decisões tomadas pela equipe de desenvolvimento de projeto.

Na atualidade, outra área de interesse e importante na construção de sistemas fundamentais é a

Todavia, ao longo do tempo, a modelagem de software vem sendo criticada devido à

Quando os modelos são considerados artefatos de desenvolvimento de primeira classe, os

Quando os modelos abrangem as atividades de desenvolvimento e em tempo de execução dessa

De acordo com a Microsoft, em seu documento denominado de Estratégia de modelagem, de 2005,

Vale a pena ler o artigo de maio de 2005, disponível no site

1.2 Motivação para o uso de modelos

O autor Senge (1990):

4. Dessa maneira, um modelo se parece muito com um arquivo de código-fonte, e os mecanismos

5. Um modelo representa um conjunto de abstrações que dá suporte a um desenvolvedor em um

Um modelo de conectividade de aplicativos, por exemplo, poderá

Um modelo é uma representação ou interpretação simplificada da realidade, ou uma interpretação

• Uma base para concepção de novos processos.

• Além de garantir o correto funcionamento, permite efetuar medições quanto ao desempenho do

1.3 Princípios da modelagem de software

A modelagem de sistemas de informação (software) é a atividade de construir modelos que expliquem

Na construção do software, os modelos podem ser usados na identificação das características e

A modelagem de software normalmente implica a construção de modelos gráficos que simbolizam

Vale a pena, para quem ainda não conhece ou utilizou uma

uma série de propriedades e facilidades que ajudam na documentação,

1.4 Modelagem e orientação a objetos

O enfoque tradicional de modelagem para a construção de sistemas de informação baseia-se na

A figura 1 mostra o enfoque baseado em sistema versus o enfoque baseado em objetos.

Foco em sistema Foco em objeto

Figura 1 – Sistema vs. objeto

Um programa, no sentido tradicional agora, é um conjunto de objetos que se relacionam para

• manter a modelagem do sistema e, em decorrência, sua automação o mais próximo possível de

Embora o termo “orientação a objetos” tenha sido usado de várias

James Rumbaugh (1994) define orientação a objetos como:

[...] uma nova maneira de pensar os problemas utilizando modelos

O componente fundamental é o objeto que combina estrutura e

1.5 Por que usar a orientação a objetos?

Dentre as várias razões pode-se citar:

• Inconsistência na visão dos modelos:

— Diferentemente das outras tecnologias de desenvolvimento, o mesmo conjunto de modelos na

– Descobertos na fase de análise de sistemas para representar os requisitos do usuário.

– Alterado na fase de projeto para incorporar as características do ambiente operacional do

– E finalmente utilizado na fase de construção para subsidiar a implementação nas linguagens

• Melhor abstração do domínio do problema:

• Facilidade para reusabilidade:

— A OO, com a implementação do conceito de generalização e especialização, a partir da herança,