Buscar

Apostila-UML

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 81 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 6, do total de 81 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 9, do total de 81 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Prévia do material em texto

1 
 
 
 
Análise Orientada a 
Objetos 
 
 
Goianésia – 2011 
 
 
 
 
2 
 
 
 
Sumário 
Introdução ................................................................................................................................................... 5 
Análise e Especificação de Requisitos .......................................................................................................... 5 
Processo de desenvolvimento de software .................................................................................................... 6 
Visões de um Sistema .................................................................................................................................. 8 
Levantamento de Requisitos .................................................................................................... 10 
Estudo de Viabilidade ............................................................................................................... 12 
Processo de Extração de Requisitos .......................................................................................... 13 
Técnicas para extração de requisitos ........................................................................................ 14 
Especificação e documentação ................................................................................................. 17 
Validação .................................................................................................................................................. 22 
UML – Linguagem de Modelagem Unificada ............................................................................................ 23 
Um processo para utilizar a UML ............................................................................................................... 25 
O Futuro da UML ....................................................................................................................................... 26 
Abstração ................................................................................................................................. 26 
Classes ..................................................................................................................................... 27 
Objetos .................................................................................................................................... 27 
Instanciação ............................................................................................................................. 28 
Encapsulamento ...................................................................................................................... 28 
Métodos .................................................................................................................................. 29 
Herança ................................................................................................................................... 30 
Herança Múltipla ..................................................................................................................... 30 
Polimorfismo ........................................................................................................................... 30 
Diagramas da UML ................................................................................................................................... 31 
Diagrama de Casos de Uso ....................................................................................................... 32 
Atores .......................................................................................................................................... 33 
Casos de Uso ................................................................................................................................ 34 
Associação (Interação) ................................................................................................................. 34 
Relacionamento entre Atores ...................................................................................................... 34 
Relacionamento entre Atores e casos de uso ............................................................................... 35 
Relacionamento entre casos de uso e outros casos de uso ........................................................... 35 
Documentação de Casos de Uso ............................................................................................... 38 
 
 
 
3 
 
Diagrama de Classes .................................................................................................................................. 39 
Responsabilidade ..................................................................................................................... 40 
Componentes........................................................................................................................... 40 
Atributos...................................................................................................................................... 40 
Operações (Métodos) .................................................................................................................. 40 
Visibilidade .................................................................................................................................. 42 
Relacionamentos ..................................................................................................................... 42 
Classe Associativa .................................................................................................................... 47 
Diagrama de Objetos ................................................................................................................................. 48 
Diagrama de Máquina de Estados .............................................................................................................. 48 
Estado ...................................................................................................................................... 49 
Transições ................................................................................................................................ 49 
Estados Inicial e Final ............................................................................................................... 50 
Atividades internas .................................................................................................................. 50 
Transições internas .................................................................................................................. 51 
Auto-Transições ....................................................................................................................... 51 
Pseudo-Estado de Escolha ........................................................................................................ 51 
Barra de Sincronização ............................................................................................................. 52 
Pseudo-Estado de Junção ......................................................................................................... 53 
Estado Composto ..................................................................................................................... 53 
Estado de História .................................................................................................................... 54 
Estado de Submáquina ............................................................................................................. 54 
Estados de Entrada e Saída (Entry e Exit States) ....................................................................... 55 
Pseudo-Estado de Término ...................................................................................................... 55 
Estado de Sincronismo .............................................................................................................55 
Diagrama de Sequência ............................................................................................................................. 56 
Atores ...................................................................................................................................... 57 
Objetos .................................................................................................................................... 57 
Linha de Vida ........................................................................................................................... 58 
Foco de Controle ou Ativação ................................................................................................... 58 
Mensagens ou Estímulos .......................................................................................................... 59 
Mensagens de retorno ............................................................................................................. 61 
Auto-chamadas ou Auto-delegações ........................................................................................ 62 
Fragmentos de Interação e Ocorrências de Interação ............................................................... 62 
 
 
 
4 
 
Portões (Gates) ............................................................................................................................ 64 
Fragmentos Combinados e Operadores de Interação ................................................................... 64 
Diagrama de Comunicação ........................................................................................................................ 68 
Diagrama de Atividade .............................................................................................................................. 69 
Nó de Ação .............................................................................................................................. 70 
Controle de Fluxo ..................................................................................................................... 70 
Nó Inicial .................................................................................................................................. 71 
Nó Final.................................................................................................................................... 71 
Nó de Decisão .......................................................................................................................... 71 
Conectores ............................................................................................................................... 71 
Subatividade ............................................................................................................................ 72 
Nó de Bifurcação/União ........................................................................................................... 73 
Fluxo de Objetos ...................................................................................................................... 74 
Nó de Objeto ........................................................................................................................... 74 
Alfinetes (Pins) ......................................................................................................................... 74 
Exceções .................................................................................................................................. 75 
Ação de Objeto de Envio .......................................................................................................... 75 
Ação de Evento de Aceitação ................................................................................................... 75 
Ação de Evento de Tempo de Aceitação ................................................................................... 76 
Nó de Repositório de Dados (Data Store Node) ........................................................................ 76 
Partição de Atividade ............................................................................................................... 77 
Região de Atividade Interrompível ........................................................................................... 77 
Região de Expansão ................................................................................................................. 78 
Diagrama de Componente ......................................................................................................................... 78 
Diagrama de Execução ............................................................................................................................... 80 
Diagrama de Estrutura Composta .............................................................................................................. 80 
 
 
 
 
 
5 
 
Introdução 
 
 O desenvolvimento de software é uma atividade de crescente importância na 
sociedade contemporânea. A utilização de computadores nas mais diversas áreas do 
conhecimento humano tem gerado uma crescente demanda por soluções 
computadorizadas. 
 É importante observar que, associada ao acréscimo da demanda, a evolução do 
hardware tem sido mais acentuada, disponibilizando aos usuários máquinas cada vez mais 
velozes e com maior capacidade de processamento. 
 Neste contexto, identificou-se, já na década de 70, uma situação crítica no 
desenvolvimento de software, a chamada Crise do Software, caracterizada pelos seguintes 
fatos: 
 demanda muito superior à capacidade de desenvolvimento; 
 qualidade insuficiente dos produtos; e 
 estimativas de custo e tempo raramente cumpridas nos projetos. 
 Visando melhorar a qualidade dos produtos de software e aumentar a produtividade 
no processo de desenvolvimento, surgiu a área de pesquisa denominada Engenharia de 
Software. A Engenharia de Software busca organizar esforços no desenvolvimento de 
ferramentas, metodologias e ambientes de suporte ao desenvolvimento de software. 
 Dentre as principais atividades de um processo de desenvolvimento de software, 
destaca-se a atividade de análise e especificação de requisitos, na qual os requisitos de um 
sistema são levantados e modelados, para só então ser projetada e implementada uma 
solução. 
 Esta atividade é o objeto de estudo desta disciplina. 
Análise e Especificação de Requisitos 
 
 Um completo entendimento dos requisitos do software é essencial para o sucesso de 
um esforço de desenvolvimento de software. A atividade de análise e especificação de 
requisitos é um processo de descoberta, refinamento, modelagem e especificação. O 
escopo do software definido no planejamento do projeto é refinado em detalhe, as funções 
e o desempenho do software são especificados, as interfaces com outros sistemas são 
indicadas e restrições que o software deve atender são estabelecidas. Modelos dos dados 
 
 
 
6 
 
requeridos, do controle e do comportamento operacional são construídos. Finalmente, 
critérios para a avaliação da qualidade em atividades subseqüentes são estabelecidos. 
 Os principais profissionais envolvidos nesta atividade são o analista e o 
cliente/usuário. 
 Na atividade de especificação, os requisitos são capturados sob uma perspectiva dos 
usuários, isto é, os modelos gerados procuram definir as funcionalidades (requisitos 
funcionais) e restrições (requisitos não funcionais) que devem ser consideradas para 
atender às necessidades dos usuários. Já na atividade de análise são modeladas as 
estruturas internas de um sistema capazes de satisfazer os requisitos identificados. 
 A etapa de especificação de requisitos é independente de paradigma, uma vez que 
trata os requisitos do sistema sob uma perspectiva externa. Nesta parte, são discutidas 
técnicas para levantamento de requisitos e a técnica de modelagem de casos de uso, para 
modelagem dos requisitos funcionais de um sistema. Entretanto,a atividade de análise, que 
modela as estruturas internas de um sistema, é completamente dependente do paradigma 
adotado no desenvolvimento, como a Análise Orientada a Objetos, que apresenta os 
principais conceitos da orientação a objetos e a linguagem de modelagem unificada (UML) 
e explora a modelagem de análise segundo o paradigma de objetos; e a Análise Essencial 
de sistemas que apresenta os principais conceitos da análise essencial e discute a 
modelagem de análise segundo o método da análise essencial, que adota o paradigma 
estruturado. 
Processo de desenvolvimento de software 
 
 Um Processo de desenvolvimento de software é um conjunto de atividades, 
parcialmente ordenadas, com a finalidade de obter um produto de software. É estudado 
dentro da área de Engenharia de Software, sendo considerado um dos principais 
mecanismos para se obter software de qualidade e cumprir corretamente os contratos de 
desenvolvimento, sendo uma das respostas técnicas adequadas para resolver a t do 
software. 
 Passos/Atividades do Processo: 
 Análise de requisitos de software: A extração dos requisitos de um desejado 
produto de software é a primeira tarefa na sua criação. Embora o cliente, 
provavelmente, acredite saber o que o software deva fazer, esta tarefa requer 
 
 
 
7 
 
habilidade e experiência em engenharia de software para reconhecer a 
incompletude, ambigüidade ou contradição nos requisitos. 
 Especificação: A especificação é a tarefa de descrever precisamente o software que 
será escrito, preferencialmente de uma forma matematicamente rigorosa. Na 
prática, somente especificações mais bem sucedidas foram escritas para aplicações 
bem compreendidas e afinadas que já estavam bem desenvolvidas, embora sistemas 
de software de missão crítica sejam freqüentemente bem especificados antes do 
desenvolvimento da aplicação. Especificações são mais importantes para interfaces 
externas que devem permanecer estáveis. 
 Arquitetura de Software: A arquitetura de um sistema de software remete a uma 
representação abstrata daquele sistema. Arquitetura é concernente à garantia de que 
o sistema de software irá ao encontro de requisitos do produto, como também 
assegurar que futuros requisitos possam ser atendidos. A etapa da arquitetura 
também direciona as interfaces entre os sistemas de software e outros produtos de 
software, como também com o hardware básico ou com o sistema operacional. 
 Implementação (ou codificação): A transformação de um projeto para um código 
dever ser a parte mais evidente do trabalho da engenharia de software, mas não 
necessariamente a sua maior porção. 
 Teste: Teste de partes do software, especialmente onde tenha sido codificado por 
dois ou mais engenheiros trabalhando juntos, é um papel da engenharia de 
software. 
 Documentação: Uma importante tarefa é a documentação do projeto interno do 
software para propósitos de futuras manutenções e aprimoramentos. As 
documentações mais importantes são das interfaces externas. 
 Suporte e Treinamento de Software: Uma grande porcentagem dos projetos de 
software falha pelo fato de o desenvolvedor não perceber que não importa quanto 
tempo a equipe de planejamento e desenvolvimento irá gastar na criação do 
software se ninguém da organização irá usá-lo. As pessoas ocasionalmente resistem 
à mudança e evitam aventurar-se em áreas pouco familiares. Então, como parte da 
fase de desenvolvimento, é muito importante o treinamento para os usuários de 
software mais entusiasmados, alternando o treinamento entre usuários neutros e 
usuários favoráveis ao software. Usuários irão ter muitas questões e problemas de 
software os quais conduzirão para a próxima fase. 
 
 
 
8 
 
 Manutenção: A manutenção e melhoria de software lidam com a descoberta de 
novos problemas e requerimentos. Ela pode tomar mais tempo que o gasto no 
desenvolvimento inicial do mesmo. Não somente pode ser necessário adicionar 
códigos que combinem com o projeto original, mas determinar como o software 
trabalhará em algum ponto depois da manutenção estar completa, pode requerer um 
significativo esforço por parte de um engenheiro de software. Cerca de ⅔ de todos 
os engenheiros de software trabalham com a manutenção. Uma pequena parte 
destes trabalha na correção de erros. A maioria das manutenções é para ampliar os 
sistemas para novas funcionalidades, as quais, de diversas formas, podem ser 
consideradas um novo trabalho. Analogamente, cerca de ⅔ de todos os engenheiros 
civis, arquitetos e construtores trabalham com manutenção de uma forma similar. 
Visões de um Sistema 
 
 O desenvolvimento de um sistema complexo não é uma tarefa fácil. O ideal seria 
que o sistema inteiro pudesse ser descrito em um único gráfico e que este representasse por 
completo as reais intenções do sistema sem ambiguidades, sendo facilmente interpretável. 
Infelizmente, isso é impossível. Um único gráfico é incapaz de capturar todas as 
informações necessárias para descrever um sistema. 
 Um sistema é composto por diversos aspectos: funcional (que é sua estrutura 
estática e suas interações dinâmicas), não funcional (requisitos de tempo, confiabilidade, 
desenvolvimento, etc.) e aspectos organizacionais (organização do trabalho, mapeamento 
dos módulos de código, etc.). Então o sistema é descrito em um certo número de visões, 
cada uma representando uma projeção da descrição completa e mostrando aspectos 
particulares do sistema. 
 Cada visão é descrita por um número de diagramas que contém informações que 
dão ênfase aos aspectos particulares do sistema. Existe em alguns casos uma sobreposição 
entre os diagramas o que significa que cada um pode fazer parte de mais do que uma visão. 
Os diagramas que compõem as visões contêm os modelos de elementos do sistema. As 
visões que compõem um sistema são: 
 
 
 
 
Visão de Componentes Visão Lógica 
Visão de Use-case 
 
 
 
9 
 
 
 
 
 Visão "Use-case" (caso de uso): Descreve a funcionalidade do sistema 
desempenhada pelos atores externos do sistema (utilizadores). A visão use-case é 
central, já que seu conteúdo é base do desenvolvimento das outras visões do 
sistema. Essa visão é montada sobre os diagramas de use-case (caso de uso) e 
eventualmente diagramas de atividade. 
 Visão Lógica: Descreve como a funcionalidade do sistema será implementada. É 
feita principalmente pelos analistas, programadores e utilizadores. Em contraste 
com a visão use-case, a visão lógica observa e estuda o sistema internamente. Ela 
descreve e especifica a estrutura estática do sistema (classes, objectos, e 
relacionamentos) e as colaborações dinâmicas quando os objetos enviarem 
mensagens uns para os outros para realizarem as funções do sistema. Propriedades 
como persistência e concorrência são definidas nesta fase, bem como as interfaces e 
as estruturas de classes. A estrutura estática é descrita pelos diagramas de classes e 
objetos. O modelo dinâmico é descrito pelos diagramas de estado, sequência, 
Comunicação e atividade. 
 Visão de Concorrência: Trata a divisão do sistema em processos e processadores. 
Este aspecto, que é uma propriedade não funcional do sistema, permite uma melhor 
utilização do ambiente onde o sistema se encontrará, se o mesmo possui execuções 
paralelas, e se existe dentro do sistema uma gestão de eventos assíncronos. Uma 
vez dividido o sistema em linhas de execução de processos concorrentes (threads), 
esta visão de concorrência deverá mostrar como se dá a comunicação e a 
concorrência destas threads. A visão de concorrência é suportada pelos diagramas 
dinâmicos, que são os diagramas de estado, sequência, Comunicação e atividade, e 
pelos diagramas de implementação, que são os diagramas de componentes e de 
instalação. 
 Visão de Componentes: É suportada pelos diagramas de componentes que 
descrevem a implementação dos módulos e suas dependências. É principalmente 
executada por programadores. Visão de Organização: Esta visão é representada pelos diagramas de instalação ou 
de execução. A visão de organização mostra a organização física do sistema, os 
Visão de Organização Visão de Concorrência 
 
 
 
10 
computadores, os periféricos e como eles se conectam entre si. É executada pelos 
engenheiros de sistemas (programadores, integradores e testers). 
Levantamento de Requisitos 
 
 Entender os requisitos de um problema está entre as tarefas mais difíceis 
enfrentadas por um engenheiro de software. A engenharia de requisitos ajuda os 
engenheiros de software a compreender melhor o problema que eles vão trabalhar para 
resolver. Inclui um conjunto de tarefas que levam a um entendimento de qual será o 
impacto do software sobre o negócio, do que o cliente quer e de como os usuários finais 
vão interagir com o software. A engenharia de requisitos começa com a concepção – tarefa 
que define o escopo e a natureza do problema a ser resolvido. Ela avança para o 
levantamento – tarefa que ajuda o cliente a definir o que é necessário; e depois para a 
elaboração – em que os requisitos básicos são refinados e modificados. À medida que o 
cliente define o problema, ocorre a negociação – quais são as prioridades, o que é 
essencial, o que é necessário? 
 Mas será que é fácil? 
 
 
 
 
 
11 
 
Segundo dicionário da Língua Portuguesa: 
 “Requisito: Condição a ser preenchida necessariamente pelo produto ou serviço.” 
 É uma condição ou capacidade que deve ser alcançada ou possuída por um sistema 
ou componente deste para satisfazer um contrato, padrão, especificação ou outros 
documentos formalmente impostos. 
 Não importa quão bem projetado ou codificado está um programa, se ele for mal 
analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor. 
 A atividade de levantamento de requisitos é a etapa de compreensão do problema 
aplicado ao desenvolvimento de software. O principal objetivo é que os desenvolvedores e 
usuários do sistema a ser construído tenham a mesma visão do problema a ser resolvido. 
 É de suma importância que antes da escrita de uma única linha de código, seja 
“concluída” a etapa do levantamento de requisitos, vale a máxima que é quase impossível 
concluir esta etapa devido à natureza flexível que os sistemas de softwares exigem. 
 Normalmente os requisitos de um sistema são identificados a partir do domínio do 
negócio. O produto do levantamento de requisito é o documento de requisitos, que declara 
os diversos tipos de requisitos do sistema. O vocabuláriqo utilizado que deve ser utilizado 
neste documento deve ser acessível ao usuário (cliente) do sistema e preferencialmente que 
não possua nenhuma referência à tecnologia. 
 Imagine que um determinado software tenha sido desenvolvido aplicando as 
melhores práticas e técnicas de programação, mas que quando entram em produção os 
usuários não conseguem operá-los, ou não conseguem extrair/trabalhar as informações que 
ele normalmente está acostumado a obter. Então logo eles irão começar a reclamar do 
sistema e em muitos dos casos irão se antepor a utilizá-lo. É para evitar situações como 
essa que a fase de levantamento de requisitos existe. 
 Uma das formas de se medir a qualidade de um sistema de software é através de sua 
utilidade. E um sistema será útil para seus usuários se atender aos requisitos definidos. 
 Portanto, os requisitos devem ser expressos de uma maneira tal que eles possam ser 
verificados e comunicados a leitores técnicos e não-técnicos. Clientes (leitores não-
técnicos) devem entender esses documentos para que possam priorizar o desenvolvimento 
dos requisitos, conforme as necessidades da organização. 
 Não importa qual seja o processo de desenvolvimento utilizado: o envolvimento do 
usuário final no desenvolvimento de um sistema de software é de fundamental 
importância. 
 
 
 
12 
 
 A engenharia de requisitos consiste no estudo de viabilidade do sistema, na 
extração, na análise, na especificação, na documentação e validação de requisitos. O 
produto final do processo de extração de requisitos é um documento de Especificação de 
Requisitos de Software (ERS), que descreve o que o sistema proposto deverá fazer, sem, 
entretanto descrever como o software fará isso. 
Estudo de Viabilidade 
 
 Para todos os sistemas novos, o processo de engenharia de requisitos deve começar 
com um estudo de viabilidade. A entrada para o estudo de viabilidade é uma descrição 
geral do sistema e de como ele será utilizado dentro de uma organização. Os resultados do 
estudo de viabilidade deve ser um relatório que recomenda se vale a pena ou não realizar o 
processo de engenharia de requisitos e o processo de desenvolvimento de sistema. 
 Um estudo de viabilidade é, na maioria das vezes, um estudo breve, direcionado, 
que se destina a responder algumas perguntas: 
 O sistema contribui para os objetivos gerais da organização? 
 O sistema pode ser implementado com a utilização de tecnologia atual dentro das 
restrições de custo e de prazo? 
 O sistema pode ser integrado com outros sistemas já em operação? 
 Preparar um estudo de viabilidade envolve avaliar e coletar informações e preparar 
relatórios. Depois de obtida as informações, as seguintes perguntas devem ser feitas: 
 Como a organização se comportaria, se esse sistema não fosse implementado? 
 Quais são os problemas com os processos atuais e como o sistema ajudaria a 
diminuí-los? 
 Quais serão as contribuições diretas advindas do novo sistema? 
 Essas informações podem ser transferidas para outros sistemas existentes na 
organização e/ou podem ser recebidas de programas já implementados? 
 O sistema requer tecnologia que não tenha sido utilizada anteriormente na 
organização? 
 Quais as compatibilidades que serão necessárias para com o sistema? 
 Entre as fontes de informação estão os gerentes dos departamentos no qual o 
sistema será implantado, os engenheiros de software acostumados com o tipo do sistema 
proposto, peritos em tecnologia, usuários finais do sistema, etc… (stakeholders - qualquer 
pessoa que tenha uma influência direta ou indireta sobre os requisitos do sistema). 
 
 
 
13 
 
 O relatório de estudo de viabilidade pode propor mudanças no enfoque, no 
orçamento e no cronograma e sugerir outros requisitos de alto nível do sistema. 
Processo de Extração de Requisitos 
 
 A tarefa de extração de requisitos não é fácil. As necessidades do usuário mudam à 
medida que o ambiente no qual o sistema funciona muda com o tempo. Além disso, 
frequentemente a ERS e o próprio processo de análise e especificação de requisitos dão 
novas ideias aos clientes sobre as suas necessidades e sobre as funções do sistema. 
Portanto, mudanças nos requisitos acontecem na maioria dos sistemas complexos. Embora 
muitas mudanças sejam devidas às mudanças das necessidades dos usuários, muitas advêm 
da interpretação ou especificação incorreta dos requisitos do sistema. Requisitos 
incompletos, incorretos ou mal entendidos são as causas mais frequentes da baixa 
qualidade, excesso de custo e entrega fora do prazo. 
 Essa tarefa não é encarada com a devida importância durante a maioria dos cursos. 
Normalmente o professor cria a especificação e os alunos sentam-se frente ao computador 
e começam a escrever o programa. Na vida real, isso não acontece. O software a ser 
desenvolvido pode ter escopos e complexidade diversificados e na maioria dos casos não é 
possível sentar à frente da máquina antes de obter mais informações sobre o que o software 
deve fazer, que serão obtidas através da extração de requisitos. 
 A habilidade de empregar um processo sistemático na extração de requisitos é um 
dos conhecimentos imprescindíveis para um engenheiro de software. Pesquisas têm 
mostrado que quase todo o software vendido não satisfaz as necessidades do usuário. A 
engenharia de requisitos, um dos termos utilizados para esse processo,engloba os 
seguintes processos: 
 Extração dos Requisitos: é o processo através do qual os usuários ou compradores 
de um sistema de software descobrem, revelam e entendem os requisitos. 
 Análise dos Requisitos: é o processo de raciocínio sobre os requisitos que foram 
extraídos; envolve atividades de exame dos requisitos para descobrir conflitos ou 
inconsistências, união de requisitos relacionados e identificação de requisitos que 
porventura estejam faltando. 
 Especificação dos Requisitos: é o processo de armazenar os requisitos em uma ou 
mais formas, incluindo língua natural ou formal, representações simbólicas ou 
gráficas. 
 
 
 
14 
 Validação dos Requisitos: é o processo de confirmação, junto ao usuário, que os 
requisitos especificados são válidos e estão corretos e completos. 
 Esses processos não podem ser totalmente separados e executados seqüencialmente. 
Todos eles são intercalados e executados repetidamente. Em muitos casos, quando se 
especifica os requisitos localiza-se conflitos ou ausências, quando se valida, percebe-se a 
necessidade de outros requisitos ou detalhes. Nesses casos, precisa-se retornar ao processo 
de extração de requisitos. 
 A maneira mais comum de extrair requisitos é obter a informação diretamente das 
pessoas que utilizam o sistema e esse procedimento pode ser dividido em cinco etapas: 
 Identificar as fontes de requisitos relevantes (usuários ou mais propriamente 
stakeholders); 
 Fazer perguntas apropriadas visando obter um entendimento das necessidades dos 
usuários; 
 Analisar as informações obtidas, procurando por implicações, inconsistências ou 
questões não resolvidas; 
 Confirmar com os usuários o seu entendimento do problema; 
 Sintetizar os requisitos de forma apropriada. 
Técnicas para extração de requisitos 
 
 Em todo desenvolvimento de software, um aspecto fundamental é a captura dos 
requisitos dos usuários. A extração de requisitos é um processo impreciso e difícil. Existem 
várias dificuldades implícitas nesse processo. 
 
 Para apoiar este trabalho, diversas técnicas podem ser utilizadas. 
Amostragem: Em um levantamento de requisitos, geralmente um engenheiro de software 
se depara com duas importantes questões: 
 Entre os muitos relatórios, formulários e documentos gerados pelos membros de 
uma organização, quais deverão ser objeto de investigação? 
 
 
 
15 
 
 Pode haver um grande número de pessoas afetadas pelo sistema de informação 
proposto. Quais delas devem ser entrevistadas, observadas ou questionadas? 
 Servindo de base para todas as técnicas de levantamento de requisitos, entre elas 
investigação, entrevistas e observação, estão as decisões cruciais dizendo respeito a o que 
examinar e quem questionar ou observar. Estas decisões podem ser apoiadas por uma 
abordagem estruturada chamada amostragem. 
 Amostragem é o processo de seleção sistemática de elementos representativos de 
uma população. Quando os elementos selecionados em uma amostragem são analisados, 
pode-se assumir que esta análise revelará informações úteis acerca da população como um 
todo. 
 Por que usar amostragem? 
 diminuir custos; 
 acelerar o processo de levantamento de informações; 
 eficiência: a informação tende a ser mais apurada, já que menos elementos podem 
ser analisados, mas estes podem ser analisados com mais detalhes; 
 reduzir tendências. 
Investigação: Muitas vezes, algumas informações são difíceis de serem obtidas através de 
entrevistas ou observação. Tais informações revelam, tipicamente, um histórico da 
organização e sua direção. Nestes casos, devemos utilizar investigação, isto é, análise de 
documentos. 
 Através de investigação, podemos obter mais facilmente informações, tais como 
tipos de documentos e problemas associados, informação financeira e contextos da 
organização. Essas informações são difíceis de serem obtidas através de outras técnicas de 
levantamento de requisitos, tais como entrevistas ou observação. 
Entrevistas: Uma entrevista de levantamento de informações é uma conversa 
direcionada com um propósito específico, que utiliza um formato “pergunta-resposta”. Os 
objetivos de uma entrevista incluem: 
 obter as opiniões do entrevistado, o que ajuda na descoberta dos problemas-chave a 
serem tratados; 
 conhecer os sentimentos do entrevistado sobre o estado corrente do sistema; 
 obter metas organizacionais e pessoais; e 
 levantar procedimentos informais 
 
 
 
16 
 
 Em uma entrevista, o engenheiro de software está, provavelmente, estabelecendo 
um relacionamento com uma pessoa estranha a ele. Assim, é importante que ele: 
 construa, rapidamente, uma base de confiança e entendimento; 
 mantenha o controle da entrevista; 
 venda a “idéia do sistema”, provendo ao entrevistado as informações necessárias. 
Questionários: O uso de questionários constitui uma técnica de levantamento de 
informações que permite ao analista obter de várias pessoas afetadas pelo sistema (corrente 
ou proposto). Informações tais como: 
 Posturas: o que as pessoas na organização dizem querer; 
 Crenças: o que as pessoas pensam ser realmente verdade; 
 Comportamento: o que as pessoas fazem; 
 Características: propriedades de pessoas ou coisas. 
 Um questionário pode ter objetivos distintos, em função de sua aplicação, tais 
como: 
 Procurar quantificar o que foi levantado em entrevistas. 
 Determinar como um sentimento (expresso em uma entrevista) é realmente 
difundido ou limitado. 
 Examinar uma grande amostra de usuários do sistema para sentir problemas ou 
levantar questões importantes, antes de se programar entrevistas. 
 Há muitas similaridades entre estas duas técnicas. De fato, pode ser útil utilizar as 
duas abordagens em conjunto: 
 procurando refinar respostas não claras de um questionário em uma entrevista; 
 projetando um questionário com base no que foi levantado em uma entrevista. 
Observação: Observar o comportamento e o ambiente do indivíduo que toma decisões 
pode ser uma forma bastante eficaz de levantar informações que, tipicamente, passam 
despercebidas usando outras técnicas. 
 Tomadas de decisão ocorrem em diversos níveis da organização: operacional, 
gerencial e estratégico e, portanto, é importante observá-las em todos os níveis que tenham 
interação com o sistema. Através da observação é possível capturar: 
 o que realmente é feito e não apenas o que é documentado ou explicado. 
 o relacionamento entre o “tomador de decisão” e outros membros da organização. 
 A observação é usada para: 
 
 
 
17 
 
 obter informações sobre o “tomador de decisão” e seu ambiente, que não são 
capturadas por outras técnicas. 
 confirmar ou negar informações de entrevistas e/ou questionários. 
 Alguns pontos importantes devem ser realçados: o analista deve saber o que 
observar, quem observar, quando, onde, porque e como. 
Prototipação: A prototipação é uma técnica valiosa para se obter rapidamente informações 
específicas sobre requisitos de informação do usuário. Trata-se de uma versão inicial do 
sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar 
desde cedo falhas que através da comunicação verbal não são tão facilmente identificáveis. 
Neste tipo de abordagem apenas são desenvolvidas algumas funcionalidades sendo 
normalmente desenvolvidas primeiro aquelas que são mais fáceis de compreender por 
parte do utilizador e que lhe podem trazer maior valor acrescentado (principalmente na 
prototipação evolutiva, isto é, aquela que mais tarde é evoluída para a fase de 
desenvolvimento). O uso de protótipos deve ser considerado apenas mediante uma análise 
custo-benefício, já que os custos de desenvolvimento de um protótipo podem facilmente 
crescer, sendo particularmente úteis em situações em que a interface com os utilizadores é, 
para eles, um aspecto crítico. Tipicamente, a prototipação permite capturar os seguintes 
tipos de informação: Reações iniciais do usuário: Como o usuário se sente em relação ao sistema em 
desenvolvimento? Reações ao protótipo podem ser obtidas através da observação, 
entrevistas, questionário ou relatório de avaliação. 
 Sugestões do usuário para refinar ou alterar o protótipo: guiam o analista na 
direção de melhor atender as necessidades dos usuários. 
 Inovações: novas capacidades, não imaginadas antes da interação com o protótipo. 
 Informações para revisão de planos: estabelecer prioridades e redirecionar planos. 
 Usuários são fundamentais na prototipação. Para capturar as reações dos usuários 
em relação ao protótipo, outras técnicas de levantamento de informação devem ser usadas 
em conjunto. Durante a experimentação do usuário com o protótipo, utiliza-se a 
observação. Para capturar opiniões e sugestões, podem ser empregados, além da 
observação, entrevistas e questionários. 
Especificação e documentação 
 É nesta fase que se dá a produção propriamente dita do documento de especificação 
de requisitos. 
 
 
 
18 
 
 Em todos os tipos de especificação há dois tipos de requisitos a considerar: 
 Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema 
disponibilize, de uma forma completa e consistente. É aquilo que o utilizador 
espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será 
desenvolvido. 
Exemplos: 
o “O software deve possibilitar o cálculo dos gastos diários, semanais, 
mensais e anuais com pessoal”. 
o “O software deve emitir relatórios de compras”. 
o “Os usuários devem poder obter o número de aprovações, reprovações e 
trancamentos em todas as disciplinas”. 
 Os requisitos funcionais descrevem as funcionalidades e serviços que o 
sistema deve oferecer. Dependem do tipo do software, potenciais usuários e do tipo 
de sistema onde o software será utilizado. 
 Requisitos não-funcionais: referem-se a aspectos não-funcionais do sistema, como 
restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. 
Costumam ser divididos em Requisitos não-funcionais de: Utilidade, Confiança, 
Desempenho, Suporte e Escalabilidade. 
Exemplos: 
o “O tempo de resposta do sistema deve ser inferior a 30 segundos”. 
o “O tempo de desenvolvimento não deve ultrapassar seis meses”. 
o “O software deve ser operacionalizado no sistema específico”. 
 Os requisitos não-funcionais definem as propriedades do sistema e suas 
restrições, isto é, confiabilidade, tempo de resposta. Restrições podem ser 
capacidade de dispositivos de I/O, representações gráficas, etc. 
 Pode-se também considerar os requisitos do domínio, que tal como o nome indica 
derivam do domínio e não de necessidades específicas dos utilizadores, podendo depois ser 
classificados como funcionais ou não funcionais. 
 A documentação produzida poderá ter diferentes destinatários e como tal diferentes 
objetivos. Podem-se distinguir três tipos de especificação: 
 Especificação de requisitos do usuário. 
 Especificação de requisitos do sistema. 
 Especificação do design da aplicação. 
 
 
 
19 
 
 A vantagem de conceber mais do que uma especificação para um dado sistema é a 
de em cada especificação se comunicar apenas um determinado tipo de informação 
adequado ao leitor a que se destina (usando "linguagens" que o utilizador conheça). Por 
exemplo, enquanto que nos requisitos do utilizador apenas é feita uma abordagem de alto 
nível das funcionalidades do sistema e suas restrições, usando linguagem natural e 
eventualmente diagramas (esquemas), nos requisitos do sistema cada requisito é descrito 
com mais detalhe introduzindo já alguns conceitos relativos à arquitetura do sistema, 
fazendo-se uso de linguagens estruturadas (notações gráficas como diagramas de casos de 
uso). 
 Requisitos do Usuário: Os requisitos do utilizador destinam-se, portanto, aos 
vários níveis hierárquicos da organização na qual o sistema será implementado 
(desde gestores a utilizadores), pelo que são descritos usando apenas linguagem 
natural, formulários e diagramas muito simples. Obviamente, neste nível de 
especificação surgem algumas dificuldades: 
o Ambigüidade: torna-se difícil descrever os requisitos de uma forma 
inequívoca sem tornar a sua descrição muito longa ou de difícil 
compreensão. 
o Confusão: ainda que possa não ser tão relevante do ponto de vista do 
cliente, a distinção entre requisitos funcionais/não-funcionais e objetivos do 
sistema torna-se difícil. 
o Agrupamento de requisitos: ao descrever as funcionalidades de um sistema, 
pode tornar-se difícil separar claramente os requisitos, o que leva a que 
vários requisitos sejam expressos como sendo apenas um. 
 Algumas considerações úteis a ter em conta ao escrever uma especificação 
 de requisitos do utilizador: 
o Usar o mesmo formato em todos os requisitos (evitam-se omissões e 
facilita-se a verificação dos requisitos). 
o Distinguir claramente entre comportamentos esperados e desejáveis do 
sistema através do uso de expressões como "O sistema permitirá criar (...)" 
ou "Deverá ser possível criar (...)" respectivamente. É importante deixar 
claro o que o sistema tem de fazer e sugestões de como o deve fazer e, 
acima de tudo, usar este tipo de expressões de forma consistente ao longo de 
todo o documento. 
 
 
 
20 
 
o Usar formatação de texto para salientar determinados aspectos do 
documento (usando negrito, por exemplo). 
o Evitar usar termos demasiado técnicos ou fora do âmbito do sistema, 
identificando-os e definindo-os de uma forma clara quando for 
absolutamente necessário usá-los. 
 Requisitos do sistema: Os requisitos do sistema têm um caráter mais técnico, 
consistindo numa descrição detalhada dos requisitos do utilizador correspondentes 
recorrendo ao uso, para além da linguagem natural, de linguagens estruturadas e 
notações gráficas. Estes requisitos destinam-se ainda aos utilizadores do sistema (e 
particularmente aos engenheiros que trabalhem nessa organização) e destinam-se 
também às equipes de especificação de arquitetura do sistema e de 
desenvolvimento. Tal como nos requisitos do utilizador, o uso de linguagem natural 
levanta problemas, embora alguns deles sejam ligeiramente diferentes: 
o As mesmas palavras podem, de acordo com a interpretação de cada pessoa, 
designar conceitos diferentes. 
o O mesmo requisito pode ser descrito de formas diferentes, o que leva a que 
cada pessoa tenha de saber quando é que descrições diferentes se referem ou 
não a requisitos diferentes. 
 Design de aplicação: Por fim, a especificação do design da aplicação consiste 
num documento usado pela equipe de desenvolvimento do sistema no qual 
estão definidos pormenores, a um nível mais técnico, acerca da implementação 
do sistema e sua arquitetura. A partir deste documento, um elemento que entre 
para a equipe de desenvolvimento a meio do projeto deverá ser capaz de "se 
situar" quando precisar começar a codificar, compreendendo a forma como a 
implementação, a um nível global, está a ser feita, mas sem conhecer 
necessariamente os detalhes de implementação dos componentes menores. Não 
convém cair na tentação de deixar toda a implementação detalhada, uma vez 
que convém que os desenvolvedores tenham alguma margem de manobra tanto 
para inovar como para resolver problemas encontrados em subsistemas de 
forma que uma especificação inicial da arquitetura não consegue prever. 
 
Saídas de um bom processo – ajuda os usuários a explorarem e entenderem 
completamente seus requisitos, especialmente a separação entre o que eles querem e o que 
 
 
 
21 
 
realmente precisam. Suas interações com o engenheiro de software os ajudam a entender as 
restrições que podem ser impostas ao sistema pela tecnologia, pelas práticas da própria 
organização ou por regulamentações governamentais. Eles passam a entender as 
alternativas, tanto tecnológicas quanto procedimentais, as escolhas que podem ser 
necessáriasquando dois requisitos não podem ser totalmente satisfeitos, entendendo, na 
maioria das vezes, as implicações das decisões por eles tomadas durante o 
desenvolvimento de requisitos, criando poucas surpresas no momento de entrega do 
sistema. Os usuários passam a compartilhar com o engenheiro de software uma visão dos 
problemas que estão tentando resolver, dos tipos de soluções possíveis e se sentem um 
pouco donos dos produtos gerados pela extração, sentem-se satisfeitos, informados e 
acreditam que o risco é minimizado. Similarmente, os engenheiros e desenvolvedores de 
software que participaram do processo de extração de requisitos têm confiança de que 
estão resolvendo o problema certo e se convencem de que estão resolvendo o problema 
viável sob todos os aspectos, não somente técnicos, mas também humanos. Sabem que os 
usuários irão cooperar se for necessário novos esclarecimentos e que essas interações serão 
mínimas. 
Saídas de um Processo Ruim – o pior resultado de um processo de extração de requisitos 
mal feito é que os desenvolvedores poderão estar resolvendo o problema errado. Mesmo 
que os desenvolvedores estejam resolvendo essencialmente o problema certo, um processo 
de extração ruim pode trazer outras conseqüências negativas. Compradores e usuários 
podem ficar insatisfeitos (acontecem freqüentemente quando os desenvolvedores não 
ouvem os usuários ou tendem a forçar suas próprias visões e interpretações), resultando 
numa participação menos efetiva por parte dos compradores e usuários, resultando em 
respostas menos completas, podendo continuar afetando o projeto durante o 
desenvolvimento e entrega. Os desenvolvedores podem descobrir que há informações 
importantes faltando, o que resulta em encontros adicionais, podem tomar decisões erradas 
devido à falta de entendimento das reais necessidades. Os requisitos podem mudar 
freqüentemente, resultando em demoras ou esforços desperdiçados nas fases de projeto e 
implementação, resultando num custo maior, atraso no planejamento e algumas vezes, 
projetos cancelados. Tudo isso pode resultar numa perda de dinheiro, tanto para a empresa 
a que pertencem os desenvolvedores, como para os compradores, má reputação e perda de 
credibilidade dos desenvolvedores, além de uma queda na confiança dos próprios 
desenvolvedores em si mesmos 
 
 
 
22 
 
Validação 
 
 Nesta fase pretende-se demonstrar que o documento de requisitos produzido 
corresponde, de fato, o sistema que o cliente necessita. 
 À semelhança do que sucede na análise dos requisitos, pretende-se encontrar 
problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lida 
com uma especificação completa dos requisitos. 
 A validação é especialmente importante em sistemas de grandes dimensões porque 
muitas vezes são encontrados erros (durante o desenvolvimento ou já depois de o sistema 
estar sendo usado) no documento de requisitos, e esses erros têm repercussões 
proporcionais à dimensão do projeto. Estes tipos de erros traduzem-se em elevados custos 
e necessidade de refazer muito do trabalho que se julgava já concluído. 
 Durante a fase de validação dos requisitos, devem ser verificados (através de 
checklists) os seguintes atributos dos requisitos: 
 Validade: a especificação resulta da análise dos requisitos identificados junto das 
diversas partes interessadas envolvidas. Como tal, requisitos identificados 
individualmente (isto é, junto de cada parte interessada) podem diferir da 
especificação final que se atinge após o cruzamento de informação e é necessário 
que cada cliente compreenda e aceite a especificação final obtida. 
 Consistência: não devem existir conflitos entre os requisitos identificados. 
 Compreensibilidade/Ambigüidade: os requisitos devem poder ser compreendidos 
de forma inequívoca pelas partes interessadas. 
 Completude: todas as funcionalidades pretendidas devem fazer parte da 
especificação do sistema. 
 Realismo: dadas às restrições do projeto (tecnológicas, financeiras e temporais) o 
sistema especificado tem de ser implementável. 
 Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização 
dos requisitos especificados, estes devem ser descritos de modo a que seja possível 
verificar se foram ou não concretizados, isto é, se o sistema final corresponde à 
especificação inicial. 
 Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar 
claramente identificada. Entre outros motivos, isto é importante para facilitar a 
gestão futura dos requisitos. 
 
 
 
23 
 
 Conformidade com normas: para além dos aspectos funcionais dos requisitos, a 
sua especificação deve obedecer às normas usadas ao longo de todo o documento. 
 A fase de validação não deve ser encarada de ânimo leve: trata-se de uma fase 
muito importante na engenharia de requisitos e da qual dependem elevados custos a médio 
e longo prazo. 
 Por depender bastante dos retornos transmitidos pelos clientes (que não são peritos 
em validação de requisitos) é bastante falível e regra geral há erros que não são 
encontrados num primeiro momento, o que leva inevitavelmente a discordâncias numa fase 
posterior, já com o documento validado e o projeto em desenvolvimento ou concluído. 
Quando isto sucede, torna-se necessário negociar e chegar a um acordo quanto à forma de 
corrigir o erro detectado. 
UML – Linguagem de Modelagem Unificada 
 
A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é 
uma linguagem visual utilizada para modelar sistemas computacionais por meio do 
paradigma de orientação a objetos. Essa linguagem tornou-se, nos últimos anos, a 
linguagem padrão de modelagem de Software adotada internacionalmente pela indústria de 
Engenharia de Software. 
 Deve ficar bem claro, no entanto, que a UML não é uma linguagem de 
programação e sim uma linguagem de modelagem, cujo objetivo é auxiliar os engenheiros 
de Software a definir as características do Software, tais como seus requisitos, seu 
comportamento, sua estrutura lógica, a dinâmica de seus processos e até mesmo suas 
necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser 
implantado. Todas essas características são definidas por meio da UML antes do Software 
começar a ser realmente desenvolvido. 
 Através da UML podemos modelar um sistema utilizando vários diagramas, nos 
quais podemos destacar dois grandes grupos: 
 Modelagem Estrutural 
o Diagrama de Classes 
o Diagrama de Objetos 
o Diagrama de Componentes 
o Diagrama de Estrutura Composta 
o Diagrama de Pacotes 
 
 
 
24 
o Diagrama de Implantação 
 Modelagem Comportamental (Temporal) 
o Diagrama de Casos de Uso 
o Diagrama de Atividades 
o Diagrama de Transição de Estados 
o Diagrama de Máquina de Estados 
o Diagramas de Interação Geral 
o Diagramas de Interação entre Objetos 
 Diagrama de Sequência 
 Diagrama de Comunicação 
 Diagrama de Tempo 
 Diagrama de Comunicação 
A UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que são 
conhecidos como "os três amigos". Eles possuem um extenso conhecimento na área de 
modelagem orientado a objetos já que as três mais conceituadas metodologias de 
modelagem Orientada a Objetos foram eles que desenvolveram e, a UML é a junção do 
que havia de melhor nestas três metodologias adicionado novos conceitos e visões da 
linguagem. 
 A UML é o resultado da unificação da linguagem de modelagem de objetos de 3 
métodos líderes do mercado: Booch, Object Modeling Technique (OMT) e Objected-
Oriented Software Engineering (OOSE). Em 1997, a UML v1.1 foi adotada pela OMG 
(Object Management Group) e desde então tornou-se o padrão da indústria de Software 
para a modelagem de objetos e componentes. 
 
 
 
 
25 
 
Um processo para utilizar a UML 
 
A UML contém notações e regras que tornam possível expressar modelos 
orientados a objetos. Mas ela não prescreve como o trabalhotem que ser feito, ou seja, não 
possui um processo de como o trabalho tem que ser desenvolvido. Já que a UML foi 
desenvolvida para ser usada em diversos métodos de desenvolvimento. 
Para usar a UML com sucesso é necessário adotar algum tipo de método de 
desenvolvimento, especialmente em sistema de grande porte onde a organização de tarefas 
é essencial. A utilização de um processo de desenvolvimento torna mais eficiente calcular 
o progresso do projeto, controlar e melhorar o trabalho. 
Um processo de desenvolvimento descreve "o que fazer", "como fazer", "quando 
fazer", e "porque deve ser feito". Este também descreve um número de atividades que 
devem ser executadas em uma certa ordem. Quando são definidas e relacionadas as 
atividades de um processo, um objetivo específico é alcançado. 
Em seu uso normal, a palavra "processo" significa uma relação de atividades que 
devem ser executadas em uma certa ordem sem importar o objetivo, regras ou material a 
ser usado. No processo de desenvolvimento da engenharia de software, é necessário saber 
o objetivo final do processo, definir regras a serem seguidas e adotar um método fixo de 
desenvolvimento. 
Um método (processo) tradicional de desenvolvimento orientado a objetos é 
dividido em análise de requisitos, análise, design (projeto), implementação, e testes. A 
análise de requisitos captura as necessidades básicas funcionais e não-funcionais do 
sistema que deve ser desenvolvido. A análise modela o problema principal (classes, 
objetos) e cria um modelo ideal do sistema sem levar em conta requisitos técnicos do 
sistema. O design expande e adapta os modelos da análise para um ambiente técnico, onde 
as soluções técnicas são trabalhadas em detalhes. A implementação consiste em codificar 
em linguagem de programação e banco de dados os modelos criados. E as atividades de 
testes devem testar o sistema em diferentes níveis, verificando se o mesmo corresponde as 
expectativas do usuário. 
Existe um processo desenvolvido pela Rational Inc., mesma empresa que 
desenvolveu a UML, que monta duas visões do desenvolvimento de um sistema: visão 
gerencial e técnica. A visão técnica utiliza as tradicionais atividades de análise, design e 
implementação, enquanto a visão gerencial utiliza as seguintes fases no desenvolvimento 
de cada geração do sistema. 
 
 
 
26 
 
 Início: Define o escopo e objetivo do projeto; 
 Elaboração: Desenvolve o produto em detalhes através de uma série 
de interações. Isto envolve mais análise, design e programação; 
 Transição: Gera o sistema para o usuário final, incluindo as 
atividades de marketing, suporte, documentação e treinamento. 
Cada fase no ciclo é executada em séries de interações que podem sobrepor outras 
fases. Cada interação consiste tipicamente em atividades tradicionais como análise e 
design, mas em diferentes proporções dependendo da fase em que esteja a geração do 
sistema em desenvolvimento. 
Ferramentas modernas devem dar suporte não apenas para linguagens de 
modelagem e programação, mas devem suportar um método de desenvolvimento de 
sistemas também. Isso inclui conhecimento das fases em um processo, ajuda online, e 
aconselhamentos do que fazer em cada fase do desenvolvimento, suporte a 
desenvolvimento interativo e fácil integração com outras ferramentas. 
O Futuro da UML 
 
Embora a UML defina uma linguagem precisa, ela não é uma barreira para futuros 
aperfeiçoamentos nos conceitos de modelagem. O desenvolvimento da UML foi baseado 
em técnicas antigas e marcantes da orientação a objetos, mas muitas outras influenciarão a 
linguagem em suas próximas versões. Muitas técnicas avançadas de modelagem podem ser 
definidas usando UML como base, podendo ser estendida sem se fazer necessário redefinir 
a sua estrutura interna. 
A UML será a base para muitas ferramentas de desenvolvimento, incluindo 
modelagem visual, simulações e ambientes de desenvolvimento. Em breve ferramentas de 
integração e padrões de implementação baseados em UML estarão disponíveis para 
qualquer um. 
A UML integrou muitas idéias adversas, e esta integração vai acelerar o uso do 
desenvolvimento de softwares orientados a objetos. 
Abstração 
 O uso do computador é baseado em abstrações, que nada mais é do que uma 
representação simplificada da realidade, segundo um ponto de vista específico. Na 
orientação a objetos o principal mecanismo de abstração é a Classe. Abstração nada mais é 
 
 
 
27 
do que, a grosso modo, interpretação, ou seja, conseguir enxergar informações que estão 
subentendidas. 
 
Exemplo de Abstração 
Classes 
 Conceitualmente, uma classe descreve um conjunto de objetos que compartilham 
características comuns. Uma classe implementa um Tipo Abstrato de Dados, e “encapsula” 
esses dados e suas operações. 
 Classe é a definição de um conjunto de objetos que compartilham estruturas e 
comportamentos comuns, sendo a sua abstração muito importante, dizendo respeito às 
informações extraídas em um levantamento de requisitos, por exemplo. 
 Assim as classes podem ser entendidas como descrições genéricas ou coletivas de 
entidades do mundo real. Mantém-se aqui a intenção de aproximar entidades externas de 
representações internas. Desta forma, a definição das classes de um sistema deverá 
procurar inspiração nas entidades do mundo real. 
 
Exemplo de Classe 
Objetos 
 Um objeto é um elemento que podemos manipular, acompanhar seu 
comportamento, criar, destruir etc. Um objeto existe no mundo real. Pode ser uma parte de 
qualquer tipo de sistema, por exemplo, uma máquina, uma organização, ou negócio. 
 Existem objetos que não encontramos no mundo real, mas que podem ser vistos de 
derivações de estudos da estrutura e comportamento de outros objetos do mundo real. 
 Um objeto é um elemento da classe 
 
 
 
28 
o Objeto deve pertencer a somente uma classe 
o O objeto é o elemento que efetivamente armazena as informações de um 
programa. 
 Objetos trocam mensagens entre si 
o O funcionamento de um programa OO é caracterizado pela troca de 
mensagens de objetos criados 
 
Exemplos de Objetos 
Instanciação 
 Instanciação trata-se apenas da criação um objeto a partir de uma classe já definida, 
isto é, “instanciamos” um objeto a partir de uma classe. Deve-se ressaltar que Instâncias 
(Objetos) de uma mesma classe possuem características idênticas, variando os valores que 
essas características podem assumir. Ex: Todos os objetos de uma classe carro possuem 
uma característica comum que é cor, mas um pode ter o valor para essa característica igual 
a “Azul” e outro “Preto”. 
 
Exemplo de Instanciação 
 
Encapsulamento 
 Encapsular significa “Proteger” dados, ou informações de um objeto, através de 
métodos, que garantem acesso seguro à informação armazenada nesses objetos. 
 
 
 
29 
 Ocultamento da Informação 
o O acesso aos dados internos de objetos só pode ocorrer a partir de 
mensagens. 
 Independência de aplicação 
o Um método deve acessar informações internas do objeto. Na necessidade de 
outra informação, somente através de mensagens. 
 
Exemplo de Encapsulamento 
 
 
Encapsulamento - “Muralha” em volta do objeto 
Métodos 
 Métodos ou comportamentos representam atividades que objetos de uma classe 
podem executar. É um conjunto de instruções que é executado quando é chamado, por 
exemplo, um objeto da classe carro pode executar a atividade de transportar pessoas 
(método). Grande parte da codificação propriamente dita dos sistemas de informação 
orientados a objetos esta contida nos métodos definidos em suas classes. 
 
Exemplo de Método 
 
 
 
30 
Herança 
 Herança é o reaproveitamento de atributos e métodos, otimizando o tempo de 
desenvolvimento. É uma das características mais poderosas e importantes da orientação a 
objetos, porque permite a diminuição de linhas de código. 
 Quando temos herança, a classe que fornece a herança é chamada de SuperClasse, e 
a que recebea herança é chamada de SubClasse. Quando uma SubClasse herda os atributos 
e operações de outra, ela herda todos. O que faz a diferença é a visibilidade, que veremos 
mais adiante. 
 
Exemplo de Herança 
 
Herança Múltipla 
 Ocorre quando uma SubClasse herda características e métodos de duas ou mais 
SuperClasses. 
 
Exemplo de Herança Múltipla 
Polimorfismo 
 O conceito de polimorfismo está associado à herança. O polimorfismo trabalha com 
a redeclararão de métodos herdados por uma classe. Esses métodos, embora semelhantes, 
diferem de alguma forma da implementação utilizada na SuperClasse, sendo necessário, 
portanto, reimplementá-los na SubClasse. 
 O conceito polimorfismo é muito semelhante ao conceito de variáveis locais e 
globais, utilizado pela linguagem de programação C. Ao declararmos uma variável global 
 
 
 
31 
em um programa escrito na linguagem C, essa variável poderá ser vista e utilizada por 
qualquer outra função do programa, no entanto se em alguma função declararmos uma 
variável local com o mesmo nome da variável global, naquela função específica, quando 
nos referirmos à variável em questão será à variável local e não à global. 
 O mesmo ocorre com os métodos polimórficos, ou seja, supondo existirem diversas 
SubClasses que herdem um método de uma SuperClasse, se uma delas redeclarar este 
método, ele só se comportará de maneira diferente nos objetos da classe que o modificou, 
permanecendo igual à forma como foi implementado na SuperClasse para os objetos de 
todas as outras classes. 
 
Exemplo de Polimorfismo 
Diagramas da UML 
 Poderíamos nos perguntar: Porque a UML é composta de tantos diagramas? O 
objetivo disto é fornecer múltiplas visões do sistema a ser modelado, analisando-o e 
modelando-o sob diversos aspectos, procurando-se assim alcançar a completitude da 
modelagem, permitindo que cada diagrama complete os outros. 
 Cada diagrama da UML analisa o sistema, ou parte dele, sob uma determinada 
ótica, é como se o sistema fosse modelado em camadas, sendo que alguns diagramas 
enfocam o sistema de forma mais geral, apresentando uma visão mais externa do sistema, 
como é o objetivo do diagrama de casos de uso, enquanto outros oferecem uma visão de 
uma camada mais profunda do Software, apresentando um enfoque mais técnico ou ainda 
visualizando apenas uma característica específica do sistema ou um determinado processo. 
A utilização de diversos diagramas permite que falhas sejam descobertas, diminuindo a 
possibilidade da ocorrência de erros futuros. 
 
 
 
32 
 
Diagramas UML 
 
Diagrama de Casos de Uso 
 O diagrama de casos de uso procura, por meio de uma linguagem simples, 
possibilitar a compreensão do comportamento externo do sistema por qualquer pessoa, 
tentando apresentar o sistema através de uma perspectiva do usuário. É, dentre todos os 
diagramas da UML o mais abstrato e, portanto o mais flexível e informal. O diagrama de 
casos de uso costuma ser utilizado principalmente no início da modelagem do sistema, 
principalmente nas etapas de levantamento e análise de requisitos, embora venha a ser 
consultado e possivelmente modificado durante todo o processo de engenharia e sirva de 
base para a modelagem de outros diagramas. 
 Este diagrama tem por objetivo apresentar uma visão externa geral das funções e 
serviços que o sistema deverá oferecer aos usuários, sem se preocupar em como essas 
funções serão implementadas. O diagrama de casos de uso é de grande auxílio na etapa de 
análise de requisitos, ajudando a especificar, visualizar e documentar as características, 
funções e serviços do sistema desejados pelo usuário. O diagrama de casos de uso tenta 
identificar os tipos de usuários que irão interagir com o sistema, quais os papéis que esses 
usuários irão assumir e quais funções serão requisitadas por cada usuário específico. 
 Por utilizar uma linguagem informal e apresentar uma visão geral do 
comportamento do sistema a ser desenvolvido, o diagrama de casos de uso pode e deve ser 
apresentado durante as reuniões iniciais com os clientes como uma forma de ilustrar o 
comportamento do sistema de informação, facilitar o entendimento dos usuários e auxiliar 
na identificação de possíveis falhas de especificação. É bastante útil e recomendável que 
 
 
 
33 
um diagrama de casos de uso seja apresentado aos clientes juntamente com um protótipo, 
que permitirá que um complete o outro. 
Atores 
 Atores são representações de entidades externas, mas que interagem com o sistema 
durante sua execução. Basicamente, a interação de atores com o sistema dá-se através de 
comunicações (troca de mensagens). As entidades externas representadas pelos atores 
podem ser: 
 Pessoas: usuário, secretária, aluno, professor, administrador, etc. 
 Dispositivos: impressora, máquina ou outro equipamentos externo. 
 Hardwares: placa de modem, placa de controle, etc. 
 Software: sistema de banco de dados, aplicativos, etc. 
 E importante observar que atores representam, na verdade, papéis desempenhados 
por pessoas, dispositivos ou outros Softwares quando estiverem interagindo com o sistema. 
 Por exemplo, um ator cujo identificador seja Aluno não representa um aluno 
específico, mas sim um aluno qualquer, ou seja, uma pessoa qualquer que esteja 
interagindo com o sistema na qualidade de aluno. Desta forma, um ator pode representar 
um entre vários indivíduos, equipamentos ou Softwares. De forma análoga, uma entidade 
externa pode ser representada na forma de vários atores. Isto ocorre quando a entidade tem 
mais de um papel (tipo de participação ou interação) no sistema. Por exemplo, o indivíduo 
João da Silva poderia ser representado em um sistema na forma do ator Usuário, pois ele 
interage com o sistema nesta qualidade, e também na forma do ator Administrador, pois ele 
também interage com o sistema para este outro fim que é a administração do Software. 
 
Exemplos de Atores 
 
 
 
 
 
34 
Casos de Uso 
 A descrição dos serviços a serem oferecidos pelo sistema é feita na UML 
discriminando-se os Casos de Usos do sistema. Cada Caso de Uso descreve uma aplicação 
ou uso completo do Software. O conceito de caso de uso não deve ser confundido com o de 
módulo já que um caso de uso não é um componente do sistema, mas sim um de seus 
empregos possíveis. Também não se deve confundir o conceito de caso de uso com o de 
função que possui um escopo muito mais limitado, traduzindo frequentemente apenas um 
recurso ou utilidade do sistema. Um caso de uso é muito mais abrangente, envolvendo todo 
um conjunto de transações que juntas constituem um serviço completo oferecido pelo 
sistema. 
 A especificação das funcionalidades de um sistema na forma de casos de uso 
permite uma visão mais abrangente das aplicações do sistema, favorecendo um 
levantamento mais completo e preciso de suas atribuições. 
 
Exemplos Caso de Uso 
Associação (Interação) 
 As associações representam as interações ou relacionamentos entre os atores que 
fazem parte do diagrama, entre os atores e os casos de uso, ou os relacionamentos entre 
os casos de uso e outros casos de uso. Os relacionamentos entre os casos de uso recebem 
nomes especiais como Inclusão, Extensão e Generalização. 
 Uma Associação entre um ator e um caso de uso demonstra que o ator utiliza-se, de 
alguma maneira, da função do sistema representada pelo caso de uso em questão, seja 
requisitando a execução daquela função, seja recebendo o resultado produzido por ela a 
pedido de outro ator. 
Relacionamento entre Atores 
 Como os atores são entidades externas, os relacionamentos entre eles serão relações 
externas ao sistema. Embora estas relações possam ser desprezadas, pois não fazem parte 
do sistema e nem são de conhecimento do sistema, é possível incluí-las no modelo de casos 
de uso. De certa forma, estas relações descrevem parte do modelo de negócios da empresa. 
 
 
 
35 
 
Exemplos de Relacionamentos entre atoresRelacionamento entre Atores e casos de uso 
 O relacionamento entre um ator e um caso de uso expressa sempre uma 
comunicação entre eles, pois o ator sendo uma entidade externa não poderia possuir 
qualquer relacionamento estrutural com o sistema computacional. A notação UML para 
este tipo de relacionamento é um segmento de reta ligando ator e caso de uso. Em 
diagramas mais complexos pode-se utilizar cadeias de segmentos de retas para se evitar 
cruzamentos. 
 Como atores podem ter vários propósitos, no que diz respeito a suas interações com 
o sistema, podem existir mais de um relacionamento de um ator com diferentes casos de 
usos. De forma análoga, um mesmo caso de uso pode envolver a participação de mais de 
um ator. O caso de uso Emitir Histórico Escolar envolve a participação de dois atores: 
Secretaria e Impressora. O ator Secretaria participa em dois casos de uso: Emitir Histórico 
e Registrar Novo Aluno. 
 
Exemplo Relacionamento Ator / Caso de Uso 
 
Relacionamento entre casos de uso e outros casos de uso 
 Ao contrário do relacionamento entre ator e caso de uso, as relações entre casos de 
uso nunca serão do tipo comunicação. Isto ocorre porque casos de uso são aplicações 
completas do sistema e, por consequência, não existe sentido em fazer-se comunicar dois 
 
 
 
36 
”usos do sistema”. Todas as relações entre casos de uso serão sempre estruturais. Existem 
três tipos de relações entre casos de uso (inclusão, extensão e generalização) conforme 
descritos a seguir. 
 Inclusão (<<Include>>) 
 A associação de inclusão costuma ser utilizada quando existe um serviço, situação 
ou rotina comum a mais de um caso de uso. Quando isso ocorre à documentação dessa 
rotina é colocada em um caso de uso específico para que outros casos de uso utilizem-se 
desse serviço, evitando descrever uma mesma seqüência de passos em vários casos de uso. 
Os relacionamentos de inclusão indicam obrigatoriedade de execução. 
 
Exemplo de Relacionamento de Inclusão 
 
 Extensão (<<Extends>>) 
 Associações de extensão são utilizadas para descrever cenários opcionais de um 
caso de uso. Eles descrevem cenários que somente ocorrerão em uma situação específica, 
se uma determinada condição for satisfeita. Representam eventos que não ocorrem sempre, 
ou seja, são incomuns, não obrigatórios. 
 
Exemplo de Relacionamento de Extensão 
 
 
 
 
37 
Restrições em Associações de Extensão 
Restrições são compostas por um texto entre chaves e são utilizadas para definir 
validações, consistências, condições etc., que devem ser aplicadas a um determinado 
componente ou situação. Às vezes, não fica claro qual é a condição para que um caso de 
uso estendido seja executado, assim, pode-se acrescentar uma restrição à associação de 
extensão por meio de uma nota explicativa, determinando a condição para que o caso de 
uso seja executado. 
 
Exemplo de Extensão com Restrição 
 
 Generalização 
 Este relacionamento é uma forma de Associação entre casos de uso na qual existem 
dois ou mais casos de uso com características semelhantes, apresentando pequenas 
diferenças entre si. Quando tal situação ocorre, costuma-se definir um Caso de Uso Geral, 
que descreve as características compartilhadas por todos os casos de uso em questão, e 
então relacioná-lo com estes, cuja documentação conterá somente as características 
especificas de cada um. Assim não será necessário colocar a mesma documentação para 
todos os casos de uso envolvidos, porque toda a estrutura de um Caso de Uso generalizada 
é herdada pelos Casos de Uso Especializados, incluindo quaisquer possíveis Associações. 
 
Exemplo de Relacionamento de Generalização 
 
 
 
38 
 
Documentação de Casos de Uso 
A documentação de um caso de uso costuma descrever, por meio de uma 
linguagem bastante simples, a função em linhas gerais do caso de uso, destacando quais 
atores interagem com ele, quais etapas devem ser executadas pelo ator e pelo sistema para 
que o caso de uso execute sua função, quais parâmetros devem ser fornecidos e quais 
restrições e validações o caso de uso deve possuir. 
Não existe um formato específico de documentação para casos de uso definido pela 
UML, o que está de acordo com a característica do próprio diagrama, ou seja, o formato de 
documentação de um caso de uso é bastante flexível, permitindo que se documente o caso 
de uso da forma que se considerar melhor. 
Os casos de uso podem também ser documentados por meio de outros diagramas, 
como o Diagrama de Sequência ou o Diagrama de Atividade. 
Descrição dos Casos de uso 
 Descrição do Caso de Uso são narrativas de texto do Caso de Uso. Elas usualmente 
tomam a forma de uma nota ou um documento que é de alguma maneira ligada ao Caso de 
Uso, e explana o processo ou atividades que tomarão lugar no Caso de Uso. 
Descrição dos atores 
 Descrição dos atores é narrativa de texto descrevendo suas funções e suas 
interações em relação ao sistema. 
Detalhamento dos casos de uso 
 Tabela descritiva contendo todas as informações e interações do caso de uso que 
descrevem ainda os fluxos de atividade entre o sistema e o usuário. 
Nome do Caso de Uso Coloque um nome adequado para o Caso de Uso 
Caso de Uso Geral Se for um caso de uso generalizado, colocar o nome do 
caso de uso mais geral 
Descrição Descreva detalhadamente o propósito do caso de uso 
Pré Condições Se existir uma ou mais pré condições, descreva-as aqui 
Pós Condições Se existir uma ou mais pós condições, descreva-as aqui. 
Atores Liste os atores que se relacionam com este caso de uso 
Fluxo Principal 
Ações Recebidas Ações Realizadas 
1. O ator X inicia a fluxo 
principal (ou fluxo ótimo). 
2. O processo recebe a entrada, avalia e 
envia ao controle. 
 
 
 
39 
3. O controle trata a informação. 
4. Após tratar a informação os dados são 
apresentados ao ator. 
Fluxo Alternativo N 
Ações Recebidas Ações Realizadas 
 O ator X inicia a fluxo 
alternativo N (ou fluxo de 
erro, ou fluxo opcional, etc). 
 O processo recebe a entrada, avalia e 
envia ao controle. 
 O controle trata a informação. 
 Após tratar a informação os dados são 
apresentados ao ator. 
Diagrama de Classes 
 O diagrama de classes é, com certeza, o mais importante e mais utilizado diagrama 
da UML. Seu principal enfoque está em permitir a visualização das classes que comporão 
o sistema com seus respectivos atributos e métodos, bem como em demonstrar como as 
classes do diagrama se relacionam, complementam e transmitem informações entre si. Esse 
diagrama apresenta uma visão estática de como as classes estão organizadas, preocupando-
se em como definir a estrutura lógica das mesmas. O diagrama de classe serve ainda como 
base para a construção da maioria dos outros diagramas da linguagem UML. 
 Basicamente o diagrama de classes é composto por suas classes e pelas associações 
existentes entre elas, ou seja, os relacionamentos entre as classes. Nesse diagrama a 
abstração de cada classe com seus atributos e métodos individualmente corresponde à 
modelagem de vocabulário, onde são definidas as classes do sistema. 
 É no diagrama de classes que começamos a sair da parte exclusivamente de 
negócios e passamos a tornar realidade à automatização do negócio desejado 
 
Exemplo de uma Classe 
 
 
 
 
40 
Responsabilidade 
 Uma classe sempre deve versar sobre um mesmo assunto. Uma classe encapsula 
um dado conhecimento sobre algo. Não faz sentido inserirmos, em uma classe que trata de 
apartamentos, dados sobre a imobiliária ou atrasos de pagamento da hipoteca – são 
assuntos diferentes, portanto, classes diferentes! 
 Uma classe tem responsabilidade por tudo o que lhe diz respeito. Sua 
responsabilidade é resumida em seus atributos e métodos. Não é de responsabilidade de um 
proprietário incluir um apartamento, é responsabilidade da própria classe fazer essa 
inclusão. 
Componentes 
Atributos 
 Classes costumam definir atributos, também conhecidos

Outros materiais