Escolar Documentos
Profissional Documentos
Cultura Documentos
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.
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
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
Modelagem de Processos
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
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
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.
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:
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.
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
Modelagem de Processos
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.
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.
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.
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.
11
Unidade I
Saiba mais
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.
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.
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
Modelagem de Processos
Observação
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 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.
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.
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
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 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).
Programa Classe
Processos
Atributos
Dados
Operações
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:
• 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
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.
— Os objetos são:
— 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.
— 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.
— 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.
— Interação entre os componentes OO é restrita a poucas interfaces que são bem definidas.
— 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.
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
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
Modelagem de Processos
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.
Estruturas
Assuntos Assuntos
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.
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
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.
• 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
Modelagem de Processos
• 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.
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.
• 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.
• 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.
• 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.
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
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
22
Modelagem de Processos
• 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.
— 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 podem representar coisas do mundo real: carro, gato, máquinas 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.
— 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
— A mensagem indica uma solicitação de O1 para O2, “coloque o flap num ângulo x!”
— 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
Modelagem de Processos
• 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.
• 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.
— A linguagem Java é um conjunto de classes. Por exemplo: Panel, Label etc. Se o objeto “O”
pertence à classe “C”, dizemos que:
— Quando queremos ser precisos e nos referirmos a uma coisa exata, usaremos “instância de
objeto”.
— 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
— 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.
— 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).
— Característica que um objeto possui. Exemplo: nome, cor, altura, data de nascimento etc.
– 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).
26
Modelagem de Processos
— Vantagens do encapsulamento:
– 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.
• 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.
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 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.
— 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çã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.
— O ato de invocar um método também é chamado de “passar uma mensagem para o objeto”.
• Subclasse: característica particular de uma classe. Exemplo: classe “animal”, subclasses “gato”,
“cachorro” etc.
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
Modelagem de Processos
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
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 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
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:
— 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).
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.
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
Modelagem de Processos
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”
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
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.
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.
Para se falar de um processo de software, é necessário alguns conceitos envolvidos com a Engenharia
de software.
32
Modelagem de Processos
• Uma disciplina de Engenharia voltada para todos os aspectos da produção de software de qualidade.
• 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)
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.
Dentro dessa abrangência da ES, um dos aspectos mais importantes é o estudo dos processos
envolvidos com o software.
Saiba mais
– Começa em termos de sistema e progride por meio da análise, design, codificação, teste e
manutenção.
34
Modelagem de Processos
Engenharia de
Sistemas
Análise
Design
Codificação
Teste
Manutenção
– 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.
– 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 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.
Observação
– 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
Modelagem de Processos
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.
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.
Saiba mais
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.
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 UML, nessa fase, contribui com os diagramas de sequência, comunicação, tempo, pacotes,
implantação e componentes.
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
Modelagem de Processos
Resumo
39
Unidade I
— ferramentas Case;
— programação visual;
— geradores de código;
Exercícios
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.
Resposta: Alternativa E.
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
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.
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.
UNIDADE I
Questão 2
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.
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 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;
• documentar as decisões tomadas pela equipe de desenvolvimento de projeto (REED JR., 2000).
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
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).
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.
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
Modelagem de Processos
• 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.
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).
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
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.
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.
46
Modelagem de Processos
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
Lembrete
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.
Lembrete
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
Modelagem de Processos
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.
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.
Um esquema de numeração pode ser: 1, 1.1, 1.1.1, 1.1.2, 1.2 e assim por diante.
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.
Um diagrama de implantação (deployment) mostra como e onde o sistema será implantado, ou seja,
sua arquitetura de execução.
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.
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.
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.
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
Mundo real
Realidade de interesse
(Observado)
Modelo de objeto
Atributos
Operações ( )
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”.
Pessoa Pessoa
Correto
Cod_Pessoa Nome
Nome idade
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 pública indica que qualquer outra classe poderá acessar seus atributos e solicitar a
execução de suas operações.
52
Modelagem de Processos
• 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.
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.
53
Unidade II
Papel 1
Classe A Classe B
Papel 2
associação
Pessoa Empresa
trabalha_para
João da Silva Telesp
ligação
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.
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..*
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
Modelagem de Processos
1..* 1..*
Projeto Linguagem
1..*
Pessoa
A UML possui uma notação específica para representar as regras de uma associação entre os objetos
das 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}
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.
A figura 21 mostra um exemplo do uso da navegação em uma associação entre duas classes de
objetos.
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.
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.
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.
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
Modelagem de Processos
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
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 ( )
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
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.
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
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.
1
0..*
Divisão
1
0..*
Departamento
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
Modelagem de Processos
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.
Livro
1
0..*
Capítulo
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
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.
Associação de
generalização
Empresa Trabalha_para Funcionário
0..1 0..*
Masculino Feminino
Divisão
Departamento
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.
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).
60
Modelagem de Processos
Aeronave
Classe ou superclasse
Jato Planador
Subclasse
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.
Funcionário
Funcionário Funcionário
feminino masculino
nome solteira
registrar licença
maternindade
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
61
Unidade II
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
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.
62
Modelagem de Processos
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.
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.
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.
Tela
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.
Veículo
Terrestre Aquático
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
Modelagem de Processos
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.
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}
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}
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.
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.
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
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.
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.
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
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.
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.
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
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.
68
Modelagem de Processos
Observação
Requisitos funcionais
69
Unidade II
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.
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;
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.
70
Modelagem de Processos
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
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
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
Modelagem de Processos
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
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
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.
Resposta: Alternativa A.
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
Modelagem de Processos
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.
UNIDADE II
Questão 2
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.
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.
Unidade III
5 MODELAGEM COMPORTAMENTAL (MODELO DINÂMICO)
5.1 Introduçã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 atividades: que descreve os passos a serem percorridos para a conclusão de uma atividade.
— 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 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.
Lembrete
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).
• 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
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.
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
• atores;
Faz login
Usuário <<extend>>
Registra
Usuário
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
Modelagem de Processos
Cliente
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
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
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.
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
UML Superestrutura Especificação, versão 2.1.1, p. 584.
79
Unidade III
Receber
Pagamento
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.
• 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 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).
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.
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”.
A B
<<extend>>
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
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.
A B
<<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.
Receber Emitir
pagamento <<include>> recibo
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.
• inclusão revela comportamentos utilizados por mais que um caso de uso (reuso 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
Modelagem de Processos
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.
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
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
84
Modelagem de Processos
Ferramentas Case:
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”.
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.
• 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.
• 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.
• 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).
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.
86
Modelagem de Processos
Requisitos funcionais
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.
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
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 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 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.
• Caminho básico:
— Descrição (passos):
• Caminho alternativo:
— Descrição (passos):
5. Vendedor responsável entra com dados da zona de venda/ setor de vendas a serem alterados.
• Caminho alternativo:
— Descrição (passos):
1. Vendedor responsável entra com filial/zona de venda ou setor de vendas que quer
excluir.
• Caminho alternativo:
— Nome: erros.
— Descrição (passos):
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
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.
92
Modelagem de Processos
Avaliar item
em estoque
Registrar
pedido
Autorizar forma
de pagamento OK?
Cancelar Aceitar
pedido pedido
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.
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.
telefone ocupado ( )
telefone toca ( )
som da campainha ( )
atenda telefone ( )
telefones interligados ( )
telefones interligados ( )
pessoa chamada desliga ( )
conexão desfeita ( )
conexão desfeita ( )
chamador desliga ( )
94
Modelagem de Processos
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.
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.
O diagrama de estados representa, para uma determinada classe de objetos, seu padrão de eventos,
estados e transição de estados.
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
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
Modelagem de Processos
Pseudo_estado_inicial
Estado_composto
Estado_simples
Est_simples 1 Est_simples 2
Pseudo_estado_final
6.4.3 Evento
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.
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.
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.
Partida_aviões Botão_do_mouse_
levantado
Empresa_aerea
Número_do_voo Botão
Cidade_destino localização
Altera_destino()
6.4.4 Transição
t (objeto)
Evento 1 Evento 2
A Figura 56 mostra um exemplo de eventos para uma classe conta de cliente de um banco.
98
Modelagem de Processos
Inativa
Depósito_Cliente
Depósito_Aceito
Ativa
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.
Cadastramento
Saiba mais
99
Unidade III
Resumo
100
Modelagem de Processos
Exercícios
A) Na UML, o modelo de caso de uso é importante, já que auxilia na captura de requisitos do sistema
que será construído.
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.
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
MODELAGEM DE PROCESSOS
UNIDADE III
Questão 2
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.
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.
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.
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.
Qual a prioridade?
Quais os procedimentos?
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.
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
Modelagem de Processos
Observação
Lembrete
Observação
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.
Função de negócio
Atividade de negócio
Atividade componente
do processo
Processo de negócio
Subprocesso
componente de processo
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
106
Modelagem de Processos
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:
107
Unidade IV
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.
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.
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.
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.
109
Unidade IV
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.
...
SI1 SI2 SIn
RC1 RCn
TI
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.
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.
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.
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.
111
Unidade IV
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.
112
Modelagem de Processos
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.
Proposta
de software
Engenharia de Engenharia
processo de negócio de software
Modelo de negócio
113
Unidade IV
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.
• 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.
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
114
Modelagem de Processos
• 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.
• 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.
A OCL é suportada para os seguintes tipos de diagramas da UML 2.0, como mostrta a quadro 10.
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
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:
• 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
Modelagem Análise
de negócio
Implantação
Design
Teste Implementação
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
Modelagem de Processos
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).
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).
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.
Fases
Disciplinas Iniciação Elaboração Construção Transição
Modelagem de negócios
Requisitos
Concentração
de esforços nas
fases iniciais.
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
Modelagem de Processos
Saiba mais
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.
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.
119
Unidade IV
• 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.
• usam recursos;
• possuem um número de atividades, realizadas em alguma ordem, que podem ser vistas como
subprocessos;
<<processo>>
Processo A
120
Modelagem de Processos
• Diretas: diretamente envolvidas na criação do produto ou serviço, que é o valor criado pelo
processo.
<<processo>>
Furação
<<processo>>
Fazer furo
Ler Ligar Furar
Calibrar instrução furadeira
<<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
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
A notação de Erikson e Penker ainda hoje é utilizada, e algumas ferramentas Case, tal como a
ferramenta EA, mantêm essa notação.
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.
122
Modelagem de Processos
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:
• definição de workflow;
• regras de negócio;
• integradores;
• 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.
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
• fluxo de execução;
• regras;
• eventos;
De acordo com vários autores, um BPMS completo teria os seguintes módulos ou funcionalidades:
— Repositório de metadados;
124
Modelagem de Processos
• objetos de fluxo;
• objetos de conexão;
• raias (swimlanes); e
• artefatos.
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
125
Unidade IV
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
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.
• 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.
• 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
UML Superestrutura Especificação, versão 2.1.1, p. 318.
126
Modelagem de Processos
• 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).
Atividade Sub_processo
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.
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.
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
Um fluxo de sequência é usado para mostrar a ordem (sequência) que as atividades são realizadas
em um processo.
BPMN BPMN
Fluxo de sequência
Atividade 1 Atividade 2
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
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.
Documento
Activity2
IntermediateEvent3
Figura 74 – Associação
128
Modelagem de Processos
class BPMN
No
EndEvent
StartEvent
Repeat for Each Supplier
Limite do tempo excedeu
Evento intermediário
Marca que mostra que o para um time out
subprocesso tem loop
• Pool;
• Lane.
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
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
A figura 78 mostra um exemplo de um BDP com duas pools, sendo que essas somente possuem uma
lane cada.
130
Modelagem de Processos
class BPMN
remédios
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.
• 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
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
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
132
Modelagem de Processos
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
Resumo
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.
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.
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.
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.
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.
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
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
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
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
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.
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
MODELAGEM DE PROCESSOS
UNIDADE IV
Questão 2
Resposta correta: C.
Justificativa