ANÁLISE DE SISTEMAS ORIENTADOS A OBJETOS

Prévia do material em texto

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 Introdução 
 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 valor a esse processo (BEZERRA, 2006) 
 
 
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? 
 
Te
cn
o
lo
gi
a 
d
e 
si
st
em
aa
s 
d
e 
in
o
fr
m
aç
ão
Infraestrutura
Servidores
Computadores
Sistemas 
Operacionas
Sistemas de 
Software
 
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
Enfase no cmo fazer para 
desenvolver um sistema de software
Ferramentas
Fornecem suporpte para processo 
de desenvolvimento de software
Processos
Definem quando e onde fazer e 
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 interessanteobservado 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 umponto 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.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çõesobtidas 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çae 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ísticasde 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.2.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çãodas 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 oestereó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