Sumário

Sumário 1

1. INTRODUÇÃO À ANÁLISE DE SISTEMAS 4

1.1 Introdução 4

1.2 Sistemas de informação x software 4

2. PROJETO DE DESENVOLVIMENTO 6

2.1 Processo de desenvolvimento de software 6

2.2 Modelos de processos de software 6

2.2.1 Modelo cascata 6

2.2.2 Modelo incremental 7

2.2.3 Modelo espiral 9

2.2.4 Processo unificado (UP) 9

2.3 Processo x pessoas 10

2.4 O paradigma da orientação a objetos 12

2.5 A linguagem de modelagem unificada 13

3. ENGENHARIA DE REQUISITOS (ER) 15

3.2 Introdução à Engenharia de Requisitos 15

3.2 Classificação de requisitos 16

3.2.1 Requisitos funcionais (RF) 16

3.2.2 Requisitos não funcionais (RNF) 16

3.3 Processo de Engenharia de Requisitos 19

3.3.1 Elicitação de requisitos 20

3.3.2 Análise de requisitos 20

3.3.3 Documentação de requisitos 21

3.3.4 – Validação de requisitos 22

3.3.5 - Gerenciamento de requisitos 22

Controle de versão 23
 Rastreabilidade 23

4. MODELAGEM DE CASOS DE USO 25

4.1 Casos de uso e atores 25

4.2 Descrição de casos de uso 26

4.3 Diagrama de caso de uso 28

4.4 Estrutura do diagrama de caso de uso 28

4.4.2 Relacionamento entre atores 31

5. MODELAGEM DE PROCESSO DE NEGÓCIO 34

5.1 Introdução à modelagem de processo de negócio 34

5.2 O papel do analista de negócio 34

5.3 Regras de negócio 36

5.4 Métodos de modelagem de processos de negócio 36

5.4.1 UML 36

5.4.1.1 Diagrama de processo 36

5.4.1.2 Diagrama de atividade 40

5.4.1.3 Adornos da UML 43

6. AS VISÕES DA UML 44

7. VISAO ESTRUTURA ESTÁTICA 45

7.1 Conceitos fundamentos da orientação a objetos 45

7.2 Modelo de classe de domínio 47

7.2.2 Relacionamento entre classes 48

7.2.2.1 Dependência 48

7.2.2.2 Associação 48

7.2.2.3 Agregação 50

7.2.2.4 Composição 50

7.2.2.5 Classes associativas 51

7.2.3 Herança 51
 7.2.4 Diagramas de classes 53

7.2.5 Diagrama de objetos 54

8. VISÃO ESTRUTURAL DINÃMICA 56

8.1 Realização de casos de uso 56

8.2 Classes de análise 56

8.2.1 Entidade 57

8.2.2 Fronteira 57

8.2.3 Controle 57

8.3 Comportamento de objetos 57

8.3.1 Representando métodos 58

8.3.2 Polimorfismo 58

8.3.3 Visibilidade de atributos e métodos 59

8.3.4 Interfaces 59

8.3.5 Ciclo de vida de objetos 60

8.4 Comunicação entre objetos 61

8.4.1 Mensagem 61

8.4.2 Diagrama de sequência 61

Mensagens síncronas 63

Mensagens assíncronas 64

Autodelegação de mensagens 64
 1. INTRODUÇÃO À ANÁLISE DE SISTEMAS
1. 1.1 Introdução
2. 1.2 Sistemas de informação x software
Sistema de informação é a composição de informações (ou dados), pessoas, processos e
tecnologias que tem por objetivo apoiar ou melhorar o processo de negócio de uma corporação.
Tem foco na informação gerada em um processo organizacional, de tal forma a originar

T e c n o lo g ia d e s is t e m a a s d e
valor a esse processo (BEZERRA, 2006)

Infraestrutura

in o fr m a ç ã o
Servidores

Computadores

Sistemas
Operacionas
Sistemas de
Software

Rezende (2005) observa que todo sistema que gera e armazena

informação pode ser considerado um sistema de informação, independentemente se utiliza
tecnologia ou não.
 É importante ter em mente quais são os objetivos que o sistema deve atingir,
pois eles servem de norte para todo o restante.
 É importante o mapeamento do processo a ser executado.
o Qual é a sequência de atividades a serem executadas a partir do
momento que inicia o processo?
o Quem são as pessoas que executam cada atividade?
o Qual informação é gerada no decorrer do processo?
 Na plataforma tecnológica, deveríamos nos atentar a detalhes como e onde essa
informação seria armazenada e qual o melhor projeto de rede para suportar o tráfego dessa
informação.
Pensar também qual parte do processo seria automatizada por um sistema de software.
Um sistema de software também pode ser identificado como o conjunto de vários
componentes (componentes de software) que, quando executados, produzem um resultado
previamente desejado. Estes componentes são desenvolvidos utilizando métodos e processos que
estabelecem uma relação entre a necessidade do cliente e um código executado em uma máquina
(PRESSMAN, 2006).

Engenharia de
Software
Fornece técnica para especificar,
projetar, manter e gerir um sistema

Métodos Ferramentas Processos

Enfase no cmo fazer para Fornecem suporpte para processo Definem quando e onde fazer e
desenvolver um sistema de software de desenvolvimento de software quem dever ser o respons=avel
 2. PROJETO DE DESENVOLVIMENTO
2.1 Processo de desenvolvimento de software
O processo de desenvolvimento de software resume-se a um conjunto de atividades
(etapas da Engenharia de Software ou paradigmas da Engenharia de Software) executadas
em uma determinada sequência.

Cada atividade possui:

 Pré e pós-condições;
 Papéis
 Produtos

2.2 Modelos de processos de software

2.2.1 Modelo cascata

Também chamado de waterfall ou também citado na literatura como clico de vida

clássico, o modelo cascata é composto de cinco atividades:
Análise de requisitos: Elicitação e documentação dos requisitos do sistema
Projeto: definição dos componentes do software e como eles irão interagir para
atingir os requisitos elicitados, bem como definição das necessidades e as restrições de software
e hardware. Nesse momento que a arquitetura do sistema começa a ser definida.
Codificação: componentes do software são desenvolvidos em linguagem de
máquina. Nesta fase são feitos os testes unitários, ou também chamados de testes de
desenvolvimento.
Testes: validação com o objetivo de encontrar e corrigir possíveis não conformidades
Implantação e manutenção: fase mais longa do ciclo de vida de um software e tem
início quando o sistema é colocado para uso por parte do usuário final.
 Uma das importantes características que um sistema de software deve possuir é ser
manutenível, ou seja, capacidade e facilidade de adaptação de um software

No modelo cascata, as atividades são executadas de forma sequencial. Assim, uma

atividade não é iniciada até que sua predecessora seja completamente finalizada. Esta é a
fraqueza desse modelo.
Esse cenário nos expõe duas situações:
 Alto custo em cada atividade:
 Alto custo de retrabalho

2.2.2 Modelo incremental

Também chama de iterativo (no sentido de repetição), é, em sua essência, bem parecido
com o modelo cascata.
No modelo iterativo, as atividades e a sequência de execução são exatamente as mesmas
do modelo cascata.
A diferença é que no modelo incremental não é necessário que todos os requisitos
estejam mapeados para se iniciar o ciclo de desenvolvimento.
Não diminui o custo total do projeto, mas reduz o custo de cata atividade. Possui menor
tempo de execução
Apresenta redução do retrabalho.
A chave para aumentarmos a eficiência na produção de um sistema de software
utilizando o modelo incremental é: bom planejamento.
O modelo incremental serviu de base para muitos outros processos largamente
utilizados e debatidos na literatura, como: prototipagem, modelo espiral e processo unificado
2.2.2 Prototipagem
 Em Engenharia de Software prototipagem é a primeira versão de um sistema de
software (SOMMERVILLE, 2020).
Finalidades:
 Verificar e demonstrar se os requisitos mapeados estão de acordo com a
necessidade do usuário
 Validar uma solução de projeto
É utilizada com o objetivo de antecipar mudanças que possam vir a ser mais custosas no
desenvolvimento de um sistema de software.
O modelo de prototipagem possui quatro atividades:
 planejamento;
 definição das funcionalidades;
 construção;
 validação.

Protótipo de baixa fidelização – da ênfase na interação com o usuário e na estrutura

geral do sistema de software, não se preocupando em fazer protótipos que produzissem uma
imagem real do sistema. (ROSEMBERG, 2008)
Outro fato interessante observado foi a viabilidade econômica do protótipo: barato na
construção e na alteração.
Alguns dos bons resultados obtidos nesse projeto: rapidez no processo de captação
dos requisitos e antecipação dos problemas.

2.2.3 Modelo espiral

Também conhecido como modelo de Boehm (1988), tem como raiz o modelo iterativo
incremental e como preocupação central a mitigação de riscos.
 A diferença do modelo espiral para os outros modelos é que cada ciclo completo, ou
cada iteração, não produz ou implementa um sistema ou uma
parte do sistema de software.
O model espiral é composto de quatro fases:
 Definição dos objetivos
 Mitigação dos riscos
 Desenvolvimento do produto
 Planejamento da próxima fase

2.2.4 Processo unificado (UP)

Tem em seu fundamento a estrutura do modelo iterativo incremental

Composto por quatro fases:

 Iniciação; definição do escopo do projeto, que é a relação das necessidades que

serão atendidas no projeto de software e aquelas que não serão.
 Elaboração: detalhamento do escopo, produzindo o modelo de requisitos dos
sistemas. Nesta fase, pode-se produzir o plano de projeto, ou plano de
desenvolvimento, que consiste no mapeamento dos requisitos, as soluções de
software desenvolvidas para solução de cada requisito e o planejamento dos
riscos associados para cada solução.
 Construção: associada ao desenvolvimento do projeto, que consiste em projetar,
codificar e testar o sistema de software
 Transição: o sistema de software é entregue para o usuário final, sendo comum
que existam correções e adaptações a serem feitas.
Segundo os próprios autores, o UP é baseado em três pilares:
 Dirigido por caso de uso – descrição detalhada dos requisitos de um sistema de
software que seguem uma determinada metodologia e um determinado padrão
 Centrado na arquitetura
 Iterativo e Incremental

RUP (Rational Unified Process) é uma variação do UP, um modelo de processos,

desenvolvido pela Rational, que associou o Modelo de Processo Unificado às melhores práticas
da engenharia de Software, que são:
  Desenvolva iterativamente
 Gerencie requisitos
 Use arquitetura de componentes
 Modele visualmente
 Verifique continuamente a qualidade
 Gerencie mudanças

O modelo proposto pela Rational especifica, de forma sistemática, a sequência que as

atividades, ou também chamadas de disciplinas, devem ser realizadas dentro de cada fase, quem
são os responsáveis e quais produtos são resultantes de cada atividade.
As fases da RUP são as mesmas definidas na UP: Iniciação, elaboração, construção e
transição.
RUP utiliza a orientação a objetos como boa prática de Engenharia de Software

2.3 Processo x pessoas

Qualquer modelo de processo de Engenharia de Software se preocupa em definir quem

produz o que, como e quando:
Quais as responsabilidades de uma equipe dentro de um projeto? Qual é o papel da
pessoa dentro do processo de desenvolvimento?
O RUP, por exemplo, não tem ênfase no individuo, mas sim no papel. O papel é o
responsável pela execução de uma determinada tarefa, que é responsável por um determinado
artefato.
Segundo a empresa Wthereex (s.d) o papel “define o comportamento e as
responsabilidade de um indivíduo ou de um conjunto de indivíduos que trabalham juntos como
uma equipe, no contexto de uma organização de engenharia de software”.
Bezerra (2006) tem ideia semelhante e destaca que o componente humano é fator
importante no desenvolvimento de um sistema de software, uma vez que ele é composto de
tarefas “altamente cooperativas”

Papéis desempenhadas em um projeto de desenvolvimento de software:

Gerente de projetos:
 Gere, coordena, acompanha as atividades do projeto e aloca as pessoas para as funções
determinadas

Analista

Muitas vezes chamado de analista de negócios, é responsável por captar as

necessidades do negócio e transformá-las em requisitos dos sistemas de software.
Alguns conhecimentos são necessários, como: conhecimento ou familiaridade com o
negócio, boa capacidade de comunicação oral e escrita, conhecimento de computação, entre
outros.

Projetista

Responsável por produzir uma solução computacional para os problemas identificados.

Arquiteto de software

Responsável pela elaboração da arquitetura do sistema. Como e quais serão os

componentes internos do sistema de software e como esses componentes irão se comunicar para
tender a uma determinada necessidade.
Geralmente, o arquiteto trabalha em contato com o gerente de projetos, ajudando a
organizar o desenvolvimento e estimando tamanho e tempo de desenvolvimento, e com o corpo
técnico, orientando decisões técnicas de desenvolvimento.
Desenvolvedores

Também chamados de programadores, os desenvolvedores têm a responsabilidade de

implementar o projeto. Transformar a arquitetura e a solução do projeto em solução
computacional.

Clientes

O usuário é parte fundamental do processo de desenvolvimento, ele precisa estar

envolvido e com foco desde o momento do levantamento de requisitos até a validação.
 Avaliadores de qualidade

São responsáveis por garantir que o sistema de software atenda a todas as necessidades
do negócio.

2.4 O paradigma da orientação a objetos

Um paradigma é um conjunto de regras que estabelecem fronteiras entre o que é certo e

errado, entre o que é verdadeiro e o que é falso, entre o que se deve fazer e o que não se deve
fazer [...]
O paradigma da orientação a objetos é uma forma de se desenvolver um sistema de
software que o enxerga como um conjunto de componentes que interagem entre si para resolver
um determinado problema.
Em orientação a objetos, cada objeto também possui características, denominadas
atributos, e a ação a ser executada por esse objeto, que tem o nome de método
Na orientação a objetos, dois objetos interagem entre si para executar uma determinada
tarefa computacional por meio da troca de mensagens. Uma mensagem pode ser interpretada
como requisição que um objeto faz a outro objeto para que ele execute um determinado serviço.
Bezerra (2006) interpreta a orientação a objetos como uma técnica para modelar
sistemas que diminui a diferença semântica entre a realidade sendo modelada e os modelos
construídos.
Antes do paradigma orientação a objetos, no início da década de 90, o paradigma
estruturado era amplamente utilizado para modelagem de sistemas, e é baseado em dois
elementos: informações (dados) e processos. Esse paradigma apresentava um grande
problema, a atomicidade dos processos. O que levava a sistemas muitos complexos e de difícil
manutenção.

Vantagens da orientação a objetos:

 A modelagem próxima ao mundo real gera modelos mais fáceis de entender e
manter
 Aumento do reuso de códigos
 Aumento da manutenibilidade: sistemas mais manuteníveis, mudanças nos
requisitos não implica necessariamente na alteração do sistema todo.
 O paradigma da OO é baseado nos seguinte pilares:
 Classes;
 Objetos;
 Abstração;
 Encapsulamento;
 Herança;
 Polimorfismo;

2.5 A linguagem de modelagem unificada

É uma linguagem para modelar sistemas orientados a objetos

Por se tratar de uma linguagem, ainda que visual, também é composta por elementos
(gráficos) que também seguem algumas regras
 Regra de sintaxe: padronização dos elementos
 Regra de semântica: significado do elemento dentro de um contexto
A UML surgiu da necessidade de se desenvolver uma linguagem que fosse padrão para
modelagem de sistemas orientados a objetos e que fosse interpretável por qualquer um: usuários,
desenvolvedores, arquiteto e gerentes.
Segundo os criadores da UML, Booch, Jacobson e Rumbaugh (2006), um sistema de
software pode ser dividido em cinco visões, sendo que, dependendo da complexidade, nem todas
precisam ser desenvolvidas:

 Caso de Uso: representa o sistema de um ponto de vista externo, como ele

interage com agentes externos, como usuários ou outros sistemas.
 Projeto: representa a arquitetura do sistema de software.
 Implementação: representa os componentes e subsistemas.
 Implantação: representa a distribuição física do sistema e seus componentes e
como estes irão se comunicar.
 Processo: dá ênfase na representação do paralelismo e sincronização dos
componentes do sistema
Cada visão é composta por um ou mais diagramas UML. Um diagrama UML é uma
composição de elementos gráficos com o objetivo de representar alguma perspectiva do sistema
 3. ENGENHARIA DE REQUISITOS (ER)

3.2 Introdução à Engenharia de Requisitos

A engenharia é um conjunto de métodos, procedimentos e ferramentas (MPF) que

tem por objetivos resolver um determinado problema.
Requisitos, segundo Sommerville (2010), são serviços que um sistema deve prestar e
suas restrições de funcionamento. Eles devem necessariamente refletir as necessidades do
cliente.
Engenharia de Requisitos é um conjunto de MPF que tem por objetivo descobrir
analisar, documentar, verificar e validar esses requisitos (SOMMERVILLE, 2010).
Sob a ótica da Engenharia de Software, a Engenharia de Requisitos é um ramo da
Engenharia de Software que envolve, dentro do ciclo de vida de um software, atividades
relacionadas a requisitos (KOTONYA; SOMMERVILLE, 1998).
Desafios da ER:
 A definição de requisitos inconsistentes leva a problemas que se estendem por
todo ciclo de vida do software.
 A ER proporciona estimar com maior precisão o tempo e o custo de um projeto.
Requisitos mal definidos geram um projeto com maior custo e maior tempo de
desenvolvimento.
 A ER proporciona melhor gerência das mudanças, comuns em projetos. Em
contrapartida, falhas nesse processo geram sistemas de software com altos custos
de manutenção.
Dentro do projeto as pessoas mais interessadas (Stakeholders) pelos requisitos é o
cliente e o usuário, com papéis diferentes.
 O cliente é o contratante do projeto,
 O usuário é quem vai, efetivamente, usar o sistema, quem detém o maior
conhecimento do negócio.
É importante que o cliente e o usuário sejam parte integrante do projeto, que se
envolvam e se motivem com o projeto
Além do usuário e do cliente, são considerados interessados pelos requisitos:
 analista de sistemas,
 desenvolvedores,
 arquitetos e
  gerentes de projeto.

3. 3.2 Classificação de requisitos

Separar os requisitos a partir do seu nível de descrição:

 Requisitos de usuários: segundo Sommerville (2010, p 83), são declarações em

linguagem natural com diagramas de quais serviços o sistema deverá fornecer a
seus usuários e as restrições com as quais ele deve operar. Eles dever ser
direcionados aos clientes, usuários, gerentes do projeto e arquiteto de sistema,
pois definem em alto nível as necessidades, o que define, entre outras coisas, o
escopo do projeto.
 Requisitos de sistemas: segundo Sommerville, são “descrições mais detalhadas
das funções, serviços e restrições operacionais do sistema de software”. Eles
devem ser direcionados aos usuários, arquitetos de sistemas e desenvolvedores,
pois podem definir uma sequência de implementação, o que influencia
diretamente na solução dada.

A diferença entre os níveis de descrição está ligada à quantidade e à qualidade da

informação que cada interessado deve possuir do requisito. Em contrapartida, requisitos não
devem contemplar informações de gestão do projeto, detalhes da arquitetura, projeto ou
implementação, bem como informações sobre como o sistema será validado.
Os requisitos de software devem dar ênfase no comportamento do software que
será construído e mantido.
Além da classificação em níveis, os requisitos também são categorizados em:
requisitos funcionais e requisitos não funcionais.

3.2.1 Requisitos funcionais (RF)

Descrevem o comportamento esperado de um sistema de software, explicita o que o

sistema deve fazer e idealmente o que o sistema não deve fazer (SOMMERVILLE, 2010)
Requisitos funcionais, como o detalhamento da interação entre o sistema de software
e o seu ambiente/USUÁRIO (PFLEEGER 2004).

3.2.2 Requisitos não funcionais (RNF)

 Descrevem restrições sobre os serviços oferecidos pelo sistema de software
(SOMMERVILLE, 2010)
Os requisitos funcionais são insuficientes para descrever o sistema de software, pois
é necessário descrever outros aspectos: atributos do sistema e atributos do ambiente do sistema,
normalmente classificados como requisitos não funcionais.

A classificação acima é feita a partir da origem dos requisitos não funcionais, que
são:
 Requisitos Organizacionais (DAO – Desenvolvimento, Ambientais,
Organizacionais): provenientes da organização do cliente, como padronização de
uma linguagem de desenvolvimento.
 Requisitos de Produto (CUSPE TReES - Confiabilidade, Usabilidade,
Proteção, Eficiência: Tempo de resposta e Espaço.) são aqueles que restringem
o comportamento do sistema de software, com o espaço em disco que ele irá
ocupar.
 Requisitos Externos (LER – Legais, Éticos e Reguladores): são requisitos de
fora da fronteira do sistema de software, como requisitos legais, de cumprimento
da legislação.

Além da proposta de Sommerville (2010), a norma ISO/IEC 25010:2011 trata da

classificação e da definição de requisitos não funcionais.
 Fui Confiar E fiz Uso Manual da Porta

Fui - Funcionalidade
Confiar – Confiabilidade
E fiz - Eficiência
Uso - Usabilidade
Manual da - Manutenibilidade
Porta – Portabilidade

Os requisitos não funcionais, em geral, são levantados de maneira informal e abstrata

e logo são colocados em segundo plano no processo de elicitação de requisitos. São, em geral,
altamente complexos em sua documentação, rastreabilidade e validação.
 O fator de sucesso deve-se ao fato de que todo requisito não funcional especificado
deve fornecer subsídios numéricos para que seja validado.
Enquanto requisitos funcionais são facilmente verificáveis, requisitos não
funcionais nos parecem, em um primeiro momento, mais abstratos.
É importante que tenhamos em mente que não importa o tipo do requisito,
funcional ou não funcional, ele sempre deve ser verificável e validado (BOURQUE;
FAIRLEY, 2004).

3.3 Processo de Engenharia de Requisitos

Tem como objetivo obter requisitos definidos, especificados e modelos de sistemas a

partir de fontes de requisitos (BOURQUE; FAIRLEY, 2004). As fontes de requisitos poder ser,
segundo Kotonya e Sommerville (1998)
 Sistemas de informações existentes.
 Necessidade dos interessados (stakeholders)
 Padrões da organização.
 Informações do Domínio
 Regulamentos (ou legislações)

O processo de engenharia de requisitos possui cinco atividades principais:

 .

3.3.1 Elicitação de requisitos

A qualidade dos requisitos é influenciada diretamente pelas técnicas empregadas

durante a elicitação de requisitos (HICKEY; DAVIS, 2002).
A elicitação de requisitos tem como objetivo a descoberta dos requisitos e das
fronteiras do sistema, que determinam o escopo do projeto. Nesta fase, é fundamental que haja
uma interação e uma cooperação grande entre todos os interessados – clientes, usuários e
analista. E uma atividade de grande dependência do fator humano.
Um dos grandes problemas é a confiança depositada em demasia na figura do
analista de requisitos.
Para esclarecer essa situação, Cristel e Kung (1992 apud PRESSMAN, 2006) citam
alguns dos problemas identificados durante o levantamento:
 Problemas de escopo
 Problemas de entendimento
 Problema de volatilidade
Técnicas de Elicitação:
 Entrevistas
 Cenários
 Protótipos
 Reuniões facilitadas (brainstorming)
 Análise de documentos

3.3.2 Análise de requisitos

Com os requisitos identificados, é necessário explicitar as informações obtidas na

elicitação. Esse processo auxilia no entendimento dos requisitos elicitados, eliminando possíveis
ambiguidades e problemas que possam ter passado despercebidos pelo processo de elicitação.
 É comum que na fase de análise dos requisitos elicitados, surjam requisitos
conflitantes, esses conflitos precisam ser resolvidos por um processo de negociação. Uma
negociação envolve três fases:
 Discussão
 Priorização
 Concordância
Explicitar os requisitos significa especificar as características operacionais do
software, descrever suas restrições e suas interações com outros sistemas a fim de estabelecer um
modelo conceitual do problema (PFLEEGER, 2004)
Os modelos produzidos na análise de requisitos são importantes, pois (PRESSMAN,
2006):
 Sistematizam e facilitam a análise de requisitos, pois ajudam o analista e os
interessados a entenderem a função e o comportamento do software.
 São chaves para a validação da especificação.

3.3.3 Documentação de requisitos

Tem por objetivo formalizar os requisitos e modelos definidos nas etapas anteriores
(BOURQUE; FAIRLEY, 2004)
Mais do que isso, documentos têm a finalidade de comunicar. Nesse ponto, devemos
estar atentos aos diferentes papéis de interessados em cada tipo de requisito.
Temos diferentes interessados com necessidades e pontos de vistas diferentes. O
Swebok (BOURQUE; FAIRLEY, 2004) sugere três documentos de visão:
 Documento de definição de sistema – pode incluir requisitos não funcionais e
modelos conceituais
 Especificação de requisitos do sistema: - contém requisitos na visão sistêmica
 Especificação de requisitos de software: pode ser utilizado como base para o
desenvolvimento e para as futuras validações.

3.3.4 – Validação de requisitos

Todos os documentos de requisitos estão sujeitos a passarem por procedimentos de

verificação e validação (BOURQUE; FAIRLEY, 2004). O objetivo do processo de validação é
assegurar que o trabalho de elicitação, análise e documentação dos requisitos está consistente
com o domínio do projeto.
Existe uma série de questionamentos que devem ser feitos nesta fase
(SOMMERVILLE, 2010):
 Os requisitos descritos são consistentes? Ou seja, não entram em conflito?
 Os requisitos descritos são completos? Ou seja, definem todas as funcionalidades
e restrições previstas na elicitação?
 Os requisitos são passíveis de serem implementados?
 Os requisitos são verificáveis? Ou seja, podemos escrever testes que possam
verificar que o sistema implementado atende a cada requisito elicitado?
Requisitos que não podem ser testados não são requisitos, mas sim apenas desejos
(BOURQUE; FAIRLEY, 2004).

Métodos para validação de requisitos:

 Revisão de requisitos
 Prototipação
 Teste de aceitação

3.3.5 - Gerenciamento de requisitos

Na engenharia de requisitos, devemos nos acostumar com a ideia de que requisitos

podem (e quase sempre) mudam. Inevitavelmente, requisitos podem ser incompletos e
inconsistente, bem como novos requisitos podem surgir.
A meta da gerência de requisitos é o controle da mudança dos requisitos ao longo
do processo de engenharia de requisitos (PRESSMAN, 2006). Controlar mudanças significa,
entre outras coisas, analisar o impacto dessas mudanças.
Além de controlar a mudança dos requisitos, a gerência de requisitos tem mais dois
objetivos:
 Gerenciar o relacionamento entre requisitos.
 Gerenciar o relacionamento entre requisitos e os documentos produzidos durante todo o
projeto.
Uma boa gestão de requisitos passa principalmente pela definição de uma política
organizacional, que muitas vezes é impactada pelo nível de maturidade dessa organização.
 Para definição de uma política organizacional de produção de software com
qualidade, existem alguns modelos de processo que definem de maneira completa e complexa
todas as atividades, artefatos a serem produzidos. Dois dos modelos mais difundidos atualmente
são: CMMI (Capability Maturity Model for Software) e o MPS.BR (Melhoria de Processo do
Software Brasileiro).
Duas das atividades fundamentais no processo de gestão de requisitos, citadas tantos
nos modelos CMMI e MPS.BR quanto por Wiegers (2003), que são: controle de versão e
rastreabilidade.

Controle de versão

Um documento de requisitos e os documentos que o compõem são considerados a

base para o desenvolvimento. Essa base pode ser considerada uma versão. É importante que
tenhamos sob controle, por qualquer mecanismo que seja, quais documentos fazem parte de uma
versão base, uma vez que, a partir da mudança de um requisito, é gerada uma nova versão.

Rastreabilidade

Rastreabilidade especifica as dependências de um requisito para com outro e de um

requisito com cada artefato gerado ao longo do projeto. Quando falamos de artefatos, não
estamos falando apenas dos gerados durante a engenharia de requisitos, mas sim em todo o
projeto, como qual requisito está relacionado à qual solução de software (SOMMERVILLE,
2010).
Esse controle pode ser feito utilizando uma matriz de rastreabilidade, que tem por
objetivo cruzar um requisito com outro dependente ou um requisito com um artefato.
Existem diversas matrizes de requisitos. Entre as mais utilizadas, podemos destacar
(KOTONYA; SOMMERVILLE, 1998):
 Matriz que indica o relacionamento requisito x requisito.
 Matriz que indica o relacionamento requisito x fonte do requisito.
 Matriz que indica o relacionamento requisito x subsistemas, que descreve quais
subsistemas atendem àquele requisito.
 Matriz que indica o relacionamento entre um requisito elicitado e um artefato
produzido no processo da Engenharia de Software, como um caso de teste ou um
documento de requisitos
 4. MODELAGEM DE CASOS DE USO

O objetivo agora é apresentar a modelagem de caso de uso como uma abordagem

que combina método e ferramenta e que cumpra com os objetivos a serem atingidos na fase de
análise de requisitos.
A análise de requisitos tem como objetivo explicitar os requisitos elicitados, o
que significa especificar as características operacionais do software, descrever suas
restrições e suas interações com outros sistemas a fim de estabelecer um modelo conceitual
do problema (PFLEEGER, 2004).
Lembremos ainda que esse modelo conceitual pode ser interpretado como uma
“maquete da realidade”, utilizada para representar o domínio do problema. Além disso, esses
modelos são utilizados na comunicação entre clientes, arquiteto, gerentes de projeto e
desenvolvedores.
Segundo Bezerra (2006, p. 45), “modelo de casos de uso é uma representação das
funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que
interagem com ele”
A definição do professor Eduardo Bezerra, corrobora com a visão dos criadores da
modelagem de casos de uso, que diz que não existem sistemas de software que existam
isoladamente (BOOCH; JACOBSON; RUMBAUGH, 2006). Todo sistema de software interage
com algum agente externo a ele, seja um usuário ou outro sistema, com o objetivo de realizar
uma determinada ação.

4.1 Casos de uso e atores

Caso de uso é a descrição de uma sequência de atividades executadas por um

agente externo ao sistema sem que sejam revelados detalhes do funcionamento interno ao
sistema, por isso dizemos que o caso de uso mostra a visão comportamental externa ao
sistema (BEZERRA, 2006).
Se bem descritos e definidos, casos de uso definem um denominador comum, de
conhecimento do domínio do problema e das funcionalidades do sistema, que pode ser
interpretado facilmente por usuários, analistas e desenvolvedores (BOOCH; JACOBSON;
RUMBAUGH, 2006).
 Atores são os agentes externos ao sistema que executam uma determinada ação e
que esperam algum resultado, ou seja, interagem diretamente com o sistema a partir dos casos de
uso.
Algumas considerações importantes a respeito de atores:
 Ator é qualquer entidade externa que interage com o sistema: usuários,
outros sistemas de software ou até mesmo dispositivos de hardware.
 Um ator nunca é um componente interno do sistema, ou mesmo qualquer
detalhe interno ou componente de implementação dele.
 Um sistema nunca é um ator de si mesmo.

4.2 Descrição de casos de uso

Muitas são as discussões na literatura a respeito do nível de detalhamento

necessário para se descrever um caso de uso. Podemos considerar a descrição em linguagem
natural, desde que sequencial, como uma descrição de caso de uso.

Um requisito deve ser completo. Voltando ao nosso exemplo, onde está descrito o
comportamento do sistema ou do cliente, caso o cliente não possua saldo em conta corrente, não
informe a senha correta ou ainda não possuam notas disponíveis no terminal?
 Pensando na completude do modelo, Cockburn (2005) propõe um modelo de
descrição de caso de uso contendo alguns elementos que nos guiam a especificar um caso de uso
completo.
 4.3 Diagrama de caso de uso

Diagrama de casos de uso é um diagrama da UML que tem por objetivo mostrar, a
partir de um ponto de vista estático, o conjunto de casos de uso, atores e seus relacionamentos
(BOOCH; JACOBSON; RUMBAUGH, 2006).
Visão estática é o termo usado para descrever uma parte do sistema sob o ponto de
vista estrutural

4.4 Estrutura do diagrama de caso de uso

4.4.1 Relacionamento entre casos de uso

Podemos utilizar três tipos de relacionamento entre casos de uso: inclusão,

extensão e herança.

Inclusão
 Significa que o comportamento definido no caso de uso de inclusão é incorporado
ao comportamento do caso de uso base, ou seja, para que este seja executado, obrigatoriamente o
caso de uso de inclusão também deverá ser executado (BOOCH; JACOBSON; RUMBAUGH,
2006)

Extensão

Significa que o comportamento definido no caso de uso de extensão pode ou não

ser incorporado ao comportamento do caso de uso base, ou seja, para que este seja executado, o
caso de uso de extensão pode ou não ser executado (BOOCH; JACOBSON; RUMBAUGH,
2006).

Por exemplo, na figura a seguir, podemos interpretar que o cliente pode solicitar
um empréstimo pessoal durante uma operação de saque, o que quer dizer que existe uma
condição para execução, ou não, do caso de uso “solicitar empréstimo pessoal”.
 Herança
Significa que o caso de uso filho herda o comportamento e o significado do caso
de uso pai, acrescentando ou mudando seu comportamento (BOOCH; JACOBSON;
RUMBAUGH, 2006

Na figura a seguir, por exemplo, podemos interpretar que a validação de acesso

por biometria ou por senha são especializações da validação de segurança de acesso. Os casos de
uso filho: “Validar Segurança Acesso por Senha” e “Validar Segurança Acesso por Biometria”
possuem exatamente o mesmo comportamento do caso de uso “Validar Segurança Acesso” pai,
todavia, possuem comportamentos diferentes.
 4.4.2 Relacionamento entre atores

Diferentemente dos casos de uso, atores possuem apenas um tipo de relacionamento:

herança.
Significa que o ator filho herda o comportamento e o significado do ator pai,
acrescentando ou mudando seu comportamento. Em suma, o ator filho pode executar todos os
casos de uso do ator pai e mais aqueles que apenas ele executa (BOOCH; JACOBSON;
RUMBAUGH, 2006)

Na figura a seguir, por exemplo, podemos interpretar que o Cliente Pessoa Jurídica
pode “Efetuar Saque”, “Contratar Empréstimo Pessoal” e “Aumentar Limite de Crédito”.
Podemos afirmar que o ator Cliente não executa o caso de uso “Aumentar Limite de Crédito”,
mas somente “Efetuar Saque” e “Contratar Empréstimo Pessoal”.
 5. MODELAGEM DE PROCESSO DE NEGÓCIO
5.1 Introdução à modelagem de processo de negócio

Processo de negócio são atividades relacionadas a um determinado negócio,

que são executadas em uma determinada sequência e que produzem um determinado
resultado ou objetivo.
Atividades são executadas por agentes de uma determinada forma, em um
determinado espaço de tempo, em uma determinada condição de ambiente e com uma
determinada finalidade.
É o que podemos encontrar na literatura, como 5W1H, do inglês cinco W´s
(What, Who, When, Where, Why) e um H (How) (ZACHMAN, 1987).

Como vimos, um modelo pode ser considerado a representação de uma

realidade, que pode ser utilizado de diversas maneiras. No caso do modelo conceitual, estamos
preocupados em representar o domínio do nosso problema para utilizarmos em uma determinada
função.
Existem diversas formas de se representar, de se modelar, a mesma coisa.
Todavia, cada modelo representa uma visão diferente e é utilizado de formas diferentes.
Modelagem de um processo de negócio é a representação dos diversos aspectos
de um processo de negócio sob diferentes pontos de vista e para determinados objetivos dentro
de um projeto de software.

5.2 O papel do analista de negócio

 Segundo o Babok (INTERNATIONAL INSTITUTE OF BUSINESS
ANALISYS, 2008), o analista de negócio é o profissional responsável por captar as reais
necessidades dos stakeholders e não apenas seus desejos expressos. Ele estabelece um elo entre o
usuário do sistema de informação e o sistema de informação propriamente dito, estabelece a
ligação entre a área de negócio e a área de TI.
A função de analista de negócio pode ser desempenhada por qualquer pessoa ou
profissional, independentemente do seu cargo na organização. Existem diversas nomenclaturas
para o papel de analista de negócio, a depender da organização, como analista de processo,
analista de processo de negócio ou gerente de processo.
O analista de negócio atua nas seguintes áreas de conhecimento:
 análise de requisitos;
 análise corporativa;
 avaliação e validação da solução;
 elicitação;
 gestão e comunicação de requisitos;
 planejamento e monitoramento da análise de negócio.
O Professor Belloquim (2007), aponta cinco competências fundamentais para o
analista de negócio:
 Profundo conhecimento do negócio.
 Formação ampla. Apenas o conhecimento na área de desenvolvimento
de sistemas não basta, são necessários conhecimentos de finanças,
marketing, governança, marcos regulatórios, entre outros.
 Habilidades interpessoais e pensamento sistêmico, importante para se
estabelecer as relações entre as áreas.
 Dominar técnicas necessárias para entender, modelar, analisar e
documentar processos de negócio e requisitos de sistemas, como a UML.
 Compreensão das possibilidades oferecidas pela tecnologia disponível,
ou seja, não é necessário que o analista seja um especialista em uma
determinada tecnologia, mas é necessário que tenha uma visão geral
sobre suas capacidades e limitações.

5.3 Regras de negócio

Um conjunto de restrições que definem como um processo de negócio de uma

organização deve ser executado, que, além de representar determinados conhecimentos a respeito
de um processo, também representam importantes aspectos restritivos na execução deste
processo (BUSINESS RULES GROUP, 2000),
Segundo Ross (2003), existem alguns princípios básicos nos quais devemos estar
atentos quando estamos trabalhando na elicitação das regras de negócio, com ênfase
principalmente na descrição e detalhamento delas. Alguns desses princípios são:
 Princípio da unicidade: regras de negócio devem ser únicas.
 Devem ser escritas e expressas de forma explícita e com linguagem clara, diminuindo
possíveis ambiguidades.
 Preferencialmente devem ser especificadas pelas pessoas com maior conhecimento.
 Como estão em constantes mudanças, regras de negócio devem ser gerenciáveis.
Regras de negócio restringem a execução dos casos de uso.
Regras de negócio são passíveis de mudanças, logo, podem gerar mudanças nos
casos de uso. Tratamos sobre gestão de mudança e matriz de rastreabilidade de casos de uso.
Existem diversas maneiras de descrevermos uma regra de negócio, sendo que uma
das mais utilizadas é a descrição por linguagem natural. Aqui o ponto de preocupação está em
relação à completude do que queremos descrever, com o objetivo de diminuirmos possíveis
ambiguidades.
5.4 Métodos de modelagem de processos de negócio

A modelagem de processos de negócios mais usada é a abordagem de Eriksson

e Penker (2000), que tem como base a UML, e a abordagem BPMN (Busines Process Modeling
Ntoation)
É importante termos sempre em mente que, independentemente da abordagem
utilizada, um modelo sempre deve representar uma visão do processo de negócio, que sempre
deve estar relacionada ao 5W1H.

5.4.1 UML
5.4.1.1 Diagrama de processo

A extensão Eriksson-Penker, em 2000, segue a proposta fundamental da UML,

ou seja, é composta por elementos gráficos que também seguem regras de sintaxe e semântica.
Os elementos de um processo de negócio a serem representados, segundo
Eriksson e Penker (2000) são:
  Recursos: representam os objetos de uma organização, como pessoas, materiais e
informações, que são usados, consumidos refinados ou produzidos em um processo
de negócio.
 Processos: representam atividades executadas em uma organização.
 Objetivos: representam o resultado que se deseja alcançar, as metas da
organização.
 Regras: representam as particularidades que restringem algum aspecto do negócio
e representam conhecimento do negócio.
 Eventos: representam a mudança de estado do negócio. Um evento pode ser gerado
por um processo, que, inclusive, pode estar fora do negócio e é recebido por um ou
mais processos

Processo - denota um fluxo de execução da esquerda para a direita, no qual na esquerda

colocamos as entradas da atividade, um evento, por exemplo, e na direita representamos as
saídas do processo
Objeto de negócio - Em geral, são utilizados estereótipos para diferenciar e explicitar melhor os
tipos de objeto de negócio, que são: <<objetivo>> quando o objeto representa uma meta ou um
objetivo do processo; <<Pessoa>> quando o objeto representa uma pessoa; e <<recurso>>
quando o objeto representa um recurso utilizado pelo processo.

Objeto de informação - identifica informações produzidas ou consumidas pelo processo. Nesta

representação podemos ou não adicionar o estereótipo<<informação>>, mas obrigatoriamente
devemos identificar textualmente o descritivo da informação que estamos representando.

Dependência - A conexão utilizando linha tracejada e seta indica dependência entre os

componentes do modelo, sendo que a direção da seta indica a direção da dependência. É comum
adicionarmos estereótipos às setas para esclarecer a natureza da dependência, como mostra o
exemplo a seguir.

Podemos ainda representar um ou mais processos dentro do mesmo diagrama. Pode-

se utilizar um recurso chamado de raias, que normalmente são utilizadas para descrever onde as
atividades são executadas dentro da organização.

Segundo a abordagem de Eriksson e Penker (2000), são três os diagramas utilizados

na modelagem de processos de negócio:
- Diagrama de caso de uso.
- Diagrama de modelo de processo.
- Diagrama de atividade
 5.4.1.2 Diagrama de atividade

Definido na UML, o diagrama de atividade representa um fluxo de atividades que

tem como objetivo atingir um determinado objetivo.
O diagrama de atividade é muito semelhante ao fluxograma tradicional, pois ambos
representam o fluxo sequencial de atividades de um processo. Todavia, o diagrama de atividade,
além de representar o fluxo sequencial e suas possíveis ramificações, assim como o fluxograma,
representa também o paralelismo e a concorrência na execução dessas atividades (BOOCH;
JACOBSON; RUMBAUGH, 2006).
Segundo Booch, Jacobson e Rumbaugh (2006), os diagramas de atividades são
utilizados para representação de aspectos dinâmicos do sistema e comumente são utilizados em
duas situações:
 Modelagem de fluxo de trabalho: dá ênfase no processo de negócio sob o
ponto de vista dos atores que interagem com o sistema.
 Modelagem de operação: expõe a visão computacional da implementação
de um caso de uso

O diagrama de atividades compartilha das mesmas características que os outros

diagramas da UML que vimos até agora, sendo acrescidos apenas os elementos particulares a
este diagrama.
 5.4.1.3 Adornos da UML

Adornos são mecanismos ou elementos da linguagem UML utilizados com o único

intuito de facilitar o entendimento ou ratificar o significado de algo que estamos querendo
representar.
Nós já vimos um exemplo de adorno quando tratamos sobre os estereótipos.
Estereótipos são notações que utilizamos para especificar e diferenciar um tipo de
objeto ou de ratificar um tipo de relacionamento, como vimos no modelo de processo de
negócio.
Além do estereótipo, outro adorno é extremamente utilizado em todos os diagramas
da UML: a nota.
Uma nota é uma representação gráfica para comentários, observações ou restrições
que associamos a um determinado elemento da modelagem.
 6. AS VISÕES DA UML
Segundo a abordagem de Kruchten (1995), um sistema de software pode ser
organizado em cinco visões e cada visão possui um conjunto de diagramas UML que
representam aspectos particulares desse sistema.
 7. VISAO ESTRUTURA ESTÁTICA

A visão de caso de uso produz modelos que representam as necessidades do negócio, que
são traduzidas nas funcionalidades de um sistema de software.
No projeto desse sistema de software, necessitamos tanto especificar as funcionalidades,
quanto especificar como os problemas serão resolvidos.
É na fase de projetos, também chamada de fase de design, que definimos como os
problemas do sistema de software serão resolvidos e como as funcionalidades serão
implementadas.
Definir como as funcionalidades serão implementadas em um sistema de software é
definir os componentes desse sistema, suas responsabilidades e como eles irão interagir entre si
para resolver um determinado problema.
Quando estamos falando do paradigma da orientação a objetos, ou seja, de sistemas de
software orientados a objetos, os componentes do sistema podem ser interpretados como objetos
e a comunicação entre eles visa à execução de uma determinada tarefa.
À representação desses objetos e à relação entre eles, dá-se o nome de visão estrutural,
que basicamente é a representação da estrutura dos objetos e a relação entre eles (BEZERRA,
2006). Também chamado de aspecto estrutural estático, a visão estrutural estática representa a
estrutura interna do sistema, quais são os objetos, suas responsabilidades e relacionamentos. O
termo estrutural se dá pela representação da estrutura do sistema e o estático se dá pelo fato de
que nesse aspecto não temos a representação de informações desses objetos dentro de uma linha
de tempo de execução (BEZERRA, 2006).

7.1 Conceitos fundamentos da orientação a objetos

Podemos dizer que o paradigma da orientação a objetos é uma forma de se

desenvolver um sistema. Nesse paradigma o software é visto como um conjunto de componentes
que interagem entre si para resolver um determinado problema, a cada componente dá-se o nome
de objeto.
O principal motivador e diferenciador do paradigma orientado a objetos dos
demais paradigmas de desenvolvimento de sistemas está na tentativa de aproximar o software do
mundo real.
Devemos ter sempre em consideração que um objeto não é simplesmente um
elemento do mundo real, mas, sim, que é um objeto do mundo real que possui relevância para
solução de um determinado problema. Assim como no mundo real, um objeto possui
características e executa determinadas ações, ou possui determinados comportamentos.
Às características de um objeto, damos o nome de atributos, e aos
comportamentos, de métodos.
O paradigma da orientação a objetos é baseado nos seguintes pilares:
 Classes - Podemos definir classe, ou classe de objetos, como um grupo de
objetos com mesmas propriedades (atributos), comportamento
(operações), relacionamentos e semântica. Uma classe deve possuir
responsabilidades bem-definidas, cada responsabilidade representa um
contrato ou obrigações dela.
Classe é uma especificação do objeto

 Encapsulamento – Deixar visível apenas o que é necessário.

 Abstração - Abstração é um dos principais conceitos aplicados à resolução
de problemas, que é fundamental para a modelagem da estrutura de um
sistema de software. Abstração está ligada à nossa capacidade de
selecionar determinados aspectos do problema e isolar o que é importante
para algum propósito, ou seja, é dar ênfase àquilo que é necessário.
A melhor forma de se representar a estrutura estática de um sistema orientado a
objetos é utilizando o modelo de classes, são três os modelos utilizados (BEZERRA, 2006):
 Modelo de classe de domínio: desenvolvido na fase de análise, o modelo
de classe de domínio representa os objetos, ou classes, inerentes ao domínio do
problema que queremos resolver, deixando de lado, nessa visão, detalhes
tecnológicos da solução do problema.
 Modelo de classe de especificação: construído na fase de desenvolvimento,
o modelo de classe de especificação adiciona ao modelo de classes de domínio,
objetos ou classes específicas para a solução do problema sob o aspecto
tecnológico, ou seja, é uma extensão do modelo de classe de domínio.
 Modelo de classe de implementação: o modelo de implementação nada
mais é que a implementação das classes, especificadas no modelo de
especificação, construídas ou codificadas em alguma linguagem de
desenvolvimento orientada a objetos, como a linguagem Java ou a linguagem
C#.
 7.2 Modelo de classe de domínio

O modelo de classes de domínio representa os objetos, ou classes, inerentes ao

domínio do problema que queremos resolver, deixando de lado, nessa visão, detalhes
tecnológicos da solução do problema.

7.1.1 Conceitos fundamentais do modelo de domínio

Normalmente identificamos uma classe pelo que ela representa dentro do domínio
do negócio em que estamos trabalhando, por exemplo: a classe Cliente Pessoa Física representa
todos os clientes do tipo pessoa física que podem efetuar saques em nosso terminal de
autoatendimento.

7.2.2 Relacionamento entre classes

Existem cinco tipos de relacionamento entre objetos. Quatro deles, estudaremos

na sequência. São eles: dependência, associação, agregação e composição. O quinto e último
tipo, a herança, será debatido separadamente.
 7.2.2.1 Dependência

Segundo Booch, Jacobson e Rumbaugh (2006), dependência é um relacionamento

em que um objeto depende de informações de outro objeto para a execução de um determinado
comportamento.
Na UML, representamos a dependência utilizando uma seta tracejada, como
mostra a figura a seguir. Ainda na imagem, podemos fazer a leitura de que a Classe A depende da
Classe B.

7.2.2.2 Associação

A associação mostra que um objeto pode se relacionar com outro, que existe uma
conexão entre esses objetos. Existem dois tipos de associação:
 Associação binária: amplamente utilizada, é a associação entre duas
classes apenas.
 Associação enésima: raramente utilizada, é a associação entre mais de
duas classes (BOOCH; JACOBSON; RUMBAUGH, 2006).

Na UML, representamos a associação como uma reta, ou uma linha, que conecta
as classes que se associam de alguma forma.

Para quantificar essa associação, utilizamos o conceito de multiplicidade, que

nada mais é que a representação da quantidade que um objeto pode possuir numa relação de
associação.
 O conceito de multiplicidade é muito semelhante ao conceito de cardinalidade,
que pode ser observado no MER (Modelo Entidade Relacionamento) quando do
desenvolvimento do modelo conceitual de um banco de dados. Mas é importante ter em mente
que é uma semelhança apenas, uma vez que são utilizados em momentos e para finalidades
distintas no projeto.
Existe ainda outra variação de associação, chamada associação reflexiva, que é
quando objetos da mesma classe são associados, sendo que nessa associação esses objetos
possuem papéis distintos, como mostra a figura a seguir.

Ainda a partir da figura, podemos tirar as seguintes conclusões:

 Um objeto X do tipo Classe A está associado a um objeto Y da mesma
Classe A. No entanto, ambos desempenham papéis distintos nessa
associação.
 Como observa Bezerra (2006), essa representação não significa que um
objeto se associa com ele mesmo.
 7.2.2.3 Agregação

A agregação é utilizada para representar uma conexão entre dois objetos, sendo que essa
conexão define uma relação todo-parte entre esses objetos, ou seja, um objeto está contido no
outro (BEZERRA, 2006).
Na UML, representamos agregação utilizando uma reta saindo da classe que representa
a parte e se conectando a um losango, também chamado de diamante, na classe que representa o
todo.

7.2.2.4 Composição

A composição tem exatamente o mesmo conceito da agregação, ou seja, estabelece uma

relação todo-parte entre dois objetos.
A única diferença entre composição e agregação é que a classe que representa a parte da
relação, para existir, depende da classe que representa o todo, ou seja, o ciclo de vida do objeto
da classe parte depende do ciclo de vida do objeto da classe todo.

Assim como na associação e na agregação, na composição também temos o

conceito de multiplicidade, que define a quantidade de objetos compostos na relação todo-parte.
 7.2.2.5 Classes associativas

Classes associativas são associações que possuem propriedades de classe

(BOOCH; JACOBSON; RUMBAUGH, 2006), ou, como observa Bezerra (2006), são classes
que, em vez de estarem ligadas à outras classes, estão ligadas a uma associação.
Normalmente utilizamos classes associativas quando desejamos armazenar
informações importantes de uma associação.

7.2.3 Herança

Um objeto pode herdar atributos e métodos de outro objeto

Classe mãe, ou superclasse, possui atributos e métodos que podem ser herdados
por uma ou mais classes filhas, também chamadas de subclasses.
Na UML, representamos herança com uma seta direcional, sendo que a ponta da
seta é cheia
  As subclasses A e B herdam atributos e métodos da superclasse. No
entanto, podem ter seus próprios atributos e métodos, que não serão
compartilhados entre elas ou com a superclasse

A figura anterior mostra um exemplo claro de herança simples, no qual uma

classe filha herda atributos e métodos de apenas uma classe mãe. No caso, as subclasses A e B
herdam atributos e métodos apenas da superclasse.
Todavia, existe ainda outro tipo de herança: a herança múltipla. Diferentemente
da herança simples, na herança múltipla uma classe filha pode herdar atributos e métodos de
duas ou mais classes mãe.

Quando falamos em herança de classes, estamos falando em criar uma hierarquia,

na qual são comuns os termos “um tipo de”, “generalização” e “especialização”, como pode
ser notado anteriormente.
Hierarquia de classes pressupõe uma relação de “um tipo de”, na qual uma classe
filha é um tipo de uma classe mãe, ou seja, ela possui todas as características da classe mãe e
mais as suas próprias
A herança é dos principais conceitos da orientação a objetos, pois fecha com um
dos principais benefícios do paradigma: o reuso.

7.2.4 Diagramas de classes

Segundo Booch, Jacobson e Rumbaugh (2006), diagrama de classes é um diagrama

UML que tem como objetivo representar a estrutura estática das classes de um sistema de
software.
 Resumindo, um diagrama de classes é a representação das classes, seus atributos,
métodos e o relacionamento entre essas classes, que debatemos na seção anterior
No entanto, é importante que saibamos algumas diferenças entre modelo de classes
e diagrama de classes.
O modelo de classes é mais abrangente. Nele não representamos apenas as classes,
mas também devemos nos atentar em descrever detalhadamente o que cada classe representa
dentro do domínio do problema.
Assim sendo, podemos considerar que um modelo de classes se utiliza do
diagrama de classes como ferramenta para representar uma determinada visão ou um
determinado tipo do modelo de classes.
A Figura a seguir mostra um exemplo de diagrama de classes e o quadro em
seguida mostra os conceitos e as interpretações do modelo de classes representado pelo diagrama
de classe da figura
 7.2.5 Diagrama de objetos

O objetivo de um diagrama de objetos é representar instâncias de classes, ou seja,

objetos e suas respectivas ligações ou associações. Podemos dizer, então, que a base do diagrama
de objetos é o diagrama de classes.
O diagrama de objetos fornece uma visão dos objetos, suas informações e seus
relacionamentos em um determinado cenário em determinado momento de execução desse
cenário.
A figura a seguir mostra três possíveis representações para objetos, instâncias:
A) A classe ClasseA foi identificada no modelo de classes como sendo do domínio e possui
atributos e métodos.
B) Representa um objeto de nome Objeto A, que é uma instância da classe ClasseA. Essa é a
representação mais utilizada de objetos:
Nome do Objeto + Separador : + Nome da Classe
C) Representa um objeto não identificado, também chamado de anônimo, que é uma instância da
classe ClasseA.
D) Representa um objeto de nome Objeto A cuja classe não foi especificada. Esse tipo de
representação é pouco utilizado pelo grau de ambiguidade que acaba gerando. Utilizamos essa
notação normalmente em um determinado momento da modelagem, quando ainda não temos a
definição pronta da classe e desejamos fazer uma simulação de um determinado cenário do qual
esse objeto faz parte.
 8. VISÃO ESTRUTURAL DINÃMICA

Um sistema de software, dentro do paradigma da orientação a objetos, pode ser

considerado como uma coleção de objetos que possuem atributos e métodos e que interagem
entre si para resolver um determinado problema
A visão estrutural dinâmica, também chamada de visão comportamental, tem como
objetivo representar a interação dos objetos para atingir um determinado objetivo.
O objetivo a ser atingido por um conjunto de objetos, como vimos, está
representado nos casos de uso, nas regras de negócio. Logo, podemos dizer que um conjunto de
objetos interage entre si para a realização de casos de uso e a forma como essa interação se dá é
representada pelo modelo estrutural dinâmico.

8.1 Realização de casos de uso

O fundamental para a realização de casos de uso é saber que essa realização se dá a

partir da interação entre objetos, todavia, apenas isso não basta.
Em orientação a objetos, em primeiro lugar precisamos definir as
responsabilidades de cada objeto. A abordagem para definição de responsabilidades de objetos
é chamada de método dirigido a responsabilidades, que se baseia em um dos conceitos
fundamentais da orientação a objetos: encapsulamento do comportamento e das
características do objeto (WIRFS-BROCK e WILKERSON, 1989).

8.2 Classes de análise

Como observa Bezerra (2006), a responsabilidade de um objeto é a “obrigação” que

ele deve cumprir no sistema de software do qual faz parte. Todavia, em alguns casos, o objeto
não consegue cumprir com a sua “obrigação” de forma autônoma, precisando da colaboração de
outros objetos.
Os objetos são divididos e categorizados em três grupos de acordo com seu tipo de
responsabilidade: classe entidade, classe de controle e classe de fronteira.
A forma de organizar essas classes, também chamadas de classes de análise, vai ao
encontro de um dos princípios fundamentais da orientação a objetos: divisão de
responsabilidades.
 A divisão de responsabilidades é uma das características fundamentais em uma boa
modelagem de sistemas. Objetos com responsabilidades bem definidas aumentam a sua
capacidade de reuso.
No caso, a divisão de responsabilidades pode ser encarada como um padrão de
projeto com o objetivo de aumentar o reuso e diminuir o acoplamento entre objetos de um
sistema. Esse conceito é a base para o padrão de projeto MVC (Model-View-Controller)
8.2.1 Entidade

Uma entidade, classe de entidade ou ainda objeto de entidade, são objetos mais
próximos do domínio do mundo real que o sistema representa, são abstrações do mundo real que
normalmente conseguimos identificar nos casos de uso.
Esses objetos têm como objetivo principal manter informações referentes ao
domínio de problema que queremos resolver.

8.2.2 Fronteira

Classes de fronteira ou objetos de fronteira, como o próprio nome já diz, têm como
responsabilidade dividir o ambiente interno do sistema e suas interações externas.
Podemos interpretar interações externas a um sistema como toda e qualquer
comunicação que um sistema faz com atores do sistema ou ainda alimentar informações de
outros sistemas.

8.2.3 Controle

Classes de controle, objetos de controle ou ainda controladores são objetos que têm
como objetivo realizar o sequenciamento da execução de um caso de uso na estrutura de objetos
do sistema, fazer a coordenação entre as camadas internas do sistema, representadas pelas classes
de entidade, com as camadas externas ao sistema, representadas pelas classes de fronteira.
Alguns autores também chamam esse movimento de orquestração.

8.3 Comportamento de objetos

Comportamentos, ou métodos de objetos, possuem certos aspectos a serem

conceituados, como a forma que os representamos e características próprias da orientação a
objetos
 8.3.1 Representando métodos

Representamos métodos da mesma forma que representamos funções. Um método,

bem como uma função, possui um nome que o identifique e pode ou não possuir parâmetros de
entrada e ou saídas com determinados tipos de dados.

8.3.2 Polimorfismo

É quando um objeto tem um comportamento diferente para a mesma

É quando uma classe filha herda um método de uma classe mãe, ou seja, o método na
classe filha possui a mesma assinatura do método da classe mãe, todavia possuem
implementações diferentes, reagem de maneiras diferentes à mesma ação.
Polimorfismos nos conferem duas características importantes na orientação a objetos
(LARMAN, 2007):
 Facilidade na introdução de novas implementações, possibilitando
manutenibilidade e extensão ao sistema.
 Encapsulamento das variações de implementação.
Na UML, não temos uma representação específica para polimorfismo, como mostra a
figura a seguir. No entanto, vale ressaltar que a especificação do método polimórfico pode não
constar literalmente no diagrama de classes da UML, mas deve necessariamente estar
documentado no modelo de classes.

8.3.3 Visibilidade de atributos e métodos

Visibilidade indica quando e em que nível um atributo ou um método de um objeto

pode ser acessível aos objetos que se relacionam com ele. Em orientação a objetos, temos três
níveis de visibilidade de atributos e métodos: Público (+), Privado (-), Protegido (#).
 8.3.4 Interfaces

Uma interface, em orientação a objetos, pode ser definida como um contrato que
define quais métodos devem ser implementados por uma classe. Uma interface define o que deve
ser implementado, mas não como deve ser implementado, define a assinatura de um método, mas
não a forma de implementação, que fica a cargo da classe.
Resumindo, interface é um contrato que contém apenas assinaturas de métodos (não
contém atributos) e que podem ser implementados por mais de uma classe.
Na UML, representamos interfaces com o estereótipo <<interface>> e, como boa
prática, o nome sempre começa com a letra I (interface), como mostra a figura a seguir.

8.3.5 Ciclo de vida de objetos

Dentro de um sistema de software, um objeto é criado, utilizado e destruído,

obrigatoriamente nessa sequência. Isso é o que chamamos de ciclo de vida de objetos e que
envolvem alguns conceitos.
Construtor é um método da própria classe que tem como objetivo a criação da
estrutura do objeto em memória.
 Geralmente, nas linguagens de desenvolvimento orientado a objetos, não há a
necessidade do desenvolvedor efetivamente implementar um construtor manualmente, basta
saber alguns conceitos básicos:
 Um construtor é um método da própria classe.
 Um construtor é um método público.
 Um construtor não possui saída.
 Um construtor pode ou não receber parâmetros de entrada.

Se para construir um objeto temos o construtor, para destruir o objeto temos o

destrutor, que tem como objetivo remover o objeto da memória. Assim como o construtor, o
destrutor também é um método da própria classe.
Diferentemente do construtor, o destrutor obrigatoriamente não possui saída e não
possui parâmetros de entrada.
Na UML, raramente necessitamos representar um destrutor, isso porque, na maioria
das linguagens e plataformas de desenvolvimento orientadas a objeto, a destruição de objetos da
memória fica a cargo da própria plataforma. Todavia, caso haja necessidade de representação, o
destrutor é representado da mesma forma que o construtor, porém acrescido de um ~ (til).

8.4 Comunicação entre objetos

Basicamente, a comunicação entre objetos se dá pela chamada de métodos. Para isso,

é fundamental os conceitos de encapsulamento e visibilidade de métodos.

8.4.1 Mensagem

Uma mensagem pode ser considerada um meio de comunicação entre objetos e tem
como objetivo a ativação de um processamento.
 Uma mensagem pode ter três significados (STADZISZ, 2002):
 Chamada de função ou procedimento: é o tipo mais utilizado de mensagem.
Significa que um objeto está solicitando a execução de um método de outro
objeto.
 Envio explícito de mensagem utilizando um tipo de serviço bem específico e
especializado para envio e recebimento de mensagens, por exemplo: Message
Queue (fila de mensagens).
 Evento: quando uma mensagem é enviada para um objeto do sistema
originária de um evento externo ao sistema. É comum que esse tipo de
mensagem seja próprio da comunicação entre atores e objetos. Por exemplo:
um clique de mouse pode ser considerado um evento externo ao sistema e que
deve ser interpretado por um objeto .interno do mesmo sistema.

8.4.2 Diagrama de sequência

O diagrama de sequência da UML representa a interação de um conjunto de

objetos, a troca de mensagens entre eles para resolver um problema específico. Uma
característica positiva do diagrama de sequência é que podemos visualizar a troca de mensagens
de forma sequencial e encaixada em uma linha de tempo.
Em um diagrama de sequência podemos representar todos os objetos e atores que
fazem parte do cenário do problema que desejamos representar. Idealmente, representamos em
um diagrama de sequência um cenário específico de um problema que queremos resolver,
podemos fazer uma quebra por casos de uso ou por regras de negócio, a depender da
complexidade de cada um, com o intuito de deixar o diagrama de sequência o mais inteligível
possível.
 Existe dois tipos de mensagens

Mensagens síncronas

Criam uma dependência do estado do objeto que enviou uma mensagem com o
estado do objeto que a recebe. Isso significa que o objeto que enviou a mensagem não tem seu
estado alterado, não executa nenhuma ação, até que o objeto que recebeu a mensagem permita.

Mensagens assíncronas
Ao contrário das mensagens síncronas, as assíncronas não criam uma dependência
do estado do objeto que enviou a mensagem com o estado do objeto que a recebe. Ou seja, o
objeto que enviou a mensagem pode executar qualquer ação independentemente da reação do
objeto que recebeu a mensagem.

Criação e destruição de objetos

 Em orientação a objetos, quando um objeto cria outro para utilizá-lo ou para
enviar-lhe uma mensagem, dizemos que o primeiro possui uma referência à instância do objeto
criado.

Autodelegação de mensagens

Todavia, um objeto pode enviar uma mensagem para ele mesmo, solicitando a
execução de um método privado. Esse movimento é chamado de autodelegação

Notação de estruturas de decisão e de repetição