Prévia do material em texto

UML e o Processo Unificado de 
Desenvolvimento
Análise e Projeto de 
Software Orientado 
a Objetos
Diretor Executivo 
DAVID LIRA STEPHEN BARROS
Gerente Editorial 
CRISTIANE SILVEIRA CESAR DE OLIVEIRA
Projeto Gráfico 
TIAGO DA ROCHA
Autoria 
JOÃO DANILO NOGUEIRA
LEANDRO C. CARDOSO
AUTORIA
João Danilo Nogueira
Sou graduado em Ciência da Computação pela Faculdade 
Grande Fortaleza (FGF) e amo programar. Atualmente, o foco de minha 
expertise é na área de gerenciamento de projetos, teoria dos números, 
RSA e criptografia. Vai ser um prazer enorme ajudar VOCÊ a se tornar 
um excelente desenvolvedor de software ou administrador de banco 
de dados. Conte comigo para lhe ajudar nessa trajetória rumo ao seu 
desenvolvimento profissional! Muito sucesso para você. Conte comigo!
Leandro C. Cardoso 
Sou formado na Graduação em Comunicação Social com 
Habilitação em Design Digital, e mestrado em Tecnologias da Inteligência 
e Design Digital pela PUC-SP, com uma experiência em direção de arte 
e criação na área com mais de 20 anos. Passei por empresas, a exemplo 
da Laureate International Universities, FMU, FIAM-FAAM, Universidade 
Anhembi Morumbi, Universidade do Centro Paula Souza (FATEC-ETEC), 
DeVry Brasil, UNEF, FAESF, Faculdade Positivo, Uninter, Platos Soluções 
Educacionais S.A. (Krotonn - Universidade Anhaguera). Além disso, atuei 
como analista de Desenvolvimento Pedagógico Sênior, Coordenador 
de Curso Técnico de Comunicação Visual e Revisor Técnico e Validador 
para Curso EAD. Também sou autor de mais de 10 livros didáticos um dos 
organizadores da Maratona de Criação e Design do Curso de Comunicação 
Visual da ETEC Albert Einstein. Sou apaixonado pelo que faço e adoro 
transmitir minha experiência de vida àqueles que estão iniciando em suas 
profissões. Por isso fui convidado pela Editora Telesapiens a integrar seu 
elenco de autores independentes. Estou muito feliz em poder ajudar você 
nesta fase de muito estudo e trabalho. Conte comigo!
ICONOGRÁFICOS
Olá. Esses ícones irão aparecer em sua trilha de aprendizagem toda vez 
que:
OBJETIVO:
para o início do 
desenvolvimento de 
uma nova compe-
tência;
DEFINIÇÃO:
houver necessidade 
de se apresentar um 
novo conceito;
NOTA:
quando forem 
necessários obser-
vações ou comple-
mentações para o 
seu conhecimento;
IMPORTANTE:
as observações 
escritas tiveram que 
ser priorizadas para 
você;
EXPLICANDO 
MELHOR: 
algo precisa ser 
melhor explicado ou 
detalhado;
VOCÊ SABIA?
curiosidades e 
indagações lúdicas 
sobre o tema em 
estudo, se forem 
necessárias;
SAIBA MAIS: 
textos, referências 
bibliográficas e links 
para aprofundamen-
to do seu conheci-
mento;
REFLITA:
se houver a neces-
sidade de chamar a 
atenção sobre algo 
a ser refletido ou dis-
cutido sobre;
ACESSE: 
se for preciso aces-
sar um ou mais sites 
para fazer download, 
assistir vídeos, ler 
textos, ouvir podcast;
RESUMINDO:
quando for preciso 
se fazer um resumo 
acumulativo das últi-
mas abordagens;
ATIVIDADES: 
quando alguma 
atividade de au-
toaprendizagem for 
aplicada;
TESTANDO:
quando o desen-
volvimento de uma 
competência for 
concluído e questões 
forem explicadas;
SUMÁRIO
Diagramas da UML...................................................................................... 10
O que é um Diagrama? ...............................................................................................................10
Processo Unificado de Desenvolvimento de Software ............... 21
Conceituação ..................................................................................................................................... 21
Ciclo de Vida .......................................................................................................................................23
Concepção do Processo Unificado .....................................................30
A Fase de Concepção ................................................................................................................. 30
Estudo de Caso ............................................................................................................. 31
Desenvolvendo o Esboço do Projeto ........................................................... 36
Elaboração do Processo Unificado ......................................................39
A Fase de Elaboração ................................................................................................................. 39
Detalhamento da Fase ................................................................................................................43
7
UNIDADE
02
Análise e Projeto de Software Orientado a Objetos
8
INTRODUÇÃO
Você sabia que a área de processos unificados no desenvolvimento 
de software, é uns dos pilares para o entendimento e realização na 
prática da análise e projeto de softwares orientados a objetos? Isso 
mesmo. Mas, para isso, é importante o conhecimento prévio do conceito 
e das aplicações gerais da UML - Modeling Language, ou a Linguagem 
Unificada de Modelação em projetos orientados a objetos. É importante, 
além da teoria, executar a aplicação prática dos conceitos na estruturação 
de um processo unificado de desenvolvimento de software orientado 
a objetos, utilizando os diagramas e notações da UML - Linguagem 
Unificada de Modelação. Para isso, é relevante o conhecimento das 
técnicas de desenvolvimento unificado de sistemas. Entendeu? Portanto, 
ao longo desta unidade letiva, você vai mergulhar neste universo!
Análise e Projeto de Software Orientado a Objetos
9
OBJETIVOS
Olá. Seja muito bem-vindo à Unidade 2. Nosso objetivo é auxiliar 
você no desenvolvimento das seguintes competências profissionais até o 
término desta etapa de estudos:
1. Utilizar os diagramas da Linguagem de Modelação Unificada, bem 
como diferenciar seus usos e estéticas.
2. Discernir sobre o que é processo unificado de desenvolvimento de 
software, suas fases e as atividades de um fluxo de trabalho.
3. Identificar todos os procedimentos e características da fase de 
concepção de um processo unificado.
4. Aplicar todos os procedimentos e características da fase de 
elaboração de um processo unificado.
Análise e Projeto de Software Orientado a Objetos
10
Diagramas da UML
OBJETIVO:
Ao término deste capítulo, você será capaz de compreender 
e utilizar os diagramas da Linguagem de Modelação. 
Isto será fundamental para o exercício de sua profissão. 
E então? Motivado para desenvolver esta competência? 
Desta forma, vamos lá. Avante!
O que é um Diagrama?
Diagramas são elementos gráficos de uma linguagem de 
comunicação. Podemos utilizar diagramas em quase tudo em nosso dia 
a dia, desde em um simples organograma de um setor ou empresa, até 
em sofisticados fluxogramas que orientam como determinado processo 
irá funcionar em um programa de computador.
Você pode utilizar diagramas de todo tipo para se expressar, como 
é o caso dos mapas mentais, o qual é considerado uma técnica cognitiva. 
Os mapas mentais são diagramas bastante requisitados por professores 
e alunos, com o objetivo de facilitar o entendimento de aulas e assuntos 
lidos em livros didáticos. A UML - Linguagem Unificada de Modelação, 
utiliza de nove tipos de diagramas: 
1. Casos de uso; 
2. Classes;
3. Objetos; 
4. Estados; 
5. Sequência;
6. Colaboração; 
7. Atividade; 
8. Componente; 
9. Execução (MICROSOFT, 2018).
Análise e Projeto de Software Orientado a Objetos
11
Todo e qualquer sistema é composto por uma estrutura estática 
e um comportamento dinâmico. Considerando isso, a UML suporta os 
modelos de estrutura estática e dinâmica, além de abranger o modelo 
funcional, para isto, ela se prende a diagramas específicos (FOWLER, 
2007). Os responsáveis pelo modelo estático são os diagramas de 
classes e de objetos, que incluem toda a representação das classes e 
seus relacionamentos. A parte de modelação dinâmica se dá por meio de 
diagramas de estados, sequências,colaboração e atividades, enquanto a 
parte funcional é suportada pelos diagramas de componentes e execução. 
Figura 1 - Organograma, um exemplo de diagrama
Fonte: Nogueira (2018a, p. 14).
O diagrama de casos de uso descreve todos os elementos do 
sistema por meio de atores externos, casos de uso e processos, cabe 
aos atores o papel de representar entidades, como sistemas externos, 
usuários ou hardwares. São os atores que estabelecerão canais de 
comunicações com o sistema em cada caso de uso. Os casos de uso, 
por sua vez, representam sequências de ações a serem executadas pelo 
sistema, respondendo à comunicação dos seus respectivos atores.
IMPORTANTE:
Um diagrama de caso de uso serve para descrever e definir 
todos os requisitos funcionais de um sistema.
Análise e Projeto de Software Orientado a Objetos
12
A imagem a seguir representa um exemplo de diagrama de casos 
de uso. Neste exemplo, apenas um ator envolve-se com todos os casos 
de uso, mas poderiam ser vários. Além disso, tal figura descreve todas as 
funções possíveis para um ator externo a um sistema de controle bancário, 
sendo que o ator é o gerente desse sistema e é capaz de realizar cada 
uma das ações descritas nos balões de casos de uso.
Figura 2 - Exemplo de um diagrama de casos de uso de uma agência bancária, na qual o 
ator é o gerente da agência
Cadastrar 
cliente
Abrir conta 
corrente
Fechar 
conta corrente
Abrir 
poupança
Fechar 
poupança Cadastrar 
agência
Remover 
ou atualizar 
cliente
Remover 
ou atualizar 
operação
Cadastrar 
operação
Cadastrar 
dependente
Remover 
ou atualizar 
agência
Fonte: Nogueira (2018a, p. 14).
Assim, o diagrama de classes é utilizado para demonstrar 
graficamente a estrutura das classes criadas para o sistema modelado. 
Cada classe representa elementos gerenciados pela aplicação final. 
O diagrama de classes utiliza diversos relacionamentos, tais como 
associação, dependência, especialização, agrupamentos etc. 
Nesse sentido, o diagrama de classes mostra todos os 
relacionamentos, juntamente com as estruturas internas das classes, 
atributos e métodos. Somado a isso, ele é considerado estático, pois sua 
estrutura permanece a mesma em todos os ciclos de vida do sistema. 
Assim, a imagem a seguir representa um exemplo deste tipo de diagrama.
Análise e Projeto de Software Orientado a Objetos
13
Figura 3 - Exemplo de um diagrama de classes para um sistema de controle de locação de 
veículos
Cliente
Contrato de aluguel Veículo alugado
Companhia 
de aluguel de 
veículos
Caminhão Carro 
esportivo
Carro de 
passeio
Tipos de veículo
possui
Refere-se a
possui
1
1
0..*
0..*
0..1
Fonte: Nogueira (2018a, p. 17).
Os diagramas de classes, quando implementados em parceria com 
o desenvolvimento, normalmente já são desenhados contendo sintaxes 
e referências à linguagem de programação a ser aplicada ao projeto 
(MICROSOFT, 2018). 
IMPORTANTE:
Classes apenas irão aparecer em um diagrama se, e 
somente se, possuírem relacionamentos entre si.
Como sabemos, em um sistema, muitas classes não possuem 
relacionamento entre elas. Por conta disso, perceba que um sistema 
raramente possuirá apenas um diagrama de classes. No diagrama de 
objetos, objetos utilizados no sistema são demonstrados graficamente, 
além disso, esse diagrama expõe as instâncias das classes, traçando 
uma espécie de modelo do sistema em determinado momento. A 
imagem ilustrada adiante traz um exemplo de um diagrama de objetos, 
apresentando três deles referente a um sistema de controle de locação 
de veículos.
Análise e Projeto de Software Orientado a Objetos
14
Figura 4 - Exemplo de um diagrama de objetos do mesmo sistema de locação 
anteriormente apresentado
2679: Contrato de aluguel
Num_Contrato: 2679
Veículo: “Audi V8”
Pablo: Cliente
Nome: “Pablo F. Barros”
Idade:20
CPF: 941689121-05
2678: Contrato de 
aluguel
Num_Contrato: 2678
Veículo: “BMW 914”
Fonte: Nogueira (2018a, p. 18).
O diagrama de objetos não possui a importância de um diagrama 
de classes, mas, em sua composição, existem todos os relacionamentos 
definidos no diagrama de classes, com a exceção de que, no diagrama 
de objetos, temos modelos de valores finais se relacionando. Vale 
ressaltar também que esses diagramas são utilizados, geralmente, 
para exemplificar partes complexas dos relacionamentos, muitas vezes, 
utilizados como parte dos diagramas de colaboração.
Já o diagrama de estados é um complemento do diagrama de 
classes, mostrando todos os possíveis estados que um objeto pode 
demonstrar e quais eventos do sistema irão realizar modificações de 
estado. Esse diagrama, por mais que seja um complemento descritivo, 
raramente é desenhado para todas as classes do sistema, mas sim para 
aquelas que possuem números definidos de estados e que afetam o 
sistema de maneira diferente para cada estado. Adiante, você pode 
conferir um exemplo dele.
Análise e Projeto de Software Orientado a Objetos
15
Figura 5 - Exemplo de um diagrama de estado para um transeunte se deslocando entre 
dois andares
Chegar ao 
térreo
Chegar ao andar
Tempo de espera
Subir 
andar
Subir 
andar
Chegar ao 
andar
Descer 
andar
No térreo
Descendo
Subindo
Parado
Indo para 
o térreo
Fonte: Nogueira (2018a, p. 19).
Os diagramas de estados possuem o item chamado “Ponto de 
Início”, além de um, ou mais “pontos de finalização”. No diagrama da 
figura anterior, o ponto de início é representado por uma pequena 
circunferência simples. Já os pontos de finalização são representados por 
uma circunferência menor circunscrita em um círculo maior. 
Ainda no diagrama do exemplo, temos um clássico loop de 
informações, que nunca irá encontrar seu fim, por isto não apresentamos 
um exemplo de ponto de finalização. Além disso, o referido diagrama 
mostra os estados de um transeunte andando por um estabelecimento 
que possui dois andares, e explica como seria representado seu 
comportamento em cada uma das possibilidades de deslocamento.
No diagrama de sequência, é o utilizado para demonstrar 
colaborações dinâmicas entre objetos, a partir dele é possível observar-se 
toda a estrutura de mensagens enviadas entre os objetos. O diagrama de 
sequência é capaz de demonstrar a interação, o evento que ocorre, o que 
esse evento afeta e o que ocorrerá em determinados pontos do sistema. 
Ele também é chamado de Diagrama de Linha do Tempo, por ser capaz de 
mostrar todos os objetos protagonistas em uma linha horizontal e, abaixo 
dos mesmos, toda a linha cronológica de ações que irá desencadear um 
evento final.
Análise e Projeto de Software Orientado a Objetos
16
Figura 6 - Diagrama de sequência aplicado ao spooler de impressão
Computador
Servidor de 
impressão
Impressora Fila
Imprimir arquivo [Impressora livre]
Imprimir arquivo
[Impressora 
ocupada]
Imprimir arquivo
Fonte: Nogueira (2018a, p. 20).
No diagrama ilustrado na anterior, temos uma demonstração da 
sequência de passos para que um computador realiza para impressão 
de um arquivo. Perceba que o computador envia a mensagem para o 
servidor de impressão, que manda a mensagem para a fila da impressora, 
que se comunica com a impressora para verificar se ela está livre ou não, 
para somente então realizar a impressão.
Além disso, o diagrama de colaboração possui um formato mais 
limpo para se demonstrar um diagrama de sequência, ou seja, ele 
representa uma alternativa ao diagrama de sequência. Desta forma, ele é 
um pouco mais completo que o de sequência, pois, além de mostrar as 
mensagens do sistema, mostra também seus relacionamentos. 
Mas, em que situações deve-se utilizar um ou outro? O fator 
determinante para esta escolha está na função do tempo, isto é, se o 
diagrama for tratar de uma sequência de eventos que ocorre no tempo, o 
diagrama de sequência será a escolha mais adequada. Porém, se a função 
for contextual, o de colaboração é a escolha certa. Para exemplificarmos, 
vamos retomar o mesmo exemplo ilustradopara o diagrama de sequência, 
só que utilizando o diagrama de colaboração, neste caso, teríamos a 
seguinte ilustração com apresentando na figura a seguir.
Análise e Projeto de Software Orientado a Objetos
17
Figura 7 - Diagrama de colaboração de um spooler de impressão
Computador
Servidor de 
impressão Impressora 
Fila
1. Imprimir 
arquivo
[Impressora livre]
1.1 Imprimir arquivo
[Im
pr
es
so
ra
 oc
up
ad
a]
1.2
 A
rm
az
en
ar 
(ar
qu
ivo
)
Fonte: Nogueira (2018a, p. 21). 
Como podemos observar na ilustração da figura anterior, o modelo 
de colaboração é semelhante ao diagrama de objetos, listando vários 
objetos juntamente com os seus relacionamentos. A diferença é que, 
neste, não teremos a descrição de atributos e métodos, mas apenas as 
mensagens de comunicação. 
Note ainda que, no diagrama de colaboração do sistema de 
spooler de impressão da figura anterior, as mensagens estão numeradas, 
incluindo os estados que permitem as mensagens serem entregues ou 
não para determinado objeto, como, por exemplo, quando o estado do 
objeto Impressora for “Livre”, ela irá receber o comando de imprimir. Já 
quando o estado do objeto Impressora for “Ocupado”, a mensagem de 
armazenamento será enviada para o Objeto Fila.
Já o diagrama de atividades é aquele que descreve todas as 
ações do sistema e seus resultados. Todos os trabalhos executados em 
operações e atividades de instâncias de objetos são representados por 
este diagrama. Podemos dizer que o diagrama de atividades captura as 
ações e resultados causados pelas mudanças de estado do sistema. 
Análise e Projeto de Software Orientado a Objetos
18
Assim, enquanto o diagrama de estados. São cinco os objetos do 
diagrama de atividades: 
1. Capturar os trabalhos resultantes da execução de operações; 
2. Capturar os dados das ações de um objeto; 
3. Mostrar as formas de como as ações podem ser executadas e 
seus respectivos resultados; 
4. Mostrar como uma instancia de classe pode ser executada; 
5. Mostrar como um negócio funciona, através dos atores e fluxos.
A figura a seguir ilustra como o diagrama de atividades é capaz de 
representar determinado fluxo de atividades.
Figura 8 - Diagrama de colaboração de um spooler de impressão
Remover Caixa 
de Mensagem
Imprimir arquivo ()
(Di
sco
 ch
eio
)
(Espaço em disco)
^Impressora.Imprimir (arq)
Criar arquivo 
PostScript
Mostrar caixa 
de mensagem 
“Disco cheio”
Mostrar caixa 
de mensagem 
“Disco cheio”
Fonte: Nogueira (2018a, p. 22).
Já o diagrama de componentes é um diagrama que, juntamente 
com o diagrama de execução, demonstra o lado funcional do sistema, seu 
objetivo é descrever todos os componentes do sistema e as dependências 
entre os mesmos. Entende-se por componente toda a estruturação lógica 
de parte do sistema, definido por arquivos de código (como uma classe 
completa e suas ações), uma biblioteca (ou uma estrutura linguística), e 
de partes da implementação da arquitetura física. 
Análise e Projeto de Software Orientado a Objetos
19
Este diagrama mostra os componentes unicamente como tipos, 
sendo que ele se diferencia do diagrama de execução, que mostra as 
instâncias executáveis. Geralmente, componentes representam as partes 
visíveis do sistema, de modo que outros componentes possam enxergar 
e utilizar. A ilustração seguir expressa um exemplo deste tipo de diagrama.
Figura 9 - Exemplo de diagrama de componentes
Gerenciador 
de banco de 
dados
Db.dll
Aplicação
App.excel
Gerenciador de 
comunicação
Comm.dll
Gráficos
Graficos.dll
Fonte: Nogueira (2018a, p. 23).
O diagrama de execução é o responsável por descrever graficamente 
toda a arquitetura física do sistema, além de como o software se relaciona 
com esta arquitetura. Ele ainda descreve os tipos de conexão utilizados 
para realizar a comunicação entre artefatos, como pode ser observado no 
exemplo ilustrado na figura a seguir.
Análise e Projeto de Software Orientado a Objetos
20
Figura 10 - Exemplo de um diagrama de execução
Fonte: Nogueira (2018a, p. 23).
Para que um software seja desenvolvido, é importantíssimo que 
todos os seus requisitos sejam devidamente diagramados, para que o 
resultado final se aproxima ao máximo das necessidades iniciais definidas 
no escopo do projeto.
RESUMINDO:
E então? Gostou do que lhe mostramos? Aprendeu mesmo 
tudinho? Agora, só para termos certeza de que você 
realmente entendeu o tema de estudo deste capítulo, 
vamos resumir tudo o que vimos. Você deve ter aprendido 
que como são desenvolvidas as notações e representações 
gráficas dos diagramas que compõem a UML. Vimos 
que a UML possui notações e regras bem detalhistas, 
que permitem descrever e demonstrar diversos modelos 
orientados a objetos. Realizar a descrição de um sistema 
em UML não prescreve a ação de implementar, já que a 
UML faz parte da zona de planejamento do projeto. Assim, 
podemos afirmar que a UML responde de forma rápida e 
direta “O que fazer?”, “Como Fazer?”, “Quando Fazer?” e “Por 
que deve ser Feito?”, além de demonstrar quantas serão as 
atividades e a ordem em que devem ser executadas. De 
maneira geral a UML se utiliza de um conjunto de diagramas 
para estruturar o projeto de maneira compreensível a todos, 
tanto aos profissionais da área de TI, quanto aos usuários e 
demais atores do sistema em desenvolvimento.
Análise e Projeto de Software Orientado a Objetos
21
Processo Unificado de Desenvolvimento 
de Software
OBJETIVO:
Ao término deste capítulo, você será capaz de compreender 
o que é um processo unificado de desenvolvimento de 
software, suas fases e as atividades de um fluxo de trabalho. 
Isto será fundamental para o exercício de sua profissão. 
E então? Motivado para desenvolver esta competência? 
Então vamos lá. Avante!.
Conceituação
O processo unificado é um conjunto de atividades necessárias para 
unir todos os processos relacionados a um projeto, em prol da entrega 
de um produto final. A UML é apenas uma linguagem de modelagem 
utilizada para criar e ler modelos bem formados, referentes a sistemas 
planejados. Sua estrutura impede que seja definida a cronologia da 
criação e a definição dos quais realmente precisam ser implementados. 
Assim, a atividade de desenvolvimento de software acaba por cair nas 
mãos do processo unificado, que já se utiliza de modelos de UML para 
fins de implementação (BRAZ, 2006). O processo unificado apresenta três 
características que o torna indicado para trabalhar ao lado da UML: 
1. Orientação a casos de uso; 
2. Arquitetura centrada; 
3. Processo iterativo incremental.
Para avançarmos no tema de processo unificado de desenvolvimento 
de software, é importante revisar os conceitos de processo orientado a 
casos de uso, que se trata de um agrupamento de dados cuja finalidade 
é a de descrever uma funcionalidade do sistema. 
Análise e Projeto de Software Orientado a Objetos
22
Também é importante salientar que a um conjunto de casos de 
uso em determinado contexto, quando interage com um ator, atribui-se o 
nome de diagrama de casos de uso. Em outras palavras, um diagrama de 
casos de uso é uma descrição de como determinado sistema funciona, 
e como ele interage com cada tipo de ator, seja ele um usuário ou um 
sistema externo.
Já se tratando de um processo orientado a casos de uso, todo o 
desenvolvimento do projeto visa atender às especificações e reações 
que o ator irá necessitar. Em termos práticos, desenvolvemos módulos 
do sistema para atender cada caso de necessidade, envolvendo cada 
diagrama de caso de uso, obedecendo cada uma de suas exigências, 
para que, ao final, quando unidos, os módulos possam compor todas as 
interações dos atores externos. 
A grande vantagem de um processo orientado a casos de uso é a 
garantia de que um sistema não terá funções desnecessárias, pois toda 
a funcionalidade foi definida por meio da análise sucinta da UML. Desta 
forma, o processo irá seguir todo um fluxo planejado de desenvolvimento,ou seja, os fluxos de trabalho pelos quais o processo irá passar estarão 
definidos e bem empregados.
Sobre o processo centrado na arquitetura, a arquitetura de software 
engloba todos os conceitos significativos do sistema, crescendo de acordo 
com as necessidades de um determinado projeto de desenvolvimento. 
As mudanças de arquitetura atingem diretamente os casos de uso do 
sistema, afetando o desenvolvimento e planejamento do projeto final. A 
arquitetura é influenciada por todos os fatores relacionados ao sistema, 
desde a plataforma até as modularizações criadas pelo software.
IMPORTANTE:
Quando falamos de arquitetura, seja ela a arquitetura de um 
prédio, ou a arquitetura de um sistema, estamos falando de 
uma visão geral de como o projeto se mostra, salientando 
suas características mais importantes.
Análise e Projeto de Software Orientado a Objetos
23
Quando traçamos o relacionamento entre a arquitetura e os casos 
de uso do sistema, percebemos que todas as funcionalidades do sistema, 
descritas nos casos de uso, fazem parte da arquitetura. Então, finalmente, 
abstraímos que o conjunto de casos de uso do sistema define parte 
da arquitetura do software, pois deve haver sempre um balanço entre 
funcionalidade e forma. De maneira geral, um sistema é dito inteligente 
quando sua arquitetura é planejada pensando em possíveis evoluções e 
mudanças, para que, caso ocorram, não venham a ser dificultosas nem 
complexas para serem implantadas.
Já no processo iterativo e incremental, a modularização do sistema 
é a forma mais prática e cômoda de se trabalhar no sistema como um todo. 
Por meio do processo de modularização, criamos pequenos projetos com 
problemas menores, que podem ser também modularizados e facilmente 
solucionados. Desse modo, é possível solucionar problemas bem mais 
complexos essas modularizações são iterativas e incrementais, pois, 
quando juntas, apresentam o resultado final.
DEFINIÇÃO:
Interativo é tudo aquilo que se repete (o mesmo que cíclico 
ou repetitivo) e incremental é tudo aquilo que é adicionado 
de um valor constante a cada novo ciclo.
É importante sempre perceber que cada iteração deve envolver 
casos de uso relevantes, pois, caso contrário, acabam por ser 
desnecessárias, gerando retrabalho. Iterações bem desenvolvidas 
reduzem os riscos e, consequentemente, os custos, a violação de prazos 
e o tempo de desenvolvimento como um todo.
Ciclo de Vida
Para a aplicação de um processo unificado, há de se compreender 
que ele é, na verdade, a reaplicação constante de uma série de ciclos 
que regem toda a vida do sistema. Cada ciclo é responsável pela entrega 
Análise e Projeto de Software Orientado a Objetos
24
de uma versão do sistema, geralmente subdividida em quatro fases: 
Concepção, Elaboração, Construção e Transição. 
Cada uma dessas fases é subdividida em processos de iteração, 
em um total de cinco processos, chamados de fluxos de trabalho, são 
eles: Requisitos, Análise, Projeto, Implementação e Teste. 
Figura 11 - Cada ciclo é responsável pela entrega de uma versão do sistema
Fonte: Nogueira (2018b, p. 23).
Os fluxos de trabalho não são exclusivos, pois eles devem ser 
desenvolvidos simultaneamente, conforme as iterações das fases vão 
se aplicando. Aqui, chamamos de Iterações os pequenos módulos do 
sistema, desenvolvidos dentro de cada fase. Durante todo o ciclo de 
vida do projeto, diversas iterações são aplicadas. Cada iteração gera uma 
Análise e Projeto de Software Orientado a Objetos
25
chamada “versão” do sistema, criando produtos executáveis que são, na 
verdade, subprodutos do projeto final.
Sobre os fluxos de trabalho do ciclo de vida do projeto, para 
compreendermos bem o que vem a ser um fluxo de trabalho, vamos tomar 
algumas definições preliminarmente, tais como as fases que compõem 
um fluxo de trabalho, a saber: Requisitos, Análise, Projeto, Implementação 
e Teste.
Figura 12 - Diagrama de um fluxo de trabalho
Fonte: Nogueira (2018b, p. 23).
É importante salientar que todos os requisitos do sistema devem 
ser especificados neste fluxo, por meio de entrevistas que gerem a lista 
de necessidades dos usuários e clientes. Esses requisitos estão todos 
expressos nos diagramas de casos de uso.
IMPORTANTE:
Lembre-se. Os atores do diagrama são usuários do sistema 
e cada caso de uso é uma funcionalidade.
Durante a concepção, os casos de uso mais relevantes determinam 
os domínios do sistema, a elaboração ajuda a pôr na prática a codificação 
dos casos de uso. Em sua construção, é realizada a “costura” de toda 
Análise e Projeto de Software Orientado a Objetos
26
a implementação para que comecem a funcionar como um sistema 
completo.
Como pode ser observado na figura anterior, a fase de transição 
é também chamada de fase de adaptação, é nesta fase nos quais 
os requisitos que sofreram mudanças são identificados. O fluxo de 
requisitos é mais constante durante as fases de Concepção e Elaboração. 
Normalmente, essas são as fases em que há a coleta, e começa a haver 
diminuição conforme a fase de construção vai se elaborando.
Já o modelo de análise refina os requisitos especificados, por meio 
dos diagramas de classes, ele argumenta quais os tipos de implementação 
que serão realizadas. É o diagrama de análise que define como os estados 
do Diagrama de Estados irão se comportar, e como as interações irão 
ocorrer. 
Durante a fase de concepção, o diagrama de análise é uma 
formalidade, ele passa a se tornar importante a partir da fase de elaboração, 
quando, na prática, os códigos começam a ser desenvolvidos. Como 
pode ser observado na figura anterior, o modelo do fluxo de análise é de 
crescimento incremental. Se o colocarmos em gráficos, a fase de análise 
possuirá uma grande saliência durante a fase de elaboração, e, então, 
decrescerá em sua massa, conforme as fases vão se desenvolvendo.
Figura 13 - O diagrama de análise é importante a partir da fase de elaboração no momento 
que os códigos começam a ser desenvolvidos
Fonte: Freepik.
Análise e Projeto de Software Orientado a Objetos
27
Em relação ao projeto, é no fluxo de projeto que o sistema começa 
a ser moldado conforme sua forma, essa forma é definida para atender as 
necessidades dos requisitos e da análise. O foco da fase de projeto é o 
final da fase de elaboração, quando todas as definições já foram descritas 
e o projeto pode começar a ser aplicado com foco no produto final. 
E, na implementação, é o fluxo pelo qual os componentes do 
projeto são desenvolvidos. Esse fluxo se limita a integrar o sistema em 
cada iteração, implementar os subsistemas, testar implementações e 
integrá-las. A maior evidência do fluxo de implementação está na parte 
de construção, que é quando o projeto é propriamente desenvolvido em 
código e prática, mantendo-se até a fase de transição para a correção de 
erros.
Figura 14 - Na implementação, é o momento que os componentes do software orientado a 
objetos são desenvolvidos
Fonte: Freepik.
Já o fluxo de teste é um dos mais importantes do sistema. É 
nesta fase que verificamos se todas as exigências e necessidades estão 
sendo atendidas. Nela, são realizadas ações em todos os componentes 
Análise e Projeto de Software Orientado a Objetos
28
executáveis do sistema, com o intuito de garantir que estejam realizando 
suas funções de maneira correta. Esse fluxo consiste em uma sequência 
lógica de testes com o objetivo de analisar todos os resultados, verificando 
todos os componentes do sistema. Aqui, são identificados erros de 
concepção e implementação. 
Figura 15 - No fluxo de teste, é verificado se todas as exigências e necessidades estão 
sendo atendidas
Fonte: Freepik.
Os testes de sistema começam na fase de elaboração, quando a 
arquitetura já está definida e os resultados finais já podem ser logicamente 
enxergados. É um fluxo que se estende até o final da fase de construção, 
mantendo-se na fase de transição para corrigirpossíveis erros.
Análise e Projeto de Software Orientado a Objetos
29
RESUMINDO:
E então? Gostou do que lhe mostramos? Aprendeu 
mesmo tudinho? Agora, só para termos certeza de 
que você realmente entendeu o tema de estudo deste 
capítulo, vamos resumir tudo o que vimos. Você deve ter 
aprendido que um processo unificado de desenvolvimento 
de sistemas tem como objetivo garantir que o sistema 
possa ser desenvolvido. Mas de forma enxuta e sucinta, 
assegurando a eficácia de cada uma das fases, desde a 
definição e análise dos requisitos, até o teste do sistema 
como um todo. Também é importante compreender o 
conceito de processo, que se trata de um conjunto de 
ações continuadas, divididas em passos que definem algo 
a ser feito, quando será feito e como será feito. Sob a ótica 
da Engenharia de Software, um processo é uma tentativa 
incessante de entregar o produto final de um projeto, 
capaz de atender as necessidades de um cliente ou de um 
negócio. Mas, ao falarmos em algo unificado, vem a nossa 
mente o conceito de unitariedade, o que não é errado se 
pensar. Então, um processo unificado nada mais é do que 
um conjunto de atividades necessárias para unir todos os 
processos relacionados a um projeto, em prol da entrega 
de um produto final, que no caso de nosso estudo um 
software orientado a objetos..
Análise e Projeto de Software Orientado a Objetos
30
Concepção do Processo Unificado 
OBJETIVO:
Ao término deste capítulo, você será capaz de compreender 
alguns procedimentos e características da fase de 
concepção de um processo unificado. Isto será fundamental 
para o exercício de sua profissão. E então? Motivado para 
desenvolver esta competência? Então vamos lá. Avante!.
A Fase de Concepção
Para o desenvolvimento de um projeto, como, por exemplo, 
de software orientado a objetos, o pensamento claro é a chave de 
determinação, é na fase de concepção em que é utilizada a lógica, a 
análise e o planejamento para delimitar o chamado “escopo do projeto”. 
É a partir do escopo que o projeto passa a ser desenvolvido, sendo 
determinado até onde ele irá cobrir e cumprir o que se pede. 
A maior concentração da fase de concepção está no fluxo de requisitos, 
pois a definição de todos os requisitos concebe o sistema como um todo. 
Além disso, é ao final desta fase que é avaliado se um processo deve ser 
seguido em plena escala. Antes de lançarmos um exemplo prático de tudo 
isto sobre o qual estamos falando, vamos relembrar o que representa cada 
fase do processo unificado de desenvolvimento de sistemas. 
 • A fase de requisitos: este é o fluxo mais importante da fase de 
concepção e, quando bem executado, torna-se o cerne de todo o 
projeto a ser desenvolvido, cabendo a esta fase o detalhamento de 
todos os requisitos.
 • A fase da análise: nesta fase, é criado um modelo de análise inicial, por 
meio dos detalhamentos realizados no fluxo de requisitos;
 • A fase do projeto: é o momento em que os primeiros esboços do 
projeto começam a tomar forma; 
 • A fase de implementação e de teste: nessas fases, são realizadas, 
respectivamente, a codificação e a identificação dos erros cometidos 
durante a execução dos módulos do sistema.
Análise e Projeto de Software Orientado a Objetos
31
Estudo de Caso
Vamos elaborar um exemplo prático de concepção, de um jogo 
chamado Pokémon, cujo objetivo é realizar batalhas entre criaturas que 
possuem características e habilidades diferentes (SOUZA, 2016). Vamos 
tomar este jogo como base para desenvolver nossa concepção, neste 
jogo, temos um ator externo chamado “Treinador”, que tem cinco funções: 
1. Ver Pokémon;
2. Capturar Pokémon;
3. Desafiar Treinadores;
4. Mudar de Local; 
5. Libertar Pokémon.
O diagrama de casos de uso de um treinador pode ser descrito da 
maneira expressa no diagrama ilustrado na figura a seguir. 
Figura 15 - Diagrama descrevendo as cinco funcionalidades do Pokémon
Ver Pokemons
Capturar 
Pokemon
Desafiar 
Treinador
Treinador
Mudar de 
Local
Libertar 
Pokemon
Fonte: Nogueira (2018c, p. 14).
Análise e Projeto de Software Orientado a Objetos
32
Além disso, o jogo tem um segundo ator, chamado Pokémon, que 
possui as ações: 
1. Atacar; 
2. Evoluir; 
3. Fugir.
Veja como pode ser exemplificado as ações do segundo ator 
segundo na figura a seguir.
Figura 16 - Ações possíveis ao Pokémon
Atacar
Fugir Evoluir
Pokemon
Fonte: Nogueira (2018c, p. 14).
O fluxo de requisitos é definido com base no diagrama de casos de 
uso, no caso, os diagramas ilustrados nas figuras anteriores, existirão duas 
superclasses que irão gerir o sistema: 
1. Pokémon; 
2. Treinador.
Há um diagrama de classes que generaliza os pokémons da 
seguinte maneira exemplificado na figura a seguir.
Análise e Projeto de Software Orientado a Objetos
33
Figura 17 - Generalização da superclasse Pokémon
Pokemon
Água Fogo Planta
Squirtle Chamander Bulbasaur
Fonte: Nogueira (2018c, p. 15).
De maneira análoga, há um diagrama de classes que generaliza os 
treinadores, como pode ser observado na ilustração a seguir.
Figura 18 - Generalização da superclasse Treinador
Treinador
Jogador Aleatório Ginásio
Fonte: Nogueira (2018c, p. 15).
Analisando as informações compiladas até este ponto, podemos 
concluir que serão necessárias 7 classes para tratarmos pokémons e 4 
classes para tratarmos treinadores. Claro que o sistema está totalmente 
simplificado, pois, para sua implementação, seriam necessárias as regras 
e definições de atributos e métodos. Em uma análise preliminar, as 
informações nos dizem que um pokémon possui uma série de atributos, 
tais como:
Análise e Projeto de Software Orientado a Objetos
34
 • Vida; 
 • Nível; 
 • Ataque; 
 • Defesa; 
 • Ataque Especial; 
 • Defesa Especial; 
 • Nome; 
 • Tipo; 
 • Evolução (SOUZA, 2016). 
Cada subclasse de Pokémon traz características exclusivas dos 
tipos definidos, como: 
 • Fraquezas; 
 • Vantagens; 
 • Habilidades especiais (SOUZA, 2016). 
Cada Subclasse dos tipos é referida como espécie e traz consigo 
uma lista de características que diferenciam as espécies, como habilidades 
específicas, um treinador é separado em três distinções: 
1. Jogador, quando é o perfil do usuário; 
2. Ginásio, quando é um membro ou líder do ginásio; 
3. Aleatório, quando não faz parte de nenhuma agregação.
Avaliando um diagrama de classes mais detalhado, podemos 
observar a formação descrita na ilustração apresentada na figura a seguir.
Análise e Projeto de Software Orientado a Objetos
35
Figura 19 - Diagrama de classes do Pokémon
Água
Fraqueza: String (planta)
Vantagem: String (fogo)
Tipo: String (Água)
Pokemon
Nome: String
Tipo: String
Evolução: String
Vida: Inteiro
Nível: Inteiro
Ataque: Inteiro
Defesa: Inteiro
SAtaque: Inteiro
SDefesa: Inteiro
Vantagem: String
Fraqueza: String
Fogo
Fraqueza: String (água)
Vantagem: String (planta)
Tipo: String (fogo)
Planta
Fraqueza: String (fogo)
Vantagem: String (água)
Tipo: String (planta)
Fonte: Nogueira, 2018c, p. 17.
Perceba, na ilustração da figura anterior, que as subclasses 
elementares herdam todas as características da classe Pokémon, as 
classes elementares utilizam a característica de polimorfismo para 
modificar valores padrões definidos na superclasse. Já no caso da classe 
Treinadores, teremos o diagrama ilustrado na próxima figura.
Figura 20 - Diagrama de classes do Pokémon
Jogador
Insignias: Inteiro
Treinador
Nome: String
Pokemon: Pokemon
Local: String
Pokemons: Inteiro
Aleatório
Derrotado: boolean
Ginásio
Tipo: String
Líder: boolean
Fonte: Nogueira (2018c, p. 17).
Análise e Projeto de Software Orientado a Objetos
36
Definidas de classes do sistema, poderemos, então, começar a 
detalhar o projeto como um todo.
Desenvolvendo o Esboço do Projeto
Um exemplo de como pode ser desenvolvido o projeto de batalhas 
do jogo Pokémon, poderá será escrito em linguagem PHP, com suporte ao 
banco de dados MySQL, executados por meio de uma rotina de suporte 
APACHE.A escolha da rotina APACHE se dá pelo motivo de que o projeto 
será desenvolvido em uma plataforma web, que é conhecida por dar um 
retorno instantâneo em termos de resultados, o que é extremamente 
válido para quem está apenas aprendendo. 
A linguagem PHP foi a escolhida por ser de fácil compreensão, além 
de conseguir se ligar facilmente ao HTML, podendo criar um pequeno 
sistema compatível com o navegador, tornando-o rápido e enxuto. 
Também há o suporte de gerar um website futuro para dar continuidade 
ao projeto, até o seu término. Em que pese o fato de a linguagem PHP 
não ser propriamente orientada a objetos, ela pode ser utilizada nesta 
modalidade de programação, portanto, atende o requisito mínimo de 
implementação com base em uma modelagem UML, aplicada a um 
modelo de processo unificado de desenvolvimento de software.
É importante salientar que o nosso foco aqui não é o ensino da 
linguagem de programação PHP, que estará sendo utilizada apenas para 
dar suporte e não como protagonista do nosso processo de aprendizagem. 
Os fragmentos de código que serão inseridos para demonstrar os artefatos 
e componentes do sistema serão explicados em termos de lógica, e não 
de sintaxe.
O nosso sistema irá consistir em uma plataforma de batalhas, 
dotada de treinadores e seus pokémons. O usuário, como treinador, irá 
possuir um pokémon e poderá desafiar outros treinadores, desenvolvidos 
com uma pequena inteligência artificial e controlados unicamente pelo 
computador. Os treinadores podem fazer parte de um ginásio ou serem 
treinadores locais, cada treinador pode possuir até seis pokémons, no 
máximo, cada pokémon possui duas habilidades, sendo uma física e 
outra especial. Caso haja um desafio de ginásio, e ele seja bem-sucedido, 
Análise e Projeto de Software Orientado a Objetos
37
uma insígnia (distintivo qualquer, como uma medalha, por exemplo) será 
gerada. O pokémon é capaz de subir de nível e, atingindo um certo nível, 
passará por um processo de evolução.
O ginásio possui um líder, este status de liderança é o desafio final 
para destravar a insígnia. As batalhas levam em consideração as vantagens 
e fraquezas, além de considerar os atributos de ataque, defesa, ataque 
especial e defesa especial. O nível impulsiona ou reduz os possíveis 
danos, por meio de cálculos a serem descritos mais adiante. O treinador 
do jogador pode transitar entre locações, definidas como cidades, cada 
cidade terá seus pokémons exclusivos, treinadores diferentes e ginásios. 
O jogo se encerra quando o jogador conseguir a oitava insígnia.
Depois de concluir a fase de concepção, podemos começar a nos 
concentrar em outras etapas, inicialmente, temos que avaliar quais serão 
as peculiaridades sobre as quais manteremos nosso foco na Fase de 
Elaboração. 
Análise e Projeto de Software Orientado a Objetos
38
RESUMINDO:
E então? Gostou do que lhe mostramos? Aprendeu 
mesmo tudinho? Agora, só para termos certeza de 
que você realmente entendeu o tema de estudo deste 
capítulo, vamos resumir tudo o que vimos. Você deve ter 
aprendido que os fluxos de trabalho definem todas as 
possíveis atividades e onde cada uma terá maior influência, 
todo o processo geralmente é dividido em quatro fases, 
compondo os ciclos de vida do projeto. Ao final de cada 
fase há um ponto de verificação que checa se todos os 
artefatos necessários foram desenvolvidos e aplicados, 
realizando então o avanço, ou não, para a próxima fase. É 
importante destacar que a Fase de concepção é totalmente 
focada em conceitos e teorias, lembrando de que ela não 
é definitiva, ou seja, a qualquer momento, velhos conceitos 
poderão ser redefinidos para que possam ser realmente 
aplicados no corpo do projeto. Seja quaisquer projetos de 
análise e projeto de software orientados a objetos, como 
por exemplo, o apresentado neste tópico especificamente 
de um jogo, o pókemon, que também é considerado com 
um software.
Análise e Projeto de Software Orientado a Objetos
39
Elaboração do Processo Unificado
OBJETIVO:
Ao término deste capítulo, você será capaz de 
compreender alguns procedimentos e características da 
fase de elaboração de um processo unificado. Isto será 
fundamental para o exercício de sua profissão. E então? 
Motivado para desenvolver esta competência? Então 
vamos lá. Avante!
A Fase de Elaboração
É na fase de elaboração que os requisitos ainda não definidos na 
concepção são incorporados ao plano, é a etapa no qual tudo irá se iniciar. 
Nesta fase, ignoraremos os detalhes do sistema e enxergamos as fronteiras 
mais distantes que ele irá atingir, evitando que coisas desnecessárias 
sejam imaginadas. O real foco desta fase é a de criar uma base firme, 
sobre a qual o sistema começará a ser implementado e ganhará força 
para se tornar o que deve ser. 
Ao completarmos a fase de elaboração, o sistema já apresentará 
uma arquitetura-base bem estabelecida seu escopo estará bem definido 
e seus detalhamentos começarão a ser implementados. Os riscos 
deverão ser avaliados com cautela e, para cada um, uma solução deverá 
ser planejada, com o intuito de que eles não atrapalhem o andamento do 
projeto. Assim como a concepção, a elaboração também é dividida em 
seus 5 fluxos, sendo eles:
1. Requisitos; 
2. Análise; 
3. Projeto; 
4. Implementação; 
5. Testes (BRAZ, 2006).
Análise e Projeto de Software Orientado a Objetos
40
O fluxo de requisitos, na fase de análise, é um dos principais objetivos 
a ser alcançado, os requisitos pré-estabelecidos na fase de concepção 
são analisados novamente para a checagem de faltas e complementos, 
para então serem reaplicados ao projeto. Todos os casos de uso adicionais 
devem ser analisados e estruturados de forma a apresentar um plano de 
como devem ser implementados. Os casos de uso adicionais vão formar 
a maior parte do sistema, já que englobam comunicações com o banco 
de dados, comunicações com hardware, processos de comunicação do 
sistema com o usuário, entre outros.
Figura 21 - Os requisitos pré-estabelecidos na fase de concepção são analisados 
novamente
Fonte: Freepik.
Nem todos os casos de uso do sistema vão ser detalhados nesta fase, 
salvo se o projeto for declarado como “Projeto de Escopo Fechado”, neste 
caso, outro conceito vem à tona: “Escopo Aberto”. Os projetos de escopo 
aberto são os mais utilizados, pois estão em constante desenvolvimento, 
e cada modificação de escopo impacta no valor final do sistema. 
Análise e Projeto de Software Orientado a Objetos
41
Já no caso dos projetos de escopo fechado, o escopo já está 
inteiramente definido. Geralmente, quando tratamos deste tipo de projeto, 
especificamos todo o sistema de forma a deixar claro o que realmente 
será desenvolvido, e como será desenvolvido. Qualquer modificação é 
considerada um aditivo ao projeto. Quanto menos casos de uso forem 
detalhados na fase de concepção, maiores serão os riscos, quanto mais 
casos de uso forem detalhados, menores serão esses riscos, porém, o 
impacto no custo do projeto será enorme.
IMPORTANTE:
Conforme os casos de uso forem sendo detalhados, 
possíveis redundâncias e processos desnecessários 
provavelmente começarão a ser cortados, tornando a 
experiência de desenvolvimento mais dinâmica.
Chegado o fluxo de análise, o foco será voltado para os casos 
de uso mais relevantes para o sistema, esses casos de uso são os mais 
movimentados, tendo suas classes e objetos como protagonistas de todo 
o desenvolvimento.
Figura 22 - Na análise, o foco é voltado para os casos de uso mais relevantes para o sistema
Fonte: Freepik.
Análise e Projeto de Software Orientado a Objetos
42
No projeto, é chegada a hora de começar o desenvolvimento dos 
casos de uso analisados, é na fase de projeto da elaboração que as 
classes, subclasses, objetos e subsistemas começam a ser envolvidos 
diretamente. Vale salientar que, até este momento, nada foi realizado 
na parte estrutural do código do projeto, apenas estudose análises 
conceituais são aplicadas até esta fase.
Figura 23 - Na fase de projeto da elaboração, as classes, subclasses, objetos e subsistemas 
começam a ser envolvidos diretamente
Fonte: Freepik.
É no fluxo de projeto da elaboração que o arquiteto do sistema deve 
começar a segregar as classes em pacotes de trabalho, que, mais adiante, 
desempenharão seu papel no desenvolvimento do projeto. É bem lógico 
adivinhar que um projeto possui classes não relevantes, o que realmente 
ocorre. Porém, o agrupamento dessas classes é extremamente relevante, 
daí a necessidade de se criar pacotes de trabalho com agregações dessas 
classes. 
Análise e Projeto de Software Orientado a Objetos
43
Na implementação ou fase de elaboração, finalmente, os dados 
começam a ser codificados e inseridos. Nesta fase, a elaboração irá cuidar 
de desenvolver todas as classes mais significantes e tratar de aplicar suas 
funcionalidades. Já no fluxo de testes, as classes criadas são testadas de 
maneira minimalista e detalhada, tornando sua usabilidade extremamente 
confiável e preparando o sistema para a próxima fase.
Detalhamento da Fase
A Fase de elaboração engloba o planejamento e modelagem do 
sistema. A elaboração é a fase que refina e expande os casos de uso, 
além de cria uma representação arquitetural do projeto, seus principais 
objetivos são: 
 • A criação da Linha de Base da arquitetura;
 • A determinação e combate dos riscos em potencial;
 • A definição dos componentes do sistema; 
 • A diagramação e descrição das partes reutilizáveis (FOWLER, 
2007).
Esta fase gera diversos artefatos que são utilizados pelas fases 
seguintes, dentre os principais estão: 
 • Os protótipos do sistema; 
 • Os arquivos base, que servirão como modelos de teste e modelos 
de aprimoramento; 
 • Os modelos de design, tanto de interfaces, para começar a definir 
qual o visual que será apresentado para o usuário final, quanto o 
de código, definindo regras de diagramação de sintaxe;
 • Os modelos de dados, determinando as estruturas das classes, 
seus atributos e métodos, já inicializando as capacidades de cada 
classe, deixando o caminho bem delimitado para a aplicação dos 
casos de uso; 
 • Um modelo de implantação, que é definido como um mapa de 
como o projeto deve ser implantado.
Análise e Projeto de Software Orientado a Objetos
44
A Fase de concepção irá retornar diversos resultados que serão 
utilizados pela fase de elaboração para dar prosseguimento ao processo, 
como por exemplo, uma lista inicial de requisitos, atores, objetivos e 
casos de uso importantes. Além disto, é de se esperar uma descrição 
resumida dos demais casos de uso, para aprimoramento, os requisitos 
mais influentes e os que podem causar maior risco. 
A fase de concepção também irá criar uma primeira versão da 
visão e especificação suplementar, ou seja, se o cliente realizar um 
questionamento sobre os resultados do processo, os responsáveis 
podem defender suas marcas. Caso o projeto seja extremamente extenso, 
é também a fase de concepção que irá enviar os dados de protótipos 
para a fase de elaboração aprimorá-los, além de enviar uma lista de 
recomendações do que comprar, construir ou reutilizar. Já a fase de 
elaboração tem como objetivos principais:
 • Descobrir e listar a maioria dos requisitos; 
 • Eliminar os riscos; 
 • Implementar os elementos centrais. 
Isto não significa que tudo ficará pronto ao final desta fase, pelo 
contrário, aqui é dado apenas um pontapé inicial para a construção das 
fases seguintes. A fase de elaboração irá selecionar um dos casos de uso 
enviados pela fase de concepção, para utilizá-lo como inicial.
IMPORTANTE:
Sempre é escolhido um caso de uso simples, sem muitos 
riscos, mas em situações emergenciais, pode-se optar 
pelos mais complexos.
Todos os protótipos criados na fase de concepção são descartáveis, 
pois são apenas modelos a serem desmistificados e aplicados, porém, 
na fase elaboração, todos os protótipos já fazem parte do sistema, ou 
seja, eles já são pequenos subconjuntos do sistema final. Para manter 
tudo funcionando como dever ser, inicialmente, os módulos do sistema 
Análise e Projeto de Software Orientado a Objetos
45
são identificados, dividindo-os em processos, camadas, pacotes, 
subsistemas e outros tipos de segregação. Para cada módulo é definida a 
responsabilidade e quais serão as interfaces utilizadas, por fim, devemos 
definir como os módulos irão se conectar entre si.
Para um melhor aproveitamento da fase de elaboração, é necessária 
a criação de iterações curtas e com prazos bem estabelecidos. Vale notar 
que, algumas vezes, a melhor maneira de garantir qualidade é definir 
e cumprir um prazo, mesmo que isso signifique diminuir o número de 
iterações. A chave do sucesso é o início da programação, quanto mais cedo 
for iniciada a programação, mais cedo se iniciam os testes. Quanto mais 
cedo se iniciam os testes, mais cedo se encontram erros, quanto mais cedo 
se encontram erros, menores são os riscos de o processo falhar. 
Mas é importante que todas as fases sejam executadas no momento 
correto, a ideia não é de adiantar sem cumprir os requisitos necessário 
de cada etapa. Uma forma de garantir que não haja retrabalho é, ao final 
de cada fase, sempre elaborar um cronograma de projeto que permita o 
sistema ser construído de maneira adaptativa. Ou seja, que ele já esteja 
preparado para receber diversos tipos de mudança e sempre adaptar 
todas as modificações de acordo com o feedback de testes.
Sobre as iterações, de cada fase, trata-se de pequenos módulos 
que irão se realizar conforme a fase avança, durante a fase de elaboração, 
definir bem as iterações pode garantir um excelente resultado. Para uma 
boa definição, deve-se levar em conta os riscos de complexidade técnica, 
a inexperiência de quem irá lidar com elas, a criticidade e a garantia 
de que as iterações irão cobrir todas as partes do sistema. Também é 
importante conhecer o modelo de domínio, como pode ser observado 
na ilustração da figura a seguir, o modelo de domínio é um modelo 
conceitual que mostra todas as classes do sistema e quem domina quem. 
É um retrabalho do diagrama de classes da UML.
Análise e Projeto de Software Orientado a Objetos
46
Figura 24 - Exemplo de modelo de domínio
Batalha Naval
Tabuleiro
Nome
Jogado em
Casa
Coordenada
Jogador
Nome
Bomba
Coordenada
Embarcação
Tipo
- Possui 
- Lança 
- Joga 
- Ataca 
- Ocupa 
- Contém 
1
1
1 1
1
1
11
1 2
2
1.8
81
1.5
Fonte: Nogueira (2018d, p. 18).
Na análise e projeto de software orientado a objetos, é importante 
o conhecimento do modelo de projeto e documento de arquitetura do 
software. Trata-se da documentação que compreende o conjunto de 
diagramas que descreve todo o projeto, bem como os dados do projeto 
como um todo, descrições de objetivos, riscos e linha de base. Também é 
o documento que ilustra todos os problemas da arquitetura e as possíveis 
soluções que serão adotadas neste projeto em si, com a justificativa da 
solução adotada, este é o documento no qual o projeto irá passar a se 
basear. Além do storyboard de casos de uso, no qual é uma adaptação do 
diagrama de sequência, que irá indicar toda a descrição da interface com 
o usuário e as trajetórias da navegação.
De maneira geral, com base em diagramas UML - Modeling 
Language, ou a Linguagem Unificada de Modelação, é possível iniciar a 
análise da fase de concepção de projetos, na qual os softwares orientando 
a objetos podem ser aplicados.
Análise e Projeto de Software Orientado a Objetos
47
RESUMINDO:
E então? Gostou do que lhe mostramos? Aprendeu mesmo 
tudinho? Agora, só para termos certeza de que você 
realmente entendeu o tema de estudo deste capítulo, vamos 
resumir tudo o que vimos. Você deve ter aprendido que é 
necessário que os diagramas UML - Modeling Language, 
ou a Linguagem Unificada de Modelação para começar a 
etapa de análisee da fase de concepção de projetos. Nos 
quais as classes principais devem ser definidas e listadas na 
fase de concepção, e que os principais casos de uso que 
iriam ser aplicados ao projeto também devem ser listados. 
Assim é possível iniciar a fase de elaboração. A fase em 
que as primeiras partes do projeto passam a tomar forma 
e permitindo assim começar a enxergar um produto final. 
De maneira geral a fase de elaboração é extremamente 
delicada dentro do contexto de um processo unificado, 
nela, toda a linha de base do projeto é firmada. Caso não 
seja desenvolvida de maneira sólida, o projeto corre sérios 
riscos de falhar, desta maneira é importante a atenção 
de todos esses aspectos na análise e projeto de software 
orientados a objetos.
Análise e Projeto de Software Orientado a Objetos
48
REFERÊNCIAS
BRAZ, C. C. Introdução ao Processo Unificado. Devmedia, 2006. 
Disponível em https://www.devmedia.com.br/introducao-ao-processo-
unificado/3931. Acesso em: 03 Dez 2021. 
FOWLER, M. UML Essencial: Um Breve Guia para Linguagem 
Padrao. São Paulo: Bookman, 2007.
MICROSOFT. Criar projetos e diagramas de modelagem UML. 
Microsoft Developer Network, 2018. Disponível em: https://msdn.
microsoft.com/pt-br/library/dd409445.aspx.
NOGUEIRA, J. Análise e Projeto de Software Orientado a Objetos. 
Diagramas da UML. São Paulo: Uninassau, 2018a.
NOGUEIRA, J. Análise e Projeto de Software Orientado a Objetos: 
Conceitos e definições sobre OO. São Paulo: Uninassau, 2018b.
NOGUEIRA, J. Análise e Projeto de Software Orientado a Objetos: 
Características da OO. São Paulo: Uninassau, 2018c.
NOGUEIRA, J. Análise e Projeto de Software Orientado a Objetos: 
UML – Conceito e Aplicações. São Paulo: Uninassau, 2018d.
 SOUZA, S. Pokemon Go como introdução à Programação 
Orientada a Objeto. Medium, 2016. Disponível em: https://medium.
com/@samuelsouza/pokemon-go-como-introdução-à-programação-
orientada-a-objeto-803e7abf1ed1 Acesso em 27 de Jun de 2018.
Análise e Projeto de Software Orientado a Objetos
	Diagramas da UML
	O que é um Diagrama?
	Processo Unificado de Desenvolvimento de Software
	Conceituação
	Ciclo de Vida
	Concepção do Processo Unificado 
	A Fase de Concepção
	Estudo de Caso
	Desenvolvendo o Esboço do Projeto
	Elaboração do Processo Unificado
	A Fase de Elaboração
	Detalhamento da Fase