Modelagem Processos

Modelagem de Processos
Autor: Prof. Dr. Ivanir Costa

Colaboradores: Prof. Roberto Macias
Profa. Elisngela Mnaco de Moraes
Prof. Emanuel Augusto Severino de Matos
Professor conteudista: Dr. Ivanir Costa

Doutor em Engenharia de Produo pela Escola Politcnica da Universidade de So Paulo (USP, 2003) e mestre
em Engenharia de Produo pela Universidade Paulista (UNIP), ps-graduado em Sistemas de Informao pela UNIP,
graduado em Fsica pela USP. Professor titular do programa de mestrado e doutorado da UNIP em Engenharia de
Produo, onde realiza orientao para alunos doutorandos, mestrandos e da iniciao cientfica na graduao.
Professor da EAD na UNIP, nas disciplinas de Qualidade de Software e Sistemas de Informao. Orientador de alunos de
mestrado do IPT (Instituto de Pesquisas Tecnolgicas) da USP, professor do curso Gesto da Tecnologia da Informao,
MBA da FIA/FEA. Possui dezenas de publicaes na rea de Engenharia de Produo e Tecnologia da Informao
no Brasil e no exterior. consultor h mais de 30 anos em Tecnologia da Informao, com nfase em Engenharia
de Software e Qualidade de Software, atuando principalmente nos seguintes temas: desenvolvimento de software,
metodologia de desenvolvimento, mtricas de software, mtodos geis, produo de software, qualidade de software
e governana de TI.
Dados Internacionais de Catalogao na Publicao (CIP)

C837m
Costa, Ivanir
Modelagem de processos / Ivanir Costa. So Paulo: Editora
Sol, 2012.
144 p., il.
Notas: este volume est publicado nos Cadernos de Estudos e
Pesquisas da UNIP, Srie Didtica, ano XVII, n. 2-066/12, ISSN 1517-9230.
1. Tecnologia da informao. 2. Modelagem de processos. 3.
Modelagem comportamental. I. Ttulo.
CDU 65.011.56
Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida por qualquer forma e/ou
quaisquer meios (eletrnico, incluindo fotocpia e gravao) ou arquivada em qualquer sistema ou banco de dados sem
permisso escrita da Universidade Paulista.
Prof. Dr. Joo Carlos Di Genio

Reitor
Prof. Fbio Romeu de Carvalho

Vice-Reitor de Planejamento, Administrao e Finanas
Profa. Melnia Dalla Torre

Vice-Reitora de Unidades Universitrias
Prof. Dr. Yugo Okida

Vice-Reitor de Ps-Graduao e Pesquisa
Profa. Dra. Marlia Ancona-Lopez

Vice-Reitora de Graduao
Unip Interativa EaD

Profa. Elisabete Brihy
Prof. Marcelo Souza
Prof. Dr. Luiz Felipe Scabar
Prof. Ivan Daliberto Frugoli
Material Didtico EaD

Comisso editorial:

Dra. Anglica L. Carlini (UNIP)

Dra. Divane Alves da Silva (UNIP)

Dr. Ivan Dias da Motta (CESUMAR)

Dra. Ktia Mosorov Alonso (UFMT)

Dra. Valria de Carvalho (UNIP)
Apoio:

Profa. Cludia Regina Baptista EaD

Profa. Betisa Malaman Comisso de Qualificao e Avaliao de Cursos

Projeto grfico:

Prof. Alexandre Ponzetto
Reviso:
Virgnia Bilatto
Amanda Casale
Sumrio
APRESENTAO.......................................................................................................................................................7
INTRODUO............................................................................................................................................................7
Unidade I
1 A Linguagem Unificada de Modelos...............................................................................................11

1.1 Introduo.................................................................................................................................................11
1.2 Motivao para o uso de modelos................................................................................................. 12
1.3 Princpios da modelagem de software......................................................................................... 14
1.4 Modelagem e orientao a objetos............................................................................................... 15
1.5 Por que usar a orientao a objetos?............................................................................................ 16
1.6 Conceitos bsicos da orientao a objetos................................................................................. 22
2 a linguagem unificada de modelos (uml)................................................................................. 28
2.1Introduo................................................................................................................................................. 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 Introduo................................................................................................................................................ 43
3.2 Viso 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/instncias.............................................................. 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 Introduo................................................................................................................................................ 51
4.2 Associao................................................................................................................................................ 53
4.3 Papis em associao........................................................................................................................... 55
4.4 Classe de associao............................................................................................................................ 56
4.5 Agregao e composio................................................................................................................... 58
4.6 Generalizao/especializao........................................................................................................... 59
4.7 Herana..................................................................................................................................................... 60
4.8 Conceitos avanados envolvendo classes................................................................................... 63
4.8.1 Herana mltipla..................................................................................................................................... 63

4.8.2 Classes abstratas...................................................................................................................................... 65
4.8.3 Polimorfismo (ocultamento de informaes).............................................................................. 66

4.8.4 Interfaces tipos e papis....................................................................................................................... 67
4.8.5 Pacotes lgicos......................................................................................................................................... 67
4.8.6 Objetivos do diagrama de classes..................................................................................................... 68
4.9 Estudo de caso aplicando modelo de classes............................................................................ 68

4.9.1 Descrio 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 DINMICO).............................................................. 76

5.1 Introduo................................................................................................................................................ 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 Introduo................................................................................................................................................ 91
6.2 Diagrama de atividades...................................................................................................................... 92
6.3 Diagrama de sequncia....................................................................................................................... 93
6.3.1 Linha de vida............................................................................................................................................. 95
6.3.2 Ativao....................................................................................................................................................... 95
6.3.3 Autodelegao.......................................................................................................................................... 95
6.3.4 Mensagem.................................................................................................................................................. 95
6.4 Diagramas de estado (mquina de estado)................................................................................ 96

6.4.1 Estado........................................................................................................................................................... 96
6.4.2 Notaes...................................................................................................................................................... 96
6.4.3 Evento........................................................................................................................................................... 97
6.4.4 Transio...................................................................................................................................................... 98
Unidade IV
7 MODELAGEM DA ARQUITETURA DE NEGCIO..................................................................................103

7.1 Introduo..............................................................................................................................................103
7.2 Modelagem de negcio....................................................................................................................104
7.2.1 Conceitos de negcio...........................................................................................................................105
7.2.2 Extenso de negcio da UML............................................................................................................ 110
7.2.3 Vises de modelos de negcio.........................................................................................................114
7.3 OCL e sua utilizao na modelagem de processo de negcio.......................................... 114

7.4 Integrao com o desenvolvimento de software................................................................... 116
7.4.1 Processo de desenvolvimento de software.................................................................................116

7.4.2 Arquitetura de negcio e arquitetura de software..................................................................117
8 A modelagem de processos de negcio................................................................................... 119

8.1 Viso Erikson e Penker....................................................................................................................... 119
8.2 A modelagem de processos de negcio com a BPM............................................................122
8.2.1 Objetos de fluxo.................................................................................................................................... 125

8.2.2 Objetos de conexo.............................................................................................................................. 127
8.2.3 Raias (Swimlanes)................................................................................................................................. 129
8.2.4 Artefatos....................................................................................................................................................131
8.3 Concluso do BPMN..........................................................................................................................133
APRESENTAO
O objetivo da disciplina Modelagem de Processos apresentar e conceituar a importncia de modelos

no desenvolvimento de sistemas de informao.
Nela, os alunos tero condies 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 estticos como os modelos dinmicos.
A disciplina tambm apresenta os conceitos e simbologias envolvidos com a modelagem das reas
de negcio, bem como os mapeamentos de negcios por meio da UML e da moderna linguagem de
modelagem de negcios BPMN (Business Process Modeling Notation).
INTRODUO
Entre os autores e especialistas envolvidos com os processos de desenvolvimento de software, existe

a crena de que, de algum modo, a modelagem pode ser aplicada para facilitar a nossa vida.
Desde a dcada de 1970, os autores especializados em software vm propondo processos ou
metodologias de desenvolvimento de sistemas que, apesar de utilizarem abordagens diferentes, sempre
possuem em seu bojo o uso de modelos visuais e descritivos. Isso fundamentado no fato de que
os modelos visuais permitem o entendimento do mesmo assunto por pessoas com conhecimentos e
perfis diferentes. A importncia desse entendimento torna-se primordial, j que no processo de software
temos a participao de pessoas de diversas reas de uma organizao, indo do usurio final de uma
rea de negcio at o especialista em software e hardware da rea de TI.
Todavia, ao longo desse tempo, a modelagem de software vem sendo criticada devido percepo
de que a modelagem uma atividade que precede o desenvolvimento real e que tem como foco a
documentao. Isto , para muitos especialistas, no se deve privilegiar o desenho ao prprio
desenvolvimento. Essas crticas vieram principalmente dos defensores dos mtodos geis, que privilegiam
o cdigo em vez da documentao.
Outros autores, entretanto, insistem que a modelagem deve ser reconhecida como uma tarefa de
desenvolvimento central importante. Quando os modelos so considerados parte das atividades do
processo de desenvolvimento e geram artefatos de primeira classe, os desenvolvedores geram menos
cdigo convencional, uma vez que abstraes de aplicativo mais poderosas podem ser empregadas.
Dessa forma, quando os modelos abrangem as atividades de desenvolvimento, a comunicao entre
as pessoas envolvidas pode ser otimizada e a capacidade de rastreamento ativada no ciclo de vida em
qualquer direo. A otimizao tambm vem do fato de que os modelos podem ser fontes de reuso
tanto dos objetos criados como das descries que os envolvem.
Acredita-se que tornar a modelagem uma corrente predominante dentro da rea de desenvolvimento
de sistemas de uma organizao pode levar a uma economia de recursos e, com isso, aumentar a
7
abrangncia de automao no atendimento das necessidades de uma empresa. A automao do processo

de desenvolvimento com o uso de geradores de sistemas a partir de modelos construdos tende a ser
uma realidade a mdio e longo prazos no processo de software.
Pode-se citar, dentro dessa realidade, a Microsoft, que emitiu um documento denominado de
Estratgia de modelagem em 2005, que aborda o desenvolvimento dirigido por modelo dentro de
uma iniciativa chamada Fbricas de Software.
Existem diversas empresas, rgos e grupos que adotam e propem 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 adoo ocorreu em um evento histrico e marcante, pois assinalou a aceitao de uma linguagem
padronizada de modelagem de sistemas baseada nas melhores prticas atuais para a anlise, o projeto
e a construo de software orientado a objetos.
A UML, tema central desta disciplina, a primeira notao que atingiu o consenso entre a maioria
dos profissionais, vendedores e acadmicos como o padro real para expressar um domnio comercial
da soluo de software. Entre os autores da UML, temos o americano Grady Booch, que diz que a
modelagem deve atingir quatro objetivos para se tornar efetiva em um ambiente de desenvolvimento
de software:
1. Ajudar a equipe de projeto a visualizar um sistema como ele ou pretende ser.
2. Ajudar a especificar a estrutura ou o comportamento do sistema.
3. Proporcionar um modelo que sirva de guia na construo do sistema.
4. Documentar as decises tomadas pela equipe de desenvolvimento de projeto.
A UML precisa desses objetivos para ser efetiva (REED Jr., 2000).
Ela apresentada tanto nos seus modelos estticos como nos modelos dinmicos que mostram as
estruturas e os comportamentos dos objetos envolvidos em uma determinada aplicao ou software
nos modelos da tecnologia orientada a objetos.
Na atualidade, outra rea de interesse e importante na construo de sistemas fundamentais a
de processos de negcio, que se prope a mostrar as atividades previamente estabelecidas nas reas de
negcio e determinar a forma como o trabalho realizado numa organizao.
Essas atividades de negcio constituem um conjunto de aes relacionadas entre si de forma lgica
e coerente, a fim de promover uma sada favorvel organizao, em nveis interno e externo. Uma
boa modelagem dos processos de negcio leva implementao de um sistema de informao bemestruturado.
8
A disciplina aborda os conceitos de modelos, a importncia da modelagem de sistemas de informao,

a tecnologia orientada a objetos e as modelagens UML e BPM no processo de desenvolvimento de
software.
Unidade I
1 A Linguagem Unificada de Modelos
1.1 Introduo
Existe uma crena, entre os envolvidos no desenvolvimento de software, de que, de algum modo, a
modelagem pode ser aplicada para facilitar as suas vidas.
Todavia, ao longo do tempo, a modelagem de software vem sendo criticada devido
percepo de que uma atividade que precede o desenvolvimento real e que tem como foco a
documentao.
Outros autores insistem que a modelagem deve ser reconhecida como uma tarefa de desenvolvimento
central importante e no uma atividade focada principalmente em documentao.
Quando os modelos so considerados artefatos de desenvolvimento de primeira classe, os
desenvolvedores geram menos cdigo convencional, uma vez que abstraes de aplicativo mais
poderosas podem ser empregadas.
Assim, o desenvolvimento dirigido por modelo inerentemente mais produtivo e gil. Alm
disso, outros participantes no desenvolvimento como analistas de negcios, arquitetos e gerentes
de projetos, iro reconhecer a modelagem como o que adiciona valor s tarefas pelas quais so
responsveis.
Quando os modelos abrangem as atividades de desenvolvimento e em tempo de execuo dessa
maneira, a comunicao entre as pessoas pode ser otimizada, e a capacidade de rastreamento ativada
no ciclo de vida em qualquer direo.
Acredita-se que, ao tornar a modelagem uma corrente predominante, pode-se alterar a economia
do desenvolvimento de softwares e garantir que os sistemas de software atendam s necessidades de
uma empresa.
De acordo com a Microsoft, em seu documento denominado de Estratgia de modelagem, de 2005,
essa abordagem do desenvolvimento dirigido por modelo parte de uma iniciativa chamada Fbricas
de software.
11
Unidade I
Saiba mais
Vale a pena ler o artigo de maio de 2005, disponvel no site
<http://msdn.microsoft.com/pt-br/library/ms379623(v=vs.80).aspx>,
que discute a estratgia de desenvolvimento da Microsoft, dirigido
por modelos com uma srie de perguntas e respostas relativas a esses
tpicos e interesses. Esse artigo basicamente pergunta e responde:
por que modelagem? Como as DSLs so usadas no desenvolvimento
dirigido por modelo? E quanto UML? E quanto MDA? O que so
fbricas de software?
1.2 Motivao para o uso de modelos
Ainda de acordo com a Microsoft, um modelo deve ser um artefato de primeira classe em um
projeto, no apenas uma documentao aguardando para se tornar desatualizada.
O autor Senge (1990):
1. Define que modelos so mentais, so pressuspostos profundamente arraigados, generalizaes,
ou mesmo imagens que influenciam a forma de ver o mundo e de nele agir. Muitas vezes,
no estamos conscientes de nossos modelos mentais ou de seus efeitos sobre nosso
comportamento.
2. Afirma que o trabalho com modelos mentais inclui tambm a capacidade de realizar
conversas ricas em aprendizados, que equilibrem indagao e argumentao, em que as
pessoas exponham de forma eficaz seus prprios pensamentos e estejam abertas influncia
dos outros.
3. Os modelos possuem uma sintaxe precisa, geralmente so melhores editados e visualizados com
uma ferramenta grfica e contm semnticas que determinam como conceitos especficos de
domnio mapeiam para outros artefatos de implementao, como: cdigo, estruturas de projeto
e arquivos de configurao.
4. Dessa maneira, um modelo se parece muito com um arquivo de cdigo-fonte, e os mecanismos
que o sincronizam com outros artefatos de implementao so muito semelhantes a compiladores.
5. Um modelo representa um conjunto de abstraes que d suporte a um desenvolvedor em um
aspecto de desenvolvimento bem definido.
6. Como os modelos podem abstrair e agregar informaes de uma srie de artefatos, podem dar
suporte de modo mais rpido a verificaes de consistncia e outras formas de anlise.
12
Observao
Um modelo de conectividade de aplicativos, por exemplo, poder
suportar validao de protocolo de contrato, anlise de segurana ou
anlise de desempenho.
Um modelo uma representao ou interpretao simplificada da realidade, ou uma interpretao
de um fragmento de um sistema segundo uma estrutura de conceitos.
Um modelo apresenta apenas uma viso ou cenrio de um fragmento do todo. Normalmente, para
estudar um determinado fenmeno complexo, criam-se vrios modelos.
Observao
Por exemplo, pode-se citar obras da Engenharia civil, tais como, uma
grande obra hidrulica, uma ampliao de uma praia artificial ou mesmo
uma usina hidreltrica, no so projetadas sem estudos detalhados em
vrios tipos de modelos matemticos de diversas categorias e tipos, como
modelos de hidrologia, hidrulica e mecnica dos solos.
Modelagem tambm pode ser vista como a arte de criar moldes tanto em fundio (nesse caso, os
de areia), como em calados e em confeco de peas para o vesturio. No caso dessa ltima, o molde
obtido por uma das trs tcnicas bsicas: moulage, modelagem geomtrica ou simples cpia.
Segundo os autores Huckvale e Ould (1993, apud BRANCO, 2007), um modelo aplicado a processos
oferece:
Um meio para discusso: o modelo de processos ajuda a situar as questes relevantes ao permitir
a abstrao do mundo real, salientando os objetos e relacionamentos que so de interesse e
ignorando detalhes que possam contribuir para aumentar a complexidade.
Um meio para comunicao: permite que outras pessoas, que no as envolvidas no desenvolvimento
do modelo, possam utiliz-lo como base para a sua implementao ou para a concepo de novos
modelos.
Uma base para anlise: a anlise de um modelo pode revelar os pontos fortes e fracos do processo,
com especial relevncia para os fracos, como aes que acrescentam pouco valor ou so potenciais
focos de problemas.
A anlise por simulao e animao do modelo permite, ainda, estudar os efeitos que possveis
alteraes podem causar em um dado processo.
13
Unidade I
Uma base para concepo de novos processos.
Uma base para melhoria contnua: as sugestes para a mudana podem ser expressas em termos
de alteraes ao modelo e da sua anlise, sendo possvel ainda sugerir mtricas para avaliar o seu
desempenho.
Uma base para controle: quando suficientemente formal para ser automatizado, o modelo pode
ser utilizado para controlar a execuo do sistema modelado, como em um sistema de gesto de
Workflow.
Alm de garantir o correto funcionamento, permite efetuar medies quanto ao desempenho do
processo.
1.3 Princpios da modelagem de software
A modelagem de sistemas de informao (software) a atividade de construir modelos que expliquem

as caractersticas ou o comportamento de um software ou aplicativo, ou de um sistema de software.
Na construo do software, os modelos podem ser usados na identificao das caractersticas e
funcionalidades que o esse dever prover e no planejamento de sua construo.
Frequentemente, a modelagem de software usa algum tipo de notao grfica e apoiada pelo uso
de ferramentas de apoio denominadas de ferramentas Case.
Ferramentas Case (Computer-Aided Software Engineering) uma classificao que abrange todas
as ferramentas baseadas em computadores que auxiliam atividades de Engenharia de software, desde
anlise de requisitos e modelagem at programao e testes.
Podem ser consideradas como ferramentas automatizadas que tm como objetivo auxiliar o
desenvolvedor de sistemas em uma ou vrias etapas do ciclo de desenvolvimento de software.
A modelagem de software normalmente implica a construo de modelos grficos que simbolizam
os artefatos dos componentes de software utilizados e os seus inter-relacionamentos.
Uma forma comum de modelagem de programas procedurais (no orientados a objeto) por meio
de fluxogramas, enquanto que a modelagem de programas orientados a objeto normalmente usa a
linguagem grfica de modelos UML.
Observao
Vale a pena, para quem ainda no conhece ou utilizou uma
ferramenta Case, fazer download de uma ferramenta free, tais como a
ferramenta JUDE ou a ferramenta Umbrello UML, e com elas verificar
14
uma srie de propriedades e facilidades que ajudam na documentao,
facilitam a comunicao e ainda aumentam de forma considervel
a produtividade dos desenvolvedores de software. Algumas so to
sofisticadas que chegam a gerar cdigo diretamente dos modelos
construdos.
1.4 Modelagem e orientao a objetos
De acordo com vrios autores, h muito tempo busca-se um padro de construo de software
orientado a objetos e sua representao, semelhana da planta utilizada por outras reas da Engenharia,
tal como a planta de uma casa ou arquitetura de um prdio da Engenharia Civil.
O enfoque tradicional de modelagem para a construo de sistemas de informao baseia-se na
compreenso desse sistema como um conjunto de programas que, por sua vez, executam processos
sobre dados.
O enfoque de modelagem por objetos v o mundo como uma coletnea de objetos que interagem
entre si e apresentam caractersticas prprias, que so representadas pelos seus atributos (dados) e
operaes (processos) (FURLAN, 1998).
A figura 1 mostra o enfoque baseado em sistema versus o enfoque baseado em objetos.
Programa
Classe
Processos
Atributos
Dados
Operaes
Foco em sistema
Foco em objeto
Figura 1 Sistema vs. objeto
Um programa, no sentido tradicional agora, um conjunto de objetos que se relacionam para

executar as funcionalidades ou processos do sistema aplicativo. Ento, o programa representado por
classes; os processos, por operaes ou mtodos; e os dados, por atributos dos objetos.
Essa mudana 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 caractersticas prprias que podem ser
representadas pelos seus atributos e pelos seus comportamentos no mundo real.
Furlan (1998) informa que essa abordagem oferece como principais benefcios:
manter a modelagem do sistema e, em decorrncia, sua automao o mais prximo possvel de
uma viso conceitual do mundo real;
servir de base decomposio e modelagem do sistema nos dados, que o elemento mais estvel
de todos aqueles que compem um sistema de informao;
oferecer maior tranparncia na passagem de modelagem para a construo por meio da introduo
de detalhes, no requerendo uma reorganizao do modelo.
Lembrete
Embora o termo orientao a objetos tenha sido usado de vrias
formas distintas, deveria sempre sugerir uma associao entre coisas do
mundo real e trechos de programas de computador ou objetos.
De uma maneira mais informal, objeto pode ser visto ou entendido como uma entidade independente,
assncrona e concorrente.
Diz-se que um objeto sabe coisas, isto , armazena dados; objeto realiza trabalho, isto , encapsula
servios; objeto colabora com outros objetos por meio de troca de mensagens, para executar as funes
finais do sistema, sendo modelado.
James Rumbaugh (1994) define orientao a objetos como:
[...] uma nova maneira de pensar os problemas utilizando modelos
organizados a partir de conceitos do mundo real.
O componente fundamental o objeto que combina estrutura e
comportamento em uma nica entidade (RUMBAUGH, 1994).
1.5 Por que usar a orientao a objetos?
Dentre as vrias razes pode-se citar:

Inconsistncia na viso dos modelos:
Diferentemente das outras tecnologias de desenvolvimento, o mesmo conjunto de modelos na
OO utilizado em todo o ciclo de desenvolvimento.
16
Os objetos so:
Descobertos na fase de anlise de sistemas para representar os requisitos do usurio.
Alterado na fase de projeto para incorporar as caractersticas do ambiente operacional do
sistema.
E finalmente utilizado na fase de construo para subsidiar a implementao nas linguagens
OO e nos gerenciadores de banco de dados.
Objetos definidos na anlise tm representao direta no cdigo, evidenciando a relao entre
a definio do problema e a sua implementao.
Melhor abstrao do domnio do problema:
A OO mantm uma forte coeso entre a estrutura e o comportamento dos objetos, e essa a
maneira como a realidade se manifesta.
Facilidade para reusabilidade:
A grande procura da Engenharia de software nos ltimos anos foi uma forma, ou um mtodo
que possibilitasse o reuso de cdigo, prometida por todos, mas nunca alcanado.
A OO, com a implementao do conceito de generalizao e especializao, a partir da herana,
possibilitam isto.
Melhor suporte integridade:
Interao entre os componentes OO restrita a poucas interfaces que so bem definidas.
A nica forma de comunicao entre os objetos se d por meio de troca de mensagens.
Suporte decorrencial concorrncia:
A sincronizao de suas partes pode ser mostrada por meio de diagramas e da passagem de
mensagens entre os objetos do sistema.
Uso de herana:
Identifica e aproveita os pontos comuns dos dados e servios (operaes, rotinas, mtodos).
Herana sinnimo de reusabilidade.
A orientao a objetos oferece modularidade de seus elementos, podendo-se tomar um subconjunto
existente e integr-lo de uma maneira diferente em outra parte do sistema.
17
Unidade I
Afirma-se que, dessa forma, uma aplicao (sistema) no universo de objetos consiste de um conjunto
de blocos de construo autocontidos e predefinidos que podem ser localizados, reparados ou substitudos.
Lembrete
Uma das coisas mais importantes da modelagem orientada a objetos est
na reusabilidade. As tcnicas de orientao a objetos permitem reutilizar
muito mais do que o cdigo. Com os modelos orientados a objetos, pode-se
reutilizar requisitos, anlise, projeto, planejamento de testes, interfaces de
usurios e arquiteturas.
Praticamente todos os componentes do ciclo de vida da Engenharia de software podem ser
encapsulados como objetos reusveis (YOURDON, 1998).
A essncia da anlise e do desenho orientados a objetos de uma aplicao de software a descrio
de comportamentos. Modelos dinmicos so utilizados para implementar os comportamentos que
atendem s necessidades e metas do usurio.
As disciplinas de anlise e de desenho com objetos apresentam tcnicas utilizadas para separar e
encapsular os comportamentos das aplicaes de software.
Os diferentes modelos elaborados durante a anlise e o desenho so utilizados de acordo com a sua
natureza:
Modelo dinmico: descreve os comportamentos exibidos pelo computador, quando esse realiza os
servios solicitados pelo usurio.
Modelo esttico: descreve a estrutura lgica do computador, de modo que ele se comporte de
maneira adequada, e gerencia as dependncias entre as diversas partes lgicas do computador.
A modelagem orientada a objetos inicia-se com a anlise orientada a objetos (AOO), que estabelece o
comportamento fundamental de um sistema, comportamento que pode ser mantido independentemente
de como o sistema ser construdo.
Na anlise OO, so construdos modelos formais de um sistema de software proposto (semelhante
aos modelos em escala de um prdio feitos por um arquiteto ou engenheiro civil), que capturam os
requisitos essenciais do sistema.
Esse modelo deve ser documentado em uma notao ou linguagem simblica, de preferncia
conhecida e testada no mercado de software.
Um modelo de AOO retrata objetos que representam um domnio de aplicao especfico, juntamente
com diversos relacionamentos estruturais e de comunicao.
18
De acordo com Yourdon (1998), o modelo de AOO serve para dois propsitos: primeiro, para formalizar
a viso do mundo real dentro do qual o sistema de software ser construdo; 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 vises, conforme a figura 2, que
permitem visualiz-lo de perspectivas distintas.
Nome da camada
Classes e objetos
Smbolos
Bordas da classe
Borda da instncia (objeto)
Atributos
Atributos
Servios
Conexo entre
objetos
Mensagens
Servios
Estruturas
Assuntos
Assuntos
Figura 2 Estrutura de um modelo de AOO
A camada de classes e objetos apresenta os blocos bsicos de construo do sistema proposto. Os

objetos so abstraes de conceitos do domnio de aplicao do mundo real.
O corao de qualquer AOO o processo denominado de modelagem de informaes. Na modelagem
AOO, os autores consideram como parte difcil do problema estabelecer o que so as coisas do mundo
real.
No caso de mtodos orientados a objetos, tem sido dada mais nfase na modelagem de informaes
como um procedimento formal dentro do processo de Engenharia de software (YOURDON, 1998).
A figura 3 apresenta um exemplo de aplicao da modelagem AOO com o uso da notao de Edward
Yourdon. Sero representadas as entidades envolvidas em um domnio de prestao de servios por
assinatura, como uma assinatura de tv fechada, uma assinatura telefnica etc.
O exemplo apresenta somente alguns atributos e alguns servios de um domnio de aplicao
qualquer.
19
Unidade I
Assinante
Id_assinante
Det_assinante
Id_endereco
Assinatura
1
Entrar_assinante
Informar_endereco
Id_assinatura
Estado_assinatura
Detalhes_assinatura
Entrar_assinatura
Figura 3 Exemplo de uma aplicao da AOO
Aps a modelagem completa do sistema com todas as entidades, seus atributos, seus servios e suas
estruturas comportamentais definidas (relacionamentos), deve ser construdo o Projeto Orientado a
Objetos (POO), como uma extenso do modelo AOO.
Na proposta de Edward Yourdon, o modelo POO contm as mesmas cinco camadas e usa a
mesma notao do modelo AOO, mas estendido para conter: componente de interao humana
(interface homem x mquina), componente de gerenciamento de tarefas e componente de
gerenciamento de dados.
O componente de interao humana modela a tecnologia de interface que ser usada para uma
implementao especfica do sistema.
O componente de gerenciamento de tarefas especifica os itens operacionais que sero
estabelecidos para implementar o sistema. Finalmente, o componente de gerenciamento de dados
define aqueles objetos necessrios para interfacear com a tecnologia de banco de dados que est
sendo usada.
Alm da abordagem de Edward Yourdon, outros mtodos e modelagens orientadas a objetos
apareceram desde a dcada de 1970 at 1995. A seguir, algumas das iniciativas desse perodo:
Sally Shlaer e Steve Mellor escreveram livros sobre anlise e desenho orientado a objetos no final
da dcada de 1980 e incio da dcada de 1990.
Jim Odell e James Martin basearam seus enfoques na longa experincia adquirida por ambos
no uso e divulgao da Engenharia da informao. Em 1994 e 1996, lanaram 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 laboratrios da General Electric, que o
levou ao livro sobre mtodos chamados OMT (Object Modeling Technique) em 1991.
20
Grady Booch desenvolveu um mtodo na Rational Software para anlise 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 experincia em sistemas na Ericson e desenvolveu
o mtodo OOSE (Object-Oriented Software Engineering), que se tornou a base do processo UP e
do processo RUP.
Toda a proposta est na procura da independncia de tecnologia e, portanto, a busca da reusabilidade.
Se um dia for necessrio trocar a tecnologia envolvida com as interfaces GUI por outra tecnologia mais
atual, seria necessrio substituir apenas o componente de interao humana.
A histria da OO inicia-se no final da dcada de 1960, com a linguagem Simula, que foi projetada
por Kristen Nygaard e Ole-Johan Dahl no centro de computao noruegus, em Oslo.
No incio da dcada de 1970, os cientistas da computao Edsger Dijkstra e David Lorge Parnas
trabalharam no conceito de programao modular, que um importante elemento da programao
orientada a objetos nos dias de hoje.
Tambm na dcada de 1970, surge a linguagem Smalltalk:
Uma linguagem de programao orientada a objeto fracamente tipada. Em Smalltalk, tudo
objeto: os nmeros, as classes, os mtodos, os blocos de cdigo etc.
No h tipos primitivos, ao contrrio de outras linguagens orientadas a objeto. Strings, nmeros e
caracteres so implementados como classes em Smalltalk, por isso essa linguagem considerada
puramente orientada a objetos.
Tecnicamente, todo elemento de Smalltalk um objeto de primeira ordem.
Os programadores definem classes de objetos em suas aplicaes para imitar (ou simular) o mundo
real. Essas classes de objeto so organizadas hierarquicamente, de modo que seja possvel fazer
novos objetos com caractersticas de outros objetos, com poucas mudanas.
A linguagem Smalltalk foi desenvolvida por Adele Goldberg e Alan C. Kay.
No final da dcada de 1970, surge a linguagem ADA:
Ada uma linguagem de programao estruturada, de tipagem esttica, uma linguagem
imperativa, orientada a objetos, e uma linguagem de alto nvel, originada da linguagem Pascal
e de outras linguagens.
Foi originalmente produzida por uma equipe liderada por Jean Ichbiah, da Companhia Honeywell
Bull, contratada pelo Departamento de Defesa dos Estados Unidos durante a dcada de 1970, com
o intuito de substituir as centenas de linguagem de programao usadas pelo DoD.
21
Unidade I
Ada uma aplicao com compiladores validados para uso confivel em misses crticas, tais
como softwares de aviao. Normatizada internacionalmente pela ISO, sua verso mais atual de
2005.
Em meados de 1980, o cientista da computao dinamarqus Bjarne Stroustrup criou a linguagem
C++ e, dessa forma, conhecido como o pai da linguagem de programao C++.
Stroustrup tambm escreveu o que muitos consideram a obra padro de introduo linguagem, A
linguagem de programao C++, que se encontra na terceira edio. A obra possui revista para refletir a
evoluo da linguagem e o trabalho do comit de padres de C++, e inspirou as novas linguagens, tais
como a linguagem Java e o C#.
Saiba mais
Vale a pena ler o livro de Bertrand Meyer cujo ttulo Object-oriented
Software Construction, que se tornou um clssico na rea da tecnologia
OO. O livro, apesar de ser de 1988, j apresenta um conjunto de conceitos
sobre a reusabilidade, tcnicas de projeto, programao orientada a objetos
e a aplicao das tcnicas OO em outros ambientes de desenvolvimento.
1.6 Conceitos bsicos da orientao a objetos
Os objetos podem ser vistos como blocos de construo que, combinados por meio de tcnicas
apropriadas, produzem um sistema.
Blocos de construo
Blocos de rotinas/mtodos
Tcnicas adequadas
de anlise e projeto
Anlise/
Projeto/
Construo
Sistemas
Figura 4 Objetos vistos como blocos de construo
22
A tecnologia OO apresenta diversos conceitos fundamentais para seu entendimento e aplicao
(FURLAN, 1998):
Objeto: um objeto uma ocorrncia especfica (instncia) 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 coleo de dados relacionados com um tema em comum.
Uma pessoa um objeto, um veculo um objeto, um documento um objeto.
Outros conceitos sobre objeto:
Objeto uma bolha de inteligncia que sabe agir numa determinada situao (Steve Jobs).
Objeto alguma coisa que faz sentido no contexto de uma aplicao, dependente do nvel de
abstrao do desenvolvedor do sistema.
Objetos so a base da tecnologia orientada a objetos.
Objetos podem representar coisas do mundo real: carro, gato, mquinas etc.
Entidades conceituais: conta bancria, compras, pedido etc.
Coisas visuais: polgonos, pontos, retas, letras, formulrios etc.
Objeto um conceito, uma abstrao, algo com limites ntidos e significado com relao ao
problema em causa (James Rumbaugh).
Abstrao: abstrao consiste na seleo que se faz de alguns aspectos do problema em questo,
ignorando-se outros aspectos.
Qualquer objeto real pode ser abstrado para filtrar seu estado e comportamento.
O estado de um objeto determinado pelo seu conjunto de atributos (dados), e seu
comportamento definido pelos seus servios (mtodos).
Exemplos de objetos de informtica: label, boto, caixa de texto, de dilogo etc.
Exemplos de objetos de negcio: funcionrio, departamento, produto etc.
Mensagem: objetos se comunicam a partir da troca de mensagens, isto , um sinal enviado de
um objeto a outro, requisitando um servio por meio da execuo de uma operao do objeto
chamado.
A interface lgica entre objetos feita a partir da passagem de mensagens.
23
Unidade I
As mensagens ocorrem apenas entre objetos que possuem uma associao.
Todo o processamento da OO ativado por uma implementao de mensagens que refora o
conceito de baixo acoplamento em sistemas orientados a objetos.
A recepo de uma mensagem causa a invocao de uma operao no recebedor (objeto alvo).
Esse executa o mtodo da classe que corresponde quela operao.
Uma mensagem pode tomar vrias formas: procedure, passagem de sinal entre threads ativas,
acionamento especfico de um evento etc.
Um determinado objeto, recebendo uma mensagem, executar uma ao especfica como
resposta, alterando seu estado interno, enviando mensagens a outros objetos, criando novos
objetos etc.
Objeto
cliente para o2
Objeto o1
Objeto o3
Objeto
servidor
para o2
Mensagem
de o1
para o2
Objeto o2
Objeto
cliente
para o3
01
02
aeronave
Objeto
aeronave
Flap 1
Flap
ngulo
aterrisar
ajustar ngulo
Nome da
mensagem
Objeto
Flap
Flap
ajustado
Figura 5 Troca de mensagens entre objetos
A mensagem indica uma solicitao de O1 para O2, coloque o flap num ngulo x!
Essa uma mensagem imperativa.
O objeto 02 responde que est tudo ok. Na OO, os parmetros de chamada e resposta tambm
so chamados objetos (tudo objeto).
24
Polimorfismo: o poder que uma operao de um objeto tem de assumir vrios comportamentos
dependendo da chamada recebida, tratando e devolvendo respostas especficas 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 poupana, saldo do fundo de aes, saldo de
renda fixa etc.
Ento, a operao buscar_saldo vai buscar o saldo dependendo do tipo ou parmetro da
chamada, tendo vrias lgicas diferentes para um mesmo comportamento denominado
buscar_saldo.
Classe: classe uma coleo de objetos que podem ser descritos com os mesmos atributos e as
mesmas operaes.
Representa uma idia ou um conceito simples e categoriza objetos que possuem propriedades
similares, configurando-se em um modelo para a criao de novas instncias.
uma abstrao das caractersticas comuns a um conjunto de objetos similares.
A classe pode ser pensada como sendo um tipo abstrato de dados.
Conjunto de objetos com propriedades semelhantes, mesmo comportamento (operaes,
mtodos), mesmos relacionamentos com outros objetos e mesma semntica em um domnio
de aplicao.
como se fosse um molde para criao de objetos.
A linguagem Java um conjunto de classes. Por exemplo: Panel, Label etc. Se o objeto O
pertence classe C, dizemos que:
O uma instncia de C; ou
O um membro da classe C; ou
O pertence a C.
Quando queremos ser precisos e nos referirmos a uma coisa exata, usaremos instncia de
objeto.
Para nos referirmos a um grupo de coisas semelhantes, usaremos classe de objetos.
Os objetos de uma classe compartilham um objetivo semntico comum, alm dos requisitos de
atributos e comportamentos.
25
Unidade I
Classe
Cavalo
Classe
Celeiro
Figura 6 Exemplo de classe de objetos
Embora um celeiro e um cavalo tenham ambos um preo e uma idade, podem pertencer a
classes diferentes.
Caso sejam vistos, no problema, apenas como bens contbeis, poderiam pertencer mesma classe.
Herana: a capacidade de um novo objeto tomar atributos e operaes de um objeto existente,
permitindo criar classes complexas sem repetir cdigo. A nova classe simplesmente herda seu
nvel base de caractersticas de um antepassado na hierarquia de classe.
O propsito principal do uso de herana construir estruturas que possam ser estendidas
em muitas formas diferentes. Esse enfoque pragmtico pode-se completar considerando os
propsitos de reusabilidade a vrios nveis e os propsitos 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 situao diferente
da original para o qual foi criado, reduzindo e simplificando esforos (MATICH e CARVALHO,
1992).
A herana tem implicitamente um propsito de reusabilidade, j que proporciona uma forma
de reaproveitar caractersticas capturadas por componentes, seja na forma de objetos, tipos ou
classes.
Atributo ou propriedade: caracterstica particular de uma ocorrncia da classe, por exemplo: o
aluno possui nome, sexo, data de nascimento, nmero de registro, telefone etc.
Caracterstica que um objeto possui. Exemplo: nome, cor, altura, data de nascimento etc.
Conjunto de propriedades de um objeto que definem o seu estado.
Propriedades estticas: mantm o mesmo valor durante toda a sua existncia (exemplo:
data de nascimento de uma pessoa).
Propriedades dinmicas: podem ter valores que variam com o passar do tempo (exemplo:
salrio de um funcionrio).
Encapsulamento: combinao de atributos e operaes em uma classe. Exemplo: classe aluno,
com atributo nome e operao altera_nome_aluno.
26
a capacidade que possuem os objetos de incorporar tanto as estruturas de dados que os
determinam, como as operaes aplicveis a essas estruturas em nico bloco de organizao e
s permitir o acesso a elas por meio de mtodos determinados.
Vantagens do encapsulamento:
Esconder (ocultar) a complexidade do cdigo.
No necessrio conhecer como a operao feita para poder utiliz-la, o cdigo oculto
do usurio.
Proteger os dados, permitindo o acesso a eles apenas a partir de mtodos, evita que seus
dados sejam corrompidos por aplicaes externas.
Generalizao: atributos e operaes comuns, compartilhados por classes em uma hierarquia
pai-e-filho, ou superclasse e subclasses, ou classe pai e classes filho.
Instncia de classe: uma ocorrncia especfica de uma classe. o mesmo que objeto. Jos
Carlos Filho uma instncia da classe aluno, j que o Jos Carlos Filho aluno cadastrado no
sistema acadmico da escola.
Classes fabricam instncias sob requisio. Esse processo chamado instanciao.
Um objeto
Aeronave
Uma
classe
Outro objeto
Instanciao
E outro objeto
Figura 7 Instanciao
O projetista/programador cria a classe. Em tempo de execuo, a classe pode ser solicitada para
criar novos objetos.
Uma classe possui dados/atributos ou variveis (programao), servios/operaes ou mtodos
(programao).
Exemplo: quantidade de carros um atributo de classe da classe carro. Cada atributo de
classe possui um nico valor para o conjunto de objetos da classe.
27
Unidade I
Uma instncia (um membro) de uma classe tambm possui: dados/atributos ou variveis de
instncia e operaes/mtodos de instncia.
Exemplo: cor, peso e ano de fabricao so atributos de instncia da classe carro.
Cada atributo de instncia possui um valor para cada instncia de objeto. O nome de um
atributo nico dentro de uma classe.
O agrupamento de objetos em classes permite a abstrao de um problema.
As definies comuns e as operaes de cada instncia so descritas somente uma vez na
classe, e os objetos da classe podem beneficiar-se da reutilizao das definies armazenadas.
Operaes: lgica contida em uma classe para designar-lhe um comportamento. Exemplo:
calcular a idade de um aluno dada a sua data de nascimento.
Operao uma funo ou transformao que pode ser aplicada a objetos ou por esses a uma
classe em uma determinada situao.
Exemplo: alterar sua cor, mostrar uma janela, debitar um valor, aceitar o crdito de um cliente.
Todos os objetos da classe compartilham as mesmas operaes.
Mtodo a implementao de uma operao para uma classe.
O ato de invocar um mtodo tambm chamado de passar uma mensagem para o objeto.
Toda classe possui um mtodo denominado construtor: atribui valores s propriedades de um
objeto quando esse criado. o mtodo de inicializao de um objeto instanciado.
Em Java o mtodo construtor possui sempre o mesmo nome da classe.
Subclasse: caracterstica particular de uma classe. Exemplo: classe animal, subclasses gato,
cachorro etc.
2 a linguagem unificada de modelos (uml)
2.1Introduo
Antes da UML, havia uma diversidade imensa e improdutiva de abordagens de modelagem, e sua convergncia
na UML 1.0 foi um passo frente significante na utilizao de modelos no desenvolvimento de software.
Cada desenvolvedor usava a abordagem do autor de sua preferncia, que nem sempre convergiam
suas opinies em torno do tema. Outro problema era a proliferao de ferramentas grficas especficas
28
para uma determinada notao para uma metodologia OO tambm especfica e, na maioria das vezes,
proprietrias.
Ivar Jacobson, Grady Booch e Jim Rumbaugh, em 1995, tomaram a iniciativa de unificar os mtodos
OOSE (Object Oriented Software Engineering), o mtodo Booch93 e o OMT (Object Modeling Technique)
e deram o nome de UML. UML significa Unified Modeling Language e uma ferramenta para modelagem
de sistemas de todas as complexidades (MEDEIROS, 2004).
Lembrete
UML significa Unified Modeling Language (Linguagem Unificada de
Modelos) e uma ferramenta para modelagem de sistemas de todas as
complexidades, (MEDEIROS, 2004).
Em 1999, na verso 1.3, a UML passou a ser mantida pela OMG (Object Management Group), que
um grupo americano responsvel pela padronizao do uso da orientao a objetos nos Estados Unidos.
A UML firma-se ento no mercado e passa a ser um padro internacional para a especificao e
modelagem de sistemas aplicativos em todas as reas de abrangncia da rea de informtica ou TI
(Tecnologia da Informao).
A finalidade da UML proporcionar um padro para a especificao e arquitetura de projetos de
sistemas, desde os aspectos conceituais at as solues concretas, tais como, as classes de objetos,
esquemas de banco de dados e componentes de software reusveis (BOOCH; RUMBAUGH e JACOBSON,
1999).
A UML foi criada para ser independe de processo de software. Os desenvolvedores podem pegar
alguma coisa da UML que seja apropriado para seu prprio tipo de projeto e para seu prprio processo,
usando a UML para registrar os resultados de suas decises de anlise e design.
Lembrete
A garantia de ser um padro internacional levou a UML a ser adotada
pela OMG que especifica e mantm o metamodelo UML.
A especificao da UML, na OMG, definida usando-se uma abordagem de metamodelo, (isto ,
um metamodelo usado para especificar o modelo que compreende a UML), que adota tcnicas de
especificao formal.
Por outro lado, enquanto essa abordagem usa o rigor de um mtodo formal de especificao,
tambm oferece a vantagem de ser mais intuitivo e pragmtico para a maioria dos implementadores e
praticantes.
29
Unidade I
O metamodelo da UML foi projetada com os princpios de design flexvel, tendo em mente o seguinte:
Modularidade: o princpio da forte coeso e baixo acoplamento aplicado para a construo em
pacotes, que permitem organizar recursos em metaclasses.
Camadas: o conceito de camadas aplicado para o metamodelo UML.
Particionamento: o particionamento usado para organizar as reas conceituais dentro de uma
mesma camada.
Extensibilidade: a UML pode ser estendida de duas maneiras:
Um novo dialeto da UML pode ser definido por meio de perfis para personalizar o idioma
para plataformas especficas (por exemplo, (J2EE/EJB, .NET / COM +) e domnios (por exemplo,
finanas, telecomunicaes, aeroespacial).
Uma nova linguagem relacionada UML pode ser especificada por reutilizar parte do pacote e
bibliotecas de InfraEstrutura dessa.
Reutilizao: a biblioteca do metamodelo flexvel para permitir que seja reutilizada para definir
o metamodelo UML, bem como outros metamodelos arquitetnicos relacionados, tais como, o
Meta Object Facility (MOF) e o Common Warehouse Metamodel (CWM).
A infraestrutura da UML definida pela biblioteca de InfraEstrutura UML, pertencente e definida
pela OMG. A OMG uma associao internacional, aberta, sem fins lucrativos e um consrcio da indstria
de computador desde 1989.
Qualquer organizao pode participar da OMG e dos processos de definio das normas. A poltica da
OMG garante que todas as organizaes, grandes e pequenas, tenham uma voz eficaz no seu processo.
A associao inclui centenas de organizaes, sendo metade de softwares finais e a outra metade
representando praticamente todas as organizaes da indstria de computadores.
Quando metamodelamos, primeiramente distinguimos entre metamodelos e modelos. Um modelo
deve ser instanciado a partir de um metamodelo que, por sua vez, pode ser usado como um metamodelo
de outro modelo de forma recursiva.
Um modelo normalmente contm os elementos do modelo. Esses so criados instanciando-se
os elementos do modelo a partir de um metamodelo. O papel tpico de um metamodelo definir a
semntica de como os elementos do modelo em um modelo podem ser instanciados.
Como exemplo, considere-se a figura 4, em que as metaclasses Classe e Associao so ambas
definidas como parte do metamodelo UML.
30
Essas so instanciadas em um modelo de usurio ou desenvolvedor, de modo que as classes Pessoa e Carro so
as duas instncias da metaclasse Classe, e a associao entre as classes um exemplo da metaclasse Associao.
A Figura 8 mostra todos os relacionamentos entre o metamodelo e o modelo do sistema que est
sendo desenvolvido.
Metalmodelo
UML
Classe
Associao
InstnciaDe
Modelo do
sistema
Pessoa
Carro
Figura 8 Exemplo de metamodelagem (note que todos os relacionamentos so mostrados no diagrama)
A semntica da UML define o que acontece quando o usurio define os elementos que so
instanciados em seu modelo.
Saiba mais
Na atualidade, a UML encontra-se na verso 2.3 e composta de 13
diagramas. A especificao formal da UML 2.3 pode ser encontrada no
endereo <www.omg.org/spec/UML/2.3/>.
Quadro 1 Diagramas da UML
Diagramas
Nmero
UML 1.X
UML 2.3
Atividade
Atividade
Caso de uso
Caso de uso
Classe de objetos
Classe de objetos
Objetos
Objetos
Sequncia
Sequncia
Colaborao
Comunicao
Estado
Estado
Componentes
Componentes
Implantao
Implantao
10
-------------
Pacotes
11
-------------
Interao
12
-----------
Tempo
13
----------
Estrutura composta
31
Unidade I
A proposta da UML no 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 prope modelos para a fase de especificao, outros modelos para a fase de design e modelos
para o momento de se definir as lgicas dos programas ou transaes.
Todas essas formas ou modelos obedecem s regras e fundamentos da orientao a objetos na
construo de softwares.
Conforme Medeiros (2004), apesar da definio dos trs amigos, pode-se dizer que a UML uma
forma de comunicar uma idia, e busca um padro para a cincia da computao com relao
comunicao de pessoas da rea, e no uma linguagem de computador.
A UML no um processo de desenvolvimento, tais como, o modelo cascade, ou o modelo RUP
(Rational Unified Process), ou o processo gil SCRUM. uma linguagem de comunicao 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 aplicvel a diversos tipos de sistemas, dos
mais simples at os mais complexos.
Alm disso, a UML no proprietria e aberta a todos. Com a aprovao da UML em novembro de
1997 pela OMG, a guerra de mtodos OO havia chegado ao seu final.
De acordo com a UML, ela pode ser usada para:
Mostrar as fronteiras de um sistema e suas funes principais. Aqui se introduziu os conceitos de
atores e casos de uso.
Ilustrar a realizao de casos de uso com diagramas de interaes.
Representar uma estrutura esttica de um sistema utilizando diagramas de classes.
Modelar o comportamento de objetos com diagramas de transio de estado.
Revelar a arquitetura de implementao fsica com diagramas de componentes e de implantao
(deployment).
Estender sua funcionalidade a partir de esteretipos.
2.2 A UML e o Processo Unificado
Para se falar de um processo de software, necessrio alguns conceitos envolvidos com a Engenharia
de software.
32
2.2.1 Engenharia de software e processos de software
Mas o que a Engenharia de software?
A Engenharia de software pode ser conceituda como:
Uma disciplina de Engenharia voltada para todos os aspectos da produo de software de qualidade.
A Engenharia de software estuda processos, modelos e metodologias de desenvolvimento, a
gerncia de projeto de software, investigao de novos mtodos, ferramentas e teorias correlatas,
tais como, a qualidade e a produtividade.
Envolve a escolha seletiva de mtodos e ferramentas adequados para o atendimento de um
determinado contexto (restries) de sistema de computao.
Abrange todo o ciclo de vida do software, desde a especificao inicial do sistema at sua operao
e manuteno.
A Engenharia de software est baseada em pilares que lhe do sustentao. A figura 9 mostra um
esquema dessa viso da ES.
Engenharia de software(s)
Processos/
guias/prticas/
metodologias
Tcnicas
mtodos
mtricas
Ferramentas
Qualidade/
produtividade
Gerncia
governana
Figura 9 Pilares da Engenharia de software
O estudo dos mtodos/tcnicas/mtricas definem a sequncia, a simbologia e os padres em que as

atividades devem ser aplicadas no desenvolvimento e manuteno de software.
Com relao s ferramentas, a ES estuda e prope a automatizao dos mtodos e tcnicas. Essas
ferramentas de software so 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 construo de softwares de qualidade. Com as ferramentas, procura-se tambm a
melhoria da produtividade das equipes de desenvolvimento.
A gesto/gerncia/governana inclui o planejamento de projetos, controle dos projetos, alocao
de recursos, cronogramas e indicadores que apoiem na busca da garantia da qualidade dos produtos
confeccionados e no alinhamento da rea de TI com as estratgias empresariais.
33
Unidade I
Dentro dessa abrangncia da ES, um dos aspectos mais importantes o estudo dos processos
envolvidos com o software.
Saiba mais
A Engenharia de Software uma disciplina que adotada
nos cursos de Cincia da Computao, Sistemas de Informao e
Engenharia da Computao e cobre todo ciclo de vida de um sistema
ou software .
Os principais livros adotados pelos cursos so: Engenharia de software,
de Roger. S. Pressman, editado no Brasil McGraw Hill; o livro Engenharia
de software, de Ian Sommerville, editado pela Addison-Wesley; o livro
Engenharia de software teoria e prtica, de James F. Peters e Witpd
Pedrycz, editado pela Editora Campos; e o Livro Engenharia de software
fundamentos, mtdos e padres, de Wilson de Pdua Paula Filho, editado
pela LTC.
Mas, o que um processo de software?
Um processo de software um conjunto estruturado de atividades (ou fases) necessrias para
produzir um produto de software.
Um processo de software completo abrange as grandes fases de especificao, design ou projeto,
a implementao e a manuteno ou evoluo do software.
Os processos de software so organizados segundo diferentes modelos de desenvolvimento.
Quais so os modelos ou processos de software mais conhecidos?
Ao longo do tempo, desde a dcada de 1960, a Engenharia de software desenvolveu diferentes
representaes abstratas das fases de um processo de software e suas interdependncias.
Os modelos mais representativos e utilizados na Engenharia de software so:
Modelo cascata (ou clssico):
O paradigma do ciclo de vida clssico ou cascade demanda uma abordagem sistemtica e
sequencial para o desenvolvimento de software.
Comea em termos de sistema e progride por meio da anlise, design, codificao, teste e
manuteno.
34
A figura 10 mostra um esquema visual do modelo cascade ou cascata.
Engenharia de
Sistemas
Anlise
Design
Codificao
Teste
Manuteno
Figrura 10 Ciclo de vida clssico
Todavia, os projetos reais raramente seguem um fluxo sequencial que o modelo prope.
Ocorrem interaes, voltas a nveis anteriores, provocando problemas na aplicao do
paradigma clssico.
Frequentemente, os usurios tm dificuldade de estabelecer explicitamente todos os
requisitos do software, acompanhados das incertezas naturais que existem no incio de
muitos projetos.
Os usurios tem que ser muito pacientes. Uma verso do software somente estar disponvel
quando todo o sistema for definido e desenvolvido. Qualquer alterao pode ocasionar um
desastre no desenvolvimento do sistema.
Esses problemas so reais, porm o paradigma do ciclo clssico de software tem um definitivo
e importante lugar na Engenharia de software, pois ele proporciona um modelo real para o
uso dos mtodos para analisar, projetar, codificar, testar e manter softwares.
Espiral:
O modelo espiral para a ES foi desenvolvido para abranger as melhores caractersticas do
ciclo clssico, adicionando um novo elemento chamado anlise de risco.
O modelo apresenta quatro grandes atividades:
Planejamento: determinao dos objetivos, alternativas e requerimentos.
Anlise de risco: anlise das alternativas e identificao e resoluo dos riscos.
35
Unidade I
Engenharia: desenvolvimento do prximo nvel do produto.
Avaliao do cliente: aceite dos resultados da Engenharia.
O modelo espiral desenvolve o software passo a passo. Cada novo ciclo pressupe um maior
detalhamento do software, sua construo por meio ou no de prototipagem e um uso real
para aceite dos usurios.
A cada final de ciclo e incio de outro, os riscos so avaliados e o projeto pode ser ou no
cancelado. O nmero de ciclos no pode ser alto, pois poderia colocar em risco o modelo.
O ciclo final utilizado para incorporar a parte de segurana, perfomance e garantias de
qualidade ao software.
O modelo espiral segue os conceitos da iteratividade ao longo do desenvolvimento de um
aplicativo ou projeto de software.
Observao
Todos os modernos processos de software, inclusive os mtodos geis,
consideram a iteratividade e a liberao parcial de um projeto em suas
propostas metodolicas, conceitos oriundos do modelo espiral.
4GL tcnicas de quarta gerao:
O termo tcnicas de quarta gerao (4GL) abrange um conjunto de ferramentas de
software que possuem alguma coisa em comum.
Permitem ao desenvolvedor especificar algumas caractersticas do software em alto nvel de
abstrao e ento geram automaticamente cdigos fontes baseados nas definies.
Os principais ambientes que suportam o paradigma 4GL so: linguagens no procedurais para
pesquisas em banco de dados, geradores de relatrios, manipuladores de dados, definidores de
telas interativas, geradores de cdigo, geradores de grficos, arquitetura MDA etc.
Idntico aos outros paradigmas, o 4GL comea com a especificao dos requisitos junto aos
usurios, que devero ser transportados para um prototipador. Os cdigos gerados devero
ser testados e aprovados para que o sistema possa ser considerado pronto.
As tcnicas de quarta gerao tm se tornado uma parte importante da ES, principalmente
na rea de sistemas de informao gerenciais. O que se ve uma diminuio cada vez maior
no uso de mtodos tradicionais no desenvolvimento de sistemas, e o crescimento no uso
das tcnicas de quarta gerao.
36
2.2.2 Os processos denominados de geis
Os processos geis ou a modelagem gil um processo baseado nas prticas que descrevem como
um modelador gil deve agir.
A motivao devido s estratgias atuais ou clssicas de modelagem que, muitas vezes, no se
mostram funcionais ou so consideradas muito pesadas e burocrticas.
Em um extremo, a modelagem no existe; do outro, se produz modelagem em excesso.
De acordo com Scott W. Ambler, a modelagem gil se prope a encontrar um meio termo, o qual
permita uma modelagem suficiente para explorar e documentar um sistema de modo eficaz, mas no a
ponto de tornar isso um fardo e fatalmente torn-lo um fracasso.
As tcnicas da modelagem gil podem e devem ser aplicadas por equipes de projetos que desejam
empregar uma estratgia gil de desenvolvimento de software.
Os principais frameworks ou modelos ou mtodos geis da atualidade so: XP (Xtremme Programming),
SCRUM, Crystal, AUP (gile Unified Process), ICONIX etc.
Saiba mais
Roger S. Pressman, em seu livro Engenharia de software (6 ed.,
2006), nas pginas 59 a 76, faz uma abordagem sinttica sobre os
mtodos geis que ele denomina de desenvolvimento gil, que se
inicia com a discusso do que agilidade, passa pelos conceitos de um
processo gil e apresenta os principais modelos ou mtodos geis em
uso no mbito internacional, tais como: a Extreme Programming (XP), o
Scrum, o Crystal, o FDD (Desenvolvimento Guiado por Caractersticas) e
a Modelagem gil.
2.2.3 O Processo Unificado UP
O processo unificado UP (Unified Process) um processo de software composto por quatro fases: a
fase de concepo, de elaborao, de construo e de transio.
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
I1
E1
Construction
Transition
Model
Implementation
Test
Deployment
Configuration management
Project management
Environment
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 concepo, a fase Elaboration seria a fase de elaborao, a fase
Construction a fase de construo e a fase Transition a fase de transio.
Na fase de concepo, se definem os requisitos do software e se avalia a tecnologia necessria
para uma soluo aderente s necessidades do cliente. Nesse ponto, tambm importante que sejam
considerados os riscos principais envolvidos com o software a ser desenvolvido.
Diversos diagramas e modelos da UML (disciplina Model) podem ser utilizados nessa fase, sendo o
mais importante modelo de casos de uso em um nvel mais abstrato, j que no se pode demorar muito
para se fazer uma proposta comercial e tcnica ao cliente envolvido.
Na fase de elaborao, na qual para a UP se detalham os requisitos, a UML apia com diversos
diagramas e modelos (disciplina Model), tais como: o modelo de casos de uso com os cenrios
detalhados, diagrama de atividades (para especificaes visuais de lgicas mais complexas), diagramas
de estado, diagrama de classes em nvel de domnio e outros que se fizerem necessrios para deixar as
especificaes suficientes para a implementao.
A fase de construo quando se pensa em prottipos, em banco de dados e lgicas de programao.
A UML, nessa fase, contribui com os diagramas de sequncia, comunicao, tempo, pacotes,
implantao e componentes.
Se o processo iterativo e incremental, no qual o software no liberado todo de uma
nica vez, mas desenvolvido e liberado em pedaos, a fase de construo consiste de muitas
iteraes, em que constri-se software, testa-se e faz-se a integrao que satisfaa um conjunto
de requisitos do projeto.
J na fase de transio, estamos falando dos testes e homologao, dos quais a UML no possui
diagramas ou modelos de suporte diretamente.
38
Resumo
Este captulo apresentou um histrico e conceitos da modelagem de
software e o histrico da linguagem de modelos UML.
Modelar sistemas a capacidade de simplificar a complexidade inerente
aos sistemas de informao.
A construo de modelos permite se enxergar o todo antes de se iniciar
a construo ou programao propriamente dita.
Modelar significa desenhar e pensar antes de fazer. Permite a passagem
de conhecimento para outras pessoas que saibam ler os desenhos e as
plantas do sistema.
Significa, no final, que os sistemas fiquem menos dependentes de
pessoas e passem a ser uma propriedade coletiva.
Bom para os profissionais e bom para as empresas de software.
importante salientar que a UML uma linguagem de modelagem, no
uma metodologia de desenvolvimento de software.
A UML define uma notao e um metamodelo. A notao o material
grfico visto em modelos, a sintaxe da linguagem de modelagem.
Ainda sobre a tecnologia orientada a objetos:
As tcnicas baseadas em objetos simplificam o projeto de sistemas
complexos.
A tecnologia de objetos visualiza os sistemas como uma coleo de
objetos, cada um deles em um determinado estado, dentre muitos
estados existentes.
A revoluo na indstria de software indica um movimento em
direo a uma era em que os softwares sero montados a partir de
componentes reutilizveis.
Os componentes sero criados a partir de componentes existentes, e
sero criadas grandes bibliotecas desses componentes.
39
Unidade I
Novamente, discute-se com bastante veemncia o conceito das
caixas-pretas, cujo interior no enxergamos, apesar de sabermos o
que elas fazem ou produzem.
As tcnicas baseadas em objetos sozinhas no podem prover a
magnitude da mudana necessria. Elas tm de ser combinadas com
outras tecnologias.
As tecnologias ditas otimizadoras so:
ferramentas Case;
programao visual;
geradores de cdigo;
repositrio central de dados e mdulos/componentes;
metodologias baseadas em objetos;
banco de dados orientado a objetos;
linguagens no procedurais;
mtodos formais baseados na matemtica;
tecnologia cliente-servidor, aplicativos orientados a servios
(SOA);
bibliotecas de classes que maximizem a reusabilidade;
abstrao de modelos mais prximas do mundo real.
Exerccios
Questo 1. Os autores que trabalham os conceitos envolvidos com os objetivos da
Engenharia de software afirmam que ela a aplicao de teoria, modelos, formalismos, tcnicas
e ferramentas da cincia da computao e reas afins para o desenvolvimento sistemtico
de software . Ainda de acordo com os autores, o desenvolvimento de software que utiliza
modelos para representar a realidade se torna mais produtivo e gil; aqueles construdos em
padres e simbologias predefinidos permitem que os participantes de um projeto, tanto os
analistas como os arquitetos e programadores de software , tenham um mesmo entendimento
do problema que est sendo resolvido. Os mtodos, as tcnicas e as ferramentas tambm
40
apoiam o gerenciamento do processo de desenvolvimento, devido principalmente a criao de
uma documentao formal, que destinada comunicao entre os membros da equipe e aos
usurios do sistema.
Considerando os conceitos sobre o uso de modelos no desenvolvimento de software, analise as
afirmaes a seguir e assinale a alternativa incorreta:
A) O uso de modelos mentais influencia a forma de encararmos o mundo, e o trabalho com modelos
permite a realizao de conversas ricas em aprendizados.
B) Como os modelos possuem uma sintaxe precisa, geralmente so melhor utilizados com o apoio
de uma ferramenta grfica, que, por conter semnticas que determinam como os conceitos
especficos de domnio so aplicados, diminuem consideravelmente os erros cometidos no
processo de desenvolvimento.
C) Como os modelos aplicados na Engenharia de software podem abstrair e agregar informaes
de uma srie de artefatos, eles podem ser utilizados para as verificaes de consistncia e para a
garantia da qualidade.
D) Um modelo pode ser considerado um meio de comunicao entre as pessoas envolvidas
em um projeto. Tambm ajuda outros indivduos, que podem utiliz-lo como base para a sua
implementao ou para a concepo de novos modelos.
E) Os modelos, no processo de desenvolvimento de software, somente possuem caractersticas de
comunicao e no conseguem apoiar a equipe na melhoria contnua de seus processos.
Resposta: Alternativa E.
A modelagem de sistemas de informao ou sistemas de software uma atividade que, a partir da
construo de modelos, consegue explicar as caractersticas ou o comportamento de um aplicativo ou
de um sistema de software. No processo de desenvolvimento e construo de um software, os modelos
podem ser usados na identificao das caractersticas e funcionalidades que o software dever prover e
no planejamento de sua construo.
Anlise das alternativas
A) Correta. Quando se defronta com um problema, o homem desenvolve mentalmente uma srie de
abstraes, as quais permitem o encaminhamento de solues. Essas abstraes da realidade so
denominadas modelos.
B) Correta. Os modelos so acompanhados de padres no seu uso e possuem uma semntica bem
definida. As ferramentas denominadas CASE incluem esses padres, conseguindo, assim, orientar
e diminuir os possveis erros que possam ser cometidos pelas pessoas.
41
Unidade I
C) Correta. A qualidade de software pressupe que os artefatos produzidos no ciclo de desenvolvimento
devem ser verificados passo a passo, para que se tenha uma consistncia nos produtos realizados.
Como os modelos representam graficamente os produtos de software, possibilitam revises mais
cosistentes pelos participantes de seu processo de construo.
D) Correta. Como um modelo representa uma abstrao de uma realidade, outros podem ser construdos
para uma soluo de novos aspectos envolvidos com aquela realidade. Um modelo tambm pode ser
detalhado com o uso de novos modelos mais especficos dentro da realidade observada.
E) Incorreta. Os modelos no processo de desenvolvimento so utilizados por todos os envolvidos no
sistema e so considerados como uma forma de entendimento e apoio s atividades do processo
de desenvolvimento, que, a partir da avaliao dos problemas encontrados, pode proporcionar a
melhoria do processo.
Questo 2. A Orientao a Objetos considerada um paradigma para o desenvolvimento de software.
Baseia-se na utilizao de componentes individuais (chamados de objetos), que colaboram para construir
sistemas mais complexos. Toda a comunicao ou colaborao entre os objetos feita por meio do
envio de mensagens (um objeto aciona outro objeto para a execuo de uma operao e aguarda uma
resposta). Um paradigma um conjunto de regras que estabelece fronteiras e descreve como resolver
problemas dentro dessa fronteira. Um paradigma ajuda o homem a organizar a e coordenar a maneira
como ele observa o mundo.
Considerando-se os conceitos sobre a Orientao a Objetos, analise as afirmaes a seguir e assinale
a alternativa incorreta:
A) Dentro da tecnologia OO, um objeto alguma coisa que faz sentido no contexto de uma aplicao
e representa uma entidade relevante para o entendimento e para a soluo de uma necessidade
de uma atividade ou ao usurio do sistema.
B) Como na OO os objetos se comunicam por meio de mensagens, uma mensagem enviada por um
objeto causa a ativao de uma operao (mtodo) no objeto alvo para responder ao chamado do
objeto ativador ou chamador.
C) Na OO, o conceito de polimorfismo surge quando uma operao de um determinado objeto atua
de acordo com as definies especficas de sua funcionalidade.
D) Para ser utilizada, uma classe de objeto precisa de um mtodo denominado Construtor, que
inicializa o objeto quando ele instanciado e disponibiliza os recursos para que sejam utilizados
pelos mtodos ou operaes do objeto.
E) A UML (Unified Modeling Language) foi desenvolvida na dcada de 1990 para unificar as diversas correntes
existentes no desenvolvimento de software que utilizavam a tecnologia da Orientao a Objetos.
Resoluo desta questo na Plataforma.
42
MODELAGEM DE PROCESSOS
UNIDADE I
Questo 2
Resposta correta: alternativa C.
Justificativa: os autores originais da UML afirmam que a linguagem de modelos
no pretende dizer para os desenvolvedores como se deve fazer um software, e sim
proporcionar formas ou maneiras que podem ser utilizadas para representar essa
ferramenta de acordo com a fase do desenvolvimento dentro de um processo
especfico. A UML prope diversos modelos diferentes que cobrem todo o ciclo de
desenvolvimento, desde a especificao at a construo do produto de software. Os
modelos propostos na UML obedecem s regras e fundamentos da Orientao a
Objetos e no podem ser interpretados como um processo de desenvolvimento, como
os modelos cascade e RUP (Rational Unified Process) e o processo gil SCRUM.
A) Correta. Uma aplicao desenvolvida com a Orientao a Objetos um
conjunto de objetos (representados por classes de objetos) que interagem para
resolver as funcionalidades do sistema ou aplicao.
B) Correta. Os objetos so denominados de cliente e fornecedor. Cliente o
objeto que aciona outro objeto; fornecedor o objeto que atende a um chamado de
outro objeto. O atendimento ocorre por meio das operaes do objeto fornecedor, que
recebe os parmetros, executa suas aes e devolve o resultado ao objeto cliente
(chamador).
C) Incorreta. Polimorfismo quando uma operao ou mtodo de um objeto atua
de formas diferentes dependendo da chamada recebida. Isto , o comportamento do
objeto varia de acordo com o tipo de chamada realizada para a operao do objeto.
Polimorfismo quer dizer diversas formas assumidas pelo objeto em um determinado
contexto.
D) Correta. Sem um mtodo construtor, o objeto no poderia ser inicializado e no
se teria a atribuio de valores s propriedades do objeto.
E) Correta. Conforme Medeiros (2004), os autores Ivar Jacobson, Grady Booch e
Jim Rumbaugh se uniram em 1995 para unificar seus mtodos para o
desenvolvimento OO e criaram a UML, que se tornou ao longo do tempo a linguagem
padro para a OO.
Unidade II
3 Modelo Conceitual da UML
3.1 Introduo
O Object Management Group (OMG) adotou a UML em novembro de 1997. Essa adoo ocorreu
em um evento histrico e marcante, pois assinalou a aceitao de uma linguagem padronizada de
modelagem de sistemas baseada nas melhores prticas atuais para a anlise, projeto e construo de
software orientado a objetos.
Saiba mais
A Object Management Group, ou OMG, uma organizao internacional
que aprova padres abertos para aplicaes orientadas a objetos. O Object
Management Group foi fundado em 1989. Constantemente, a OMG publica
o documento dos padres e normativos sobre a UML no seu portal cuja URL
: <http://www.omg.org/spec/UML/2.3/Infrastructure>.
A UML a primeira notao que atingiu o concenso entre a maioria dos profissionais,
vendedores e acadmicos como o padro real para expressar um domnio comercial da soluo
de software.
Grady Booch (2000) diz que a modelagem deve atingir quatro objetivos para se tornar efetiva em
um ambiente de desenvolvimento de software:
ajudar a equipe de projeto a visualizar um sistema como ele ou como ele pretende ser;
ajudar a especificar a estrutura ou comportamento do sistema;
proporcionar um modelo que sirva de guia na construo do sistema;
documentar as decises tomadas pela equipe de desenvolvimento de projeto (REED JR., 2000).
3.2 Viso geral da UML
A UML no um modelo de processo/metodologia de software. uma notao, um mecanismo para

mostrar o problema de forma a expor a essncia do domnio de um aplicativo.
43
Unidade II
A combinao da UML com um bom modelo de processo, tais como, o RUP (Rational Unified Process)
ou o processo gil SCRUM, resulta em uma poderosa combinao para a criao de aplicativos bemsucedidos (REED JR., 2000).
A linguagem de modelos UML tem dois objetivos: um deles proporcionar consistncia, informando
o cliente ou patrocinador do projeto de que o domnio do problema est bem entendido pela equipe
de desenvolvedores. O outro objetivo proporcionar um modelo de consistncia para a equipe de
implementao (arquitetos e programadores), que assim podero fazer uma implementao adequada
do software.
Lembrete
Todavia, deve ficar claro que somente os diagramas da UML no
conseguem garantir o processo de desenvolvimento. Um bom modelo de
processo e um plano adequado do projeto so fundamentais para que o
projeto no falhe.
Todos os artefatos propostos pela UML so rastreveis e, se construdos 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 construdos ao longo do desenvolvimento com a UML serviro como um ponto
de controle da qualidade do modelo anterior, j que se completam. Como os modelos UML so interrelacionados na sua criao, mais fcil identificar quando um componente est faltando ou est incorreto.
Todavia, a UML no resolve diretamente alguns aspectos de um projeto e, se necessrio, deve-se
utilizar outros diagramas auxiliares, como a interface grfica de usurio (GUI), a distribuio do processo
(processamento distribudo) e a distribuio dos dados (BDs distribudos).
3.3 Arquitetura da UML
Uma arquitetura de sistema de software pode ser descrita por cinco vises interconectadas. Cada
viso uma projeo na organizao e estrutura do sistema, focando em um aspecto particular desse.
As cinco vises da arquitetura UML so: viso de anlise, viso de design, viso de implementao,
viso do processo e viso da implantao. Para a UML, o modelo ou viso que interconecta essas vises
se d pelo modelo de caso de uso.
A viso de caso de uso de um sistema compreende os que descrevem o comportamento do sistema
como visto pelos usurios finais, analistas e testadores.
Essa viso no especifica a organizao do sistema de software. Na UML, os aspectos estticos do
sistema so capturados no diagrama de caso de uso.
44
Os 13 diagramas da UML esto divididos em trs categorias: esttico, dinmico e arquitetural:
Os diagramas estticos mostram a esturutra do sistema e as responsabilidades. Esses diagramas
mostram a estrutura fsica dos elementos e no envolvem a passagem do tempo. Isto ,
eles no mostram a dinmica das coisas, simplesmente sua organizao. Os trs principais
diagramas estticos da UML so: o modelo de caso de uso, o modelo de classes e o modelo
de objetos.
Um diagrama dinmico mostra a interao ativa que o sistema suporta e detalha a interao
entre os elementos estruturais dos diagramas estticos.
Essas interaes dinmicas so descobertas nos casos de uso como caminhos executados
em resposta a alguns estmulos externos ao sistema. Os diagramas dinmicos mostram o
comportamento pretendido do sistema. Os principais diagramas dinmicos so: atividades,
comunicao, sequncia e estado.
Um diagrama arquitetural mostra a realizao do sistema em componentes funcionais e
executveis. Eles tambm diferenciam a localizao fsica da execuo e os ns de armazenamento
e uma estrutura dentro da qual eles podem interagir.
Os principais diagramas estruturais so: componentes e implantao.
3.4 Modelagem estrutural
Na UML, o principal diagrama que mostra a estrutura de um sistema o diagrama de classes.

Todavia, outros diagramas tambm permitem visualizar a estrutura do sistema, tais como, o diagrama
de pacotes, o diagrama de componentes, o diagrama de objetos e o diagrama deployment (implantao).
3.4.1 Classes de objetos
Uma classe de objetos uma coleo de objetos que podem ser descritos com os mesmos atributos
e as mesmas operaes.
Representa uma idia ou um conceito simples e categoriza objetos que possuem propriedades
similares, configurando-se em um modelo para a criao de novas instncias (outros objetos).
Uma classe de objetos na UML possui trs segmentos: nome, atributos e operaes.
A representao ou notao de uma classe um retngulo com os trs 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 instncias do objeto podem ter.
45
Unidade II
O terceiro segmento da classe so as operaes. Uma operao a implementao de um servio
ou funcionalidade que pode ser requisitado de qualquer objeto da classe para afetar o comportamento
do objeto.
3.4.2 Relacionamentos entre classes de objetos/instncias
As classes de objetos, no modelo de classes, se relacionam ou se associam de acordo com as
necessidades do sistema. Esses relacionamentos so denominados associao entre classes.
Um relacionamento define as regras da associao que, por seu lado, so impostas pelas regras de
negcio da aplicao, sendo modelada.
A criao de um objeto, baseado em uma classe, recebe um nome especial: instncia. Quando
necessrio manipular um determinado objeto, a classe carregada na memria, e os objetos so
instanciados, isto , so criados na memria e podem ser manipulados.
A instanciao de objetos depende da linguagem OO utilizada, mas, em geral, possuem uma funo
especial que cuida das instncias dos objetos, denominada construtora.
Quando o objeto j no mais necessrio, outra funo especial chamada de destrutora da classe
elimina as instncias criadas. Por exemplo: para uma classe funcionrio, o objeto tipo funcionario Joo
Carlos da Silva seria uma instncia na memria.
3.4.3 Mecanismos comuns
A UML feita simplesmente pela presena de mecanismos comuns que garantem a consistncia a
partir da linguagem, tais como: especificao, adornos e mecanismo de extensibilidade.
A especificao refere-se aos padres das descries dos componentes dos modelos: como
nomear os componentes, como descrever a lgica de um cenrio de um caso de uso , e assim
por diante.
Adornos so itens grficos e textuais que so adicionados a uma notao de um elemento bsico e
so usados para visualizar detalhes da especificao do elemento. Por exemplo, no smbolo de n de um
diagrama de implantao, pode ser interessante colocar os componentes executveis dentro de uma
caixa extra do desenho.
O mecanismo de extensibilidade da UML permite extender a linguagem de uma maneira controlada.
Esse mecanismo inclui esteretipos, valores marcados e restries.
Um esteretipo extende o vocabulrio da UML, permitindo que se criem novos tipos
de blocos de construo que so derivados de outros existentes, mas especifcos para um
determinado problema.
46
3.4.4 Diagramas da UML
Com um modelo, possvel um melhor entendimento dos sistemas que esto em desenvolvimento.
Com a UML, pode-se construir modelos a partir de um conjunto de blocos bsicos, tais como, classes,
interfaces, colaboraes, componentes, ns, dependncias, generalizaes e associaes.
Lembrete
Quando o homem modela qualquer coisa, ele est criando uma
simplificao da realidade.
A UML prope 13 diagramas, conforme mostra a quadro 2:
Quadro 2 Diagramas da UML
Nmero
Diagramas
UML 1.X
UML 2.3
Atividade
Atividade
Caso de uso
Caso de uso
Classe de objetos
Classe de objetos
Objetos
Objetos
Sequncia
Sequncia
Colaborao
Comunicao
Estado
Estado
Componentes
Componentes
Implantao
Implantao (deployment)
10
-------------
Pacotes
11
-------------
Interao
12
-----------
Tempo
13
----------
Estrutura composta
Lembrete
Com relao ao ciclo de desenvolvimento de software:
Cada diagrama da UML, ou modelo, pode ser usado em um
determinado momento do ciclo de desenvolvimento de software.
Um diagrama da UML deve ser usado para resolver ou mostrar
aspectos especficos do problema sendo modelado.
Um diagrama da UML pode ser usado para especificar artefatos
diferentes em atividades diferentes do processo de software. Por
47
Unidade II
exemplo, o diagrama de atividade pode ser usado para detalhar uma
funcionalidade, como mostrar um determinado fluxo do problema
que est sendo estudado etc.
3.4.4.1 Diagrama de atividade
Os diagramas de atividades so usados para modelar o comportamento de um sistema, e a forma em
que esses comportamentos esto relacionados em um fluxo geral desse.
O fluxo mostra os caminhos de um processo lgico a seguir, com base em vrias condies,
processamento simultneo, acesso a dados, interrupes e outras distines do caminho lgico.
So usados para construir um sistema, um processo, ou um procedimento.
3.4.4.2 Diagrama de caso de uso
Um diagrama de caso de uso captura as funcionalidades do sistema e as relaes entre os atores e o
sistema. Ele descreve os requisitos funcionais do sistema, a maneira pela qual as coisas de fora (atores)
interagem no limite do sistema e a resposta desse aos usurios.
Lembrete
O diagrama de caso de uso, ou modelo de caso de uso, um dos mais
importantes modelos da UML e ser detalhado na Unidade 3.
3.4.4.3 Diagrama de objetos
Um diagrama de objetos est intimamente relacionado a um diagrama de classes de objetos,
com a distino de que retrata instncias de objetos das classes e seus relacionamentos em um
ponto no tempo.
Isso pode parecer semelhante a um diagrama de estrutura composta, que tambm modela
comportamentos em tempo de execuo. A diferena que os diagramas de objetos exemplificam os
diagramas de classes estticas, enquanto que os diagramas de estrutura composta refletem arquiteturas
em tempo de execuo.
Eles so teis na compreenso de um diagrama de classes complexas, criando diferentes casos em
que os relacionamentos e as classes so aplicados.
Um diagrama de objeto tambm pode ser uma espcie de diagrama de comunicao, que
tambm modela as conexes entre os objetos, mas adiciona sequncias de eventos ao longo de
cada caminho.
48
3.4.4.4 Diagrama de sequncia
O diagrama de sequncia um dos quatro tipos de diagrama de interao. Um diagrama de sequncia
uma representao estruturada de comportamento com uma srie de etapas sequenciais ao longo do
tempo.
Ele usado para descrever o fluxo de trabalho, passagem de mensagens. Cada elemento da sequncia
organizado em uma sequncia horizontal, com mensagens que passam para trs e para frente entre
os elementos.
Um elemento de ator pode ser usado para representar o usurio 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 interaes.
3.4.4.5 Diagrama de comunicao
Um dos quatro tipos de diagrama de interao. Um diagrama de comunicao mostra as interaes
entre os elementos em tempo de execuo da mesma maneira que um diagrama de sequncia.
No entanto, os diagramas de comunicao so usados para visualizar as relaes entre objetos, enquanto
os diagramas de sequncia so mais eficazes na visualizao de processamento ao longo do tempo.
Os diagramas de comunicao empregam associaes rotuladas e ordenadas para ilustrar o
processamento. A numerao importante para indicar a ordem e a nodificao de processamento.
Um esquema de numerao pode ser: 1, 1.1, 1.1.1, 1.1.2, 1.2 e assim por diante.
3.4.4.6 Diagrama de estado (mquina de estado)
Os diagramas de estado da mquina eram anteriormente conhecidos como diagramas de estado.
Esse diagrama ilustra como um elemento (geralmente uma classe) pode mover-se entre os estados,
classificando o seu comportamento de acordo com gatilhos de transio ou guardas de restrio.
Outros aspectos do diagrama de mquina de estado ajudam a descrever e explicar os movimentos e
comportamentos dos sistemas.
3.4.4.7 Diagrama de componentes
Um diagrama de componentes mostra os pedaos de software, controladores embutidos que formam
um sistema, sua organizao e as dependncias.
Um diagrama de componente tem um nvel maior de abstrao do que um diagrama de classes. Geralmente,
um componente implementado por uma ou mais classes (ou objetos) em tempo de execuo.
49
Unidade II
Eles so blocos de construo, construdos de modo que, eventualmente, um componente pode
abranger uma grande parte de um sistema.
3.4.4.8 Diagrama de implantao
Um diagrama de implantao (deployment) mostra como e onde o sistema ser implantado, ou seja,
sua arquitetura de execuo.
Dispositivos de hardware, processadores e ambientes de software de execuo (artefatos do sistema)
so refletidos como ns, e a construo interna pode ser representada incorporando ns no desenho.
Como os artefatos so alocados para os ns do modelo de implantao do sistema, a alocao guiada
pela utilizao das especificaes de implantao.
3.4.4.9 Diagrama de pacotes
O diagrama de pacotes (pakage) mostra a organizao dos elementos de um modelo em pacotes
(agrupamentos) e as dependncias entre esses pacotes, incluindo pacotes importados e extenses de
pacotes.
3.4.4.10 Diagrama de interao (viso geral)
Um diagrama geral de interao visualiza a cooperao entre os diagramas de interao para ilustrar
um fluxo de controle que serve a um propsito abrangente.
Como os diagramas gerais de interao so uma variante de diagramas de atividades, a maioria da
notao do diagrama a mesma, como o processo de construo do diagrama.
Pontos de deciso, forks, junes, pontos iniciais e finais so os mesmos. Em vez de elementos
de atividade, no entanto, elementos retangulares so usados. Existem dois tipos desses elementos:
elementos de interao e e elementos de ocorrncia.
3.4.4.11 Diagrama de tempo
Um diagrama de tempo define o comportamento de objetos diferentes dento de uma escala de
tempo. Ele fornece uma representao visual da mudana dos objetos, mudando de estado e interagindo
todo o tempo.
Ele pode ser usado para definir os componentes e softwares embutidos. Tambm pode ser utilizado
para especificar processos de negcio orientados pelo tempo.
3.4.4.12 Diagrama estrutura composta
Um diagrama de estrutura composta reflete a colaborao interna de classes, interfaces ou
componentes (e suas propriedades) para descrever a funcionalidade do sistema.
50
Eles so similares aos diagramas de classe, exceto pelo fato de que eles modelam um uso especfico
da estrutura. Um diagrama de estrutura composta usado para expressar o tempo de execuo das
arquiteturas, padres e relacionamentos dos elementos participantes, que no podem ser refletidos por
meio de diagramas estticos.
4 Diagrama de classes de objetos da UML
Entre esses diagramas, o diagrama de classes considerado um dos principais e ser detalhado a
seguir.
4.1 Introduo
O diagrama de classes mostra a estrutura esttica do sistema por meio de suas classes e objetos e
tambm como eles se relacionam.
considerado por alguns autores como o mais importante diagrama no desenvolvimento orientado
a objetos e, portanto, tambm da UML.
Observao
A meta na construo de um modelo de objetos incorporar os
conceitos do mundo real que sejam importantes para a aplicao.
A figura 12 mostra um exemplo de modelo de classes de objetos na notao da UML.
Mundo real
Realidade de interesse
(Observado)
Modelo de objeto
Nome da classe de objetos
Atributos
Operaes ( )
Figura 12 Viso do mundo real x a OO
51
Unidade II
A figura 13 mostra um exemplo de diagrama de objetos com um metamodelo de classe, uma classe
e duas instncias da classe Jos da Silva e Maria Rodrigues.
Nome da classe de objetos
Pessoa
Nome dos atributos
Nome
idade
Operaes ( )
Mudar_endereo ( )
Jos da Silva
32
Maria de Tal
26
Objetos com valores da

classe pessoa.
O nome da classe (metamodelo)

representa o agrupamento de
objetos do mesmo tipo.
Figura 13 Exemplo de uma classe e suas instncias na notao UML
Alguns meios de implementao (linguagens de programao e sistemas gerenciadores de banco de

dados) exigem que um objeto tenha um identificador explcito para cada objeto. Esses identificadores
explcitos no so obrigatrios em um modelo de objetos.
A figura 14 mostra um uso incorreto de identificadores internos.
Pessoa
Cod_Pessoa
Nome
Pessoa
Correto
Nome
idade
Figura 14 Uso incorreto de identificador interno
Os identificadores internos (gerados pelas linguagens) no podem ser confundidos com atributos
do mundo real e no devem fazer parte do modelo conceitual. O nmero_telefone e nmero_placa_
carro no so identificadores internos porque tm significado no mundo real.
Uma classe sempre deve representar um mesmo assunto, isto , ela encapsula conhecimentos sobre
algo. No teria sentido colocarmos dados sobre a empresa em que trabalha na classe pessoa.
Pessoa e empresa so assuntos diferentes ou objetos diferentes e, portanto, devem estar em classes
distintas. Uma classe tem responsabilidade por tudo o que lhe diz respeito. No de responsabilidade da
pessoa/funcionrio incluir ou manter os dados da empresa.
Uma classe poder ter visibilidade pblica, protegida, privada:
Uma classe pblica indica que qualquer outra classe poder acessar seus atributos e solicitar a
execuo de suas operaes.
52
Uma classe denominada de privada quando restringe totalmente o acesso a seus atributos e as
suas operaes.
Uma classe com visibilidade protegida somente permite a ela e aos seus herdeiros o acesso a seus
atributos e suas operaes.
As operaes ou comportamentos de uma classe de objetos recebem e devolvem valores que
so passados numa lista de argumentos, dentro de um padro especfico que cada linguagem
adota.
O diagrama do modelo conceitual deve ser independente da tecnologia, e quando da implementao
que se considera os padres especficos.
A figura 15 mostra um exemplo de chamada de uma operao com a lista de argumentos.
Exemplo: mudar_endereo (novo_endereo, ok)
Operao
Parmetro
de entrada
Parmetro
de sada
Figura 15 Exemplo de uma operao e a lista de argumentos
Em um modelo de classes, existem diversas classes do domnio da aplicao que precisam se

relacionar dentro das regras de negcio.
Elas, quando esto 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 trs tipos: associao, agregao
e composio e generalizao/especializao.
4.2 Associao
Associao uma relao semntica entre classes. Uma associao acontece quando uma
determinada instncia de uma classe se associa a uma ou mais instncias de outra ou da
mesma classe.
Ligaes e associaes so os meios para estabelecermos relacionamentos entre objetos e classes. As
ligaes so conexes entre instncias de objetos.
A figura 16 mostra o metamodelo de associao de classes e um exemplo prtico.
53
Unidade II
Papel 1
Classe A
Classe B
Papel 2
associao
Pessoa
Empresa
trabalha_para
Joo da Silva
Telesp
ligao
Figura 16 Exemplo de uma associao entre duas classes. O modelo apresentado
o modelo de objetos no qual o objeto pessoa trabalha para uma empresa
As associaes ainda podem ser binrias, unrias, ternrias e assim por diante. Uma
associao dita binria quando duas classes esto envolvidas na associao, conforme mosta
a figura 17.
tem_capital
Pais
Cidade
0.1
Nome
Nome
Figura 17 Associao binria
Uma associao dita unria quando o relacionamento de uma classe consigo prpria.
A figura 18 mostra um exemplo de associao unria. Uma pea pode compor outras peas maiores,
mas tambm pode ser composta de outras peas menores.
Pea
1..*
Componente
Composta
0..*
Figura 18 Um exemplo de associao unria
Uma associao dita ternria quando trs classes fazem parte da associao. Na figura 19, tem-se
que um projeto tem vrias pessoas trabalhando nele e pode ser implementado em vrias linguagens
diferentes.
A nomeao das associaes so opcionais para associaes ternrias ou de ordem superior
(n-rias).
54
A figura 19 mostra um exemplo de associao ternria.
1..*
Projeto
1..*
Linguagem
1..*
Pessoa
Smbolo de associao ternria ou de ordem superior
Figura 19 Exemplo de uma associao ternria
4.3 Papis em associao
A UML possui uma notao especfica para representar as regras de uma associao entre os objetos
das classes.
A notao denomina-se cardinalidade ou multiplicidade e deve ser descrita no diagrama, como
mostra a tabela 1.
Tabela 1 Cardinalidades ou multiplicidades das associaes entre classes
Cardinalidade
Descrio
0..1
Opcional e nico
0..*
Opcional e mltiplo
Obrigatrio e nico
1..*
Obrigatrio e mltiplo
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 associao deve estar classificado, deve-se
utilizar a palavra-chave {ordenado}, como mostra a figura 20.
Classe A
Papel 2
Papel 1
{ordenado}
Classe B
Figura 20 Uso da palavra chave {ordenado}
Quando se quer declarar a visibilidade da associao, deve-se colocar os smbolos em frente ao nome
do papel (+ pblico, # protegido, - privado). Isso declara a visibilidade da associao em direo
quele papel.
55
Unidade II
Por exemplo: na figura 9, se for colocado em frente do papel 1 o smbolo +, est declarado que esse
papel na associao de uso pblico.
Quando existir a necessidade de mostrar o sentido da navegao em uma determinada
associao, deve-se colocar uma seta na extremidade da associao para indicar a direo
suportada pelo modelo.
A figura 21 mostra um exemplo do uso da navegao em uma associao entre duas classes de
objetos.
tem capital
Pais
Nome
0..1
Cidade
1
Nome
Figura 21 Navegao (restrio de acionamento de classes)
A seta indica o sentido em que a navegao suportada no modelo, dessa forma no possvel
operaes da classe cidade acessarem as operaes da classe pas.
4.4 Classe de associao
Em alguns modelos, devido s regras de negcio, torna-se necessria a colocao de atributos em

uma determinada associao. Um atributo uma propriedade dos objetos de uma classe.
Como uma associao tambm um objeto, perfeitamente possvel colocar nela atributos. Ento,
um atributo de ligao uma propriedade de uma associao.
A figura 22 apresenta a classe depto de uma empresa e a classe funcionrio, nas quais ficam os
funcionrios da empresa.
Depto
Nome
Chefia
Funcionrio
0..1
Cod_func
nome
Figura 22 O uso de atributos de associao
A questo que se coloca no modelo : onde colocar a data de posse da chefia, em departamento
ou em funcionrio? Todavia, a data de posse uma propriedade da associao chefia e deve
pertencer a ela.
A data de posse no propriedade nem do departamento e nem do funcionrio.
Uma das solues seria colocar a data em uma das classes associadas. A escolha fica a critrio do
analista, j que esse atributo no natural nem para departamento e nem para funcionrio.
56
O problema decorrente da colocao dos atributos de ligao em uma das classes ligadas a
flexibilidade futura do modelo. Caso haja qualquer dvida com relao ao futuro, como regra, cria-se
uma classe de associao.
Como mostra a figura 23, criou-se uma classe nova denominada classe de associao para permitir
a colocao do atributo especfico da associao.
A classe de objetos chefia, possui atributos prprios e provavelmente operaes para tratar esses
atributos e as associaes.
0..1
Depto
Funcionrio
Cod_func
nome
Nome
Chefia
Data_posse
Figura 23 O uso da classe de associao
A figura 24 mostra outro exemplo de classe de associao para um modelo mais sofisticado. Temos
um modelo que mostra uma empresa, seus funcionrios e o grau de desempenho desses.
Funcionrio
Nome
RG
0..* Trabalha_para
1..*
Empresa
Nome
Endereo
Endereo
Gerencia
Grau de
desempenho
Trabalha para
Salrio
Cargo
Admite_funcionrio ( )
Figura 24 Classes de associao
Note que o grau de desempenho pertence associao, j que o atributo somente tem sentido
enquanto o funcionrio ocupa o cargo de gerncia.
A classe trabalha para indica que o salrio e o cargo do funcionrio so atributos que dependem
da empresa em que trabalha, j que o modelo permite que um funcionario trabalhe em mais de uma
empresa.
57
Unidade II
4.5 Agregao e composio
Agregao um tipo especial de associao em que um objeto contm o(s) outro(s). tambm
chamado de relacionamento todo/parte. Agregao um modo de associao na qual um objeto
agregado feito de componentes. Os componentes fazem parte do agregado.
A figura 25 mostra um exemplo de agregao. Uma publicao possui artigos obrigatoriamente no
modelo. Isso significa que uma publicao composta necessariamente de artigos.
O diamante vazio indica que a ligao fraca, j que uma publicao pode existir sem nenhum
artigo, mas um artigo no existe sem uma publicao associada.
Publicao
1..*
0..*
Artigo
Figura 25 Exemplo de uma agregao entre classes associadas
As agregaes incluem exploses das partes e expanses de um objeto em suas partes constituintes.
A figura 26 mostra outro exemplo de agregao entre classes de objetos.
Empresa
Trabalha_para
0..1
Funcionrio
0..*
1
0..*
Diviso
1
0..*
Departamento
Figura 26 Exemplo de agregao
Uma empresa uma agregao de suas divises, que so, por sua vez, agregaes de seus
departamentos. Uma empresa no uma agregao de seus funcionrios, uma vez que empresa e
pessoa so objetos distintos e independentes.
58
Uma composio uma agregao forte em que as partes esto fisicamente contidas dentro do
todo. Os componentes no podem ser compartilhados por outros compostos. Uma excluso do todo
desencadeia uma excluso em cascata das partes, portanto, o ciclo de vida das classes em composio
coincidem.
A figura 27 mostra um exemplo de composio.
Livro
1
0..*
Captulo
Figura 27 Exemplo de composio (associao forte)
A excluso de um livro acarreta a excluso de todos os seus captulos, e a excluso dos captulos do
livro implica a elimincao do livro.
4.6 Generalizao/especializao
A generalizao uma forma de se estruturar a visibilidade de um elemento global com uma viso
mais detalhada desse. Isso feito adicionando caractersticas especficas ao elemento na viso detalhada
e aproveitando as caractersticas gerais.
generalizao
especializao
Figura 28 Generalizao x especializao
A generalizao/especializao 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 so chamadas superclasses, e as inferiores subclasses. Tanto a superclasse como
as subclasses referem-se s caractersticas de um nico objeto.
Com a generalizao, um objeto simultaneamente instncia da superclasse e instncia da
subclasse.
Trabalha_para
Empresa
0..1
Diviso
Funcionrio
Associao de
generalizao
0..*
Masculino
Feminino
Departamento
Figura 29 Exemplo de generalizao
Uma rvore de generalizao composta por classes que descrevem um objeto. No exemplo da figura
19, a classe funcionrio foi especializada em masculino e feminimo, devido a caractersticas especficas
de cada um, mas o modelo garante que as caractersticas comuns esto representadas somente uma
vez na superclasse funcionrio.
Diz-se que masculino um tipo_de funcionrio ou masculino um funcionrio. Um funcionrio
ou masculino ou feminino.
4.7 Herana
Na UML, herana um mecanismo por meio do qual uma instncia de uma classe assume os atributos
e os comportamentos dos objetos de outra classe (antepassados ou antecedentes).
Os objetos subordinados herdam atributos e servios da classe superior. A propriedade herana
permite que novas classes sejam construdas pela herana de classes existentes. A figura 30 mostra um
exemplo de herana.
60
Aeronave
Classe ou superclasse
Jato
Planador
Subclasse
Figura 30 Exemplo de aplicao do mecanismo de herana
No exemplo da figura 30, as classes jato e planador so subclasses de aeronave. As classes subordinadas
podem ter atributos e ou mtodos prprios. O conceito de herana refora a extensibilidade caracterstica
que sempre se procurou na programao.
Uma classe descendente/subclasse no pode omitir ou suprimir um atributo da superclasse, seno
no seria uma instncia antecessora. As subclasses tambm so chamadas de classes derivadas ou
classes-filho na hierarquia de classes.
As classes que ficam mais altas na hierarquia so denominadas de superclasses.
Funcionrio
Funcionrio
feminino
nome solteira
registrar licena
maternindade
Funcionrio
masculino
Figura 31 Exemplo de herana
Pode acontecer de uma subclasse possuir alguma operao diferente de seu antecessor. Isso
chamado de extenso. Uma subclasse pode restringir atributos do antecessor. Isso chamado de
restrio, pois restringe os valores que aquela instncia pode assumir.
Lembrete
O mecanismo de herana se tornou sinnimo de reutilizao de cdigo
no projeto orientado a objetos.
61
Unidade II
A figura 32 mostra um exemplo completo do uso de herana.
Equipamento
nome
fabricante
preo
peso
Bomba
Tanque
Volume
presso
Tipo de equipamento
presso de suco
presso de descarga
taxa de fluxo
Tipo de tanque
Tipo de bomba
Tanque esfrico
Bomba centrfuga
dimetro
eixo de rotao
Tanque pressurizado
dimetro
altura
Tanque de teto flutuante

dimetro
altura
Bomba de imerso
Bomba de diafragma
dimetro de pisto
nmero de cilindros
material do diafragma
Figura 32 Exemplo completo do uso de herana
A quadro 3 mostra o contedo dos objetos da classe bomba centrfuga e da classe tanque de teto
flutuante com suas caractersticas especficas apesar de serem ambas equipamento.
Diversos atributos e operaes so vlidos para os dois objetos e possuem atributos e operaes
especficos.
Quadro 3 Contedo das classes
Bomba de diafragma
62
Tanque de teto flutuante
Nome = P101
Nome = T111
Fabricante = Simplex
Fabricante = Simplex
Peso = 100 kg
Peso = 10.000 kg
Preo = R$ 5.000,00
Preo = R$ 50.000,00
Presso suco = 1,1 atm
Volume = 400.000 l
Presso de descarga = 3,3 atm
Presso = 1,1 atm
Taxa de fluxo = 300 l/hora
Dimetro = 8 m
Mat. diafragma = teflon
Altura = 9 m
Herana um mecanismo da OO que permite criar novas classes a partir de classes j
existentes, aproveitando-se das caractersticas existentes na classe a ser extendida.
Este mecanismo muito interessante, pois promove um grande reuso e reaproveitamento
de cdigo existente. Com a herana possvel criar classes derivadas (subclasses) a partir de
classes bases (superclasses). As subclasses so mais especializadas do que as suas superclasses,
mais genricas. As subclasses herdam todas as caractersticas de suas superclasses, como
suas variveis e mtodos.
Imagine que dentro de uma organizao empresarial, o sistema de RH tenha que
trabalhar com os diferentes nveis hierrquicos da empresa, desde o funcionrio de baixo
escalo at o seu presidente.
Todos so funcionrios da empresa, porm cada um com um cargo diferente. Mesmo
a secretria, o pessoal da limpeza, o diretor e o presidente possuem um nmero de
identificao, alm de salrio e outras caractersticas em comum. Essas caractersticas em
comum podem ser reunidas em um tipo de classe em comum, e cada nvel da hierarquia ser
tratado como um novo tipo, mas aproveitando-se dos tipos j criados, a partir da herana.
Os subtipos, alm de herdarem todas as caractersticas de seus supertipos, tambm
podem adicionar mais caractersticas, seja na forma de variveis e/ou mtodos adicionais,
bem como reescrever mtodos j existentes na superclasse (polimorfismo).
A herana permite vrios nveis na hierarquia de classes, podendo criar tantos subtipos
quanto necessrio, at se chegar no nvel de especializao desejado. Podemos tratar
subtipos como se fossem seus supertipos, por exemplo, o sistema de RH pode tratar uma
instncia de presidente como se fosse um objeto do tipo funcionrio, em determinada
funcionalidade.
Porm, no possvel tratar um supertipo como se fosse um subtipo, a no ser que o
objeto em questo seja realmente do subtipo desejado e a linguagem suporte este tipo de
tratamento, seja por meio de converso de tipos ou outro mecanismo.
Fonte: <http://www.softechnetwork.com.br/java/CursoOO.pdf>. Acesso em: 15 jun. 2012.
4.8 Conceitos avanados envolvendo classes
4.8.1 Herana mltipla

Herana mltipla uma extenso da anlise orientada a objetos que permite uma classe ter mais de
uma superclasse e herdar todas as caractersticas (atributos e operaes) de todos os seus pais.
considerada a mais complicada forma de generalizao, e nem todas as linguagens de programao
do suporte diretamente. A figura 33 mostra um exemplo de herana mltipla.
63
Unidade II
Janela
Texto
rvore
Tela
Figura 33 Herana mltipla
Com a herana mltipla a classe tela herda todas as caracersticas de suas trs classes-pai ou superclasses.
A classe janela possui as propriedades das janelas e as operaes para mostr-las e moviment-las pela tela.
A classe texto oferece as propriedades textuais das janelas, com operaes/mtodos para manipular
linhas de texto etc.
A herana mltipla aumenta o potencial de uma linguagem orientada a objetos, mas a um custo na
complexidade da programao, bem como um overhead de compilao e de tempo de execuo.
Uma classe com mais de uma superclasse chamada de classe-de-juno.
Veculo
Terrestre
Carro
Aqutico
Anfbio
Barco
Figura 34 Classe-de-juno anfbia
Uma caracterstica proveniente da mesma classe ancestral encontrada em mais de um caminho

herdada apenas uma vez.
No exemplo da figura 34, a caracterstica cor da classe veculo herdada tanto por veculo terrestre
como por veculo aqutico, mas a subclasse veculo anfbio, que possui herana mltipla, herda a
caracterstica cor de apenas uma das suas superclasses.
64
As subclasses provenientes de generalizaes podem ou no ser disjuntas. No exemplo da figura 34,
as classes terrestre e aqutico no so disjuntas nesse nvel, porque elas se sobrepem, isto , algum
veculo pode andar na terra e na gua.
4.8.2 Classes abstratas
Uma classe abstrata uma classe que no possui instncias diretamente, mas cujos descendentes
possuem instncias diretas. Esse tipo de classe til durante um projeto OO, para facilitar a programao
e a manuteno dos sistemas.
s vezes, til criar superclasses abstratas para encapsular classes que participam em uma mesma
associao. Algumas classes abstratas aparecem naturalmente no domnio da aplicao, outras so
artificialmente criadas como um mecanismo para permitir reuso de cdigo.
As classes abstratas so usadas frequentemente para definir mtodos para serem abordados por subclasses.
Uma classe abstrata no uma classe concreta j que no pode ser instanciada diretamente. Para
ser instancivel a classe abstrata deve possuir descendentes concretos.
J uma classe concreta pode ser uma classe de folhas (ltimo nvel da hierarquia). Uma classe abstrata
no pode ser classe de folha j que precisa de descendentes para ser instancivel.
A figura 35 mostra uma hierarquia de classes concretas e dessa forma todas podem ser instanciveis
diretamente.
Trabalhador
{incompleto}
Pedreiro
Cobrador
Aougueiro
Figura 35 hierarquia de classes concretas
A classe trabalhador tambm pode ser classe concreta, pois algumas ocupaes podem estar contidas
nelas. Dessa forma, a hierarquia {incompleto}.
Todavia, uma classe concreta pode ser refinada em vrias 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 operao Calcular_Salario( ) e que
sero programadas com lgicas especficas.
65
Unidade II
Trabalhador
{completo}
Horista
Calcular_Salrio ()
Mensalista
Calcular_Salrio( )
Autnomo
Calcular_Salrio()
Figura 36 Exemplo de classe abstrata
Nesse exemplo, a classe empregado no possui instncias diretas, e a operao Calcular_Salario( )

ser implementada por mtodos diferentes em cada subclasse. A classe de origem de qualquer estrutura
a classe definidora de mais alto nvel.
Ela define o protocolo ou assinatura da estrutura (tipo de um atributo, nmero e tipo de
argumentos e tipo de resultado de uma operao). As classes descendentes podem refinar o protocolo,
restringindo os tipos ou refazendo a inicializao ou a codificao do mtodo, mas no podem ampliar
ou modificar o protocolo.
Por exemplo: se um atributo foi definido na classe de origem, as classes descendentes podem
restringir os valores que aceitam no atributo, mas no podem modificar seu tipo.
O discriminador {completo} indica que qualquer instncia da superclasse empregado ser uma
instncia de um dos seus filhos, e a superclasse se torna abstrata.
J o discriminador {incompleto} indica que o conjunto pode esperar novas subclasses, e a
superclasse concreta. Dessa forma, a superclasse pode ser instanciada diretamente.
4.8.3 Polimorfismo (ocultamento de informaes)
O polimorfismo implica que uma mesma operao 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.
Observao
Por exemplo: mandar algum correr. Se a pessoa estiver parada, ir
sair correndo. Se a pessoa estiver no volante de um carro, ir aumentar a
presso do p no acelerador.
O polimorfismo estimulado pelo paradigma da hereditariedade, exclusivo da OO. Dentro do
polimorfismo, pode-se ter a sobreposio, a redefinio (overriding) de mtodo: o mtodo deve ter a
mesma assinatura (nome, argumentos e valor de retorno) e cdigo diferente.
66
J na sobrecarga (overloading), usa-se o mesmo nome e mais alguma caracterstica para se fazer a
mesma coisa. Dependendo dos argumentos da chamada, ser chamado o mtodo adequado.
4.8.4 Interfaces tipos e papis
A herana mltipla no permitida em algumas de programao OO diretamente. Para facilitar a
necessidade do uso desse tipo de herana, aparece o uso da interface.
Uma interface, por exemplo, na linguagem Java no uma classe, um arquivo que define valores
constantes, e as operaes que outra classe deve implementar. Ela no tem operaes/mtodos, apenas
seus prottipos.
Dessa forma, quando uma classe expe apenas constantes e operaes sem implementao, tambm
chamada de interface.
4.8.5 Pacotes lgicos
A UML define um diagrama de pacotes como sendo um modelo que descreve como os elementos so
organizados dentro de pacotes e suas dependncias. Um pacote pode estar contido em outros pacotes.
Em um diagrama de pacotes, esses so ligados por setas pontilhadas, que tm seu esteretipo
alterado de acordo com a necessidade.
Um pacote pode ter qualquer diagrama da UML, porm so mais comuns em diagrama de casos
de uso, para ajudar a abstrao do domnio do problema, e em classes, para ajudar na organizao das
classes construdas em sistemas mdios e grandes.
Uma classe tambm pode ser declarada com em pacote e, dessa forma, ter a sua visibilidade
restrita ao pacote em que reside. Classes fora desse pacote no podero sequer saber de sua existncia
e, por isso, no poder acessar classes do pacote.
Uma classe dentro de um pacote sem visibilidade definida assume a visibilidade padro do pacote.
Existe uma notao especial na UML para designar um pacote. Essa notao no deixa dvidas ao
implementador que est usando o diagrama sobre a inteno do uso do pacote.
pktLogin
Figura 37 Exemplo de um pacote
67
Unidade II
Nesse exemplo, todas as classes referentes ao login esto contidas nesse pacote. O acesso a essas
classes internas vai depender da visibilidade do pacote.
4.8.6 Objetivos do diagrama de classes
1. Mostrar a estrutura esttica do sistema.
2. Montar essa estrutura com as classes de objetos e tambm como seus relacionamentos.
3. Mapear os objetos a partir das classe de objetos com seus nomes, atributos e operaes.
4. Aplicar as propriedades e caractersticas da tecnologia OO por meio dos mecanismos de associao,
herana, polimorfismo e abstrao.
4.9 Estudo de caso aplicando modelo de classes
Para demonstrao do uso de um dos mais importantes modelos da UML, ser utilizada a descrio
de um sistema de vendas simples, com algumas funcionalidades fundamentais.
Como ferramenta de apoio preparao do estudo de caso, foi utilizada a ferramenta Case Enterprise
Architect (EA).
Saiba mais
O estudo de caso foi adaptado do exemplo apresentado no livro
Modelagem de Objetos, do autor Jos Davi Furlan, publicado pela editora
Makron Books (FURLAN, 1998).
4.9.1 Descrio do sistema
O sistema de vendas tem o objetivo de fornecer informaes unificadas, abrangentes e atualizadas
aos vendedores, incluindo a situao dos pedidos tirados, a posio de crdito dos clientes, a programao
de apresentao de produtos e a eficincia de vendas.
A fora de vendas est estruturada em filiais, zonas e setores. Uma filial atua em uma rea geogrfica.
Os vendedores das filiais atuam em zonas de vendas e um deles o responsvel pela tal. A estrutura de
visitas aos clientes pelos vendedores definida por essas zonas de vendas e distribuda aos vendedores.
As visitas ainda so organizadas semanalmente e representam perodos semanais, quinzenais e mensais.
A partir da data e do perodo de visita, o sistema encarrega-se de gerar automaticamente o roteiro
dirio que deve ser seguido pelo vendedor para cumprir sua programao de vendas.
68
4.9.2 Requisitos do sistema
A partir da descrio do sistema existem diversas alternativas de soluo. De qualquer maneira, os
requisitos independem de outra soluo especfica, mais simples ou mais complexa, j que eles mapeiam
as necessidades dos clientes em forma de sentenas.
A figura 38 apresenta o diagrama de requisitos do sistema a ser modelado.
Observao
Os requisitos so organizados em dois grupos ou pacotes. O pacote de
requisitos funcionais e o pacote de requisitos no funcionais:
O pacote que contm os requisitos funcionais apresentam
as caractersticas que representam o comportamento das
funcionalidades ou regras de negcio que o sistema deve apoiar.
O pacote de requisitos no funcionais contm os requisitos condicionantes
e nveis de desempenho que o sistema deve atender. Por exemplo: tempo
de resposta do sistema, transaes de segurana etc.
No nosso estudo, somente sero abordados os requisitos funcionais.
req Modelo de requisitos
Requisitos funcionais
RF01 O sistema deve manter atualizada a posio do cliente
RF02 O sistema deve elaborar o roteiro de visita do dia
RF03 Sistema emite informaes adicionais sobre os clientes
RF04 Gera informaes sobre filial
RF05 Analisa situao financeira do cliente
RF06 Anlise do histrico de vendas
RF07 Registra pedido de venda
Figura 38 Requisitos do sistema modelado na ferramenta EA
69
Unidade II
4.9.3 Modelo de classe do sistema
Aps uma anlise dos requisitos e reunies 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 cenrios e das funcionalidades, so descobertas as entidades envolvidas com o problema
e que sero usurias do sistema, e as entidades de dados que sero modeladas e colocadas no banco de
dados desse.
As principais classes obtidas com essa anlise so:
1. filial de venda;
2. zona de venda;
3. setor de venda;
4. cliente;
5. produto;
6. produto em cliente;
7. preo do produto;
8. pedido;
9. item de pedido;
10. nota fiscal;
11. fatura.
A figura 39 apresenta o diagrama de classes proposto para o sistema, contendo os principais atributos.
Esse modelo/diagrama denominado de modelo de domnio, j que no contm as classes de objetos
da soluo tecnolgica do sistema, tais como: classes de interface, classes de comunicao, classes de
padres e classes de banco de dados.
Essas classes completaro o modelo de domnio na fase de design do projeto.
70
class Diagrama de Classes
Cliente
Filial de venda
- numero: int
- nome: char
*
Zona de venda
- codigo: int
- nomeCompleto: char
- nomeReduzido: char
- endereco: char
- IRPJ: char
1
- telefone: char
- horarioDeVisita: int
- CondicaoDePagamento: int
- dataDaUltimaVisita: date
1
- numero: int
- nomeDoVendedor: char
- numero: int
- data: date
- situacao: int
- tipoDePedido: int
0..*
0..*
0..*
Item de pedido
0..*
Nota fiscal
- numero: int
- numero: int
- quantidade: date
- dataDeEmissao: date
- precoNegociado: int
0..* 0..* - situacao: boolean
- situacao: int
- condicaoDeEntrega: int
0..*
0..*
0..*
Setor de venda
- nome: char
- periodoDeVisita: date
Pedido
Produto em cliente
- data: date
- quantidade: int
- tipo: int
0..*
0..*
Produto
Fatura
- codigo: int
- descricao: int
- faixaDePreco: int
- valorUnitario: int
- numero: int
- dataDeVencimento: date
- valor: int
- dataEfetivaPagamento: date
Figura 39 Diagrama de classes preliminar
Nesse diagrama, temos as principais classes juntamente com seus relacionamentos.

O modelo, nesse momento, ainda no sofreu quaisquer questionamentos conceituais profundos, ou
mesmo foi promovida uma normalizao visando sua estabilidade e integridade.
As operaes dessas classes so obtidas a partir do estudo das funcionalidades descritas nos modelos
de caso de uso e diagramas de sequncia das transaes necessrias, para que o sistema atenda aos
requisitos, que no sero mostrados nesse exemplo, j que se pretende apresentar somente um exemplo
de aplicao do modelo de classes.
A figura 40 apresenta o mesmo diagrama de classes, mas com as principais operaes necessrias
para resolver o sistema.
71
Unidade II
class Diagrama de Classes
Cliente
- codigo: int
- nomeCompleto: char
- nomeReduzido: char
- endereco: char
- IRPJ: char
- telefone: char
- horarioDeVisita: int
- CondicaoDePagamento: int
Filial de venda
- numero: int
- nome: char
+ obte_Clientes_Ativos() : void
+ obter_Limite_Credito() : void
+ obter_Condicao_Entrega : void
+ obter_Condicao_Pagamento() : void
+ obter_dia_Entrega() : void
+ obter_Nome_Filial(): void
- numero: int
0..* - data: date
- situacao: int
- tipoDePedido: int
+ obter_Pedido() : void
+ incluir_Pedido() : void
0..*
Zona de venda
- numero: int
- nomeDoVendedor: char
Pedido
0..*
0..*
Item de pedido
- numero: int
- quantidade: date
- precoNegociado: int
- situacao: int
- condicaoDeEntrega: int
0..*
Nota fiscal
- numero: int
0..* 0..* - situacao: boolean
+ obter_NF_Cliente() : void
+ obter_Descricao_Produto() : void
+ obter_Preco_Produto() : void
Setor de venda
0..*
0..*
- nome: char
- periodoDeVisita: date
0..*
0..*
+ atualizar_Data_Ultima_Visita() : void
Produto em cliente
- data: date
- quantidade: int
- tipo: int
+ registrar_Estoque_Cliente() : void
+ registrr_Produto_Recolhodo() : void
Fatura
1
Produto
- codigo: int
- descricao: int
- faixaDePreco: int
- valorUnitario: int
+ obter_Descricao_Produto() : void
+ obter_Preco_Produto() : void
- numero: int
- dataDeVencimento: date
- valor: int
- dataEfetivaPagamento: date
+ obter_Faturas_Vencidas() : void
+ obter_Faturas_A_Vencer
Figura 40 Diagrama/modelo de classes com algumas operaes
O modelo de classes, quando completo, incluindo atributos e operaes, pode ser implementado em
um banco de dados e em uma linguagem de programao orientada a objetos.
Outras classes sero necessrias, tanto para o banco de dados, como para a implementao em uma
linguagem especfica nas prximas fases do desenvolvimento.
Para a fase de design, devero ser desenvolvidos os modelos de interface homem versus mquina,
que indicar as interaes dos usurios com o sistema. Para isso devero ser montados os modelos de
casos de uso com os atores e as funcionalidades.
72
Por meio do modelo de caso de uso e do prottipo, os diagramas de sequncia indicaro as mensagens
que sero trocadas entre os objetos. A partir dessas mensagens, o modelo de classe ser aumentado, e
todas as operaes ou mtodos devero ser includos nas classes especficas.
Resumo
Esta unidade apresentou uma viso da estrutura da UML. Foi discutido
que, de acordo com os autores a UML, no um modelo de processo/
metodologia de software.
Ela considerada uma linguagem padro de modelagem de sistemas e,
por isso, tem uma notao e um mecanismo para mostrar o problema, de
forma a expor a essncia do domnio de um aplicativo.
Tambm se detalhou os conceitos envolvidos com todos os diagramas
apresentados na linguagem UML, principalmente o diagrama de classes de
objetos. O detalhamento desse modelo se justifica devido sua importncia
na tecnologia orientada a objetos.
A partir desse modelo de classes detalhado, so derivadas as solues
de banco de dados e as classes que sero implementadas em linguagens
especficas. O diagrama de classes a entrada para os processos de
arquitetura e implentao, tanto do banco de dados como do aplicativo.
Uma das mensagens mais importantes com relao ao reuso de
software. Quando se trabalha com os conceitos envolvidos com o reuso de
software, o modelo de classes fundamental e apresenta os mecanismos
de herana e polimorfismo que permite um avano considervel em direo
reusabilidade.
Exerccios
Questo 1. De acordo com a IBM-Rational, a Unified Modeling Language (UML) uma linguagem
de modelagem no proprietria adotada pela OMG, e no uma metodologia de desenvolvimento. Ela
no diz como desenvolver ou manter um sistema ou software, mas auxilia a visualizar seu desenho
e a comunicao entre os objetos envolvidos com o sistema. Tambm permite que desenvolvedores
vejam os produtos de seus trabalhos em diagramas ou grficos padronizados, oferecendo uma notao
grfica, especificando os significados, isto , ela uma liguagem com uma semntica predefinida.
uma notao 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 diferena entre um modelo UML e um diagrama (ou conjunto de diagramas) de UML; um diagrama
ou grfico uma representao grfica da informao de um determinado sistema, e o modelo pode
73
Unidade II
existir independentemente. Considerando-se os conceitos sobre a UML, analise as afirmaes a seguir e
assinale a alternativa incorreta:
A) A viso de caso de uso de um sistema descreve as fucionalidades ou o comportamento do sistema
assim como os analistas e programadores de sistemas.
B) De acordo com diversos autores, o diagrama de classes de objetos o mais importante dos
diagramas da UML, pois uma classe de objetos uma coleo de objetos que podem ser descritos
com os mesmos atributos e as mesmas operaes. Tambm representam as entidades envolvidas
em um sistema de informao.
C) Para que um sistema seja executado, as classes de objetos precisam estar relacionadas ou
associadas no modelo de classes. Esse relacionamento ou associao deve estar de acordo com
as necessidades do sistema e deve cobrir as regras de negcio envolvidas com as funcionalidades
que o sistema executar.
D) Sistema a representao abstrata do mundo real; quanto mais complexo, mais necessita de
descries de seus vrios aspectos. Ele deve mostrar: a estrutura esttica dos objetos e a interao
dinmica entre eles; as caractersticas do tipo de tempo de processamento, de confiabilidade, de
usabilidade etc.; e, por ltimo, o mapeamento do modelo organizacional em termos da organizao
do trabalho, mapeamento e os cdigos.
E) Herana o mecanismo de reutilizao de atributos e operaes definidos em superclasses por
classes mais especficas, podendo ser usada para expressar tanto generalizao como associao.
Resposta: Alternativa A.
De acordo com a OMG, a UML apresenta 4 grandes objetivos: especificao de um sistema,
documentao de todos os artefatos produzidos no processo, estruturao para subvisualizao
e maior viso lgica do desenvolvimento completo de um sistema de informao. A UML uma
linguagem padronizada de se modelar sistemas de informao desenvolvidos na tecnologia da
Orientao a Objetos.
A) Incorreta. A viso de caso de uso de um sistema realmente descreve as funcionalidades ou o
comportamento de um sistema, mas tem como princpio fundamental entender os requisitos do
sistema e interpret-los graficamente. Outro fator fundamental que os Casos de Uso so como
uma linguagem de comunicao entre os usurios e os desenvolvedores de um determinado
sistema.
B) Correta. Uma classe de objetos representa uma ideia ou um conceito simples e categoriza objetos
que possuem propriedades similares, configurando-se em um modelo para a criao de novas
instncias. Exemplo: uma classe que represente um Cliente pode ser instanciada para representar
74
um cliente pessoa fsica ou um cliente pessoa jurdica, os quais possuem caractersticas semelhantes
e especficas.
C) Correta. Esses relacionamentos ou associaes definem as regras que so impostas pelas regras de
negcio da aplicao sendo modelada.
D) Correta. Cada viso apresentada em um diagrama da UML descrita por um ou mais diagramas,
que contm informaes referentes a um aspecto especfico do sistema sendo modelado.
E) Correta. Quando se usa o paradigma da herana na OO, uma classe de menor nvel (subclasse)
considerada uma classe especializada ou uma classe de extenso da classe de maior nvel
(superclasse).
Questo 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 semntica
comum. As propriedades so: os atributos e as operaes. Estas so encapsuladas no objeto. Exemplo:
em um sistema ERP, o cliente e o fornecedor so classes de objetos. Cada cliente tem um nome e
um endereo; estes seriam os atributos comuns da classe cliente. Fornecedores tambm podem ter os
mesmos atributos, nomes e endereos definidos. Entretanto, elas podem no estar definidas em uma
mesma estrutura de objetos devido distino semntica. Como se pode observar, o agrupamento em
classes no leva em conta apenas o compartilhamento de propriedades, seno essas classes deveriam
ser sempre agrupadas na mesma estrutura. Considerando-se os conceitos apresentados sobre a UML
nesta unidade, examine as afirmaes a seguir e assinale a alternativa incorreta:
A) Com a hierarquia de classes de objetos que so apresentadas no diagrama de classes e com o
mecanismo de herana, o modelo de classes de objetos potencializa o reuso no desenvolvimento
de software OO.
B) Para se ter herana mltipla em um modelo de classes, necessita-se que uma subclasse herde
atributos e operaes de mais de uma superclasse.
C) Quando um modelo de classes apresenta herana mltipla e vai ser implementado em uma
linguagem de programao OO e em banco de dados, pode-se ter problemas na transio, devido
a que esses ambientes podem no suportar a herana mltipla.
D) O uso de herana mltipla 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 diferena que
tem um modificador abstract em sua definio de atributo ou de operao. Ela no pode ser
instanciada, ou seja, no possvel obter objetos. Classes abstratas podem ser herdadas por outras
classes abstratas ou concretas, e isso possibilita o polimorfismo.
Resoluo desta questo na plataforma.
75
UNIDADE II
Questo 2
Resposta correta: alternativa D.
Justificativa: todo objeto sabe a que classe ele pertence, ou seja, a classe de um
objeto um atributo implcito do objeto. Este conceito suportado na maior parte das
linguagens de programao orientada a objetos, como C ++, ADA etc.
A) Correta. Como vrias subclasses podem herdar as propriedades de uma
superclasse, os mesmos atributos e operaes so reutilizados nas subclasses,
levando ao reso de software.
B) Correta. A herana mltipla permite que uma subclasse herde propriedades de
vrias superclasses. Exemplo: carro e barco so objetos que possuem caractersticas
semelhantes, mas diferentes comportamentos. Todavia, um anfbio pode se
comportar como um carro quando em terra e como um barco quando est na gua.
Ento, esse animal pode herdar tanto propriedades e comportamentos de carro como
do barco.
C) Correta. Exemplo: na linguagem de programao Java, no temos a
implementao da herana mltipla, e isso dificulta a transio do modelo de classes
para o cdigo na linguagem Java.
D) Incorreta. O uso de herana mltipla, apesar de no ser comum nos modelos
de sistemas OO, aparece na modelagem do mundo real, porm raramente
implementada em linguagens de programao.
E) Correta. As classes abstratas so permisses das linguagens orientadas a
objeto que permitem definir classes com a mesma estrutura de classes concretas.
Podem ser herdadas por subclasses que programam as operaes com a mesma
assinatura herdada, mas com cdigos especficos, por meio do mecanismo do
polimorfismo.
Unidade III
Unidade III
5 MODELAGEM COMPORTAMENTAL (MODELO DINMICO)
5.1 Introduo
Na abordagem de anlise da UML, a viso de modelo comportamental representa o sistema do ponto

de vista dos comportamentos e interaes do sistema com o usurio. Os diagramas que modelam o
comportamento de um sistema da UML so:
diagrama de caso de uso (use case): um diagrama de uso geral para as fases de levantamento e
anlise de requisitos do sistema;
o diagrama de estados ou mquina de estados: que procura acompanhar as mudanas sofridas
por um objeto dentro de um processo no tempo;
o diagrama de atividades: que descreve os passos a serem percorridos para a concluso de uma atividade.
os diagramas de interao: que so dividios em:
diagrama de sequncia: diagrama que descreve a ordem temporal em que as mensagens so
trocadas entre os objetos;
diagrama geral interao: uma variao dos diagramas de atividades que fornece viso geral
dentro do sistema ou processo do negcio;
diagrama de comunicao: associado ao diagrama de sequncia, complementando-o e
concentrando-se em como os objetos esto vinculados.
diagrama de tempo: diagrama que descreve a mudana de estado ou condio de uma instncia
de uma classe, ou seu papel durante o tempo.
Esta unidade abordar os principais diagramas comportamentais da UML.
Lembrete
A UML prope 13 diagramas que cobrem as estruturas estticas e os
comportamentos de um aplicativo ou sistema de software. Nesta unidade,
somente sero abordados os diagramas denominados comportamentais.
76
5.2 Modelo de casos de uso
O caso de uso nos modelos da UML um elemento que descreve como um usurio do sistema
proposto interage com o sistema para realizar uma determinada tarefa discreta.
Ele descreve e significa uma interao simples, a todo o tempo, que tenha significado para o usurio
(uma pessoa, uma mquina ou outro sistema).
Um caso de uso, de acordo com a UML:
tipicamente, tem requisitos e restries que descrevem as facilidades e regras sobre as quais ele
opera;
pode ter um diagrama associado (diagrama de sequncia ou de atividades) que ilustre seus
comportamentos ao longo do tempo: quem faz o qu, para quem e quando.
tipicamente, tem cenrios associados com ele e que descrevem o fluxo de trabalho durante todo
o tempo que realiza suas tarefas, at produzir os resultados finais.
a especificao da OMG UML afirma: um caso de uso um tipo de classificador de comportamento
que representa uma declarao de um comportamento oferecido.1
Cada caso de uso especifica alguns comportamentos, possivelmente incluindo variantes, as quais
pode executar em colaborao com um ou mais atores.
Lembrete
Os elementos de casos de uso so utilizados para construir modelos de
caso de uso. Eles descrevem a funcionalidade do sistema a ser construdo,
os requisitos, as restries e como o usurio interage com o sistema.
Muitas vezes, os diagramas de sequncia so associados com casos de uso para capturar o fluxo de
trabalho e o comportamento do sistema.
5.2.1 Diagramas de caso de uso
O diagrama ou modelo de casos de uso mostra o que existe fora do sistema (atores) e o que pode ou
deve ser executado pelo sistema (casos de uso).
Os casos de uso so importantes, pois provm uma ferramenta para capturar os requisitos do sistema,
ou seja, o que o sistema necessita disponibilizar para possibilitar a execuo das atividades do negcio.
1
UML Superestrutura Especificao, verso 2.1.1, p. 592.
77
Unidade III
O conjunto de casos de uso do sistema representa a funcionalidade desse, isto , a totalidade de
maneiras de se utilizar o sistema.
Um diagrama de caso de uso um grfico de:
atores;
conjunto de casos de uso do sistema, encapsulados pela fronteira desse;
a associao entre os atores e os casos de uso utilizados por eles; e
os eventuais relacionamentos entre os prprios casos de uso.
A figura 41 mostra um exemplo de um diagrama tpico de casos de uso.
uc Use Case Model
Faz login
Usurio
<<extend>>
Registra
Usurio
Figura 41 Diagrama ou modelo de casos de uso
5.2.1.1 Atores
Os atores representam toda a necessidade de troca de informao com o sistema. Eles constituem,
portanto, o ambiente do sistema (seres humanos, mquinas, agrupamentos lgicos, outros sistemas).
A diferena entre atores e usurios que um ator representa certa regra que um usurio pode utilizar
na interao com o sistema, e o usurio a pessoa que est usando aquela regra, naquele momento.
Dentro da tecnologia OO, o ator uma classe, enquanto o usurio uma instncia daquela classe.
A instncia existe apenas enquanto o usurio est fazendo algo no sistema, portanto, o mesmo usurio
pode ser instncia de vrios atores no sistema.
78
A figura 42 mostra a notao de Ator na UML.
Cliente
Figura 42 Notao de ator
O cone padro do esteretipo do ator a figura do stick man. O nome do ator deve ser sempre um
substantivo no singular, por exemplo: cliente, professor, operador etc.
Observao
A especificao da OMG UML2 afirma:
Um ator modela um tipo de papel desempenhado por uma entidade
que interage com o sistema (por exemplo, intercmbio de dados e sinais),
mas que externo ao sistema.
Atores podem representar papis desempenhados por usurios humanos, de hardware externo ou
de outros sistemas.
Note que um ator no representa, necessariamente, uma entidade fsica especfica, mas apenas uma
faceta particular (isto , papel) de alguma entidade que relevante para a especificao de seus casos
de uso associados.
Saiba mais
Vale a pena fazer download do manual da OMG Unified Modeling
Language (OMG UML), o Infrastruture verso 2.3, que se encontra gratuitamente
disponvel em: <http://www.omg.org/spec/UML/2.3/Infrastructure>, e possui
todas as definies e caractersticas dos modelos da UML.
Assim, uma nica instncia fsica pode desempenhar o papel de vrios atores diferentes e,
inversamente, um determinado ator pode ser jogador de vrias instncias diferentes.
5.2.2.2 Casos de uso
Uma instncia de um ator desencadeia a execuo de um caso de uso no sistema. Na UML, um caso
de uso representado por uma elipse com seu nome em texto dentro.
2
79
Unidade III
A figura 43 mostra um exemplo da notao de caso de uso na UML.
Receber
Pagamento
Figura 43 Notao de caso de uso
Um caso de uso , portanto, um conjunto de transaes, executadas em uma determinada sequncia,

em dilogo com o sistema.
Alm 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 instncia dessa classe chamada de cenrio. Cada cenrio retrata a sequncia de interaes
entre atores (estmulos e respostas) e classes do sistema (consultas e atualizaes), com todas as
alternativas de deciso (e respectivas aes) definidas.
Um cenrio (instncia de caso de uso) pode ser desencadeado:
por meio de um evento externo (estimulado por um usurio instncia de um ator); ou
por um evento temporal (o sistema toma a iniciativa a partir de um algoritmo interno tempo
transcorrido, mudana de estado etc.)
Para se representar os cenrios de um caso de uso, podem ser utilizados outros diagramas da UML, tais
como, os diagramas de interao: diagrama de atividades, diagrama de sequncia ou de comunicao.
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 padro que todos sigam
na empresa, por exemplo: emitir recibo ou emite recibo.
Observao
O diagrama de casos de uso exerce um papel importante na anlise
de sistemas no momento de se entender e especificar as necessidades do
cliente ou usurio, j que:
o principal diagrama para ser usado no dilogo com o usurio na
descoberta e validao de requisitos;
o diagrama pode ser construdo a partir do prottipo do sistema, pois
mostra os usurios (atores) interagindo com o sistema, de acordo
com as telas, pginas ou relatrios apresentados no prottipo;
80
os casos de uso constituem elementos que estruturam todas as
etapas do processo de software.
5.2.1.3 Para identificar casos de uso
A partir do levantamento das necessidades do cliente ou de um usurio, a identificao dos casos de
uso devem seguir um roteiro, conforme o sugerido a seguir:
O que cada ator necessita ou deve ser capaz de fazer com ou para o sistema. Um ator pode
armazenar, eliminar, alterar ou ler informaes.
Que tarefas devem ser executadas para suprir deficincias da atual implementao do
sistema.
Quais tarefas executar que a implementao atual no supre (novas funcionalidades).
5.2.1.4 Casos de uso empregados por mais de um ator
Quando vrios atores do mesmo tipo utilizam o mesmo caso de uso, possvel identificar um ator
abstrato e tornar os outros atores do mesmo tipo que o utilizam herdeiros dele. Ou ainda, eleger um ator
como usurio do caso de uso e tornar os demais atores seus herdeiros.
5.2.1.5 Casos de uso utilizados por outros casos de uso
Um relacionamento de extenso (extend) de um caso B (caso estendido) para um caso A (caso
bsico) indica que instncias especficas de A podem incluir B.
Portanto, um caso de uso de extenso normalmente criado para mostrar comportamentos
especiais e de exceo, que complementam o caso bsico, quando aquelas condies
excepcionais ocorrerem.
A figura 44 mostra um caso de uso com extenso.
uc Use Case Model
<<extend>>
Figura 44 O uso da extenso
No exemplo da figura 45, somente nas instncias do caso de uso receber pagamento em que o prazo
estiver vencido que o caso calcular juros de mora ser utilizado como extenso.
81
Unidade III
uc Use Case Model
Receber
pagamento
<<extend>>
Calcular juros
de mora
Figura 45 Uso de extend (extenso)
Um relacionamento de incluso (include) de um caso A para um caso B indica que uma instncia
do caso A incluir, tambm, as instncias do caso B. Nesse caso, o caso de uso B sempre ser acionado
quando o caso de uso A estiver ativo. A figura 46 mostra esse caso.
uc Use Case Model
<<include>>
Figura 46 Uso do include
A figura 47 mostra um exemplo de include. Nesse caso, sempre que o caso de uso receber pagamento
for ativado, o caso de uso emitir recibo tambm ser acionado.
uc Use Case Model
Receber
pagamento
<<include>>
Emitir
recibo
Figura 47 Uso do include (incluso)
Para todas as instncias do caso de uso receber pagamento, ser usado o caso de uso emitir recibo.
O caso de uso emitir recibo poder ser usado tambm por outros casos de uso.
Tanto o relacionamento de extenso (extend) como de incluso (include) so provenientes de
fatorao de casos de uso maiores, sendo que:
extenso normalmente descreve variaes de um comportamento normal, e
incluso revela comportamentos utilizados por mais que um caso de uso (reuso de caso de uso).
5.2.1.6 Especificao do modelo de caso de uso
A UML no especfica um formato rigdo para os cabealhos e a estrutura de um caso de uso. Eles
podem ser alterados de acordo com as necessidades de documentao dos sistemas.
82
O quadro 4 a seguir mostra um exemplo de especificao de um caso de uso de alto nvel.
Quadro 4 Descrio de um caso de uso de alto nvel
Caso de uso
Atores envolvidos
Tipo
Comprar Itens
Cliente e operador
Primrio
Descrio
Um cliente chega ao caixa com itens para

comprar. O operador registra os itens e coleta o
pagamento. Ao final, o cliente sai com os itens.
O quadro 5 mostra um exemplo de um caso de uso extendido (detalhado).

Quadro 5 Caso de uso extendido
Caso de uso
Atores envolvidos
Comprar itens com dinheiro

Cliente e operador
Propsito
Capturar uma venda e seu pagamento em dinheiro.
Descrio
Um cliente chega ao caixa com itens para comprar.

O operador registra os itens e coleta um pagamento
com dinheiro. Ao final, o cliente sai com os itens.
Tipo
Referncia
Primrio e essencial .
Requisitos funcionais: R1, R2, R3 (requisitos).
O quadro 6 mostra a sequncia de eventos do exemplo do quadro 5. Aes dos atores e do sistema
durante a ocorrncia de compra.
Quadro 6 Sequncia de eventos em uma compra de cliente
Ao do ator
Resposta do sistema
1. Este caso de uso comea quando um cliente chega ao

caixa com itens para comprar.
Se h mais de um do mesmo item, o operador tambm
pode informar a quantidade.
3. Determina o preo do item e adiciona

informao sobre o item transao de venda em
andamento. Mostra a descrio e o preo do item
corrente.
4. Aps processar o ltimo item, o operador indica ao

sistema.
5. Calcula e mostra o valor total da venda.
2. O operador registra o identificador de cada item.
6. O operador informa o total ao cliente.

7. O cliente entrega um pagamento em dinheiro,
possivelmente maior do que o valor total.
8. O operador registra o valor recebido em dinheiro.
10. O operador deposita o dinheiro e retira o troco devido.
O operador entrega o troco e o recibo ao cliente.
9. Mostra o troco devido.

Emite um recibo.
11. Registra a venda no log de vendas completadas.
12. O cliente sai com os itens comprados.
83
Unidade III
Essa sequncia de eventos ainda pode comportar os eventos de excesso ou sequncia de erros.
Essas sequncias devem ser colocadas como caminhos alternativos e podem merecer que novos casos
de uso possam ser definidos para comport-las.
Saiba mais
O autor Martin Fowler escreveu com Kendall Scott um livro denominado
UML Distilled, que resume a UML e discute todos os modelos ou diagramas
envolvidos com a linguagem. O livro se encontra na sua 3 edio. Ele foi
traduzido para o portugus pela editora Bookman em 2004, e se chama
UML Essencial Um breve guia para a linguagem padro de modelagem
de Objetos.
O livro UML Essencial descreve a maioria dos tipos de diagramas
UML, sua utilizao e a notao bsica envolvida na criao. Esses
diagramas incluem classes, sequncia, objeto, pacote, instalao,
casos de uso, mquina de estados, atividades, comunicao, estruturas
compostas, componentes, viso geral da interao e diagramas de
temporizao.
Os exemplos so claros e as explicaes chegam ao fundamento lgico
de projeto de software orientado a objetos.
5.2.1.7 Estudo de caso com o modelo de caso de uso
Para demonstrao da aplicao do modelo de caso de uso da UML, ser utilizada a descrio 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 preparao do estudo de caso, foi utilizada a ferramenta Case Enterprise
Architect (EA).
Saiba mais
O estudo de caso foi adaptado do exemplo apresentado no livro
Modelagem de objetos, do autor Jos Davi Furlan, publicado pela Makron
Books (FURLAN, 1998). Foi um dos autores brasileiros pioneiros na divulgao
da UML no Brasil.
84
Ferramentas Case:
O termo Case (Computer-Aided Software Engineering) signfica Engenharia de software auxiliada
por computador.
Antigamente, os engenheiros de software desenvolviam software para outras reas, tais como,
Engenharia, Arquitetura, Medicina etc., mas no se utilizavam de software para fazer seu trabalho,
confirmando o velho ditado casa de ferreiro, espeto de pau.
Com a necessidade de aumentar a produtividade e melhorar a qualidade, foram obrigados a
desenvolver tambm software para uso prprio.
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 presena de ferramentas Case vital hoje em dia para o bom funcionamento desse ambiente, e elas
existem apoiando todo o ciclo de desenvolvimento (anlise, projeto, implementao, teste e manuteno).
H tambm ferramentas Case para apoiar a gerncia dos projetos de desenvolvimento, a gerncia de
configurao e a gerncia de riscos.
Sem ferramentas, uma metodologia ou mtodo no ter boa aceitao 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 diagramao.
Hoje em dia, h tambm a difuso do termo I-Case, que usado para caracterizar um grupo de
ferramentas Case integradas, isto , que se relacionam entre si (entradas e sadas) e que permitem
controlar a consistncia dos dados quando uma metodologia seguida.
Vantagens das ferramentas Case:
Maior qualidade dos produtos finais: as ferramentas Case diminuem a probabilidade de erros, uma
vez que podem ajudar no controle de consistncia dos dados em um ambiente de desenvolvimento
de software; tambm proporcionam maior eficcia dos produtos, ao auxiliarem as fases de anlise
e teste do produto pelo usurio.
Produtividade: ao ajudar na realizao de tarefas e at mesmo ao realizar algumas
automaticamente, as ferramentas contribuem para uma maior agilidade no desenvolvimento
de software, isto , mais produtos em menos tempo.
85
Unidade III
Eliminao de trabalho montono: as ferramentas Case podem realizar algumas tarefas cansativas
para os desenvolvedores, tais como, procurar informaes e desenhar smbolos de um diagrama,
as quais so mais suscetveis ao erro.
Mais tempo para a tomada de deciso: em consequncia das ferramentas realizarem certas
atividades pelas pessoas, essas ficam liberadas para outras tarefas, geralmente mais nobres, que
exigem tomada de deciso e criatividade, ao invs de tarefas repetitivas.
Flexibilidade para mudanas: as ferramentas permitem que sejam mudados dados e diagramas de
maneira mais rpida e fcil, o que ajuda o desenvolvedor no trabalho de atender s necessidades
do usurio.
Menos programao: as ferramentas eliminam muito do trabalho de programao, deixando mais
tempo para que a equipe tcnica se preocupe com a anlise do sistema, que onde se define
como solucionar o problema do usurio.
Melhor documentao: por armazenarem dados e diagramas, as ferramentas tambm contribuem
para uma melhor documentao do sistema, agilizando relatrios, busca de informaes e
alteraes.
Manuteno mais fcil e gil: por consequncia do item anterior, possvel ter mais informaes
sobre o software na hora de realizar sua manuteno (correo, atualizao ou expanso).
5.2.1.8 Descrio do sistema exemplo de uso do modelo de caso de uso
O sistema de vendas tem o objetivo de fornecer informaes unificadas, abrangentes e atualizadas
aos vendedores, incluindo a situao dos pedidos tirados, posio de crdito dos clientes, a programao
de apresentao de produtos e a eficincia de vendas.
A fora de vendas est estruturada em filiais, zonas e setores. Uma filial atua em uma rea geogrfica.
Os vendedores das filiais atuam em zonas de vendas, e um deles o responsvel pela zona de vendas.
A estrutura de visitas aos clientes pelos vendedores definida por zona de vendas e distribuda aos
vendedores. As visitas ainda so organizadas semanalmente e representam perodos semanais, quinzenais
e mensais.
A partir da data e do perodo de visita, o sistema encarrega-se de gerar automaticamente o roteiro
dirio que deve ser seguido pelo vendedor para cumprir sua programao de vendas.
5.2.1.8.1 Requisitos do sistema
A partir da descrio do sistema, existem diversas alternativas de soluo. De qualquer maneira, os
requisitos independem de outra soluo especfica, mais simples ou mais complexa, j que eles mapeiam
as necessidades dos clientes em forma de sentenas.
86
A figura 48 apresenta o diagrama de requisitos do sistema a ser modelado.
Os requisitos so organizados em dois grupos ou pacotes. O pacote de requisitos funcionais e o
pacote de requisitos no funcionais:
O pacote que contm os requisitos funcionais apresenta as caractersticas que representam o
comportamento das funcionalidades ou regras de negcio que o sistema deve apoiar.
O pacote de requisitos no funcionais contm os requisitos condicionantes e nveis de desempenho
que o sistema deve atender. Por exemplo: tempo de resposta do sistema, transaes de segurana
etc.
No nosso estudo, somente sero abordados os requisitos funcionais. Ler foneticamente.
req Modelo de requisitos
Requisitos funcionais
RF01 O sistema deve manter atualizada a posio do cliente
RF02 O sistema deve elaborar o roteiro de visita do dia
RF03 Sistema emite informaes adicionais sobre os clientes
RF04 Gera informaes sobre filial
RF05 Analisa situao financeira do cliente
RF06 Anlise do histrico de vendas
RF07 Registra pedido de venda
Figura 48 Requisitos do sistema modelado na ferramenta EA
5.2.1.7.2 Modelo de caso de uso do sistema

O primeiro passo para modelar o sistema a partir dos requisitos apresentados na figura 48, que
definem os casos de uso que descrevem o que o sistema de suporte a vendas ir oferecer em termos de
funcionalidades.
Os atores envolvidos so 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 srie de informaes do
sistema, mas no interage com o sistema diretamente para entrada de dados ou para consultas online.
87
Unidade III
A figura 49 apresenta uma possvel viso de soluo para o sistema. O diagrama ou modelo de caso
de uso no mostra as solues de arquitetura do sistema, mostra apenas os atores interagindo com as
funcionalidades dele.
uc Modelo de Caso de Uso
Manter
cliente
Mostra
detalhes do
cliente
<<extend>>
Elabora o
roteiro de
visita
Informa
visita
<<include>>
Coloca
pedido
Vendedor
Manter filial
Gera
informaes
sobre filial
Cliente
<<include>>
<<include>>
Analisa
situao
Analisa
financeira
histrico de
vendas
Figura 49 Modelo de caso de uso do estudo de caso
5.2.1.8.3 Especificaes do modelo de caso de uso

Inicialmente, deve-se descrever os atores envolvidos com o sistema e suas interaes.
Ator vendedor:
O vendedor, com base na zona e setor de vendas da filial, solicita a elaborao do roteiro de visita
a clientes do dia.
O vendedor, a partir do roteiro de visitas, programa seu deslocamento a clientes.
O sistema dever estar preparado para informar o vendedor sobre a localizao dos logradouros e
as principais alternativas virias de acesso ao cliente.
O sistema deve estar preparado para fornecer informaes adicionais sobre os clientes para apoiar
o vendedor na venda.
O vendedor acessa o sistema para obter dados gerais sobre a filial.
88
O vendedor analisa e discute com o cliente a situao da fatura com o cliente, tanto as faturas
vencidas, como as faturas a vencer nos prximos perodos.
O sistema permite que o vendedor analise a mdia de vendas por produto nos ltimos meses, por
meio do histrico de vendas ao cliente.
Aps a formalizao do pedido de venda, o vendedor faz as ltimas anotaes 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 tambm recebe uma cpia do pedido depois de dada a
entrada pelo vendedor.
Aps as descries dos atores e de suas interaes com o sistema, o desenvolvedor dever descrever
os casos de uso, usando padro definido pela organizao em que trabalha.
Ser mostrada, como exemplo, a descrio do caso de uso manter filial, que de responsabilidade
do vendedor. A ferramenta Case utilizada o EA.
Descrio geral:
A fora de vendas est estruturada em filiais, zonas e setores. Uma filial atua em uma rea
geogrfica. Os vendedores das filiais atuam em zonas de vendas e um deles o responsvel
pela zona de vendas.
Pr-condies: vendedor autorizado no sistema.
Ps-condies: filial liberada para uso.
Caminho bsico:
Nome: inclui filial.
Descrio (passos):
1. Vendedor responsvel entra com dados da Filial.
2. Sistema valida filial.
3. Vendedor responsvel entra com dados da zona de venda.
4. Sistema valida zona de venda.
89
Unidade III
5. Sistema associa zona de venda filial.
6. Vendedor responsvel entra com dados do setor de vendas.
7. Sistema valida setor de vendas.
8. Vendedor responsvel associa setor de vendas zona de venda.
9. Vendedor responsvel associa outros vendedores zona de vendas.
Caminho alternativo:
Nome: altera filial.
Descrio (passos):
1. Vendedor responsvel entra com filial.
2. Sistema valida filial.
3. Vendedor altera dados da filial.
4. Sistema altera dados da filial.
5. Vendedor responsvel entra com dados da zona de venda/ setor de vendas a serem alterados.
6. Sistema valida zona de venda/setor de vendas.
7. Sistema altera dados da zona ou setor de vendas.
8. Vendedor associa/disassocia zona de venda a filial.
9. Sistema altera dados no banco de dados.
Nome: exclui filial.
Descrio (passos):
1. Vendedor responsvel entra com filial/zona de venda ou setor de vendas que quer
excluir.
2. Sistema valida filial/zona e setor de vendas.
90
3. Sistema verifica se existe cliente com pedido pendente.
4. Sistema exclui vendedores da lista da filial.
5. Sistema elimina filial/zona ou setor de vendas.
Nome: erros.
Descrio (passos):
1. Filial/zona ou setor de vendas invlido.
2. Filial/zona ou setor de vendas j existe.
3. Filial/zona ou setor de vendas no existe.
4. No possvel eliminar filial/zona ou setor de vendas.
6 Outros modelos comportamentais da UML
6.1 Introduo
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 usurio
de um sistema.
Todavia, outras necessidades de representar a realidade surgem quando os analistas de sistemas esto
desenvolvendo ou especificando todas as abordagens necessrias para um entendimento completo do
sistema que est sendo construdo.
Para dar apoio aos desenvolvedores com relao ao comportamento do sistema perante uma
determinada realidade ou situao, a UML prope diversas alternativas de modelos que devem
ser utilizados de acordo com as caractersticas do sistema ou do tipo de aplicao necessria para
automatizar um determinado processo de negcio.
Os modelos comportamentais, alm do modelo de caso de uso, so: diagrama de atividades, diagrama
de estados ou mquina de estados. Outro diagrama importante abordado nesta unidade o diagrama
de sequncia, sendo que os diagramas de comunicao e de tempo no sero detalhados por no serem
os mais utilizados na prtica da UML.
91
Unidade III
6.2 Diagrama de atividades
Um diagrama de atividade um fluxo que representa as passagens de uma atividade para outra
durante um fluxo de trabalho. Seu propsito estudar os fluxos dirigidos por processamento interno,
descrevendo as atividades em uma operao.
Esse diagrama tem sido usado para desenhar as lgicas dos cenrios dos casos de uso, ou a lgica de
processamento de uma operao de uma classe de objetos mais complexa.
A notao de um diagrama de atividades da UML usa os seguintes smbolos:
Quadro 7 Smbolos do diagrama de atividade
Smbolos
Atividade
Breve descrio
Representa uma atividade realizada por um usurio ou
pelo sistema.
Representa a passagem de uma atividade para outra.
Esta passagem tambm chamada de gatilho (trigger).
tambm chamado de fluxo de controle.
Smbolo de deciso.
Podem-se apontar diversas entradas ou sadas para esse
smbolo de deciso.
Pode indicar que uma atividade chegou neste ponto e
foi subdividida em mais de uma atividade (fork).
Caso diversas atividades chegem neste ponto e saiam
para uma nica atividade. O smbolo chama-se Join.
Smbolo de incio ou entrada em um fluxo de
atividades.
Pode haver vrios pontos de entrada para um processo.
Smbolo de sada de um processo.
Pode haver diversos pontos de sada para um processo.
Fluxo final.
O X dentro do smbolo indica o final de um fluxo que
no seja uma sada normal do processo.
act Use Case Model
Swimlanes: este smbolo reproduz as raias de uma

piscina.
Indica o confinamento de um conjunto de atividades
em uma determinada rea da empresa.
usada para organizar logicamente uma atividade.
A figura 50 mostra um exemplo da aplicao do diagrama de atividade.
92
Avaliar item
em estoque
Registrar
pedido
Autorizar forma
de pagamento
Cancelar
pedido
OK?
Aceitar
pedido
Figura 50 Exemplo de diagrama de atividade
6.3 Diagrama de sequncia
O diagrama de sequncia mostra os objetos e as mensagens sendo trocadas entre eles, necessrias
para a execuo de uma determinada tarefa, evidenciando a ordem em que as coisas acontecem, sem
mostrar as associaes entre os objetos.
Um diagrama de sequncia uma representao estruturada de comportamento com uma srie
de etapas sequenciais ao longo do tempo. Ele usado para descrever o fluxo de trabalho, passagem de
mensagens e mostrar como elementos em geral cooperam no tempo para alcanar um resultado.
Esse diagrama pode ser usado para mostrar a evoluo de uma dada situao em um determinado
momento do software, mostrar uma dada colaborao entre duas ou mais classes e pode, tambm, ser
usado para mostrar a traduo de um caso de uso, desde a interao com o usurio at a finalizao
daquele dado processo (MEDEIROS, 2004).
Os objetos so mostrados na parte superior do grfico e, para cada objeto, desenhada uma linha
vertical, que representa sua linha de vida.
As mensagens so 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 vo ocorrendo de cima
para baixo na sequncia de eventos.
Cada elemento da sequncia organizado em uma sequncia horizontal, com mensagens que
passam para trs e para frente entre os elementos.
93
Unidade III
Um elemento de ator pode ser usado para representar o usurio 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 interaes.
A figura 51 mostra um diagrama de sequncia de um evento em que uma pessoa est telefonando,
essa pessoa chamada de chamador.
Os objetos telefone chamador e telefone chamado tambm interagem para que o telefonema
acontea.
sd Use Case Model
Telefone
chamador
Chamador
chamador levanta receptor( )
Telefone chamado
Linha de
vida do
objeto
sinal de discar comea ( )

disca ( )
Ativao
disca ( )
disca ( )
telefone ocupado ( )
som da campainha ( )
telefone toca ( )
atenda telefone ( )
telefones interligados ( )
telefones interligados ( )
pessoa chamada desliga ( )
conexo desfeita ( )
conexo desfeita ( )
chamador desliga ( )
Figura 51 Exemplo de diagrama de sequncia
94
6.3.1 Linha de vida
As linhas pontilhadas na vertical representam a existncia do objeto em um determinado tempo.
Se uma determinada mensagem representa a criao da instncia do objeto, sua linha de vida iniciase naquele ponto.
Se ela representa a destruio do objeto, a linha termina nesse ponto e a sequncia termina.
Se o objeto existe durante todo o processo, a linha de vida permeia todo o espao vertical
do diagrama.
A linha de vida pode se bifurcar em duas ou mais linhas concorrentes para mostrar
condicionalidades.
6.3.2 Ativao
Uma ativao evidencia o perodo de tempo em que um objeto est executando uma ao,
diretamente ou a partir de um procedimento subordinado.
A ativao representada por um retngulo de base pequena e cuja altura representa o tempo da
ao (o topo do retngulo coincide com o incio da ao e a base com o seu fim).
A ao a ser executada pode ser colocada em uma etiqueta na proximidade da ativao ou na
margem esquerda do diagrama, ou estar implcita na mensagem que aciona a ativao.
6.3.3 Autodelegao
Evidencia a mensagem cujo objeto emissor (remetente) coincide com o objeto alvo (destinatrio).
Trata-se de uma chamada recursiva. Se a chamada recursiva se der sobre uma ativao, desenha-se
outro retngulo aninhado com o primeiro, para mostrar a autodelegao.
6.3.4 Mensagem
Uma comunicao entre objetos, que leva informao com a expectativa de que resultar em uma
atividade.
O recebimento de uma mensagem normalmente considerado um evento. Mensagem a unidade
fundamental da comunicao entre objetos.
A recepo de uma mensagem causa a invocao de uma operao no recebedor (objeto alvo). Esse
executa o mtodo da classe que corresponde quela operao.
95
Unidade III
As mensagens so representadas por setas nomeadas, colocadas nas proximidades da ligao, 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 implementao de uma mensagem pode tomar vrias formas: a chamada procedure, a passagem
de sinal entre threads ativas, o especfico acionamento de um evento etc.
6.4 Diagramas de estado (mquina de estado)
O diagrama de estados representa, para uma determinada classe de objetos, seu padro de eventos,
estados e transio de estados.
Um diagrama de estados uma rede de estados e eventos.
Na realidade, somente constri-se diagrama de estados para as classes que possuem comportamento
dinmico importante.
6.4.1 Estado
Um estado uma abstrao dos valores de atributos e ligaes de um objeto. Por exemplo: a linha
telefnica est no estado sinal de discar.
Caso o dgito seja discado, a linha muda de estado, indo para o estado discando. Se o usurio
recolocar o telefone no gancho, a linha telefnica 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 solvncia
ou de insolvncia depende do seu ativo exceder o seu passivo.
Com o passar do tempo, os objetos estimulam uns aos outros, resultando em uma srie de alteraes
em seus estados.
6.4.2 Notaes
Na UML, o estado representado por um retngulo, como no diagrama de atividades. Um retngulo
com o nome do estado representa um estado simples.
Um retngulo maior designa um estado composto ou mquina de estados. Quando outros estados
(simples) esto participando de determinado composto, so desenhados em seu interior.
96
Pseudo_estado_inicial
Estado_composto
Estado_simples
Est_simples 1
Est_simples 2
Pseudo_estado_final
Figura 52 Smbolos do diagrama de estado
6.4.3 Evento
Um estmulo individual de um objeto A que o objeto B reconhece e reage um evento.
Objeto
A
Objeto
Estmulo
Figura 53 Evento entre objetos
O objeto B reage ao estmulo 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 estmulos.
Os eventos possuem os seguintes tipos: mensagem, tempo transcorrido e condio de guarda.
Um evento algo que acontece em um certo momento com os objetos de uma classe. Por exemplo:
um usurio aperta o boto cancelar, o cliente desconta um cheque.
Um evento pode logicamente preceder ou suceder outro evento. Dois eventos podem no estar
relacionados, nesse caso, so chamados de concorrentes.
Cada evento uma ocorrncia nica, que pode ser agrupada em classes de eventos.
Cada classe de eventos recebe um nome para indicar estrutura e comportamentos comuns.
O exemplo a seguir demonstra uma classe de eventos:
O voo 100 parte de So Paulo.
O voo 200 parte de Fortaleza.
O voo 30 parte de Porto Alegre.
97
Unidade III
Pode-se criar a classe partida de avies e tratar esses voos como instncias da classe. Os atributos
dessa classe seriam: linha_area, nmero_do_voo, cidade_origem, cidade_destino etc.
A Figura 54 mostra exemplos de classes de eventos:
Partida_avies
Boto_do_mouse_
levantado
Empresa_aerea
Nmero_do_voo
Cidade_destino
Boto
localizao
Altera_destino()
Figura 54 Exemplo de classes de eventos
6.4.4 Transio
A modificao de estado causada por um evento chamada de transio. A reao de um
objeto a um evento pode constituir-se de uma ao que provoca uma modificao de estado no
objeto.
Um estado corresponde ao intervalo entre dois eventos recebidos por um objeto.
Os eventos correspondem a pontos no tempo, e os estados representam intervalos no tempo,
como mostra a Figura 55.
Estados de um objeto
t (objeto)
Evento 1
Evento 2
Figura 55 eventos e estados
Na definio de estados, ignoram-se os atributos que no afetam o comportamento dos

objetos.
Englobam-se em um s estado todas as combinaes de valores de atributos e ligaes que
apresentam a mesma reao dos eventos.
O diagrama de estados ou diagrama de mquina de estados determina ou especfica a sequncia de
estados causada por uma sequncia de eventos.
A Figura 56 mostra um exemplo de eventos para uma classe conta de cliente de um banco.
98
Inativa
Depsito_Cliente
Mensagem
rejeitado
Depsito_Rejeitado
Depositando
Depsito_Aceito
Ativa
Figura 56 Exemplo de um diagrama de estado
Um diagrama de estados uma fonte de descoberta de operaes. Ajuda a descobrir tambm novos
estados, regras de integridade e definir com mais preciso os domnios dos atributos envolvidos.
A figura 56 mostra um exemplo de um sistema de biblioteca.
Cadastramento
Publicao
indisponvel
Emprstimo de
todos exemplares
Correo de erros
de digitao
Liberao da publicao
Publicao
disponvel
Devoluo do emprstimo
Retirada por emprstimo
Depsito_Aceito
Indisp.
temporria
(alienada)
Figura 56 Diagrama de estados
Saiba mais
Vale a pena ler o material disponvel no endereo: <http://www.
fabriciosousa.com/APS_Diagrama_Estados.pdf>.
Este material est baseado no livro Princpios de anlise e projeto de
sistemas com UML, de Eduardo Bezerra, 2 ed., Editora Campus/Elsevier.
99
Unidade III
Resumo
Esta unidade apresentou conceitos da modelagem comportamental
dos sistemas de informao.
Diversos diagramas e modelos da UML so utilizados para se modelar
os comportamentos dos sistemas, mas esta unidade deu nfase ao modelo
de caso de uso que, para alguns autores, o principal modelo de UML,
juntamente com o modelo de classes de objetos.
Como os modelos estruturais so fundamentais para se definir a
estrutura de um sistema, sua composio e dependncias, os modelos
comportamentais mostram as aes que durante o tempo acontecem com
o sistema e com os atores que com ele interagem.
A UML apia o processo de desenvolvimento UP (Unified Process). Ele
considerado um processo use case driven, o que significa um processo
dirigido por casos de uso.
O modelo de caso de uso mostra o sistema realizando uma sequncia
de aes, para receber entradas dos usurios e gerar sadas para responder
as necessidades do negcio. Da a sua importncia no desenvolvimento
moderno e a nfase dada a ele nesta unidade.
De todos os diagramas da UML, juntamente com o diagrama
de casos de uso e o diagrama de classes, o diagrama de sequncia
considerado um dos mais importantes, principalmente no momento da
programao.
Com ele, pode-se passar a ordem e a sequncia de chamadas dos
objetos para resolver determinada lgica ou cenrio de um caso de uso. Por
sua vez, o diagrama de estado descreve o comportamento de um objeto de
uma determinada classe de objetos.
J com o diagrama de estados, so modelados os eventos que podem
ser representados como operaes nos modelos de objetos. O modelo
dinmico de uma classe herdado por suas subclasses. As subclasses
herdam os estados e as transies de seus ancestrais. As subclasses podem
ter seus prprios diagramas de estado.
100
Exerccios
Questo 1. Os processos de desenvolvimento de software que se baseiam na UML como linguagem
de modelos denominam o modelo de caso de uso como o orientador do processo (use case driven). Nesse
modelo, temos trs elementos considerados bsicos: o Ator, o Caso de Uso e a Associao entre o ator e o
caso de uso. O ator usado para definir o papel que um utilizador ou usurio representa relativamente ao
sistema de informao modelado. Ele representa um conjunto coerente de papis que os usurios de casos
de uso desempenham quando interagem com esses casos de uso. Pode-se afirmar que um ator representa
um papel que um ser humano, um dispositivo de hardware ou at outro sistema desempenha com o
sistema. A UML define que um usurio do sistema representado pelo ator pode ser: uma pessoa; outro
sistema de informao; um equipamento hardware especializado; a passagem de tempo. Considerando-se
os conceitos apresentados sobre a UML, analise as afirmaes a seguir e assinale a alternativa incorreta:
A) Na UML, o modelo de caso de uso importante, j que auxilia na captura de requisitos do sistema
que ser construdo.
B) Os casos de uso de um diagrama de Caso de Uso representam as funcionalidades que sero
implementadas em um sistema de informao.
C) Os atores representam o ambiente externo do sistema (seres humanos, mquinas, agrupamentos
lgicos, outros sistemas).
D) Como a UML apresenta modelos e elementos na tecnologia OO, pode-se afirmar que um Ator
uma classe de objetos.
E) O cone que representa um ator no diagrama de casos de uso um retngulo com diversos
segmentos.
Resposta: Alternativa E.
Na UML, o modelo de caso de uso descreve como os usurios do sistema (entidades externas ao
sistema), interagem com o sistema enviando ou recebendo informaes.
A) Correta. Quando o analista de sistemas precisa representar as necessidades do cliente ou usurio,
utiliza o modelo de caso de uso da UML; este permite ao usurio mapear os requisitos em torno
dos usurios e das funcionalidades do sistema.
B) Correta. No modelo de caso de uso, o elemento que representa as funcionalidades do sistema e
que executar os requisitos do sistema o prprio caso de uso.
101
Unidade III
C) Correta. Como os atores esto 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 execuo do sistema. O ator que representa os usurios do sistema tambm ser
instanciado na execuo 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.
Questo 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 extenso que complementam os cenrios do caso de uso
bsico modelo. Considerando-se os conceitos apresentados sobre o modelo de caso de uso, analise as
afirmaes a seguir e assinale a alternativa incorreta:
A) Um modelo de casos de uso um modelo das funes pretendidas do sistema e suas vizinhanas,
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 comunicao entre as pessoas envolvidas com o sistema.
C) Os usurios e qualquer outro sistema que pode interagir com o sistema sendo modelado com o
diagrama de caso de uso so os atores.
D) O modelo de casos de uso no uma ferramenta til na negociao entre os desenvolvedores e
os clientes/usurios devido sua complexidade tcnica.
E) Os casos de uso so desenvolvidos com base nas necessidades dos atores. Isso garante que o
sistema ser o que os usurios esperam.
102
UNIDADE III
Questo 2
Resposta correta: alternativa D.
Justificativa: quando uma funcionalidade (caso de uso) for complexa, prope-se
uma decomposio em funes mais detalhadas, entretanto, um dos pontos mais
difceis aprender como determinar em que nvel de detalhe os casos de uso devem
"comear e terminar". Os casos de uso ou os requisitos do software devem
estabelecer "o que" o sistema executa, mas no "como" ele executa.
A) Correta. Quando o modelo de caso de uso criado, ele deve ser aprovado pelo
cliente ou usurio do futuro sistema. Dessa forma, ele pode ser usado para garantir
aos clientes ou aos usurios que a equipe entendeu o problema e que vai tomar uma
soluo adequada.
B) Correta. O modelo de caso de uso foi desenvolvido para facilitar a comunicao
da equipe de desenvolvimento entre os seus componentes e com os clientes ou
usurios do sistema. Dessa forma, ele considerado uma ferramenta de
comunicao no processo de desenvolvimento de sistemas.
C) Correta. O Ator representa os usurios que iro interagir com o sistema, seja
por meio da entrada de dados ou como receptor das sadas do sistema.
D) Incorreta. O modelo de casos de uso um dos modelos mais simples da UML,
sendo que essa simplicidade e os poucos smbolos grficos permitem que pessoas
sem grandes conhecimentos tcnicos em sistemas consigam interpret-lo.
E) Correta. O modelo de caso de uso tem por finalidade mapear as necessidades
ou os requisitos de um sistema e a ferramenta de comunicao entre os envolvidos
com o sistema.
Unidade IV
7 MODELAGEM DA ARQUITETURA DE NEGCIO
7.1 Introduo
Processos de negcio so atividades previamente estabelecidas que tm como objetivo determinar

a forma como o trabalho realizado numa organizao.
Constituem um conjunto de aes, relacionadas entre si de forma lgica e coerente, a fim de
promover uma sada favorvel organizao, tanto em termos internos como externos.
Uma estrutura de processos de negcio mal concebida pode por em risco a eficincia e a eficcia de
uma empresa por meio dos produtos e servios que gera e disponibiliza.
Dada a similaridade das suas composies, funo de negcio e processo de negcio so conceitos
que frequentemente suscitam dvidas entre as pessoas interessadas em formar um melhor entendimento
a respeito dos elementos de uma arquitetura de negcios.
Ambos so coisas que a empresa faz, entretanto, os processos so transfuncionais (ou horizontais),
j que perpassam diversas barreiras funcionais dentro da organizao (por exemplo: adquirir bem,
alienar bem, contratar funcionrio), enquanto que as funes, que em conjunto descrevem a misso da
empresa, so verticais (por exemplo: contabilidade, vendas, logstica).
Um outro aspecto relevante, e que pode representar uma mais valia na implementao dos processos de
negcio numa organizao, tem a ver com a implementao de um sistema de informao bem estruturado.
A existncia de uma boa rede de informao, entre todos os intervenientes nos processos de negcio
da organizao, condio sine qua non, uma vez que permite a comunicao em tempo real, tornando
possvel uma adequada tomada de deciso, resultante do ajuste contnuo de procedimentos que ir
repercutir em toda a dinmica organizacional e, consequentemente, na excelncia dos seus resultados.
Desse modo, quando se fala em processos de negcio, a abrangncia enorme, pois o seu mbito de
atuao transversal e atua em todas as reas da organizao, com elevado impacto na qualidade dos
servios e/ou produtos, na reduo de custos e no desenvolvimento do prprio negcio.
Por outro lado, a existncia de uma interface entre os processos de negcio e uma rede de sistemas
de informao constituem fatores-chave fundamentais, quer para a generalidade dos negcios dos
tempos de hoje, quer para a produo de indicadores e instrumentos de controle efetivo para uma
constante monitorizao das atividades da organizao.
103
Unidade IV
Assim, como a Figura 57 sugere, pode-se definir processos de negcio como um conjunto de atividades
desenvolvidas a partir de um objetivo predefinido que ir concretizar-se num resultado especfico, em
termos de produto ou servio que se pretenda realizar.
Pessoas
Objetivo
Equipamento
Informao
Processos de negcio
Resultado
Que tarefas especficas?

Qual a prioridade?
Quais os procedimentos?
Figura 57 Processos de negcio
7.2 Modelagem de negcio
Para compreender uma organizao, necessrio entender seus processos de negcio. Profissionais
da Tecnologia da Informao se empenham em construir solues que tm por finalidade auxiliar a
empresa na conquista de maior espao no mercado globalizado.
Nesse contexto, os processos so avaliados e, sempre que possvel, informatizados, de forma a
promover vantagens competitivas a partir do alinhamento estratgico entre o sistema e o negcio da
empresa.
Para a OMG (Object Management Group, 2005), um processo de negcio corresponde a um conjunto
coeso de atividades que criam um resultado, o qual garante a criao de valor a um cliente externo
ou interno empresa, ou, visto de outra forma, pode ser um conjunto de tarefas regido por regras de
negcio e que se desenvolve a partir de um determinado evento de negcio.
Segundo Laudon e Laudon (2001), um processo de negcio refere-se maneira pela qual o trabalho
organizado, coordenado e focado, para produzir um produto ou servio de valor.
De um lado, processos de negcios so fluxos de trabalhos concretos de materiais,
informaes e conhecimentos. De outro, referem-se tambm maneira singular de as
organizaes coordenarem trabalho, informao e conhecimento, e de como a gerncia prefere
coordenar o trabalho.
J a modelagem de negcio uma tcnica de modelagem de alto nvel, que surgiu das dificuldades
identificadas pelos analistas de sistemas.
104
uma abstrao voltada realidade dos administradores, assim, estudiosos e pesquisadores da
rea de TI criaram uma tcnica de modelagem de alto nvel denominada de modelagem de negcio,
que hoje parte integrante no processo de desenvolvimento de software e que serviu para facilitar
a comunicao com as pessoas que fazem parte do negcio mas no possuem conhecimentos de
Engenharia de software.
Observao
Os autores Michael Hammer e James Champy afirmam:
Um processo de negcio uma coleo de atividades que usam um ou mais tipos
de entrada e criam uma sada que seja de valor para o cliente. Um processo de negcio
tem um objetivo e afetado por eventos que ocorrem no mundo externo ou em outros
processos.
Lembrete
A tcnica de modelagem de negcio profundamente relacionada
arquitetura de negcios.
Observao
J o autor Thomas Davenport aponta que o processo de modelagem de
negcios:
[...] um conjunto estruturado de atividades, desenhado para produzir
um resultado especificado para um cliente ou um mercado em particular. Isso
implica forte nfase sobre como o trabalho feito dentro da organizao,
em contraste com o foco no produto. Um processo ento uma ordenao
especfica de atividades de trabalho, por meio do tempo e do espao, com
comeo e fim e entradas e sadas claramente dentificadas: uma estrutura
para ao.
7.2.1 Conceitos de negcio
Funes de negcio so estruturas conceituais idealizadas que servem para descrever a misso de
uma organizao. Uma vez que tenham sido definidas e decompostas adequadamente, elas se mantm
estveis ao longo do tempo, mesmo diante de reorganizaes da empresa.
Como so perenes, as funes representam um ponto de referncia (conceitos comuns) ao se
descrever diferentes negcios, que de outra forma exibiriam variaes significativas.
105
Unidade IV
A Figura 58 exemplifica o relacionamento dentro de uma organizao entre as funes de negcio e
os processos de negcio a partir das atividades organizacionais e atividades de processos.
act Business Process Model
Funo de negcio
Atividade de negcio
Atividade componente
do processo
Processo de negcio
Subprocesso
componente de processo
Figura 58 Funo de negcio, processo de negcio e seus relacionamentos
Como exemplo da aplicao dessa definio, temos o fato de que a funo contabilidade de uma
empresa define o contador, a funo gerencial define o gerente e assim por diante.
Funes de negcio so tambm alocadas a unidades ou reas organizacionais especficas (que
exercero os diferentes papis) e so envolvidas e acionadas no decorrer do comportamento do
negcio.
A Figura 58 mostra que uma funo corresponde a uma srie de atividades relacionadas, envolvendo
uma ou mais entidades de dados, realizadas com o objetivo de se cumprir um ou mais objetivos da
misso da empresa.
As atividades de negcio que compem uma funo de negcio so relacionadas entre si por
afinidade, porque trabalham um grupo comum de entidade de dados (clientes e produtos) ou porque
so sequenciais ou paralelas na realizao do trabalho associado a um resultado final comum.
Observao
A arquitetura de negcio busca uma viso conceitual e nica de uma
atividade ou funcionalidade, de forma que se possa identificar quando e
como ela se repete nos diversos processos de negcio, a fim de determinar
106
a generalizao dos conceitos de tarefas comuns, identificando atividades
compartilhadas e administrando seu reuso por meio da distribuio dos
componentes que as suportam.
Da mesma forma, os sistemas de informao que suportam tais funes estaro focados em
aspectos especficos do funcionamento do negcio, independentemente da forma como a empresa est
organizada.
As atividades so direcionadas a dados e so iniciadas por transaes ou solicitaes de dados. Elas
so a poro ativa das funes e tendem a ser repetitivas e formalizadas.
Observao
importante notar:
Uma maneira de se diferenciar o conceito de funes e atividades
que, geralmente, as funes so gerenciadas e atividades so
realizadas.
Funes so gerenciais e atividades so operacionais.
J um processo de negcio definido como a sequncia completa de um comportamento de
negcio, provocado por algum evento, que produz um resultado significativo para o negcio e que, de
preferncia, tenha foco no cliente.
No percurso do processo, desde o evento inicial at a produo de um determinado resultado,
vrias funes do negcio podem estar envolvidas. Assim, diz-se que os processos so elementos
transfuncionais, j que perpassam diversas funes dentro da organizao.
Se uma funo composta de atividades que representam um papel ou razo de existir da
organizao, os processos de negcio executam essas atividades de forma que, individualmente ou
combinadas, realizem o trabalho de uma determinada funo.
Um estudo de aplicao de modelagem de processo de negcio para apoiar a
especificao de requisitos de um sistema
Antes de entrarmos em duas notaes de modelagem de processos seria interessante
analisarmos os resultados obtidos com a aplicao da modelagem apresentada no artigo
Um estudo de aplicao de modelagem de processo de negcio para apoiar a especificao
de requisitos de um sistema, dos autores Adriana Andrade, Andriele Ribeiro, Eduardo Borges
e Wolber Neves, apresentado no VI Simpsio Internacional de Melhoria de Processos de
Software, em So Paulo, em 2004.
107
Unidade IV
No item resultados obtidos, os autores afirmam:
A aplicao da modelagem de processos de negcio trouxe resultados bastante positivos.
A execuo dessa etapa antes da realizao do levantamento dos requisitos do sistema foi
um fator de reduo de riscos, tanto para o cliente quanto para o fornecedor.
O cliente pde ter uma viso melhor do seu negcio, identificando as reas que realmente
seriam beneficiadas pela construo do sistema, evitando assim o desperdcio de recursos.
Foi interessante observar que, durante as oficinas, o cliente pde perceber que
determinados processos no estavam sendo executados da melhor forma. Diante desta
percepo, alguns processos foram remodelados, evitando que o sistema fosse construdo
sobre uma base operacional deficiente.
Para o fornecedor, a execuo da modelagem de processos de negcio resultou em
maior facilidade na gesto dos requisitos do sistema. Muitas das constantes mudanas
que ocorrem durante o desenvolvimento de um sistema decorrem da inexistncia de um
consenso entre os representantes do cliente sobre a melhor forma de se executar um
processo.
A modelagem de processos de negcio fez com que esse consenso fosse alcanado antes
do incio do levantamento dos requisitos do sistema, tornando esta etapa mais eficiente.
A identificao dos casos de uso do sistema (UML) tambm foi bastante facilitada. Como
passaram a conhecer melhor a realidade do cliente, os engenheiros de requisitos puderam
ser mais proativos nessa atividade, contribuindo com sugestes e ponderaes baseadas em
conhecimento mais slido.
Esta proatividade mostrou-se especialmente til nas primeiras oficinas, j que naquele
momento os representantes do cliente ainda no estavam totalmente seguros com a
metodologia de levantamento dos requisitos.
Outro benefcio trazido pela modelagem de processos de negcio diz respeito
rastreabilidade dos requisitos. Uma caracterstica de qualidade importante para uma
especificao de requisitos a facilidade em se determinar os resultados do desenvolvimento
que sero afetados por cada requisito (rastreabilidade para frente), bem como a origem de
cada um (rastreabilidade para trs).
Como os requisitos foram derivados diretamente do modelo de processos de negcio, a
rastreabilidade para trs foi garantida documentando-se, para cada requisito, o processo de
negcio que o gerou.
Um ponto importante no desenvolvimento de um sistema, especialmente quando seu
porte no pequeno, a sua diviso em produtos. A diviso uma maneira formal de se
108
exercitar o desenvolvimento incremental, j que produtos coesos e de menor porte so
entregues em menor tempo do que um nico mdulo que contemple todas as funes.
Isto importante tanto do ponto de vista tcnico quanto do de negcio, j que muitas
vezes o cliente no dispe de recursos para construir todo o sistema de uma s vez, e a
priorizao de requisitos dentro de um mdulo nico no uma tarefa simples.
Esse foi tambm um ponto em que a modelagem de processos de negcio foi benfica.
Antes de sua realizao, cliente e fornecedor imaginavam que o sistema seria composto por
trs produtos. Aps a modelagem, percebeu-se que o nmero de produtos era realmente
trs, mas a composio dos mesmos foi bastante modificada. Dois dos produtos foram
agrupados em um nico, e um produto de controle de fluxo de trabalho (workflow) foi
identificado.
Apenas um produto permaneceu conforme tinha sido concebido no incio. A diviso
inicial dos produtos espelhava a diviso funcional da empresa, o que no se mostrou uma
boa idia do ponto de vista de sistemas. A modelagem de processos de negcio fez com
que cliente e fornecedor percebessem que duas das reas eram muito integradas, o que
justificaria um nico produto para atend-las.
Da mesma forma, o problema de controle de fluxo de trabalho era comum a todas as
reas funcionais, o que justificaria um produto genrico para este fim, e no a insero de
funcionalidades correlatas em um dos produtos especficos para determinada rea.
Aps a diviso dos produtos, um deles foi escolhido para ser especificado e construdo.
Seria necessrio, portanto, realizar uma estimativa do tamanho do produto em pontos
de funo, para orar-se a fase de elaborao. O melhor conhecimento da organizao,
conseguido por meio da modelagem de processos de negcio, tambm foi fundamental
para que essa estimativa fosse bem prxima da contagem oficial de pontos de funo,
realizada alguns meses depois (aps o fim da elaborao).
Percebeu-se inclusive que a aproximao do nmero real foi maior do que em projetos
em que a modelagem de processos de negcio no foi usada.
Como ltimo resultado importante, podemos citar o artefato resultante da modelagem de
processos de negcio. Esse documento importante para o cliente, j que a documentao
dos processos da organizao. Mas tambm do ponto de vista do fornecedor o documento
foi de grande utilidade, pois serviu para dar uma viso geral s pessoas que entravam no
projeto depois de seu incio. Foi uma forma simples e barata de integrar novas pessoas
equipe.
Adaptado de: <www.simpros.com.br>. Acesso em: 13 jul. 2012.
109
Unidade IV
7.2.2 Extenso de negcio da UML
Segundo Paul e Serrano (2003), o estudo sobre processo de negcio no deve ser isolado, sendo
importante seu relacionamento com a rea de TI, pois ela considerada sua grande modificadora.
O processo de negcio geralmente confia no suporte fornecido pelos Sistemas de Informao (SI)
para a realizao de suas atividades.
Similarmente, esses sistemas dependem da infraestrutura de comunicao, normalmente oferecido
por rede de computadores (RC).
A Figura 59 demonstra o relacionamento existente entre processos, sistemas de informao e redes
de computadores, no qual mudanas ocorridas em alguns dos domnios devem afetar os demais.
Processo1
Processo2
SI2
SI1
TI
Processon
RC1
...
SIn
RCn
Figura 59 Relacionamento de processos, Sistemas de Informao (SI) e

Redes de Computadores (RC)
De acordo com Dalal et al (2004), muitas tcnicas para modelagem dos processos empresariais, incluindo
DFDs (Diagramas de Fluxo de Dados), Idef0 (Definies Integradas para Modelagem por Funes, em nvel
0) e diagramas de casos de uso de negcio, tm suas razes nos processos de desenvolvimento de software.
De acordo com as orientaes da UML 2.0 Superstructure Specification, disponibilizada a partir de
outubro de 2004 pela OMG, os casos de uso so meios de especificar os requisitos de um sistema de
informao.
Todavia, quando casos de uso documentam processos de negcio de uma organizao, o Sistema
sob Discusso (SsD), do ingls System under Discussion (SuD), a prpria organizao.
Os stakeholders ou atores de negcio so os acionistas da companhia, clientes, vendedores e as
agncias governamentais regulamentadoras. Os atores primrios incluem os clientes da companhia e
talvez seus fornecedores. Um caso de uso apenas documenta um processo, ele no faz reEngenharia, ou
seu projeto novamente (COCKBURN, 2005).
Um caso de uso especifica o comportamento de um sistema ou de parte de um sistema e uma
descrio de um conjunto de sequncias de aes, incluindo variantes realizadas pelo sistema para
produzir um resultado observvel do valor de um ator.
110
Alm disso, os casos de usos podem ser aplicados para captar o comportamento pretendido do sistema
que est sendo desenvolvido, sem ser necessrio especificar como esse comportamento implementado.
Tambm fornecem uma maneira para os desenvolvedores chegarem a uma compreenso comum com os
usurios finais do sistema e com os especialistas do domnio 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 organizao, os casos de uso so identificados
como casos de uso de negcio.
Em outras palavras, um caso de uso de negcio representa o que a organizao faz (BOGGS e BOGGS,
2002). O escopo de um caso de uso pode abranger uma escala de assuntos:
Uma empresa ou uma linha de negcio: este nvel de modelo utilizado para descrever como os
sistemas se integram.
Um sistema individual: este o nvel mais utilizado na abordagem por casos de uso.
Um simples subsistema simples ou componente: este nvel descreve os mecanismos de
implementao de um elemento do modelo.
Para descrever um processo de trabalho de um negcio.
Para focar discusso sobre futuros requisitos de software.
Para ser os requisitos funcionais de um sistema.
Para documentar o projeto do sistema.
Para ser escrito em um grupo pequeno e restrito, ou em um grupo grande ou distribudo.
O modelo de casos de uso de negcio um modelo das funes pretendidas do negcio. usado
como base para identificar papis e produtos liberados na organizao.
Os casos de uso de negcios so identificados e possivelmente resumidos no incio da fase de
iniciao, para ajudar a definir o escopo do projeto (RUP, 2001).
Quadro 8 Propriedades de um caso de uso de negcio
Nome da propriedade
Descrio
Nome
O nome do caso de uso de negcio.
Breve descrio
Uma breve descrio do papel e da finalidade do caso de uso de negcios.
Metas
Uma especificao das metas ou objetivos mensurveis do caso de uso de negcios.
Metas de desempenho
Uma especificao das mtricas relevantes ao caso de uso de negcios e uma

definio das metas de utilizao dessas mtricas.
111
Unidade IV
Fluxo de trabalho
Uma descrio textual do fluxo de trabalho representado pelo caso de uso de

negcios. O fluxo deve descrever o que o negcio faz para oferecer vantagens
a um ator de negcio, e no como esse negcio resolve os problemas. A
descrio deve ser compreensvel para qualquer pessoa dentro do negcio.
Categoria
Se o caso de uso de negcios pertence categoria central, suporte ou

gerenciamento.
Risco
Uma especificao dos riscos de executar e/ou implementar o caso de uso de

negcios.
Possibilidades
Uma descrio do potencial de melhoria estimado do caso de uso de negcios.
Proprietrio do processo
Uma definio de quem o proprietrio do processo de negcios: a pessoa que

gerencia e planeja as mudanas.
Requisitos especiais
As caractersticas do caso de uso de negcio no cobertas pelo fluxo de

trabalho conforme descrito.
Pontos de extenso
Uma lista dos locais dentro do fluxo de eventos do caso de uso de negcios
em que um comportamento adicional pode ser inserido por meio do
relacionamento de extenso.
Relacionamentos
Os relacionamentos (como associaes de comunicao, relacionamentos de

incluso e de extenso) dos quais o caso de uso participa.
Diagramas de atividades
Esses diagramas mostram a estrutura do fluxo de trabalho.
Diagramas de casos de uso
Esses diagramas mostram os relacionamentos que envolvem o caso de uso.
Ilustraes do fluxo de trabalho
Resultados ou esboos manuscritos provenientes das sesses de encenao.

Adaptado de: RUP, 2001.
De acordo com o RUP (2001), os elementos de um modelo de caso de uso de negcio podem ser
demonstrados conforme o quadro 9.
Quadro 9 Componentes do diagrama de caso de uso de negcio
Nome
112
Notao
Descrio
Ator de negcio
Um ator de negcio representa um papel

desempenhado em relao ao negcio por
algum ou algo no ambiente do negcio.
Caso de uso de negcio
Um caso de uso de negcios define uma

instncia de negcio, no qual cada instncia
uma sequncia de aes realizada por um
negcio que produz um resultado de valor
observvel para um determinado ator de
negcio.
Modelo de caso de uso de negcio
O modelo de casos de uso de negcios um

modelo das funes pretendidas do negcio.
usado como base para identificar papis e
produtos liberados na organizao.
Generalizao de ator
Um relacionamento de generalizao de uma

classe de ator de negcio (descendente) com outra
classe de ator de negcios (ascendente) indica que
o descendente herda o papel que o ascendente
pode assumir em um caso de uso de negcios.
Associao de comunicao
Uma associao de comunicao entre um caso

de uso e um ator indica que uma instncia
do caso de uso e uma instncia do ator iro
interagir.
Relacionamento de extenso
Um relacionamento de extenso aquele que

se estabelece entre um caso de uso de extenso
e um caso de uso base, especificando como o
comportamento definido para o caso de uso de
extenso pode ser inserido no comportamento
definido para o caso de uso de base. Ele
inserido implicitamente, ou seja, a extenso no
exibida no caso de uso base.
extenso
Um relacionamento de incluso aquele que

se estabelece entre um caso de uso base e um
caso de uso de incluso, especificando como
o comportamento definido para o caso de uso
de incluso inserido de forma explcita no
comportamento definido para o caso de uso
base.
incluso
Relacionamento de incluso
Generalizao de casos de uso
Uma generalizao de casos de uso um

relacionamento de um caso de uso filho com
um caso de uso pai, especificando como um
filho pode adotar todo o comportamento e as
caractersticas descritas para o pai.
Diagrama de casos de uso
Um diagrama de casos de uso mostra os atores

de negcios, os casos de uso de negcios, os
pacotes de casos de uso e seus relacionamentos.
De acordo com o RUP (2001), a projeo realizada pela Engenharia de negcio fundamental para
a realizao do sistema.
As atividades do negcio e os relacionamentos identificados entre elas, bem como a atuao dos
envolvidos, determinaro os objetivos a serem alcanados pelo software a ser desenvolvido.
A Figura 60 apresenta uma conexo entre essas duas reas.
Proposta para informatizao
Proposta
de software
Engenharia de
processo de negcio
Engenharia
de software
Modelo de negcio
Figura 60 O relacionamento entre Engenharia de processo de negcio e Engenharia de software
113
Unidade IV
7.2.3 Vises de modelos de negcio
O modelo de negcios a forma pela qual uma empresa cria valor para todos os seus principais
pblicos de interesse.
Sua utilizao ajuda a ver de forma estruturada e unificada os diversos elementos que compem
todas as formas de negcios da organizao.
O modelo de negcio de uma empresa composto por 5 principais elementos:
Modelo de proposta de valor: a forma pela qual a empresa define qual o seu diferencial
no mercado, a forma pela qual nica e se destaca de todas as demais empresas que participam
desse mesmo mercado.
Modelo de interface com o consumidor: o que escreve onde, quando e como uma empresa
interage com os seus consumidores. Essa interao pode se dar por meio de lojas, embalagens de
produtos, comerciais, SAC, website etc.
Modelo de operao: como que uma empresa faz para levar o seu produto at o seu consumidor.
Esse modelo deve prever todos as etapas necessria para viabilizar sua produo, passando por
logstica, at chegar s mos de quem compra o seu produto ou servio.
Modelo estratgico: a descrio de como uma empresa ir atingir os seus objetivos estratgicos.
Nesse modelo onde visualiza-se a misso de uma empresa, sua viso, seus valores e todas as
competncias necessrias para que a empresa funcione de forma adequada.
Modelo econmico: onde se demonstra a viabilidade financeira de uma empresa. Esse
modelo mostra como uma empresa ganha recursos e paga suas despesas a fim de atingir a
sustentabilidade.
7.3 OCL e sua utilizao na modelagem de processo de negcio
A OCL (Object Constraint Language) uma notao que permite se dar mais preciso nas especificaes
ou modelos que usam a UML.
Lembrete
A OCL baseada na lgica e matemtica discreta. Assim como a UML,
uma linguagem de modelagem e no uma linguagem de programao.
uma linguagem de modelos tipada. Inicialmente, a OCL era uma extenso
para a UML, agora parte da UML padro.
114
Por que a OCL?
Um diagrama UML, tal como o diagrama de classes, tipicamente no refinado o suficiente para
permitir-se ter todos os aspectos relevantes de uma especificao.
H a necessidade de se descrever restries adicionais sobre os objetos de um modelo.
A linguagem natural inerentemente ambgua.
Linguagens formais tradicionais so dificeis para usurios de negcio ou modeladores de sistemas.
A OCL uma linguagem formal que permanece simples para ler e escrever.
Quando se deve usar a OCL?
A linguagem OCL usada para expressar condies constantes de restries de especificaes
para sistemas que esto sendo modelados.
Para especificar invariantes nas classes e tipos no modelo de classes.
Para especificar tipos invariantes para esteretipos.
Para descrever pr e ps-condies nas operaes e mtodos.
Para especificar restries nas operaes.
A OCL suportada para os seguintes tipos de diagramas da UML 2.0, como mostrta a quadro 10.
Quadro 10 Diagramas com suporte OCL
Tipo de diagrama
Verso da UML
Como o suporte provido
Use case (caso de uso)
UML 2.0
Restries para o comportamento associado

com os casos de uso como expresses OCL.
Por exemplo, uma interao escolhida como
um comportamento.
Classes (classe, namespace e

comunicao)
UML 1.5 e 2.0
Restries na criao de objetos so

suportadas.
Interao (sequncia e comunicao)
UML 2.0
Restries de invarincia de estado para

linhas de vida e restries dos operandos de
fragmentos combinados como expresses OCL.
Mquina de estado
UML 2.0
Condies de guarda de transies como

expresses OCL.
Como os modelos de negcio so suportados pelos diagramas de casos de uso a OCL, esses apoiaro
as restries das pr e ps-condies para execuo de um caso de uso de negcio.
115
Unidade IV
7.4 Integrao com o desenvolvimento de software
Num processo iterativo de desenvolvimento de software, a equipe do projeto segue uma srie de
fases, cada uma focando diferentes partes do negcio ou sistema. Existem duas abordagens para a
modelagem de negcio em um ambiente iterativo:
Primeiro, terminar toda a modelagem de negcio e, na sequncia, iniciar as atividades iterativas
(anlise, design, codificao, teste e implantao).
Alternativamente, pode-se incluir a modelagem de negcio nas iteraes (BOGGS e BOGGS, 2002).
Para Boggs e Boggs (2002), tanto num processo iterativo, como num modelo de processo do tipo
cascata, a modelagem de negcio surge nas fases iniciais.
As razes pelas quais isso ocorre que a modelagem de negcio determina o contexto para o
projeto. As figuras 60 e 61 mostram o aparecimento da modelagem de negcio nos processos de
desenvolvimento de software.
Modelagem de negcio
Anlise
Implantao
Design
Teste
Implementao
Figura 61 Processo iterativo aps o surgimento da modelagem de negcio
Modelagem
de negcio
Anlise
Implantao
Design
Teste
Implementao
Figura 62 Modelagem de negcio como fase integrante do processo iterativo
7.4.1 Processo de desenvolvimento de software

Existem inmeros caminhos para reproduzir modelos de negcio dentro dos processos de
desenvolvimento de software, incluindo o uso de outras notaes tais como Idef0 (modelagem
funcional), ou mesmo descries textuais do processo.
116
No entanto, a UML um padro bem definido, suportado por muitas tcnicas. a linguagem de
modelagem dominante, usada em sistemas de informao orientados a objeto.
A UML na atualidade o padro que possui a melhor definio, suportada por muitas ferramentas e,
dessa forma, tornou-se a linguagem de modelagem dominante na aplicao da tecnologia da orientao
a objetos.
Alm disso, pode ser utilizada para a modelagem de negcio e tambm para a modelagem de
outros sistemas, ou seja, para aqueles que no sero utilizados para o desenvolvimento de softwares
(OMG, 2005).
Para Widrig e Leffingwell (2003), os principais modelos para a modelagem de negcio so: business
use-case e business object model. Diagramas num modelo de negcio ajudaro a compreender o que a
organizao fornece de valor, dentro de um relacionamento.
Enquanto a maioria dos diagramas da UML foca no sistema que ser construdo, o modelo de casos
de uso de negcio se concentra no negcio em torno desse sistema (BOGGS e BOGGS, 2002).
O modelo de caso de uso de negcio consiste na interao entre atores e casos de uso, para
demonstrar a sequncia de eventos necessrios na realizao de um trabalho.
Juntos, atores e casos de uso descrevem o que est envolvido nas atividades do negcio e tambm
como ele ocorre (WIDRIG e LEFFINGWELL, 2003).
7.4.2 Arquitetura de negcio e arquitetura de software
Um dos principais esforos da investigao relacionada com a Engenharia de software tem sido
a definio e representao de modelos que descrevam os processos de software, garantindo que
esses correspondam fidedignamente s necessidades efetivas (em forma e contedo) dos processos
de negcio.
Deparamo-nos ento com duas realidades complementares: a modelagem dos processos de negcio
e a modelagem do software, que tambm podem ser chamadas de arquitetura de negcio e arquitetura
de software, na qual esta ltima tem cada vez mais a necessidade de estar em sintonia com toda a
abrangncia do negcio (RODRIGUES, 2004).
As modelagens de negcio e de sistema (software) so frequentemente desenvolvidas como parte
de dois diferentes projetos com dois diferentes times. Ambas devem possuir boa definio, pois so
ferramentas importantes para o gerenciamento da complexidade da amplitude e dificuldade do sistema
(PENKER e ERIKSSON, 2000).
Rodrigues (2004), ao avaliar o contexto da modelagem de negcio para a modelagem de sistema,
especifica que ainda existe um caminho a ser percorrido para que a ponte entre esses dois domnios seja
estabelecida de forma suave e sem sobressaltos.
117
Unidade IV
A Figura 63 mostra a integrao proposta por Rodrigues (2004).
Modelagem do processo
Modelagem de sistema
O que existe para fazer a ponte efetiva

entre modelagem de negcio e sistema?
Figura 63 Integrao entre modelagem de negcio e sistema
No RUP (2001), a integrao entre negcio e sistema tem incio nas primeiras atividades da iterao
do ciclo de desenvolvimento do sistema, definida como iniciao.
Nesse momento, a maior parte dos esforos, para as disciplinas Modelagem de Negcios e Requisitos,
utilizada com o propsito de obter as informaes necessrias para a conduo do projeto e elaborao
do software.
A Figura 64 demonstra, no detalhe, o esforo necessrio na fase inicial da iterao, a partir do
desenho de viso geral do RUP.
Fases
Disciplinas
Iniciao
Elaborao
Construo
Transio
Modelagem de negcios
Requisitos
Concentrao
de esforos nas
fases iniciais.
Figura 64 O esforo da modelagem de negcios e requisitos
A Figura 64 mostra que as disciplinas de Modelagem de Negcios e Requisitos do Sistema so

perfeitamente integradas e dependentes ao longo do processo de desenvolvimento iterativo RUP.
Um conceito atual que vem sendo tratado pelos autores e as empresas de tecnologia o gerenciamento
de processos de negcio ou business process management.
118
Saiba mais
Vale a pena conferir o documento Business Process Management Enabled
by SOA, da IBM de 2009, em que o gerenciamento de processos de negcio
mais frequentemente associado com o ciclo de vida de um de processos
de negcios. O ciclo de vida de processo de negcio abrange identificar
e melhorar os processos que proporcionam capacidade de negcios para
implantar e gerenciar os seus processos quando estiver operacional.
O que frequentemente esquecido a gesto do desempenho do processo depois que operacional.
De certa forma, essa provavelmente a fase mais importante do ciclo de vida de processos. Depois que
um processo de negcio implantado, ele deve ser gerenciado, e, para gerenciar o processo de negcio,
deve-se ter visibilidade do desempenho de processos.
Quando um processo no atingir mais o seu desempenho de seus objetivos, hora de voltar ao
ciclo de vida para avaliar a causa raiz do problema de desempenho e buscar oportunidades de melhoria
adicionais.
Subjacente, BPM tambm governana. Governana um componente essencial de BPM porque
fornece a estrutura que garante que a estratgia de negcios e metas sejam implementadas no nvel
operacional.
A estrutura de governana tambm permite negcio e alinhamento de TI, fornecendo mecanismos
que aumentem a colaborao e cooperao entre os dois mundos, os processos de negcio e a tecnologia
da informao.
8 A modelagem de processos de negcio
8.1 Viso Erikson e Penker
Antes que a OMG se preocupasse com a modelagem de negcios com a linguagem UML, os autores
Erikson e Penker (2000) propuseram um metamodelo para a modelagem dos processos de negcio, o
qual apresenta:
Uma viso de mais alto nvel, visando identificar a situao do negcio que ser abordada.
Nessa viso, deve-se definir o contexto e o escopo, sendo que:
o contexto o que est relacionado, qual a situao, descrio do problema; e
o escopo at onde vai, contorno ou limite.
119
Unidade IV
Essa viso pode incluir FCSs (Fatores Crticos de Sucesso).
As metas e objetivos (do original Goal) podem ser decompostos em diferentes nveis, como,
estratgico/ttico/operacional, sendo que:
o objetivo qualificvel; e
a meta quantificvel.
Nesse modelo, os processos de negcio:
possuem uma meta;
possuem entradas e sadas especficas;
usam recursos;
possuem um nmero de atividades, realizadas em alguma ordem, que podem ser vistas como
subprocessos;
afetam mais de uma unidade da organizao;
criam valor para algum consumidor (interno ou externo).
A figura 65 apresenta os elementos ou smbolos propostos para o modelo de Erikson e Penker.
<<processo>>
Processo A
<<processo>>
<<processo>>
<<processo>>
Subprocesso A1
Subprocesso A1
Subprocesso A1
Atividade A2a
Atividade A2b
Atividade A2c
Atividades podem ser entendidas

como processos atmicos
Figura 65 Notao de Erikson e Penker para modelagem de negcio
120
As atividades ou processos atmicos so:
Diretas: diretamente envolvidas na criao do produto ou servio, que o valor criado pelo
processo.
Indiretas: d suporte s atividades diretas, como manuteno, administrao etc.
Garantia de qualidade: atividades que garantem a qualidade de outras atividades, como
inspeo, controle, reviso e validao.
A figura 66 ilustra os passos de um processo de negcio nesta notao.
<<processo>>
Furao
<<processo>>
Fazer furo
Ler
instruo
Calibrar
Ligar
furadeira
Furar
Processo contendo 3 subprocessos: dois atmicos e um composto

Figura 66 Passos de um processo
A figura 67 mostra um exemplo de um processo de negcio com recepo e emisso.
<<processo>>
Ordem
de
compra
Demanda
do cliente
por ao
Ordem
de
venda
<<processo>>
Administrao
de compra de
ao
Compra de
ao no
mercado
<<processo>>
Administrao
de venda de
ao
Venda de
ao no
mercado
Figura 67 Processo de recepo e emisso
121
Unidade IV
Como novo exemplo, a figura 68 apresenta um modelo de processo de furao de chapas em uma
indstria qualquer.
<<goal>>
chapas furadas
por dia: Meta
Quantitativa
Valor = 100
<<achieve>>
<<information>>
instrues
de fucao
<<processo>>
furao
<<physical>>
chapa de ao
<<physical>>
chapa
perfurada
Figura 68 Exemplo de um processo de furao de chapa
A notao de Erikson e Penker ainda hoje utilizada, e algumas ferramentas Case, tal como a
ferramenta EA, mantm essa notao.
8.2 A modelagem de processos de negcio com a BPM
A notao BPMN surgiu como um padro alternativo UML, tambm sendo grfica, porm seus
smbolos so um pouco diferentes, pois a BPMN (Business Process Modeling Notation) foi criada
especificamente para modelar processos de negcio. Essa notao no 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 lanou a especificao 1.0 ao pblico em maio de 2004.
Tanto a UML como a BPMN so notaes mantidas pela OMG.
Os objetivos do esforo do grupo que desenvolveu o BPMN so:
Fornecer uma notao que seja fcil.
Ser compreensvel por todos os usurios de negcios.
Envolver os analistas de negcio, os desenvolvedores, os tcnicos responsveis pela aplicao dos
sistemas que iro executar os processos e as pessoas de negcios.
122
A BPMN define um Business Process Diagram (BPD), que baseado em um fluxograma adaptado
para a criao de modelos grficos de tarefas dos processos de negcio.
Para a BPMN, um modelo de processo de negcios uma rede de objetos grficos, denominados de
atividades, e do fluxo de controle, que define a ordem de execuo.
As grandes empresas de software, tais como a IBM, a Oracle, a SAP e outras, vm investindo em
sistemas que automatizam a gesto de processos de negcio (execuo, controle e monitorao).
Esses sistemas so os denominados BPMS (Business Process Management Suite), que do suporte ao
mapeamento, execuo, monitorao e controle dos processos de negcio de uma organizao.
Tipicamente, inclui:
o mapeamento dos processos de negcio ponta-a-ponta;
desenho dos fluxos e formulrios eletrnicos;
definio de workflow;
regras de negcio;
integradores;
monitorao em tempo real das atividades; e
alertas.
uma poderosa ferramenta de gesto, para garantir que os processos esto sendo efetivamente
executados como modelados, contribuindo para os objetivos da organizao.
Os softwares utilizados na operacionalizao e gerenciamento de processos de negcio so um dos
principais facilitadores da gesto do conhecimento referente ao processo, sendo considerada a maior
facilidade para obteno, distribuio e anlise dos dados.
H algumas funcionalidades que podem ser disponibilizadas via software, inclusive nos softwares
BPMS, que, quando disponveis, aumentam a capacidade dos gestores e demais envolvidos com o processo
em estabelecer uma troca de imagens e idias, nos ambientes onde ocorre a gerao do conhecimento.
Observao
A soluo BPMS no prope a substituio dos sistemas existentes na
organizao os conhecidos como sistemas legados, e sim disponibiliza um
ambiente de integrao de sistemas de informao, que permite definir:
123
Unidade IV
fluxo de execuo;
regras;
eventos;
demais especificaes necessrias operao e gerenciamento do
processo de negcio.
Dessa forma, permite atender a outra caracterstica do processo de negcio: a de ser
extremamente dinmico, permitindo, por exemplo, uma substituio rpida e simples de um
software por outro, necessria quando uma empresa parceira da organizao substituda,
demandando a integrao com um novo software disponvel no ambiente computacional do
novo parceiro.
De acordo com vrios autores, um BPMS completo teria os seguintes mdulos ou funcionalidades:
Funcionalidades mnimas para uma soluo poder se classificar como BPMS:
ferramenta de modelagem e desenho do processo;
engenho de execuo do processo;
orquestrao de web services;
interface de workflow para usurios.
Para ter um produto mais completo, seria necessrio:
suporte para regras de negcio complexas;
Business Activity Monitoring (BAM);
controle de verso dos documentos anexados a instncias do processo.
E para um produto completo, seria acrescentado de:
Enterprise Service Bus (ESB);
Repositrio de metadados;
Uma suite de business intelligence.
124
Um BPD formado por um conjunto de quatro elementos grficos, que so:
objetos de fluxo;
objetos de conexo;
raias (swimlanes); e
artefatos.
8.2.1 Objetos de fluxo
Um BPD apresenta trs objetos de fluxo: evento, atividade e gateway. Os objetos de fluxo so os
principais elementos grficos para definir o comportamento de um processo de negcio.
8.2.1.1 Evento
Um evento algo que acontece no decurso de um processo de negcio. Esses eventos afetam o
fluxo do processo e normalmente tm uma causa (trigger) ou um impacto (resultado).
Somente os eventos tm a capacidade de iniciar ou terminar um processo, porm no executam
tarefas nesse. Os eventos ainda podem forar a execuo ou desviar para uma determinada atividade.
H trs tipos de eventos, com base em quando eles afetam o fluxo: evento de incio, evento
intermedirio e evento de fim, com notao apresentada na figura 69.
BPMN BPMN
Evento incio
Evento intermedirio
Evento fim
Figura 69 Smbolos de eventos da BPMN
125
Unidade IV
O evento incio define a inicializao em um processo. O evento intermedirio define um evento
intermedirio em um processo. J o evento fim define o trmino de um evento em um processo.
Um processo pode ser iniciado por diferentes circunstncias. Essas circunstncias so chamadas de
gatilhos (triggers), tais como, uma mensagem chegando ou um temporizador.
8.2.1.2 Atividade
Uma atividade organiza e especifica participao de comportamentos subordinados, tais como, as
sub-atividades ou aes, para refletir o controle e o fluxo de dados de um processo.
As atividades so usadas nos diagramas de atividades para vrios propsitos de modelagem: para a
modelagem do desenvolvimento de uma aplicao tpica, para modelagem de um processo de negcio
ou para modelar um workflow.
Durante a criao, ou em edies mais tarde, uma atividade pode ser definida como um elemento
composto. Contudo, quando se cria uma atividade composta, possvel usar tambm o elemento
atividade estruturada, que foi criada para esse propsito.
A especificao da OMG UML1 estabelece:
Uma atividade especfica coordenao da execuo de comportamentos subordinados, usando
um controle e modelo de fluxo de dados.
Os comportamentos subordinados coordenados por esses modelos podem ser iniciados porque
outros comportamentos no modelo iro concluir a execuo, ou porque os objetos e os dados
ficam disponveis, ou porque ocorrem eventos externos para o fluxo.
O fluxo de execuo modelado como atividades, os ns so ligados por arestas. Um n pode ser
a execuo de um comportamento do subordinado, como um clculo aritmtico, uma chamada
para uma operao, ou a manipulao do contedo do objeto.
Atividades podem formar hierarquias invocando outras atividades, em ltima anlise, para resolver
as aes individuais. Em um modelo orientado a objetos, as atividades so geralmente chamadas
indiretamente de mtodos vinculados s operaes que estejam diretamente invocadas.
As atividades podem descrever processos de computao. Nesse contexto, so os mtodos
correspondentes s operaes nas classes. As atividades podem ser aplicadas modelagem
organizacional para a Engenharia de processos de negcio e workflow.
Nesse sentido, eventos geralmente se originam de dentro do sistema, tais como o acabamento de
uma tarefa, mas tambm de fora do sistema, como uma chamada de cliente.
1
126
As atividades tambm podem ser utilizadas para a modelagem de sistema de informao, para
especificar os processos ao nvel do sistema. As atividades podem incluir aes de vrios tipos
(funes primitivas, operaes aritmticas etc.).
Uma atividade representada por um retngulo de bordas arredondadas e um termo genrico para o
trabalho que a empresa realiza. Uma atividade pode ser atmica (tarefa) ou no atmica (composta subprocesso).
analysis Diagrama Estrutura de Verso
Sub_processo
Atividade
Figura 70 Atividade atmica e no atmica
8.2.1.3 Gateway
Utilizado para controlar a divergncia e convergncia da sequncia de fluxos, determina as decises tradicionais
de bifurcao, fuso e unio de caminhos. Marcadores internos indicam o tipo de controle do comportamento.
analysis Diagrama Estrutura de Verso
Figura 71 Elemento gateway
Gateways so os mecanismos padronizados na notao 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 sequncia.
8.2.2 Objetos de conexo
Os objetos de fluxo so conectados ao diagrama pelos objetos de conexo, para criar o esqueleto
estrutural bsico de um processo de negcio.
Um BPD tem trs objetos de conexo: fluxo de sequncia, fluxo de mensagem e associao.
127
Unidade IV
8.2.2.1 Fluxo de sequncia
Um fluxo de sequncia usado para mostrar a ordem (sequncia) que as atividades so realizadas
em um processo.
A figura 72 mostra um exemplo de fluxo de sequncia.
BPMN BPMN
Atividade 1
Fluxo de sequncia
Atividade 2
Figura 72 Fluxo de sequncia
8.2.2.2 Fluxo de mensagem

Um fluxo de mensagem usado para mostrar mensagens entre dois participantes do processo
(entidades empresariais ou papis de negcio) que enviam e recebem mensagens.
BPMN BPMN
Atividade 1
Fluxo de mensagem
Atividade 2
Figura 73 Fluxo de mensagem
8.2.2.3 Associao
Uma associao usada para associar dados, textos e outros artefatos com os objetos de fluxo.
Associaes so utilizadas para mostrar as entradas e sadas de atividades.
analysis Diagrama Viso Estrutura de Verso
Documento
Activity2
IntermediateEvent3
Figura 74 Associao
128
A figura 75 mostra um exemplo de um pedao de um processo utilizando os elementos apresentados.
class BPMN
No
EndEvent
StartEvent
Repeat for Each Supplier
YES
Send RFQ
Receive
Quote
Limite do tempo excedeu
Add
Quote
Marca que mostra que o

subprocesso tem loop
Evento intermedirio
para um time out
Figura 75 Exemplo de um processo
8.2.3 Raias (Swimlanes)
Swimlanes um mecanismo para organizar atividades em categorias visuais separadas, que

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

diagrama, de forma a ilustrar diferentes capacidades funcionais ou responsabilidades.
Pools so utilizados quando o diagrama envolve duas entidades empresariais e so separados fisicamente
no diagrama. As atividades dentro de grupos separados so consideradas processos autocontidos.
Os fluxos de sequncia no podem cruzar a fronteira de um pool. Deve-se usar o fluxo de mensagem
como mecanismo para mostrar a comunicao 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 grfico para o particionamento de um conjunto de atividades de um ou mais
processos de um participante.
129
Unidade IV
Cliente
<<Pool>>
class BPMN
Figura 76 Exemplo de um diagrama com pool
8.2.3.2 Lane
Lane uma subpartio dentro de um pool que vai se estender a todo comprimento do pool,
tanto verticalmente quanto horizontalmente. Lanes so usadas para organizar e categorizar
atividades.
As lanes so elementos que so posicionados dentro de pools para indicar mais de um perfil que
colaboram para a execuo de um processo. Lanes criam subparties para os objetos dentro de um
pool. Essas participaes so usadas para agrupar elementos do processo.
So frequentemente usadas para separar as atividades associadas com uma funo ou papel de uma
determinada empresa. Os fluxos de sequncia podem atravessar as fronteiras das lanes dentro de um
pool.
O fluxo de mensagem no pode ser usado entre fluxos de objetos nas lanes de um mesmo pool.
CAC
<<Pool>>
HELPDESK
Cliente
class BPMN
Figura 77 Uma pool com duas lanes
A figura 78 mostra um exemplo de um BDP com duas pools, sendo que essas somente possuem uma
lane cada.
130
PACIENTE
Consultrio Mdico
<<Pool>>
<<Pool>>
class BPMN
Ocorre
doena
Envia
pedido
mdico
Recebe
pedido
sintomas
Eu quero ver
o mdico
Envia
sintomas
Eu me sinto
doente
O mdico
pede sintomas
Envia
pedido
mdico
Recebe
receita
Recebe
pedido
sintomas
Pegue sua receita

para comprar os
remdios
Envia
sintomas
Recebe
receita
Figura 78 Exemplo de pools e lanes juntas
8.2.4 Artefatos
A notao BPMN permite aos modeladores o uso de extenses de notao. Um nmero qualquer
de artefatos pode ser adicionado ao diagrama, conforme as necessidades apropriadas ao contexto de
negcio sendo modelado.
A verso corrente do BPMN predefine trs tipos de artefatos BPD:
objeto de dados;
grupo; e
anotao.
Os modeladores podem criar seus prprios 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
Gerenciamento
Web Service
Administrao
class BPMN
<<Group>>
Prepara ordem
de pagamento
+
Informaes
pagamento
E-mail
requisio
aprovao
Despacha para
aprovao
Aprova
requisio
Estas atividades
podem ser iniciadas
ao mesmo tempo
Figura 79 Uso de artefatos no BPD
8.2.4.1 Objeto de dados

So mecanismos para mostrar que dados so requeridos ou produzidos pelas atividades. So
conectados s atividades a partir das associaes.
BPMN BPMN
<<Group>>
Grupos
Objetos de dados
Anotaes
Figura 80 Artefatos do BPD
8.2.4.2 Grupo
Um grupo pode ser usado para documentao, mas no afeta o fluxo de mensagens.
8.2.4.3 Anotao
um mecanismo para um modelador colocar textos de informaes adicionais no diagrama.
132
8.3 Concluso do BPMN
Um objetivo-chave da BPMN foi criar uma ponte entre a notao da modelagem de processos de
negcios e a modelagem de linguagens orientadas para TI, que ir implementar os processos dentro de
um sistema de gesto de processos de negcios.
Observao
Os objetos grficos da BPMN, apoiados por um rico conjunto de atributos
de objeto, foram mapeados para o Business Process Execution Language
for Web Services (BPEL4WS v 1.1), o padro de fato para a execuo do
processo.
Resumo
Esta unidade mostrou os conceitos envolvidos com a modelagem de
negcios que precede a modelagem de sistemas de informao.
Mostrou tambm que a UML prope uma notao e um padro de
modelagem voltados para a especificao das regras de negcio de uma funo
e processo de negcio de uma organizao. A OMG tambm vem propondo o
uso da nova notao denominada BPMN, que est sendo preparada para novas
ferramentas de automao de aplicaes a partir dos modelos de negcio.
O uso dessa combinao tem como grande objetivo colocar a rea de
desenvolvimento de sistemas totalmente casada com s reas de negcio e
construindo aplicaes que agreguem valor ao negcio.
Com relao s organizaes, elas esto descobrindo que a modelagem
de processos de negcio pode ser uma excelente ferramenta para disseminar
o conhecimento organizacional.
Uma vez que as organizaes passam a compreend-lo como um recurso,
a modelagem de processos de negcio pode tornar-se uma excelente fonte
para a vantagem competitiva.
Processos de negcio estruturados na cooperao, integrao e no
alinhamento entre todas as reas organizacionais constituem o segredo de
sucesso de uma organizao.
Atualmente, o modelo de caso de uso de negcio pode ser aplicado
nos modelos de desenvolvimento em cascata, na fase de levantamento
133
Unidade IV
de requisitos de negcio, e no modelo iterativo RUP, na fase de iniciao,
tambm para modelagem dos requisitos de negcio que precedem as
definies e especificaes dos modelos dos sistemas de informao da
organizao.
Exerccios
Questo 1. Os autores definem que processos de negcio so um conjunto de atividades previamente
estabelecidas cujo objetivo determinar como o trabalho ser realizado em uma organizao por uma
rea de negcio. Diz-se que uma estrutura de processos de negcio mal concebida pode por em risco
a eficincia e a eficcia da organizao por meio dos produtos e servios gerados e disponibilizados.
Considerando os conceitos sobre processos de negcio, analise as afirmaes a seguir e assinale a
alternativa incorreta:
A) Uma funo de negcio a mesma coisa que um processo de negcio, j que ambos representam
o conjunto de atividades de uma organizao.
B) Processos de negcio so atividades transfuncionais previamente estabelecidas para tratar um
determinado negcio da organizao.
C) Um sistema de informao bem estruturado implementa processos de negcio de uma empresa
ou organizao.
D) Uma Funo de Negcio representa a estrutura funcional da Organizao, j que um Processo
de Negcio um conjunto de atividades ou aes que so transfuncionais, isto , atravessam
diversas reas ou funes de negcio.
E) Os processos de negcio devem funcionar de forma alinhada em relao a toda a estrutura
organizacional, pois somente dessa forma ser possvel atingir os objetivos transversais de
qualquer organizao.
Resposta: Alternativa A.
Alguns autores definem processo de negcio ou processo organizacional como sendo um conjunto
de atividades. Nesse conjunto, uma organizao deve ser estruturada com o objetivo de produzir valor
para os seus clientes.
A) Incorreta. Funo de negcio uma representao de uma estrutura dentro de uma
organizao. Por exemplo: o departamento financeiro uma funo de negcio; j um sistema
financeiro (processo de negcio financeiro), atua em diversas reas da empresa. Quando se
mapeia o processo de negcio financeiro, torna-se necessrio entender diversas reas ou
134
funes da empresa, que, de alguma forma, utilizam ou precisam tratar com as informaes
financeiras da empresa.
B) Correta. Os processos de negcio esto diretamente ligados aos negcios da empresa e independem
da estrutura organizacional. Normalmente atravessam as fronteiras das funes de negcio.
C) Correta. Um sistema de informao automatiza atividades dos processos de negcio, e, se ficarem
estritamente ligados a uma funo da empresa, no sero eficazes na busca de valor para a
instituio.
D) Correta. uma funo de negcio representa uma estrutura funcional de uma empresa, por
exemplo: rea de TI, rea de Logstica etc. E um processo de negcio seria a venda de carros de
luxo de uma montadora de veculos.
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 veculos, linha de produo, e assim por diante.
Questo 2. Na atualidade, com propsito de se ter sistemas de informaes abrangentes e que
agreguem valor ao negcio de uma organizao, evolue-se para duas vises complementares: a modelagem
de negcio e a modelagem de sistemas de informao. Normalmente, as modelagens de negcio e de
sistemas (software) so desenvolvidas como parte de dois diferentes projetos, com dois diferentes times. A
modelagem de negcios trata todas as atividades envolvidas com o negcio, e a modelagem de sistemas
verifica o aspecto de automao a partir do modelo de negcio. Ambas devem possuir boa definio,
pois so ferramentas importantes para o gerenciamento da complexidade da amplitude e dificuldade do
sistema. Considerando os conceitos sobre Arquitetura de negcio, Arquitetura de Software e exemplos
apresentados nesta unidade, analise as afirmaes a seguir e assinale a alternativa incorreta:
A) Para a modelagem de negcio, utiliza-se a notao BPMN, a qual surgiu como um padro alternativo
UML, j que esta foi desenvolvida para abranger somente as atividades de desenvolvimento de software.
B) A modelagem de negcio com BPMN grfica, porm, para representar as atividades existentes
nos processos de negcio, seus smbolos so um pouco diferentes da UML.
C) Quem desenvolveu o BPMN foi o Instituto de Engenharia de Software, em 1991.
D) Pode-se afirmar que o processo de modelagem de negcios um conjunto estruturado de
atividades, desenhado para produzir um resultado especfico para um cliente ou um mercado em
particular.
E) A modelagem de negcio leva em considerao que um processo uma ordenao especfica
de atividades de trabalho, por meio do tempo e do espao, com comeo, fim e entradas e sadas
claramente identificadas: uma estrutura para ao.
135
Figuras e ilustraes
Figura 2
Estrutura de um modelo de AOO. Adaptada de YOURDON, E.; ARGILA, C. Anlise e projeto orientados a
objetos, So Paulo: Makron Books, 1998.
Figura 3
Exemplo de uma aplicao da AOO. Adaptada de YOURDON, E.; ARGILA, C. Anlise e projeto orientados
a objetos, So Paulo: Makron Books, 1998.
Figura 57
Processos de negcio. Disponvel em: <http://www.trainning.com.br/analistadenegocios_bpm_artigo.

asp>. Acesso em: 14 mai. 2012.
Figura 59
Relacionamento de processos, Sistemas de Informao (SI) e Redes de Computadores (RC). PAUL, R. J.;
SERRANO, A. Simulation for business processes and information systems design. Anais da Conferncia
de Simulao de Inverno de 2003. Departamento de Sistemas de Informao e Computao,
Universidade de Brunel, U.K.: Uxbridge Middlesex, 2003.
Figura 60
O relacionamento entre Engenharia de processo de negcio e Engenharia de software. RUP. Rational

Unified Process. Rational Software Corporation, verso 2002.05.00, 2001.
Figuras 61 e 62
Processo iterativo aps o surgimento da modelagem de negcio e Modelagem de negcio como fase
integrante do processo iterativo. BOGGS; BOGGS. Mastering UML with Rational Rose. SYBEX Sample
Chapter. 2002.
Figura 63
Integrao entre modelagem de negcio e sistema. RODRIGUES, V. M. S. Mapeamento de processos de

negcio com base nas extenses de penker e eriksson para casos de uso. Portugal. 2004.
Figura 64
O esforo da modelagem de negcios e requisitos. RUP. Rational Unified Process. Rational Software
Corporation, verso 2002.05.00, 2001.
136
Referncias
BRANCO, I. V. C. Modelagem de processos organizacionais integrada s aplicaes prticas de
aprendizagem organizacional e compencias conversacionais. Dissertao de Mestrado da UCB,
Brasilia, Brasil, 2007.
BOGGS; BOGGS. Mastering UML with Rational Rose. SYBEX Sample Chapter. 2002.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML guia do usurio. Rio de Janeiro: Editora Campus, 2000.
COCKBURN, A. Escrevendo casos de uso eficazes um guia prtico para desenvolvedores de software.
Traduo 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 atravs da UML, So Paulo: Makron Books, 1998.
JACOBSON, I; BOOCH, G; RUMBAUGH, J. The unified software development process. Indianpolis, 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 informao. Rio de Janeiro: LTC, 2001.
MEDEIROS, E. Desenvolvendo software com UML. So Paulo: Makron Books, 2004.
OMG. Object management Group. Disponvel 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 Conferncia de Simulao de Inverno de 2003. Departamento de Sistemas de Informao e
Computao, Universidade de Brunel, U.K.: Uxbridge Middlesex, 2003.
PFLEEGER, S. L. Engenharia de software teoria e prtica. So Paulo: Prentice hall, 2004.
RUMBAUGH, J. et al. Modelagem e projetos baseados em objetos. So Paulo: Editora Campus, 1994.
REED JR., P. R. Desenvolvendo aplicativos com Visual Basic e UML. So Paulo: Makron Books, 2000.
137
RODRIGUES, V. M. S. Mapeamento de processos de negcio com base nas extenses de Penker e

Eriksson para casos de uso. Portugal, 2004.
RUP. Rational Unified Process. Rational Software Corporation, verso 2002.05.00, 2001.
SENGE, P. M. A quinta disciplina: arte, teoria e prtica da organizao de aprendizagem. So Paulo:
Best Seller, 1990.
SZILAGYI, D. C. Modelagem de processos de negcio um comparativo entre BPML e UML. Dissertao
de Mestrado da Pontifcia Universidade Catlica So Paulo, 2010.
YOURDON, E.; ARGILA, C. Anlise e projeto orientados a objetos, So 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
Informaes:
www.sepi.unip.br ou 0800 010 9000
UNIDADE IV
Questo 2
Resposta correta: C.
Justificativa
A) Correta. Para a modelagem de negcio, utilizada a notao BPMN, a qual
surgiu como um padro alternativo UML. Os autores da UML eram da rea de
software e desenvolveram esse padro para ser utilizado somente no
desenvolvimento de sistemas.
B) Correta. Tanto a modelagem de negcio como a modelagem de sistemas
utilizam smbolos grficos, porm a simbologia da modelagem de negcios est
voltada para o entendimento das atividades do processo, enquanto a modelagem de
sistemas est voltada para a soluo das funcionalidades e arquiteturas de sistemas
de informao (software).
C) Incorreta. Quem desenvolveu o BPMN foi o Business Process Management
Initiative (BPMI), iniciativa oriunda da OMG que lanou a especificao 1.0 ao pblico
em maio de 2004.
D) Correta. A tcnica de Modelagem de Negcios profundamente relacionada
Arquitetura de Negcios e baseada em atividades das reas de negcio.
E) Correta. Processo de Negcio definido como a sequncia completa de um
comportamento de negcio provocado por algum evento e que produz um resultado
significativo para o negcio e que, de preferncia, tenha foco no cliente.

Modelagem Processos

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelagem Processos

Uploaded by

Copyright:

Available Formats

Modelagem de Processos

Autor: Prof. Dr. Ivanir Costa

Professor conteudista: Dr. Ivanir Costa

Dados Internacionais de Catalogao na Publicao (CIP)

Prof. Dr. Joo Carlos Di Genio

Prof. Fbio Romeu de Carvalho

Profa. Melnia Dalla Torre

Prof. Dr. Yugo Okida

Profa. Dra. Marlia Ancona-Lopez

Unip Interativa EaD

Material Didtico EaD

1 A Linguagem Unificada de Modelos...............................................................................................11

3 Modelo Conceitual da UML.................................................................................................................. 43

4 Diagrama de classes de objetos da UML.................................................................................... 51

4.8.1 Herana mltipla..................................................................................................................................... 63

4.8.3 Polimorfismo (ocultamento de informaes).............................................................................. 66

4.9 Estudo de caso aplicando modelo de classes............................................................................ 68

5 MODELAGEM COMPORTAMENTAL (MODELO DINMICO).............................................................. 76

6 Outros modelos comportamentais da UML............................................................................. 91

6.4 Diagramas de estado (mquina de estado)................................................................................ 96

7 MODELAGEM DA ARQUITETURA DE NEGCIO..................................................................................103

7.3 OCL e sua utilizao na modelagem de processo de negcio.......................................... 114

7.4.1 Processo de desenvolvimento de software.................................................................................116

8 A modelagem de processos de negcio................................................................................... 119

8.2.1 Objetos de fluxo.................................................................................................................................... 125

8.3 Concluso do BPMN..........................................................................................................................133

O objetivo da disciplina Modelagem de Processos apresentar e conceituar a importncia de modelos

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

abrangncia de automao no atendimento das necessidades de uma empresa. A automao do processo

A disciplina aborda os conceitos de modelos, a importncia da modelagem de sistemas de informao,

A modelagem de sistemas de informao (software) a atividade de construir modelos que expliquem

Figura 1 Sistema vs. objeto

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

Dentre as vrias razes pode-se citar:

Figura 2 Estrutura de um modelo de AOO

A camada de classes e objetos apresenta os blocos bsicos de construo do sistema proposto. Os

Figura 3 Exemplo de uma aplicao da AOO

Figura 5 Troca de mensagens entre objetos

Figura 6 Exemplo de classe de objetos

Figura 8 Exemplo de metamodelagem (note que todos os relacionamentos so mostrados no diagrama)

Figura 9 Pilares da Engenharia de software

O estudo dos mtodos/tcnicas/mtricas definem a sequncia, a simbologia e os padres em que as

Figrura 10 Ciclo de vida clssico

A UML no um modelo de processo/metodologia de software. uma notao, um mecanismo para

Na UML, o principal diagrama que mostra a estrutura de um sistema o diagrama de classes.

Nome dos atributos

Objetos com valores da

O nome da classe (metamodelo)

Alguns meios de implementao (linguagens de programao e sistemas gerenciadores de banco de

Figura 14 Uso incorreto de identificador interno

Figura 15 Exemplo de uma operao e a lista de argumentos

Em um modelo de classes, existem diversas classes do domnio da aplicao que precisam se

Figura 17 Associao binria

Figura 18 Um exemplo de associao unria

4.3 Papis em associao

O mesmo que 0..*

Figura 20 Uso da palavra chave {ordenado}

Figura 21 Navegao (restrio de acionamento de classes)

Em alguns modelos, devido s regras de negcio, torna-se necessria a colocao de atributos em

Figura 22 O uso de atributos de associao

Figura 23 O uso da classe de associao

Figura 24 Classes de associao

Figura 25 Exemplo de uma agregao entre classes associadas

Figura 26 Exemplo de agregao