Livro - Analise de Projetos OO

ANÁLISE E PROJETO
ORIENTADO
A OBJETOS
PROFESSORES
Me. Déverson Rogério Rando
Esp. Janaína Aparecida de Freitas
ACESSE AQUI
O SEU LIVRO
NA VERSÃO
DIGITAL!
EXPEDIENTE
DIREÇÃ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 Executivo de EAD William Victor Kendrick de Matos Silva Pró-Reitor de Ensino
de EAD Janes Fidélis Tomelin Presidente da Mantenedora Cláudio Ferdinandi
NEAD - NÚCLEO DE EDUCAÇÃO A DISTÂNCIA

Diretoria Executiva Chrystiano Mincoﬀ, James Prestes, Tiago Stachon Diretoria de Design Educacional
Débora Leite Diretoria Diretoria de Graduação e Pós-graduação Kátia Coelho Diretoria de Permanência
Leonardo Spaine Head de Curadoria e Inovação Tania Cristiane Yoshie Fukushima Head de Produção de
Conteúdo Franklin Portela Correia Gerência de Contratos e Operações Jislaine Cristina da Silva Gerência de
Produção de Conteúdo Diogo Ribeiro Garcia Gerência de Projetos Especiais Daniel Fuverki Hey Supervisora
de Projetos Especiais Yasminn Talyta Tavares Zagonel Supervisora de Produção de Conteúdo Daniele C.
Correia
FICHA CATALOGRÁFICA
Coordenador(a) de Conteúdo
Flavia Lumi Matuzawa
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ.
Projeto Gráfico e Capa
Núcleo de Educação a Distância. RANDO, Déverson Rogério;
Arthur Cantareli, Jhonny Coelho FREITAS, Janaína Aparecida de.
e Thayla Guimarães
Análise e Projeto Orientado a Objetos.
Editoração Déverson Rogério Rando; Janaína Aparecida de Freitas.
Flávia Thaís Pedroso
Design Educacional Maringá - PR.: UniCesumar, 2020. Reimpresso em 2023.
Paulo Victor Souza e Silva 176 p.
Revisão Textual “Graduação - EaD”.
Carla Cristina Farinha e 1. Análise 2. Projeto Orientado a Objeto 3. Informática. EaD.
Ariane Andrade Fabreti I. Título.
Ilustração
Bruno Pardinho e André Azevedo
Fotos CDD - 22 ed. 005.1
CIP - NBR 12899 - AACR/2
Shutterstock Impresso por:
978-85-459-0113-6
Bibliotecário: João Vivaldo de Souza CRB- 9-1679
NEAD - Núcleo de Educação a Distância

Av. Guedner, 1610, Bloco 4Jd. Aclimação - Cep 87050-900 | Maringá - Paraná
www.unicesumar.edu.br | 0800 600 6360
BOAS-VINDAS
Neste mundo globalizado e dinâmico, nós tra-

balhamos com princípios éticos e profissiona-
lismo, não somente para oferecer educação de Tudo isso para honrarmos a nossa mis-
qualidade, como, acima de tudo, gerar a con- são, que é promover a educação de qua-
versão integral das pessoas ao conhecimento. lidade nas diferentes áreas do conheci-
Baseamo-nos em 4 pilares: intelectual, profis- mento, formando profissionais cidadãos
sional, emocional e espiritual. que contribuam para o desenvolvimento

de uma sociedade justa e solidária.
Assim, iniciamos a Unicesumar em 1990, com
dois cursos de graduação e 180 alunos. Hoje,
temos mais de 100 mil estudantes espalhados
em todo o Brasil, nos quatro campi presenciais
(Maringá, Londrina, Curitiba e Ponta Grossa) e
em mais de 500 polos de educação a distância
espalhados por todos os estados do Brasil e,
também, no exterior, com dezenas de cursos
de graduação e pós-graduação. Por ano, pro-
duzimos e revisamos 500 livros e distribuímos
mais de 500 mil exemplares. Somos reconhe-
cidos pelo MEC como uma instituição de exce-
lência, com IGC 4 por sete anos consecutivos
e estamos entre os 10 maiores grupos educa-
cionais do Brasil.
A rapidez do mundo moderno exige dos edu-

cadores soluções inteligentes para as neces-
sidades de todos. Para continuar relevante, a
instituição de educação precisa ter, pelo menos,
três virtudes: inovação, coragem e compromis-
so com a qualidade. Por isso, desenvolvemos,
para os cursos de Engenharia, metodologias ati-
vas, as quais visam reunir o melhor do ensino
presencial e a distância.
Reitor
Wilson de Matos Silva
TRAJETÓRIA PROFISSIONAL

Mestre em Ciência da Computação pela Universidade Estadual de Maringá (UEM). Es-
pecialista em Engenharia de Software pela Universidade Norte do Paraná. Graduado
em Geografia pela Universidade Estadual de Londrina e Análise e Desenvolvimento
de Sistemas pela Unicesumar. 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 disci-
plinas 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 e Trabalho de Conclusão de Curso.
http://lattes.cnpq.br/3108532655755995

Possui graduação em Informática pela Universidade Estadual de Maringá (2010) e
especialização em MBA em Teste de Software pela Unicesumar (2012). Atualmente,
cursa o Programa de Mestrado em Ciência da Computação na Universidade Estadual
de Maringá (UEM) e é graduanda de Letras – Português/Inglês na Unicesumar. Atua,
há três anos, como professora mediadora, professora conteudista em gravação de
aulas ao vivo e conceituais nos cursos do NEAD – Núcleo de Educação a Distância,
da Unicesumar, para os cursos de graduação de Sistemas para Internet, Análise e
Desenvolvimento de Sistemas, Gestão da Tecnologia da Informação e Engenharia
de Software, nas disciplinas de Engenharia de Software, Design Gráfico, Tópicos
Especiais, Gerenciamento de Software, Design de Interação Humano-Computador,
Projeto de Implementação e Teste de Software. Além disso, tem experiência em
iniciativa privada na área de Análise de Sistemas e Testes de Software.
http://lattes.cnpq.br/4906244382612830
A P R E S E N TA Ç Ã O DA DISCIPLINA
ANÁLISE E PROJETO ORIENTADO A OBJETOS
Caro(a) aluno(a)! Seja bem-vindo(a) à disciplina de Análise e Projeto Orientado a Objetos (OO).
Esta disciplina abordará vários aspectos relacionados à análise e ao projeto de sistemas orien-
tados a objetos, utilizando, como notação, a linguagem de modelagem UML. Apresentamos
a você, aluno(a), o livro que conduzirá seus estudos, auxiliando no aprendizado de análise e
projeto orientado a objetos com a UML.
A Unidade 1 apresenta os conceitos iniciais sobre a análise e os projetos orientados a objetos.

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, conheceremos os con-
ceitos básicos que envolvem a Orientação a Objetos para dar subsídio às unidades subse-
quentes. E, por fim, veremos os principais diagramas da UML utilizados na documentação
de software.
Na Unidade 2, estudaremos as fases que compreendem a análise e o projeto de um software.

Entraremos em contato com dois dos modelos de processos: cascata e evolucionário. Vere-
mos as vantagens e desvantagens da utilização de cada um desses métodos, abordaremos,
também, os requisitos de software e conheceremos os procedimentos mínimos para a obten-
ção de um software de qualidade. Encerraremos a unidade falando 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 3 é toda dedicada à confecção do diagrama de classes responsável por demons-

trar a estrutura estática do sistema. Conheceremos, em detalhes, a notação para o diagrama
de classes. Abordaremos os conceitos e a assinatura da declaração de atributos e métodos.
Veremos como ocorrem as ligações entre as classes e como definir a multiplicidade entre
elas. Discutiremos, ainda, as várias formas de associar as classes, sejam elas unária, binária,
ternária, sejam elas associativa, de agregação ou generalização.
A P R E S E N TA Ç Ã O DA DISCIPLINA
Na Unidade 4, conheceremos mais três diagramas, essenciais em análise e projeto OO, que
utilizaremos para refinar o diagrama de classes que representa a estrutura do sistema. O
primeiro diagrama que veremos, nesta unidade, é o de sequência, cujo objetivo é estudar as
interações entre os objetos, considerando a dimensão tempo. O segundo diagrama que ve-
remos é o de estados, que tem como objetivo especificar 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 do diagrama de sequência, porém não considera o tempo,
e sim a ordem da comunicação.
Por fim, na Unidade 5, resolveremos, juntos, um estudo de caso, no qual teremos a oportu-
nidade de apresentar, de forma prática, a construção dos diagramas citados na elaboração
da análise e do projeto de um software. Dessa forma, reforçaremos todos os conceitos tra-
balhados nas unidades anteriores.
Ao longo deste livro, você encontrará indicações de leitura complementar, as quais enrique-
cerão o seu conhecimento sobre projetos. É importante que você desenvolva as atividades de
estudo para fixar o conteúdo abordado e identificar eventuais dificuldades. Preparados(as)?
Vamos lá!
ÍCONES
pensando juntos
Ao longo do livro, você será convidado(a) a refletir, questionar e

transformar. Aproveite este momento!
explorando ideias
Neste elemento, você fará uma pausa para conhecer um pouco

mais sobre o assunto em estudo e aprenderá novos conceitos.
quadro-resumo
No fim da unidade, o tema em estudo aparecerá de forma resumida

para ajudar você a fixar e a memorizar melhor os conceitos aprendidos.
conceituando
Sabe aquela palavra ou aquele termo que você não conhece? Este ele-
mento ajudará você a conceituá-la(o) melhor da maneira mais simples.
conecte-se
Enquanto estuda, você encontrará conteúdos relevantes

online e aprenderá de maneira interativa usando a tecno-
logia a seu favor.
Quando identificar o ícone de QR-CODE, utilize o aplicativo Unicesumar

Experience para ter acesso aos conteúdos online. O download do aplicativo
está disponível nas plataformas: Google Play App Store
CONTEÚDO
PROGRAMÁTICO
UNIDADE 01
10 UNIDADE 02
40
INTRODUÇÃO CASOS DE USO
AO ESTUDO DE
ORIENTAÇÃO A
OBJETOS
UNIDADE 03
70 UNIDADE 04
102
DIAGRAMA DE DIAGRAMAS DE
CLASSES SEQUÊNCIA, ESTADO
E COLABORAÇÃO
UNIDADE 05
130 FECHAMENTO
168
ESTUDO DE CASO CONCLUSÃO GERAL
1
INTRODUÇÃO
AO ESTUDO
de orientação a objetos
PROFESSORES
PLANO DE ESTUDO
A seguir, apresentam-se as aulas 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.
OBJETIVOS DE APRENDIZAGEM
Entender a importância de análise e projeto • Conhecer a evolução dos métodos OO • Compreender as
características dos métodos OO e seus diferentes termos • Conhecer os principais diagramas da UML.
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
desenvolvimento de software. É nessa fase que determinamos e especifi-
camos 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 colaborativo entre analistas de sistemas e usuários.
Em seguida, veremos como os métodos surgiram e como aconteceu sua
evolução. Abordaremos, a partir do primeiro método orientado a objetos,
proposto por Shlaer e Mellor em 1988, o OOSA, até chegarmos à Unified
Modeling Language, UML, que será a linguagem que utilizaremos para as
nossas análises e nossos 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
métodos que serão apresentados. Ou seja, a evolução de todos os outros
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 termos utilizados na análise e no projeto OO. Dentre os conceitos que
veremos, estão os de objeto, abstração, classe, instância, atributo, operação,
mensagem, evento, estado e parâmetro. 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 dia-
grama de classes que modela a estrutura estática do sistema, o diagrama
de sequência, o de colaboração e o de estado.
Então, o que estamos esperando? Vamos ao trabalho?
Boa leitura a todos.
1
INTRODUÇÃO
UNIDADE 1
À ORIENTAÇÃO
a objetos
ANÁLISE E PROJETO
O processo de desenvolvimento de um sistema computacional tem, na análise,

sua atividade inicial. Atividade esta 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
do respectivo ambiente.
De acordo com Sommerville (2011), podemos chamar de “análise de sistemas”
o que faz parte da “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
destes, por ser uma etapa inicial e, também, porque as falhas terão efeitos em
cadeia nas etapas subsequentes, assim como no produto final. A determinação
incorreta dos requisitos levará à obtenção e à disponibilização de sistemas com-
putacionais inadequados.
12
Resumindo: a análise é a solução conceitual dada ao problema. Marca o início
UNICESUMAR
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 utilizados.
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 consiste na solução computacional aplicada ao
problema. Dizer onde acaba a análise e se inicia o projeto é muito complicado,
uma vez que o projeto é o resultado de refinamentos sucessivos do modelo con-
ceitual de análise.
A Orientação a Objetos fez com que fosse alterado o enfoque necessário
para desenvolver um sistema, enquanto que, na programação estruturada, havia,
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 tratá-los, 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 entre 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 é compreendi-
do 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 o projeto estruturado são:

■ Diagrama Entidade e Relacionamento (DER).
■ Dicionários de dados.
■ Diagrama de Fluxo de Dados (DFD).
13
O DER modela a estrutura de dados parados, ou seja, é o modelo conceitual do
UNIDADE 1
sistema, mostra-nos as entidades e seus relacionamentos. Neste 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 destes, em outras palavras, mostra os dados em movimento,
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 de-
senvolvimento de software que o organiza como uma coleção de objetos que
contém tanto a estrutura dos dados quanto 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 por objetos.
A proposta da Orientação a Objetos é deslocar o esforço de desenvolvimento
para a fase de análise, dando ênfase às estruturas de dados antes das funções e,
assim, os benefícios são: a reutilização do código (componentes), a confiabilidade
(objetos encapsulados) e o aumento de produtividade (SOMMERVILE, 2011).
Com planejamento adequado, desenvolvedores capacitados e 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 a modelar os requisitos dos
usuários que o sistema deve atender.
explorando Ideias
Um sistema orientado a objetos é composto de objetos interativos que mantêm seu pró-
prio estado local e oferecem operações nesse estado. A representação do estado é privada
e não pode ser acessada diretamente, de fora do objeto. Processos de projeto orientado a
objetos envolvem projetar as classes de objetos e os relacionamentos entre essas classes.
Essas classes definem os objetos no sistema e suas interações. Quando o projeto é con-
cebido como um programa em execução, os objetos são criados dinamicamente a partir
dessas definições de classe. Sistemas orientados a objetos são mais fáceis de mudar do
que os sistemas desenvolvidos com abordagens funcionais. Os objetos incluem os dados
e as operações para manipulá-los. Portanto, eles podem ser entendidos e modificados
como entidades autônomas. Como os objetos são associados com coisas, muitas vezes,
existe um mapeamento claro entre entidades do mundo real e seus objetos de controle
no sistema, o que melhora a inteligibilidade e, portanto, a manuteniblidade do projeto.
Fonte: Sommerville (2011, p.125).
14
2
EVOLUÇÃO
UNICESUMAR
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, 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
por 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 meto-
dologia 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.
15
Shlaer e Mellor (1990)
UNIDADE 1
Abrangem as fases de análise, projeto e implementação. Propõem mecanis-

mos para facilitar a representação de modelos dinâmicos dos objetos, dando
ênfase à modelagem da informação, por meio dos modelos de objetos, de
estados, de 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 orientados 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 obje-
tos, modelagem dinâmica e modelagem funcional, destacando o tratamento
de processos e dividindo a fase de projeto em projeto de objetos e de sistema.
Martin e Odell (1995)

Abrangem as fases de análise e projeto. Propõem o uso da Engenharia da
Informação baseada em objetos por meio de um repositório de objetos, para
a obtenção, em alto nível, de reaproveitamento dos sistemas.
Fusion (1996)
Abrange as fases de análise, projeto e implementação. Sintetiza os aspec-
tos 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).
16
UML – Unified Modeling Language (2000)
UNICESUMAR
Abrange as fases de levantamento de requisitos, análise, projeto e implemen-
tação. Fusão dos métodos de James Rumbaugh/OMT, Grady Boock e Ivar
Jacobson. A fusão inicia com o trabalho de Rumbaugh e Booch, os dois me-
todistas que ganharam mais popularização, os quais se juntaram para criar
para o público um método comum por meio de pontos fortes em 1995. Em
seguida, em meados de 1996, 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, considerado um padrão mundial.
A UML sugere, fortemente, a adoção de casos de uso (use cases) como dire-
cionadores de projetos de software, a utilização de diagramas de interação para
identificação de objetos e uma série de outros conceitos.
explorando Ideias
O projeto de software começa quando a primeira iteração da engenharia de requisitos

chega a uma conclusão. O intuito do projeto de software é aplicar um conjunto de prin-
cípios, conceitos e práticas que levam ao desenvolvimento de um sistema ou produto de
alta qualidade. O objetivo do projeto é criar um modelo de software que irá implementar
corretamente todos os requisitos do cliente e trazer satisfação àqueles que o usarem. Os
projetistas de software devem examinar completamente muitas alternativas de projeto e
convergir para uma solução que melhor atenda às necessidades dos interessados no pro-
jeto. O processo de projeto passa de uma visão macro do software para uma visão mais
estreita que define os detalhes necessários para implementar um sistema. O processo
começa concentrando-se na arquitetura. São definidos subsistemas; são estabelecidos
mecanismos de comunicação entre os subsistemas; são identificados componentes; e é
desenvolvida uma descrição detalhada de cada componente. Além disso, são projetadas
interfaces externas, internas e para o usuário.
Fonte: Pressman (2011, p. 226).
pensando juntos
O modelo de projeto engloba quatro elementos distintos; à medida que cada um é desen-
volvido, evolui uma visão mais completa do projeto.
(Roger Pressman)
17
3
CONCEITOS
UNIDADE 1
BÁSICOS DE OO
Conheceremos, a seguir, os principais termos e conceitos utilizados em análise

e projeto OO. Vamos lá!
■ Objeto: qualquer elemento concreto ou abstrato que existe no mundo

real, que se pode individualizar por possuir comportamentos e caracte-
rísticas próprios.
Figura 1 - Objetos concretos Figura 2 - Objetos abstratos
18
■ Abstração: abstraímos quando definimos um objeto conceitual partindo
UNICESUMAR
de objetos do mundo real com os mesmos comportamentos e caracterís-
ticas, os quais são classificados como de um mesmo tipo.
Figura 3 - Abstração de bolsa Figura 4 - Abstração de avião
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

19
■ Instância: é cada umas das ocorrências de um objeto formado a partir
UNIDADE 1
da sua classe.
Figura 7 - Classe e objetos / Fonte: os autores.
■ 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: os autores.
■ 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: os autores.

20
■ Mensagem: representa o mecanismo de chamada de uma operação. É
UNICESUMAR
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: os autores.
■ Evento: é um tipo especial de operação que faz com que os objetos mu-
dem de estado.
Figura 11 - Evento / Fonte: os autores.
■ Parâmetro: é um ou mais atributos que são carregados para dentro de

uma mensagem.
Figura 12 - Parâmetro - Avião, partida (linha aérea, número do voo, cidade) / Fonte:
os autores.
21
■ Estado: é a forma de apresentação dos objetos de uma classe em deter-
UNIDADE 1
minado instante.
Figura 13 - Estado / Fonte: os autores.
■ Transição de estado: é quando ocorre a mudança de estado de um ob-

jeto de uma classe como resposta à chegada de um evento.
Estado Parado Estado Decolando
Estado Criado Estado Eliminado
Figura 14 - Transição de estado / Fonte: os autores.
■ Associação: é a forma como os objetos de uma mesma classe ou de

classes diferentes se conectam.
Figura 15 - Associação de classes / Fonte: os autores.
■ Encapsulamento: é a reunião de características e comportamentos de

objetos em uma classe.
Figura 16 - Encapsulamento / Fonte: os autores.

22
■ Polimorfismo: é a capacidade que objetos de classes diferentes possuem
UNICESUMAR
de se comportarem de forma diferente em uma mesma operação. A es-
trutura (atributos) de cada classe é diferente.
Figura 17 - Polimorfismo / Fonte: os autores.
■ Método: é o algoritmo (conjunto de passos) que um objeto executa quan-

do 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: os autores.
■ Colaboração: é a troca de mensagens que acontece entre objetos e atores
■ Figura 18 - Troca de mensagens entre os objetos / Fonte: os autores.
■ Herança: é a propriedade que possibilita que a classe herde característi-

cas e comportamento de outra classe.
Figura 19 - Herança / Fonte: os autores.
23
4
PRINCIPAIS
UNIDADE 1
DIAGRAMAS DA UML
Agora que já conhecemos os principais termos utilizados na análise e no projeto

OO, conheceremos os diagramas utilizados para documentação de software. A
UML 2.5 apresenta vários diagramas, classificados em estruturais e de compor-
tamento. A Figura 20 mostra esta organização em um diagrama de classes.
Figura 20 - Organização do diagrama UML / Fonte: os autores.
24
É comum verificarmos que a documentação do software, na maioria das vezes, não
UNICESUMAR
tem a devida atenção da equipe de desenvolvimento, por preguiça, ou por falta de
tempo, ou mesmo por pensar que é perda de tempo elaborar inúmeros diagramas.
Porém, bons softwares têm documentação que nos permite contar e entender a sua
história. A seguir, conheceremos alguns dos diagramas mais utilizados na UML.
Diagramas de comportamento
Os diagramas de comportamento são utilizados para descrever o sistema mo-

delado 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
O diagrama de casos de uso (comportamento) é utilizado na análise de requisitos.

Este 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 stickman (“homem palito”) e suas respectivas
ações descritas nas elipses.
Realiza
Cria livro empréstimo
Realiza
Cria aluno
consulta
Bibliotecária Aluno
Realiza
Efetua empréstimo devolução
Figura 21 - Diagrama de caso de uso / Fonte: os autores.
25
Diagrama de sequência
UNIDADE 1
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. A partir desta ação, é desencadeado um conjunto de mensagens entre
os objetos, que, por sua vez, permite a verificação da existência da pessoa aluno, e,
em seguida, é criado o item de empréstimo, que verifica a existência do exemplar
solicitado, realizando o empréstimo.
Como é possível observar, a partir das informações fornecidas pelo diagra-
ma de sequência, pode-se identificar os métodos associados às classes, além da
identificação das relações entre elas.
Figura 22 - Diagrama de sequência / Fonte: os autores.
26
Outra forma de representar esse cenário é pelo diagrama de comunicação (com-
UNICESUMAR
portamento). Ele contém as mesmas informações que o diagrama de sequência,
porém não considera a dimensão temporal.
Diagrama de estados
Agora, veremos o diagrama de estados (comportamento), que tem como obje-

tivo especificar o comportamento das classes mais complexas, utilizando uma
máquina de estados.
explorando Ideias
Autômato finito ou máquina de estados finitos representa a modelagem de comporta-

mentos 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 detalha-
mento de uma atividade que deve ser executada em determinado momento.
Fonte: adaptado de Sommervile (2011).
Não são todas as classes do sistema que apresentam mais de um estado. O diagrama
de estado a seguir mostra todos os estados do exemplar no momento empréstimo.
O início do estado é marcado pelo círculo, e o fim é marcado pelo duplo círculo.
Figura 23 - Diagrama de estado / Fonte: os autores.

27
Diagrama de comunicação
UNIDADE 1
O diagrama de comunicação permite a identificação das classes mais próximas, e

a ordem de envio de mensagens é identificada por números sequenciais. A seguir,
é apresentado o diagrama de comunicação equivalente ao diagrama de sequência
mostrado anteriormente.
Figura 24 - Diagrama de comunicação (comportamento) / Fonte: os autores.
Diagrama de atividades
O diagrama de atividade é, em sua essência, um gráfico de fluxo demonstran-

do como ocorre o fluxo de controle entre as atividades. Este diagrama é um dos
mais detalhistas, dando mais ênfase ao nível de algoritmo.
Os diagramas de atividades podem ser utilizados com vários propósitos. Den-
tre eles, podemos citar a captura do funcionamento interno do objeto, mostrar
como pode ser executado um conjunto de ações relacionadas e como elas podem
afetar os objetos ao seu redor.
28
UNICESUMAR
Figura 25 - Diagrama de atividades / Fonte: os autores.
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 repre-
sentam 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.
Diagrama de classes
Após a elaboração do diagrama de caso de uso, podemos modelar a primeira ver-

são do diagrama de classes, pois este 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 comportamento de seus
objetos, e os possíveis estados do objeto são modelados por meio de atributos.
29
Para entendermos melhor, faremos a analogia com a construção de um veícu-
UNIDADE 1
lo. Todos os veículos serão rigorosamente iguais, pois estarão baseados em uma
planta (projeto) que esclarece o número de portas, a potência do motor, o número
de marchas do câmbio, entre 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 a seguir modela a estrutura estática do sistema de bi-
blioteca, 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 3, mas,
para adiantar, é possível observar, neste 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.
Figura 26 - Diagrama de classes / Fonte: os autores.
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 que ele, porém podem 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 deste para mostrar as instâncias da classe.
30
PESSOA
UNICESUMAR
• Nome: “João da Silva”
• Fone: “(43) 3948-4039
ALUNO PROFESSOR
• Curso: “Programação Java” • Disciplina: “Java”
Figura 27 - Diagrama de objetos / Fonte: os autores.
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ódulos
executáveis do software.
Apesar de ser um diagrama de alto nível, a organização do sistema é depen-
dente da linguagem de programação utilizada, portanto a solução de desenvol-
vimento adotada refletirá, diretamente, neste diagrama.
Um componente corresponde a uma parte do código distribuível, a qual pode
ser substituída por outro componente e que contém elementos que mostram um
conjunto de interfaces fornecidas e requeridas. Podemos apresentar como exemplos
de componentes: os executáveis, as tabelas, as bibliotecas, o documento e o arquivo.
Figura 28 - Diagrama de componente / Fonte: os autores.
31
Diagrama de implantação
UNIDADE 1
Diagramas de implantação são utilizados para modelar a arquitetura física de

distribuição em que 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 computa-
cional com memória e processamento, ou seja, um disco rígido, um computa-
dor, uma impressora etc. É uma ferramenta importante quando queremos saber
quais computadores e outros hardwares estão conectados, bem como saber de
que modo estão distribuídas as classes e quando a atualização de determinado
arquivo resulta na recompilação de outros.
Figura 29 - Diagrama de implantação / Fonte: os autores.
32
Diagrama de pacotes
UNICESUMAR
O pacote representa um agrupamento de classes, formando uma unidade. Nor-
malmente, os pacotes apresentam relações em que um depende de outro para o
funcionamento. Como a estrutura de uma aplicação é dada pelas classes e associa-
ções, podemos 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 sub-
sistemas, e, neste caso, cada subsistema é representado por um pacote. Dessa forma,
um pacote pode representar uma biblioteca, um subsistema, um sistema, entre
outros, e, também, um pacote pode conter outros. Os pacotes, invariavelmente,
apresentam dependência entre si, o relacionamento de dependência indica que
o pacote dependente precisa, de alguma forma, daquele outro do qual depende.
Figura 30 - Diagrama de pacotes / Fonte: os autores.
33
CONSIDERAÇÕES FINAIS
UNIDADE 1
Nesta unidade, aprendemos que a análise é a solução conceitual dada ao proble-

ma. 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 gerenciador
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 este como
uma coleção de objetos, que contém tanto a estrutura dos dados quanto o com-
portamento 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 se 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 a 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 Rumbaugh e Boo-
ch; em seguida, em meados de 1996, Jacobson integrou-se ao grupo, e lançaram a
UML versão 0.9. A partir daí, criaram forças com a cooperaçã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
e testes. Após conhecermos os principais métodos e estudarmos as suas caracte-
rísticas, entramos em contato com os conceitos de OO, em que aprendemos sobre
objetos, abstração, classes, operações, atributos, instância, mensagem, entre outros.
Por fim, conhecemos os diagramas utilizados para documentação de software.
Os diagramas de caso de uso, classes, estado, sequência e colaboração foram apre-
sentados de forma sucinta, já que os veremos com detalhes nas unidades seguintes.
A partir dos conceitos que foram abordados nesta unidade, conseguimos ter
uma visão geral sobre a Orientação a Objetos. Agora, você conhecerá as etapas
da análise e notação para o diagrama de caso de uso.
34
na prática
1. Na análise e no 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
do projeto estruturados, na Orientação a Objetos, o processo a ser informatizado é
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 Jacobson
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 propostos
pelos autores citados?
3. A UML – Unified Modeling Language abrange as fases de levantamento de requisi-

tos, 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 objetos?
I - Objetos: qualquer elemento concreto ou abstrato com existência perceptível

no mundo real.
II - Classes: abstração de um conjunto de objetos.
III - Atributo: característica particular possuída por todos os objetos de uma classe.
IV - Chave primária: identifica, unicamente, um objeto.
É correto o que se afirma em:
a) I, apenas.
b) I e II, apenas.
c) I, II e III, apenas.
d) III e IV, apenas.
e) I, II, III e IV.
35
na prática
4. É comum verificarmos que a documentação do software, na maioria das vezes, não

tem a devida atenção da equipe de desenvolvimento, por preguiça, ou por falta
de tempo, ou mesmo por pensar que é uma perda de tempo elaborar inúmeros
diagramas. Bons softwares, porém, têm documentação que nos permite contar e
entender a sua história, e contamos esta por meio de diagramas. Sabendo disso,
quais diagramas são utilizados na UML e como estão organizados?
5. Leia o excerto a seguir e veja quais das alternativas preenche, corretamente, a lacuna:
O diagrama __________ contém as mesmas informações que o diagrama de sequência,

porém não considera a dimensão temporal.
Assinale a alternativa correta:
a) De comunicação.
b) De caso de uso.
c) De classes.
d) De estado.
e) De pacotes.
36
aprimore-se
QUALIFICAÇÃO DE SOFTWARES
Como um software pode ser qualificado? É muito simplório definir isto pelo tempo
de desenvolvimento ou pela excelência na programação. Existem casos de desen-
volvimento de softwares em que o programador ouve todas as informações e apre-
senta uma solução instantânea, quase que “mágica”, algo que resolve perfeitamente
o que foi apresentado. Vendo desta forma, a sensação é que o atendimento foi
excepcional, contudo, na maioria dos casos, programas feitos neste formato não
suprem a real necessidade do cliente.
Não podemos julgar o cliente por não saber apresentar, de forma assertiva, as
suas necessidades, pois o conhecimento da construção técnica é inexistente ou su-
perficial, 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 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á os tenha vivenciado.
Este problema, porém, não é exclusivo do desenvolvimento de softwares, é cor-
riqueiro no mercado. Para provar isto, basta necessitarmos de um serviço que não
temos nenhum conhecimento do processo, como consertar um carro. A solução
só vem quando um profissional qualificado está mais preocupado em satisfazer o
cliente do que resolver, exclusivamente, o seu problema apresentado. Os profissio-
nais que mantêm este método de atendimento são substituídos aos poucos.
Na rotina diária de programação, normalmente, o início do projeto vem de uma
conversa informal, e, só na primeira apresentação, depois de um bom tempo de de-
dicação, é que o cliente consegue esclarecer o que deseja, ainda de forma abstrata,
por meio de frases como “não é bem isso que eu esperava”. Outro caso comum que
acontece pela falta de alinhamento é o seguinte: as solicitações do cliente aumen-
tam durante o processo todo, e, como nada é estabelecido de forma clara no início
do trabalho, você pode até prolongar o projeto, mas, possivelmente, não atenderá a
todas as necessidades do seu cliente.
37
aprimore-se
Finalizo lembrando que o cliente não tem obrigação de entender como funciona
toda a programação e que a preocupação em o atender deve ser do programador,
não o contrário. Um bom profissional precisa “interpretar” a necessidade de um clien-
te e oferecer não o que ele está pedindo, mas, sim, o que suprirá a necessidade dele.
Fonte: o autor.
38
eu recomendo!
livro
Desenvolvendo Software com UML 2.0: definitivo

Autor: Ernani Medeiros
Editora: Makron Books
Sinopse: este livro apresenta, de maneira prática e testada, o que
é, para que serve e como usar os diagramas da UML 2.0. Além de
sugerir o melhor momento para 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 con-
ceito e como usá-lo.
conecte-se
Para aprofundar os conhecimentos sobre OO, leia o artigo intitulado “A história de

UML e seus diagramas”. Ele descreve a história da UML desde a década de 90 até
o momento atual. É apresentada a organização dos 13 diagramas de UML, classi-
ficando-os em diagramas estruturais e comportamentais. Os quatro documentos
pertencentes à especificação também são mencionados e explicados.
https://fdocumentos.tips/document/a-historia-de-uml-e-seus-diagramas.html
39
2
CASOS
DE USO
PROFESSORES
PLANO DE ESTUDO
A seguir, apresentam-se as aulas que você estudará nesta unidade: • Fases da Análise e do Projeto •
Modelos de Processo • Requisitos de Software • Diagrama de Casos de Uso.
Conhecer as fases de 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 diagra-
ma de caso de uso.
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 acreditamos ser a
fase mais difícil e crítica da produção de um software. Difícil porque é o
momento em que ocorrem as tentativas de delimitar o domínio do proble-
ma e entendê-lo; crítica porque uma análise malfeita comprometerá todas
as outras fases de produção do software, além do fato de que o produto a
ser entregue não será aquele que o cliente, inicialmente, requeria.
Entenderemos e conheceremos dois modelos de processos de software,
dentre os diversos processos existentes. Citaremos, aqui, o modelo em cas-
cata e o evolucioná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 esta-
belecidos por clientes e usuários do sistema, que definem as diversas pro-
priedades 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, os quais o sistema deverá possuir.
Ainda, veremos a importância do levantamento de requisitos para o
desenvolvimento de software. Aprenderemos que a definição de requisitos
pode utilizar uma narrativa ou 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 softwa-
re. Esses diagramas 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! Boa leitura a todos.
1
FASES
UNIDADE 2
DA ANÁLISE
e do projeto
Como vimos na primeira unidade, a análise de sistemas é a atividade inicial do

processo de desenvolvimento de software em que se determina e especifica o que
um sistema deve fazer, assim como as circunstâncias sob as quais ele deve operar,
envolvendo, geralmente, 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 a hardware, software, pessoas, banco de dados e 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 trabalho
subsequente.
Independentemente do método ou processo utilizado para a análise, o projeto e

a implementação, algumas etapas são comuns, são elas (SOMMERVILE, 2011):
■ Identificação da necessidade.
■ Estudo de viabilidade.
■ Análise.
■ Projeto (ferramentas).
42
■ Implementação (codificação).
UNICESUMAR
■ Implantação.
■ Manutenção (adaptativa, corretiva e evolutiva).
A seguir, conheceremos cada uma dessas etapas de suma importância para a

produção de um software de qualidade.
Identificação da necessidade
Comentaremos cada uma dessas etapas começando pela identificação da ne-

cessidade, que é o ponto de partida na evolução de um sistema. Nesta etapa, são
definidas as metas globais do sistema, respondendo a algumas perguntas-chave:
■ Quais informações serão produzidas?
■ Quais informações devem ser fornecidas?
■ Que funções e desempenho são exigidos?
Ainda nesta 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 o tempo necessário para conclusão?
Caso o novo sistema seja um produto a ser desenvolvido para a venda direcio-
nada a muitos clientes, o analista, ainda, deve avaliar o seguinte:
■ Qual é o mercado em potencial para o produto?
■ Como este 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 determi-

nar, 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 e sistema operacional. E, também, se existe pessoal competente
à disposição para desenvolver o sistema em questão (SOMMERVILE, 2011).
43
No aspecto da viabilidade legal, o analista verifica se não existem conflitos
UNIDADE 2
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 es-
taduais/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 de-
terminar 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 a análise completa de um sistema, por-
tanto o analista deve considerar os seguintes objetivos (SOMMERVILE, 2011):
■ Entender os objetivos do sistema (o que o administrador/usuário espera dele).
■ Entender as exigências do sistema (o que processar e que saídas produzir).
■ Entender que os objetivos e as 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.
44
Projeto
UNICESUMAR
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 es-
trutura 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 elaborar modelos com
diferentes níveis de abstração, é possível detectar problemas nos níveis anteriores.
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 em que se cria uma versão exe-

cutável ele, utilizando as ferramentas para desenvolvimento definidas no projeto.
A implementação pode iniciar após o término do projeto ou pode acontecer de
forma paralela a ele, 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 implementado
usando os recursos existentes: computadores, periféricos, sistema operacional,
entre outros, e, também, se existe pessoal competente à disposição para desen-
volver o sistema em questão.
Todo o projeto é construído com base no estudo de viabilidade técnica, utili-
zando ferramentas suportadas pelo hardware e entendida pelos usuários, portan-
to os riscos da implantação não funcionar são minimizados no projeto. O fator
45
mais preocupante, nesta fase, é, justamente, o período que será necessário para a
UNIDADE 2
adaptação do usuário com o novo sistema, pois toda mudança gera transtornos,
na maioria das vezes, o usuário está acostumado a executar suas tarefas de de-
terminada 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, mas tam-
bém a motivos que não foram possíveis de observar no momento da análise, do
projeto ou, mesmo, da implementação.
As manutenções podem ser adaptativas, cujo objetivo, como o próprio nome
diz, é adaptar algumas tarefas ou funções para o ambiente de implantação. As
manutenções também podem ser evolutivas, cujo objetivo é a inserção de novos
módulos no sistema.
explorando Ideias
Projeto é o que quase todo engenheiro quer fazer. É o lugar onde a criatividade impera
— onde os requisitos dos interessados, as necessidades da aplicação e considerações
técnicas se juntam na formulação de um produto ou sistema. O projeto cria uma repre-
sentação ou modelo do software, mas diferentemente do modelo de requisitos (que se
concentra na descrição do “O que” é para ser feito: dos dados, função e comportamento
necessários), o modelo de projeto indica “O Como” fazer, fornecendo detalhes sobre a ar-
quitetura de software, estruturas de dados, interfaces e componentes fundamentais para
implementar o sistema. Os engenheiros de software conduzem cada uma das tarefas de
projeto. Por que é importante? O projeto permite que se modele o sistema ou produto
a ser construído. O modelo pode ser avaliado em termos de qualidade e aperfeiçoado
ANTES de o código ser gerado, ou de os testes serem realizados, ou de os usuários finais
se envolverem com grandes números.
Fonte: Pressman (2011, p. 206, grifo do autor).
46
2
MODELOS
UNICESUMAR
DE PROCESSO
A análise e o projeto de sistemas de software devem fornecer para os stakeholders,

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

lo de processo em cascata, ou queda
d’água, como colocado por alguns
autores.
Figura 1 - Modelo cascata / Fonte: adaptada de

Sommerville (2011).
47
Conhecido como ciclo de vida clássico, o modelo em cascata é o primeiro a ser
UNIDADE 2
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.
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 requisitos em
sistemas de hardware ou de software são agrupados, estabelecendo uma arqui-
tetura do sistema geral.
A terceira fase é a implementação e o teste de unidades. Durante este 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
atende à sua especificação.
A quarta fase é a integração e o teste de sistemas. Neste estágio, as unidades de
programa ou programas individuais são integrados e testados como um sistema
completo, a fim de garantir que os requisitos de software foram atendidos.
A quinta fase é a operação e manutenção. Normalmente, esta é a fase mais longa
do ciclo de vida. O sistema é instalado e colocado em operação. A manutençã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 requisitos são descobertos.
Neste 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 do-

mínio do problema, é recomendável a utilização do modelo de desenvolvimento
evolucionário. Este tem, como base, a ideia de desenvolver uma implementaçã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 seja desenvolvido.
Em vez de ter as atividades de especificação, desenvolvimento e validação em
separado, todo esse trabalho é realizado concorrentemente, com rápido feedback
por meio dessas atividades. A Figura 2 ilustra bem as fases do modelo evolucionário.
48
UNICESUMAR
Figura 2 - Modelo evolucionário / Fonte: adaptada de Sommerville (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 espe-
cificação, que pode ser desenvolvida gradualmente, à medida que os usuários
compreendem melhor o problema.
Como nem tudo são flores, porém, problemas acontecem nesse modelo; enu-
meraremos alguns deles:
■ 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 constan-
te tende a corromper a estrutura do software, incorporar modificações
torna-se cada vez mais difícil e oneroso.
Utilizando o modelo em cascata, ou o 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 Diagra-
mas de Entidade-Relacionamento (DER), Diagrama de Fluxo de Dados (DFD),
diagrama de contexto, dicionário de dados etc. Esses modelos fornecem uma
compreensão única do projeto.
O foco da nossa disciplina, contudo, é a orientação a objetos, portanto, nas
fases de análise e projeto, construiremos diagramas de caso de uso, de classes, de
estado, de sequência etc. Esses modelos também fornecerão uma compreensão
única do projeto.
49
Linguagem de modelagem – UML
UNIDADE 2
A linguagem de modelagem é uma parte muito importante do método. Corresponde

ao ponto principal da comunicação. Se uma pessoa quer conversar 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 repre-
sentação gráfica vistos no modelo (retângulo, setas, texto etc.) são a notação, essa
é 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 isto, é possível concluir que, independentemente 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 figura a seguir ilustra, de forma lúdica, o que ocorre em um projeto de
software em que a equipe de desenvolvimento e o cliente não se entendem.
50
UNICESUMAR
Figura 3 - Charge sobre projeto de software / Fonte: Ampersand (2013, on-line, traduzido
pelo autor)1.
pensando juntos
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.
51
3
REQUISITOS
UNIDADE 2
DE SOFTWARE
Agora que já sabemos a importância da análise e do projeto na produção de um

software, conheceremos 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 é isso?
Vamos por partes, então. O termo “engenharia” permite dizer que se utiliza 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 é elicitar, devemos obter o máximo de informações

para o conhecimento do objeto em questão dentro do domínio do problema.
52
Domínio
UNICESUMAR
O que é domínio? Para entender melhor, imaginaremos que você foi contrata-
do(a) para desenvolver um software em determinada Casa de Carnes. Do lado
direito da Casa de Carnes, existe uma farmácia, do lado esquerdo, um mercado,
atrás, uma lanchonete e, em frente, uma igreja. Neste caso, o domínio do seu
problema é a Casa de Carnes, os demais estabelecimentos 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(a) para desenvolver um software para determinado
departamento de uma empresa, dessa forma, determinar esse domínio 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 devemos
centrar em funcionalidades, mas, sim, em finalidade.
Requisitos
Os requisitos são os objetivos e as restrições estabelecidas pelo usuário do sis-

tema. É o usuário ou o cliente o responsável por descrever as necessidades ou
o desejo para o software (SOMMERVILE, 2011). Em um primeiro momento, é
interessante definir os requisitos sem se preocupar em detalhá-los, isto 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, produzimos um documento estruturado contendo requisitos e
restrições descritos detalhadamente. Vamos aos exemplos.
53
Definições de requisitos:
UNIDADE 2
1. O software deve proporcionar um meio para representar e acessar arquivos exter-

nos criados por outros aplicativos.
Especificação de requisitos:
1.1. O usuário deverá ser provido de recursos que permitam definir os tipos de arqui-
vos 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 utilizados na repre-
sentação dos arquivos externos.
Quadro 1 - Exemplos de definições e especificação de requisitos / Fonte: o autor.
Na definição de requisitos, pode-se utilizar uma narrativa ou representações grá-

ficas. Normalmente, as informações coletadas são fornecidas pelo usuário. Por
meio dessas definições, pode ser elaborado o documento preliminar de requisitos.
Eles 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 providas 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, à usa-

bilidade, ao desempenho, à segurança, confiabilidade, manuteniblidade e dispo-
nibilidade que o sistema deverá possuir. Por exemplo:
■ O sistema deverá apresentar interface gráfica (padrão Windows).
■ Facilidade de uso.
■ Possibilidade de ajuda no contexto.
54
A partir das definições dos requisitos, produzimos o documento preliminar deles,
UNICESUMAR
que deve conter todos os serviços (requisitos) requeridos pelo cliente, explicitados
de forma clara, sem contradições. Atingir este objetivo é uma tarefa difícil pelas
inúmeras dificuldades que são encontradas no domínio. Mas, 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 podem tornar o
documento de requisitos um documento de adivinhações.
Característica 2 – Precisam ser possíveis: você deve ser hábil em imple-

mentar cada requisito declarado, observando os recursos e as limitações do
sistema e ambiente. Para evitar requisitos impossíveis, trabalhe, com o pes-
soal técnico, o documento de requisitos, checando o que é ou 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 a uma interfa-
ce externa ou, ainda, um padrão. Você pode pensar que “necessário” significa
cada requisito com 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
auxiliem 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 com o cliente a prioridade de cada um.
55
Característica 5 – Não podem ser ambíguas: cada declaração deve ser ex-
UNIDADE 2
plicitada de maneira que permita somente uma interpretação. Linguagem

natural é altamente propensa a ambiguidades, elimine termos subjetivos,
como: amigável ao usuário, fácil, simples, rápido, eficiente, vários, aperfeiçoar,
maximizar 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 tes-

tes 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 despro-
vidos de ambiguidades também não são verificáveis.
Após o estágio de elicitação (extração), um documento contendo os requisitos

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, por sua vez, envolve uma série de atividades (SOMMER-
VILE, 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.
56
Os casos de uso têm um papel importantíssimo na análise de requisitos, pois
UNICESUMAR
permitem criar um cenário do domínio, e, talvez, este seja o único instrumento
que acompanha o software do início até seu término, além disso, casos de uso
representam funcionalidades completas para o usuário e não funcionalidades
internas do sistema. Outro ponto importante é que o diagrama 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 dos usuários no processo de desenvolvimento, 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, e estes podem ser
um usuário ou outro sistema.
O diagrama de casos de uso é apenas um panorama visual das funciona-
lidades do sistema, é necessária uma descrição textual para detalhar os casos.
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.
explorando Ideias
A especificação de requisitos é o processo de escrever os requisitos de usuário e de sis-

tema em um documento de requisitos. Idealmente, os requisitos de usuário e de sistema
devem ser claros, inequívocos, de fácil compreensão, completos e consistentes. Na práti-
ca, isso é difícil de conseguir, pois os stakeholders interpretam os requisitos de maneiras
diferentes, e, muitas vezes, notam-se conflitos e inconsistências inerentes aos requisitos.
Os requisitos de usuário para um sistema devem descrever os requisitos funcionais e não
funcionais de modo que sejam compreensíveis para os usuários do sistema que não te-
nham conhecimentos técnicos detalhados. Idealmente, eles devem especificar somente o
comportamento externo do sistema. O documento de requisitos não deve incluir detalhes
da arquitetura ou projeto do sistema.
Fonte: Sommerville (2011, p. 65).
57
4
DIAGRAMA
UNIDADE 2
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, e, também,
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.
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
preocupar, neste momento, com a implementação).
Conhecer a notação para os diagramas de caso de uso preconizados pela UML.

Os elementos básicos deste diagrama são:
■ Atores.
■ Casos de uso.
■ Relações entre atores e casos de uso.
58
Atores
UNICESUMAR
Começaremos, então, pelo homem palito, que representa um
ator no meu sistema. Esse ator pode ser uma pessoa, outro sis-
tema ou uma entidade externa ao sistema.
Como encontrar os atores para um sistema? Usando as
seguintes dicas:
■ Examine o problema procurando por pessoas ou sis-
Figura 4 - O ator /
temas do entorno. Fonte: os autores.
■ Faça as seguintes perguntas:
■ Quais são as pessoas ou os departamentos interessados em determi-
nado requisito funcional?
■ Quem suprirá o sistema com informações e quem receberá informa-
ções dele?
■ Quais os recursos externos utilizados pelo sistema?
■ Uma pessoa desempenha diferentes papéis?
■ O sistema interage com outros sistemas existentes?
Essas dicas também não garantem que o ator foi bem escolhido da primeira vez,
pois este é um processo iterativo; dificilmente, a primeira tentativa será a definitiva.
explorando Ideias
Os casos de uso são documentados por um diagrama de casos de uso de alto nível. O
conjunto de casos de uso representa todas as possíveis interações que serão descritas
nos requisitos de sistema. Atores, que podem ser pessoas ou outros sistemas, são repre-
sentados como figuras “palito”. Cada classe de interação é representada por uma elipse.
Linhas fazem a ligação entre os atores e a interação. Opcionalmente, pontas de flechas
podem ser adicionadas às linhas para mostrar como a interação se inicia. Não há distin-
ção entre cenários e casos de uso que seja simples e rápida. Algumas pessoas consideram
cada caso de uso um cenário único; outros, encapsulam um conjunto de cenários em um
único caso de uso. Cada cenário é um segmento através do caso de uso. Portanto, seria
um cenário para a interação normal, além de cenários para cada possível exceção. Você
pode, na prática, usá-los de qualquer forma.
59
Casos de uso
UNIDADE 2
A coleção de casos de uso representa, do ponto de vista do usuário, todos os

modos de execução do sistema. Um caso de uso é uma sequência de ações que
produz um resultado significativo para um ator, e, assim, são necessárias as se-
guintes 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, na verdade, as duas denomi-
nações são utilizadas. Um caso de uso representa uma atividade que o ator realiza.
O caso de uso necessita de uma descri-

ção, porém, não há descrição padrão
definida pela UML. Em geral, o diagra-
ma é bastante informal e sua estrutura-
ção (relação entre casos) não deve ser
levada ao extremo. É importante ressal-
tar que o diagrama de casos de uso é
Figura 5 - Caso de uso / Fonte: os autores. uma forma de visualizar 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 em que, normalmente, relacionamos os se-
guintes itens:
■ Nome.
■ Descrição.
■ Requisitos funcionais providos pelo caso de uso.
■ Restrições, tais como pré e pós-condições.
60
■ Pré-condições: define o que deve ser verdadeiro para que o caso de uso
UNICESUMAR
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 anterior, o sistema pode se encontrar em um dos seguintes es-
tados: seguro concedido ou seguro não concedido por reprovaçã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.
Relações de dependência
As relações de dependência são representadas por uma seta tracejada, ela parte
do caso de uso que depende de outro em algum momento. O diagrama da Figura
6 nos diz que, para o cadastro de aluno, é necessária a conclusão do cadastro de
pessoa.
´
Figura 6 - Dependência / Fonte: os autores.
Se um caso de uso inclui o comportamento de outro, então dizemos que um usa

o outro. Aqui, a linha tracejada com uma seta também pode representar uma
inclusão de outro caso de uso. No exemplo da Figura 7, o caso de uso Calcular
Contas a Receber utilizará a forma de cálculo que está na documentação de Cal-
cular Contas a Pagar; usamos este artifício para evitar a necessidade de digitar
duas vezes a mesma especificação.
61
UNIDADE 2
<<include>>
Calcular contas Calcular contas
a pagar receber
Figura 7 - Inclusão / Fonte: os autores.
Já as extensões adicionam um comportamento a um caso de uso que descreve

uma variação do comportamento normal. Nesta situação, o caso de uso base
pode ser executado mesmo sem a extensão. O modelo da Figura 8 mostra que
existe um cálculo em Calcular Descontos que se estenderá para Calcular Contas
a Pagar, ampliando o significado da fórmula existente em Calcular Descontos.
Figura 8 - Extensão / Fonte: os autores.
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.
Ilustraremos esta documentação, por meio do caso de uso, para resolver ex-
pressões aritméticas.
62
Podemos fazer a descrição textual para o caso de uso Resolver Expressões Arit-
UNICESUMAR
méticas de acordo com o quadro a seguir:
Nome do caso de uso Resolver Expressões Aritméticas.
Permite resolver expressões envolvendo

números inteiros e reais e as operações
Descrição
básicas de soma, subtração, multiplica-
ção e divisão.
Ator Aluno.
Pré-condições O sistema deve estar em execução.
Expressão aritmética resolvida ou cance-

Pós-condições
lamento da operação pelo aluno.
Fluxo básico
Usuário Sistema
{Solicita expressão}
Solicita a expressão (A2).
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.
63
Fluxos alternativos
UNIDADE 2
Se o usuário fornecer uma expressão

sintaticamente incorreta, informá-lo so-
A1: em {Valida expressão}
bre o erro e retornar ao fluxo básico em
{Solicita expressão}
O usuário pode decidir encerrar o caso de

A2: em {Solicita expressão} uso sem fornecer uma expressão. Neste
caso, retornar ao fluxo básico em {Fim}
Quadro 2 - Resolver Expressões Aritméticas / Fonte: os autores.
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; isso 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, cujo 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 cami-
nho entre muitos possíveis, visto que um caso de uso pode ser executado de vários
modos. Existem os fluxos básicos, que demonstram o fluxo normal de eventos, e
os alternativos, que dizem o que fazer, caso não seja possível seguir o fluxo básico.
Para exemplificar, inspiraremo-nos na situação em que uma pessoa explica
um caminho à outra. Primeiro, o fluxo básico é explicado, depois, o fluxo alter-
nativo. No caso de uso 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.
64
UNICESUMAR
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 do respectivo ambiente. Vimos que, independentemente
do método ou processo utilizado para a análise, projeto e implementação, algu-
mas 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 construí-lo.
Familiarizamo-nos com dois modelos de processo de software: o cascata e
o evolucionário. Verificamos que o modelo cascata é indicado quando conhe-
cemos 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 conclusão da anterior. Já
o modelo evolucionário é indicado quando temos que aprender sobre o domínio
e o problema no desenvolvimento da aplicação, resultando em várias 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 eles serão consistentes, completos e relevantes. Vimos,
também, que a engenharia de requisitos é de suma importância, pois é nesta fase
que especificamos o problema, bem como 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 preocuparmos
com a implementação.
65
na prática
1. Quais são objetivos que 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 desenvolvimento

e o cliente não se entendem?
6. O que são requisitos de software e como podemos classificá-los?
66
aprimore-se
COMO FAZER UM PLANO DE TESTES BASEADO EM CASOS DE USO
Qual é a função primordial de qualquer software desenvolvido? A questão parece

simples, mas respondo que é ter acessibilidade, e, para que isto seja possível, hoje, é
obrigatório testá-lo adequadamente. Conheceremos uma forma sistêmica de mon-
tar toda a linha de testes embasada em casos de uso.
Uma das primeiras perguntas que devem ser levantada para iniciar a montagem
de um plano de testes é: o que testar? Parece visível a resposta, que é testar as
funcionalidades que compõem o escopo do software que está sendo desenvolvido.
Agora, você se pergunta: onde está descrito esse escopo? Normalmente, ele pode
estar na proposta do projeto, na especificação funcional e, em muitos projetos, nos
casos de uso.
Eduardo Ernandes da Silva, no artigo intitulado “Como fazer um plano de testes
baseado em casos de uso” ([2020], on-line)2, descreve os casos de uso como requisi-
tos que identificam o valor que o cliente espera obter da funcionalidade e represen-
tam a forma como o sistema será utilizado. Além disso, permitem identificar todos
os caminhos que o usuário pode percorrer para conseguir o que deseja e se podem
ocorrer problemas. E, também, mostram ao cliente o que esperar do software; ao
desenvolvedor, o que codificar; ao testador ou certificador, o que validar para garan-
tir a qualidade dos entregáveis.
Desse modo, podemos concluir que os casos de uso ajudam na certificação e
validação dos requisitos implementados, simplificando e sistematizando o processo
de teste do software, permitindo ganho de produtividade e ajudando na garantia de
que todo o escopo será abrangido pelo teste.
Sabendo onde os casos de uso podem nos ajudar, vem a próxima pergunta: o
que fazer agora? No artigo citado, o autor classifica várias utilidades e destaca qua-
tro procedimentos que podemos seguir:
67
aprimore-se
■ Selecione o caso de uso que será testado, identifique o fluxo principal e os fluxos
alternativos e desenhe um diagrama de atividades. Desse modo, você consegui-
rá visualizar, mais facilmente, todos os cenários que o usuário pode utilizar.
■ Agora que já identificou os cenários, você começará a escrever um caso de
teste para cada cenário, detalhando todos os passos do cenário. Desse modo,
o testador poderá executar as ações do ator e validar se a resposta do siste-
ma está de acordo com o que foi especificado.
■ Para iniciar os testes, será necessária a criação de uma base de dados de
certificação, se ela ainda não existir (não é prudente fazer os testes na base
de desenvolvimento e, muito menos, em produção), e identificar os dados de
entrada que serão utilizados nos testes.
■ É importante tabular o resultado dos testes, como quantidade de acertos, de-
feitos e correções, e armazenar esta informação em algum meio permanente.
Isto servirá para avaliar a qualidade de cada desenvolvedor da sua equipe.
Dessa maneira, podemos concluir que usar os casos de uso como modelo para os
testes permitirá a visão mais apurada do software, bem como mais noção das ne-
cessidades dos clientes.
Fonte: adaptado de Silva ([2020], on-line)2.
68
eu recomendo!
livro
Fundamentos do Desenho Orientado a Objeto com UML

Autor: 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 me-
lhores práticas quanto ao desenvolvimento de OO para melhorar
o seu código e o seu índice de sucesso em projetos fundamentados em objetos.
conecte-se
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 de-
senvolvimento distribuído de software”. Este 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.
http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER03/leandro_audy.pdf
69
3
DIAGRAMA
DE CLASSES
PROFESSORES
PLANO DE ESTUDO
A seguir, apresentam-se as aulas que você estudará nesta unidade: • Diagrama de Classes • Notação
para Classes • Atributos e Métodos • Multiplicidade entre as Associações de Classes • Tipos de Associação
entre Xlasses • Herança Múltipla.
Entender o objetivo do diagrama de classes • Conhecer a notação UML para 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.
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 unidade. 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 dia-
grama de classes, além das convenções para os nomes das classes, atributos
e métodos, veremos, também, as várias formas de notação para o diagrama
de classes. A classe tem a função de individualizar o objeto (qualquer ele-
mento concreto ou abstrato) por meio de suas características (atributos)
e comportamentos (métodos). Sendo assim, aprenderemos a sintaxe, ou
seja, como construir a linha de declaração para os atributos e métodos,
bem como conheceremos os tipos de dados primitivos.
Veremos que existem várias formas de associação de classes, e tais as-
sociações fazem surgir o conceito de multiplicidade. Esta é o resultado da
necessidade de associação entre as classes, além disso, a multiplicidade nos
mostra a cardinalidade de uma associação. Veremos, também, as várias for-
mas de associação entre classes, entre elas, a unária, a binária, a agregação
regular e a composição, a generalização e as classes associativas.
Aprenderemos, também, que, na herança múltipla, uma subclasse é
derivada de mais de uma superclasse, a qual evidencia somente uma parte
do conceito representado 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.
Mesmo mais complexa, porém, a herança múltipla tem a vantagem de
oferecer mais capacidade de especificação de classes e mais oportunidade
de reutilização. A desvantagem é, justamente, como já citamos, a perda em
simplicidade conceitual e implementação.
Então, o que estamos esperando? Vamos ao trabalho! Boa leitura a todos.
1
DIAGRAMA
UNIDADE 3
DE CLASSES
Como vimos, após a elaboração do diagrama de caso de uso, podemos modelar a

primeira versão do diagrama de classes, o qual 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 classificados
como pertencentes a um mesmo tipo.
Objeto é qualquer elemento concreto ou abstrato com existência perceptí-
vel no mundo real e que possa ser individualizado por possuir características e
comportamento próprio.
Na Figura 1, temos o exemplo de objetos de mundo real que, na verdade, são
funcionários com características em comum, por exemplo: todos os funcionários
possuem nome, endereço e telefone, dessa forma, podemos abstrair para criar um
objeto conceitual a partir dos objetos do mundo real.
72
UNICESUMAR
Figura 1 - Objetos do mundo real / Fonte: os autores.
Uma classe é uma estrutura que modela um conjunto de objetos cujas caracterís-
ticas 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 atribu-
tos. As classes, juntamente com os atributos, as operações e associações, são de-
finidas em um diagrama de classe. Porém, não existe uma receita ou um método
para a escolha das classes do sistema, esta tarefa depende, fundamentalmente, da
experiência do desenvolvedor.
No início do projeto, as classes são denominadas “candidatas” ou “análise”, pois
existe uma probabilidade muito grande de que mudem ao longo dele. Antes de
aprendermos como fazer, apresento a notação para classes.
explorando Ideias
Os diagramas de classe são usados no desenvolvimento de um modelo de sistema orien-

tado a objetos para mostrar as classes de um sistema e as associações entre essas classes.
Em poucas palavras, uma classe de objeto pode ser pensada como uma definição geral de
um tipo de objeto do sistema. Uma associação é um link entre classes que indica algum
relacionamento entre essas classes. Consequentemente, cada classe pode precisar de al-
gum conhecimento sobre sua classe associada. Quando você está desenvolvendo modelos,
durante os estágios iniciais do processo de engenharia de software, os objetos representam
algo no mundo real, como um paciente, uma receita médica, um médico etc. Enquanto uma
aplicação é desenvolvida, geralmente é necessário definir objetos adicionais de implemen-
tação que são usados para fornecer a funcionalidade requerida do sistema.
73
2
NOTAÇÃO
UNIDADE 3
PARA CLASSES
Uma classe é representada por um retângulo e Aluno

pode ser apresentada somente com o seu estereóti-
po (nome da classe). Por convenção, todo nome de
Figura 2 - Notação simplifica-
classe deve começar com uma letra maiúscula e, de da de uma classe / Fonte: os
preferência, não pode conter letras não ASCII (ca- autores.
racteres de língua de origem latina, como caracteres acentuados). Portanto, não
é possível declarar uma classe com qualquer caractere especial (@, #, $, %, &, *,
_ etc.). Caso o nome de uma classe seja composto por mais de uma palavra, a
primeira letra de cada uma delas deve ser maiúscula.
A classe também pode ser apresentada como um Aluno

retângulo com dois compartimentos, em que o pri-
- Nome : String
meiro contém o nome da classe, e o segundo contém - Endereco : String
os atributos juntamente com seu tipo de dados. - Data_nasc : Date
Figura 3 - Notação com nome

da classe e atributos / Fonte:
os autores.
74
Por fim, a classe também pode ser
UNICESUMAR
apresentada em um retângulo divi-
dido em três compartimentos, como
ilustra a Figura 4.
Figura 4 - Notação com nome, atributos e mé-

todos / Fonte: os autores.
pensando juntos
Uma classe abstrata não gera objetos, porque, geralmente, ela tem, no mínimo, uma ope-
ração abstrata nela definida. Se ela, na verdade, criasse um objeto, uma mensagem invo-
cando a operação abstrata do objeto provocaria um erro de run-time.
(Ian Sommerville)
75
3
ATRIBUTOS
UNIDADE 3
E MÉTODOS
Atributos
O dicionário Michaelis ([2020], on-line)3 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 e, também,
são denominados variáveis de classe. O atributo é um elemento da classe que
pode representar uma característica dos objetos instanciados.
A sintaxe (assinatura) para declaração de um atributo em UML tem o se-
guinte formato:
[<visibilidade>]<nome>:[<tipo>][=<valor inicial>]
Figura 5 - Sintaxe para declaração de um atributo em UML / Fonte: os autores.
Entenderemos, agora, cada um dos elementos da sintaxe. Gostaria de abrir um

parêntese 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.
76
<visibilidade>
UNICESUMAR
A visibilidade nos informa quais são as classes que podem ver esse atributo. Te-
mos 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.
Métodos definidos na classe e nas classes derivadas

# Protegido
podem vê-lo.
~ Pacote Visível dentro das classes do pacote.
Quadro 1 - Representação da visibilidade e seu significado / Fonte: os autores.
<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, cedilhas etc.).
■ 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 uma delas deve ser em maiúscula.
<tipo>
Pode-se utilizar os tipos da linguagem de programação de implementação. Lis-

taremos alguns tipos primitivos e, 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.
77
■ Int: 4 bytes.
UNIDADE 3
■ Long: 8 bytes.
■ Reais em ponto flutuante: igual aos inteiros, também diferem nas preci-
sõ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.
Na Figura 6, podemos observar que o
atributo nome tem visibilidade privada, ou
seja, somente os métodos desta classe pode-
rão realizar operações com esse atributo. O
atributo sexo é protegido, podendo ser vis-
to somente nesta classe ou em classes deri-
vadas, observe que esse atributo é iniciado
com o valor ‘F’, que implica dizer que sem-
pre que um objeto for instanciado, receberá
Figura 6 - Classe com os compartimentos
o valor ‘F’. Por fim, o atributo código tem a de nome e atributos / Fonte: os autores.
visibilidade pública, que significa dizer que
esse atributo está visível para todas as classes.
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 aos 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.
78
A sintaxe para declaração de um método é semelhante à declaração de atri-
UNICESUMAR
butos, vamos lá:
[<visibilidade>]<nome>(<lista argumentos>):[<retorno>]
Figura 7 - Sintaxe para declaração de um método / Fonte: os autores.
<visibilidade>
Notação Nome Significado
+ Público Todas as classes têm acesso.
- Privado Somente métodos definidos na classe podem vê-lo.
Métodos definidos na classe e nas classes derivadas

# Protegido
podem vê-lo.
~ Pacote Visível dentro das classes de um pacote.
Quadro 2 - Representação da visibilidade e seu significado / Fonte: os autores.
<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 utili-

zaremos para passar dados aos mé-
todos, e esses métodos trabalharão,
especificamente, em cima destas in-
formações. Por exemplo:
Figura 8 - Lista de argumentos do método /

Fonte: os autores.
79
<retorno>
UNIDADE 3
Tipo do dado retornado pelo argumento. Pode-se utilizar os tipos da linguagem

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 mesma forma que o tipo de dados de intei-
ros, os tipos de dados reais também diferem nas precisões e podem ser
positivos ou negativos:
■ Float: 4 bytes.
■ Double: 8 bytes.
No diagrama a seguir, podemos observar que, para o método calcularIdadeEm-

Meses funcionar, deverá ser transmitida a data de nascimento e, após o cálculo
para transformar em meses, o método retornará um valor inteiro correspondente
à quantidade de meses de vida.
Figura 9 - Retorno do método / Fonte: os autores.
80
4
MULTIPLICIDADE
UNICESUMAR
ENTRE AS
ASSOCIAÇÕES
de classes
Associação é uma relação entre duas classes, significando que os seus objetos pos-
suem 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).
Quadro 3 - Representação da notação e seu significado / Fonte: os autores.
81
Vamos exemplificar: o diagrama de classes da Figura 10 nos mostra o relacio-
UNIDADE 3
namento entre as classes Aluno e Disciplina, e, para definir a multiplicidade do

relacionamento, 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 a 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 a seguir:
■ Da esquerda para a direita:
■ Um aluno pode cursar somente uma disciplina.
■ Da direita para a esquerda:
■ Uma disciplina pode ser cursada somente por um aluno.
Figura 10 - Multiplicidade um para um / Fonte: os autores.
Vamos exercitar um pouco: a Figura 11 nos mostra as classes Aluno e Disciplina

sem a multiplicidade.
Aluno Disciplina
Figura 11 - Sem declaração de multiplicidade / Fonte: os autores.
Definiremos uma ação entre as classes para definir a multiplicidade. Pense na

palavra “cursa”, uma vez que o aluno cursa a disciplina. Então, ficará como apre-
sentado na Figura 12:
Aluno Disciplina
Cursa 1..*
Figura 12 - Identificação da associação / Fonte: os autores.
82
O próximo passo é fazer aquela pergunta da esquerda para a direita:
UNICESUMAR
■ Um aluno cursa quantas disciplinas?
■ Nossa resposta, agora, será: no mínimo, uma, no máximo, várias dis-
ciplinas.
Nosso diagrama de classes ficará como na Figura 13:
Aluno Disciplina
* Cursa 1..*
Figura 13 - Multiplicidade um ou muitos / Fonte: os autores.
Por fim, o próximo passo é fazer aquela pergunta da direita para a esquerda:
■ Uma disciplina pode ser cursada por quantos alunos?
■ Nossa resposta, agora, será: vários alunos.
Nosso diagrama de classes ficará como na Figura 14:
Aluno Disciplina
* Cursa 1..*
Figura 14 - Multiplicidade um ou muitos para muitos / Fonte: os autores.
Perfeito! Agora nosso diagrama está completo! Fácil, não é!? Testaremos outras
cardinalidades: supondo que um aluno pode cursar somente uma disciplina, mas
a disciplina pode ser cursada por, no mínimo, um e, no máximo, muitos alunos,
nosso diagrama ficará como na Figura 15:
Aluno Disciplina
1..” Cursa 1
Figura 15 - Multiplicidade somente um para um ou muitos / Fonte: os autores.
83
5
TIPOS DE
UNIDADE 3
ASSOCIAÇÃO
entre classes
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 16 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 or-
dens, e um trabalhador pode ter nenhum chefe ou, 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 16 - Associação unária / Fonte: os autores.
84
Associação binária
UNICESUMAR
As associações binárias são as mais comuns, elas acontecem entre duas classes.
Fazendo a leitura do diagrama da Figura 17, podemos verificar que uma instância
de objeto da classe cliente está associada a 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 17 - Associação binária / Fonte: os autores.
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 18 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, neste caso, pode ter uma ou várias regras para aquele contrato específico.
Contrato Cliente
0..” 1..”
1..”
Regras do
Contrato
Figura 18 - Associação ternária / Fonte: os autores.
85
Classe associativa
UNIDADE 3
De acordo com Sommerville (2011), quando uma associação possuir atributos pró-
prios, pode-se criar uma classe associativa. Estas classes são úteis quando queremos
armazenar o histórico de uma associação (relacionamentos que ocorrem e inte-
ressam ser salvos). Enumeraremos 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 19, 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 permite ar-
mazenar cada um dos itens de produto, juntamente com a quantidade e o valor
total, e uma classe separada.
Produto Venda
* *
Itens da Venda
Itens da Venda
Figura 19 - Classe associativa / Fonte: os autores.
Agregação
Lee e Tepfenhart (2002) explicam que a agregação é um caso especial de associa-

çã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
86
representa uma ligação entre o objeto todo (a janela) e as partes (botão, caixas
UNICESUMAR
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 se
deslocam também. A agregação pode ser regular ou de composição. Veremos a
diferença entre elas.
Agregação regular
De acordo com Lee e Tepfenhart (2002), a agregação regular é representada por

um losango vazado. O diagrama da Figura 20 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 20 - Agregação regular / Fonte: os autores.
No exemplo da Figura 21, verificamos que, em um quadro, podem ter uma ou

várias figuras, ou seja, a figura é uma parte do quadro, porém ela existe mesmo
que não exista um quadro para ela.
Quadro Figura
1..”
O objeto figura existe sem o

objeto quadro
Para ficar ainda mais claro, utilizaremos o exemplo da Figura 22, o qual 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. Neste caso,
podemos afirmar que a destruição do objeto CPU não implicará a destruição dos
demais objetos associados.
87
UNIDADE 3
CPU
1 1 1 0..”
Monitor Teclado Mouse Drive
Agregação de composição
Lee e 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 ambos, 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 23, a agregação de composição é repre-
sentada por um losango preenchido. O diagrama a seguir 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 a destruição da instância de objeto associado da classe B.
A B
B não existe sem A
Figura 23 - Agregação de composição / Fonte: os autores.
Na Figura 24, podemos verificar que um orçamento pode ter muitos itens, porém
os itens de orçamento não existirão sem o orçamento.
88
Na Figura 25, o diagrama nos diz que um documento é composto de nenhum
UNICESUMAR
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 a
destruição das instâncias de objetos das outras duas classes agregadas.
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.
Generalização
Veremos, 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, classes mãe e filha, respectivamente.
Em outras palavras, a generalização é um relacionamento entre um elemento
geral e um outro mais específico. Este último possui todas as caracterí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 di-
videm em generalização de sobreposição, exclusiva, total e parcial. A generalizaçã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 genera-
lização, é enfatizado o conceito de herança, que tem como característica a reu-
tilização de atributos e métodos definidos nas classes mais gerais (superclasse)
por classes mais específicas (subclasses), ou seja, permite a criação de elementos
especializados em outros. Por sua vez, as subclasses, que representam 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.
89
A Figura 26 modela uma generalização para pessoa. Uma pessoa pode ser
UNIDADE 3
física ou jurídica, porém o que diferencia os tipos de pessoas é um atributo es-

pecífico que identifica a 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().
Figura 26 - Generalização / Fonte: os autores.
Cobertura total
A generalização apresenta um conceito importante: a cobertura. A notação para

a cobertura é uma linha tracejada com o tipo de cobertura entre chaves. Dize-
mos que a cobertura é total ou completa se cada elemento da classe genérica é
mapeado para, pelo menos, um elemento das classes especializadas.
Na Figura 27, verificamos que a cobertura da generalização é total, o que
significa dizer que uma pessoa, obrigatoriamente, tem que ser homem ou mulher.
Figura 27 - Generalização com cobertura total / Fonte: os autores.
90
Exclusiva
UNICESUMAR
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 28, refinamos o diagrama do exemplo anterior, juntando as cober-
turas total e exclusiva. Dessa forma, temos que uma pessoa será, obrigatoriamente,
um homem ou uma mulher, não podendo ser os dois.
Figura 28 - Generalização com cobertura total e exclusiva / Fonte: os autores.
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 29 nos mostra que um veículo pode ser um carro ou uma bicicleta,
podendo não ser nenhum dos dois. Percebam que, neste tipo de cobertura, não
sou obrigado a especializar o veículo, diferentemente da cobertura total que, obri-
gatoriamente, devo mapear para, pelo menos, uma subclasse.
Figura 29 - Generalização com cobertura parcial / Fonte: os autores.
91
Sobreposição
UNIDADE 3
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 30, podemos verificar que uma pessoa pode ser aluno ou professor,
podendo ser os dois.
Figura 30 - Generalização com cobertura de sobreposição / Fonte: os autores.
As coberturas podem ser combinadas da seguinte forma:

■ Total, exclusiva: nesta combinação de cobertura, uma classe genérica deve
ser mapeada para uma única subclasse.
■ Total, sobreposição: nesta combinação de cobertura, uma classe genérica
deve ser mapeada para uma ou várias subclasses.
■ Parcial, exclusiva: nesta combinação de cobertura, uma classe genérica
pode ser mapeada para uma única subclasse ou para nenhuma.
■ Parcial, sobreposição: nesta combinação de cobertura, uma classe gené-
rica pode ser mapeada para uma ou mais subclasses ou para nenhuma.
92
6
HERANÇA
UNICESUMAR
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 31, 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 subclasse
Extensão herdará atributos e métodos das superclasses Curso e Evento.
Figura 31 - Herança múltipla / Fonte: os autores.
93
A herança múltipla permite a concatenação (mesclagem) de informações de duas
UNIDADE 3
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 é ter mais capacidade de especificação de classes e
mais oportunidade de reutilização. Ela traz a modelagem de objetos mais próxima
da maneira como se costuma pensar. A desvantagem é a perda em simplicidade
conceitual e de implementação.
explorando Ideias
Herança múltipla dá-se quando uma subclasse herda atributos e operações de duas ou
mais superclasses. Este tipo de situação deve ser evitado. Apesar de a orientação a obje-
tos prever esta situação, ela introduz possibilidades de difícil solução.
Fonte: Medeiros (2004, p. 80).
94
UNICESUMAR
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 objetos
no sistema e os vários tipos de relacionamentos estáticos que existem entre eles.
Mostra os atributos e as 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 objetos
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.
Familiarizamo-nos com o conceito e a sintaxe dos atributos e aprendemos
que são estes elementos que definem a estrutura de uma classe, representando
uma característica dos objetos instanciados. Aprendemos, também, que são os
métodos que determinam o comportamento dos objetos de uma classe e são
semelhantes às funções ou aos procedimentos da programaçã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: a associação unária
e binária, as classes associativas, a agregação regular e de composição, a genera-
lização e a especialização. Compreendemos que a 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, comunicaçã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 diagrama de classes.
95
na prática
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 são 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?
96
aprimore-se
SISTEMA DE INFORMAÇÃO ORIENTADO A OBJETOS COM AGENTES INTE-

LIGENTES
[...] O modelo apresentado é baseado na aplicação da tecnologia de agentes inte-

ligentes aos sistemas de informação contábeis, buscando aperfeiçoar a maneira
como os sistemas disponibilizam a informação aos usuários, proporcionando varia-
ções de formatação e detalhamento da informação.
Mesmo sendo o modelo REA o mais aceito para estruturar os fenômenos con-
tábeis, este é eficiente no armazenamento dos dados, mas não no tratamento da
informação (VERDAASDONK, 2003, p. 45). Dessa maneira, se torna necessário o de-
senvolvimento de um sistema destinado ao tratamento dos dados, gerando infor-
mação relevante, confiável e comparável, características estas que determinam a
utilidade da informação contábil (FASB, 1980, p.7).
O desenvolvimento deste modelo é feito através da linguagem de banco de da-
dos orientado a objetos. A utilização de modelagem orientada a objetos foi intro-
duzida no desenvolvimento de sistemas de informação contábeis por Knaus (2001),
mas sua proposta utiliza como base o modelo DCA, sendo cada conta contábil como
classe distinta (KNAUS, 2001, p. 78).
A modelagem de banco de dados orientados a objeto surgiu das limitações dos
bancos de dados relacionais, seu objetivo básico é o gerenciamento de grandes volu-
mes de informação, possuindo maior facilidade no tratamento de dados e atendendo
aos requisitos atuais de sistemas com outros tipos de bancos de dados, como o hiper-
texto, tão amplamente utilizado (SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p.249).
Dentro desta característica a linguagem UML (Unified Modeling Language) pode
ser aplicada, principalmente por ser uma ferramenta apropriada para modelagem
de agentes inteligentes (HEINZE, 2004, p. 41) e baseada em bancos de dados orien-
tados a objetos. Esta abordagem se difere dos sistemas de informação contábeis
tradicionais por separar os dados das operações de modelagem da informação ao
mesmo tempo em que utiliza uma abordagem orientada a objetos.
97
aprimore-se
Visando um melhor desempenho da modelagem proposta, a forma de desen-

volvimento por UML é utilizada para facilitar a visualização e a integração entre os
diferentes objetivos.
Nos sistemas tradicionais os relatórios são desenvolvidos no próprio banco de
dados, enquanto neste modelo REA orientado a objetos (REAOO) os relatórios e
suas análises são desenvolvidos através de agentes inteligentes, baseados em siste-
mas especialistas. A grande diferença se dá na separação da aplicação de contabili-
dade do banco de dados, o que não ocorre normalmente.
Assim, para tal desenvolvimento, a utilização da linguagem UML para a mode-
lagem do sistema é de grande auxílio, é importante ressaltar que o modelo é uma
simplificação da realidade, apresentando um caso geral de um sistema de infor-
mação para qualquer atividade que se deseje assumir. Desse modo, enquanto a
modelagem E-R no modelo REA assume 3 entidades (Recursos, Eventos e Agentes),
para o desenvolvimento da modelagem orientada a objetos estes recursos, eventos
e agentes são as classes a serem implementadas.
Assim, com a utilização de Agentes Inteligentes para o desenvolvimento da infor-
mação para os diferentes tipos de usuário, o esquema externo (conforme modelo
REA) pode ser desenvolvido por meio de Agentes Inteligentes, onde este agente será
um novo ator neste diagrama.
Enquanto os agentes externos podem tomar parte nos eventos de transação
como clientes e fornecedores, os agentes internos atuam na transação, são respon-
sáveis pela intra-ação e alocação de recursos. Além disso, com a inserção de agentes
inteligentes no desenvolvimento e análises de relatórios.
Normalmente, existem muitos objetos similares em um banco de dados, ou seja,
eles respondem às mesmas mensagens, usam os mesmos métodos e têm variáveis
de mesmo nome e tipo. Dessa forma, o agrupamento desses objetos similares se dá
por meio das classes (SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 252).
Com isso, as entidades utilizadas no modelo REA podem ser consideradas como clas-
ses. Na modelagem orientada a objetos para banco de dados, uma classe pode possuir
hierarquia de especialização, ou seja, o relacionamento ISA, que indica uma classe como
sendo especialização de outra (SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 253).
98
aprimore-se
Assim, como na generalização do modelo REA, é possível determinar uma espe-

cialização para as classes de Recursos, Eventos e Agentes, conforme exemplo.
A partir da determinação das classes e suas especializações é possível compor o
modelo geral do diagrama de classes dentro da proposta apresentada no modelo REA.
No modelo REA orientado a objetos (REAOO), um agente econômico, que pode
ser interno ou externo, realiza um ou mais eventos econômicos e o próprio evento
econômico gerado ocasiona a dualidade em relação aos recursos, proporcionando
consumo (custo) e geração (benefício) de um ou mais recursos simultaneamente.
No caso geral da comercialização de um produto fabricado na própria entidade,
um cliente (agente econômico externo) pode adquirir um ou mais produtos com um
vendedor (agente econômico interno), ocasionando um evento econômico (venda)
que terá impacto nos recursos econômicos, seja sob a forma de custo de uma ou
mais unidades, seja na forma de benefício com o recebimento financeiro ou direito
de recebimento futuro.
Este modelo, assim como o formato original do modelo REA, pode ser aplicado a
qualquer situação dentro dos diversos tipos de organizações que realizem ativida-
des econômicas.
A atuação do agente inteligente se dá de maneira autônoma, ou seja, o agente
inteligente é um software separado do banco de dados, que o acessa remotamente
e, atuando 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.
Fonte: Moraes e Nagano (2009, p. 474-475).
99
eu recomendo!
livro
Engenharia de Software
Autor: 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 as-
pectos da produção de software, ela é multidisciplinar e está em
constante mudança.
conecte-se
Para aprofundar os conhecimentos sobre OO, leia o artigo intitulado “AspectJ –

Programação orientada a aspectos em Java”. A Programação Orientada a Aspec-
tos (AOP) procura solucionar algumas ineficiências da Orientação a Objetos, como
o entrelaçamento e o espalhamento de código com diferentes propósitos.
https://homepages.dcc.ufmg.br/~mariza/CELP/sblp2003/sblp2003_files/aspectj.pdf
100
anotações

4
DIAGRAMAS DE
SEQUÊNCIA,
ESTADO
e colaboração
PROFESSORES
PLANO DE ESTUDO
A seguir, apresentam-se as aulas que você estudará nesta unidade: • Avançando nos Diagramas • Dia-
grama de Sequência • Diagrama de Estados • Diagrama de Comunicaçã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.
INTRODUÇÃO
Caro(a) aluno(a), nesta quarta unidade do livro de Análise e Projeto Orien-

tado a Objetos, mostraremos mais alguns diagramas importantíssimos que
complementam e refinam o diagrama de casos de uso e de classes.
Aprenderemos a notação e como utilizar o diagrama de sequência;
desse modo, 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 necessida-
de 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 comportamento modelado por esse diagrama.
Por fim, aprenderemos o diagrama de comunicação, conhecido, tam-
bém, como diagrama de colaboração (UML 1.5). Veremos que esse diagra-
ma 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, considerando 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
unidade, em que teremos a oportunidade de modelar um sistema OO.
Então, o que estamos esperando? Vamos ao trabalho! Boa leitura para você.
1
AVANÇANDO
UNIDADE 4
NOS DIAGRAMAS
Agora que já conhecemos o objetivo e a notação dos diagramas de caso de uso e

de classes, avançaremos um pouco e conheceremos 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, 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 têm documentação que nos permite contar e
entender a sua história. 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, po-
rém o esforço será maior no momento da manutenção, quando nos depararmos
com um software sem documentação; a experiência 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.
104
Vimos, na Unidade 2, que o diagrama de caso de uso é utilizadoRealiza
na análise
UNICESUMAR
empréstimo
de requisitos e acompanha o software desde o seu início até a conclusão. Nesse
diagrama, surge a figura do ator, que pode ser uma pessoa, um sistema, um ro-
Realiza
teador. O ator é quem realiza as atividades e sempre atua sobre um consulta
caso de uso.
Portanto, o diagrama de caso de uso modela o comportamento dos atores no
sistema. Olhando para o diagrama de caso de Aluno
uso da Figura 1, fica claro que o
Realiza
aluno realiza empréstimos, consultas e devoluções, enquanto a bibliotecária
devolução é
quem cria o livro, o aluno e os empréstimos no sistema.
Realiza Cria
empréstimo livro
Realiza Cria
consulta aluno
Bibliotecária
Aluno
Realiza Efetua
devolução empréstimo
Cria
Porém, o diagrama de casos de livrouso nos fornece apenas um panorama visual das
funcionalidades do sistema, sendo necessário um detalhamento por meio de uma

descrição textual, mas não háCria descrição padrão definida pela UML; em geral, o
aluno
diagrama é bastante informal.
Bibliotecária
É evidente, então, que o diagrama por si só não é suficiente. Os casos de uso
deEfetua
devem vir acompanhadosempréstimo uma descrição. Após a elaboração do diagrama de
caso de uso e sua descrição, teremos conhecimento suficiente a respeito do do-
mínio para modelar a primeira versão do diagrama de classes, que nos mostrará
a estrutura estática do sistema.
explorando Ideias
É a classe que nos fornecerá a estrutura para modelar um conjunto de objetos com carac-
terí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: os autores.
105
2
DIAGRAMA
UNIDADE 4
DE SEQUÊNCIA
O diagrama de sequência é o próximo que conheceremos a notação. Sua utilidade

é estudar as interações entre os objetos, possibilitando a identificação de relação
entre as classes, servindo para refinar o diagrama delas.
O cenário da Figura 2 mostra a solicitação de um empréstimo pelo aluno. A
partir dessa ação, desencadeia-se um conjunto de mensagens entre os objetos
que permitem a verificação da existência da pessoa aluno, e, em seguida, cria-se
o item de empréstimo, o qual verifica a existência do exemplar solicitado, reali-
zando 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 identificação das relações entre elas.
106
UNICESUMAR
s
Figura 2 - Diagrama de sequência / Fonte: os autores.
Muito bem, mas como posso interpretar esse diagrama? A resposta é: conhecendo
sua notação. Vamos lá!
107
Notação do Diagrama de Sequência
UNIDADE 4
O diagrama de sequência da Figura 3 tem todos os elementos da notação desta-

cados por uma elipse vermelha, em que é possível observar as mensagens (sín-
cronas, assíncronas, reflexiva), a linha do tempo, o tempo de atividade e objetos.
Vamos conhecê-los em detalhes.
Figura 3 - Modelo de diagrama de sequência / Fonte: os autores.
Timeline
Linha do Tempo
As timelines, ou linhas de vidas, fazem
parte da dimensão vertical do diagra-
ma. A linha de vida é composta por
duas partes: cabeça e cauda. A cabeça
é representada por um retângulo, no
qual é exibida a identificação do objeto,
a cauda corresponde a uma linha verti-
cal tracejada.
Figura 4 - Timeline (linha de vida ou tempo) /
Fonte: os autores.
108
Mensagens
UNICESUMAR
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 par-
te a seta é aquele que está enviando
a mensagem (objeto remetente). O
objeto para o qual a seta aponta é Figura 5 - Mensagens síncrona e assíncrona /
aquele que está recebendo a mensa- Fonte: os autores.
gem (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.
Como podemos verificar na Figura 5, 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 aguardando a
resposta do receptor e são representadas por uma seta com a ponta preenchida.
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 aguardando a resposta do receptor e são representadas por uma seta com
a ponta vazada. Não há 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 6:
Figura 6 - Auto mensagem síncrona / Fonte: os autores.
109
Tempo de atividade
UNIDADE 4
Os objetos, também, apresentam um tempo de atividade na linha do tempo, e 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 7:
Figura 7 - Tempo de atividade / Fonte: os autores.
Exemplo
Já conhecemos a notação do diagrama de sequência, agora, praticaremos um pouco.

Para facilitar o entendimento da notação, utilizaremos um exemplo da Unidade 2,
na qual apresentamos 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 detalhar
os casos de uso. Na Figura 8, apresentaremos um diagrama de casos de uso que
mostra o ator “Operador” interagindo com o caso de uso “Cadastrar Pessoas”.
Cadastrar Pessoas
Operador
Figura 8 - Caso de uso / Fonte: os autores.
110
O Quadro 1 mostra a descrição textual para o caso de uso “Cadastrar Pessoas”,
UNICESUMAR
vejamos:
Nome do caso de uso Cadastrar Pessoas.
Permite inserir novos dados cadastrais

Descrição
de pessoas no sistema.
Ator Operação.
Dados gravados ou cancelamento da

Pós-condições
operação pelo Operador.
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
Se o usuário fornecer entradas que não

obedecem às regras de entrada (más-
A1: em {Valida expressão} cara de entrada, intervalo, datas etc.),
informá-lo sobre o erro e retornar ao
fluxo básico em {Solicita expressão}.
O usuário pode decidir encerrar o caso

A2: em {Solicita expressão} de uso sem fornecer os dados. Nesse
caso, retornar ao fluxo básico em {Fim}.
Quadro 1 - Descrição textual para o caso de uso / Fonte: os autores.
111
Essa descrição textual detalha o caso de uso, mostrando as prés e pós-condições
UNIDADE 4
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, dentre 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, des-
viando 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,
definiremos as linhas do tempo, teremos uma para o usuário, outra para a inter-
face 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 9 - Linhas do tempo para calculadora / Fonte: os autores.
112
Em seguida, o sistema solicitará a expressão para o usuário, enviando uma mensa-
UNICESUMAR
gem síncrona para a interface usuário, que deverá aguardar a resposta do Usuário
para a continuação, conforme a figura a seguir.
Usuário
1.1: Expressão? ( ) 1: SolicitarExpressao ( )
{Exp}
{Exp}
Figura 10 - Diagrama de sequência com troca de mensagens entre usuário e sistema / Fonte:
os autores.
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 10 - Diagrama de sequência para Resolver Expressões Aritméticas / Fonte: os autores.
113
3
DIAGRAMA
UNIDADE 4
DE ESTADOS
Nesta aula, veremos o diagrama de estados, que tem como objetivo especificar o com-
portamento 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 com-
portamentos 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 comporta-
mento interno da classe, permitindo a especificação da sua dinâmica. Uma especifi-
cação corresponde a como deve ser implementada uma classe.
Estado
O estado representa a situação ou momento no tempo de vida de um objeto, o

qual 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.
114
Todos os objetos possuem um estado que, normalmente, é determinado pelos
UNICESUMAR
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 A notação para o estado final é um

círculo preenchido, como mostra a círculo preenchido com borda, como
Figura 11: mostra a figura a seguir:
Figura 11 - Estado inicial / Fonte: os autores. Figura 12 - Estado final / Fonte: os autores.
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 13 - Estado simples / Fonte: os autores.
O estado simples, também, pode ser representado por um retângulo com dois
compartimentos. No primeiro compartimento, é informado o nome para o es-
tado, e, no segundo compartimento, as ações.
StateName
entry / action
do / action
exit / action
Figura 14 - Estado / Fonte: os autores.
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.
115
Estado Composto
UNIDADE 4
Estado Estado
Figura 15 - Estado composto / Fonte: os autores.
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 16 - Estado de escolha / Fonte: os autores.
A junção é o contrário do estado de escolha, ou seja, vários estados podem chegar a um

único estado. Nesse caso, a representação é feita por meio de um círculo preenchido.
Estado 2
Estado 1 Estado 3
Estado 4
Figura 17 - Estado de junção / Fonte: os autores.
116
O fork, representado por um retângulo preenchido, indica estados concorrentes.
UNICESUMAR
Quando um estado chega ao fork, desencadeia um ou mais estados concorrentes.
Estado 1
Estado 2 Estado 3 Estado 4
Figura 18 - Estado fork / Fonte: os autores.
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.
Estado 1 Estado 2
Estado 3
Figura 19 - Estado de join (junção) / Fonte: os autores.
E, por último, as ações. Elas ocorrem em três eventos: quando entra (entry), sai
(exit) ou quando está (do) em um estado.
Estado 1 Estado 2
entry / funcaoX funcaoZ( ) (Z>1) exit / funcaoY
Figura 20 - Ações do estado / Fonte: os autores.
117
De acordo com o diagrama de estados apresentado na Figura 15, a funcaoX será
UNIDADE 4
executada no momento em que entrar no Estado1. Na transição do Estado1 para

o Estado2, será executada 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 12 mostra que, quando
um exemplar estiver 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 exemplar_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, é 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 21 - Diagrama de estado / Fonte: os autores.
118
4
DIAGRAMA
UNICESUMAR
DE COMUNICAÇÃO
Vamos para o último diagrama, conhecido como diagrama de colaboração até

a versão 1.5 da UML, e que teve sua denominação modificada para diagrama de
comunicação na versão 2.0 da UML.
O diagrama de comunicação é outra forma de representar o cenário. Ele con-
té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
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 quatro elementos:
■ Ator.
■ Objetos.
■ Vínculos.
■ Mensagens.
119
Notação para o Diagrama de Co-
UNIDADE 4
municação
Ator
O ator tem a mesma representação dos demais diagra- :Ator

mas, ou seja, o homem palito, com seu rótulo precedido
Figura 22 - Ator /
de dois pontos. Fonte: os autores.
Objeto
O objeto é representado por um retângulo, em que, em seu interior, são infor-

mados o objeto e o nome da classe à qual aquele objeto pertence, separados por
dois pontos, que definimos como instância identificada.
umaPessoa : Pessoa
Figura 23 - Instância identificada / Fonte: os autores.
O objeto, também, pode ser representado somente com a identificação da classe

em seu rótulo.
Pessoa
Figura 24 - Classe / Fonte: os autores.
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 25 - Instância / Fonte: os autores.
120
Vínculo
UNICESUMAR
O vínculo é a ligação entre dois objetos, que identifica o envio e o recebimento
de mensagens.
: umaPessoa
: Médico
Figura 26 - Vínculo / Fonte: os autores.
Mensagens
As mensagens enviadas e recebidas são representadas por setas que apontam suas
direções, e a descrição da mensagem vem acompanhada do seu número de ordem.
1: Consulta ( )
2: fazDiagnóstico ( )
3: aplicaMedicação ( )
: umPaciente
: Médico 4: Sara ( )
Figura 27 - Troca de Mensagens / Fonte: oss autores.
Exemplo
O diagrama de comunicação da Figura 28 exemplifica a troca de mensagens

entre os objetos. Podemos verificar que o objeto GUI Bibliotecária envia uma
mensagem 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.
121
Após a validação do aluno, o objeto empréstimo envia uma mensagem para o
UNIDADE 4
item empréstimo validar (3) o exemplar que está sendo emprestado, porém, para
o 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 ( )
Item Empréstimo
4: Valida ( )
Exemplar
Figura 28 - Diagrama de Comunicação / Fonte: o autor.
pensando juntos
Se o diagrama de sequência já cria o cenário que mostra a troca de mensagens entre os

objetos, qual é a necessidade de elaborar, também, o diagrama de comunicação?
122
UNICESUMAR
Nesta unidade, aprendemos mais três diagramas importantes para análise e projeto
orientado a objetos, sendo eles: diagramas de sequência, de colaboração e de estado.
Familiarizamo-nos com a notação e com o modo de utilizar o diagrama de
sequência; 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 sistema
irá funcionar, representando toda a ordem de comunicação entre classes por meio
do diagrama de colaboração. Aprendemos que, diferentemente do diagrama 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
atalhos, e o tempo tratará de refinar sua arte. Então, programar é uma arte? Sim,
consideramos 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 os contornos. A
diferença é que nem sempre produzimos aquilo que gostaríamos, mas, sim, aquilo
para o qual fomos contratados, por isso, há necessidade de apresentar habilidades
que permitam agregar pessoas.
123
na prática
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? Explique.
3. Sabemos que o diagrama de comunicação é outra forma de modelar o cenário do

software; então, quando devemos utilizá-lo?
4. Qual é a diferença entre os diagramas de sequência e comunicação?
124
aprimore-se
Prezado(a) aluno(a), segue uma matéria muito interessante sobre UP, um processo
unificado e estabelecido para o desenvolvimento de software, resultado de três dé-
cadas de desenvolvimento e de uso prático.
ENGENHARIA DE REQUISITOS E O UP
A engenharia de software se produz por meio de um conjunto de fases. Cada uma

das fases pode envolver métodos, ferramentas e procedimentos, cujas formas de
estruturação são citadas como modelo de engenharia de software (PRESSMAN,
2002). Ainda segundo Pressman (2002), independentemente do modelo de desen-
volvimento de software, o processo contém três fases genéricas: definição, desen-
volvimento e manutenção.
Quatro modelos de engenharia de software têm sido amplamente discutidos: o
ciclo de vida clássico (ou cascata), a prototipação, o modelo espiral e as técnicas de
Quarta Geração (PRESSMAN, 2002). Atualmente, um novo modelo tem sido bastante
usado: o modelo iterativo e incremental (JACOBSON; BOOCH; RUMBAUGH, 1999;
PAULA FILHO, 2001).
A análise de requisitos é uma etapa presente na fase de definição do software, in-
dependentemente do modelo de engenharia de software adotado. Paula Filho (2001)
afirma que a engenharia de requisitos é formada por um conjunto de técnicas em-
pregadas para levantar, detalhar, documentar e validar os requisitos de um produto
de software. Assim, é possível definir a engenharia de requisitos como um campo da
engenharia de software que visa a aplicação de técnicas de engenharia em métodos
de análise de requisitos, que efetua a ligação entre a necessidade de informatização
de processos e o projeto do software que atenderá a tais necessidades.
No decorrer das duas últimas décadas, uma série de métodos de análise e especi-
ficação de requisitos foi desenvolvida, sendo poucas as propostas que visam a siste-
matização da definição de requisitos de forma menos subjetiva (SANTANDER, 2002).
125
aprimore-se
O UP (Processo Unificado) é um processo estabelecido para o desenvolvimento

de software resultado de três décadas de desenvolvimento e de uso prático. Jacob-
son, Booch e Rumbaugh (1999) apresentam as origens do UP no processo Objectory,
que teve sua primeira versão apresentada em 1987, passando pelas contribuições
do Processo Rational Objectory (1997), até chegar ao Processo Unificado da Rational
– RUP (KRUCHTEN, 2003). O propósito do UP, como qualquer outro processo de de-
senvolvimento, é determinar um conjunto de atividades necessárias para transformar
requisitos em sistemas de software. Neste caso, utiliza a UML como linguagem para
a modelagem dos artefatos de software produzidos ao longo do processo de desen-
volvimento. O UP é fundamentado em três boas práticas: dirigido por caso de uso,
centrado em arquitetura, iterativo e incremental. Os casos de uso definidos para um
sistema são a base de todo o processo de desenvolvimento. A partir de uma perspec-
tiva de gerenciamento, o ciclo de vida de software do UP é dividido em quatro fases
sequenciais (Concepção, Elaboração, Construção e Transição), sendo que cada fase
refere-se a uma determinada meta a ser atingida ao longo do desenvolvimento.
Cada uma das quatro fases do UP é adicionalmente dividida em iterações e fina-
lizada com um ponto de checagem que verifica se os objetivos daquela fase foram
alcançados. Toda iteração é organizada em termos de workflows de processo, que
são conjuntos de atividades realizadas pelos responsáveis pela produção dos arte-
fatos. Os principais workflows de processo do UP são Levantamento de Requisitos,
Análise, Projeto, Implementação, Teste e Implantação, sendo que o RUP se diferen-
cia, principalmente, em relação ao workflow de Modelagem de Negócio.
126
aprimore-se
A UML foi adotada pela OMG (Object Management Group), em 1997, como lingua-
gem padrão para a modelagem de sistemas orientados a objeto. É uma linguagem
para especificação, visualização, construção e documentação de artefatos de sis-
temas de software, como também para a modelagem de negócios e outros siste-
mas não necessariamente relacionados a software, e representa uma coleção das
melhores práticas de engenharia que comprovaram bom êxito na modelagem de
sistemas grandes e complexos (OMG, 1997). Os principais diagramas da UML são:
Diagrama de Classes, Diagrama de Objetos, Diagrama de Casos de Uso, Diagrama
de Sequência, Diagrama de Colaborações, Diagrama de Gráficos de Estados, Diagra-
ma de Atividades, Diagrama de Componentes, Diagrama de Implantação.
A UML também permite a ampliação da linguagem de maneira controlada, por
meio de mecanismos de extensão, de forma a expressar todas as nuances possíveis
de todos os modelos em qualquer domínio de análise (exemplo: análise de negó-
cios), fornecendo alguma flexibilidade.
Fonte: adaptado de Junior e Campos (2008, p. 28).
127
eu recomendo!
livro
UML e C++: guia prático de desenvolvimento orientado a

objetos
Autores: Richard C. Lee e William M. Tepfenhart
Sinopse: este livro prático é um guia autoexplicativo para ana-
listas e desenvolvedores de software. Ele ensina como realmen-
te praticar modelagem orientada a objeto, usando a notação da
UML, e implementar o modelo com C++. Os autores apresentam todos os con-
ceitos básicos da tecnologia orientada a objeto, que são necessários para que os
leitores possam entender e aplicar o paradigma orientado a objeto.
conecte-se
Da mesma forma que é impossível construir uma casa sem, primeiramente, de-
finir 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/motiva-
cao1.htm
128
anotações

5
ESTUDO
DE CASO
PROFESSORES
PLANO DE ESTUDO
A seguir, apresentam-se as aulas que você estudará nesta unidade: • Ferramentas CASE • Estudo de
Caso • Diagrama de Caso de Uso • Diagrama de Classes • Diagrama de Sequência • Diagrama de Estado
• Diagrama de Comunicação.
Conhecer uma ferramenta CASE para modelagem OO • Fazer a análise e projeto a partir de um estu-
do 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.
INTRODUÇÃO
Caro(a) aluno(a), chegamos à quinta e última unidade do livro Análise e

Projeto Orientado a Objetos. Assim, faremos 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 conosco, a análise e o projeto de
um software, porém, para não precisarmos desenhar os diagramas à mão,
utilizaremos um software para nos auxiliar. Esse software é denominado
ferramenta CASE.
Existem muitas ferramentas CASE no mercado. Como todo produto
de software, existem os softwares proprietários, que necessitam de uma
licença de uso, e os softwares livres, que não necessitam de uma licença de
uso. Optaremos, aqui, por uma ferramenta que seja livre e que atenda às
nossas necessidades.
Apresentaremos a você um estudo de caso em que teremos a oportu-
nidade de modelar um software orientado a objetos, utilizando uma fer-
ramenta CASE que nos auxiliará na construção dos diagramas. Construi-
remos, 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 dia-
grama de caso de uso, poderemos, então, elaborar o diagrama de classes,
que representa 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 colabo-
raçã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 compor-
tamento da classe por meio de máquinas de estado. Então, o que estamos
esperando? Vamos ao trabalho! Boa leitura!
1
FERRAMENTAS
UNIDADE 5
CASE
Modelar um sistema à 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 tra-
dução livre, significa “engenharia de software auxiliada por computador”. É uma
classificaçã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 inseridas neste material foram feitas com a fer-
ramenta CASE, produzida pela empresa Astah. Desse modo, no material comple-
mentar, disponibilizamos o link para o download dessa ferramenta, que é gratuita.
pensando juntos
É 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?
132
Muito bem, para nossa análise e projeto orientado a objetos, adotaremos a ferra-
UNICESUMAR
menta CASE Astah Community, por oferecer suporte para o modelo de lingua-
gem 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. Pensa que não é possível utilizar um mo-
delo de processo sem ferramentas CASE que o suportem. Invariavelmente, ocorre
que, na primeira manutenção, a documentação fica desatualizada, e, conforme
já discutimos, documentação desatualizada não serve para muita coisa. Porém,
com a utilização de uma ferramenta CASE adequada, fica fácil atualizar a docu-
mentação a cada manutenção.
explorando Ideias
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 livremente, já vem sendo utilizado há mais de um ano por mais
de uma centena de alunos. Para saber mais sobre o FAST CASE, acesse: http://www.inf.
ufsc.br/sbes99/anais/Sessao-Ferramenta-Completo/12-fastcase.pdf
Fonte: o autor.
133
2
ESTUDO
UNIDADE 5
DE CASO
Apresentaremos, 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, e o ob-
jetivo é que façamos a construção dos diagramas UML 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 re-
ferida ferramenta é bem intuitivo, e você não terá dificuldades em desenvolver.
Vamos pôr a mão na massa!
A distribuidora de filmes Fenix é proprietária de vários cinemas em diversas
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, 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 ser exibido em
vários cinemas e, é claro, em várias cidades ao mesmo tempo.
Cada cinema possui uma identificação: um nome fantasia, um endereço e
uma capacidade de lotação. Cada filme é registrado com título, duração, impro-
priedade e um conjunto de atores que formam seu elenco, bem como seu diretor.
134
Os atores de um filme podem atuar em diversos filmes, assim como o diretor
UNICESUMAR
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, definiremos os requisitos funcionais do sistema. Lembrando que
requisito funcional é 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.
4. Os tipos possíveis de usuários são:
a) Administrador: aquele que gerencia questões administrativas, como
permissões, bloqueio 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.
135
3
DIAGRAMA
UNIDADE 5
DE CASO DE USO
Começaremos, então, compondo nosso cenário ao construir, primeiro, o diagra-

ma de caso de uso. Lembrando que esse diagrama nos fornecerá um panorama
dos requisitos funcionais. Estes 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 Use-
Case Diagram, como mostrado na figura a seguir, ou clique no menu Diagram
e escolha a opção UseCase Diagram.
Figura 1 - Tela principal do Astah Community / Fonte: os autores.

136
Em seguida, abrirá a tela apresentada na Figura 2. Na elipse vermelha, estão todas
UNICESUMAR
as ferramentas que precisaremos para a confecção do diagrama de caso de uso.
Como você pode observar, o software é bem intuitivo:
Figura 2 - Ferramentas para o diagrama de caso de uso / Fonte: os autores.
Iniciaremos modelando o ator que será o administrador do sistema, pois 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 3 - Ator administrador / Fonte: os autores.
137
O diagrama da Figura 4, agora, completo, mostra o operador do cinema e suas
UNIDADE 5
atribuições de realizar os cadastros de ator, filme, cinemas, salas, bem como fazer
as movimentações de exibir e suspender a exibição de um filme.
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
Para completarmos o diagrama de caso de uso, devemos adicionar, a cada um

deles, uma descrição textual, vamos lá!
138
Ator: Administrador
UNICESUMAR
Cadastrar novos
usuários
Administrador
Figura 5 - Cadastrar novos usuários / Fonte: os autores.
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
1. Solicitar a criação do novo usuário
2. Abre a Janela de Cadastro (A2)
3. Usuário informa os dados
4. Sistema valida a entrada (A1)
5. Sistema salva os dados
6. Fim
Fluxos alternativos
Se o usuário fornecer uma entrada incor-

A1: em {Valida entrada} reta, informá-lo sobre o erro e retornar
ao campo incorreto..

A2: em {Solicita Cancelamento} de uso sem fornecer uma entrada. Nesse
Quadro 1 - Caso de uso: cadastrar novos usuários / Fonte: os autores.
139
UNIDADE 5
Definir permissões
para usuário
Administrador
Figura 6 - Definir permissões para usuário / Fonte: os autores.
Nome do Caso de Uso Definir Permissões para os Usuários.
Permite definir permissões para os

Descrição
usuários.
Ator Administrador.
Pós-condições Permissões concedidas.
Fluxo Básico
1. Solicitar a definição de permissões
2. Abre a Janela de Definição de Permis-

sões (A2)
3. Usuário informa as permissões
6. Fim
Fluxos alternativos

ao campo incorreto.

Quadro 2 - Caso de uso: definir permissões para os usuários / Fonte: os autores.
140
Ator: operador
UNICESUMAR
Cadastrar Elenco
Operador
Figura 7 - Cadastrar ator / Fonte: os autores.
Nome do Caso de Uso Cadastrar Elenco.
Permite inserir novos atores ou diretores

Descrição
no sistema.
Ator Operador.
Pós-condições Novo ator inserido.
Fluxo Básico
1. Solicitar a criação do novo ator
6. Fim
Fluxos alternativos

ao campo incorreto.

Quadro 3 - Caso de uso: cadastrar elenco / Fonte: os autores.
141
UNIDADE 5
Cadastrar Filmes
Operador
Figura 8 - Cadastrar filmes / Fonte: os autores.
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
1. Solicitar a criação do novo filme
6. Fim
Fluxos alternativos

ao campo incorreto.

Quadro 4 - Caso de uso: cadastrar novos filmes / Fonte: os autores.
142
UNICESUMAR
Cadastrar Cinemas
Operador
Figura 9 - Cadastrar cinemas / Fonte: os autores.
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
1. Solicitar a criação do novo cinema
6. Fim
FLUXOS ALTERNATIVOS

ao campo incorreto.

Quadro 5 - Caso de uso: cadastrar novos cinemas / Fonte: os autores.
143
UNIDADE 5
Cadastrar Salas
Operador
Figura 10 - Cadastrar salas / Fonte: os autores.
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
1. Solicitar a criação da nova sala
6. Fim
Fluxos alternativos

ao campo incorreto.

Quadro 8 - Caso de uso: cadastrar novas salas / Fonte: os autores.
144
UNICESUMAR
Exibir Filme
Operador
Figura 11 - Exibir filme / Fonte: os autores.
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
1. Solicitar a exibição do filme
2. Abre a Janela de Movimentação (A2)
3. Usuário altera o status
5. Sistema solicita horário de exibição
6. Usuário informa o horário de exibição
9. Fim
Fluxos alternativos

ao campo incorreto.

Quadro 9 - Caso de uso: exibir filmes / Fonte: os autores.

145
UNIDADE 5
Suspender exibição
de filme
Operador
Figura 12 - Suspender filme / Fonte: os autores.
Nome do Caso de Uso Suspender a Exibição do Filme.
Permite suspender a exibição do filme

Descrição
no sistema.
Ator Operador.
Pós-condições Suspensão da exibição do filme.
Fluxo Básico
1. Solicitar a suspensão de exibição
2. Abre a Janela de Movimentação (A2)
3. Usuário informa o filme
5. Usuário altera o status
7. Fim
Fluxos alternativos

ao campo incorreto

Quadro 10 - Caso de uso: suspender a exibição de filmes / Fonte: os autores.
146
O que fizemos até agora?
UNICESUMAR
■ 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.

■ Elaborar o diagrama de sequência.
■ Elaborar o diagrama de colaboração.
■ Elaborar o diagrama de estado.
147
4
DIAGRAMA
UNIDADE 5
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 mo-
dela 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. Definiremos 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 indi-
cação (impropriedade). Na classe elenco, precisamos registrar o nome do diretor/
ator, a data de nascimento 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 momen-
to, horário de exibição e capacidade. A primeira versão do diagrama de classes
ficará de acordo com a Figura 13.
148
Cinema Filme
UNICESUMAR
- 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 13 - Diagrama de classes - Versão 1.0 / Fonte: os autores.
Como pôde ter percebido, o nosso diagrama de classes está sem as associações,
então vamos completá-lo 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 se associa, uma vez
que o cinema é composto por salas.
Olhe que interessante: sublinhei 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 por quantas salas?
■ Resposta: por uma ou várias.
■ Uma sala compõe quantos cinemas?
■ Resposta: somente um.
149
Sendo assim, nosso diagrama ficou conforme mostrado na Figura 14. Observe
UNIDADE 5
que, na agregação por composição, o losango é preenchido.
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 14 - Associação por agregação / Fonte: os autores.
Agora, verificaremos 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 existir. Vamos
fazer aquelas perguntinhas para verificar a multiplicidade:
■ Uma sala pode exibir quantos filmes?
■ Resposta: somente um.
■ Um filme pode ser exibido em quantas salas?
■ Resposta: 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 15 - Associação por agregação e simples / Fonte: os autores.
150
Vamos para a última associação entre filme e elenco. Nós sabemos que um ator
UNICESUMAR
pode atuar em vários filmes e que um filme pode ter vários atores. Podemos verifi-
car, 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 versão final do nosso
diagrama de classes na Figura 16.
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 16 - Diagrama de classes versão final / Fonte: os autores.
151
5
DIAGRAMA
UNIDADE 5
DE SEQUÊNCIA
Elaboraremos, 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 mu-
danças nas classes após a aná- Filme
lise do diagrama de sequência,
mas, também, pode ser que Operador 1: Solicita Inserir ( )
não ocorra nenhuma mudança 2: Verifica entrada ( )
significativa. Porém o objetivo
é estudar as interações de for- 3: Salva Dados ( )
ma mais profunda. Iniciaremos

4: OK ( )
pelo caso de uso “Cadastrar
Filme”; verificaremos toda a
sequência de mensagens entre
Figura 17 - Diagrama de sequência para inserir filme /
os objetos até a conclusão do Fonte: os autores.
cadastro. 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.
152
O próximo diagrama de se-
UNICESUMAR
Cinema
quência é para o caso de uso
Operador
1: Solicita Inserir ( ) “Cadastrar Cinema”. Nesse
2: Verifica entrada ( ) caso de uso, o operador solici-
ta a inserção de uma nova ins-
3: Salva Dados ( ) tância para a classe cinema, a
classe verifica se a entrada está
4: OK ( )
correta, salva os dados e retor-
na um ok para o operador.
Figura 18 - Diagrama de sequência para cadastrar
cinema / Fonte: os autores.
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.
Elenco Ator Filme
Operador
1: Solicita Inserir ( )
2: Verifica entrada ( )
3: Salva os dados ( )
4: Informa Filme ( )
5: Verifica Filme ( )
5.1: OK ( )
6: Salva os dados ( )
7: OK( )
8: OK( )
Figura 19 - Diagrama de sequência para inserir elenco / Fonte: os autores.

153
O próximo diagrama de sequência é para o caso de uso “Cadastrar Sala”. Nesse
UNIDADE 5
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.
Sala Cinema
Operador
1: Solicita Inserir ( )
3: Verifica Cinema ( )
3.1: OK ( )
4: Salva Dados ( )
5: OK ( )
Figura 20 - Diagrama de sequência para cadastrar sala / Fonte: os autores.
154
O próximo diagrama de sequência é para o caso de uso “Exibir Filme”. Nesse caso
UNICESUMAR
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.
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 21 - Diagrama de sequência para exibir filme / Fonte: os autores.
155
O próximo diagrama de sequência é para o caso de uso “Suspender a Exibição
UNIDADE 5
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
suspenso e exclui de todas as salas que estão sendo exibidas.
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 22 - Diagrama de sequência para suspender a exibição do filme / Fonte: os autores.
156
6
DIAGRAMA
UNICESUMAR
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 necessi-
dade 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 de sua classe.
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, núme-
ros, símbolos). Por meio do atributo “status”, é possível colocar o filme em dois
estados diferentes (“exibindo”, “suspenso”). Portanto, modelaremos o diagrama
de estado somente para a classe Filme.
157
O diagrama de estado da Figura 23 nos
UNIDADE 5
mostra que, caso o objeto esteja no estado

“SUSPENSO”, seu estado será modificado
para “EXIBINDO” e finaliza. Porém, se o SUSPENSO
status já for “EXIBINDO”, então o objeto do / atualiza
não sofrerá nenhuma alteração. O início é
Status = “SUSPENSO”
marcado pela notação do círculo preenchi-
do, os estados possíveis são identificados Status = “EXIBINDO”
pela notação do retângulo com cantos arre-

dondados. O losango indica um estado de
escolha, em que se deve verificar o estado EXIBINDO
atual do objeto para decidir se muda seu
exit / gravar
valor ou não.
Figura 23 - Estado inicial SUSPENSO /
Fonte: os autores.
O diagrama de estado da Figura 24 nos

mostra o caso contrário, ou seja, caso o
objeto esteja no estado “EXIBINDO”, seu
estado será modificado para “SUSPENSO” EXIBINDO
e finaliza. Porém, se o status já for “SUS- do / atualiza
PENSO”, então o objeto não sofrerá nenhu-
Status = “EXIBINDO”
ma alteração.
Status = “SUSPENSO”
SUSPENSO
exit / gravar
Figura 24 - Estado inicial EXIBINDO /

Fonte: os autores.
158
7
DIAGRAMA
UNICESUMAR
DE COMUNICAÇÃO
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 em 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 25 apresenta
o diagrama de comunicação para cadastrar um novo filme. O operador insere
novos dados para o filme, 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 ( )( )
Filme
Operador
4: OK ( )
Figura 25 - Cadastrar filmes / Fonte: os autores.
159
A Figura 26 apresenta o diagrama de comunicação para cadastrar um novo cine-
UNIDADE 5
ma. 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 26 - Diagrama de comunicação para cadastrar cinema / Fonte: os autores.
A Figura 27 apresenta o diagrama de comunicação para cadastrar um novo elen-

co. 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.
2: Valida ( )
3: Salva ( )
1: Insere ( )( ) 4: Informa Filme ( ) 5: Verifica Cinema ( )
Elenco Ator Filme

Operador 8: OK ( ) 7: OK ( ) 6: OK ( )
Figura 27 - Diagrama de comunicação para inserir elenco / Fonte: os autores.
A Figura 28 apresenta o 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 a classe sala, que salva os dados e confirma a
operação para o operador.
160
UNICESUMAR
5: Salva ( )
1: Insere ( )[ ] 3: Verifica Cinema ( )
Sala Cinema
Operador 6: OK ( ) 4: OK ( )
Figura 28 - Diagrama de comunicação para inserir novas salas / Fonte: os autores.
A Figura 29 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 a 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.
2: Verifica Exibição ( )
9: Salva ( ) 4: Altera Statu
1: Solicita Exibição ( ) 3: Verifica Cinema ( )
Sala Cinema
Operador
6: Solicita Horário ( ) 5: OK ( )
7: Informa Horário ( )
Figura 29 - Diagrama de comunicação para exibição do filme / Fonte: os autores.
10: OK ( )
161
A Figura 30 apresenta um diagrama de comunicação para suspender a exibição
UNIDADE 5
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 a 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 30 - Diagrama de comunicação para suspender a exibição do filme / Fonte: os autores.
162
UNICESUMAR
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 criarmos
um cenário do sistema; com ele, podemos verificar quais são os atores que inte-
ragem 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!
163
na prática
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.
164
aprimore-se
A LINGUAGEM DE MODELAGEM UNIFICADA (UML) E USE CASES
A UML (Unified Modelling Language - Linguagem de Modelagem Unificada) surgiu, nos

últimos anos, da união de métodos anteriores para análise e projeto de sistemas
orientados a objetos e em 1997 passou a ser aceita e reconhecida como um padrão
potencial de notação para modelagem de múltiplas perspectivas de sistemas de
informações pela OMG (Object Management Group) (BOOCH et al., 1999). Entre os
métodos que deram origem a esta linguagem de modelagem visual estão: Booch
(BOOCH, 1994), OMT (Object Modelling Technique) e OOSE (Object Oriented Software
Engineering). A UML define um conjunto básico de diagramas e notações que permi-
tem representar as múltiplas perspectivas (estruturais / estáticas e comportamen-
tais / dinâmicas) do sistema sobre análise e desenvolvimento. Dentre os diagramas
podem ser citados: Diagramas de Use Cases, Diagramas de Classes, Diagramas de
Interações (Sequência ou Colaboração), Diagramas de Atividades e Diagramas de
Estado e Transição. As Tabela 1.1, Tabela 1.2 e Tabela 1.3 descrevem brevemen-
te alguns destes diagramas. Informações complementares sobre outros tipos de
representações diagramáticas da UML podem ser encontradas em (BOOCH et al.,
1999; JACOBSON et al., 1999). O ambiente de projeto de moldes de injeção foi gene-
ricamente utilizado como exemplo para a representação de tais diagramas.
Diferente do RM-ODP, a UML oferece um suporte direto para o projeto e im-
plementação de cada perspectiva do sistema em desenvolvimento e também uma
notação para sua representação. Por esta razão, para a sua completa utilização,
torna-se necessário um processo/metodologia que permita a migração e evolução
das informações através das diferentes fases de representação, tais como funcio-
nalidade, análise e projetos, implementação, etc. JACOBSON et al. (1999) fornecem
um processo chamado Processo de Desenvolvimento de Software Unificado (UML
process).TEXEL & WILLIAMS (1997) propõem um processo baseado em Use Cases
combinado com Booch, OMT e UML, para o desenvolvimento de sistemas orienta-
dos a objetos.
165
aprimore-se
Em ambos os processos, os Use Cases definem o primeiro nível de representa-

ção do sistema e resultam de uma fase de captura das "necessidades" a serem aten-
didas pelo mesmo. Os Use Cases representarão, num nível mais geral, as funciona-
lidades do sistema em desenvolvimento e guiarão todas as fases subsequentes de
análise, projeto, implementação e testes do sistema computacional.
Este artigo não tem como objetivo maior explorar o processo a ser aplicado
para a modelagem das informações, visto que se trata de um outro tópico bastante
abrangente. A Figura 3 mostra, de forma simplificada, como tal processo pode ser
desenvolvido (TEXEL & WILLIAMS, 1997).
Com base em uma descrição detalhada do sistema, principalmente enfocando as
expectativas dos usuários em termos de "o que o sistema deveria fazer", Use Cases
potenciais são extraídos, bem como as Categorias do sistema. As Categorias (ou
Pacotes) são outros tipos de elementos da UML e representam os módulos princi-
pais (grupo de objetos com funcionalidade similar) do sistema em desenvolvimento.
Com base nestes dois elementos, uma descrição geral de como as Categorias intera-
gem entre si para executar cada Use Case, pode ser representada por diagramas de
Sequência. Esta fase é definida como análise do sistema onde tais representações
podem ser utilizadas para um melhor esclarecimento e discussão com os usuários
e responsáveis pela implementação do sistema. Numa fase seguinte, caracterizada
com maior ênfase no projeto do sistema, busca-se um refinamento destas repre-
sentações, a nível dos objetos que farão parte do sistema. Ambos os diagramas,
Classes e Interações são utilizados e apoiados por representações mais detalhadas
dos aspectos comportamentais dos objetos, através de diagramas de Estado e Tran-
sição e diagramas de Atividades.
Fonte: Costa (2001, p. 22-26).
166
eu recomendo!
livro
Programação Orientada a Objetos com Java

Autor: 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, uti-
lizando o compilador-padrão e a máquina virtual. Ele foi especi-
ficamente projetado para o ensino introdutório da programação
orientada a objetos, permitindo ao aluno criar objetos de qualquer classe e inte-
ragir 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.
conecte-se
Existem duas versões para a ferramenta Astah Community, a versão professional

e a 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 inseridos neste livro no link a seguir:
http://astah.net/download
Caso tenha dificuldades na confecção do diagrama de caso de uso, sugiro que

assista ao vídeo da professora Decíola Fernandes, da Universidade Rural da Ama-
zônia. O vídeo apresenta um tutorial de quatro minutos, mostrando como usar as
ferramentas. Acesse-o no link disponível em:
https://www.youtube.com/watch?v=VMG0EOangKY
Para aprofundar os conhecimentos sobre OO, leia a tese intitulada “Desenvolvi-

mento 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 em:
http://www.coep.ufrj.br/~tarang/Simulight/Tese_Manzoni.pdf
167
167
conclusão geral
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(a) em sua vida
acadêmica e profissional. Procuramos focar em elementos práticos e teóricos que
contribuam para sua formação e aperfeiçoamento. Os exemplos de estudos de ca-
sos apresentados 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
o(a) desmotivem, talvez, façam você até pensar em desistir, porém a persistência
o(a) levará à 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 leitura 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!
168
referências
BOOCH, G. Object-oriented Analysis and Design. San Francisco: Benjamin- Cummings, 1997.
COLEMAN, D. Desenvolvimento Orientado a Objetos: o Método Fusion. Rio de Janeiro: Cam-

pus, 1996.
COSTA, C. A. A aplicação da linguagem de modelagem unificada (UML) para o suporte ao pro-

jeto de sistemas computacionais dentro de um modelo de referência. Gestão e produção, v.
8, n. 1, p. 19-36, abr. 2001. Disponível em: https://www.scielo.br/pdf/gp/v8n1/v8n1a02.pdf.
Acesso em: 27 jul. 2020.
JACOBSON, I. Object Oriented Software Engineering. Boston: Addison-Wesley, 1995.
JUNIOR, A. P. de A.; CAMPOS, R. de. Definição de requisitos de software baseada numa arquite-
tura de modelagem de negócios. Produção, São Paulo, v. 18, n. 1, 2008. Disponível em: https://
www.scielo.br/pdf/prod/v18n1/a03v18n1.pdf. Acesso em: 27 jul. 2020.
MARTIN, J.; ODELL, J. J. Análise e Projeto Orientados a Objeto. São Paulo: Makron Books, 1995.
MEDEIROS, E. S. de. Desenvolvendo software com UML 2.0: definitivo. São Paulo: Pearson
Makron Books, 2004.
PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books, 1995.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. ed. Porto Alegre:

AMGH, 2011.
SHLAER, S.; MELLOR, S. J. Análise de Sistemas Orientada a Objetos. São Paulo: Makron Books, 1990.
SILVEIRA, D. S.; SCHMITZ, E. A. Fast case: uma ferramenta case para o desenvolvimento visual
de sistemas orientados a objetos. 1999. 4 f. Tese (Mestrado) — Instituto de Matemática / Nú-
cleo de Computação Eletrônica, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 1999.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
RUMBAUGH, J. Object Oriented Modeling and Design. New Jersey: Prentice Hall, 1991.
YOURDON, E. Análise Estruturada Moderna. Rio de Janeiro: Campus, 1990.
REFERÊNCIAS ONLINE
1
Em: https://ampersandcommerce.com/news/agile-test-driven-development-our-way/. Aces-
so em: 27 jul. 2020.
2
Em: http://www.linhadecodigo.com.br/artigo/2958/como-fazer-um-plano-de-testes-basea-
do-em-casos-de-uso.aspx#ixzz3fJNU7NrE. Acesso em: 27 jul. 2020.
³ Em: http://michaelis.uol.com.br/busca?r=0&f=0&t=0&palavra=atributo. Acesso em: 27 jul.

2020.
169
gabarito
UNIDADE 1 aos demais elementos do sistema; esta-

belecer as restrições de prazo e de cus-
1. Maior grau de abstração, pois trata a to; criar uma definição de sistema que
realidade de forma natural, conside- constitua a base para todo o trabalho
rando que o mundo real é formado por subsequente.
objetos.
2. O domínio do problema diz respeito
Encapsulamento que adiciona segu- ao contexto onde o sistema funcionará,
rança à aplicação pelo fato de ocultar portanto, o domínio é a área de alcan-
suas propriedades. ce do sistema ou o seu escopo. Quando
conhecemos o domínio, estabelecemos
Herança permite o reuso do código,
fronteiras, possibilitando a definição de
otimizando a produção da aplicação.
objetivos claros.
Polimorfismo consiste na mudança do
funcionamento de um método herda- 3. Linguagem de modelagem correspon-
do de um ancestral. de à notação, que corresponde ao ponto
principal da comunicação entre os sta-
2. Análise, projeto, implementação, teste,
keholders. Os processos são os passos
implantação, manutenção.
que devem ser seguidos para construir
3. A. o projeto. Um modelo de processo de
4. São 13 diagramas ao todo, divididos em software define a sequência em que as
diagrama estruturais, que definem a es- atividades do processo serão realizadas.
trutura estática do software, e os diagra- 4. Como o modelo de processo em cas-
mas comportamentais, que definem cata tem suas fases bem definidas, é
a dinâmica dos objetos. Os diagramas necessário um amplo entendimento
estruturais são: classes, pacotes, compo- do domínio do problema para a sua
nentes, objetos, implantação e estrutu- utilização. O modelo de processo evo-
ra composta. Os diagramas comporta- lucionário permite compreendermos
mentais são: caso de uso, estados, visão o domínio do problema durante o de-
geral, comunicação, sequência, tempo- senvolvimento, portanto é mais indica-
rização. do quando não há amplo domínio do
5. A. problema.
5. O resultado será a implementação de

um produto que não condiz com a ne-
UNIDADE 2
cessidade do cliente.
1. Identificar a necessidade do usuário; 6. Requisitos são descrições das neces-

executar análise econômica e técnica; sidades para o software. São objetivos
atribuir funções ao hardware, ao soft- ou restrições estabelecidas por clientes
ware, às pessoas, ao banco de dados e e usuários do sistema que definem as
170
gabarito
diversas propriedades do sistema e são 6. É uma classe que surge a partir da as-
classificados como: funcionais (definem sociação de duas outras classes, em que
as funções do sistema, ou seja, o que se a associação possui atributos próprios.
espera que o sistema realize) e não fun-
cionais (definem as características de
qualidade que o sistema deve possuir). UNIDADE 4
1. O objetivo do diagrama de sequência é

UNIDADE 3 fornecer elementos para o refinamento
do diagrama de classes a partir dos es-
1. Não. A classe representa a abstração de tudos das interações entre os objetos, o
um conjunto de objetos do mundo real que possibilita a identificação de rela-
que possui comportamentos e caracte- ção entre as classes. Os principais ele-
rísticas comuns, o objeto é uma ocor- mentos de sua notação é o ator, a time-
rência da classe. line ou linha da vida, as mensagens e o
tempo de atividade.
2. É uma característica da Orientação a
Objetos que possibilita que a classe 2. O diagrama de estados mostra o com-
herde todas as características e comportamento das classes mais comple-
portamentos de outra classe. xas; esse diagrama é indicado para as
classes que apresentam um número
3. A herança múltipla acontece quando
conhecido de estados, dessa forma,
uma classe é derivada de mais de uma
conseguimos prever o comportamen-
superclasse, em que cada superclasse
to do objeto por meio da mudança de
ou classe ancestral representa somente
estados.
uma parte do conceito representado na
subclasse ou classe filha. 3. Devemos utilizar o diagrama de co-
municação quando desejarmos saber
4. Métodos e atributos declarados como
quais são as classes e a ordem de envio
protegidos são vistos pela própria classe
de mensagens, sem nos preocuparmos
e pelas classes derivadas. Já os métodos
com o tempo em que ocorrem as men-
e atributos declarados como públicos
sagens.
são vistos por todas as classes.
4. Ambos os diagramas, diagramas de se-
5. Na agregação regular, uma classe é uma
quência e comunicação, mostram-nos
parte de outra, porém uma existe sem
as mensagens que são trocadas entre
a outra. Já a agregação de composição
as classes e objetos, porém o diagrama
é uma agregação de fato, pois o todo é
de sequência considera o tempo em
composto pelas partes, e, quando o todo
que acontece, as mensagens, e o dia-
é destruído, as partes também serão,
grama de comunicação considera a or-
portanto, na agregação de composição,
dem em que elas acontecem.
as partes não existem sem o todo.
171
gabarito
UNIDADE 5
1. Diagrama de objetos para as classes cinema e sala.
CINEMA
• Cinema_id: “1”
• Nome: “Cine XV” SALA
• Endereço: “Rua Flamingos, 381”
• Sala_id: “2”
• Lotação: “150”
• Horário: “14:00”
• Bairro: “Centro” 1 1... • Capacidade: 75
• Cidade: “Apucarana”
• UF: “PR”
• CEP: “86800-00”
2. Diagrama de implantação para a Distribuidora Fênix
Sitema Gerenciador de Banco de Dados
<<MySQL>>
<<SSL>>
Servidor Web
XAMPP
<<HTTP>>
Operador
Browser
172
gabarito
3. Diagrama de componentes
Mysql Xampp browser
Pesquisar Interface
4. Diagrama de atividades
OPERADOR SISTEMA
Solicita a Mostra
exibição interface
Altera o Validação
status
Informa Encerra
horário
173
anotações

anotações

anotações

Livro - Analise de Projetos OO

Enviado por

Dados do documento

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

Livro - Analise de Projetos OO

Enviado por

Direitos autorais:

Formatos disponíveis

ANÁLISE E PROJETO

NEAD - NÚCLEO DE EDUCAÇÃO A DISTÂNCIA

Bibliotecário: João Vivaldo de Souza CRB- 9-1679

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

Neste mundo globalizado e dinâmico, nós tra-

Baseamo-nos em 4 pilares: intelectual, profis- mento, formando profissionais cidadãos

sional, emocional e espiritual. que contribuam para o desenvolvimento

A rapidez do mundo moderno exige dos edu-

Me. Déverson Rogério Rando

Esp. Janaína Aparecida de Freitas

ANÁLISE E PROJETO ORIENTADO A OBJETOS

A Unidade 1 apresenta os conceitos iniciais sobre a análise e os projetos orientados a objetos.

Na Unidade 2, estudaremos as fases que compreendem a análise e o projeto de um software.

A Unidade 3 é toda dedicada à confecção do diagrama de classes responsável por demons-

Ao longo do livro, você será convidado(a) a refletir, questionar e

Neste elemento, você fará uma pausa para conhecer um pouco

No fim da unidade, o tema em estudo aparecerá de forma resumida

Enquanto estuda, você encontrará conteúdos relevantes

Quando identificar o ícone de QR-CODE, utilize o aplicativo Unicesumar

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

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

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

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

sistema, mostra-nos as entidades e seus relacionamentos. Neste modelo, muitos

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

Ivar Jacobson (1995)

Coad e Yourdon (1992)

Abrangem as fases de análise, projeto e implementação. Propõem mecanis-

Grady Booch (1997)

James Rumbaugh (1991)

Martin e Odell (1995)

O projeto de software começa quando a primeira iteração da engenharia de requisitos

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

■ Objeto: qualquer elemento concreto ou abstrato que existe no mundo

Figura 1 - Objetos concretos Figura 2 - Objetos abstratos

Figura 3 - Abstração de bolsa Figura 4 - Abstração de avião

Figura 5 - Abstração de esporte

■ Classe: representa a abstração de um conjunto de objetos do mundo

Figura 6 - Classe funcionário

Figura 7 - Classe e objetos / Fonte: os autores.

■ Atributo: é uma característica particular que os objetos de uma classe

Figura 8 - Classe, objeto e valor / Fonte: os autores.

Figura 9 - Operação / Fonte: os autores.

Figura 10 - Mensagem / Fonte: os autores.

Figura 11 - Evento / Fonte: os autores.

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

Figura 13 - Estado / Fonte: os autores.

■ Transição de estado: é quando ocorre a mudança de estado de um ob-

Estado Parado Estado Decolando

Estado Criado Estado Eliminado

Figura 14 - Transição de estado / Fonte: os autores.

■ Associação: é a forma como os objetos de uma mesma classe ou de

Figura 15 - Associação de classes / Fonte: os autores.

■ Encapsulamento: é a reunião de características e comportamentos de

Figura 16 - Encapsulamento / Fonte: os autores.

Figura 17 - Polimorfismo / Fonte: os autores.

■ Método: é o algoritmo (conjunto de passos) que um objeto executa quan-

Quadro 1 - Declaração de um método / Fonte: os autores.

■ Colaboração: é a troca de mensagens que acontece entre objetos e atores

■ Figura 18 - Troca de mensagens entre os objetos / Fonte: os autores.

■ Herança: é a propriedade que possibilita que a classe herde característi-

Figura 19 - Herança / Fonte: os autores.

Agora que já conhecemos os principais termos utilizados na análise e no projeto