apostila_eng_software

Prévia do material em texto

1 
 
 
 
Apostila Engenharia de Software 
 
Elielder Berwanger 
2 
 
 
 
Sumário 
1. Processo de Software ............................................................................................................ 4 
1.1 Definição de Processos .................................................................................................. 4 
2. Ciclo de vida .......................................................................................................................... 5 
3. Gerência de Projetos de Software ........................................................................................ 6 
3.1 Atividades Típicas da Gerência de Projetos: ................................................................. 7 
3.2 O Planejamento e o Acompanhamento do Projeto ...................................................... 7 
3.3 Estimativas .................................................................................................................... 7 
4. Gerência da Qualidade .......................................................................................................... 8 
4.1 Documentação .............................................................................................................. 8 
4.2 Controle e Garantia da Qualidade................................................................................. 9 
4.3 Padrões Organizacionais ............................................................................................... 9 
4.4 Revisões ....................................................................................................................... 10 
4.5 Gerência de Configuração ........................................................................................... 11 
5. Levantamento/Análise de Requisitos ................................................................................. 11 
5.1 Requisito e Tipos de Requisitos ................................................................................... 12 
5.2 O Processo da Engenharia de Requisitos .................................................................... 12 
5.3 Levantamento de Requisitos ....................................................................................... 13 
5.4 Análise de Requisitos .................................................................................................. 13 
5.5 Especificação da Lógica dos Processos ........................................................................ 14 
6. Modelo Entidade-Relacionamento ..................................................................................... 15 
6.1 Entidades ..................................................................................................................... 15 
6.2 Atributos ...................................................................................................................... 15 
7. Dicionário de Dados ............................................................................................................ 16 
8. UML ..................................................................................................................................... 16 
8.1 Diagrama de Casos de Uso .......................................................................................... 17 
8.2 Descrição de caso de uso ............................................................................................ 18 
8.3 Diagrama de Classes .................................................................................................... 20 
8.4 Diagrama de Objetos ................................................................................................... 21 
8.5 Diagrama de Seqüência ............................................................................................... 21 
8.6 Diagrama de Colaboração ........................................................................................... 22 
8.7 Diagramas de Estado ................................................................................................... 23 
8.8 Diagrama de Atividades .............................................................................................. 23 
8.9 Diagrama de Componentes ......................................................................................... 24 
3 
 
 
 
8.10 Diagrama de Implantação ........................................................................................... 25 
9. Referências bibliográficas ................................................................................................... 26 
 
 
4 
 
 
 
1. Processo de Software 
Um processo de software pode ser visto como o conjunto de atividades, métodos, práticas e 
transformações que guiam pessoas na produção de software. Um processo eficaz deve, claramente, 
considerar as relações entre as atividades, os artefatos produzidos no desenvolvimento, as ferramentas, 
os procedimentos necessários, a habilidade, o treinamento e a motivação do pessoal envolvido. 
1.1 Definição de Processos 
Há vários aspectos a serem considerados na definição de um processo de software. No centro da 
arquitetura de um processo de desenvolvimento estão algumas atividades chaves: análise e 
especificação de requisitos, projeto, desenvolvimento e testes, que são a base sobre a qual o processo 
de desenvolvimento deve ser construído. Entretanto, a definição de um processo envolve a escolha de 
um modelo de ciclo de vida, o detalhamento (decomposição) de suas macro-atividades, a escolha de 
métodos, técnicas e roteiros (procedimentos) para a sua realização e a definição de recursos e artefatos 
necessários e produzidos. 
Um processo de software não pode ser definido de forma universal. Para ser eficaz e conduzir à 
construção de produtos de boa qualidade, um processo deve ser adequado ao domínio da aplicação e 
ao projeto específico. Deste modo, processos devem ser definidos caso a caso, considerando-se as 
especificidades da aplicação, a tecnologia a ser adotada na sua construção, a organização onde o 
produto será desenvolvido e o grupo de desenvolvimento. 
Em suma, o objetivo de se definir um processo de software é favorecer a produção de sistemas de alta 
qualidade, atingindo as necessidades dos usuários finais, dentro de um cronograma e um orçamento 
previsível. 
A escolha de um modelo de ciclo de vida (ou modelo de processo) é o ponto de partida para a definição 
de um processo de desenvolvimento de software. Um modelo de ciclo de vida organiza as macro-
atividades básicas, estabelecendo precedência e dependência entre as mesmas. 
Um modelo de ciclo de vida pode ser entendido como passos ou atividades que devem ser executados 
durante um projeto. Para a definição completa do processo, a cada atividade, devem ser associados 
técnicas, ferramentas e critérios de qualidade, entre outros, formando uma base sólida para o 
desenvolvimento. Adicionalmente, outras atividades tipicamente de cunho gerencial, devem ser 
definidas, entre elas atividade de gerência e de controle e garantia da qualidade. 
São fatores que influenciam a definição de um processo: 
• Tipo de software (sistema de informação, sistema de tempo real, etc.); 
• Paradigma (estruturado, orientado a objetos, etc.); 
• Domínio da aplicação; 
• Tamanho; 
• Complexidade; 
• Características da equipe... 
Embora diferentes projetos necessitem de processos com características específicas para atender às 
suas particularidades, é possível estabelecer um conjunto de ativos de processo (sub-processos, 
atividades, sub-atividades, artefatos, recursos e procedimentos) a ser utilizado na definição de 
processos de software de uma organização. Essas coleções de ativos de processo de software constituem 
o chamado processo padrão de desenvolvimento de software. Processos para projetos específicos 
podem, então, ser definidos a partir da instanciação do processo de software padrão da organização, 
5 
 
 
 
levando em consideração suascaracterísticas particulares. Esses processos instanciados são ditos 
processos de projeto. 
De fato, o modelo de definição de processos baseado em processos padrão pode ser estendido para 
comportar vários níveis. Primeiro, pode-se definir um processo padrão da organização, contendo os 
ativos de processo que devem fazer parte de todos os processos de projeto da organização. Esse 
processo padrão pode ser especializado para agregar novos ativos de processo, considerando aspectos, 
tais como tecnologias de desenvolvimento, paradigmas ou domínios de aplicação. Assim, obtêm-se 
processos mais completos, que consideram características da especialização desejada. Por fim, a partir 
de um processo padrão ou de um processo especializado, é possível instanciar um processo de projeto, 
que será o processo a ser utilizado em um projeto de software específico. Para definir esse processo 
devem ser consideradas as particularidades de cada projeto. 
Para apoiar a definição de processos, diversas normas e modelos de qualidade de processo de software 
foram propostas, dentre elas: ISO9001, ISO/IEC 12207, ISO/IEC 15504, CMM, CMMI e MPS.BR. O 
objetivo dessas normas e modelos de qualidade é apontar características que um bom processo de 
software tem de apresentar, deixando a organização livre para estruturar essas características segundo 
sua própria cultura. 
2. Ciclo de vida 
De maneira geral, o ciclo de vida de um software envolve as seguintes fases: 
• Planejamento: O objetivo do planejamento de projeto é fornecer uma estrutura que possibilite 
ao gerente fazer estimativas razoáveis de recursos, custos e prazos. Uma vez estabelecido o 
escopo de software, uma proposta de desenvolvimento deve ser elaborada, isto é, um plano de 
projeto deve ser elaborado configurando o processo a ser utilizado no desenvolvimento de 
software. À medida que o projeto progride, o planejamento deve ser detalhado e atualizado 
regularmente. Pelo menos ao final de cada uma das fases do desenvolvimento (análise e 
especificação de requisitos, projeto, desenvolvimento e testes), o planejamento como um todo 
deve ser revisto e o planejamento da etapa seguinte deve ser detalhado. O planejamento e o 
acompanhamento do progresso fazem parte do processo de gerência de projeto. 
• Análise e Especificação de Requisitos: Nesta fase, o processo de levantamento de requisitos é 
intensificado. O escopo deve ser refinado e os requisitos identificados. Para entender a 
natureza do software a ser construído, o engenheiro de software tem de compreender o 
domínio do problema, bem como a funcionalidade e o comportamento esperados. Uma vez 
identificados os requisitos do sistema a serem desenvolvidos, estes devem ser modelados, 
avaliados e documentados. Uma parte vital desta fase é a construção de um modelo 
descrevendo o que o software tem de fazer (e não como fazê-lo). 
• Projeto: Esta fase é responsável por incorporar requisitos tecnológicos aos requisitos essenciais 
do sistema, modelados na fase anterior e, portanto, requer que a plataforma de 
desenvolvimento seja conhecida. Basicamente, envolve duas grandes etapas: projeto da 
arquitetura do sistema e projeto detalhado. O objetivo da primeira etapa é definir a arquitetura 
geral do software, tendo por base o modelo construído na fase de análise de requisitos. Esta 
arquitetura deve descrever a estrutura de nível mais alto da aplicação e identificar seus 
principais componentes. O propósito do projeto detalhado é detalhar o projeto do software 
para cada componente identificado na etapa anterior. Os componentes de software devem ser 
sucessivamente refinados em níveis de maior detalhamento, até que possam ser codificados e 
testados. 
6 
 
 
 
• Implementação: O projeto deve ser traduzido para uma forma passível de execução pela 
máquina. A fase de desenvolvimento realiza esta tarefa, isto é, cada unidade de software do 
projeto detalhado é escrita. 
• Testes: Inclui diversos níveis de testes, por exemplo: teste de unidade, teste de integração e 
teste de sistema. Inicialmente, cada unidade de software implementada deve ser testada e os 
resultados documentados. A seguir, os diversos componentes devem ser integrados 
sucessivamente até se obter o sistema. Finalmente, o sistema como um todo deve ser testado. 
• Entrega e Implantação: Uma vez testado, o software deve ser colocado em produção. Para tal, 
contudo, é necessário treinar os usuários, configurar o ambiente de produção e, muitas vezes, 
converter bases de dados. O propósito desta fase é estabelecer que o software satisfaça os 
requisitos dos usuários. Isto é feito instalando o software e conduzindo testes de aceitação 
(validação). Quando o software tiver demonstrado prover as capacidades requeridas, ele pode 
ser aceito e a operação iniciada. 
• Operação: Nesta fase, o software é utilizado pelos usuários no ambiente de produção. 
• Manutenção: Indubitavelmente, o software sofrerá mudanças após ter sido entregue para o 
usuário. Alterações ocorrerão porque erros foram encontrados, porque o software precisa ser 
adaptado para acomodar mudanças em seu ambiente externo, ou porque o cliente necessita 
de funcionalidade adicional ou aumento de desempenho. Muitas vezes, dependendo do tipo e 
porte da manutenção necessária, essa fase pode requerer a definição de um novo processo, 
onde cada uma das fases precedentes é re-aplicada no contexto de um software existente ao 
invés de um novo. 
3. Gerência de Projetos de Software 
A Gerência de Projetos de Software envolve o Produto, o Processo e as Pessoas envolvidas no projeto. 
• Produto: No que se refere ao produto, a primeira coisa a se fazer é definir o escopo do projeto. 
Para tal, é necessário fazer um levantamento de requisitos inicial. A idéia é decompor o 
problema, em uma abordagem “dividir para conquistar”. Inicialmente, o sistema deve ser 
decomposto em subsistemas que são, por sua vez, decompostos em módulos. Os módulos 
podem, ainda, ser recursivamente decompostos em sub-módulos ou funções, até que se tenha 
uma visão geral das funcionalidades a serem tratadas no projeto. 
• Processo: visto anteriormente. 
• Pessoas: Em um projeto de software, há várias pessoas envolvidas, exercendo diferentes 
papéis, tais como: gerente de projeto, analistas, projetistas, engenheiro de software, 
programadores, engenheiros de testes, gerente da qualidade, clientes e usuários. O número de 
papéis e suas denominações podem ser bastante diferentes dependendo da organização e até 
mesmo do projeto. As pessoas trabalhando em um projeto são organizadas em equipes. Assim, 
o conceito de equipe pode ser visto como um conjunto de pessoas trabalhando em diferentes 
tarefas, mas objetivando uma meta comum. Para a boa formação de equipes, devem ser 
definidos os papéis necessários e devem ser considerados aspectos fundamentais, a saber, 
liderança, organização (estrutura da equipe) e coordenação. Além disso, há diversos fatores 
que afetam a formação de equipes: relacionamentos interpessoais, tipo do projeto, criatividade 
etc. Por fim, na formação de equipes deve-se levar em conta o tamanho da equipe. Quanto 
maior o número de membros da equipe, maior a quantidade de caminhos possíveis de 
comunicação, o que pode ser um problema, uma vez que o número de pessoas que podem se 
comunicar com outras pode afetar a qualidade do produto resultante. 
Uma boa gerência de projetos começa com a fusão das visões de Produto, Processo e Pessoas. Cada 
função ou módulo a ser desenvolvido pela equipe do projeto deve passar pelas várias atividades 
7 
 
 
 
definidas no processo de software. Essa pode ser uma base bastante efetiva para a elaboração de 
estimativas, incluindo a alocação de recursos, já que é sempre mais fácil estimar porções menores de 
trabalho. 
3.1 Atividades Típicas da Gerência de Projetos: 
A gerência de projetos envolve a realização de diversas atividades, abaixo relacionadas: 
• Determinação do escopodo software; 
• Definição do processo de software do projeto; 
• Realização de estimativas; 
• Estimativa de tamanho; 
• Estimativa de esforço; 
• Estimativa (alocação) de recursos; 
• Estimativa de tempo (elaboração do cronograma do projeto); 
• Estimativa de custos; 
• Gerência de riscos; 
• Elaboração do plano de projeto. 
3.2 O Planejamento e o Acompanhamento do Projeto 
As atividades acima relacionadas são realizadas diversas vezes ao longo do projeto. Tipicamente, no 
início do projeto, elas têm de ser realizadas para produzir uma primeira visão gerencial sobre o projeto, 
quando são conjuntamente denominadas de planejamento do projeto. À medida que o projeto avança, 
contudo, o plano do projeto deve ser revisto, uma vez que problemas podem surgir ou porque se ganha 
um maior entendimento sobre o problema. 
Essas revisões do plano de projeto são ditas atividades de acompanhamento do projeto e tipicamente 
são realizadas nos marcos do projeto. O marcos de um projeto é estabelecido durante a definição do 
processo e tipicamente correspondem ao término de atividades importantes do processo de 
desenvolvimento, tais como análise e especificação de requisitos, projeto e implementação. O propósito 
de um marco é garantir que os interessados tenham uma visão do andamento do projeto e concordem 
com os rumos a serem tomados. 
Em uma atividade de acompanhamento do projeto, o escopo pode ser revisto, alterações no processo 
podem ser necessárias, bem como devem ser monitorados os riscos e revisadas as estimativas (de 
tamanho, esforço, tempo e custo). 
3.3 Estimativas 
Antes mesmo de serem iniciadas as atividades técnicas de um projeto, o gerente e a equipe de 
desenvolvimento devem estimar o trabalho a ser realizado, os recursos necessários, o tempo de 
duração e, por fim, o custo do projeto. Apesar das estimativas serem um pouco de arte e um pouco de 
ciência, esta importante atividade não deve ser conduzida de forma desordenada. As estimativas podem 
ser consideradas a fundação para todas as outras atividades de planejamento de projeto. Para alcançar 
boas estimativas de prazo, esforço e custo, existem algumas opções: 
• Postergar as estimativas até o mais tarde possível no projeto; 
• Usar técnicas de decomposição; 
• Usar um ou mais modelos empíricos para estimativas de custo e esforço; 
• Basear as estimativas em projetos similares que já tenham sido concluídos. 
8 
 
 
 
A primeira opção, apesar de ser atraente, não é prática, pois estimativas devem ser providas logo no 
início do projeto (fase de planejamento do projeto). No entanto, deve-se reconhecer que quanto mais 
tarde for feita a estimativa, maior o conhecimento do projeto e menores as chances de se cometer 
erros. Assim, é fundamental revisar as estimativas na medida em que o projeto avança (atividades de 
acompanhamento do projeto). 
Técnicas de decomposição, a segunda opção, usam, conforme discutido anteriormente, a abordagem 
“dividir para conquistar” na realização de estimativas, através da decomposição do projeto em módulos 
/ funções (decomposição do produto) e atividades mais importantes (decomposição do processo). 
Modelos empíricos, tipicamente, usam fórmulas matemáticas, derivadas em experimentos, para prever 
esforço como uma função de tamanho (linhas de código ou pontos de função). Entretanto, deve-se 
observar que os dados empíricos que suportam a maioria desses modelos são derivados de um conjunto 
limitado de projetos. Além disso, fatores culturais da organização não são considerados no uso de 
modelos empíricos, pois os projetos que constituem a base de dados do modelo são externos à 
organização. Apesar de suas limitações, modelos empíricos podem ser úteis como um ponto de partida 
para organizações que ainda não têm dados históricos, até que a organização possa estabelecer suas 
próprias correlações. 
Finalmente, na última opção, dados de projetos anteriores armazenados em um repositório de 
experiências da organização podem prover uma perspectiva histórica importante e ser uma boa fonte 
para estimativas. Através de mecanismos de busca, é possível recuperar projetos similares, suas 
estimativas e lições aprendidas, que podem ajudar a elaborar estimativas mais precisas. Nesta 
abordagem, os fatores culturais são considerados, pois os projetos foram desenvolvidos na própria 
organização. 
Vale frisar que essas abordagens não são excludentes; muito pelo contrário. O objetivo é ter várias 
formas para realizar estimativas e usar seus resultados para se chegar a estimativas mais precisas. 
Quando se fala em estimativas, está-se tratando na realidade de diversos tipos de estimativas: tamanho, 
esforço, recursos, tempo e custos. Geralmente, a realização de estimativas começa pelas estimativas de 
tamanho. A partir delas, estima-se o esforço necessário e, na seqüência, alocam-se os recursos 
necessários, elabora-se o cronograma do projeto (estimativas de tempo) e, por fim, estima-se o custo do 
projeto. 
4. Gerência da Qualidade 
4.1 Documentação 
A documentação produzida em um projeto de software é de suma importância para se gerenciar a 
qualidade, tanto do produto sendo produzido, quanto do processo usado para seu desenvolvimento. 
No desenvolvimento de software, são produzidos diversos documentos, dentre eles, documentos 
descrevendo processos (plano de projeto, plano de qualidade etc.), registrando requisitos e modelos do 
sistema (documentos de especificação de requisitos, análise e projeto) e apoiando o uso do sistema 
gerado (manual do usuário, ajuda on-line, tutoriais etc.). 
Uma documentação de qualidade propicia uma maior organização durante o desenvolvimento de um 
sistema, facilitando modificações e futuras manutenções no mesmo. Além disso, reduz o impacto da 
perda de membros da equipe, reduz o tempo de desenvolvimento de fases posteriores, reduz o tempo 
de manutenção e contribui para redução de erros, aumentando assim, a qualidade do processo e do 
produto gerado. Dessa forma, a criação da documentação é tão importante quanto à criação do 
9 
 
 
 
software em si. Há, portanto, a necessidade de se definir um processo para controlar a documentação 
de uma organização, dito processo de documentação, incluindo atividades de planejamento, análise, 
aprovação ou reprovação, identificação de alterações, situação da revisão atual, disponibilidade das 
versões pertinentes de documentos aplicáveis, dentre outras. Algumas dessas atividades estão 
relacionadas com o controle e a garantia da qualidade de software, outras com a gerência da 
configuração do software. 
É importante notar que o planejamento da documentação tem uma estreita relação com o processo de 
software definido para o projeto. Ou seja, os documentos a serem gerenciados são aqueles previstos 
como saídas das atividades do processo. Assim, tendo sido definido o processo do projeto, o 
planejamento da sua documentação consiste apenas em selecionar quais artefatos, dentre os muitos 
produzidos ao longo do processo, serão efetivamente submetidos à gerência de configuração de 
software e ao controle e garantia da qualidade. 
4.2 Controle e Garantia da Qualidade 
Durante o processo de desenvolvimento de software, ocorrem enganos, interpretações errôneas e 
outras faltas (defeitos ou erros), principalmente provocados por problemas na comunicação e 
transformação da informação, que podem resultar em mau funcionamento do sistema produzido. 
Assim, é muito importante detectar esses defeitos o quanto antes, preferencialmente na atividade em 
que foi cometido, como forma de diminuir retrabalho e, por conseguinte, custos de alterações. As 
atividades que se preocupam com essa questão são coletivamente denominadas atividades de garantia 
da qualidade de software e devem ser realizadas ao longo de todo o processo de desenvolvimento de 
software. 
Dentre as atividades de controle e garantia da qualidade estão as atividades de verificação, validação e 
testes.O objetivo da verificação é assegurar que o software esteja sendo construído de forma correta. 
Deve-se verificar se os artefatos produzidos atendem aos requisitos estabelecidos e se os padrões 
organizacionais (de produto e processo) foram consistentemente aplicados. Por outro lado, o objetivo 
da validação é assegurar que o software que está sendo desenvolvido é o software correto, ou seja, se 
os requisitos e o software dele derivado atendem ao uso específico proposto. Por fim, os testes de 
software são atividades de validação e verificação que consistem da análise dinâmica do mesmo, isto é, 
envolvem a execução do produto de software. 
Uma vez que as atividades de verificação, validação e teste são tão importantes, elas devem ser 
cuidadosamente planejadas, dando origem a um plano de garantia da qualidade. Os artefatos que 
compõem a documentação do projeto são as entradas (insumos) para as atividades de garantia da 
qualidade, quando os mesmos são verificados quanto à aderência em relação aos padrões de 
documentação da organização e validados em relação aos seus propósitos e aos requisitos que se 
propõem a atender. Assim, uma questão imprescindível para a gerência da qualidade é a definição de 
padrões organizacionais. 
4.3 Padrões Organizacionais 
Uma vez que a gerência da qualidade envolve tanto a qualidade do processo quanto a qualidade do 
produto, devem ser estabelecidos padrões organizacionais de produto e de processo. Os padrões de 
processo são os ditos processos padrão ou processos padrão especializados. 
Os padrões de produto, por sua vez, são padrões que se aplicam a artefatos produzidos ao longo do 
processo de software. Podem ser, dentre outros, modelos de documentos, roteiros e normas, 
dependendo do artefato a que se aplicam. 
10 
 
 
 
Um modelo de documento define a estrutura (seções, subseções, informações de cabeçalho e rodapé 
de página etc.), o estilo (tamanho e tipos de fonte, cores etc.) e o conteúdo esperado para documentos 
de um tipo específico. Documentos tais como plano de projeto, especificação de requisitos e 
especificação de projeto devem ter modelos de documentos específicos associados. Documentos 
padronizados são importantes, pois facilitam a leitura e a compreensão, uma vez que os profissionais 
envolvidos estão familiarizados com seu formato. 
Quando não é possível ou desejável estabelecer uma estrutura rígida como um modelo de documento, 
roteiros dando diretrizes gerais para a elaboração de um artefato devem ser providos. Em situações 
onde não é possível definir uma estrutura, tal como no código-fonte, normas devem ser providas. Assim, 
tomando o exemplo do código-fonte, é extremamente pertinente a definição de um padrão de 
codificação, indicando nomes de variáveis válidos, estilos de endentação, regras para comentários etc. 
Padrões organizacionais, sejam de processo sejam de produto, são muito importantes, pois eles 
fornecem um meio de capturar as melhores práticas de uma organização e facilitam a realização de 
atividades de avaliação da qualidade, que podem ser dirigidas pela avaliação da conformidade em 
relação ao padrão. Além disso, sendo organizacionais, todos os membros da organização tendem a estar 
familiarizados com os mesmos, facilitando a manutenção dos artefatos ou a substituição de pessoas no 
decorrer do projeto. Para aqueles artefatos tidos como os mais importantes no planejamento da 
documentação, é saudável que haja um padrão organizacional associado. 
Dada a importância de padrões organizacionais, eles devem ser elaborados com bastante cuidado. Uma 
boa prática, conforme já sugerido para a definição de processos padrão, consiste em usar como base 
padrões gerais propostos por instituições nacionais ou internacionais voltadas para a área de qualidade 
de software. 
4.4 Revisões 
Para se controlar a qualidade em um projeto de software, uma abordagem bastante usada consiste em 
se realizar revisões. Nas revisões, processos, documentos e outros artefatos são revisados por um grupo 
de pessoas, com o objetivo de verificar se os mesmos estão em conformidade com os padrões 
organizacionais estabelecidos e se o propósito de cada um deles está sendo atingido, incluindo o 
atendimento a requisitos do cliente e usuários. Assim, o objetivo de uma revisão é detectar erros e 
inconsistências em artefatos e processos, sejam eles relacionados à forma, sejam em relação ao 
conteúdo, e apontá-los aos responsáveis pela sua elaboração. 
O processo de revisão começa com o planejamento da revisão, quando uma equipe de revisão é 
formada, tendo à frente um líder. A equipe de revisão deve incluir os membros da equipe que possam 
efetivamente úteis para atingir o objetivo da revisão. Muitas vezes, a pessoa responsável pela 
elaboração do artefato a ser revisado integra a equipe de revisão. 
Dando início ao processo de revisão propriamente dito, normalmente, o autor do artefato apresenta o 
mesmo e descreve a perspectiva utilizada para a sua construção. Além disso, o propósito da revisão 
deve ser previamente informado e o material a ser revisado deve ser entregue com antecedência para 
que cada membro da equipe de revisão possa avaliá-lo. Uma vez que todos estejam preparados, uma 
reunião é convocada pelo líder. Essa reunião deverá ser relativamente breve (duas horas, no máximo), 
uma vez que todos já estão preparados para a mesma. Durante a reunião, o líder orientará o processo 
de revisão, passando por todos os aspectos relevantes a serem revistos. Todas as considerações dos 
demais membros da equipe de revisão devem ser discutidas e as decisões registradas, dando origem a 
uma ata de reunião de revisão, contendo uma lista de defeitos encontrados. 
11 
 
 
 
4.5 Gerência de Configuração 
Durante o processo de desenvolvimento de software, vários artefatos são produzidos e alterados 
constantemente, evoluindo até que seus propósitos fundamentais sejam atendidos. 
Ferramentas de software, tais como compiladores e editores de texto, e processos também podem ser 
substituídos por versões mais recentes ou mesmo por outras, no caso de ferramentas. Porém, caso 
essas mudanças não sejam devidamente documentadas e comunicadas, poderão acarretar diversos 
problemas, tais como: dois ou mais desenvolvedores podem estar alterando um mesmo artefato ao 
mesmo tempo; não se saber qual a versão mais atual de um artefato; não se refletir alterações nos 
artefatos impactados por um artefato em alteração. Esses problemas podem gerar vários transtornos 
como incompatibilidade entre os grupos de desenvolvimento, inconsistências, retrabalho, atraso na 
entrega e insatisfação do cliente. Assim, para que esses transtornos sejam evitados, é de suma 
importância o acompanhamento e o controle de artefatos, processos e ferramentas, através de um 
processo de gerência de configuração de software, durante todo o ciclo de vida do software. 
A gerência de configuração de software visa estabelecer e manter a integridade dos itens de software 
ao longo de todo o ciclo de vida do software, garantindo a completeza, a consistência e a correção de 
tais itens, e controlando o armazenamento, a manipulação e a distribuição dos mesmos. Para tal, tem 
de identificar e documentar os produtos de trabalho que podem ser modificados, estabelecer as 
relações entre eles e os mecanismos para administrar suas diferentes versões, controlar modificações e 
permitir auditoria e a elaboração de relatórios sobre o estado de configuração. 
Pelos objetivos da gerência de configuração de software, pode-se notar que ela está diretamente 
relacionada com as atividades de garantia da qualidade de software. 
As atividades da gerência de configuração de software podem ser resumidas em: 
• Planejamento: Um plano deve ser elaborado descrevendo as atividades da gerência de 
configuração, procedimentos e responsáveis pela execução dessas atividades. 
• Identificação da configuração: Refere-se à identificação dos itens desoftware e suas versões a 
serem controladas, estabelecendo linhas básicas. 
• Controle de versão: Combina procedimentos e ferramentas para administrar diferentes versões 
dos itens de configuração criados durante o processo de software. 
• Controle de modificação: Combina procedimentos humanos e ferramentas automatizadas para 
controlar as alterações feitas em itens de software. Para tal, o seguinte processo é 
normalmente realizado: solicitação de mudança, aprovação ou rejeição da solicitação, registro 
de retirada para alteração (check-out), análise, avaliação e realização das alterações, revisão e 
registro da realização das alterações (check-in). 
• Auditoria de configuração: Visa avaliar um item de configuração quanto a características não 
consideradas nas revisões, tal como se os itens relacionados aos solicitados foram devidamente 
atualizados. 
• Relato da situação da configuração: Refere-se à preparação de relatórios que mostrem a 
situação e o histórico dos itens de software controlados. Tais relatórios podem incluir, dentre 
outros, o número de alterações nos itens, as últimas versões dos mesmos e identificadores de 
liberação. 
5. Levantamento/Análise de Requisitos 
Uma das principais medidas do sucesso de um software é o grau no qual ele atende aos objetivos e 
requisitos para os quais foi construído. De forma geral, a engenharia de requisitos de software é o 
processo de identificar todos os envolvidos, descobrir seus objetivos e necessidades e documentá-los de 
12 
 
 
 
forma apropriada para análise, comunicação e posterior desenvolvimento. Abaixo segue algumas 
características do levantamento de requisitos: 
• Entendimento do domínio da aplicação: Significa conhecer a área onde o sistema é aplicado de 
uma forma geral. Este entendimento exige conhecimentos gerais sobre a aplicação em 
questão. Por exemplo, se o sistema será aplicado numa área de seguros de automóveis, então 
devemos obter conhecimentos gerais sobre sinistros, apólices de seguro, mercado de 
automóveis etc. 
• Entendimento do problema: Significa conhecer os detalhes específicos do problema de um 
cliente em particular. Por exemplo, para um sistema de seguros de automóveis que será 
desenvolvido especificamente para um cliente, o entendimento do problema envolve conhecer 
como é o processo de atendimento ao cliente quando ocorre um sinistro, como ocorrerá o 
pagamento do conserto do automóvel do cliente, com quais oficinas a seguradora trabalha etc. 
• Entendimento do negócio: Normalmente sistemas contribuem de alguma forma com os 
objetivos e missão da organização onde ele está inserido. O entendimento do negócio significa 
conhecer como o sistema a ser desenvolvido interage e afeta os negócios da organização, e que 
tipo de contribuição ele irá proporcionar. 
• Entendimento das necessidades e restrições das pessoas envolvidas no sistema: Para 
obtermos este tipo de entendimento, é necessário conhecermos os processos que o sistema 
deverá suportar. Estes processos são realizados pelas pessoas envolvidas no sistema. 
5.1 Requisito e Tipos de Requisitos 
As descrições das funções que um sistema deve incorporar e das restrições que devem ser satisfeitas 
são os requisitos para o sistema. Isto é, os requisitos de um sistema definem o que o sistema deve fazer 
e as circunstâncias sob as quais deve operar. Em outras palavras, os requisitos definem os serviços que o 
sistema deve fornecer e dispõem sobre as restrições à operação do mesmo. 
Requisitos são, normalmente, classificados em requisitos funcionais e não funcionais. Requisitos 
funcionais, como o próprio nome indica, apontam as funções que o sistema deve fornecer e como o 
sistema deve se comportar em determinadas situações. Já os requisitos não funcionais descrevem 
restrições sobre as funções oferecidas, tais como restrições de tempo, de uso de recursos etc. Alguns 
requisitos não funcionais dizem respeito ao sistema como um todo e não a funcionalidade específica. 
Dependendo da natureza, os requisitos não funcionais podem ser classificados de diferentes maneiras, 
tais como requisitos de desempenho, requisitos de portabilidade, requisitos legais, requisitos de 
conformidade etc. 
5.2 O Processo da Engenharia de Requisitos 
O processo de descobrir, analisar, documentar e verificar/validar requisitos é chamado de processo de 
engenharia de requisitos. Os processos de engenharia de requisitos variam muito de uma organização 
para outra, mas, de maneira geral, a maioria dos processos de engenharia de requisitos é composta das 
seguintes atividades: 
• Elicitação/Descoberta/Levantamento de Requisitos: Nesta fase, os usuários, clientes e 
especialistas de domínio são identificados e trabalham junto com os engenheiros de requisitos 
para descobrir, articular e entender a organização como um todo, o domínio da aplicação, os 
processos de negócio específicos, as necessidades que o software deve atender e os problemas 
e deficiências dos sistemas atuais. Os diferentes pontos de vista dos participantes do processo, 
bem como as oportunidades e restrições existentes, os problemas a serem resolvidos, o 
desempenho requerido e as restrições também devem ser levantados. 
13 
 
 
 
• Análise de Requisitos: Visa a estabelecer um conjunto acordado de requisitos consistentes e 
sem ambigüidades, que possa ser usado como base para o desenvolvimento do software. Para 
tal, diversos tipos de modelos são construídos. Geralmente, a análise de requisitos inclui 
também a negociação para resolver conflitos detectados. 
• Documentação de Requisitos: É a atividade de representar os resultados da engenharia de 
requisitos em um documento, contendo os requisitos do software. 
• Verificação e Validação de Requisitos: A verificação de requisitos avalia se o documento de 
especificação de requisitos está sendo construído de forma correta, de acordo com padrões 
previamente definidos, sem conter requisitos ambíguos, incompletos ou, ainda, requisitos 
incoerentes ou impossíveis de serem testados. Já a validação diz respeito a avaliar se esse 
documento está correto, ou seja, se os requisitos e modelos documentados atendem às reais 
necessidades e requisitos dos usuários/cliente. 
• Gerência de Requisitos: Se preocupa em gerenciar as mudanças nos requisitos já acordados, 
manter uma trilha dessas mudanças, gerenciar os relacionamentos entre os requisitos e as 
dependências entre o documento de requisitos e os demais artefatos produzidos no processo 
de software, de forma a garantir que mudanças nos requisitos sejam feitas de maneira 
controlada e documentada. 
É possível notar que, das cinco atividades do processo de engenharia de requisitos anteriormente 
listadas, as três últimas são, na realidade, instanciações para a engenharia de requisitos de atividades 
genéricas já discutidas anteriormente, a saber: documentação, garantia da qualidade e gerência de 
configuração. Assim sendo, somente as duas primeiras atividades (Levantamento e Análise de 
Requisitos) são discutidas. 
5.3 Levantamento de Requisitos 
O levantamento de requisitos é uma atividade complexa que não se resume somente a perguntar às 
pessoas o que elas desejam e também não é uma simples transferência de conhecimento. Várias 
técnicas de levantamento de requisitos são normalmente empregadas pelos engenheiros de requisitos 
(ou analistas de sistemas), dentre elas entrevistas, questionários, prototipação, investigação de 
documentos, observação, dinâmicas de grupo etc. 
Um requisito é uma característica de um projeto, uma propriedade ou um comportamento de um 
sistema. Ao estabelecer os requisitos do sistema, você esta declarando um contrato, estabelecido entre 
as coisas externas ao sistema e o próprio sistema, declarando o que se espera que seja feito pelo 
sistema. 
5.4 Análise de Requisitos 
A análise de requisitos (muitas vezes chamada análise de sistemas) é, em última instância, uma 
atividade de construção de modelos.Um modelo é uma representação de alguma coisa do mundo real, 
uma abstração da realidade, e, portanto, representa uma seleção de características do mundo real 
relevantes para o propósito do sistema em questão. Modelos são fundamentais no desenvolvimento de 
sistemas. Tipicamente eles são construídos para: 
• Possibilitar o estudo do comportamento do sistema; 
• Facilitar a comunicação entre os componentes da equipe de desenvolvimento, clientes e 
usuários; 
• Possibilitar a discussão de correções e modificações com o usuário; 
• Formar a documentação do sistema. 
14 
 
 
 
Um modelo enfatiza um conjunto de características da realidade, que corresponde à dimensão do 
modelo. Além da dimensão que um modelo enfatiza, modelos possuem níveis de abstração. O nível de 
abstração de um modelo diz respeito ao grau de detalhamento com que as características do sistema 
são representadas. Em cada nível há uma ênfase seletiva nos detalhes representados. No caso do 
desenvolvimento de sistemas, geralmente, são considerados três níveis: 
• Conceitual: Considera características do sistema independentes do ambiente computacional 
(hardware e software) no qual o sistema será implementado. Essas características são 
dependentes unicamente das necessidades do usuário. Modelos conceituais são construídos na 
atividade de análise de requisitos. 
• Lógico: Características dependentes de um determinado tipo de sistema computacional. Essas 
características são, contudo, independentes de produtos específicos. Tais modelos são típicos 
da fase de projeto. 
• Físico: Características dependentes de um sistema computacional específico, isto é, uma 
linguagem e um compilador específico, um sistema gerenciador de bancos de dados específico, 
o hardware de um determinado fabricante etc. Tais modelos podem ser construídos tanto na 
fase de projeto quanto na fase de implementação. 
Conforme apontado acima, nas primeiras etapas do processo de desenvolvimento (levantamento de 
requisitos e análise), o engenheiro de software representa o sistema através de modelos conceituais. 
Nas etapas posteriores, as características lógicas e físicas são representadas em novos modelos. 
Para a realização da atividade de análise, uma escolha deve ser feita: o paradigma de desenvolvimento. 
Paradigmas de desenvolvimento estabelecem a forma de se ver o mundo e, portanto, definem as 
características básicas dos modelos a serem construídos. Por exemplo, o paradigma orientado a objetos 
parte do pressuposto que o mundo é povoado por objetos, ou seja, a abstração básica para se 
representar as coisas do mundo são os objetos. Já o paradigma estruturado adota uma visão de 
desenvolvimento baseada em um modelo entrada-processamento-saída. No paradigma estruturado, os 
dados são considerados separadamente das funções que os transformam e a decomposição funcional é 
usada intensamente. 
Exercício: 
Desenvolver a análise preliminar do sistema agenda. 
5.5 Especificação da Lógica dos Processos 
A especificação dos processos, por conseguinte, não é apenas um levantamento descritivo de formatos 
e nomes. Ao contrário, depende de compreender e relatar claramente os mecanismos internos de 
funcionamento da atividade. A atenção nesta tarefa é crítica, pois, a partir dela, em etapas posteriores, 
serão descritos os programas de computador que automatizarão o processo. Especificações 
incompletas, incorretas ou confusas vão comprometer a programação e, naturalmente, provocar erros 
nos sistema. 
A maior dificuldade para especificar a lógica dos processos, além da sua natural complexidade, é a 
própria ambigüidade da língua portuguesa que permite milhares de construções diferentes para o 
mesmo assunto. Essa característica contribui para que se evite a descrição da lógica em linguagem 
natural. Foi necessário, portanto, criar uma linguagem alternativa para substituir o português. 
A primeira preocupação para descrever a lógica de um processo é procurar entender os passos 
seqüenciais de sua construção. A lógica de um processo baseia-se em dois princípios: relacionar todas as 
instruções necessárias para executar o processo e colocá-las (as instruções) na ordem correta. 
15 
 
 
 
6. Modelo Entidade-Relacionamento 
Este capítulo descreve e ilustra o uso do modelo entidade-relacionamento (MER), que foi apresentado 
por Peter Cher em 1976. Hoje não existe um padrão único de modelo E-R aceito universamente, em vez 
disto, há um conjunto de conceitos dos quais se origina a maioria das variantes do E-R. No MER, os 
elementos que o compõe são representados graficamente através da ferramenta denominada diagrama 
entidade-relacionamento (DER). A seguir são descritos os principais elementos que compõe o MER. 
6.1 Entidades 
Define-se entidade como aquele objeto que existe no mundo real com uma identificação distinta e com 
um significado próprio. São as coisas que existem no negócio, ou ainda, descrevem o negócio. 
Se alguma coisa existente no negócio e nos proporciona algum interesse em mantermos informações, 
esta a caracteriza como uma entidade do negócio. 
Alguns exemplos de entidades: 
• O FUNCIONÁRIO João; 
• O VEICULO Corsa; 
• A ALUNA Maria; 
• O CLIENTE Pedro; 
• O PRODUTO A323... 
Entidades de um mesmo tipo são agrupadas em classes de entidade. Assim, a classe de entidades 
funcionário é o conjunto de todas as instâncias de funcionários. Neste texto, classes de entidades estão 
impressas em letra maiúscula. Cada ocorrência de um funcionário dentro da classe funcionário é 
denominada instância de entidade. A representação gráfica de uma entidade no MER se realiza através 
de um retângulo, com o nome desta entidade em seu interior, como mostra a figura abaixo. 
 
Importante: As instâncias de uma entidade não são representadas no DER. 
6.2 Atributos 
Toda entidade possui propriedade que são descritas por atributos. No MER supõe que todas as 
instâncias de uma dada classe de entidade possuem os mesmos atributos. Considere a entidade 
funcionário de uma empresa, o funcionário é descrito por: 
• Número de matrícula; 
• Nome; 
• Data da admissão... 
Como é representado na tabela abaixo: 
MATRÍCULA NOME DATA ADMISSÃO 
10011 João 10/01/2009 
10012 Maria 11/02/2009 
10013 Manoel 01/06/2008 
 
FUNCIONARIO VEICULO ALUNO CLIENTE PRODUTO 
16 
 
 
 
7. Dicionário de Dados 
O dicionário de dados pode ser visto como um depósito central que descreve e define o significado de 
toda a informação usada na construção de um sistema. O conteúdo de um dicionário de dados é 
composto pela: 
• Especificação dos fluxos de dados; 
• Especificação de arquivos; 
• Especificação de processos; 
• O seu conteúdo deve ser preciso, conciso e não redundante; 
 Cada ocorrência deve contemplar, pelo menos, os seguintes aspectos: 
• Nome; 
• Tipo; 
• Descrição, conjunto de dados que caracterizam o campo; 
• Pseudônimos (outros nomes possíveis); 
• Especificação; 
• Comentários significativos, que poderão incluir volume, freqüência, política de partilha e 
segurança dos dados. 
Junto com o modelo de entidade e relacionamento, é necessário que se mantenha um documento com 
a explicação de todos os objetos nele criados. Este documento, que pode ser chamado de dicionário de 
dados, permite que os analistas obtenham informações sobre todos os objetos do modelo de forma 
textual, contendo explicações por vezes difíceis de incluir no diagrama. É válido lembrar que o objetivo 
do documento é ser claro e consistente. 
8. UML 
A UML (Unified Modeling Language) é uma linguagem padrão para a elaboração da estrutura de 
projetos de software. A UML poderá ser empregada para a visualização, a especificação, a construção e 
a documentação de artefatos que façam uso de sistemas complexos de software. 
A UML é adequada para a modelagem de sistemas, cuja abrangência poderá incluir desde sistemas de 
informação corporativos a serem distribuídos a aplicações baseadas em Web e até sistemas complexosembutidos de tempo real. É uma linguagem muito expressiva, abrangendo todas as visões necessárias 
ao desenvolvimento e implantação desses sistemas. 
A UML é apenas uma linguagem para especificação, construção e documentação de artefatos de 
software e, portanto, é somente uma parte de um método para desenvolvimento de software. 
 A UML é uma linguagem destinada a: 
• Ajudar a conceber nossas idéias, em relação ao sistema que estivermos projetando; 
• Pensar antes de codificar; 
• Apresentar nossas idéias ao grupo de forma que todos possam interagir e discutir um 
determinado ponto; 
• Aumentar a participação e envolvimento do time (grupo); 
• Documentar nossas idéias quando elas já estiverem bem consolidadas para que novos 
integrantes e novos colaboradores possam acelerar sua compreensão dos sistemas 
desenvolvidos pelo grupo 
17 
 
 
 
A UML é um padrão para desenvolvimento de software que reúne melhores práticas de metodologia de 
sistemas. Diversos diagramas auxiliam na visualização do problema e a concepção da solução, 
permitindo uma visão macro dos objetos e seus relacionamentos; 
É uma linguagem visual para especificação (modelagem) de sistemas orientados a objetos, fornece 
representação gráfica para os elementos essenciais do paradigma de objetos como classes, atributos, 
objetos, troca de mensagens, etc. Grandes sistemas necessitam de uma série de especificações e 
geralmente tais documentos são longos e muito detalhados. A modelagem proporcionada pela UML 
permite simplificar o entendimento de um sistema, ao transformar suas complexidades em objetos 
gráficos simples, onde a lógica interna de seu funcionamento é abstraída. 
A manutenção que ocorrer nos posteriores ciclos de desenvolvimento fica mais fácil de ser efetuada já 
que a mesma ocorre inicialmente num nível lógico, e não no código (programa), de forma que se pode 
evoluir os diagramas que serão alterados e verificar suas conseqüências, antes de se preocupar com a 
fase de desenvolvimento. 
Algumas das diferentes formas de representação dos processos são citadas abaixo: 
• Diagrama de Casos de Uso 
• Descrição de Casos de Uso 
• Diagrama de Classes 
• Diagrama de Objetos 
• Diagrama de Seqüência 
• Diagrama de Colaboração 
• Diagrama de Estados 
• Diagrama de Atividades 
• Diagrama de Componentes 
• Diagrama de Implantação 
8.1 Diagrama de Casos de Uso 
Modelo gráfico que agrupa determinados casos de usos e atores de um determinado sistema, de forma 
a visualizar-se de maneira rápida e fácil o relacionamento entre eles, servindo de documento para 
comunicação entre os participantes do projeto. 
Aplica-se os diagramas de casos de uso na modelagem da visão de caso de uso do sistema. Na maior 
parte, isso envolve a modelagem dos requisitos do comportamento dos elementos. Esses diagramas 
fazem com que sistemas, subsistemas e classes fiquem acessíveis e compreensíveis, por apresentarem 
uma visão externa sobre como esses elementos podem ser utilizados no contexto. 
• Tem o objetivo de auxiliar a comunicação entre os analistas e o cliente. 
• Descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. 
• O cliente deve ver no diagrama de casos de uso as principais funcionalidades de seu sistema. 
• Basicamente é composto por: 
o Atores: Pessoas que desempenham algum papel no sistema, entidades externas, como 
outros sistemas, que interagem com o sistema sendo projetado; 
o Casos de Uso: Processos ou funções que o sistema deve realizar de forma automática 
ou mesmo manual, geralmente associada a descrições textuais; 
o Relacionamentos: De dependência, generalização e associação. 
Técnicas básicas de modelagem: 
18 
 
 
 
• Identifique os atores que se encontram ao redor do sistema, considerando quais grupos 
precisam de ajuda do sistema para a realização de suas tarefas; quais grupos são necessários 
para a execução de funções do sistema; quais grupos interagem com algum hardware externo 
ou outros sistemas de software; e quais grupos realizam funções secundárias de administração 
e de manutenção; 
• Organize os atores semelhantes em uma hierarquia de generalização/especificação; 
• Ofereça um estereótipo para cada ator, para ajudar a compreensão; 
• Preencha um diagrama de caso de uso com esses atores e especifique os caminhos de 
comunicação de cada ator até os casos de uso do sistema. 
O include é usado para representar sub-fluxos complexos e comuns a vários casos de uso, sempre 
usados, isto é, necessários. O caso de uso "incluído" é referenciado no fluxo do caso de uso "incluidor". 
Imagine isso como uma situação que ocorre sempre quando uma outra situação também ocorre. O caso 
de uso A inclui o caso de uso B quando B representa uma atividade complexa, comum á vários casos de 
uso. 
O extends é usado para representar sub-fluxos complexos e comuns a vários casos de uso, usados 
eventualmente, isto é, facultativos. Na prática o caso de uso "estendido" é referenciado no fluxo do caso 
de uso "principal". Imagine isso como uma situação que pode ocorrer quando outra situação também 
ocorre. O caso de uso B estende o caso de uso A, apenas quando necessário. 
Exercício: 
Desenvolver diagrama de caso de uso para o sistema agenda. 
8.2 Descrição de caso de uso 
É uma descrição textual completa de um determinado processo, identificando seu cenário principal, isto 
é, o fluxo normal que ocorreria normalmente. Este documento é estruturado descrevendo-se seus 
passos/instruções sem se ater a detalhes de tecnologia, porém identificando o limite/restrição/faixa de 
dados. 
Além disto, identificamos o(s) ator(es) que interage(m) com o sistema, as exceções (fluxos/cenários 
alternativos) também são explicadas porém a ênfase é dada no fluxo principal. 
Abaixo segue as descrições de caso de uso para o sistema agenda: 
FACULDADE DOM BOSCO 
CURSO E.S. 
 
AGENDA 
MANTER CONTATO 
 
Nome do Caso de Uso Manter Contato. 
Descrição 
Este caso de uso tem como objetivo documentar e especificar os processos de cadastro e manutenção de 
contatos para o sistema de agenda. 
Ator envolvido Administrador (adm) e Usuário (user). 
Ativação 
Este caso de uso se iniciará após um dos atores acessarem através do menu principal a opção de adicionar um 
novo contato. 
19 
 
 
 
Ou, através da interface de pesquisa de contatos, acessando a opção editar contato. 
Pré-requisito 
� O ator deverá estar logado no sistema; 
� O ator deverá possuir acesso a interface; 
� Para a situação de edição, o ator deverá realizar uma pesquisa para depois selecionar a opção de 
editar que irá carregar a interface de cadastro. 
Interação 
 O sistema irá carregar a interface de edição/lançamento de contatos conforme processo de 
ativação (ver observação). 
 Para o lançamento/edição de um contato o sistema irá disponibilizar os seguinte campos para 
preenchimento: 
a) (id) Código do contato – Campo obrigatório que servirá para identificar um contato como sendo 
único no sistema, para novos lançamentos o código será gerado automaticamente pelo sistema 
(numérico com precisão de 10 dígitos, auto-incremento); 
b) (name) Nome do contato – Campo obrigatório que referencia o contato a ser cadastrado, será 
utilizado para consultas e interfaces de pesquisa (texto para 100 caracteres); 
c) (address) Endereço – Campo facultativo, informação adicional sobre o contato (texto para 150 
caracteres com auto-redimensionamento); 
d) (city) Cidade – Campo facultativo, para identificar a cidade do contato (código da cidade numérico – 
ver caso de uso Manter cidade); 
e) (personal) Contato Privado – Campo obrigatório, informações adicional sobre o contato, identifica 
se o contato é pessoal ou público, caso seja identificado como público todos os usuários poderão 
visualizá-lo e alterá-lo (booleano – verdadeiro para privado e falso para não privado); 
f) (user) Usuário – Campo obrigatório, para identificar o usuário responsável pelo cadastro da 
informação(código do usuário numérico – ver caso de uso Manter usuário); 
g) (phones) Telefones – Campo facultativo, grade com a identificação dos telefones vinculados ao 
contato, onde poderão ser adicionados novos itens ao contato (dados do telefone – ver caso de uso 
Manter telefone); 
 Para o processo de inclusão/edição de contatos o ator deverá informar todos os campos que 
possuem definição de obrigatório, caso contrário ver EX01. 
 Após o preenchimento dos campos o usuário deverá selecionar a opção salvar, para que o sistema 
atualize as informações, ver EX02. 
Exceções / Fluxos 
Alternativos 
� EX01 – Caso algum campo obrigatório não seja preenchido, o sistema irá disponibilizar uma 
interface que irá avisar o usuário sobre o campo que deve ser preenchido; 
� EX02 – O sistema irá validar os dados (EX01) e irá salvar as informações, caso ocorra algum erro o 
sistema irá disponibilizar uma interface contendo a descrição do erro, ou, irá disponibilizar uma 
interface contendo a confirmação de que as informações foram salvas com sucesso. 
Observações 
 Informações adicionais ao processo de acessar o sistema e de alterar a senha deverão ser 
verificadas no caso de uso Controle de Acesso. 
 Caso o processo de ativação seja através do menu principal, na opção de adicionar um novo 
contato. O sistema irá carregar a interface de cadastro com todos os campos limpos. 
 Caso o processo de ativação seja através da interface de pesquisa, o sistema irá carregar a interface 
com todos os campos preenchidos para edição. 
 
EMPRESA DE DESENVOLVIMENTO 
 
Nome: Nome: 
Assinatura: Assinatura: 
20 
 
 
 
Cargo: Cargo: 
 
Descrição de Caso de Uso Manter Contato do sistema Agenda. 
 
Exercício: 
Desenvolver uma descrição de caso de uso para o sistema agenda. 
8.3 Diagrama de Classes 
Os diagramas de classes são os diagramas encontrados com maior freqüência na modelagem de 
sistemas orientados a objetos. Um diagrama de classe mostra um conjunto de classes, interfaces e 
colaborações e seus relacionamentos. 
Os diagramas de classes são importantes não só para a visualização, a especificação e a documentação 
de modelos estruturais, mas também para a construção de sistemas executáveis por intermédio de 
engenharia de produção e reversa. 
Ao construir uma casa, você começa com um vocabulário que inclui blocos de construção básicos, como 
paredes, piso, janelas, portas, tetos e vigas. Esses itens são amplamente estruturais (as paredes têm 
altura, largura e espessura), mas também são de alguma forma comportamental (tipos diferentes de 
paredes podem suportar diferentes cargas, as portas abrem e fecham, existem restrições em relação ao 
vão de um piso sem suportes). De fato, você não pode considerar essas características estruturais e 
comportamentais de maneira independente. Em vez disso, ao construir sua casa, é necessário 
considerar como estes itens interagem. Assim, o processo de determinar a arquitetura da casa envolve a 
reunião desses itens de uma maneira única e agradável para satisfazer a todos os requisitos funcionais e 
não funcionais. As plantas do projeto que você criar para visualizar sua casa e para especificar detalhes 
destinados aos construtores contratados são, na verdade, apresentações gráficas desses itens e de seus 
relacionamentos. 
A modelagem do vocabulário de um sistema envolve uma decisão a respeito de quais abstrações fazem 
parte do sistema considerado e quais estão fora dos limites do sistema.. 
As relações entre as classes podem ser associações, agregações ou heranças. As classes possuem além 
de um nome possuem atributos e operações. Uma relação indica um tipo de dependência entre as 
classes, essa dependência pode ser forte com no caso da herança ou da agregação ou mais fraca como 
no caso da associação, mas indicam que as classes relacionadas cooperam de alguma forma para 
cumprir um objetivo para o sistema. 
A UML permite diferentes níveis de abstração aos diagramas, dependendo da etapa do 
desenvolvimento do sistema em que se encontram. Assim, os diagramas de classe podem exibir nas 
fases iniciais da análise apenas o nome das classes, e em uma fase seguinte os atributos e operações. 
Finalmente, em uma fase avançada do projeto pode exibir os tipos dos atributos, a visibilidade, a 
multiplicidade das relações e diversas restrições. 
Exercício: 
Desenvolver o diagrama de classes para o sistema agenda. 
21 
 
 
 
8.4 Diagrama de Objetos 
Os diagramas de objetos fazem a modelagem de instâncias de itens contidos em diagramas de classes. 
Um diagrama de objetos mostra um conjunto de objetos e seus relacionamentos em determinado 
ponto no tempo. 
Você usa os diagramas de objetos para fazer a modelagem da visão estática do projeto ou do processo 
de um sistema. Isso envolverá a modelagem de um retrato do sistema em determinado momento e a 
representação de um conjunto de objetos, seus estados e relacionamentos. 
Se tentar traçar o fluxo de controle de um sistema em execução, você logo perderá a visão global a 
respeito do modo como as partes do sistema estão organizadas, principalmente se houver múltiplos 
threads de controle. De maneira semelhante, se você tiver uma estrutura de dados complexa, apenas a 
observação do estado de um único objeto em determinado momento não é de grande ajuda. Em vez 
disso, é necessário estudar um retrato do objeto, seus vizinhos e seus relacionamentos com esses 
vizinhos. Em todos os sistemas orientados a objetos, com exceção dos mais simples, você encontrará 
uma variedade de objetos presentes, cada um com um relacionamento preciso com os demais. De fato, 
quando ocorre uma falha em um sistema orientado a objetos, tipicamente isso não ocorre devido a 
algum erro de lógica, mas por causa de conexões entre objetos interrompidas ou ao estado danificado 
de objetos individuais. 
Um diagrama de objetos é um tipo especial de diagrama e compartilha as mesmas propriedades comuns 
a todos os outros diagramas, ou seja, um nome, relacionamentos e o conteúdo gráfico que formam uma 
projeção em um modelo. 
Exercício: 
Desenvolver um diagrama de objetos para um determinado período do sistema agenda. 
8.5 Diagrama de Seqüência 
O diagrama de seqüência é uma ferramenta que deve ser utilizada sempre em função dos casos de uso. 
Um diagrama de seqüência captura o comportamento de um único caso de uso, ou seja, mostra a 
interação entre os objetos ao longo do tempo, apresentando os objetos que participam da interação e a 
seqüência das mensagens trocadas. 
O diagrama é composto por: 
• Objeto: É uma caixa na parte superior de uma linha tracejada verticalmente. A linha vertical é 
chamada de linha da vida do objeto, e representa a vida do objeto durante a interação. 
• Mensagem: É representada por uma flecha entre as linhas de vida de dois objetos. Cada 
mensagem deve ter um nome, é comum incluir os argumentos e algumas informações de 
controle. 
Veja o exemplo abaixo: 
22 
 
 
 
 
Diagrama de seqüência para o processo de efetuar login no sistema Agenda. 
Exercício: 
Desenvolver um diagrama de seqüência para uma determinada operação do sistema agenda. 
8.6 Diagrama de Colaboração 
Um diagrama de colaboração é um diagrama que dá ênfase à organização estrutural dos objetos que 
enviam e recebem mensagens. Graficamente, um diagrama de colaboração é uma coleção de vértices e 
arcos. 
O diagrama de colaboração é formado colocando primeiramente os objetos que participam da interação 
como os vértices de um gráfico. A seguir, representam os vínculos que conectam esses objetos como os 
arcos do gráfico. Por fim, adorna esses vínculos com as mensagens que os objetos enviam e recebem. 
Isso proporciona ao leitor uma clara indicação visual do fluxo de controle no contexto da organização 
estrutural dos objetos que colaboram. 
 
23 
 
 
 
Diagrama de colaboração para o processo de efetuar login no sistema Agenda. 
Exercício: 
Desenvolver um diagrama de colaboraçãopara uma determinada operação do sistema agenda. 
8.7 Diagramas de Estado 
Em um diagrama de estado, um objeto possui um comportamento e um estado. O estado de um objeto 
depende da atividade na qual ele está processando. Um diagrama de estado mostra os possíveis estados 
de um objeto e as transações responsáveis pelas suas mudanças de estado. 
Um diagrama de estados mostra uma máquina de estados, dando ênfase ao fluxo de controle de um 
estado para outro. Uma máquina de estados é um comportamento que especifica as seqüências de 
estados pelos quais um objeto passa durante seu tempo de vida em resposta a eventos, juntamente 
com suas respostas a esses eventos. Um estado é uma condição ou situação na vida de um objeto 
durante a qual ele satisfaz a alguma condição, realiza alguma atividade ou aguarda algum evento. Um 
evento é uma especificação de uma ocorrência significativa que tem uma localização no tempo e no 
espaço. No contexto de uma máquina de estados, um evento é uma ocorrência de um estímulo capaz de 
ativar uma transição de estados. Uma transição é um relacionamento entre dois estados, indicando que 
um objeto no primeiro estado realizará certas ações e entrará no segundo estado quando um evento 
especificado ocorrer e as condições especificadas estão satisfeitas. Uma atividade é uma execução não 
atômica em andamento em uma máquina de estados. Uma ação é uma computação atômica executável 
que resulta em uma alteração do estado do modelo ou no retorno de um valor. 
 
Diagrama de estados para o jodo de Xadrez. 
Exercício: 
Desenvolver um diagrama de estado para um contato (transição entre público e privado). 
8.8 Diagrama de Atividades 
Um diagrama de atividade é essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma 
atividade para outra. São empregados para fazer a modelagem de aspectos dinâmicos do sistema. Na 
24 
 
 
 
maior parte, isso envolve a modelagem das etapas seqüenciais em um processo computacional. As 
atividades acabam resultando em alguma ação, formada pelas computações atômicas executáveis que 
resultam em uma mudança de estado do sistema ou o retorno de um valor. 
 
Diagrama de atividades para a construção de uma casa. 
Utilizado para descrever a seqüência de atividades, utilizando comportamento condicional e paralelo. É 
composto por: 
• Início (Initial): Representado por um círculo preenchido; 
• Estado de Atividade ou Atividade (Action): Representado por um retângulo com bordas 
arredondadas. Atividade é um estado de estar fazendo algo; 
• Desvio (Decision): Representado por um losango; 
• Intercalação (Merge): Também representado por um losango, é utilizada para marcar o final de 
um comportamento condicional iniciado por um desvio, ou seja, tem múltiplas entradas e uma 
única saída; 
• Separação (Fork): Representado por um traço horizontal, quando temos comportamento 
paralelo, ou seja, temos uma entrada e várias transições de saída que são executadas em 
paralelo; 
• Junção (Joins, Union): Representado por um traço horizontal, utilizamos para completar a 
separação, ou seja, quando temos um processamento paralelo, precisamos sincronizar. 
Exercício: 
Desenvolver um diagrama de atividade para uma determinada operação do sistema agenda. 
8.9 Diagrama de Componentes 
Os diagramas de componentes são empregados para a modelagem a visão estática de implementação 
de um sistema. Isso envolve a modelagem de itens físicos que residem em um nó, como executáveis, 
25 
 
 
 
bibliotecas, tabelas, arquivos e documentos. Os diagramas de componentes são essencialmente 
diagramas de classes que focalizam os componentes de um sistema. 
Você cria diagramas de casos de uso para pensar sobre o comportamento desejado para o sistema. 
Especifica o vocabulário do domínio com diagramas de classes. Cria diagramas de seqüências, diagramas 
de colaboração, diagramas de gráficos de estados e diagramas de atividades para especificar a forma 
como os itens em seu vocabulário trabalharão m conjunto para a execução desse comportamento. 
Eventualmente, você transformará esses projetos lógicos em itens que vivem no mundo dos bits, como 
executáveis, bibliotecas, tabelas, arquivos e documentos. Você concluirá que deve criar alguns desses 
componentes do ponto zero, mas também acabará reutilizando componentes antigos de maneira novas. 
 
Diagrama de componentes para o sistema Agenda. 
Exercício: 
Detalhar utilizando o diagrama de componentes o componente agenda.war. 
8.10 Diagrama de Implantação 
Os diagramas de implantação são um dos dois tipos de diagramas empregados para a modelagem dos 
aspectos físicos de um sistema orientado a objetos. O diagrama de implantação mostra a configuração 
dos nós de processamento em tempo de execução e os componentes que nele existem. 
Na maior parte, isso envolve a modelagem da topologia do hardware em que o sistema é executado. Os 
diagramas de implantação são essencialmente diagramas de classes que focalizam os nós do sistema. 
Ao criar um sistema complexo de software seu foco principal como desenvolvedor de software esta na 
arquitetura e implantação do software. Entretanto, como um engenheiro de sistemas, seu foco principal 
está no hardware e no software do sistema e no gerenciamento doa compatibilidade dos dois. 
A UML focaliza primariamente as facilidades para visualização, especificação, construção e 
documentação de artefatos de software, mas também se destina a abranger artefatos de hardware. Isso 
não significa que a UML seja uma linguagem de propósito geral para descrição de hardware. Em vez 
disso, a UML se destina a fazer a modelagem de muitos aspectos de hardware para um sistema, 
suficientes para que o engenheiro de software especifique a plataforma em que o software do sistema é 
executado e para que o engenheiro de sistemas gerencie a fronteira entre o hardware e o software do 
sistema. 
Os diagramas de implantação é um diagrama que mostra a configuração de nós de processamento em 
tempo de execução e os componentes que neles existem. 
26 
 
 
 
 
Diagrama de implantação para o sistema Agenda. 
9. Referências bibliográficas 
S.L. Pfleeger, Engenharia de Software: Teoria e Prática, São Paulo: Prentice Hall, 2ª edição, 2004. 
R.S. Pressman, Engenharia de Software, Rio de Janeiro: McGraw Hill, 5ª edição, 2002. 
I. Sommerville, Engenharia de Software, São Paulo: Addison-Wesley, 6ª edição, 2003. 
A. R. C. Rocha, J. C. Maldonado, K. C. Weber, Qualidade de Software: Teoria e Prática, São Paulo: Prentice Hall, 
2001. 
B. Booch, J. Rumbaugh, I. Jacobson, UML guia do usuário: Campus, 12ª edição, 2000.