Análise e Projeto Orientado A Objetos

ANÁLISE E
PROJETO
ORIENTADO A
OBJETOS
Professor Me. Déverson Rogério Rando
GRADUAÇÃO
Unicesumar
Reitor
Wilson de Matos Silva
Vice-Reitor
Wilson de Matos Silva Filho
Pró-Reitor de Administração
Wilson de Matos Silva Filho
Pró-Reitor de EAD
Willian Victor Kendrick de Matos Silva
Presidente da Mantenedora
Cláudio Ferdinandi
NEAD - Núcleo de Educação a Distância

Direção de Operações
Chrystiano Mincoff
Direção de Mercado
Hilton Pereira
Direção de Polos Próprios
James Prestes
Direção de Desenvolvimento
Dayane Almeida
Direção de Relacionamento
Alessandra Baron
Direção de Planejamento de Ensino
Fabrício Lazilha
Direção Operacional de Ensino
Katia Coelho
Supervisão do Núcleo de Produção de
Materiais
Nalva Aparecida da Rosa Moura
Design Educacional
Paulo Victor Souza e Silva
Projeto Gráfico
Jaime de Marchi Junior
José Jhonny Coelho
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a
Distância:
Editoração
Análise e Projeto Orientado a Objetos. Déverson Fernando Henrique Mendes
Rogério Rando.
Maringá - PR, 2015.
Revisão Textual
176 p. Viviane Favaro Notari
“Graduação - EaD”. Ilustração

1. Projeto 2. Orientado . 3. Objetos 4. EaD. I. Título.
Bruno Pardinho
CDD - 22 ed. 005.1

CIP - NBR 12899 - AACR/2
Ficha catalográfica elaborada pelo bibliotecário

João Vivaldo de Souza - CRB-8 - 6828
Viver e trabalhar em uma sociedade global é um
grande desafio para todos os cidadãos. A busca
por tecnologia, informação, conhecimento de
qualidade, novas habilidades para liderança e so-
lução de problemas com eficiência tornou-se uma
questão de sobrevivência no mundo do trabalho.
Cada um de nós tem uma grande responsabilida-
de: as escolhas que fizermos por nós e pelos nos-
sos farão grande diferença no futuro.
Com essa visão, o Centro Universitário Cesumar
assume o compromisso de democratizar o conhe-
cimento por meio de alta tecnologia e contribuir
para o futuro dos brasileiros.
No cumprimento de sua missão – “promover a
educação de qualidade nas diferentes áreas do
conhecimento, formando profissionais cidadãos
que contribuam para o desenvolvimento de uma
sociedade justa e solidária” –, o Centro Universi-
tário Cesumar busca a integração do ensino-pes-
quisa-extensão com as demandas institucionais
e sociais; a realização de uma prática acadêmica
que contribua para o desenvolvimento da consci-
ência social e política e, por fim, a democratização
do conhecimento acadêmico com a articulação e
a integração com a sociedade.
Diante disso, o Centro Universitário Cesumar al-
meja ser reconhecido como uma instituição uni-
versitária de referência regional e nacional pela
qualidade e compromisso do corpo docente;
aquisição de competências institucionais para
o desenvolvimento de linhas de pesquisa; con-
solidação da extensão universitária; qualidade
da oferta dos ensinos presencial e a distância;
bem-estar e satisfação da comunidade interna;
qualidade da gestão acadêmica e administrati-
va; compromisso social de inclusão; processos de
cooperação e parceria com o mundo do trabalho,
como também pelo compromisso e relaciona-
mento permanente com os egressos, incentivan-
do a educação continuada.
Seja bem-vindo(a), caro(a) acadêmico(a)! Você está
iniciando um processo de transformação, pois quan-
do investimos em nossa formação, seja ela pessoal
ou profissional, nos transformamos e, consequente-
Diretoria Operacional mente, transformamos também a sociedade na qual
de Ensino
estamos inseridos. De que forma o fazemos? Criando
oportunidades e/ou estabelecendo mudanças capa-
zes de alcançar um nível de desenvolvimento compa-
tível com os desafios que surgem no mundo contem-
porâneo.
O Centro Universitário Cesumar mediante o Núcleo de
Educação a Distância, o(a) acompanhará durante todo
este processo, pois conforme Freire (1996): “Os homens
se educam juntos, na transformação do mundo”.
Os materiais produzidos oferecem linguagem dialó-
gica e encontram-se integrados à proposta pedagó-
gica, contribuindo no processo educacional, comple-
mentando sua formação profissional, desenvolvendo
competências e habilidades, e aplicando conceitos
teóricos em situação de realidade, de maneira a inse-
ri-lo no mercado de trabalho. Ou seja, estes materiais
têm como principal objetivo “provocar uma aproxi-
mação entre você e o conteúdo”, desta forma possi-
bilita o desenvolvimento da autonomia em busca dos
conhecimentos necessários para a sua formação pes-
soal e profissional.
Portanto, nossa distância nesse processo de cres-
cimento e construção do conhecimento deve ser
apenas geográfica. Utilize os diversos recursos peda-
gógicos que o Centro Universitário Cesumar lhe possi-
bilita. Ou seja, acesse regularmente o AVA – Ambiente
Virtual de Aprendizagem, interaja nos fóruns e en-
quetes, assista às aulas ao vivo e participe das discus-
sões. Além disso, lembre-se que existe uma equipe de
professores e tutores que se encontra disponível para
sanar suas dúvidas e auxiliá-lo(a) em seu processo de
aprendizagem, possibilitando-lhe trilhar com tranqui-
lidade e segurança sua trajetória acadêmica.
AUTORES

Mestre em Ciência da Computação pela Universidade Estadual de Maringá
(UEM). Especialista em Engenharia de Software pela Universidade Norte do
Paraná. Graduado em Geografia pela Universidade Estadual de Londrina
e Análise e Desenvolvimento de Sistemas pelo CESUMAR. Atualmente,
coordenador do Curso de Bacharelado em Sistemas de Informação da
FAP-Faculdades Apucarana. Professor dos cursos de Técnico em Redes e
Informática, respectivamente, no SENAC e SENAI nas disciplinas de Banco de
Dados, Análise Estruturada e OO, Organização e Arquitetura de Computadores,
Computação Gráfica, IHC, Algoritmos, Linguagens de Programação, Sistemas
de Informações Geográficas, Trabalho de Conclusão de Curso.
APRESENTAÇÃO
ANÁLISE E PROJETO ORIENTADO A OBJETOS
SEJA BEM-VINDO(A)!
Caro(a) Aluno(a)! Seja bem-vindo(a) à disciplina de Análise e Projeto Orientado a Ob-
jetos (OO). Sou o professor Déverson Rogério Rando. Esta disciplina abordará vários
aspectos relacionados à análise e projeto de sistemas orientados a objetos, utilizando
como notação a UML.
Apresento a você o livro que conduzirá seus estudos, auxiliando no aprendizado de aná-
lise e projeto orientado a objetos com a UML. O livro encontra-se estruturado em cinco
unidades e cada uma conta com uma seção Reflita, Saiba Mais, Vídeos e Atividades de
Autoestudo. A seção Reflita apresenta frases que te remetem ao conteúdo estudado
na disciplina e o fazem pensar um pouco mais sobre ele. A seção Saiba Mais conta com
links para artigos que complementam o aprendizado sobre análise de projetos. A seção
Vídeo apresenta links para vídeos. E, por último, a seção Atividades de Autoestudo ex-
pressa um conjunto de questões sobre o conteúdo abordado.
A unidade I apresenta os conceitos iniciais sobre a análise e projetos orientados a ob-
jetos. Estudaremos como surgiu e como ocorreu a evolução dos métodos orientados a
objetos. Abordaremos, também, as características desses principais métodos. Conhece-
remos os conceitos básicos que envolvem a orientação a objetos, para dar subsídio nos
capítulos subsequentes. E, por fim, veremos os principais diagramas da UML utilizados
na documentação de software.
Na unidade II, estudaremos as fases que compreendem a análise e o projeto de um sof-
tware. Entraremos em contato com dois dos modelos de processos, cascata e evolucio-
nário, veremos as vantagens e desvantagens da utilização de cada um desses métodos.
Abordaremos, também, os requisitos de software e vamos conhecer os procedimentos
mínimos para a obtenção de um software de qualidade. Encerraremos a unidade falan-
do sobre a importância da construção de casos de uso no levantamento de requisitos,
bem como a notação necessária para a construção de diagramas de casos de uso.
A unidade III está toda dedicada à confecção do Diagrama de Classes responsável por
demonstrar a estrutura estática do sistema. Conheceremos a notação para o diagrama
de classes em detalhes. Abordaremos os conceitos e a assinatura da declaração de atri-
butos e métodos. Veremos como ocorrem as ligações entre as classes e como definir a
multiplicidade entre elas. Discutiremos, ainda, sobre as várias formas de se associar as
classes, sejam elas unária, binária, ternária, associativa, agregação ou generalização.
Na unidade IV, avançaremos conhecendo mais três diagramas, essenciais na análise e
projeto OO, que utilizaremos para refinar o diagrama de classes que representa a estru-
tura do sistema. O primeiro diagrama que veremos nessa unidade é o de sequência, que
tem como objetivo estudar as interações entre os objetos, considerando a dimensão
tempo. O segundo diagrama que veremos é o de estados, que tem como objetivo es-
pecificar o comportamento das classes mais complexas utilizando máquinas de estado.
Já o terceiro diagrama é o de comunicação, que contém as mesmas informações que o
diagrama de sequência, porém não considera o tempo e sim a ordem da comunicação.
APRESENTAÇÃO
Por fim, na unidade V, resolveremos, juntos, um estudo de caso, no qual teremos a

oportunidade de apresentar de forma prática a construção dos diagramas citados
na elaboração da análise e projeto de um software. Dessa forma, reforçaremos to-
dos os conceitos trabalhados nas unidades anteriores.
Ao longo deste livro, você encontrará indicações de Leitura Complementar, as quais
enriquecerão o seu conhecimento sobre projetos. É importante que você desenvol-
va as Atividades de Autoestudo para fixar o conteúdo abordado e identificar even-
tuais dificuldades. Vamos lá!?
09
SUMÁRIO
UNIDADE I
INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS
15 Introdução
16 Introdução À Orientação A Objetos
19 Evolução Dos Métodos OO
21 Conceitos Básicos De OO
27 Principais Diagramas da UML
38 Considerações Finais
UNIDADE II
CASOS DE USO
47 Introdução
48 Fases da Análise e do Projeto
53 Modelos de Processo
58 Requisitos de Software
63 Diagrama de Casos de Uso
SUMÁRIO
UNIDADE III
DIAGRAMA DE CLASSES
77 Introdução
78 Diagrama de Classes
79 Notação Para Classes
81 Atributos
83 Métodos
85 Multiplicidade
88 Associação Unária
89 Associação Binária
90 Classe Associativa
91 Agregação
94 Generalização
98 Herança Múltipla
11
SUMÁRIO
UNIDADE IV
DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO
109 Introdução
110 Avançando nos Diagramas
112 Diagrama de Sequência
120 Diagrama de Estados
125 Diagrama de Comunicação
UNIDADE V
ESTUDO DE CASO
137 Introdução
138 Ferramentas Case
139 Estudo de Caso
142 Diagrama de Caso de Uso
153 Diagrama de Classes
156 Diagrama de Sequência
162 Diagrama de Estado
164 Diagrama de Comunicação
173 Conclusão
175 Referências
INTRODUÇÃO AO ESTUDO
I
UNIDADE
DE ORIENTAÇÃO A OBJETOS
Objetivos de Aprendizagem
■■ Entender a importância da análise e projeto.
■■ Conhecer a evolução dos métodos OO.
■■ Compreender as características dos métodos OO.
■■ Entender os diferentes termos utilizados em OO.
■■ Conhecer os principais diagramas da UML.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
■■ Introdução à Orientação a Objetos
■■ Evolução dos métodos OO
■■ Conceitos básicos de OO
■■ Principais diagramas da UML
15
INTRODUÇÃO
Caro(a) aluno(a), iniciamos a primeira unidade do livro Análise e Projeto

Orientado a Objetos falando sobre a importância da análise de sistemas dentro
do projeto de produção de software.
Veremos que a análise de Sistemas é a atividade inicial do processo de desen-
volvimento de software. É nessa fase que determinamos e especificamos o que
um software deve fazer. Também nessa fase, verificamos as circunstâncias sob
as quais o software deve operar, envolvendo geralmente um esforço colabora-
Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
tivo entre analistas de sistemas e usuários.

Em seguida, veremos como os métodos surgiram e como aconteceu a evo-
lução deles. Abordaremos a partir do primeiro método Orientado a Objetos,
proposto por Shlaer e Mellor em 1988, o OOSA, até chegarmos a Unified Modeling
Language-UML, que será a linguagem que utilizaremos para as nossas análises
e projetos OO.
Mesmo utilizando a UML, é importante conhecermos as características dos
principais métodos OO, uma vez que a UML é a unificação de vários dos méto-
dos que serão apresentados. Ou seja, a evolução de todos os demais métodos
permitiu que chegássemos a uma unificação que, na verdade, apropria-se das
melhores características dos demais métodos.
Nesta unidade, também conheceremos e entenderemos os conceitos e ter-
mos utilizados na análise e no projeto OO. Dentre os conceitos que veremos,
estão o de objeto, abstração, classe, instância, atributo, operação, mensagem,
evento, estado, parâmetro, entre outros. Com esses conceitos iniciais, você terá
uma visão geral sobre OO.
Conheceremos, ainda, os principais diagramas da UML utilizados na aná-
lise e no projeto de softwares, dentre eles: o diagrama de casos de uso utilizado
na fase de análise para criar um cenário para o software, o diagrama de classes
que modela a estrutura estática do sistema, o diagrama de sequência, o de cola-
boração e o de estado.
Então, o que estamos esperando? Vamos ao trabalho?
Boa leitura a todos.
Introdução
I
INTRODUÇÃO À ORIENTAÇÃO A OBJETOS
ANÁLISE E PROJETO
O processo de desenvolvimento de um sistema computacional tem na análise

sua atividade inicial. Atividade essa que determina e especifica o que um sistema
deve fazer, além das circunstâncias sob as quais ele deve operar, envolvendo um
esforço colaborativo que abrange analistas de sistemas e usuários.
Os analistas procuram obter, a partir dos usuários, em um processo gradual
e cumulativo, o maior conhecimento possível acerca do domínio do problema
e respectivo ambiente.
De acordo com Sommerville (2011), podemos chamar “análise de sistemas”
de “engenharia de requisitos”. Acrescentar o termo engenharia implica dizer que
técnicas sistemáticas deverão ser utilizadas para assegurar que os requisitos do
sistema sejam consistentes, relevantes e completos.
A análise de sistemas é uma atividade de suma importância no processo de
desenvolvimento de sistemas, por ser uma etapa inicial e cujas falhas terão efeitos
em cadeia nas etapas subsequentes, assim como no produto final. A determi-
nação incorreta dos requisitos levará à obtenção e disponibilização de sistemas
computacionais inadequados.
Resumindo: a análise é a solução conceitual dada ao problema. Marca o iní-
cio da definição informática, mas sem levar em conta detalhes da implementação,
tais como a linguagem e o sistema gerenciador de banco de dados a serem uti-
lizados. Preocupa-se, principalmente, com as classes do domínio do problema
e suas relações e, também, com os casos de uso.
Se, por um lado, a análise é a solução conceitual, por outro, o projeto con-
siste na solução computacional aplicada ao problema. Dizer onde acaba a análise
e inicia o projeto é muito complicado, uma vez que o projeto é o resultado de
refinamentos sucessivos do modelo conceitual de análise.
A Orientação a Objetos fez com que fosse alterado o enfoque necessário
para desenvolver um sistema, enquanto na programação estruturada tínhamos

17
nitidamente uma visão sequencial e bem dividida, como os programas, que exe-
cutam determinados processos e tratam determinados dados, na orientação a
objetos passamos a visualizar classes responsáveis por atributos, com operações
criadas para tratar esses atributos, e a execução das atividades dos sistemas passa
a depender da interação dessas classes.
ANÁLISE E PROJETO OO
Na década de 80, houve preponderância dos métodos estruturados para o desen-

volvimento de software. Atualmente, o paradigma OO é mais forte e, por isso, é
importante diferenciar análise e projeto estruturado e orientado a objetos.
A análise e o projeto estruturados têm como ênfase as funções que atuam
sobre os dados, ou seja, todo o processo que se deseja informatizar é compreen-
dido como um conjunto de funções com dados de entrada, processamento e
saída. Yourdon (1990) apresenta as principais características:
■■ Modularidade e coesão.
■■ Desenvolvimento top-down (diferentes níveis de abstração).
Os diagramas que apoiam a análise e projeto estruturado são:

■■ Diagrama entidade e relacionamento (DER).
■■ Dicionários de dados.
■■ Diagrama de Fluxo de Dados (DFD).
O DER modela a estrutura de dados parados, ou seja, é o modelo conceitual do

sistema. Mostra-nos as entidades e seus relacionamentos, nesse modelo, muitos
detalhes não são mostrados, ficando a cargo do dicionário de dados os detalhes
de nomes de atributos, tipos de dados, comprimento e demais restrições de dados.
O DFD modela o fluxo de dados, em outras palavras, mostra os dados em movi-
mento, como ocorre a interação entre as diversas entidades (depósito) do sistema.
A Orientação a Objetos, ou simplesmente OO, é uma estratégia de desenvol-
vimento de software que organiza o software como uma coleção de objetos que
Introdução À Orientação A Objetos

I
contém tanto a estrutura dos dados como o comportamento deles. A orientação

a objetos tem como principal característica a forma natural de tratar a realidade,
pois considera que o mundo real é formado de objetos.
A proposta da orientação a objetos é deslocar o esforço de desenvolvimento
para a fase de análise, dando ênfase nas estruturas de dados antes do que as fun-
ções, os benefícios são: a reutilização do código (componentes), a confiabilidade
(objetos encapsulados), o aumento de produtividade (SOMMERVILE, 2011).
Com o planejamento adequado, desenvolvedores capacitados e a adoção de
uma metodologia, o sucesso é garantido. A análise OO apresenta um conjunto
de regras e modelos que auxiliam o analista a levantar e modelar os requisitos
dos usuários que o sistema deve atender.
Nos anos 50, quando inicia a informática, desenvolver software era um pro-
cesso informal, sem técnicas de projeto, conceito de reusabilidade, controle
de qualidade ou documentação. Neste artigo, Marcos Rodrigues Pinto e Sér-
gio Cosme Noronha C. Filho fazem um Estudo comparativo sobre a aborda-
gem tradicional de desenvolvimento de sistemas e a orientação a objetos.
Confira o texto completo no link disponível em: <http://www.dcc.ufrj.br/~s-
chneide/es/2002/1/g11/index.htm>. Acesso em: 28 jul. 2015.
Fonte: o autor.

19
EVOLUÇÃO DOS MÉTODOS OO
Os métodos de análise e projeto orientado a objetos surgiram assim que as lingua-

gens de programação OO começaram a estabilizar, sendo que um dos primeiros
métodos foi o modelo OOSA, proposto por Shlaer e Mellor, em 1988, e o Wirfs-
Brock, lançado em 1989, pelo grupo de pesquisa da Smalltalk. (MEDEIROS, 2004)
A maior parte dos métodos OO, porém, passou a se tornar estável na década
de 90, com a fusão das metodologias de Grady Boock, James Rumbaugh e Ivar
Jacobson e a criação da UML, que teve como base outras metodologias também,
como a de Shlaer-Mellor. Buscava-se com a criação da UML uma padronização

das metodologias OO.
Ivar Jacobson (1995): apresenta uma abordagem mais conceitual do que de
detalhes, composta de cinco fases: levantamento de requerimentos, análise de
robustez, projeto, implementação e teste. Ele segue a estratégia de métodos não
lineares e em espiral com refinamentos sucessivos.
Coad e Yourdon (1992): abrangem as fases de análise, projeto e implementa-
ção; propõem uma metodologia simples para iniciantes. As críticas mais fluentes
destacam a ausência de modelagem para abranger todo o contexto necessário
na fase de análise.
Shlaer e Mellor (1990): abrangem as fases de análise, projeto e implementa-
ção. Propõem mecanismos para facilitar a representação de modelos dinâmicos
dos objetos, dando ênfase na modelagem da informação, por meio dos modelos
de objetos, de estados, dos diagramas de fluxo de dados e de ações.
Grady Booch (1997): abrange as fases de análise, projeto e implementação.
Apresenta uma poderosa notação utilizada para expressar as relações entre as
classes, destacando-se, principalmente, na fase de projeto. É considerado um dos
mais autênticos e tradicionais métodos de desenvolvimento de sistemas orien-
tado a objetos.
James Rumbaugh (1991): abrange as fases de levantamento de dados com a
descrição do domínio e do enunciado do problema, dividindo a fase de análise
em modelagem de objetos, modelagem dinâmica e modelagem funcional, des-
tacando o tratamento de processos e dividindo a fase de projeto em projeto de
objetos e projeto de sistema.
Evolução Dos Métodos OO

I
Martin e Odell (1995): abrange as fases de análise e projeto. Propõe o uso

da Engenharia da Informação Baseada em Objetos por meio de um repositório
de objetos, para obtenção de um alto nível de reaproveitamento dos sistemas.
Fusion (1996): abrange as fases de análise, projeto e implementação.
Sintetizando os aspectos mais positivos dos métodos de James Rumbaugh/OMT,
Grady Booch, Wirfs-Brock/CRC e Ivar Jacobson/Objectory. O autor enfoca os
modelos de objetos e processos do método OMT, a interação de objetos da CRC,
a visibilidade do método de Booch e complementa com pré e pós-condições de
métodos formais (COLEMAN, 1996).
UML-Unified Method Language (2000): abrange as fases de levantamento
de requisitos, análise, projeto e implementação. Fusão dos métodos de James
Rumbaugh/OMT, Grady Boock e Ivar Jacobson. A fusão inicia com o trabalho
de James Rumbaugh e Grady Booch, os dois metodistas que ganharam maior
popularização; os quais se juntaram para criar um método comum por meio de
pontos fortes ao público em 1995. Em seguida, em meados de 1996, Ivar Jacobson
integrou-se ao grupo e lançaram a UML versão 0.9. A partir daí, criaram forças
com cooperação da OMG (Object Management Group), em julho de 1997, con-
siderado um padrão mundial.
A UML sugere fortemente a adoção de casos de uso (use cases) como dire-
cionador de projetos de software, a utilização de diagramas de interação para
identificação de objetos e uma série de outros conceitos.

21
CONCEITOS BÁSICOS DE OO
Conheceremos, a seguir, os principais termos e conceitos utilizados na análise

e projeto OO. Vamos lá!
■■ Objeto: qualquer coisa concreta ou abstrata que existe no mundo real,
em que se pode individualizá-la por possuir comportamentos e caracte-
rísticas próprias.
Figura 1: Objetos Concretos Figura 2: Objetos Abstratos
■■ Abstração: abstraímos quando definimos um objeto conceitual partindo

de OBJETOS do mundo real com os mesmos comportamentos e caracte-
rísticas, os quais são classificados como de um mesmo tipo.
Figura 3: Abstração de Bolsa Figura 4: Abstração de avião
Conceitos Básicos De OO
I
Figura 5: Abstração de Esporte
■■ Classe: representa a ABSTRAÇÃO de um conjunto de OBJETOS do mundo
real que possui comportamentos e características comuns.
Figura 6: Classe Funcionário

Fonte: o autor.
■■ Instância: é cada umas das ocorrências de um OBJETO formado a par-

tir da sua CLASSE.
Figura 7: Classe e Objetos

Fonte: o autor.
23
■■ Atributo: é uma característica particular que os OBJETOS de uma CLASSE

possuem, assumindo valores diferentes para cada OBJETO.
Figura 8: Classe, objeto e valor

Fonte: o autor.
■■ Operação: é uma ordem que faz um OBJETO executar uma ação. As ope-
rações são tudo o que os OBJETOS de uma CLASSE fazem e nada além
do que esses objetos podem fazer.
Figura 9: Operação
Fonte: o autor.
■■ Mensagem: representa o mecanismo de chamada de uma OPERAÇÃO.

É utilizada na solicitação de execução de uma OPERAÇÃO. É a maneira
como conseguimos que um método seja executado.
Figura 10: Mensagem

Fonte: o autor.
I
■■ Evento: é um tipo especial de OPERAÇÃO que faz com que os OBJETOS

mudem de ESTADO.
Figura 11: Evento

Fonte: o autor.
■■ Parâmetro: é um ou mais ATRIBUTOS que são carregados para dentro

de uma MENSAGEM.
Figura 12: Parâmetro
Fonte: o autor.
■■ Estado: é a forma de apresentação dos OBJETOS de uma CLASSE em

um determinado instante.
Figura 13: Estado

Fonte: o autor.
■■ Transição de Estado: é quando ocorre a mudança de ESTADO de um

OBJETO de uma CLASSE como resposta à chegada de um EVENTO.
Estado Parado Estado Decolando
Estado Criado Estado Eliminado
Figura 14: Transição de estado

Fonte: o autor.

25
■■ Associação: é a forma como os OBJETOS de uma mesma CLASSE ou de

CLASSES diferentes se conectam.
Figura 15: Associação de classes

Fonte: o autor.
■■ Encapsulamento: é a reunião de características e comportamentos de
OBJETOS em uma CLASSE.
Figura 16: Encapsulamento

Fonte: o autor.
■■ Polimorfismo: é a capacidade que OBJETOS de CLASSES diferentes pos-

suem de se comportarem de forma diferente em uma mesma operação.
A estrutura (ATRIBUTOS) de cada CLASSE é diferente.
Figura 17: Polimorfismo

Fonte: o autor.
I
■■ Método: é o algoritmo (conjunto de passos) que um OBJETO executa

quando reage a uma OPERAÇÃO. O método é a lógica interna de uma
operação.
public int somar( int num1, int num2 )

{
return num1 + num2;
}
Quadro 1: Declaração de um método
Fonte: o autor.
■■ Colaboração: é a troca de MENSAGENS que acontece entre OBJETOS

e atores.
Figura 18: Troca de mensagens entre os objetos

Fonte: o autor.
■■ Herança: é a propriedade que possibilita que a CLASSE herde caracte-

rísticas e comportamento de uma outra CLASSE.
Figura 19: Herança

Fonte: o autor.

27
PRINCIPAIS DIAGRAMAS DA UML
Agora que já conhecemos os principais termos utilizados na análise e projeto

OO, quero convidar você a conhecer os diagramas utilizados para documentação
de software. Apresentarei, de forma sucinta, cada um dos diagramas e veremos
com detalhes nas unidades seguintes.
A UML 2.0 apresenta treze diagramas, classificados em estruturais e de com-
portamento. A figura 20 mostra essa organização em um diagrama de classes.
Figura 20: Organização do Diagrama UML

Fonte: o autor.
É comum verificarmos que a documentação do software, na maioria das vezes,

não tem a devida atenção da equipe de desenvolvimento, ou por preguiça, ou
por falta de tempo, ou mesmo por achar que é uma perda de tempo elaborar
inúmeros diagramas. Porém bons softwares têm documentação que nos permite
contar e entender a história desse software.
Principais Diagramas da Uml

I
DIAGRAMAS DE COMPORTAMENTO
Os diagramas de comportamento são utilizados para descrever o sistema mode-
lado já em execução. São utilizados para especificar, visualizar, documentar e
construir os aspectos dinâmicos de um sistema, ou seja, é a representação das
partes que sofrem alterações.
DIAGRAMA DE CASOS DE USO
Iniciaremos, então, pelo Diagrama de Casos de Uso (comportamento), utilizado
na análise de requisitos. Esse diagrama acompanha o software desde o seu iní-
cio até a conclusão.
Para conhecermos o conceito de caso de uso, temos que conhecer, primeira-
mente, o ator. Este pode ser uma pessoa (usuário), um sistema ou uma máquina.
O ator é quem realiza as atividades e sempre atua sobre um caso de uso.
O diagrama de caso de uso da figura 21 modela o comportamento dos atores
no sistema de uma biblioteca, no exemplo, o diagrama mostra os atores ALUNO
e BIBLIOTECÁRIA, representados pelo stick man (homem palito) e suas res-
pectivas ações descritas nas elipses.
Figura 21: Diagrama de Caso de Uso

Fonte: o autor.

29
DIAGRAMA DE SEQUÊNCIA
Com o objetivo de refinar o diagrama de classes, o diagrama de sequência (com-

portamento) é um dos vários tipos de diagrama de interação disponibilizados
pela UML, sua utilidade é estudar as interações entre os objetos, possibilitando
a identificação de relação entre as classes.
O cenário representado na figura 22 mostra a solicitação de um empréstimo
pelo aluno, em que, a partir dessa ação, é desencadeado um conjunto de men-
sagens entre os objetos que permite a verificação da existência da pessoa aluno,
em seguida, é criado o item de empréstimo, que verifica a existência do exem-

plar solicitado, realizando o empréstimo.
Como é possível observar, a partir das informações fornecidas pelo dia-
grama de sequência, pode-se identificar os métodos associados às classes, além
da identificação das relações entre elas.


I
Figura 22: Diagrama de Sequencia

Fonte: o autor.
Uma outra forma de representar o cenário é pelo diagrama de comunicação
(comportamento), este contém as mesmas informações que o diagrama de sequ-
ência, porém não considera a dimensão temporal.

31
DIAGRAMA DE ESTADOS
Em seguida, veremos o diagrama de estados (comportamento), que tem como

objetivo especificar o comportamento das classes mais complexas utilizando
uma máquina de estados.
Autômato finito ou máquina de estados finitos representa a modelagem de

comportamentos considerando o seu estado. O estado guarda informações
sobre o passado do objeto, a transição indica que o objeto está mudando de
estado e uma ação é o detalhamento de uma atividade que deve ser execu-
tada em determinado momento.
Fonte: adaptado de Sommervile (2011).

I
Figura 23: Diagrama de Estado
Fonte: o autor.
Não são todas as classes do sistema que apresentam mais de um estado. O diagrama
de estado abaixo mostra todos os estados do exemplar no momento empréstimo,
o início do estado é marcado pelo círculo e o fim é mercado pelo duplo círculo.
Figura 24: Diagrama de Comunicação (comportamento)

Fonte: o autor.

33
DIAGRAMA DE COMUNICAÇÃO
O diagrama de comunicação permite a identificação das classes mais próxi-

mas e a ordem de envio de mensagens é identificada por números sequenciais.
A seguir, é apresentado o diagrama de comunicação que é equivalente ao dia-
grama de sequência mostrado anteriormente.
Figura 25: Diagrama de Atividades

Fonte: o autor.
DIAGRAMA DE ATIVIDADES
O diagrama de atividade é, em sua essência, um gráfico de fluxo, demonstrando

como ocorre o fluxo de controle entre as atividades. Esse diagrama é um dos
mais detalhistas, dando ênfase maior ao nível de algoritmo.
Os diagramas de atividades podem ser utilizados com vários propósitos.
Dentre seus propósitos, podemos citar a captura do funcionamento interno do
objeto, bem como mostrar como pode ser executo um conjunto de ações rela-
cionadas e como elas podem afetar os objetos ao seu redor.

I
DIAGRAMAS DE ESTRUTURA
Os diagramas estruturais são utilizados para especificar, visualizar, documentar

e construir os aspectos estáticos de um sistema, ou seja, diagramas estruturais
representam a estrutura estável. A estrutura estática de um sistema envolve a
existência e a colocação de itens como classes, pacotes, objetos, componentes e
utilização.
CLASSES
Após a elaboração do diagrama de caso de uso, podemos modelar a primeira

versão do diagrama de Classes. O diagrama de classes mostra a estrutura está-
tica do sistema.
Uma classe é uma estrutura que modela um conjunto de objetos cujas
características são similares. A classe, por meio dos métodos, modela o com-
portamento de seus objetos, e os possíveis estados do objeto são modelados por
meio de atributos.
Para entendermos melhor, vamos fazer a analogia com a construção de um
veículo. Todos os veículos serão rigorosamente iguais, pois estarão baseados
em uma planta (projeto) que esclarece o número de portas, potência do motor,
número de marchas do câmbio, dentre outros atributos. Portanto, o projeto do
veículo é a classe e os veículos são os objetos que foram baseados na classe.
O diagrama de classes, abaixo, modela a estrutura estática do sistema de
biblioteca apresentado em análise inicial por meio do diagrama de caso de uso,
a classe possibilita a abstração dos objetos mediante os atributos (data :date;
nome: string...) e métodos (Cria(); Recupera()...).
Toda notação do diagrama será inteiramente desmistificada na unidade 03,
mas, para adiantar, é possível observar nesse diagrama, além das classes, que
contém atributos e métodos, as conexões entre as classes, que podem ser uma
agregação, representada pelo losango, ou uma especialização, representada pelo
triângulo.

35
Figura 26: Diagrama de Classes

Fonte: o autor.
DIAGRAMA DE OBJETOS
Os diagramas de objetos correspondem a um segundo nível de abstração do

diagrama de classes. Não têm a mesma importância do diagrama de classes,
porém pode ser uma ótima opção para exemplificar os diagramas de classes
mais complexos.
O diagrama de objetos é o diagrama de classes instanciado. Utiliza a mesma
notação do diagrama de classes para mostrar as instâncias da classe.
Figura 27: Diagrama de Objetos

Fonte: o autor.
DIAGRAMA DE COMPONENTES
Um diagrama de componente mostra a organização e dependência entre todos

os componentes. Seu objetivo é modelar a visão de implementação dos módu-
los executáveis do software.
Apesar de ser um diagrama de alto nível, a organização do sistema é
dependente da linguagem de programação utilizada, portanto, a solução de
desenvolvimento adotada refletirá diretamente nesse diagrama.

I
Um componente corresponde a uma parte do código distribuível que pode

ser substituída por outro componente e que contém elementos que mostram um
conjunto de interfaces fornecidas e requeridas. Podemos apresentar como exem-
plos de componentes os executáveis, tabelas, bibliotecas, documento e arquivo.
Figura 28: Diagrama de Componentes
Fonte: o autor.
DIAGRAMA DE IMPLANTAÇÃO
Diagramas de implantação são utilizados para modelar a arquitetura física de

distribuição onde o software será executado. Esse diagrama mostra os nós e os
relacionamentos de comunicação.
O diagrama de implantação mapeia a arquitetura lógica de classe no nó de
processamento e suas dependências. Um nó representa um recurso computacio-
nal com memória e processamento, ou seja, um disco rígido, um computador,
uma impressora etc.
O diagrama de implantação é uma ferramenta importante quando qui-
ser saber quais computadores e outros hardwares estão conectados, bem como
saber como estão distribuídas as classes e quando a atualização de determinado
arquivo resulta na recompilação de outros.

37
Figura 29: Diagrama de Implantação

Fonte: o autor.
DIAGRAMA DE PACOTES
O pacote representa um agrupamento de classes, formando uma unidade.

Normalmente, os pacotes apresentam relações, em que um pacote depende de
outro para o funcionamento.
Como a estrutura de uma aplicação é dada pelas classes e associações, pode-
mos agrupar as Classes em pacotes de análise, o que facilita o manuseio do
modelo de análise.
Podemos utilizar o diagrama de pacotes para representar um conjunto de
subsistemas, que, nesse caso, cada subsistema é representado por um pacote.
Dessa forma, um pacote pode representar uma biblioteca, um subsistema, um
sistema, entre outros. Um pacote, também, pode conter outros pacotes.
Os pacotes, invariavelmente, apresentam dependência entre si. O relaciona-
mento de dependência indica que o pacote dependente precisa de alguma forma
do pacote do qual depende.

I
Figura 30: Diagrama de Pacotes

Fonte: o autor.
CONSIDERAÇÕES FINAIS
Nesta unidade, aprendemos que a análise é a solução conceitual dada ao problema.
Ela marca o início da definição informática, preocupa-se, principalmente, com as
classes do domínio do problema e suas relações e, também, com os casos de uso.
Já o projeto é o resultado do refinamento da análise e considera os detalhes
da implementação, tais como, a linguagem a ser utilizada e o sistema gerencia-
dor de banco de dados.
Você se familiarizou com o conceito de Orientação a Objetos, ou simples-
mente OO, que é um novo paradigma para o desenvolvimento de aplicações, ou
seja, é uma estratégia de desenvolvimento de software que organiza o software
como uma coleção de objetos, que contém tanto a estrutura dos dados como o
comportamento deles.
Verificamos que os métodos de análise e projeto orientado a objetos surgiram
assim que as linguagens de programação OO começaram a estabilizar, sendo que
um dos primeiros métodos foi o modelo OOSA, proposto por Shlaer e Mellor,
em 1988, e o Wirfs-Brock, lançado em 1989, pelo grupo de pesquisa da Smalltalk.
Por meio do estudo da evolução dos métodos, podemos perceber que UML-
Unified Modeling Language é a fusão dos métodos de James Rumbaugh/OMT,
Grady Boock e Ivar Jacobson. A fusão inicia com o trabalho de James Rumbaugh
e Grady Booch, em seguida, em meados de 1996, Ivar Jacobson integrou-se ao
grupo e lançaram a UML versão 0.9. A partir daí, criaram forças com a coope-
ração da OMG (Object Management Group) em julho de 1997, considerado um
padrão mundial.
Estudamos as características dos principais métodos OO e foi possível verificar
que a maioria das propostas abrangem as fases de análise, projeto, implementação

39
e testes. Após conhecermos os principais métodos e estudarmos as suas carac-

terísticas, entramos em contato com os conceitos de OO, em que aprendemos
sobre objetos, abstração, classes, operações, atributos, instância, mensagem,
dentre outros.
Por fim, conhecemos os diagramas utilizados para documentação de soft-
ware. Os diagramas de Caso de Uso, Classes, Estado, Sequência e Colaboração
foram apresentados de forma sucinta, já que os veremos com detalhes nas uni-
dades seguintes.
A partir dos conceitos que foram abordados nesta unidade, conseguimos ter
uma visão geral sobre a Orientação a Objetos. Agora, você vai conhecer as eta-
pas da análise e a notação para o diagrama de caso de uso.

1. Na análise e projeto estruturados, o processo a ser informatizado é visto como
um conjunto de funções com dados de entrada, processamento e dados de saí-
da, ou seja, a ênfase está em funções que agem sobre dados. Diferentemente da
análise e projeto estruturados, na orientação a objetos, o processo a ser infor-
matizado é visto como um conjunto de objetos que interagem para realizar as
funções. Sabendo disso, quais as vantagens do modelo OO?
2. A maior parte dos métodos OO passaram a se tornar estáveis na década de 90,
com a fusão das metodologias de Grady Boock, James Rumbaugh e Ivar Jacob-
son e a criação da UML, que se baseou, também, em outras metodologias, como
a de Shlaer-Mellor. Diante do exposto, quais as fases comuns aos métodos pro-
postos pelos autores citados?
I. A UML – Unified Modeling Language abrange as fases de levantamento
de requisitos, análise, projeto e implementação. É dada como a fusão dos
métodos de James Rumbaugh/OMT, Grady Boock e Ivar Jacobson. Quais
dos conceitos elencados nas assertivas são próprios da orientação a ob-
jetos?
II. Objetos: qualquer coisa concreta ou abstrata com existência perceptível
no mundo real.
III. Classes: ABSTRAÇÃO de um conjunto de OBJETOS.
IV. Atributo: característica particular possuída por todos os OBJETOS de uma
CLASSE.
5. Chave Primária: identifica unicamente um objeto.
Está(ão) correta(s) somente:
A. ( ) I.
B. ( ) I e II.
C. ( ) I, II e III.
D. ( ) III e IV.
E. ( ) I, II, III e IV.
4. É comum verificarmos que a documentação do software, na maioria das vezes,

não tem a devida atenção da equipe de desenvolvimento, ou por preguiça, ou
por falta de tempo, ou mesmo por achar que é uma perda de tempo elaborar
inúmeros diagramas. Bons softwares, porém, têm documentação que nos per-
mite contar e entender a história desse software. Contamos essa história por
meio de diagramas, sabendo disso, quais diagramas são utilizados na UML e
como estão organizados?
41
5. O Diagrama _____________ contém as mesmas informações que o diagrama de

sequência, porém não considera a dimensão temporal. Observe os Diagramas:
I. Comunicação
II. Caso de Uso
III. Classes
IV. Estado
A(s) afirmativa(s) que pode(m) completar a lacuna é(são) somente:
A. ( ) I.
B. ( ) I e II.
C. ( ) I, II e III.
D. ( ) III e IV.
E. ( ) I, II, III e IV.
QUALIFICAÇÃO DE SOFTWARES
Como pode ser qualificado um software? É muito simplório definir isso pelo tempo de
desenvolvimento ou pela excelência na programação. Existe caso de desenvolvimento
de softwares em que o programador ouve todas as informações e apresenta uma solu-
ção instantânea, quase que “mágica”. Algo que resolve perfeitamente o que foi apresen-
tado. Olhando assim, a sensação que temos parece que o atendimento foi excepcional,
contudo, na maioria dos casos, programas feitos nesse formato não suprem a real ne-
cessidade do cliente.
Não podemos julgar o cliente por não saber apresentar de forma assertiva as suas ne-
cessidades, pois o conhecimento da construção técnica é inexistente ou superficial, não
acompanha as tendências do mercado, entre outras hipóteses. E a consequência disso
tudo é a perda de investimento financeiro e de tempo em um projeto que não vai suprir
a necessidade geral e uma programação desgastante, tanto para o programador quanto
para o cliente. Casos assim não são exceções, é muito provável que você já tenha viven-
ciado isso.
Mas esse problema não é exclusivo do desenvolvimento de softwares, é algo corriquei-
ro no mercado. Para provar isso, basta precisarmos de um serviço em que não tenha
nenhum conhecimento do processo, como consertar um carro. A solução só vem quan-
do um profissional qualificado está mais preocupado em te satisfazer como cliente do
que resolver exclusivamente o seu problema apresentado. Os profissionais que mantêm
esse método de atendimento vão sendo substituídos aos poucos.
Na rotina diária de programação, normalmente, o início do projeto vem de um conversa
informal e só lá na primeira apresentação, depois de um grande tempo de dedicação, é
que o cliente consegue esclarecer ainda de forma abstrata com frases como “não é bem
isso que eu esperava”. Outro caso comum que acontece pela falta de alinhamento é as
solicitações do cliente irem aumentando durante o processo todo, e, como nada é esta-
belecido de forma clara no início do trabalho, você pode até prolongar o projeto, mas,
possivelmente, não atenderá todas as necessidades do seu cliente.
Finalizo lembrando que cliente não tem obrigação de entender como funciona toda
a programação e que a preocupação deve ser do programador de atender o cliente, e
não o contrário. Um bom profissional precisa “interpretar” a necessidade de um cliente e
oferecer não o que ele está pedindo, mas sim o que vai suprir sua necessidade.
Fonte: Autor.
MATERIAL COMPLEMENTAR
Desenvolvendo software com UML 2.0 definitivo

Ernani Medeiros
Editora: Makron Books
Sinopse: Este livro apresenta, de maneira prática e já testada, o que é, para que serve e
como usar os diagramas da UML 2.0. Além de sugerir o melhor momento para se pensar
em modelagem de banco de dados e propor passos dentro do processo de construção de
software, também aborda parte técnica, notação, semântica, finalidade do conceito e como
usá-lo.
Para aprofundar os conhecimentos sobre OO, leia o artigo intitulado “A história de UML e seus
diagramas”. Esse artigo descreve a história de UML desde a década de 1990 até o momento
atual. Apresenta-se a organização dos treze diagramas de UML, classificando-os em diagramas
estruturais e comportamentais. Os quatro documentos pertencentes à especificação também são
mencionados e explicados.
O artigo encontra-se disponível em: <https://projetos.inf.ufsc.br/arquivos_projetos/projeto_721/
artigo.tcc.pdf>. Acesso em: 28 jul. 2015.
Material Complementar
II
UNIDADE
CASOS DE USO
■■ Conhecer as fases da análise e projeto.
■■ Entender os modelos de processo.
■■ Compreender como ocorre o levantamento de requisitos.
■■ Diferenciar requisitos funcionais de não funcionais.
■■ Conhecer o diagrama de Caso de Uso.
Plano de Estudo
■■ Fases da análise e do projeto
■■ Modelos de processo
■■ Requisitos de software
■■ Diagrama de Casos de Uso
47
INTRODUÇÃO
Caro(a) aluno(a), iniciamos a segunda unidade do livro Análise e Projeto

Orientado a Objetos falando sobre as fases da análise e do projeto de software.
Conheceremos cada uma das etapas da análise, que acredito ser a fase mais
difícil e crítica da produção de um software, difícil porque é o momento que
ocorrem as tentativas de delimitar o domínio do problema e entendê-lo, crítica
porque uma análise mal feita comprometerá todas as outras fases de produção
do software, além do que o produto a ser entregue não será o que o cliente ini-
cialmente requeria.
Entenderemos e conheceremos dois modelos de processos de software,
entre os “N” processos existentes. Citarei, aqui, o modelo em cascata e o evo-
lucionário, em cascata por ser o primeiro modelo de processo a ser utilizado e
evolucionário por ser um dos modelos mais utilizados, principalmente na fase
de aprendizagem do problema.
Veremos que os requisitos de software são objetivos ou restrições estabele-
cidas por clientes e usuários do sistema que definem as diversas propriedades
dele. Aprenderemos como identificar os “requisitos funcionais”, que definem as
funções do sistema, e os “requisitos não funcionais”, que definem outros tipos
de características que o sistema deverá possuir.
Ainda, veremos a importância do levantamento de requisitos para o desen-
volvimento de software. Aprenderemos que a definição de requisitos pode se
utilizar de uma narrativa ou de representações gráficas. Por meio dessas defini-
ções, pode ser elaborado o documento preliminar de requisitos.
E, finalmente, conheceremos o diagrama de Caso de Uso, em que enten-
deremos a notação e o objetivo do caso de uso na fase de análise do software.
Diagramas de casos de uso são utilizados para representar, de forma panorâmica,
os requisitos funcionais de um sistema do ponto de vista do usuário.
Então, o que estamos esperando? Vamos ao trabalho.
Introdução
II
FASES DA ANÁLISE E DO PROJETO
Como vimos na unidade 1, a análise de sistemas é a atividade inicial do pro-

cesso de desenvolvimento de software em que se determina e especifica o que um
sistema deve fazer, bem como as circunstâncias sob as quais deve operar, envol-
vendo, geralmente, um esforço colaborativo entre analistas de sistemas e usuários.
De acordo com Sommervile (2011), a análise é realizada com os seguintes
objetivos em mente:
■■ Identificar a necessidade do usuário.
■■ Executar análise econômica e técnica.
■■ Atribuir funções ao hardware, software, pessoas, banco de dados e aos
demais elementos do sistema.
■■ Estabelecer as restrições de prazo e de custo.
■■ Criar uma definição de sistema que constitua a base para todo o traba-
lho subsequente.
Independente do método ou processo utilizado para a análise, projeto e imple-

mentação, algumas etapas são comuns, são elas (SOMMERVILE, 2011):
■■ Identificação da Necessidade.
■■ Estudo de Viabilidade.
■■ Análise.
■■ Projeto (Ferramentas).
■■ Implementação (Codificação).
■■ Implantação.
■■ Manutenção (Adaptativa, Corretiva e Evolutiva).
A seguir, detalharei cada uma dessas etapas de suma importância para a produ-
ção de um software de qualidade.
CASOS DE USO
49
IDENTIFICAÇÃO DA NECESSIDADE
Vamos comentar cada uma dessas etapas começando pela identificação da neces-
sidade, que é o ponto de partida na evolução de um sistema. Nessa etapa, são
definidas as metas globais do sistema, respondendo algumas perguntas-chave:
■■ Quais informações serão produzidas?
■■ Quais informações devem ser fornecidas?
■■ Que funções e desempenho são exigidos?
Ainda nessa etapa, após a definição das metas, o analista deve avaliar:
■■ Existe tecnologia para construir o sistema?
■■ Qual o custo de produção e tempo necessário para conclusão?
Caso o novo sistema seja um produto a ser desenvolvido para venda a muitos
clientes, o analista ainda deve avaliar o seguinte:
■■ Qual é o mercado em potencial para o produto?
■■ Como esse produto se compara com os produtos dos concorrentes?
ESTUDO DE VIABILIDADE
Na etapa seguinte, temos a Análise de Viabilidade, em que o analista deve deter-

minar rapidamente se o problema pode ser resolvido considerando cinco aspectos
de viabilidade: técnico, legal, operacional, temporal e econômico.
No aspecto da viabilidade técnica, o analista deve determinar se o projeto
pode ser desenvolvido e implementado usando os recursos existentes: computa-
dores, periféricos, sistema operacional. E, também, se existe pessoal competente
à disposição para desenvolver o sistema em questão (SOMMERVILE, 2011).
No aspecto da viabilidade legal, o analista verifica se não existem conflitos
entre o sistema em consideração e os compromissos legais que a empresa tem.
O analista deve considerar as implicações legais que aparecem nos estatutos
Fases Da Análise E Do Projeto

II
estaduais/federais e nas cláusulas contratuais.

No aspecto operacional, o analista faz a verificação de que o sistema será
capaz de executar as funções projetadas no ambiente organizacional existente
com o pessoal atual.
No aspecto de tempo, o analista deve determinar o cronograma para desen-
volvimento e verificar se o sistema será factível no tempo determinado.
O último aspecto é o da viabilidade econômica, em que o analista deve deter-
minar se os benefícios sobrepõem os custos; se a despesa estimada ultrapassar
a expectativa da administração ou se os benefícios não justificarem os custos, o
projeto provavelmente será abandonado.
Análise
A coleção exata dos dados é essencial para uma análise completa de um sis-
tema, portanto, o analista deve considerar os seguintes objetivos (SOMMERVILE,
2011):
■■ Entender os objetivos do sistema (o que o administrador/usuário espera
do sistema).
■■ Entender as exigências do sistema (o que processar e que saídas produzir).
■■ Entender que os objetivos e exigências são satisfeitos por meio de cui-
dadosa análise.
■■ Entender as áreas-problema do sistema.
Para tanto, são utilizadas técnicas para o levantamento de dados, tais como:
■■ Estudo dos manuais de procedimentos.
■■ Análise de formulários.
■■ Entrevista.
■■ Questionário.
■■ Observação.
CASOS DE USO
51
Projeto
Após a análise, ou levantamento de requisitos, ou, ainda, engenharia de
requisitos (como quiser chamar), vem o projeto que é a solução informática
dada ao problema.
De acordo com Sommerville (2011), o projeto de software descreve a estrutura
do software que será implementado. Nele estão contidos os dados e a interface
entre os componentes do sistema. Na primeira versão do projeto, ainda não é
possível detalhar completamente o sistema, pois, ao se elaborar modelos com
diferentes níveis de abstração, é possível detectar problemas nos níveis anterio-
res. A cada nível seguinte, são criados modelos mais detalhados, diminuindo
cada vez mais a abstração.
O projeto de software é importante para formalizar as regras de negócio do
sistema, melhorando a comunicação entre o cliente e o programador.
Implementação
É neste estágio de desenvolvimento de software no qual se cria uma versão
executável do software, utilizando as ferramentas para desenvolvimento defini-
das no projeto.
A implementação pode iniciar após o término do projeto, ou pode acontecer
de forma paralela ao projeto, tudo depende do modelo de processo escolhido.
Implantação
A implantação corresponde à fase na qual o software será entregue ao cliente.
Na fase do estudo da viabilidade, foi levantada pelo analista a viabilidade
técnica, em que se buscou verificar se o projeto pode ser desenvolvido e imple-
mentado usando os recursos existentes: computadores, periféricos, sistema
operacional, dentre outros, e, também, se existe pessoal competente à disposi-
ção para desenvolver o sistema em questão.
Todo o projeto é construído com base no estudo de viabilidade técnica,
utilizando ferramentas suportadas pelo hardware e entendida pelos usuários,
portanto, os riscos da implantação não funcionar são minimizados no projeto.
O fator de maior preocupação nesta fase é justamente o período que será
necessário para a adaptação do usuário com o novo sistema, pois toda mudança
Fases Da Análise E Do Projeto

II
gera transtornos, na maioria das vezes, o usuário está acostumado a executar suas
tarefas de determinada forma e a mudança é vista com restrição.
Manutenção
A manutenção é o processo de modificar o sistema desenvolvido depois que
ele é colocado em operação, é a fase do ciclo de vida do software que dura mais
tempo, até que o sistema deixe de ser utilizado.
O software é continuamente modificado ao longo de seu tempo de duração,
em resposta a requisitos em constante modificação e às necessidades do cliente.
As manutenções não dizem respeito somente à correção do software por
motivos que não foram possíveis observar no momento da análise, projeto ou
mesmo na implementação.
As manutenções podem ser adaptativas, que têm o objetivo, como o próprio
nome diz, de adaptar algumas tarefas ou funções para o ambiente de implanta-
ção. As manutenções também podem ser evolutivas, que têm como objetivo a
inserção de novos módulos no sistema.

CASOS DE USO
53
MODELOS DE PROCESSO
A análise e o projeto de sistemas de software deve fornecer para os stakeholders

(equipe envolvida), composto pelo cliente, analista, programador, entre outros,
uma única compreensão do projeto.
De acordo com Medeiros (2004), a UML não se trata de um método, mas
sim de uma linguagem. Um método é composto por processo e um modelo de
linguagem. Os processos são os passos que devem ser seguidos para se construir
o projeto. O modelo de linguagem é a notação que o método usa para descrever
o projeto. Um modelo de processo de software define a sequência em que as ati-

vidades do processo serão realizadas.
MODELO CASCATA
Vamos tomar como exemplo o modelo de processo em cascata, ou queda d’água,

como colocado por alguns autores.
Figura 23: Modelo Cascata

Fonte: adaptada de Sommervile (2011).
Conhecido como Ciclo de Vida Clássico, o modelo em cascata é o primeiro a ser

publicado do processo de desenvolvimento de software. O modelo considera as
atividades de especificação, desenvolvimento, validação e evolução como fases
separadas do processo.
Modelos De Processo
II
A primeira fase é a Análise e definição de requisitos (especificação de requi-

sitos). As funções, as restrições e os objetivos do sistema são estabelecidos por
meio da consulta aos usuários.
A segunda fase é o Projeto de sistemas e de software, em que os requisi-
tos em sistemas de hardware ou de software são agrupados, estabelecendo uma
arquitetura do sistema geral.
A terceira fase é a Implementação e teste de unidades, durante esse estágio,
o projeto de software é compreendido como um conjunto de programas ou de
unidades de programa. O teste de unidade envolve verificar que cada unidade
atenda a sua especificação.
A quarta fase é a Integração e teste de sistemas; nesse estágio, as unidades
de programa ou programas individuais são integrados e testados como um sis-
tema completo, a fim de garantir que os requisitos de software foram atendidos.
A quinta fase é a Operação e Manutenção, normalmente, essa é a fase mais
longa do ciclo de vida. O sistema é instalado e colocado em operação. A manu-
tenção envolve corrigir erros que não foram descobertos em estágios anteriores
do ciclo de vida ou aumentar as funções desse sistema à medida que novos requi-
sitos são descobertos.
Nesse modelo de processo em cascata, pressupõe-se que o domínio do pro-
blema foi inteiramente compreendido, portanto, é o modelo indicado quando
conhecemos por inteiro a regra de negócio do software.
MODELO EVOLUCIONÁRIO
Quando estamos produzindo um software e ainda não conhecemos todo o domí-

nio do problema, é recomendável a utilização do modelo de desenvolvimento
evolucionário.
O modelo evolucionário tem como base a ideia de desenvolver uma imple-
mentação inicial, expor o resultado ao comentário do usuário e fazer seu
aprimoramento por meio de muitas versões, até que um sistema adequado
tenha sido desenvolvido.
Em vez de ter as atividades de especificação, desenvolvimento e validação
CASOS DE USO
55
em separado, todo esse trabalho é realizado concorrentemente com um rápido

feedback por meio dessas atividades.
A figura 31 ilustra bem as fases do modelo evolucionário.
Figura 31: Modelo Evolucionário

Fonte: adaptada de Sommervile (2011).
Devido à característica de produzir sistemas que atendam às necessidades ime-

diatas do usuário, muitas vezes, o modelo evolucionário é mais eficaz do que a
abordagem em cascata. A vantagem da abordagem evolucionária está na especi-
ficação que pode ser desenvolvida gradualmente, na medida em que os usuários
compreendem melhor o problema.
Porém, como nem tudo são flores, problemas acontecem nesse modelo,
vamos enumerar alguns:
■■ Como os sistemas são desenvolvidos rapidamente, não é viável produzir
documentos que reflitam cada versão do sistema.
■■ Os sistemas, frequentemente, são mal estruturados. A mudança constante
tende a corromper a estrutura do software. Incorporar modificações tor-
na-se cada vez mais difícil e oneroso.
Utilizando o modelo em cascata ou modelo evolucionário, ou qualquer outro

modelo de desenvolvimento, é possível, nas fases de análise e projeto, optar por
uma abordagem de análise e projeto estruturado, dessa forma, construiremos dia-
gramas de entidade-relacionamento (DER), diagrama de fluxo de dados (DFD),
diagrama de contexto, dicionário de dados etc. Esses modelos fornecem uma
Modelos De Processo
II
compreensão única do projeto.

Contudo, o foco da nossa disciplina é a orientação a objetos, portanto, nas
fases de análise e projeto, construiremos Diagramas de Caso de Uso, Diagramas
de Classes, Diagramas de Estado, Diagramas de Sequência etc. Esses modelos
fornecerão uma compreensão única do projeto.
LINGUAGEM DE MODELAGEM
A Linguagem de modelagem é uma parte muito importante do método.
Corresponde ao ponto principal da comunicação. Se uma pessoa quer conver-
sar sobre o projeto com outra pessoa, é por meio da linguagem de modelagem
que elas se entendem.
A UML define uma notação e um meta-modelo. Todos os elementos de
representação gráfica vistos no modelo (retângulo, setas, o texto etc.) são a nota-
ção, esta é a sintaxe da linguagem de modelagem. A notação do diagrama de
classes define a representação de itens e conceitos, tais como: classe, associação
e multiplicidade.
Visto isso, é possível concluir que, independente do modelo de processo de
software que você escolheu, é de suma importância que o domínio do problema
seja entendido por todos da equipe de desenvolvimento, inclusive o cliente.
A charge a seguir ilustra de forma lúdica o que ocorre em um projeto de soft-
ware em que a equipe de desenvolvimento e o cliente não se entendem.
CASOS DE USO
Figura 32 Projeto de Software
Modelos De Processo
57
II
Pense em quais habilidades o analista deve possuir, uma vez que lida com
vários grupos de usuários. Além de se preocupar com o desenvolvimento e
com todos os componentes do sistema.
Fonte: o autor.
REQUISITOS DE SOFTWARE
Agora que já sabemos a importância da análise e do projeto na produção de um
software, vamos conhecer os procedimentos mínimos necessários para a obten-
ção de um software de qualidade.
Para tal, precisamos fazer uma engenharia de requisitos, mas o que é enge-
nharia de requisitos? Vamos por partes, então. O termo “ENGENHARIA” permite
dizer que é utilizado um processo sistemático na definição do software. Nesse
contexto, a engenharia de requisitos tem como objetivo compreender o sistema,
ou seja, preocupa-se com “o que fazer” e não com o “como fazer”.
As principais atividades da engenharia de requisitos são (SOMMERVILE,
2011):
■■ Especificar o problema (elicitar).
■■ Compreender o problema (analisar).
■■ Definir uma proposta (modelo válido).
■■ Atualizar requisitos (gerenciar).
Na primeira atividade, que é a de elicitar, devemos obter o máximo de informa-

ções para o conhecimento do objeto em questão, dentro do domínio do problema.
CASOS DE USO
59
DOMÍNIO
E o que é domínio? Para entender melhor, vamos imaginar que você foi contra-
tado para desenvolver um software em uma determinada Casa de Carnes. Do
lado direito da Casa de Carnes, existe uma farmácia, do lado esquerdo, um mer-
cado, atrás, uma lanchonete e, em frente, uma igreja.
Nesse caso, o domínio do seu problema é a Casa de Carnes, os demais esta-
belecimentos estão na fronteira do seu problema, portanto, não fazem parte dele.
Creio que, dessa forma, fica fácil compreender o que é o domínio do problema.
É óbvio que determinar o domínio do problema não é uma tarefa trivial,

pois você pode ser contratado para desenvolver um software para determinado
departamento de uma empresa, dessa forma, determinar o domínio do problema
se torna mais complexo.
Sendo assim, os limites do domínio (fronteira) podem ser determinados
por meio do estabelecimento dos objetivos pretendidos. Para tanto, não deve-
mos centrar em funcionalidades, e sim na finalidade.
REQUISITOS
E o que são requisitos?

Os requisitos são os objetivos e as restrições estabelecidas pelo usuário do
sistema. É o usuário ou cliente o responsável por descrever as necessidades ou
desejo para o software (SOMMERVILE, 2011).
Em um primeiro momento, é interessante definir os requisitos sem se preo-
cupar em detalhá-los. Isso permite ter uma visão global do domínio de maneira
mais rápida.
Para a definição de requisitos, produzimos um documento contendo decla-
rações em linguagem de alto nível dos requisitos e restrições do sistema. Já na
especificação de requisitos, produzimos um documento estruturado contendo
requisitos e restrições descritos detalhadamente.
Vamos aos exemplos:
Requisitos De Software
II
Especificação de requisitos:
1.1. O usuário deverá ser provido de recursos que permitam definir os

tipos de arquivos externos que serão acessados.
1.2. Para cada tipo de arquivo externo, deve ser associado o aplicativo
que o gerou.
1.3. A cada tipo de arquivo externo deve ser associado um ícone
específico.
1.4. Deverá ser permitido ao usuário definir os ícones que serão utiliza-
dos na representação dos arquivos externos.
Na definição de requisitos, pode se utilizar de uma narrativa ou de represen-

tações gráficas. Normalmente, as informações coletadas são fornecidas pelo
usuário. Por meio dessas definições, pode ser elaborado o documento prelimi-
nar de requisitos.
Requisitos podem ser divididos em:
■■ Requisitos Funcionais (RF).
■■ Requisitos Não Funcionais (RNF).
Os requisitos funcionais definem as funções do sistema, ou seja, o que se

espera que o sistema faça. Eles relatam as diversas funções que deverão ser pro-
vidas pelo software ao cliente ou usuário. Por exemplo:
■■ Monitorar sensores de temperatura.
■■ Cancelar o débito na conta corrente, caso a operação não seja completada.
■■ Avisar quando o estoque chegar ao limite mínimo.
Os requisitos não funcionais estão relacionados às tecnologias utilizadas, usabili-

dade, desempenho, segurança, confiabilidade, manutenibilidade, disponibilidade
que o sistema deverá possuir. Por exemplo:
■■ O sistema deverá apresentar interface gráfica (padrão windows).
■■ Facilidade de uso.
CASOS DE USO
61
■■ Possibilitar ajuda no contexto.
A partir das definições dos requisitos, produzimos o documento preliminar de

requisitos, que deve conter todos os serviços (requisitos) requeridos pelo cliente
explicitados de forma clara, sem contradições. Atingir esse objetivo é uma tarefa
difícil pelas inúmeras dificuldades que são encontradas no domínio. Para que
essas dificuldades sejam superadas, o documento preliminar de requisitos deve
conter algumas características de qualidade. Segundo Pressman (1995), são elas:
Característica 1 - precisam ser corretas: cada declaração de requisito deve
expressar exatamente a funcionalidade almejada. Declarações de requisitos que
conflitam com suas respectivas necessidades não estão corretas. Apenas o usuário
pode determinar se a declaração está correta, por meio de inspeções. Inspeções
em que não há a participação do usuário pode tornar o documento de requisi-
tos um documento de adivinhações.
Característica 2 - precisam ser possíveis: você precisa ser hábil para imple-
mentar cada requisito declarado, observando os recursos e limitações do sistema
e ambiente. Para evitar requisitos impossíveis, trabalhe com o pessoal técnico o
documento de requisitos, checando o que é possível e o que não é possível fazer,
avaliando custos e viabilidade.
Característica 3 - precisam ser necessários para o projeto: cada declaração de
requisito deve documentar apenas as necessidades do cliente ou qualquer outra
necessidade que exija atender a um requisito externo, ou uma interface externa,
ou, ainda, um padrão. Você pode pensar que “necessário” significa cada requi-
sito que tem origem na fonte que tem autoridade para determiná-lo.
Característica 4: é necessário definir prioridades: atribua uma prioridade
de implementação para cada requisito ou, ainda, defina casos de uso que auxi-
liem na indicação do quanto é essencial um requisito para o produto. Clientes
devem ter sua parte na responsabilidade do estabelecimento de prioridades. Se
todos os requisitos forem igualmente prioritários, você deve ter a habilidade de
definir conjuntamente com o cliente a prioridade de cada requisito.
Característica 5: não podem ser ambíguas: cada declaração deve ser expli-
citada de maneira que permita somente uma interpretação. Linguagem natural
é altamente propensa a ambiguidades. Elimine termos subjetivos, como ami-
gável ao usuário, fácil, simples, rápido, eficiente, vários, aperfeiçoar, maximizar
Requisitos De Software
II
e minimizar. Escreva cada requisito na linguagem do cliente de forma sucinta,

simples, direta, sem utilizar jargões técnicos.
Característica 6: precisam ser verificáveis: veja se é possível aplicar testes ou
utilizar outras abordagens para verificações, tais como inspeções ou demonstra-
ções para se certificar de que cada requisito será implementado apropriadamente.
Requisitos que não são consistentes, possíveis ou desprovidos de ambiguidades
também não são verificáveis.
Após o estágio de elicitação (extração), um documento contendo os requisi-
tos do cliente (necessidades, restrições, objetivos etc.) é definido. Esse documento,
que poderíamos chamar de Documento Preliminar de Requisitos, deverá sofrer
um processo de análise.
A fase de Análise envolve uma série de atividades (SUMMERVILE, 2011):
■■ Validação e Verificação.
■■ Análise de Viabilidade.
■■ Resolução de conflitos.
■■ Definição de prioridade.
Os requisitos coletados devem ser verificados e validados, com o objetivo de

garantir se estão completos, consistentes e de acordo com as reais necessidades
do domínio. Assim como nos demais procedimentos da análise de requisitos,
a participação dos interessados deve ser intensa, ou seja, todos os agentes que,
direta ou indiretamente, influenciam os requisitos do sistema precisam estar
envolvidos nesse processo.
Os casos de uso têm um papel importantíssimo na análise de requisitos, pois
permitem criar um cenário do domínio. Talvez esse seja o único instrumento
que acompanha o software do início até seu término.
Casos de uso representam funcionalidades completas para o usuário e
não funcionalidades internas do sistema. Outro ponto importante é que o dia-
grama de casos de uso é um artefato de comunicação entre cliente, usuários e
desenvolvedores.
Por ser extremamente simples e, consequentemente, de fácil compreensão,
incentiva a participação do cliente e usuários no processo de desenvolvimento.
CASOS DE USO
63
Também serve como um contrato entre a equipe desenvolvedora e o cliente.

A coleção de casos de uso representa todos os modos pelos quais o sistema
pode ser utilizado pelos atores envolvidos. Um caso de uso é uma sequência de
ações realizada colaborativamente pelos atores envolvidos e pelo sistema que
produz um resultado significativo (com valor) para os atores. Um ator pode ser
um usuário ou outro sistema.
O diagrama de casos de uso é apenas um panorama visual das funcionalida-
des do sistema, é necessária uma descrição textual para detalhar os casos de uso.
Portanto, a saída da fase de análise de requisitos é composta por:
Lista de requisitos funcionais e não funcionais.

Diagrama de casos de uso e definições textuais dos casos.
DIAGRAMA DE CASOS DE USO
Agora que já conhecemos o contexto de requisito de software, vamos para a con-

fecção do diagrama de caso de uso. O modelo de casos de uso (que é mais do que
o diagrama) é o principal resultado da fase de análise de requisitos.
Diagramas de casos de uso são utilizados para representar, de forma pano-
râmica, os requisitos funcionais de um sistema do ponto de vista do usuário.
O modelo de caso de uso é um diagrama utilizado na análise de requisitos
com objetivos claros:
■■ Compreender o problema (Elicitar).
■■ Delimitar o sistema (Domínio).
■■ Definir as funcionalidades oferecidas ao usuário (não precisamos nos pre-
ocupar nesse momento com a implementação).
Diagrama de Casos De Uso

II
Vamos conhecer a notação para os diagramas de caso de uso preconizados pela

UML. Os elementos básicos de um diagrama de casos de uso são:
■■ Atores.
■■ Casos de uso.
■■ Relações entre atores e casos de uso.
Figura 33: 0 Ator
Fonte: o autor.
Atores
Começaremos, então, pelo homem palito, que representa um ator no meu
sistema, este ator pode ser uma pessoa, outro sistema ou uma entidade externa
ao sistema.
Como encontrar os atores para um sistema? Usando as seguintes dicas:
■■ Examine o problema procurando por pessoas ou sistemas do entorno.
■■ Faça as seguintes perguntas:
• Quais as pessoas ou departamentos interessados em um determinado requi-
sito funcional?
• Quem irá suprir o sistema com informações e quem irá receber informa-
ções do sistema?
• Quais os recursos externos utilizados pelo sistema?
• Uma pessoa desempenha diferentes papéis?
• O sistema interage com outros sistemas já existentes?
Essas dicas também não garantem que o ator foi bem escolhido da primeira vez,
pois esse é um processo iterativo, a primeira tentativa dificilmente será a definitiva.
CASOS DE USO
65
“As empresas vivem os desafios constantes de produzir software de alta

qualidade, de impacto no sucesso de seus negócios, com ótima relação cus-
to benefício e, acima de tudo, em curto prazo. A engenharia de software
estabelece a importância de considerar a estratégia da organização e a ge-
ração de valor no planejamento e na implantação dos seus projetos”.
O texto completo do artigo “Proposta de integração da engenharia de sof-
tware nas estratégias empresariais”, de Adalberto Faria dos Reis e Ivanir da
Costa, você encontra no link disponível em: <http://www.scielo.br/scielo.

php?script=sci_arttext&pid=S0103-65132005000300013&lang=pt>. Aces-
so em: 29 jul. 2015.
Fonte: Reis e Costa (online).
Casos de Uso
A coleção de casos de uso representa todos os modos de execução do sis-
tema do ponto de vista do usuário. Um caso de uso é uma sequência de ações
que produz um resultado significativo para um ator.
Em um caso de uso, são necessárias as seguintes definições:
■■ As tarefas de cada ator.
■■ Quais informações o ator obtém do sistema.
■■ Quem fornece as informações.
■■ Quem captura as informações.
■■ Se algum ator precisa ser informado sobre eventos produzidos pelo sistema.
■■ Se existem eventos externos que devem ser notificados ao sistema.
A elipse é a notação para os casos de uso ou use case, as duas denominações são
utilizadas. Um caso de uso representa uma atividade que o ator realiza.

II
Figura 34: Caso de Uso

Fonte: o autor.
O caso de uso necessita de uma descrição, porém não há descrição padrão defi-
nida pela UML. Em geral, o diagrama é bastante informal e sua estruturação
(relação entre casos) não deve ser levada ao extremo.
É importante ressaltar que o diagrama de casos de uso é uma forma de visua-
lizar os casos e não de descrevê-los detalhadamente.
Sendo assim, o diagrama por si só não é suficiente. Os casos de uso devem
vir acompanhados de uma descrição onde normalmente relacionamos os seguin-
tes itens:
■■ Nome.
■■ Descrição.
■■ Requisitos funcionais providos pelo caso de uso.
■■ Restrições, tais como pré e pós-condições.
■■ Pré-condições: define o que deve ser verdadeiro para que o caso de uso
seja iniciado. Por exemplo, em um sistema para seguro de veículo, para o
caso de uso Fazer Seguro Veicular, uma pré-condição é apresentar a CNH.
■■ Pós-condições: o que se torna verdadeiro pela execução do caso de uso.
No mesmo caso de uso acima, o sistema pode se encontrar em um dos
seguintes estados: seguro concedido ou seguro não concedido por repro-
vação da CNH.
■■ Invariantes: condições que são verdadeiras durante a execução do caso
de uso.
■■ Fluxos de eventos: descrição de interações entre atores e sistema que ocor-
rem durante a execução do caso de uso.
■■ Outras informações: data, autor etc.
CASOS DE USO
67
Relações de dependência
As relações de dependência são representadas por uma seta tracejada, a seta
parte do caso de uso que depende de outro em algum momento, o diagrama da
figura 35 nos diz que para o cadastro de aluno é necessária conclusão do cadas-
tro de pessoa.
Figura 35: Dependência

Fonte: o autor.
Se um caso de uso inclui o comportamento de outro caso de uso, então, dizemos

que um usa o outro. Nesse caso, a linha tracejada com uma seta também pode
representar uma inclusão de outro caso de uso. No exemplo da figura 36, o caso
de uso Calcular Contas a Receber utilizará a forma de cálculo que está na docu-
mentação de Calcular Contas a Pagar; usamos esse artifício para evitar ter que
digitar duas vezes a mesma especificação.
Figura 36: Inclusão

Fonte: o autor.
Já as extensões adicionam um comportamento a um caso de uso que descreve

uma variação do comportamento normal. Nessa situação, o caso de uso base
pode ser executado mesmo sem a extensão. O modelo da figura 37 mostra que
existe um cálculo em Calcular Descontos que irá se estender para Calcular Contas
a Pagar, ampliando o significado da fórmula existente em Calcular Descontos.

II
Figura 37: Extensão

Fonte: o autor.
Vale lembrar que o diagrama de casos de uso é apenas um panorama visual das
funcionalidades do sistema, é necessária uma descrição textual para detalhar os
casos de uso.
Vamos ilustrar essa documentação por meio do caso de uso para resolver
expressões aritméticas.

Fonte: o autor.
Podemos fazer a descrição textual para o caso de uso Resolver Expressões

Aritméticas de acordo com o quadro a seguir:
NOME DO CASO DE USO RESOLVER EXPRESSÕES ARITMÉTICAS

Descrição Permite resolver expressões envolvendo números
inteiros e reais e as operações básicas de soma, sub-
tração, multiplicação e divisão.
Ator Aluno
Pré-condições O sistema deve estar em execução
Pós-condições Expressão aritmética resolvida ou cancelamento da
operação pelo aluno.
Fluxo Básico
Usuário Sistema
{Solicita Expressão}
Solicita a expressão. (A2)
CASOS DE USO
69
Fornece a Expressão
{Valida a expressão}
Avalia se a expressão é sintaticamente correta (A1)
{Calcula valor}
Calcula o valor da expressão
{Mostra o resultado}
Informa o resultado da expressão
{Fim}
Fim do caso de uso

Fluxos alternativos
A1: em {Valida expres- Se o usuário fornecer uma expressão sintaticamente
são} incorreta, informá-lo sobre o erro e retornar ao fluxo
básico em {Solicita expressão}
A2: em {Solicita expres- O usuário pode decidir encerrar o caso de uso sem
são} fornecer uma expressão. Nesse caso, retornar ao fluxo
básico em {Fim}
Quadro 1: Resolver expressões aritmética
Essa descrição textual detalha o caso de uso, mostrando prés e pós-condições

para execução, bem como o fluxo básico de execução, que significa dizer que
o sistema solicitará a expressão aos alunos que poderão cancelar, se desejarem,
sendo desviado o fluxo de execução para o fluxo alternativo A2, porém, caso não
cancele, o sistema validará a expressão fornecida pelo aluno, desviando para o
fluxo alternativo A1, que tem como objetivo validar a expressão de entrada, se
passar pela validação, o sistema calculará o valor e mostrará o resultado.
Um fluxo descreve como o sistema e os atores colaboram para produzir algo
de valor aos atores e o que pode impedir sua obtenção. Um fluxo descreve um
caminho entre muitos possíveis, visto que um caso de uso pode ser executado
de vários modos.
Existem fluxos básicos, que demonstram o fluxo normal de eventos, e alter-
nativos, que dizem o que fazer, caso não seja possível seguir o fluxo básico.
Para exemplificar, vamos nos inspirar na situação em que uma pessoa
explica um caminho à outra. Primeiro, o fluxo básico é explicado, depois, o
fluxo alternativo.

II
No caso de uso acima “Resolver expressões aritméticas”, o usuário pode tanto

fornecer a expressão para o cálculo (fluxo básico) quanto cancelar a operação,
desviando o fluxo alternativo A2, porém, caso o usuário siga no fluxo básico,
após o fornecimento da expressão para cálculo, o fluxo será desviado para um
caminho alternativo A1 que valida a entrada.
Dessa forma, podemos dizer que um fluxo alternativo apresenta um compor-
tamento opcional, de outra forma, que não é parte do comportamento normal
de um caso de uso.
Fluxos alternativos são utilizados para representar tratamento de exceções
ou um comportamento alternativo complexo que tornaria o fluxo básico muito
longo ou de difícil compreensão.

CASOS DE USO
71
Nesta unidade, aprendemos que o papel da análise é obter a partir dos usuários,
em um processo gradual e cumulativo, o maior conhecimento possível acerca
do domínio do problema e respectivo ambiente.
Vimos que, independente do método ou processo utilizado para a análise,
projeto e implementação, algumas etapas são comuns, por exemplo, a identifica-
ção da necessidade, o estudo de viabilidade, a análise, o projeto, a implementação,
a implantação e a manutenção.
Aprendemos que um método precisa de um modelo de linguagem e um

processo. O primeiro diz respeito à notação que o método usa para descrever o
projeto. Já o segundo descreve os passos que devem ser seguidos para se cons-
truir o projeto.
Familiarizamo-nos com dois modelos de processo de software: o “modelo
cascata” e o “modelo evolucionário”. Verificamos que o modelo cascata é indi-
cado quando conhecemos o domínio e o problema por completo, pois as fases
são bem definidas e pressupõem que o início de uma nova fase depende da con-
clusão da fase anterior. Já o modelo evolucionário é indicado quando temos que
aprender sobre o domínio e o problema no desenvolvimento da aplicação, o que
resulta em “N” versões intermediárias até chegarmos ao produto final.
Aprendemos que a adição do termo engenharia à análise de requisitos pres-
supõe que técnicas sistemáticas são utilizadas no processo de levantamento de
requisitos, garantindo que os requisitos serão consistentes, completos e relevantes.
Vimos que a engenharia de requisitos é de suma importância, pois é nessa
fase que especificamos o problema, compreendemos e definimos uma proposta
por meio de um modelo válido.
Por fim, aprendemos que o modelo de caso de uso é um diagrama utilizado
na análise de requisitos, com o objetivo de compreender o problema, delimitar
o sistema e definir as funcionalidades oferecidas ao usuário sem nos preocupar-
mos com a implementação.
Considerações Finais
1. Quais objetivos o analista deve ter no momento da análise? Explique cada um
deles.
2. O que é um domínio do problema e qual a importância de conhecê-lo?
3. Conceitue linguagem de modelagem, método e processo.
4. Quando devemos utilizar o modelo de processo cascata e o modelo de processo
evolucionário?
5. O que acontece em um projeto de software no qual a equipe de desenvolvimen-
to e o cliente não se entendem?
6. O que são requisitos de software e como podemos classificá-los?
Fundamentos do desenho orientado a objetos com UML

Meilir Page-Jones
Sinopse: Fundamentos do Desenho Orientado a Objeto com UML mostra, tanto a
programadores novatos quanto aos experientes, como aplicar os conceitos de desenhos a
UML, assim como as melhores práticas quanto ao desenvolvimento de OO para melhorar o seu
código e o seu índice de sucesso em projetos fundamentados em objetos.
Para aprofundar os conhecimentos sobre OO, leia o artigo intitulado “Em busca de um modelo
de referência para engenharia de requisitos em ambientes de desenvolvimento distribuído de
software”. Esse artigo visa apresentar um modelo de referência para engenharia de requisitos em
ambientes de desenvolvimento distribuído de software, reunindo resultados de pesquisa teórica
e prática.
O artigo encontra-se disponível em: <http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_
WER03/leandro_audy.pdf>. Acesso em: 29 jul. 2015.
Material Complementar
Qual é a função primordial de qualquer Sabendo onde os casos de uso podem nos
software desenvolvido? Parece simples a ajudar, vem a próxima pergunta: o que fazer
questão, mas respondo que é ter acessi- agora? No artigo citado, Silva classifica que
bilidade. Para que isso seja possível, hoje, são várias as utilidades e destaca quatro
já é obrigatório testá-lo adequadamente. procedimentos que podemos seguir:
Vamos conhecer uma forma sistêmica de
montar toda a linha de testes embasada • Selecione o caso de uso que será tes-
em casos de uso. tado, identifique o fluxo principal e os
fluxos alternativos e desenhe um dia-
Uma das primeiras perguntas que devem grama de atividades. Desse modo, vai
ser levantada para iniciar a montagem de conseguir visualizar mais facilmente
um plano de testes é: o que testar? Parece todos os cenários que o usuário pode
visível a resposta que é testar as funcio- utilizar.
nalidades que compõem o escopo do
software que está sendo desenvolvido. • Agora que já identificou os cenários,
Agora, você se pergunta: onde está des- você vai começar a escrever um caso
crito esse escopo? Normalmente, ele pode de teste para cada cenário, detalhando
estar na proposta do projeto, na especifi- todos os passos do cenário. Desse
cação funcional e, em muitos projetos, nos modo, o testador vai poder executar
casos de uso. as ações do ator e validar se a resposta
do sistema está de acordo com o que
Eduardo Ernandes da Silva, no artigo inti- foi especificado.
tulado “Como fazer um plano de testes”,
descreve os casos de uso como requisi- • Para iniciar os testes, vai ser necessária
tos, que identificam o valor que o cliente a criação de uma base de dados de cer-
espera obter da funcionalidade e represen- tificação, se ela ainda não existir (não
tam a forma como o sistema será utilizado. é prudente fazer os testes na base de
Além disso, permitem identificar todos os desenvolvimento e muito menos em
caminhos que o usuário pode percorrer produção), e identificar os dados de
para conseguir o que deseja e se podem entrada que serão utilizados nos testes.
ocorrer problemas. E, também, mostram ao
cliente o que esperar do software, ao desen- • É importante tabular o resultado dos
volvedor, o que codificar e, ao testador ou testes, como quantidade de acertos,
certificador, o que validar para garantir a defeitos e correções, e armazenar essa
qualidade dos entregáveis. informação em algum meio perma-
nente. Isso vai servir para avaliar a
Desse modo, podemos concluir que os casos qualidade de cada desenvolvedor da
de uso ajudam na certificação e validação sua equipe.
dos requisitos implementados, simplifi-
cando e sistematizando o processo de teste Dessa maneira, podemos concluir que usar
do software, permitindo um ganho de pro- o casos de uso como modelo para os tes-
dutividade e ajudando na garantia de que tes vai permitir uma visão mais apurada do
todo o escopo vai ser abrangido pelo teste. software e ter maior noção das necessida-
des dos clientes.
Fonte: adaptada de Silva (online).

Prof. Me. Déverson Rogério Rando
III
UNIDADE
DIAGRAMA DE CLASSES
■■ Entender a notação UML para o Diagrama de Classes.
■■ Entender o objetivo do Diagrama de Classes.
■■ Conhecer a Notação UML para a o Diagrama de Classes.
■■ Compreender as características dos Atributos, métodos e tipos de
dados.
■■ Entender como ocorre a multiplicidade entre as associações de
classes.
■■ Conhecer os tipos de associação entre classes (unária, binária,
associativa, agregação, generalização).
■■ Compreender o conceito de Herança múltipla.
Plano de Estudo
■■ Diagrama de Classes
■■ Notação para classes
■■ Atributos
■■ Métodos
■■ Multiplicidade
■■ Associação Unária
■■ Associação Binária
■■ Classe Associativa
■■ Agregação
■■ Generalização
■■ Herança Múltipla
77
INTRODUÇÃO
Caro(a) aluno(a), iniciamos a terceira unidade do livro Análise e Projeto Orientado

a Objetos relembrando e reforçando o conceito de classes visto na primeira uni-
dade. Relembrar conceitos é somente um aperitivo para desvendarmos os segredos
da modelagem de um diagrama de classes.
Motivados pela descoberta, aprenderemos a notação UML para o diagrama
de classes, além das convenções para os nomes das classes, atributos e métodos,
veremos as várias formas de notação para o diagrama de classes.
A classe tem a função de individualizar o objeto (qualquer coisa concreta ou

abstrata) por meio de suas características (atributos) e comportamentos (méto-
dos). Sendo assim, aprenderemos a sintaxe, ou seja, como construir a linha de
declaração para os atributos e métodos, além de conhecermos os tipos de dados
primitivos.
Veremos que existem várias formas de associação de classes e tais associa-
ções fazem surgir o conceito de multiplicidade. A multiplicidade é o resultado
da necessidade de associação entre as classes, a multiplicidade nos mostra a car-
dinalidade de uma associação.
Veremos as várias formas de associação entre classes, dentre elas, a asso-
ciação unária, binária, agregação regular e composição, generalização e classes
associativas.
Aprenderemos, também, que na herança múltipla uma subclasse é derivada
de mais de uma superclasse que evidencia somente uma parte do conceito repre-
sentado na subclasse.
Veremos que a herança múltipla é uma forma mais complexa de generaliza-
ção, haja vista que a herança simples restringe a hierarquia de classes a somente
uma árvore.
Porém, mesmo mais complexa, a herança múltipla tem a vantagem de ofe-
recer maior capacidade de especificação de classes e a maior oportunidade de
reutilização. A desvantagem é justamente, como já citamos, a perda em simpli-
cidade conceitual e implementação.
Então, o que estamos esperando? Vamos ao trabalho!
Introdução
III
DIAGRAMA DE CLASSES
Como já vimos, após a elaboração do diagrama de caso de uso, podemos mode-

lar a primeira versão do Diagrama de Classes. O diagrama de classes mostra a
estrutura estática do sistema.
A classe representa a ABSTRAÇÃO de um conjunto de OBJETOS do mundo
real que possui tipos, características e comportamento comuns. A Abstração
ocorre quando definimos um objeto conceitual a partir de OBJETOS do mundo
real que possuam as mesmas características e comportamento, podendo ser clas-
sificados como pertencentes a um mesmo tipo.
Objeto é qualquer coisa concreta ou abstrata com existência perceptível no
mundo real que possa ser individualizado por possuir características e compor-
tamento próprio.
Na figura 39, temos o exemplo de objetos de mundo real que, na verdade, são
funcionários que têm características em comum, por exemplo: todos os funcio-
nários possuem nome, endereço e telefone, dessa forma, podemos abstrair para
criar um objeto conceitual a partir dos objetos do mundo real.
Figura 39: Objetos do mundo real
Uma classe é uma estrutura que modela um conjunto de objetos cujas característi-
cas sejam similares. A classe, por meio dos métodos, modela o comportamento de
seus objetos, e os possíveis estados do objeto, são modelados mediante atributos.
As classes juntamente com os atributos, operações e associações são definidas
DIAGRAMA DE CLASSES
79
em um diagrama de classe. Porém não existe uma receita ou um método para a

escolha das classes do sistema. Essa tarefa depende fundamentalmente da expe-
riência do desenvolvedor.
No início do projeto, as classes são denominadas de “candidatas” ou de
“análise”, pois existe uma probabilidade muito grande de que mudem ao longo
do projeto. Antes de aprendermos como fazer, apresento a notação para classes.
NOTAÇÃO PARA CLASSES
Uma classe é representada por um retângulo e pode ser apresentada somente

com o seu estereótipo (nome da classe).
Por convenção, todo nome de classe deve começar com uma letra maiúscula
e, de preferência, não pode conter letras não ASCII (caracteres de língua de ori-
gem latina, como caracteres acentuados). Portanto, não é possível declarar uma
classe com qualquer caracter especial (@, #, $, %, &, *, _, etc...).
Caso o nome de uma classe seja composto por mais de uma palavra, a pri-
meira letra de cada palavra deve ser em maiúscula.
Aluno
Figura 40: Notação simplificada de um classe

Fonte: o autor.
A classe também pode ser apresentada como um retângulo com dois compar-
timentos, em que o primeiro contém o nome da classe e o segundo contém os
atributos juntamente com seu tipo de dados.
Aluno
- Nome: String
- Endereço: String
- Data_nasc: Date
Figura 41: Notação com nome da classe e atributos

Fonte: o autor.
Notação Para Classes
III
Por fim, a classe também pode ser apresentada em um retângulo dividido em

três compartimentos, como ilustra a figura 42.
Aluno Nome da Classe

(Estereótipo)
- Nome: String
- Endereço: String Atributos
- Data_Nasc: Date
- Criar( ): void Métodos
- Eliminar( ): void (Operação)
Figura 42: Notação com nome, atributos e métodos
Fonte: o autor.
Uma classe abstrata não gera objetos, porque geralmente ela tem, no míni-
mo, uma operação abstrata nela definida. Se ela na verdade criasse um ob-
jeto, uma mensagem invocando a operação abstrata do objeto provocaria
um erro de rum-time.
Fontes: Page-Jones (2001)

DIAGRAMA DE CLASSES
81
ATRIBUTOS
O dicionário Aurélio explica que atributo é aquilo que é próprio de alguém ou

de algo, resumindo, atributo é uma característica.
Dessa forma, os atributos são os elementos que definem a estrutura de uma
classe, também são denominados de variáveis de classe. O atributo é um ele-
mento da classe que pode representar uma característica dos objetos instanciados.
A sintaxe (assinatura) para declaração de um atributo em UML tem o seguinte
formato:
[<visibilidade>]<nome>:[<tipo>][=<valor inicial>]
Vamos entender cada um dos elementos da sintaxe. Gostaria de abrir um parên-

tese para explicar que sintaxe corresponde a um conjunto de regras que diz como
a instrução deve ser escrita, a ordem com que os elementos devem aparecer.
<visibilidade>
A visibilidade nos informa quais são as classes que podem ver esse atributo,
temos as seguintes opções:
Notação Nome Significado

+ Público Todas as classes têm acesso.
- Privado Somente métodos definidos na classe podem vê-lo.
# Protegido Métodos definidos na classe e nas classes derivadas
podem vê-lo.
~ Pacote Visível dentro das classes do pacote.
<nome>
■■ O nome do atributo deve obedecer algumas regras também, tais como:
■■ O nome pode começar com qualquer letra e os caracteres $ ou _.
■■ Não conter caracteres exclusivos da língua portuguesa (acentos, cedi-
lhas etc.).
Atributos
III
■■ Não começar por números.

■■ Caso o nome de um atributo seja composto por mais de uma palavra, a
primeira letra de cada palavra deve ser em maiúscula.
<tipo>
Pode-se utilizar os tipos da linguagem de programação de implementação.
Vamos listar alguns tipos primitivos, por primitivo entendemos aqueles tipos
de dados mais usuais e básicos. Por exemplo:
■■ Boolean: admite os valores true ou false.
■■ Char: usa o código UNICODE e ocupa cada caractere 16 bits.
■■ Inteiros: diferem nas precisões e podem ser positivos ou negativos:
• Byte: 1 byte.
• Short: 2 bytes.
• Int: 4 bytes.
• Long: 8 bytes.
Reais em ponto flutuante: igual aos inteiros, também diferem nas precisões e
podem ser positivos ou negativos:
• Float: 4 bytes.
• Double: 8 bytes.
<valor inicial>
Valor inicial para o atributo que respeite o tipo de dado, ou seja, se o tipo de
dado for um inteiro, não poderei informar uma data como valor inicial.
No figura 43, podemos observar que o atributo nome tem visibilidade pri-
vada, ou seja, somente os métodos dessa classe poderão realizar operações com
esse atributo. O atributo sexo é protegido, podendo ser visto somente nessa
classe ou em classes derivadas, observe que esse atributo é iniciado com o valor
‘F’, que implica dizer que sempre que um objeto for instanciado receberá o valor
‘F’. Por fim, o atributo código tem a visibilidade pública, que significa dizer que
esse atributo está visível para todas as classes.
DIAGRAMA DE CLASSES
83
Classe
- Nome: String
# Sexo: char = ‘F’
- Codigo: int = 20
Figura 43: Classe com os compartimentos de nome e atributos

Fonte: o autor.
MÉTODOS
De maneira geral, um método é uma maneira de ordenar a ação de acordo com

certos princípios, ou seja, é a maneira ou forma de proceder que determina um
comportamento.
Sendo assim, os métodos determinam o comportamento dos objetos de
uma classe e são semelhantes às funções ou procedimentos da programação
estruturada.
Os métodos possuem uma propriedade especial que, quando em tempo de
execução, possuem acesso aos dados armazenados em um objeto e são, dessa
forma, capazes de controlar o estado do objeto.
[<visibilidade>]<nome>(<lista argumentos>):[<retorno>]
A sintaxe para declaração de um método é semelhante à declaração de atribu-

tos, vamos lá:
<visibilidade>:
Notação Nome Significado

+ Público Todas as classes têm acesso.
- Privado Somente métodos definidos na classe podem vê-lo.
# Protegido Métodos definidos na classe e nas classes derivadas
podem vê-lo.
~ Pacote Visível dentro das classes de um pacote.
Métodos
III
<nome>:
O nome do método segue as mesmas regras para o nome dos atributos e
da classe.
<lista de argumentos>
Argumentos são os meios que utilizaremos para passar dados para o método
e esses métodos irão trabalhar, especificamente, em cima dessas informações.
Por exemplo:
Classe
- Nome: String
# Data_Nasce: Date
- Codigo: int = 20
- calcularIdadeEmMeses(data : Date) : int
Argumento
Figura 44: Lista de Argumentos do método
Fonte: o autor.
<retorno>
Tipo do dado retornado pelo argumento. Pode-se utilizar os tipos da lin-
guagem de implementação:
■■ Boolean: não é um valor numérico, só admite os valores true ou false.
■■ Char: usa o código UNICODE e ocupa cada caractere 16 bits.
■■ Inteiros: diferem nas precisões e podem ser positivos ou negativos:
• Byte: 1 byte.
• Short: 2 bytes.
• Int: 4 bytes.
• Long: 8 bytes.
■■ Reais em ponto flutuante: da mesmas forma que o tipo de dados de intei-

ros, os tipo de dados Reais também diferem nas precisões e podem ser
positivos ou negativos:
• Float: 4 bytes.
• Double: 8 bytes.
DIAGRAMA DE CLASSES
85
No diagrama a seguir, podemos observar que, para o método calcularIdadeEm-

Meses funcionar, deverá ser passada a data de nascimento e, após o cálculo para
transformar em meses, o método retornará um valor inteiro correspondente a
quantidade de meses de vida.
Classe
- Nome: String
# Data_Nasce: Date
- Codigo: int = 20
- calcularIdadeEmMeses(data : Date) : int
Retorno
Figura 45: Retorno do método
Fonte: o autor.
MULTIPLICIDADE
Associação é uma relação entre duas classes significando que os objetos des-
tas classes possuem uma ligação. Um conceito importante para as associações
entre as classes é a multiplicidade que mostra a cardinalidade de uma associação.
A multiplicidade especifica quantas instâncias de uma classe relacionam-se
a uma única instância de uma classe associada. A tabela a seguir mostra a repre-
sentação da notação e seu significado.
Representação Significado
1 Exatamente um.
0..* Zero ou mais.
* Zero ou mais.
1..* Um ou mais.
0..1 Zero ou um.
5..8 Intervalo específico (5, 6, 7 ou 8).
4..7,9 Combinação (4,5,6,7 ou 9).
Vamos exemplificar: o diagrama de classes da figura 46 nos mostra o relacionamento
Multiplicidade
III
entre as classes Aluno e Disciplina, para definir a multiplicidade do relaciona-

mento, fazemos as seguintes perguntas:
■■ Realizando a leitura do diagrama da esquerda para a direita:
• Um aluno pode cursar quantas disciplinas?
■■ A sua resposta será a multiplicidade que deverá ser informada ao

lado da classe disciplina.
■■ Realizando a leitura do diagrama da direita para esquerda:
• Uma disciplina pode ser cursada por quantos alunos?
■■ A sua resposta será a multiplicidade que deverá ser informada ao
lado da classe aluno.
Dessa forma, podemos fazer a seguinte leitura para o diagrama de classes abaixo:
■■ Da esquerda para a direita:
• Um Aluno pode cursar somente uma disciplina.
■■ Da direita para esquerda:

• Uma Disciplina pode ser cursada somente por um aluno.
Aluno Disciplina
1 Cursa 1
Figura 46: Multiplicidade um para um
Fonte: o autor.
Vamos exercitar um pouco: a figura 47 nos mostra as classes aluno e disciplina

sem a multiplicidade.
Aluno Disciplina
Figura 47: Sem declaração de multiplicidade

Fonte: o autor.
Vamos definir uma ação entre as classes para definir a multiplicidade, pensei
na palavra “cursa”, uma vez que o aluno cursa a disciplina, ficará como apresen-
tado na figura 48:
DIAGRAMA DE CLASSES
87
Aluno Disciplina
Cursa
Figura 48: Identificação da associação
Fonte: o autor.
O próximo passo é fazer aquela perguntinha da esquerda para a direita:

■■ Um aluno cursa quantas disciplinas?
• Nossa resposta, agora, será, no mínimo, uma e, no máximo, várias
disciplinas.
Nosso diagrama de classes ficará como na figura 49:
Aluno Disciplina
Cursa 1..*
Figura 49: Multiplicidade um ou muitos
Fonte: o autor.
Por fim, o próximo passo é fazer aquela perguntinha da direita para esquerda:
■■ Uma disciplina pode ser cursada por quantos alunos?
• Nossa resposta, agora, será várias disciplinas.
Nosso diagrama de classes ficará como na figura 50:
Figura 50: Multiplicidade um ou muitos para muitos

Fonte: o autor.
Perfeito, agora nosso diagrama está completo, fácil, não é!? Vamos testar
outras cardinalidades, supondo que um aluno pode cursar somente uma dis-
ciplina, mas a disciplina pode ser cursada por, no mínimo, um e, no máximo,
muitos alunos, nosso diagrama ficará como na figura 51:
Aluno Disciplina
* Cursa 1..*
Figura 51: Multiplicidade somente um para um ou muitos
Fonte: o autor.
Multiplicidade
III
ASSOCIAÇÃO UNÁRIA
Vimos que a multiplicidade entre as associações de classes nos informa quantas

instâncias de objetos da classe A se associam a quantas instâncias de objetos da
classe B, porém as classes podem se associar de várias formas.
O diagrama da figura 52 nos mostra uma associação unária, em que, de
acordo com Medeiros (2004), a classe se associa com ela mesma, ou seja, uma
autoassociação. Interpretando o diagrama, verificamos que um funcionário
pode ser “chefe” ou “trabalhador”, que o chefe pode ter vários trabalhadores sob
suas ordens e um trabalhador pode ter nenhum chefe e, no máximo, um. Mas
quando o trabalhador não terá nenhum chefe? Resposta: quando ele for o chefe.
Funcionário
chefe - Nome: String
0..1 - Endereço: String
* trabalhador
Gerência
Figura 52: Associação Unária
Fonte: o autor.

DIAGRAMA DE CLASSES
89
ASSOCIAÇÃO BINÁRIA
As associações binárias são as mais comuns, elas acontecem entre duas classes.
Fazendo a leitura do diagrama da figura 53 podemos verificar que uma instância
de objeto da classe cliente está associada com várias instâncias da classe compra,
porém cada instância de objeto da classe compra está associada a somente um
cliente, resumindo, um cliente pode realizar muitas compras, mas cada compra
pode ser somente de um cliente (MEDEIROS, 2004).
Cliente Compra
1 Fazer *
Figura 53: Associação binária
Fonte: o autor.
ASSOCIAÇÃO TERNÁRIA
A associação ternária associa três classes. A notação para essa associação é

um losango (diamante) e ainda suporta uma associação de classe ligada a ela
(MEDEIROS, 2004).
O diagrama da figura 54 mostra que um cliente pode não ter nenhum contrato
ou vários e um contrato pode ser de um cliente ou de vários, porém a associação
entre as classes cliente e contrato associa, também, a classe regras do contrato,
que, nesse caso, pode ter uma ou várias regras para aquele contrato específico.
Contrato Cliente
0..” 1..”
1..”
Regras do
Contrato
Figura 54: Associação Ternária

Fonte: o autor.
Associação Binária
III
CLASSE ASSOCIATIVA
De acordo com Summerville (2011), quando uma associação possuir atributos

próprios, pode-se criar uma classe associativa. Essas classes são úteis quando
queremos armazenar o histórico de uma associação (relacionamentos que ocor-
rem e interessam ser salvos).
Vamos enumerar algumas características das classes associativas:
■■ São comuns em associações de multiplicidade *:* (muitos para muitos),
embora não seja uma regra.
■■ A linha que representa a associação não é nomeada, o nome da classe
associativa deve ser suficiente para identificar a associação.
■■ Classes associativas podem estar relacionadas a outras classes.
No modelo da figura 55, podemos observar que a multiplicidade em ambos

os lados da associação é “*” (várias), o que implica dizer que, em uma venda,
podem ser vendidos vários produtos e um produto pode ser vendido em várias
vendas. Como resultado dessa associação, temos uma classe associativa, que per-
mite que armazene cada um dos itens de produto juntamente com a quantidade
e valor total, e uma classe separada.
Produto Venda
* *
Ítens da Venda
Ítens da Venda
Figura 55: Classe associativa

Fonte: o autor.
DIAGRAMA DE CLASSES
91
AGREGAÇÃO
Lee & Tepfenhart (2002) explicam que a agregação é um caso especial de asso-
ciação utilizado para representar relacionamentos de pertinência “parte-todo”
ou “uma parte de”. Permite representar o fato de que um objeto ou mais objetos
de uma classe fazem parte de um objeto de outra classe.
Um exemplo típico é uma janela de interface com o usuário composta por
diversos botões, caixas de textos, barra de rolagem, entre outros. A agregação
representa uma ligação entre o objeto todo (a janela) e as partes (botão, caixas
de textos, barra de rolagem). Um comportamento que se aplica ao todo se pro-

paga às partes, por exemplo, ao movimentar a janela, todos seus elementos de
deslocam também.
A agregação pode ser regular ou de composição, vamos ver a diferença entre
elas.
AGREGAÇÃO REGULAR
De acordo com Lee & Tepfenhart (2002), a agregação regular é representada

por um losango vazado, o diagrama da figura 56 nos diz que a classe B é “uma
parte” da classe A, porém as instâncias de objetos da classe B existem sem um
objeto associado na classe A.
A B
B existe sem A
Figura 56: Agregação Regular

Fonte: o autor.
No exemplo da figura 57, verificamos que em um quadro pode ter uma ou várias
figuras, ou seja, a figura é uma parte do quadro, porém a figura existe mesmo
que não exista um quadro para ela.
Agregação
III
Quadro Figura
1..”
O objeto figura existe sem o

objeto quadro

Fonte: o autor.
Para ficar ainda mais claro, vamos utilizar o exemplo da figura 58, que nos mos-
tra que monitor, teclado, mouse e drive são partes de CPU, porém cada uma das
instâncias desses objetos existe sem uma instância de CPU associada. Nesse caso,
podemos afirmar que a destruição do objeto CPU não implicará na destruição
dos demais objetos associados.
CPU
1 1 1 0..”
Monitor Teclado Mouse Drive

Fonte: o autor.
AGREGAÇÃO DE COMPOSIÇÃO
Lee & Tepfenhart (2002) explicam que a agregação de composição é uma agre-
gação de fato, em que o todo é composto pelas partes. Existe uma relação forte
entre o todo e as partes, pois, quando o todo é destruído, as partes também serão,
ou seja, a eliminação do todo se propaga para as partes. De outra forma, o todo
e as partes têm tempos de vida semelhantes.
Como podemos verificar na figura 59, a agregação de composição é repre-
sentada por um losango preenchido, o diagrama abaixo nos diz que a classe B
é “parte-todo” da classe A, dessa forma, as instâncias de objetos da classe B não
existem sem um objeto associado na classe A. A destruição da instância de objeto
de A implica na destruição da instância de objeto associado da classe B.
DIAGRAMA DE CLASSES
93
A B
B não existe sem A
Figura 59: Agregação de Composição

Fonte: o autor.
Na figura 60, podemos verificar que um orçamento pode ter muitos itens de orça-
mento, porém os itens de orçamento não existirão sem o orçamento.
Orçamento Ítens Orçamento

*
Figura 60: Agregação de composição
Fonte: o autor.
Na figura 61, o diagrama nos diz que um documento é composto de nenhum

ou muitos parágrafos e um parágrafo é composto por uma ou muitas sentenças,
as sentenças não existem sem o parágrafo e o parágrafo não existe sem o docu-
mento. A destruição de uma instância de objeto da classe documento implica na
destruição das instâncias de objetos das outras duas classes agregadas.
Documento Parágrafo Sentença

“ 1...”
Figura 61: Agregação de composição

Fonte: o autor.
A decisão de utilizar a agregação é uma questão de julgamento, nem sempre é

evidente que uma associação deve ser modelada como agregação.
Agregação
III
GENERALIZAÇÃO
Vamos ver, agora, outro tipo de associação de classes, denominado generalização.

Uma generalização é uma associação hierárquica que indica um relacionamento
entre a classe de mais alto nível, denominada superclasse, e outra de mais baixo
nível, denominada subclasse, ou, ainda, classe mãe e filha, respectivamente.
Em outras palavras, a generalização é um relacionamento entre um elemento
geral e um outro mais específico. O elemento mais específico possui todas as carac-
terísticas do elemento geral e contém, ainda, mais particularidades. Um objeto
mais específico pode ser usado como uma instância do elemento mais geral.
Existem alguns tipos de generalizações que variam em sua utilização a partir
da situação. São eles: generalização normal e restrita. As generalizações restritas
se dividem em generalização de sobreposição, exclusiva, total e parcial. A gene-
ralização recebeu muitos nomes, podendo ser denominada especialização ou,
ainda, herança.
A diferença entre a generalização e as demais associações é que, na gene-
ralização, é enfatizado o conceito de herança que tem como característica a
reutilização de atributos e métodos definidos nas classes mais gerais (super-
classe) por classes mais específicas (subclasses). Ou seja, permite a criação de
elementos especializados em outros. Por sua vez, as subclasses, que represen-
tam as classes mais especializadas, herdam atributos, métodos e associações da
superclasse, que representa a classe mais genérica. A notação para a generaliza-
ção é uma seta em branco apontando sempre para a superclasse.
A figura 62 modela uma generalização para pessoa. Uma pessoa pode ser
física ou jurídica, porém o que diferencia os tipos de pessoas é um atributo espe-
cífico que identifica e pessoa física (CPF) e a pessoa jurídica (CNPJ), ambas têm
os atributos nome e endereço que serão herdados da superclasse (pessoa), além
dos métodos Criar() e Eliminar().
DIAGRAMA DE CLASSES
95
Pessoa
- Nome: String
- Endereço: String
- Criar( ): void
- Eliminar( ): void
Jurídica Física
- CNPJ: String - CPF: String
Figura 62: Generalização

Fonte: o autor.
COBERTURA TOTAL
A generalização apresenta um conceito importante que é a cobertura. A nota-

ção para a cobertura é uma linha tracejada com o tipo de cobertura entre chaves.
Dizemos que a cobertura é total ou completa, se cada elemento da classe
genérica é mapeado para, pelo menos, um elemento das classes especializadas.
Na figura 63, verificamos que a cobertura da generalização é total, o que sig-
nifica dizer que uma pessoa, obrigatoriamente, tem que ser homem ou mulher.
Pessoa
{Total}
Homem Mulher
Figura 63: Generalização com cobertura total

Fonte: o autor.
Generalização
III
EXCLUSIVA
A cobertura de uma generalização é exclusiva, se cada elemento da classe gené-

rica é mapeado para, no máximo, um elemento das subclasses.
Na figura 64, refinei o diagrama do exemplo anterior, juntando as cobertu-
ras total e exclusiva, dessa forma, temos que uma pessoa será, obrigatoriamente,
um homem ou uma mulher, não podendo ser os dois.
Pessoa
{Total, Exclusiva}
Homem Mulher
Figura 64: Generalização com cobertura total e exclusiva

Fonte: o autor.
PARCIAL
A cobertura é parcial ou incompleta se existe algum elemento da classe genérica

que não é mapeado para nenhum elemento das subclasses.
A figura 65 nos mostra que um veículo pode ser um carro ou uma bicicleta,
podendo não ser nenhum dos dois, percebam que, nesse tipo de cobertura, não
sou obrigado a especializar o veículo, diferente da cobertura total que, obriga-
toriamente, devo mapear para, pelo menos, uma subclasse.
DIAGRAMA DE CLASSES
97
Veículo
{Parcial}
Carro Bicicleta
Figura 65: Generalização com cobertura parcial

Fonte: o autor.
SOBREPOSIÇÃO
A cobertura de uma generalização é de sobreposição, se existe algum elemento

da classe genérica que é mapeado para elementos de duas ou mais subclasses
diferentes.
Na figura 66, podemos verificar que uma pessoa pode ser aluno ou profes-
sor, podendo ser os dois.
Pessoa
{Sobreposição}
Aluno Professor
Figura 66: Generalização com cobertura de sobreposição

Fonte: o autor.
Generalização
III
As coberturas podem ser combinadas da seguinte forma:

■■ Total, Exclusiva: nessa combinação de cobertura, uma classe genérica
deve ser mapeada para uma única subclasse.
■■ Total, Sobreposição: nessa combinação de cobertura, uma classe genérica
deve ser mapeada para uma ou várias subclasses.
■■ Parcial, Exclusiva: nessa combinação de cobertura, uma classe genérica
pode ser mapeada para uma única subclasse ou para nenhuma.
■■ Parcial, Sobreposição: nessa combinação de cobertura, uma classe gené-
rica pode ser mapeada para uma ou mais subclasses ou para nenhuma.
HERANÇA MÚLTIPLA
Na herança múltipla, uma classe (subclasse) é derivada de mais de uma classe

base (superclasse). Porém ocorre uma perda conceitual, uma vez que uma super-
classe não representa um caso geral completo da subclasse. Ou seja, a superclasse
representa uma parte do conceito representado na subclasse.
Na figura 67, Curso não é uma generalização completa de Extensão, pois
não leva em conta aspectos de Extensão ligados a Eventos. Dessa forma, a sub-
classe Extensão herdará atributos e métodos das superclasses Curso e Evento.
Curso
Evento
Graduação Pós-graduação Extensão
Figura 67: Herança múltipla

Fonte: o autor.
DIAGRAMA DE CLASSES
99
A herança múltipla permite a concatenação (mesclagem) de informações de duas

ou mais origens. Essa é uma forma um pouco mais complexa de generalização
do que a herança simples, que restringe a hierarquia de classes a uma árvore.
A vantagem da herança múltipla é a maior capacidade de especificação de
classes e a maior oportunidade de reutilização. Ela traz a modelagem de obje-
tos para mais próxima da maneira como se costuma pensar. A desvantagem é a
perda em simplicidade conceitual e de implementação.
Herança múltipla dá-se quando uma subclasse herda atributos e operações

de duas ou mais superclasses. Esse tipo de situação deve ser evitado. Apesar
de a orientação a objetos prever essa situação, ela introduz possibilidades
de difícil solução.
Fonte: Medeiros (2004, p. 80).
Nesta unidade, aprendemos que o diagrama de classes mostra a estrutura estática

do domínio das abstrações (classes) do sistema. Ele descreve os tipos de obje-
tos no sistema e os vários tipos de relacionamentos estáticos que existem entre
eles. Mostra os atributos e operações de uma classe e checa a maneira com que
os objetos colaboram entre si.
Vimos que essa ferramenta de modelagem produz o diagrama mais impor-
tante do sistema, pois é usada para modelar um entendimento do domínio da
aplicação (essencialmente parte do sistema de atividades humanas), e os obje-
tos também são entendidos como partes do sistema resultante.
Conhecemos a notação UML para o Diagrama de Classes em suas diversas
apresentações, além de compreendermos que o objetivo do diagrama de classes
é mostrar a estrutura estática do sistema, modelado a partir do levantamento de
requisitos representado no diagrama de caso de uso.
III
Familiarizamo-nos com o conceito e a sintaxe dos atributos e aprendemos

que são esses elementos que definem a estrutura de uma classe, representando
uma característica dos objetos instanciados.
Aprendemos que são os métodos que determinam o comportamento dos
objetos de uma classe e são semelhantes às funções ou procedimentos da pro-
gramação estruturada.
Entendemos como ocorre a multiplicidade entre as associações de classes e
que a multiplicidade especifica quantas instâncias de uma classe relacionam-se
a uma única instância de uma classe associada.
Conhecemos os vários tipos de associação entre classes, entre elas, a asso-
ciação unária e binária, classes associativas, agregação regular e de composição,
generalização e especialização.
Compreendemos que Herança múltipla permite que uma classe possua mais
de uma superclasse e herde características de todos os seus ancestrais.
Na próxima unidade, conheceremos os diagramas de sequência, comuni-
cação e estado. Esses diagramas permitirão que tenhamos uma nova visão do
domínio de problema que resulta, na maioria das vezes, na alteração do dia-
grama de classes.

DIAGRAMA DE CLASSES
101
1. Uma classe é o mesmo que um objeto? Explique.

2. O que é a herança?
3. O que é a herança múltipla e quais seus perigos?
4. Qual a diferença entre as visibilidades ‘pública’ e ‘protegida’?
5. Quando devemos utilizar a agregação de composição e a agregação regular?
6. O que é uma classe associativa?
Engenharia de Software
Ian Sommerville
Sinopse: A engenharia de software é uma área relativamente
nova, mas adquiriu rapidamente uma posição central entre as
diferentes vertentes da engenharia. Englobando todos os aspectos
da produção de software, ela é multidisciplinar e está em constante
mudança.
Para aprofundar os conhecimentos sobre OO, leia o artigo intitulado “AspectJ—Programação

orientada a aspectos em Java”. Esse artigo apresenta um tutorial sobre AspectJ, uma extensão
orientada a aspectos de Java. Programação orientada a aspectos (AOP) procura solucionar
algumas ineficiências da orientação a objetos, como o entrelaçamento e espalhamento de
código com diferentes propósitos. O artigo encontra-se disponível em: <http://andremoraes-tcc.
googlecode.com/svn-history/r21/trunk/tcc/referencias/Soares_Borba_AspectJ.pdf>. Acesso em:
29 jul. 2015.
103
Prezado(a) aluno(a), segue uma matéria A modelagem de banco de dados orien-

muito interessante que faz a demonstração tados a objeto surgiu das limitações dos
de uma modelagem de dados orientada bancos de dados relacionais, seu obje-
a objetos com agentes inteligentes, para tivo básico é o gerenciamento de grandes
o desenvolvimento e análise da informa- volumes de informação, possuindo maior
ção de acordo com as necessidades dos facilidade no tratamento de dados e aten-
usuários. dendo aos requisitos atuais de sistemas
com outros tipos de bancos de dados,
SISTEMA DE INFORMAÇÃO ORIENTADO A como o hipertexto, tão amplamente utili-
OBJETOS COM AGENTES INTELIGENTES zado (SILBERSCHATZ; KORTH; SUDARSHAN,
1999, p.249).
Marcelo Botelho da Costa Moraes; Marcelo
Seido Nagano Dentro desta característica a linguagem
UML (Unified Modeling Language) pode
O modelo apresentado é baseado na apli- ser aplicada, principalmente por ser uma
cação da tecnologia de agentes inteligentes ferramenta apropriada para modelagem
aos sistemas de informação contábeis, de agentes inteligentes (HEINZE, 2004, p.
buscando aperfeiçoar a maneira como os 41) e baseada em bancos de dados orien-
sistemas disponibilizam a informação aos tados a objetos. Esta abordagem se difere
usuários, proporcionando variações de for- dos sistemas de informação contábeis tradi-
matação e detalhamento da informação. cionais por separar os dados das operações
de modelagem da informação ao mesmo
Mesmo sendo o modelo REA o mais aceito tempo em que utiliza uma abordagem
para estruturar os fenômenos contábeis, orientada a objetos.
este é eficiente no armazenamento dos
dados, mas não no tratamento da infor- Visando um melhor desempenho da
mação (VERDAASDONK, 2003, p. 45). Dessa modelagem proposta, a forma de desenvol-
maneira, se torna necessário o desenvolvimento por UML é utilizada para facilitar
vimento de um sistema destinado ao a visualização e a integração entre os dife-
tratamento dos dados, gerando informação rentes objetivos.
relevante, confiável e comparável, caracte-
rísticas estas que determinam a utilidade Nos sistemas tradicionais os relatórios são
da informação contábil (FASB, 1980, p.7). desenvolvidos no próprio banco de dados,
enquanto neste modelo REA orientado a
O desenvolvimento deste modelo é feito objetos (REAOO) os relatórios e suas análi-
através da linguagem de banco de dados ses são desenvolvidos através de agentes
orientado a objetos. A utilização de mode- inteligentes, baseados em sistemas espe-
lagem orientada a objetos foi introduzida cialistas. A grande diferença se dá na
no desenvolvimento de sistemas de infor- separação da aplicação de contabilidade
mação contábeis por Knaus (2001), mas sua do banco de dados, o que não ocorre nor-
proposta utiliza como base o modelo DCA, malmente.
sendo cada conta contábil como classe dis-
tinta (KNAUS, 2001, p. 78).
Assim, para tal desenvolvimento, a utiliza- Com isso, as entidades utilizadas no modelo
ção da linguagem UML para a modelagem REA podem ser consideradas como clas-
do sistema é de grande auxílio, é impor- ses. Na modelagem orientada a objetos
tante ressaltar que o modelo é uma para banco de dados, uma classe pode pos-
simplificação da realidade, apresentando suir hierarquia de especialização, ou seja, o
um caso geral de um sistema de informação relacionamento ISA, que indica uma classe
para qualquer atividade que se deseje assu- como sendo especialização de outra (SIL-
mir. Desse modo, enquanto a modelagem BERSCHATZ; KORTH; SUDARSHAN, 1999,
E-R no modelo REA assume 3 entidades p. 253).
(Recursos, Eventos e Agentes), para o
desenvolvimento da modelagem orientada Assim, como na generalização do modelo
a objetos estes recursos, eventos e agen- REA, é possível determinar uma especiali-
tes são as classes a serem implementadas. zação para as classes de Recursos, Eventos
e Agentes, conforme exemplo.
Assim, com a utilização de Agentes Inte-
ligentes para o desenvolvimento da A partir da determinação das classes e
informação para os diferentes tipos de usu- suas especializações é possível compor o
ário, o esquema externo (conforme modelo modelo geral do diagrama de classes den-
REA) pode ser desenvolvido por meio de tro da proposta apresentada no modelo
Agentes Inteligentes, onde este agente será REA.
um novo ator neste diagrama.
No modelo REA orientado a objetos
Enquanto os agentes externos podem (REAOO), um agente econômico, que pode
tomar parte nos eventos de transação ser interno ou externo, realiza um ou mais
como clientes e fornecedores, os agentes eventos econômicos e o próprio evento
internos atuam na transação, são responsá- econômico gerado ocasiona a dualidade
veis pela intra-ação e alocação de recursos. em relação aos recursos, proporcionando
Além disso, com a inserção de agentes inte- consumo (custo) e geração (benefício) de
ligentes no desenvolvimento e análises de um ou mais recursos simultaneamente.
relatórios.
No caso geral da comercialização de um
Normalmente, existem muitos objetos simi- produto fabricado na própria entidade, um
lares em um banco de dados, ou seja, eles cliente (agente econômico externo) pode
respondem às mesmas mensagens, usam adquirir um ou mais produtos com um
os mesmos métodos e têm variáveis de vendedor (agente econômico interno), oca-
mesmo nome e tipo. Dessa forma, o agru- sionando um evento econômico (venda)
pamento desses objetos similares se dá por que terá impacto nos recursos econômi-
meio das classes (SILBERSCHATZ; KORTH; cos, seja sob a forma de custo de uma ou
SUDARSHAN, 1999, p. 252). mais unidades, seja na forma de benefício
com o recebimento financeiro ou direito
de recebimento futuro.
105
Este modelo, assim como o formato ori- A atuação do agente inteligente se dá de

ginal do modelo REA, pode ser aplicado maneira autônoma, ou seja, o agente inte-
a qualquer situação dentro dos diversos ligente é um software separado do banco
tipos de organizações que realizem ativi- de dados, que o acessa remotamente e, atu-
dades econômicas. ando por meio de buscas, obtém os dados
desejados que sejam necessários para sua
atividade de desenvolvimento e/ou aná-
lise da informação.
Confira o texto completo disponível em: <http://www.scielo.br/scielo.php?script=sci_art-
text&pid=S1807-17752009000300005&lng=pt&nrm=iso>.
Fonte: Moraes e Nagano (2009, online).

IV
DIAGRAMAS DE
UNIDADE
SEQUÊNCIA, ESTADO E
COLABORAÇÃO
■■ Avançar no conhecimento de diagramas UML.
■■ Aprender sobre o Diagrama de Sequência.
■■ Aprender sobre o Diagrama de Estados.
■■ Aprender sobre o Diagrama de Comunicação.
Plano de Estudo
■■ Avançando nos diagramas
■■ Diagrama de Sequência
■■ Diagrama de Estados
■■ Diagrama de Comunicação
109
INTRODUÇÃO
Caro(a) aluno(a), iniciamos a quarta unidade do livro Análise e Projeto Orientado

a Objetos mostrando mais alguns diagramas importantíssimos que complemen-
tam e refinam o diagrama de casos de uso e de classes.
Aprenderemos a notação e como utilizar o diagrama de sequência, veremos
que a utilidade desse diagrama é a de se estudar as interações entre os objetos.
O diagrama de sequência tem o propósito de refinar o diagrama de classes, uma
vez que possibilita a identificação de relação entre as classes.
Conheceremos com detalhes o diagrama de estado, esse diagrama tem como

objetivo especificar o comportamento das classes por meio da utilização de
máquinas de estado. Veremos que as classes com necessidade da representação
por esse diagrama são somente as que possuem um número quantificável de
estados, portanto, não são todas as classes que terão a necessidade de ter o com-
portamento modelado por esse diagrama.
Por fim, aprenderemos o diagrama de comunicação, conhecido também
como diagrama de colaboração (UML 1.5). Veremos que esse diagrama nos dá
outra forma de representar o cenário. Aprenderemos que, apesar de conter as
mesmas informações que o diagrama de sequência, o diagrama de comunica-
ção representa a ordem com que ocorre a comunicação, e não o tempo, como
ocorre no diagrama de sequência.
Dessa forma, será possível perceber que a colaboração entre as classes ocorre
por meio das trocas de mensagem. Quando desejarmos verificar essa troca, consi-
derando o tempo com que elas acontecem, utilizaremos o diagrama de sequência,
porém, se o objetivo é verificar essas trocas de mensagens de acordo com sua
ordem, utilizaremos o diagrama de colaboração.
Concluiremos nossos estudos sobre análise e projeto OO na próxima uni-
dade, em que teremos a oportunidade de modelar um sistema OO.
Então, o que estamos esperando? Vamos ao trabalho! Boa leitura para você.
Introdução
IV
AVANÇANDO NOS DIAGRAMAS
Agora que já conhecemos o objetivo e a notação dos diagramas de caso de uso

e de classes, vamos avançar um pouco conhecendo mais três diagramas, essen-
ciais na análise e projeto OO, que utilizaremos para refinar o diagrama de classes
que representa a estrutura do sistema.
Já verificamos que a documentação do software, na maioria das vezes, não
tem a devida atenção da equipe de desenvolvimento, ou por não querer, ou por
falta de tempo, ou mesmo por achar que é uma perda de tempo elaborar inú-
meros diagramas.
Porém bons softwares tem documentação que nos permite contar e entender
a história do software. Uma análise criteriosa e um projeto bem fundamentado
na análise são aspectos que definem o sucesso e o tempo de vida de um software.
É fato que manter uma documentação atualizada demanda um esforço,
porém o esforço será maior no momento da manutenção, quando nos depara-
mos com um software sem documentação, a experiência vai ensinar isso a você
muito mais do que poderia estar escrito em qualquer livro.
Dada a importância de se adotar um método – para relembrar: o método
pressupõe a utilização de uma linguagem (notação) e um modelo de processo
- a relevância na construção e manutenção da documentação é imensurável.
Vimos na unidade II que o diagrama de Caso de Uso é utilizado na aná-
lise de requisitos e acompanhará o software desde o seu início até a conclusão.
No diagrama de Caso de Uso, surge a figura do ator, que pode ser uma pes-
soa, um sistema, um roteador. O ator é quem realiza as atividades e sempre atua
sobre um caso de uso. Portanto, o diagrama de caso de uso modela o compor-
tamento dos atores no sistema.
Olhando para o diagrama de caso de uso da Figura 68, fica claro que o aluno
realiza empréstimos, consultas e devoluções, enquanto a bibliotecária é quem
cria o livro, o aluno e os empréstimos no sistema.

111
Realiza
empréstimo
Realiza
consultra
Aluno
Realiza
devolução
Cria
livro
Cria
aluno
Bibliotecária
Efetua
empréstimo

Fonte: o autor.
Porém o diagrama de casos de uso nos fornece apenas um panorama visual das
funcionalidades do sistema, é necessário um detalhamento por meio de uma
descrição textual, mas não há descrição padrão definida pela UML, em geral, o
diagrama é bastante informal.
Ficou claro então que o diagrama por si só não é suficiente. Os casos de uso
devem vir acompanhados de uma descrição. Após a elaboração do diagrama
de caso de uso e sua descrição, teremos conhecimento suficiente a respeito do
domínio para modelar a primeira versão do diagrama de Classes que nos mos-
trará a estrutura estática do sistema.
Avançando nos Diagramas

IV
É a classe que nos fornecerá a estrutura para modelar um conjunto de ob-

jetos com características similares. A classe contém métodos e atributos. Os
métodos são responsáveis por modelar o comportamento dos objetos da
classe e os atributos modelam os possíveis estados do objeto.
Fonte: o autor.
O diagrama de sequência é o próximo diagrama que conheceremos a notação,

sua utilidade é estudar as interações entre os objetos, possibilitando a identifi-
cação de relação entre as classes, servindo para refinar o diagrama de classes.
O cenário da figura 60 mostra a solicitação de um empréstimo pelo aluno,
a partir dessa ação, é desencadeado um conjunto de mensagens entre os objetos
que permite a verificação da existência da pessoa aluno, em seguida, é criado o
item de empréstimo, que verifica a existência do exemplar solicitado, realizando
o empréstimo.
Observamos que a partir das informações fornecidas pelo diagrama de
sequência é possível identificar os métodos associados às classes, além da iden-
tificação das relações entre as classes.

113
Aluno Empréstimo Pessoa Ítem_Empréstimo Exemplar
1: Solicita
Empréstimo ( )
2: Verifica se
existe ( )
2.1: Verificação
OK ( )
3: Cria Ítens ( )
4: Verifica se
existe ( )
4.1: Verificação
OK ( )
5: Cria Ítens ( )
6: Cria Ítens ( )
7: Cria empréstimo ( )
Figura 69: Diagrama de Sequência

Fonte: o autor.
Muito bem, mas como posso interpretar esse diagrama? A resposta é conhe-
cendo sua notação. Vamos lá!
NOTAÇÃO DO DIAGRAMA DE SEQUÊNCIA
O diagrama de sequência da figura 70 tem todos os elementos da notação des-

tacados por uma elipse vermelha, em que é possível observar as mensagens
(síncronas, assíncronas, reflexiva), linha do tempo, tempo de atividade e obje-
tos. Vamos conhecê-los em detalhes.
Diagrama de Sequência
IV
: NomeDaClasse : NomeDoAtributo1 : NomeDoAtributo 2 : NomeDoAtributo 4
: NomeDoAtor
1: Mensagem
Sincrona( ) 1.1: Mensagem 2: Mensagem
Sincrona( ) Assincrona( ) Ator,
classe ou
atributo
Mensagen
3: Mensagem Assincrona
Sincrona( ) 3.1: Mensagem
Sincrona( )
4: Auto
Mensagem( )
Mensagem
Sincrona
Mensagem Auto Mensagem Linha de Vida

de Retorno (Lifetime)
Figura 70: Modelo de Diagrama de Sequência

Fonte: o autor.
TIMELINE
As timelines ou linhas de vidas fazem parte da dimensão vertical do diagrama.

A linha de vida é composta de duas partes: a cabeça e a cauda. A cabeça é repre-
sentada por um retângulo, no qual é exibida a identificação do objeto, a cauda
corresponde a uma linha vertical tracejada.
Linha do Tempo
Figura 71: Timeline (linha de vida ou tempo)

Fonte: o autor.

115
MENSAGENS
Uma Mensagem é representada por uma seta horizontal, do emissor para o
receptor, com o nome e possíveis argumentos, ligando uma linha de vida a outra.
O objeto do qual parte a seta é aquele que está enviando a mensagem (objeto
remetente). O objeto para o qual a seta aponta é aquele que está recebendo a
mensagem (objeto receptor).
O formato da ponta da seta indica o tipo de mensagem sendo enviada, que
pode ser síncrona ou assíncrona. O rótulo da mensagem é posicionado acima
dessa seta.
Pessoa Compra
1: Sincrona ( )
2: Assincrona ( )
Figura 72: Mensagens síncrona e assíncrona

Fonte: o autor.
Como podemos verificar na figura 72, uma Mensagem é representada por uma
seta horizontal, do emissor para o receptor, com o nome e possíveis argumentos.
As mensagens são síncronas, quando quem envia (emissor) fica no aguardo
da resposta pelo receptor, e são representadas por uma seta com a ponta preen-
chida. O retorno de Mensagem Síncrona é representado por uma linha tracejada.
As mensagens são assíncronas, quando quem envia (emissor) a mensagem
NÃO fica no aguardo da resposta pelo receptor, e são representadas por uma seta
com a ponta vazada. Não tem notação de retorno para essa mensagem.
As mensagens também podem ser reflexivas, de autodelegação ou, ainda,
automensagem, nesse caso, são representadas por uma seta que retorna para a
mesma linha do tempo de partida. Como apresentado na figura 73:
IV
Lifeline1
2: Auto Mensagem( )
Figura 73: Auto mensagem síncrona

Fonte: o autor.
TEMPO DE ATIVIDADE
Os objetos também apresentam um tempo de atividade na linha do tempo, essa
atividade corresponde ao tempo durante o qual um objeto exerce sua ação, direta
ou indiretamente, por meio de um objeto que lhe presta o serviço.
A notação é um retângulo na linha do tempo em que as bordas representam
o período de atividade, como podemos observar na figura 74:
Lifeline1
2:
Tempo de atividade
Figura 74: Tempo de atividade

Fonte: o autor.
EXEMPLO
Já conhecemos a notação do diagrama de sequência, agora vamos praticar um

pouco. Para facilitar o entendimento da notação, vamos utilizar um exemplo da uni-
dade II, que apresento um caso de uso para a resolução de expressões aritméticas.
Lembrando que o diagrama de casos de uso é apenas um panorama visual
das funcionalidades do sistema, é necessária uma descrição textual para deta-
lhar os casos de uso.
Na figura 75, é apresentado um diagrama de casos de uso que mostra o ator
“Operador” interagindo com o caso de uso “Cadastrar Pessoas”.

117
Cadastrar Pessoas
Operador
Figura 75: Caso de Uso
Fonte: o autor.
O quadro 2 mostra a descrição textual para o caso de uso “Cadastrar Pessoas”:
NOME DO CASO DE USO CADASTRAR PESSOAS

Descrição Permite inserir novos dados cadastrais de pessoas no

sistema.
Ator Operação
Pós-condições Dados gravados ou cancelamento da operação pelo Ope-
rador.
Fluxo Básico
Usuário Sistema
{Solicita Dados}
Solicita os dados do cliente. (A2)
Fornece os dados
{Valida os dados}
Verifica se os dados obedecem às regras de entrada (A1)
{Grava os dados}
{Fim}
Fim do caso de uso
Fluxos alternativos
A1: em {Valida expressão} Se o usuário fornecer entradas que não obedecem as
regras de entrada (máscara de entrada, intervalo, datas...
etc.), informá-lo sobre o erro e retornar ao fluxo básico em
{Solicita expressão}
A2: em {Solicita expressão} O usuário pode decidir encerrar o caso de uso sem forne-
cer os dados. Nesse caso, retornar ao fluxo básico em {Fim}
Quadro 02: Descrição textual para o caso de uso
Fonte: o autor.
IV
Essa descrição textual detalha o caso de uso, mostrando as prés e pós-condi-

ções para execução, bem como o fluxo básico de execução, que significa dizer
que o sistema solicitará a entrada de dados ao operador que poderá cancelar, se
desejar, sendo desviado o fluxo de execução para o fluxo alternativo A2, porém,
caso não cancele, o sistema validará a entrada de dados fornecida pelo operador,
desviando para o fluxo alternativo A1, que tem como objetivo validar a entrada
de dados, verificando as máscaras de entrada, intervalo de valores, entre outras
regras. Se passar pela validação, o sistema gravará os dados na base de dados.
Um fluxo descreve como o sistema e os atores colaboram para produzir algo
de valor aos atores e o que pode impedir sua obtenção. Um fluxo descreve um
caminho entre muitos possíveis, visto que um caso de uso pode ser executado de
vários modos. Existem fluxos básicos, que demonstram o fluxo normal de eventos,
e alternativos, que dizem o que fazer caso não seja possível seguir o fluxo básico.
No caso de uso “Resolver expressões aritméticas”, o usuário pode tanto for-
necer a expressão para o cálculo (fluxo básico) quanto cancelar a operação,
desviando o fluxo alternativo A2, porém, caso o usuário siga no fluxo básico,
após o fornecimento da expressão para cálculo, o fluxo será desviado para um
caminho alternativo A1 que valida a entrada.
Para ficar mais fácil o entendimento da sequência dos fluxos de mensagens,
construiremos o diagrama de sequência para esse caso de uso.
Primeiramente, vamos definir as linhas do tempo, teremos uma para o usuá-
rio, outra para a interface do usuário com o sistema, outra para o controle do
sistema e a última para a calculadora, como mostrado na figura a seguir.
InterfaceUsuário Sistema Calculadora
Usuário
Figura 76: Linhas do tempo para calculadora

Fonte: o autor.

119
Em seguida, o sistema irá solicitar a expressão para o Usuário, enviando uma

mensagem síncrona para a interface Usuário que deverá aguardar a resposta do
Usuário para a continuação, conforme a figura:
Usuário
1.1: Expressão? ( ) 1: SolicitarExpressao ( )
{Exp}
{Exp}
Figura 77: Diagrama de Sequência com troca de mensagens entre usuário e sistema.
Fonte: o autor.
Após o recebimento da expressão, o sistema enviará uma mensagem síncrona

para a calculadora, que validará a entrada e calculará se ela for válida, em seguida,
mostrará o resultado na interface com o usuário.
Usuário
1.1: Expressão? ( ) 1: SolicitarExpressao ( )
{Exp}
{Exp} 2: Calcular(exp) ( ) 2.1: Validar ( )
2.2: Calcular(exp) ( )
3.1: Resultado ( ) 3: MostraResultado ( ) <<Resultado>>
Figura 78: Diagrama de sequência para Resolver expressões aritméticas

Fonte: o autor.
IV
DIAGRAMA DE ESTADOS
Veremos o diagrama de estados, que tem como objetivo especificar o compor-

tamento das classes mais complexas utilizando máquinas de estado.
Somente as classes que possuem um número finito de estados conhecidos
têm a necessidade de uma representação por um diagrama de estado. É possí-
vel prever os possíveis comportamentos de um objeto por meio da análise da
mudança de estados dos tipos de objetos de um sistema.
Dessa forma, o diagrama de estado representa o comportamento interno da
classe, permitindo a especificação da sua dinâmica. Uma especificação corres-
ponde a como deve ser implementada uma classe.
ESTADO
O estado representa a situação ou momento no tempo de vida de um objeto,

o objeto pode passar por vários momentos ao longo de sua vida, por exemplo:
■■ Momento de criação.
■■ Momento de inicialização.
■■ Momento que realizou alguma solicitação.
■■ Momento que é destruído.
Todos os objetos possuem um estado que, normalmente, é determinado pelos

valores de seus atributos, que é o resultado de atividades executadas pelo objeto.
A NOTAÇÃO PARA ESTADOS
A notação para o estado inicial é um círculo preenchido, como mostra a figura

a seguir:
Figura 79: Estado Inicial

Fonte: o autor.

121
A notação para o estado final é um círculo preenchido com borda, como mos-
tra a figura a seguir:
Figura 80: Estado final

Fonte: o autor.
Um retângulo com os cantos arredondados representa um estado simples que

é o estado mais comum, somente um valor de um atributo de uma classe pode
ser representado por esse estado.
State0
Figura 81: Estado simples

Fonte: o autor.
O estado simples também pode ser representado por um retângulo com dois
compartimentos, no primeiro compartimento, é informado o nome para o estado
e, no segundo compartimento, as ações.
StateName
entry / action
do / action
exit / action
Figura 82: Estado

Fonte: o autor.
O Estado também pode ser composto, nesse caso, um retângulo maior identifica
o estado composto, o que significa dizer que dentro dele terão outros estados.
Diagrama De Estados
IV
Estado Composto
Estado Estado
Figura 76: Linhas do tempo para calculadora
Fonte: o autor.
O diagrama pode representar, também, um estado de escolha com um losango

simples e vazado. O que significa dizer que o programa deve decidir e ir para
um dos estados possíveis a partir do estado de escolha.
Reservado
Disponível Emprestado
Manutenção
Figura 84: Estado de escolha

Fonte: o autor.
A junção é o contrário do estado de escolha, ou seja, vários estados podem che-

gar a um único estado. Nesse caso, a representação é feita por meio de um círculo
preenchido.

123
Estado 2
Estado 1 Estado 3
Estado 4
Figura 85: Estado de junção

Fonte: o autor.
O fork, representado por um retângulo preenchido, indica estados concorrentes.

Quando um estado chega ao fork, desencadeia um ou mais estados concorrentes.
Estado 1
Estado 2 Estado 3 Estado 4
Figura 86: Estado fork

Fonte: o autor.
O join (junção) é representado também por um retângulo preenchido, porém,

ao contrário do fork, representa todos os estados chegando em um.
Diagrama De Estados
IV
Estado 1 Estado 2
Estado 3
Figura 87: Estado de join (junção)
Fonte: o autor.
E, por último, as ações, elas ocorrem em três eventos: quando entra (entry), sai
(exit) ou está (do) em um estado.
Estado 1 Estado 2
entry / funcaoX funcaoZ( ) (Z>1) exit / funcaoY
Figura 88: Ações do Estado

Fonte: o autor.
De acordo com o diagrama de estados apresentado na figura 83, a funcaoX será

executada no momento em que entrar no Estado1. Na transição do Estado1 para
o Estado2, será executa a funcaoZ somente se o Z for maior que 1. Por fim, na
saída do Estado2, será executada a funcaoY.
A ação “do” é executada durante todo o tempo de permanência no estado
que disparou a função.
O diagrama de estado da figura 80 mostra que, quando um exemplar tiver
DISPONÍVEL para empréstimo, será executada a função atualiza() enquanto o
objeto permanecer nesse estado. Na transição para o estado EMPRESTADO, é
executada a função empresta (exemplar_id), passando como parâmetro o exem-
plar_id. Na transição de EMPRESTADO para disponível, é executada a função
libera (exemplar_id). Por fim, na transição de DISPONÍVEL para ENCERRADO,

125
é executada a função encerra_id (exemplar_id).
libera(exemplar_id)
DISPONÍVEL EMPRESTADO
do / atualiza( ) do / atualiza( )
empresta(exemplar_id)
encerra(exemplar_id
ENCERRADO
do / atualiza( )
Figura 89: Diagrama de Estado

Fonte: o autor.
Vamos para o último diagrama, conhecido como diagrama de colaboração até a

versão 1.5 da UML, teve sua denominação modificada para diagrama de comu-
nicação na versão 2.0 da UML.
O diagrama de comunicação é outra forma de representar o cenário, esse
diagrama contém as mesmas informações que o diagrama de sequência, porém
não considera o tempo e sim a ordem da comunicação.
O diagrama de comunicação identifica as classes mais próximas e a ordem
de envio de mensagens que é identificada por números sequenciais, mostrando
a interação de forma organizada em torno dos objetos.
As classes colaboram entre si trocando mensagens, se o objetivo é verificar
o envio de mensagens no decorrer do tempo, devemos utilizar o diagrama de
Diagrama de Comunicação
IV
sequência, porém, se quisermos verificar a troca de mensagens no contexto do

sistema, utilizamos o diagrama de comunicação.
O diagrama de comunicação é composto, basicamente, por 4 elementos:
■■ Ator.
■■ Objetos.
■■ Vínculos.
■■ Mensagens.
NOTAÇÃO PARA O DIAGRAMA DE COMUNICAÇÃO
Ator
O ator tem a mesma representação dos demais diagramas, ou seja, o homem
palito, com seu rótulo precedido de dois pontos.
:Ator
Figura 90: Ator
Fonte: o autor.
Objeto
O objeto é representado por um retângulo, em que, em seu interior, é infor-
mado o objeto e o nome da classe a qual aquele objeto pertence, separados por
dois pontos, que definimos como instância identificada.
umaPessoa : Pessoa
Figura 91: Instância identificada

Fonte: o autor.

127
O objeto também pode ser representado somente com a identificação da classe

em seu rótulo.
StateName
entry / action
do / action
exit / action
Figura 92: Classe

Fonte: o autor.
Ainda, o objeto pode ser representado somente com a identificação da instância

da classe em seu rótulo, nesse caso, o rótulo deve vir precedido por dois pontos.
: umaPessoa
Figura 93: Instância

Fonte: o autor.
VÍNCULO
O vínculo é a ligação entre dois objetos, que identifica o envio e recebimento

de mensagens.
: umaPessoa
Figura 94: Vínculo

Fonte: o autor.
MENSAGENS
As mensagens enviadas e recebidas são representadas por setas que apontam suas
direções, a descrição da mensagem vem acompanhada do seu número de ordem.
IV
1: Consulta ( )
2: fazDiagnóstico ( )
3: aplicaMedicação ( )
: umPaciente
: Médico 4: Sara ( )
Figura 95: Troca de Mensagens
Fonte: o autor.
EXEMPLO
O diagrama de comunicação da figura 96 exemplifica a troca de mensagens entre

os objetos. Podemos verificar que o objeto GUI Bibliotecária envia uma men-
sagem para criar (1) um novo empréstimo. O objeto empréstimo, por sua vez,
envia uma mensagem para validar (2) o aluno, ou seja, verificar se aquele aluno
realmente existe.
Após a validação do aluno, o objeto empréstimo envia uma mensagem para
item empréstimo validar (3) o exemplar que está sendo emprestado, porém, para
item empréstimo validar (4) o exemplar é necessário enviar uma mensagem de
validação para o objeto exemplar.
1: Cria ( ) 2: Valida ( )
GUI Bibliotecária Empréstimo Aluno
3: Valida ( )
Ítem Empréstimo
4: Valida ( )
Exemplar
Figura 96: Diagrama de Comunicação

Fonte: o autor.

129
Se o diagrama de sequência já cria o cenário que mostra a troca de mensa-

gens entre os objetos, qual a necessidade de elaborar, também, diagrama
de comunicação?
Fonte: o autor.
Nesta unidade, aprendemos mais três diagramas importantes para análise e pro-
jeto orientado a objetos, são eles: os diagramas de sequência, colaboração e estado.
Familiarizamo-nos com a notação e com como utilizar o diagrama de sequên-
cia, vimos como ele pode nos auxiliar no estudo das interações entre os objetos,
bem como fornecer subsídios para o refinamento da identificação da relação
entre as classes.
Estudamos as principais características do diagrama de estados, vimos que
o comportamento de uma classe pode ser modelado por meio desse diagrama.
Porém, não são todas as classes que necessitam dessa representação, pois não
apresentam um número de estados que se possa quantificar.
Por fim, estudamos outra forma de representação do cenário em que o sis-
tema irá funcionar, representando toda a ordem de comunicação entre classes
por meio do diagrama de colaboração. Aprendemos que, diferentemente do dia-
grama de sequência, o diagrama de colaboração não se importa com o tempo
em que as mensagens ocorrem e sim com sua ordem de ocorrência.
Na verdade, a análise e o projeto de um software são extremamente depen-
dentes da habilidade do analista em articular todos os elementos do sistema. Essa
articulação se faz necessária uma vez que o software não se resume a um arquivo
executável. O software é dependente do hardware, que executará o sistema, bem
como dos usuários, que interagirão com ele, e da cultura da organização.
É difícil, em um primeiro momento, saber por onde começar o levantamento
de requisitos ou qual diagrama elaborar primeiro, porém a prática nos ensina
IV
atalhos e o tempo tratará de refinar sua arte.

Então, programar é uma arte? Sim, considero dessa forma, porque o software
é uma produção intelectual, ou seja, é uma obra do espírito, assim como aquele
bom livro que lemos, aquele excelente filme que assistimos ou, ainda, aquela
escultura que apreciamos seus contornos. A diferença é que nem sempre pro-
duzimos aquilo que gostaríamos, mas sim aquilo para o qual fomos contratados,
por isso, há necessidade de apresentar habilidades que permitam agregar pessoas.


131
1. Qual o objetivo do diagrama de sequência e quais são os principais elementos

de sua notação.
2. Quais classes são candidatas para a elaboração de um diagrama de estado? Ex-
plique.
3. Sabemos que o diagrama de comunicação é outra forma de modelar o cenário
do software, quando devemos utilizá-lo?
4. Qual a diferença entre os diagramas de sequência e comunicação?
UML e C++: Guia Prático de Desenvolvimento

Orientado a Objetos
Richard C. Lee; William M. Tepfenhart
Sinopse: Este livro prático é um guia autoexplicativo para
analistas e desenvolvedores de software. Ele ensina como,
realmente, praticar modelagem orientada a objeto usando a
notação da UML e implementar o modelo com C++. Os autores
apresentam todos os conceitos básicos da tecnologia orientada
a objeto necessários para que os leitores possam entender e
aplicar o paradigma orientado a objeto.
Da mesma forma que é impossível construir uma casa sem, primeiramente, definir sua planta,
também é impossível construir um software sem, inicialmente, definir sua arquitetura.
Leia mais sobre o assunto no link disponível em: <http://www.dsc.ufcg.edu.br/~jacques/cursos/
map/html/uml/motivacao/motivacao1.htm>. Acesso em: 30 jul. 2015.
133
Prezado(a) aluno(a), segue uma matéria definir a engenharia de requisitos como

muito interessante sobre UP, que é um um campo da engenharia de software que
processo unificado estabelecido para o visa a aplicação de técnicas de engenha-
desenvolvimento de software resultado ria em métodos de análise de requisitos,
de três décadas de desenvolvimento e de que efetua a ligação entre a necessidade de
uso prático. informatização de processos e o projeto do
software que atenderá a tais necessidades.
ENGENHARIA DE REQUISITOS E O UP
No decorrer das duas últimas décadas, uma
Delmir Peixoto de Azevedo Junior; série de métodos de análise e especificação
Renato de Campos de requisitos foi desenvolvida, sendo pou-
cas as propostas que visam a sistematização
A engenharia de software se produz atra- da definição de requisitos de forma menos
vés de um conjunto de fases. Cada uma subjetiva (SANTANDER, 2002).
das fases pode envolver métodos, ferra-
mentas e procedimentos, cujas formas de O UP (Processo Unificado) é um processo
estruturação são citadas como modelo estabelecido para o desenvolvimento de
de engenharia de software (PRESSMAN, software resultado de três décadas de
2002). Ainda segundo Pressman (2002), desenvolvimento e de uso prático. Jacob-
independentemente do modelo de desen- son, Booch e Rumbaugh (1999) apresentam
volvimento de software, o processo contém as origens do UP no processo Objectory,
três fases genéricas: definição, desenvolvi- que teve sua primeira versão apresentada
mento e manutenção. em 1987, passando pelas contribuições
do Processo Rational Objectory (1997), até
Quatro modelos de engenharia de software chegar ao Processo Unificado da Rational –
têm sido amplamente discutidos: o ciclo de RUP (KRUCHTEN, 2003). O propósito do UP,
vida clássico (ou cascata), a prototipação, como qualquer outro processo de desen-
o modelo espiral e as técnicas de Quarta volvimento, é determinar um conjunto
Geração (PRESSMAN, 2002). Atualmente de atividades necessárias para transfor-
um novo modelo tem sido bastante usado: mar requisitos em sistemas de software.
o modelo iterativo e incremental (JACOB- Neste caso, utiliza a UML como linguagem
SON; BOOCH; RUMBAUGH, 1999; PAULA para a modelagem dos artefatos de sof-
FILHO, 2001). tware produzidos ao longo do processo de
desenvolvimento. O UP é fundamentado
A análise de requisitos é uma etapa pre- em três boas práticas: dirigido por caso de
sente na fase de definição do software, uso, centrado em arquitetura, iterativo e
independentemente do modelo de enge- incremental. Os casos de uso definidos para
nharia de software adotado. Paula Filho um sistema são a base de todo o processo
(2001) afirma que a engenharia de requi- de desenvolvimento. A partir de uma pers-
sitos é formada por um conjunto de pectiva de gerenciamento, o ciclo de vida
técnicas empregadas para levantar, deta- de software do UP é dividido em quatro
lhar, documentar e validar os requisitos de fases seqüenciais (Concepção, Elaboração,
um produto de software. Assim, é possível Construção e Transição), sendo que cada
fase refere-se a uma determinada meta a construção e documentação de artefatos
ser atingida ao longo do desenvolvimento. de sistemas de software, como também
para a modelagem de negócios e outros
Cada uma das quatro fases do UP é adicio- sistemas não necessariamente relaciona-
nalmente dividida em iterações e finalizada dos a software, e representa uma coleção
com um ponto de checagem que verifica se das melhores práticas de engenharia que
os objetivos daquela fase foram alcançados. comprovaram bom êxito na modelagem
Toda iteração é organizada em termos de de sistemas grandes e complexos (OMG,
workflows de processo, que são conjuntos 1997). Os principais diagramas da UML são:
de atividades realizadas pelos responsáveis Diagrama de Classes, Diagrama de Obje-
pela produção dos artefatos. Os principais tos, Diagrama de Casos de Uso, Diagrama
workflows de processo do UP são Levan- de Seqüência, Diagrama de Colaborações,
tamento de Requisitos, Análise, Projeto, Diagrama de Gráficos de Estados, Diagrama
Implementação, Teste e Implantação, sendo de Atividades, Diagrama de Componentes,
que o RUP se diferencia, principalmente, Diagrama de Implantação.
em relação ao workflow de Modelagem
de Negócio. A UML também permite a ampliação da
linguagem de maneira controlada, atra-
A UML foi adotada pela OMG (Object vés de mecanismos de extensão, de forma
Management Group) em 1997 como lin- a expressar todas as nuances possíveis de
guagem padrão para a modelagem de todos os modelos em qualquer domínio
sistemas orientados a objeto. É uma lin- de análise (exemplo: análise de negócios),
guagem para especificação, visualização, fornecendo alguma flexibilidade.
Leia mais: http://www.scielo.br/scielo.php?script=sci_arttext&pi-
d=S0103-65132008000100003&lang=pt
V
UNIDADE
ESTUDO DE CASO
■■ Conhecer uma ferramenta case para modelagem OO.
■■ Fazer a análise e projeto a partir de um estudo de caso.
■■ Elaborar um diagrama de caso de uso.
■■ Elaborar um diagrama de classes.
■■ Elaborar um diagrama de sequência.
■■ Elaborar um diagrama de estado.
■■ Elaborar um diagrama de colaboração.
Plano de Estudo
■■ Ferramentas Case
■■ Estudo de caso
■■ Diagrama de caso de uso
■■ Diagrama de classes
■■ Diagrama de sequência
■■ Diagrama de estado
■■ Diagrama de comunicação
137
INTRODUÇÃO
Caro(a) aluno(a), chegamos a quinta e última unidade do livro Análise e Projeto

Orientado a Objetos fazendo a análise e o projeto orientado a objetos para um
estudo de caso que será apresentado.
O objetivo dessa unidade é que você desenvolva junto comigo a análise e o
projeto de um software, porém, para não precisarmos desenhar os diagramas à
mão, vamos utilizar um software para nos auxiliar. Esse software é denominado
ferramenta CASE.
Existem muitas ferramentas CASE no mercado, como todo produto de sof-

tware, existem os softwares proprietários, que necessitam uma licença de uso, e
os softwares livres, que não necessitam de uma licença de uso. Vamos optar aqui
por uma ferramenta que seja livre e que atenda as nossas necessidades.
Apresentarei a vocês um estudo de caso em que teremos a oportunidade de
modelar um software orientado a objetos, utilizando uma ferramenta CASE que
nos auxiliará na construção dos diagramas.
Construiremos, primeiramente, o diagrama de caso de uso para criarmos o
cenário para o software, definindo quais serão os atores e seus respectivos casos
de uso. Faremos, também, a especificação para os casos de uso.
Em seguida, a partir das informações coletadas na construção do diagrama
de caso de uso, poderemos, então, elaborar o diagrama de classes, que repre-
senta a estrutura estática do sistema. Esse diagrama sofrerá vários refinamentos
até sua versão final.
O diagrama que construiremos em seguida é o de sequência, que nos mostrará
como e quando ocorrem as trocas de mensagens entre os objetos. A elaboração
desse diagrama, invariavelmente, provoca um refinamento do diagrama de classes.
Logo após, construiremos o diagrama de colaboração, em uma tentativa de
representar o cenário de forma semelhante ao diagrama de sequência.
Por fim, construiremos o diagrama de estado, que mostrará o comporta-
mento da classe por meio de máquinas de estado.
Então, o que estamos esperando? Vamos ao trabalho.
Introdução
V
FERRAMENTAS CASE
Modelar um sistema na mão ou com softwares que não foram construídos para
tal pode ser um barato que sai caro. O ideal é adotarmos uma ferramenta CASE.
Uma ferramenta CASE (Computer-Aided Software Engineering), em uma
tradução livre “engenharia de software auxiliada por computador”, é uma clas-
sificação de software que abrange aquelas ferramentas computacionais que têm
como objetivo auxiliar a atividade de engenharia de software.
Todas as imagens de diagramas que adicionei foram feitas com a ferramenta
CASE produzida pela empresa Astah, no material complementar tem o link para
o download dessa ferramenta que é gratuita.
É imprescindível que, ao adotar uma ferramenta CASE, também adotemos

um processo de desenvolvimento de software. Lembra-se de que falamos
que um método pressupõe a existência de um processo e um modelo de
linguagem?
Fonte: o autor.
Muito bem, para nossa análise e projeto orientado a objetos, adotaremos ferra-
menta CASE Astah Community, por oferecer suporte para o modelo de linguagem
que utilizaremos, ou seja, a UML.
O modelo de processo de desenvolvimento que adotaremos será o cascata, por
ser um processo clássico e ter as fases bem definidas. As fases para esse modelo
são: análise, projeto, implementação, teste, integração, implantação, manutenção.
No estudo de caso que desenvolveremos, cobriremos duas fases do modelo
em cascata, que é a análise e o projeto.
Penso que não é possível utilizar um modelo de processo sem ferramentas
CASE que o suportem. Invariavelmente, ocorre que na primeira manutenção a
documentação fica desatualizada, já discutimos que documentação desatualizada
ESTUDO DE CASO
139
não serve para muita coisa. Porém, com a utilização de uma ferramenta CASE
adequada, fica fácil atualizar a documentação a cada manutenção.
O FAST CASE provê todas as funcionalidades necessárias para a construção

dos modelos, tais como o Modelo de Requisitos, suportando a técnica de
casos de usos, e os Modelos de Análise e Projeto, suportando os modelos
de Classes, Interações e de Ciclo de vida. O sistema, que é distribuído livre-
mente, já vem sendo utilizado há mais de um ano por mais de uma centena
de alunos.
Saiba mais sobre o FAST CASE em: <http://www.inf.ufsc.br/sbes99/anais/
Sessao-Ferramenta-Completo/12-fastcase.pdf>. Acesso em: 31 jul. 2015.
Fonte: o autor.
ESTUDO DE CASO
Apresentarei, agora, um estudo de caso que utilizaremos para a nossa análise e

projeto orientado a objetos.
O sistema é simples e de fácil entendimento, o objetivo é que façamos a
construção dos diagramas UML, faremos isso passo a passo. Então, para você
acompanhar a atividade, sugiro que faça o download do Astah Community ou
qualquer outra ferramenta CASE que esteja habituado.
O trabalho com a ferramenta CASE Astah Community é bem intuitivo e
você não terá dificuldades em desenvolver. Vamos por a mão na massa.
A distribuidora de filmes Fenix é proprietária de vários cinemas, em diver-
sas cidades, e precisa de um sistema para controlar as exibições de filmes em
todas as salas de seus cinemas.
No fluxo básico do sistema, o operador é responsável por alimentar todos
os cadastros que envolvem a movimentação de exibição ou suspensão do filme.
Não temos interesse em controlar os ingressos para os filmes, mas sim as
datas, horários e salas onde os filmes estão sendo exibidos, dessa forma, podemos
Estudo De Caso
V
simplesmente exibi-lo ou suspendê-lo.

Cada cinema possui uma sala ou várias salas de exibição. Um filme pode estar
em cartaz em mais de um cinema ao mesmo tempo, isto é, pode estar sendo exi-
bido em vários cinemas e, é claro, em várias cidades ao mesmo tempo.
Cada cinema possui uma identificação, um nome de fantasia, um endereço
e sua capacidade de lotação. Cada filme é registrado com um título, sua dura-
ção, sua impropriedade e um conjunto de atores que formam seu elenco, bem
como seu diretor.
Os atores de um filme podem atuar em diversos filmes, assim como o dire-
tor de um filme pode, também, ser ator nesse ou em outro filme. Um ator possui
código, nome, nacionalidade e idade. Existe um único diretor para cada filme.
Primeiramente, vamos definir os requisitos funcionais do sistema. Lembrando
que, requisitos funcionais é tudo aquilo que o sistema deve fazer.
REQUISITOS
O sistema de exibição de filmes MovieShow auxiliará o operador de cinema a

exibir e suspender a exibição dos filmes nos vários cinemas que compõem a
Distribuidora Fenix. Para isso, algumas funcionalidades são necessárias:
1. O sistema deve permitir que os usuários acessem, de maneira “on-line”
e a qualquer momento, o sistema, utilizando dispositivos que suportem
navegadores web “atuais”.
2. A autenticação deve ser feita utilizando uma conta criada no próprio
sistema. Para criar a conta, o usuário deve solicitar o cadastro que será
aprovado por um usuário “administrador”. O usuário cadastrado deverá
confirmar que leu os termos de aceite do sistema e mudar sua senha na
primeira autenticação. O sistema deve ter uma política para criação e
manutenção de senhas.
3. O controle de permissões deve ser feito por um usuário “administrador”
que diz o que cada usuário pode acessar.
ESTUDO DE CASO
141
4. Os tipos possíveis de usuários são:

a. Administrador: que gerencia questões administrativas, como permissões, blo-
queio de usuários, configurações etc.
b. Operador: responsável pelo cadastro e exibição dos filmes.
5. O menu principal do sistema deve listar os filmes e salas que estão sendo
exibidos.
6. O operador deve cadastrar os filmes, cinemas e salas.
7. O sistema deve permitir ao operador exibir ou suspender a exibição de
um filme.

Estudo De Caso
V
DIAGRAMA DE CASO DE USO
Vamos começar, então, compondo nosso cenário, construindo, primeiro, o

diagrama de caso de uso. Lembrando que esse diagrama nos fornecerá uma
panorâmica dos requisitos funcionais.
Os requisitos funcionais dizem a respeito àquilo que o software deve fazer,
ou pelo menos o que se espera que faça.
Vamos lá, primeiramente, abra o Astah Community e clique na opção UseCase
Diagram, como mostrado na imagem abaixo, ou clique no menu Diagram e esco-
lha a opção UseCase Diagram.
Figura 97: Tela principal do Astah Community

Fonte: o autor.
Em seguida, abrirá a tela apresentada na figura 98, na elipse vermelha, estão todas
as ferramentas que precisaremos para a confecção do diagrama de caso de uso.
Como você pode observar, o software é bem intuitivo:
ESTUDO DE CASO
143
Figura 98: Ferramentas para o Diagrama de Caso de Uso

Fonte: o autor.
Vamos iniciar modelando o ator que será o administrador do sistema, esse usu-
ário será responsável pela administração de novos acessos no sistema.
Cadastrar novos
usuários
Administrador Definir permissões

para usuário
Figura 99: Ator Administrador

Fonte: o autor.
O diagrama da figura 100, agora completo, mostra o operador do cinema e suas

atribuições de realizar os cadastros de ator, filme, cinemas, salas e fazer as movi-
mentações de exibir e suspender a exibição de um filme.
Diagrama De Caso De Uso

V
Cadastrar novos Definir permissões

usuários para usuário
Administrador
Cadastrar Ator Cadastrar Filmes
Cadastrar Cinemas Exibir Filme
Operador
Cadastrar Salas Suspender exibição

de filme

Fonte: o autor.
Para completarmos o diagrama de caso de uso, devemos adicionar a cada um

deles uma descrição textual, vamos lá!
ATOR: ADMINISTRADOR
Cadastrar novos
usuários
Administrador
Figura 101: Cadastrar novos usuários
Fonte: o autor.
ESTUDO DE CASO
145
NOME DO CASO DE USO CADASTRAR NOVOS USUÁRIOS

Descrição Permite inserir novos usuários no sistema.
Ator Administrador
Pós-condições Novo usuário inserido
Fluxo Básico
Ações do Ator Ações do Sistema
Solicitar a criação do
novo usuário
Abre a Janela de Cadastro (A2)

Usuário informa os
dados
Sistema valida a entrada (A1)
Sistema salva os dados
Fim
Fluxos alternativos
A1: em {Valida entrada} Se o usuário fornecer uma entrada incorreta, informá-
-lo sobre o erro e retornar ao campo incorreto.
A2: em {Solicita Cancela- O usuário pode decidir encerrar o caso de uso sem
mento} fornecer uma entrada. Nesse caso, retornar ao fluxo
básico em {Fim}
Quadro 3: Caso de Uso Cadastrar Novos Usuários.
Fonte: autor
Definir permissões
para usuário
Administrador
Figura 102: Definir permissões para usuário
Fonte: o autor.

V
NOME DO CASO DE USO DEFINIR PERMISSÕES PARA OS USUÁRIOS

Descrição Permite definir permissões para os usuá-
rios.
Ator Administrador
Pós-condições Permissões concedidas
Fluxo Básico
Solicitar a definição de permissões
Abre a Janela de definição de permissões
(A2)
Usuário informa as permissões
Fim
Fluxos alternativos
A1: em {Valida entrada} Se o usuário fornecer uma entrada incor-
reta, informá-lo sobre o erro e retornar ao
campo incorreto.
A2: em {Solicita Cancelamento} O usuário pode decidir encerrar o caso
de uso sem fornecer uma entrada. Nesse
caso, retornar ao fluxo básico em {Fim}
Quadro 4: Caso de Uso Definir Permissões para os Usuários.
Fonte: autor
ATOR: OPERADOR
Cadastrar Elenco
Operador
Figura 103: Cadastrar ator
Fonte: o autor.
ESTUDO DE CASO
147
NOME DO CASO DE USO CADASTRAR ELENCO

Descrição Permite inserir novos atores ou diretores no sistema.
Ator Operador
Pós-condições Novo ator inserido
Fluxo Básico
novo ator

Usuário informa os
dados
Fim
Fluxos alternativos
A1: em {Valida entrada} Se o usuário fornecer uma entrada incorreta, informá-
-lo sobre o erro e retornar ao campo incorreto.
A2: em {Solicita Cance- O usuário pode decidir encerrar o caso de uso sem
lamento} fornecer uma entrada. Nesse caso, retornar ao fluxo
básico em {Fim}
Quadro 5: Caso de Uso Cadastrar Elenco.
Fonte: autor

V
Cadastrar Filmes
Operador
Figura 104: Cadastrar Filmes
Fonte: o autor.
NOME DO CASO DE USO CADASTRAR NOVOS FILMES

Descrição Permite inserir novos filmes no sistema
Ator Operador
Pós-condições Novo filme inserido
Fluxo Básico
novo filme
Usuário informa os dados
Fim
Fluxos alternativos
A1: em {Valida entrada} Se o usuário fornecer uma entrada incorreta, infor-
má-lo sobre o erro e retornar ao campo incorreto.
A2: em {Solicita Cancela- O usuário pode decidir encerrar o caso de uso sem
mento} fornecer uma entrada. Nesse caso, retornar ao fluxo
básico em {Fim}
Quadro 6: Caso de Uso Cadastrar Novos Filmes.
Fonte: autor
Cadastrar Cinemas
Operador
Figura 105: Cadastrar Cinemas
Fonte: o autor.
ESTUDO DE CASO
149
NOME DO CASO DE USO CADASTRAR NOVOS CINEMAS

Descrição Permite inserir novos cinemas no sistema
Ator Operador
Pós-condições Novo cinema inserido
Fluxo Básico
Solicitar a criação do novo
cinema

Fim
Fluxos alternativos
A1: em {Valida entrada} Se o usuário fornecer uma entrada incorreta,
informá-lo sobre o erro e retornar ao campo
incorreto.
A2: em {Solicita Cancelamen- O usuário pode decidir encerrar o caso de uso
to} sem fornecer uma entrada. Nesse caso, retornar
ao fluxo básico em {Fim}
Quadro 7: Caso de Uso Cadastrar Novos Cinemas.
Fonte: autor
Cadastrar Salas
Operador
Figura 106: Cadastrar Salas
Fonte: o autor.

V
NOME DO CASO DE USO CADASTRAR SALAS

Descrição Permite inserir novas salas no sistema
Ator Operador
Pós-condições Nova sala inserida
Fluxo Básico
Solicitar a criação do nova
sala
Fim
Fluxos alternativos
incorreto.
A2: em {Solicita Cancela- O usuário pode decidir encerrar o caso de uso
mento} sem fornecer uma entrada. Nesse caso, retornar
Quadro 8: Caso de Uso Cadastrar Novas Salas.
Fonte: autor
Exibir Filme
Operador
Figura 107: Exibir Filme
Fonte: o autor.
ESTUDO DE CASO
151
NOME DO CASO DE USO EXIBIR FILME

Descrição Permite colocar um filme em exibição
Ator Operador
Pós-condições Status de exibição alterado
Fluxo Básico
Solicitar a exibição do filme
Abre a Janela de Movimentação (A2)

Usuário altera o status
Sistema solicita horário de exibição
Usuário informa o horário de
exibição
Fim
Fluxos alternativos
incorreto.
A2: em {Solicita O usuário pode decidir encerrar o caso de uso
Cancelamento} sem fornecer uma entrada. Nesse caso, retornar
Quadro 9: Caso de Uso Exibir Filmes.
Fonte: autor
Suspender exibição
de filme
Operador
Figura 108: Suspender filme
Fonte: o autor.

V
NOME DO CASO DE USO SUSPENDER A EXIBIÇÃO DO FILME

Descrição Permite suspender a exibição do filme no sistema
Ator Operador
Pós-condições Suspensão da exibição do filme
Fluxo Básico
Solicitar a suspensão
de exibição
Abre a Janela de Movimentação (A2)
Usuário informa o
filme
Usuário altera o status
Fim
Fluxos alternativos
A1: em {Valida entra- Se o usuário fornecer uma entrada incorreta, informá-lo
da} sobre o erro e retornar ao campo incorreto
A2: em {Solicita Cance- O usuário pode decidir encerrar o caso de uso sem for-
lamento} necer uma entrada. Nesse caso, retornar ao fluxo básico
em {Fim}
Quadro 10: Caso de Uso Suspender a Exibição de Filmes.
Fonte: autor
O que fizemos até agora?

■■ Levantamos os requisitos do sistema.
■■ Elaboramos o diagrama de caso de uso.
■■ Elaboramos a descrição de cada um dos casos de uso.
O que falta para terminar?

■■ Elaborar o diagrama de classes.
ESTUDO DE CASO
153
■■ Elaborar o diagrama de sequência.

■■ Elaborar o diagrama de colaboração.
■■ Elaborar o diagrama de estado.
DIAGRAMA DE CLASSES
Após o levantamento de requisitos, juntamente com sua especificação, podemos

elaborar o diagrama de classes, pois já contamos com subsídios suficientes após
a criação do cenário do sistema.
Para relembrarmos, o diagrama de classes modela a estrutura estática do
sistema. Uma classe é uma estrutura que modela um conjunto de objetos cujas
características sejam similares. O comportamento é modelado por meio dos
métodos, e os possíveis estados do objeto, são modelados mediante atributos.
Verificando o diagrama de caso de uso, podemos levantar as classes: usuário,
filme, elenco, cinema, sala. Vamos definir seus principais atributos de acordo com
o estudo de caso. Leia o estudo de caso novamente para compreender melhor.
Na classe usuário, precisamos registrar o nome do usuário, sua senha e per-
missões de acesso.
Na classe filme, precisamos registrar seu título, duração e indicação
(impropriedade).
Na classe elenco, precisamos registrar o nome do diretor/ator, a data de nas-
cimento e nacionalidade.
Na classe cinema, precisamos registrar o nome do cinema, endereço, lota-
ção, bairro e CEP.
Na classe salas, precisamos registrar o cinema ao qual ela pertence, o filme
que está sendo exibido no momento, horário de exibição e capacidade.
A primeira versão do diagrama de classes ficará de acordo com a figura 109.
Diagrama de Classes
V
Cinema Filme
- Cinema_id: int - Filme_id: int
- Nome: String - Título: String
- Endereço: String - Curação: String
- Lotação: int - Indicação: int
- Bairro: String - Status: String
- Cidade: String
- UF: String - Inserir( ): void
- CEP: String - Cancelar( ): void
- Inserir( ): void
- Cancelar( ): void
Elenco
Sala
- Elenco_id: int
- Sala_id: int - Nome: String
- Horário: String - Data de Nascimento: Date
- Capacidade: String - Nacionalidade: String
- Inserir( ): void - Inserir( ): void
- Cancelar( ): void - Cancelar( ): void
Figura 109: Diagrama de Classes - Versão 1.0

Fonte: o autor.
Como podem ter percebido, o nosso diagrama de classes está sem as associações,
vamos completá-lo, então, com as associações e multiplicidades.
Vamos começar pela classe cinema. Cinema não tem uma associação direta
com filmes, porque filmes são exibidos em salas. Também não tem uma relação
direta com elenco, porque elenco faz parte do filme. Porém, com salas, o cinema
associa, uma vez que o cinema é composto por salas. Olha que interessante, subli-
nhei a palavra composto para indicar que, se não existir cinema, também não
existirá a sala, portanto, a associação é de agregação por composição.
Já vamos aproveitar para definir a multiplicidade para associação fazendo
uma pergunta em duas direções:
■■ Um cinema é composto de quantas salas?
• Resposta: por uma ou várias.
■■ Uma sala compõe quantos cinemas?
• Resposta: somente um.
Sendo assim, nosso diagrama ficou como mostrado na figura 110, observe que
na agregação por composição o losango é preenchido.
ESTUDO DE CASO
155
Cinema Sala
- Cinema_id: int - Sala_id: int
- Nome: String - Horário: String
- Endereço: String 1 1...” - Capacidade: String
- Lotação: int
- Bairro: String - Inserir( ): void
- Cidade: String - Cancelar( ): void
- UF: String
- CEP: String
- Inserir( ): void
- Cancelar( ): void
Figura 110: Associação por agregação

Fonte: o autor.
Agora, vamos verificar a associação entre sala e filme, uma vez que os filmes são
projetados nas salas. Essa é uma associação simples, pois tanto os objetos da
classe filme quanto os objetos da classe sala não dependem do outro para exis-
tir. Vamos fazer aquelas perguntinhas para verificar a multiplicidade:
■■ Uma Sala pode exibir quantos filmes?
• Somente 1.
■■ Um filme pode estar sendo exibido em quantas salas?
• Em nenhuma ou em várias.
Cinema Sala Filme

- Cinema_id: int - Sala_id: int - Filme_id: int
- Nome: String - Horário: String - Título: String
- Endereço: String 1 1...” - Capacidade: String 0..” 1 - Curação: String
- Bairro: String - Inserir( ): void - Status: String
- Inserir( ): void
- Cancelar( ): void
Figura 111: Associação por agregação e simples

Fonte: o autor.
Vamos para a última associação entre filme e elenco. Nós sabemos que um
ator pode atuar em vários filmes e que um filme por ter vários atores. Podemos
Diagrama de Classes
V
verificar, então, que a multiplicidade para essa associação é de vários(n) para

vários(n). Quando temos uma multiplicidade “n” para “n”, obrigatoriamente,
devemos criar uma entidade associativa. Dessa forma, podemos conferir a ver-
são final do nosso diagrama de classes na figura 112.
Cinema Sala Filme

- Cinema_id: int - Sala_id: int - Filme_id: int
- Nome: String - Horário: String - Título: String
- Endereço: String 1 1...” - Capacidade: String 0..” 1 - Curação: String
- Bairro: String - Inserir( ): void - Status: String
- Inserir( ): void Ator
- Cancelar( ): void
Ator
Elenco
- Elenco_id: int
- Nome: String
- Data de Nascimento: Date
- Nacionalidade: String
- Inserir( ): void
- Cancelar( ): void
Figura 112: Diagrama de Classes versão final

Fonte: o autor.
Vamos elaborar, agora, o diagrama de sequência. Lembre-se de que a utilidade

desse diagrama é estudar as interações entre os objetos, possibilitando a identi-
ficação de relação entre as classes, servindo para refinar o diagrama de classes.
Pode ser que ocorram mudanças nas classes após a análise do diagrama de
sequência, mas também pode ser que não ocorra nenhuma mudança significa-
tiva. Porém o objetivo é estudar as interações de forma mais profunda.
Vamos iniciar pelo caso de uso “Cadastrar Filme”, vamos verificar toda a
sequência de mensagens entre os objetos até a conclusão do cadastro.
ESTUDO DE CASO
157
Nesse caso de uso, o operador solicita a inserção de uma nova instância para
a classe filme, a classe verifica se a entrada está correta, salva os dados e retorna
um ok para o operador.
Filme
Operador
1: Solicita Inserir ( )
2: Verifica entrada ( )
3: Salva Dados ( )
4: OK ( )
Figura 113: Diagrama de sequência para inserir filme

Fonte: o autor.
O próximo diagrama de sequência é para o caso de uso “Cadastrar Cinema”.

Nesse caso de uso, o operador solicita a inserção de uma nova instância para a
classe cinema, a classe verifica se a entrada está correta, salva os dados e retorna
um ok para o operador.
V
Cinema
Operador
3: Salva Dados ( )
4: OK ( )
Figura 114: Diagrama de sequência para cadastrar cinema

Fonte: o autor.
O próximo diagrama de sequência é para o caso de uso “Cadastrar Elenco”. Nesse

caso de uso, o operador solicita a inserção de uma nova instância para a classe
elenco, a classe verifica se a entrada está correta, salva os dados, informa o filme
no qual atua como ator, verifica se o filme existe, salva os dados e retorna um
ok para o operador.

ESTUDO DE CASO
159
Elenco Ator Filme
Operador
3: Salva os dados ( )
4: Informa Filme ( )
5: Verifica Filme ( )
5.1: OK ( )
6: Salva os dados ( )
7: OK( )
8: OK( )
Figura 115: Diagrama de sequência para inserir elenco

Fonte: o autor.
O próximo diagrama de sequência é para o caso de uso “Cadastrar Sala”. Nesse

caso de uso, o operador solicita a inserção de uma nova instância para a classe
sala, a classe verifica se a entrada está correta, verifica se o cinema para aquela
sala existe, salva os dados e retorna um ok para o operador.
V
Sala Cinema
Operador
3: Verifica Cinema ( )
3.1: OK ( )
4: Salva Dados ( )
5: OK ( )
Figura 116: Diagrama de sequência para cadastrar sala

Fonte: o autor.
O próximo diagrama de sequência é para o caso de uso “Exibir Filme”. Nesse caso
de uso, o operador solicita a edição de uma instância da classe sala para informar
qual filme está sendo exibido, o sistema verifica o status do filme e altera para em
exibição. O sistema solicita o horário para a exibição, verifica a entrada e salva.
ESTUDO DE CASO
161
Sala Filme
Operador
1: Solicita Exibição ( )
3: Verifica Status ( ) 3.1: Altera Status ( )
3.2: OK ( )
4: Solicita Horário ( )
5: Informa Horário ( )
6: Verifica Entrada ( )
7: Salva Dados ( )
8: OK ( )
Figura 117: Diagrama de Sequência para exibir filme

Fonte: o autor.
O próximo diagrama de sequência é para o caso de uso “Suspender a Exibição

do Filme”. Nesse caso de uso, o operador solicita a suspensão do filme, o sistema
solicita qual filme, o operador informa o filme, o sistema altera o status para sus-
penso e exclui de todas as salas que estão sendo exibidas.
V
Filme Sala
Operador
1: Solicita Suspensão ( )
2: Solicita Filme ( )
2.1: Informa Filme ( )
3: Altera Status ( )
4: Exclui Filme( )
5: Salva Dados ( )
6: OK ( )
7: OK ( )
Figura 118: Diagrama de sequência para suspender a exibição do filme

Fonte: o autor.
DIAGRAMA DE ESTADO
Vamos para a confecção, agora, do diagrama de estado. Esse diagrama representa

o comportamento interno da classe, permitindo a especificação de sua dinâ-
mica. Não precisaremos de um diagrama para cada classe ou cada caso de uso,
somente as classes que possuem um número finito de estados conhecidos têm a
necessidade de uma representação por um diagrama de estado.
Dessa forma, conseguimos prever os possíveis comportamentos de um objeto
por meio da análise da mudança de estados dos tipos de objetos de um sistema.
O objeto, normalmente, tem um estado que é determinado por um atributo da
classe daquele objeto.
Em nosso estudo de caso, a classe Filme tem um estado que é modelado
por um atributo denominado “Status”, seu tipo de dado é string, o que significa
que esse atributo aceita como valor uma cadeia genérica de caractere (letras,
ESTUDO DE CASO
163
números, símbolos).
Por meio do atributo “status” é possível colocar o filme em dois estados dife-
rentes (“exibindo”, “suspenso”). Portanto, modelaremos o diagrama de estado
somente para a classe Filme.
O diagrama de estado da figura 119 nos mostra que, caso o objeto esteja
no estado “SUSPENSO”, seu estado será modificado para “EXIBINDO” e fina-
liza. Porém, se o status já for “EXIBINDO”, então o objeto não sofrerá nenhuma
alteração.
O início é marcado pela notação do círculo preenchido, os estados possíveis
estão sendo identificados pela notação do retângulo com cantos arredondados.

O losango indica um estado de escolha, em que deve ser verificado o estado atual
do objeto para decidir se muda seu valor ou não.
SUSPENSO
do / atualiza
Status = “SUSPENSO”
Status = “EXIBINDO”
EXIBINDO
exit / gravar
Figura 119: Estado inicial SUSPENSO

Fonte: o autor.
O diagrama de estado da figura 120 nos mostra o caso contrário, ou seja,

caso o objeto esteja no estado “EXIBINDO”, seu estado será modificado para
“SUSPENSO” E finaliza. Porém, se o status já for “SUSPENSO”, então, o objeto
não sofrerá nenhuma alteração.
Diagrama de Estado
V
EXIBINDO
do / atualiza
Status = “EXIBINDO”
Status = “SUSPENSO”
SUSPENSO
exit / gravar
Figura 120: Estado inicial EXIBINDO

Fonte: o autor.
Finalmente, vamos para a confecção do nosso último diagrama. O diagrama de

comunicação nos permite representar o cenário de outra forma. Ele considera a
ordem com que ocorre a comunicação, sem se preocupar com o tempo em que
ocorre, pois, considerando o tempo, já modelamos no diagrama de sequência.
O diagrama de comunicação identifica as classes mais próximas e a ordem
de envio de mensagens que é identificada por números sequenciais, mostrando
a interação de forma organizada em torno dos objetos.
A figura 121 apresenta diagrama de comunicação para cadastrar um novo
filme. O operador insere novos dados para o filme, os dados são validados e sal-
vos pela classe, e retorna uma mensagem de confirmação da operação para o
operador.
ESTUDO DE CASO
165
2: Valida ( )
3: Salva ( )
1: Insere ( )( )
Filme
Operador
4: OK ( )
Figura 121: Cadastrar Filmes

Fonte: o autor.
A figura 122 apresenta diagrama de comunicação para cadastrar um novo cinema.

O operador insere novos dados para o cinema, os dados são validados e salvos pela
classe, e retorna uma mensagem de confirmação da operação para o operador.
2: Valida ( )
3: Salva ( )
1: Insere ( )( )
Cinema
Operador 4: OK ( )
Figura 122: Diagrama de comunicação para cadastrar cinema

Fonte: o autor.
A figura 123 apresenta diagrama de comunicação para cadastrar um novo elenco.

O operador insere novos dados para o elenco, os dados são validados e salvos
pela classe, que envia uma mensagem para a classe ator informando qual filme
aquele elenco participa como ator.
V
2: Valida ( )
3: Salva ( )
1: Insere ( )( ) 4: Informa Filme ( ) 5: Verifica Cinema ( )
Elenco Ator Filme

Operador 8: OK ( ) 7: OK ( ) 6: OK ( )
Figura 123: Diagrama de comunicação para inserir elenco
Fonte: o autor.
A figura 124 apresenta diagrama de comunicação para cadastrar novas salas. O

operador insere novos dados para a sala, os dados são validados pela classe, que
envia uma mensagem para a classe cinema, verificando a existência do cinema,
que retorna uma confirmação para classe sala, que salva os dados e confirma a
operação para o operador.
5: Salva ( )
1: Insere ( )[ ] 3: Verifica Cinema ( )
Sala Cinema
Operador 6: OK ( ) 4: OK ( )
Figura 124: Diagrama de comunicação para inserir novas salas

Fonte: o autor.
A figura 125 apresenta o diagrama de comunicação para colocar o filme em exi-

bição. O operador insere novos dados para a sala, os dados são validados pela
classe, que envia uma mensagem para a classe cinema, verificando a existência
do cinema, que retorna uma confirmação para classe sala e solicita o horário ao
operador que por sua vez informa o horário em seguida a entrada é verificada,
então os dados são salvos e a operação é confirmada para o operador.
ESTUDO DE CASO
167
2: Verifica Exibição ( )
9: Salva ( ) 4: Altera Status ( )
1: Solicita Exibição ( ) 3: Verifica Cinema ( )
Sala Cinema
Operador
6: Solicita Horário ( ) 5: OK ( )
7: Informa Horário ( )
10: OK ( )
Figura 125: Diagrama de comunicação para exibição do filme

Fonte: o autor.
A figura 126 apresenta um diagrama de comunicação para suspender a exibição

de filme. O operador insere novos dados para a sala, os dados são validados pela
classe, que envia uma mensagem para a classe cinema, verificando a existência
do cinema, que retorna uma confirmação para classe sala e solicita o horário ao
operador que por sua vez informa o horário em seguida a entrada é verificada,
então os dados são salvos e a operação é confirmada para o operador.
4: Altera Status ( ) 6: Salva ( )
1: Solicita Suspensão ( ) 5: Exclui Filme ( )
Filme Sala
Operador
2: Solicita Filme ( ) 7: OK ( )
3: Informa Filme ( )
8: OK ( )
Figura 126: Diagrama de comunicação para suspender a exibição do filme
Fonte: o autor.
V
Nesta unidade, aprendemos como usar uma ferramenta CASE para a modelagem
do sistema, pois, sem o suporte do aplicativo, o trabalho de análise e projeto se
torna bem mais difícil, principalmente quando necessitamos realizar alterações.
Por meio de um estudo de caso para uma distribuidora de filmes, tivemos
a oportunidade de construir os diagramas necessários para a análise e projeto,
aplicando os conceitos trabalhados de forma prática.
Familiarizamo-nos com a construção do diagrama de caso de uso. Este foi
o primeiro diagrama que criamos para o estudo de caso, justamente para criar-
mos um cenário do sistema, com ele, podemos verificar quais são os atores que
interagem com o sistema e quais tarefas cada um pode realizar no domínio.
Tivemos a oportunidade, também, de colocar em prática a confecção do dia-
grama de classes, que representa a estrutura estática do sistema. Vimos como
definir as classes, associações e multiplicidades.
Vimos, ainda, como construir o diagrama de sequência, que mostra as trocas
de mensagens entre os objetos considerando o tempo. Esse diagrama nos ser-
viu para verificar como e quando ocorrem as trocas. Alterações no diagrama de
classes são comuns após a elaboração do diagrama de sequência.
Estudamos a elaboração do diagrama de estados. Esse diagrama modela o
comportamento da classe com utilização de máquinas de estado, mostrando-nos
quais valores podem ser assumidos pelo atributo que representa o estado da classe.
Por fim, em uma tentativa de mostrar as trocas de mensagens de outra forma,
elaboramos o diagrama de colaboração. Na verdade, esse diagrama é semelhante
ao diagrama de sequência, porém não considera o tempo nas trocas de mensa-
gens, mas sim a ordem com que as mensagens ocorrem.
Chegamos ao final do nosso curso e, para desenvolvermos nossa habilidade
na análise e projeto OO, é extremamente necessária a prática, então, não perca
tempo e coloque a mão na massa. Bom trabalho e sucesso.
ESTUDO DE CASO
169
1. Elabore um diagrama de objetos para as classes cinema e sala.

2. Elabore um diagrama de implantação para o sistema da Distribuidora Fênix.
3. Elabore um diagrama de componentes para o sistema da distribuidora Fênix.
4. Elabore um diagrama de atividades para incluir um filme para exibição.
Prezado(a) aluno(a), segue uma matéria em (BOOCH et al., 1999; JACOBSON et al.,
que mostra como a Linguagem de Modela- 1999). O ambiente de projeto de moldes de
gem Unificada (UML) pode ser aplicada em injeção foi genericamente utilizado como
conjunto com o Modelo de Referência para exemplo para a representação de tais dia-
Processamento Distribuído Aberto (ISO/ gramas.
RM-ODP), para o apoio ao desenvolvimento
de sistemas de informações orientados a Diferente do RM-ODP, a UML oferece um
objetos. suporte direto para o projeto e implemen-
tação de cada perspectiva do sistema em
A LINGUAGEM DE MODELAGEM desenvolvimento e também uma notação
UNIFICADA (UML) E USE CASES para sua representação. Por esta razão, para
a sua completa utilização, torna-se necessá-
Carlos Alberto Costa rio um processo/metodologia que permita
a migração e evolução das informações
A UML (Unified Modelling Language - Lin- através das diferentes fases de represen-
guagem de Modelagem Unificada) surgiu, tação, tais como funcionalidade, análise e
nos últimos anos, da união de métodos projetos, implementação, etc. JACOBSON et
anteriores para análise e projeto de siste- al. (1999) fornecem um processo chamado
mas orientados a objetos e em 1997 passou Processo de Desenvolvimento de Software
a ser aceita e reconhecida como um padrão Unificado (UML process).
potencial de notação para modelagem de
múltiplas perspectivas de sistemas de infor- TEXEL & WILLIAMS (1997) propõem um pro-
mações pela OMG (“Object Management cesso baseado em Use Cases combinado
Group”) (BOOCH et al., 1999). Entre os méto- com Booch, OMT e UML, para o desenvol-
dos que deram origem a esta linguagem de vimento de sistemas orientados a objetos.
modelagem visual estão: Booch (BOOCH,
1994), OMT (Object Modelling Technique) Em ambos os processos, os Use Cases defi-
e OOSE (Object Oriented Software Engine- nem o primeiro nível de representação do
ering). A UML define um conjunto básico de sistema e resultam de uma fase de captura
diagramas e notações que permitem repre- das “necessidades” a serem atendidas pelo
sentar as múltiplas perspectivas (estruturais mesmo. Os Use Cases representarão, num
/ estáticas e comportamentais / dinâmicas) nível mais geral, as funcionalidades do sis-
do sistema sobre análise e desenvolvi- tema em desenvolvimento e guiarão todas
mento. Dentre os diagramas podem ser as fases subseqüentes de análise, projeto,
citados: Diagramas de Use Cases, Diagra- implementação e testes do sistema com-
mas de Classes, Diagramas de Interações putacional.
(Seqüência ou Colaboração), Diagramas de
Atividades e Diagramas de Estado e Tran- Este artigo não tem como objetivo maior
sição. As Tabela 1.1, Tabela 1.2 e Tabela explorar o processo a ser aplicado para a
1.3 descrevem brevemente alguns destes modelagem das informações, visto que
diagramas. Informações complementares se trata de um outro tópico bastante
sobre outros tipos de representações dia- abrangente. A Figura 3 mostra, de forma
gramáticas da UML podem ser encontradas simplificada, como tal processo pode ser
171
desenvolvido (TEXEL & WILLIAMS, 1997). cia. Esta fase é definida como análise do
sistema onde tais representações podem
Com base em uma descrição detalhada ser utilizadas para um melhor esclareci-
do sistema, principalmente enfocando as mento e discussão com os usuários e
expectativas dos usuários em termos de responsáveis pela implementação do sis-
“o que o sistema deveria fazer”, Use Cases tema. Numa fase seguinte, caracterizada
potenciais são extraídos, bem como as com maior ênfase no projeto do sistema,
Categorias do sistema. As Categorias (ou busca-se um refinamento destas represen-
Pacotes) são outros tipos de elementos da tações, a nível dos objetos que farão parte
UML e representam os módulos principais do sistema. Ambos os diagramas, Classes
(grupo de objetos com funcionalidade simi- e Interações são utilizados e apoiados por
lar) do sistema em desenvolvimento. Com representações mais detalhadas dos aspec-
base nestes dois elementos, uma descritos comportamentais dos objetos, através
ção geral de como as Categorias interagem de diagramas de Estado e Transição e dia-
entre si para executar cada Use Case, pode gramas de Atividades.
ser representada por diagramas de Seqüên-
Leia mais em: <http://www.scielo.br/scielo.php?script=sci_arttext&pi-
d=S0104-530X2001000100003&lng=pt&nrm=iso>. Fonte: Costa (2001, online).
Programação Orientada a Objetos com Java

David J. Barnes.
Editora: Person Prentice Hall
Sinopse: O BlueJ é um ambiente Java de desenvolvimento
que executa em cima do Sun Microsystems Java Development
Kit utilizando o compilador-padrão e a máquina virtual. Ele
foi especificamente projetado para o ensino introdutório da
programação orientada a objetos, permitindo ao aluno criar
objetos de qualquer classe e interagir com seus métodos. Essa
primeira abordagem verdadeiramente orientada a objetos
dentro do ambiente BlueJ personalizado está revolucionando a
maneira como a programação é ensinada.
Existem duas versões para a ferramenta Astah Community, a versão professional e community. Faça
o download da versão Astah Community, pois esta é gratuita e suficiente para o que precisamos.
Faça o download da ferramenta CASE para a elaboração dos diagramas estados nesse livro no link
disponível em: <http://astah.net/download>. Acesso em: 31 jul. 2015.
Caso tenha dificuldades na confecção do diagrama de caso de uso, sugiro que assistam ao vídeo da
professora Decíola Fernandes, da Universidade Rural da Amazônia. O vídeo apresenta um tutorial
de 4 minutos mostrando como usar as ferramentas. Acesse-o no link disponível em: <https://www.
youtube.com/watch?v=VMG0EOangKY>. Acesso em: 31 jul. 2015.
Para aprofundar os conhecimentos sobre OO, leia a tese intitulada “DESENVOLVIMENTO

DE UM SISTEMA COMPUTACIONAL ORIENTADO A OBJETOS PARA SISTEMAS ELÉTRICOS
DE POTÊNCIA: APLICAÇÃO A SIMULAÇÃO RÁPIDA E ANÁLISE DA ESTABILIDADE DE
TENSÃO”. Esse trabalho tem por objetivo aplicar a Modelagem Orientada a Objetos para o
desenvolvimento de uma base computacional capaz de integrar e dar suporte à construção
de um amplo conjunto de ferramentas para simulação e análise de sistemas elétricos.
Acesse o trabalho no link disponível em: <http://www.coep.ufrj.br/~tarang/Simulight/Tese_Manzoni.
pdf>. Acesso em: 31 jul. 2015.
173
CONCLUSÃO
Com esta unidade, encerramos mais uma etapa e chegamos ao final da disciplina de
Análise e Projeto Orientado a Objetos. Espero que o material tenha sido de grande
valia e que possa somar com o seu conhecimento.
O livro Análise e Projeto Orientado a Objetos foi desenvolvido para proporcionar o
contato com conceitos, ferramentas e métodos para direcioná-lo em sua vida aca-
dêmica e profissional. Procurei focar em elementos práticos e teóricos que contribu-
am para sua formação e aperfeiçoamento. Os exemplos de estudos de casos apre-
sentados são totalmente aplicáveis no dia a dia da engenharia de software.
Sabemos que a análise e o projeto de qualquer sistema, por mais simples que se-
jam, não são tarefas triviais, pois envolvem uma habilidade e perícia do analista em
permear pelas necessidades do usuário, para extrair dele o que realmente deseja
para a solução. Estabelecer domínios e levantar requisitos são atividades que exi-
gem muito do raciocínio lógico formal do analista e tal raciocínio se desenvolve com
a experiência. Este livro representa somente o primeiro passo da sua jornada rumo
ao conhecimento.
Pode ser que, em algum momento da sua caminhada ao encontro do conhecimen-
to, você se depare com dificuldades que, naquele momento, parecem insolúveis e te
desmotivem, talvez, faça você até pensar em desistir, porém a persistência o levará a
solução, por isso, insista e nunca desista, todo problema tem solução, você somente
ainda não a encontrou.
Para os(as) futuros(as) engenheiros(as) de software, fica a dica de leituras dos livros
mencionados no final de cada unidade. São apresentadas situações de análise, pro-
jeto e desenvolvimento que serão muito úteis em sua vida profissional.
Um grande abraço, saúde, paz e luz na sua caminhada.
175
REFERÊNCIAS
BOOCH, G. Object-oriented Analysis and Design. San Francisco-EUA: Editora

Benjamin/ Cummings, 1997.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. Uml - Guia do Usuário. Rio de Janeiro:
Editora: Campus, 2000.
COAD, P.; YOURDON, E. Análise Baseada em Objetos. Rio de Janeiro: Editora
Campos, 1992.
COLEMAN, D. Desenvolvimento Orientado a Objetos: o Método Fusion. Rio de
Janeiro: Editora: Campus, 1996.
COSTA, C. A. A aplicação da Linguagem de Modelagem Unificada (UML) para o su-
porte ao projeto de sistemas computacionais dentro de um modelo de referência.
Gest. Prod., v.8, n.1, São Carlos, abr. 2001. Disponível em: <http://www.scielo.br/
scielo.php?script=sci_arttext&pid=S0104-530X2001000100003&lng=pt&nrm=i-
so>.
JACOBSON, I. Object Oriented Software Engineering. Boston-EUA: Addison-Wes-
ley. 1995.
LEE, R. C.; TEPFENHART, W. M. UML e C++: Guia Prático de Desenvolvimento Orien-
tado a Objetos. São Paulo: Pearson Prentice Hall, 2002.
MARTIN, J.; ODELL, J. J. Análise e Projeto Orientados a Objeto. São Paulo: Editora:
Makron, 1995
MEDEIROS, E. S. de. Desenvolvendo software com UML 2.0: definitivo. São Paulo:
Pearson Makron Books, 2004.
MORAES, M. B. da C.; NAGANO, M. S. Sistemas de informação contábeis: uma abor-
dagem orientada a objetos com agentes inteligentes. JISTEM J.Inf.Syst. Technol.
Manag (online), v. 6, n. 3, São Paulo, 2009. Disponível em: <http://www.scielo.br/
scielo.php?script=sci_arttext&pid=S1807-17752009000300005&lng=pt&nrm=iso>.
Acesso em: 30 jul. 2015.
REIS, A. F. dos; COSTA, I. da. Proposta de integração da engenharia de softwa-
re nas estratégias empresariais. Production, v.15 n.3. São Paulo, sept./dec.
2005. Disponível em: <http://www.scielo.br/scielo.php?script=sci_arttext&pi-
d=S0103-65132005000300013&lang=pt>. Acesso em: 29 jul. 2015.
RUMBAUGH, J. Object Oriented Modeling and Design. New Jersey-EUA: Editora:
Prentice Hall, 1991.
SHLAER, S.; MELLOR, S.J. Análise de Sistemas Orientada a Objetos. São Paulo:
Editora Makron Books, 1990.
REFERÊNCIAS
SILVA, R. P. Avaliação das metodologias de análise e projeto orientadas a obje-

tos voltadas ao desenvolvimento de aplicações, sob a ótica de sua utilização
no desenvolvimento de frameworks orientados a objetos. UFRGS, Rio Grande
do Sul, 1996. Disponível em: <http://www.inf.ufsc.br/~ricardo/download/metodo-
logiasOOAD.pdf>. Acesso em: 31 jul. 2015.
SILVA, E. E. da. Como fazer um plano de testes baseado em casos de uso. Linha de
Código. Disponível em: <http://www.linhadecodigo.com.br/artigo/2958/como-fa-
zer-um-plano-de-testes-baseado-em-casos-de-uso.aspx#ixzz3fJNU7NrE>. Acesso
em: 29 jul. 2015.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall,
2011.
YOURDON, E. Análise Estruturada Moderna. Rio de Janeiro: Campus, 1990.

Análise e Projeto Orientado A Objetos

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Análise e Projeto Orientado A Objetos

Enviado por

Direitos autorais:

Formatos disponíveis

ANÁLISE E

Professor Me. Déverson Rogério Rando

NEAD - Núcleo de Educação a Distância

CDD - 22 ed. 005.1

Ficha catalográfica elaborada pelo bibliotecário

Professor Me. Déverson Rogério Rando

ANÁLISE E PROJETO ORIENTADO A OBJETOS

Por fim, na unidade V, resolveremos, juntos, um estudo de caso, no qual teremos a

INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS

16 Introdução À Orientação A Objetos

19 Evolução Dos Métodos OO

21 Conceitos Básicos De OO

27 Principais Diagramas da UML

48 Fases da Análise e do Projeto

63 Diagrama de Casos de Uso

79 Notação Para Classes

DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO

110 Avançando nos Diagramas

112 Diagrama de Sequência

120 Diagrama de Estados

125 Diagrama de Comunicação 

129 Considerações Finais

138 Ferramentas Case

139 Estudo de Caso

142 Diagrama de Caso de Uso

153 Diagrama de Classes

156 Diagrama de Sequência

162 Diagrama de Estado

164 Diagrama de Comunicação

168 Considerações Finais

Caro(a) aluno(a), iniciamos a primeira unidade do livro Análise e Projeto

tivo entre analistas de sistemas e usuários.

INTRODUÇÃO À ORIENTAÇÃO A OBJETOS

O processo de desenvolvimento de um sistema computacional tem na análise

INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS

Na década de 80, houve preponderância dos métodos estruturados para o desen-

Os diagramas que apoiam a análise e projeto estruturado são:

O DER modela a estrutura de dados parados, ou seja, é o modelo conceitual do

Introdução À Orientação A Objetos

contém tanto a estrutura dos dados como o comportamento deles. A orientação

INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS

EVOLUÇÃO DOS MÉTODOS OO

Os métodos de análise e projeto orientado a objetos surgiram assim que as lingua-

como a de Shlaer-Mellor. Buscava-se com a criação da UML uma padronização

Evolução Dos Métodos OO

Martin e Odell (1995): abrange as fases de análise e projeto. Propõe o uso

INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS

Conheceremos, a seguir, os principais termos e conceitos utilizados na análise

Figura 1: Objetos Concretos Figura 2: Objetos Abstratos

■■ Abstração: abstraímos quando definimos um objeto conceitual partindo

Figura 3: Abstração de Bolsa Figura 4: Abstração de avião

Figura 5: Abstração de Esporte

Figura 6: Classe Funcionário

■■ Instância: é cada umas das ocorrências de um OBJETO formado a par-

Figura 7: Classe e Objetos

■■ Atributo: é uma característica particular que os OBJETOS de uma CLASSE

Figura 8: Classe, objeto e valor

■■ Mensagem: representa o mecanismo de chamada de uma OPERAÇÃO.

Figura 10: Mensagem

■■ Evento: é um tipo especial de OPERAÇÃO que faz com que os OBJETOS

Figura 11: Evento

■■ Parâmetro: é um ou mais ATRIBUTOS que são carregados para dentro

16 Introdução À Orientação A Objetos

19 Evolução Dos Métodos OO

21 Conceitos Básicos De OO

27 Principais Diagramas da UML

48 Fases da Análise e do Projeto

63 Diagrama de Casos de Uso

79 Notação Para Classes

110 Avançando nos Diagramas

112 Diagrama de Sequência

120 Diagrama de Estados

125 Diagrama de Comunicação

129 Considerações Finais

138 Ferramentas Case

139 Estudo de Caso

142 Diagrama de Caso de Uso

153 Diagrama de Classes

156 Diagrama de Sequência

162 Diagrama de Estado

164 Diagrama de Comunicação

168 Considerações Finais